Прикольное поведение Java 1.5

обьясните несведующим причину столь замечательного и предсказуемого поведения

В том что жаба рулит! Ентырпрайз же!

А будет ли в данном случае autounboxing?

Все просто. Никакого autounboxing тут не будет, сравнение произойдет по ссылкам. i1 и i2 Java оптимизирует и сделает одной и той же ссылкой, такое же наблюдается и для String, например. А вот i3 и i4 - оптимизированы не будет (я не знаю почему) и это будет две разные ссылки. Все.

> Все просто. Никакого autounboxing тут не будет, сравнение произойдет по ссылкам. i1 и i2 Java оптимизирует и сделает одной и той же ссылкой, такое же наблюдается и для String, например. А вот i3 и i4 - оптимизированы не будет (я не знаю почему) и это будет две разные ссылки. Все.

По результатам похоже на правду, но как определяется, что i1 и i2 будут соптимизированы? Пока похоже, что если значение влезает в байт, то для него срабатывает эта "оптимизация"

Вообще забавно. Такое происходит только с 127, -127. Причем под эти числа Java 1.6 выделяет постоянно один и тот же адрес. Либо 86, а если он занят 441.

> А вот i3 и i4 - оптимизированы не будет (я не знаю почему) и это будет две разные ссылки. Все.

за это мы и людим жабу (%

Да, вы правы. Если влизает в знаковый байт.

> обьясните несведующим причину столь замечательного и предсказуемого поведения

Причина в том, что не надо заниматься глупостями, экземпляры классов сравниваются только equals:

% cat Test.java 
public class Test {

    public static void main(String[] args) {
        Integer i1 = 127;
        Integer i2 = 127;

        Integer i3 = 129;
        Integer i4 = 129;

        System.out.println ("first = " + (i1.equals(i2)));
        System.out.println ("second = " + (i3.equals(i4)));
    }
}                                                                                                                                                                                  % javac Test.java 
% java Test      
first = true
second = true

// :(

А если заменить 129 на 126, то в обоих случаях true. Видимо связано с тем, что влезает в границы байта. В любом случае оптимизация i1 и i2 имеет право на жизнь, в связи с иммутабельностью java.lang.Integer. :)

вполне нерабочий код: боксинга здесь нету, сравнение сделано по принципу ссзб. но забавно

Разве при инициализации не получается боксинг?

Integer i1 = 127;             // тут он есть
Integer i2 = new Integer(127) // тут его нет

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Java Language Specification third edition, section 5.1.7

А вот и строгое объяснение, спасибо за информацию.

Autoboxing есть. Нет autounboxing.

Блин, а почему такие ограничения?

У меня спрашиваете? :) Ладно, понятно, что по ссылкам на лоре ходить не принято, видимо, спецификации языков читать тоже, но может быть следующий абзац из того же документа хотя бы частично удовлетворит Ваш интерес:

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly.

For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all characters and shorts, as well as integers and longs in the range of -32K - +32K.

Там еще много любопытного есть - http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html

Собственно, чтобы знать как себя ведет Java, эта книга необходима, но не достаточна. Необходимое дополнение - это, понятное дело, bugparade.

Прикольно, вы только что выставили свою безграмотность на обозрение LOR. Книжки хотя бы иногда нужно открывать, а не придумывать все программы "из головы", тогда узнаете причину такого поведения автобоксинга

Так они УЖЕ выделены - см. исходники. Остальные числа каждый раз выделяются на новом месте.

Вы тоже кой чего выставили - автобоксинг тут совсем не при чём, это явные Integer, то есть уже заведомо объекты.

> Вы тоже кой чего выставили - автобоксинг тут совсем не при чём, это явные Integer, то есть уже заведомо объекты.

тоже оценил его выпад :)

Признаюсь, JLS я не читал, хотя, возможно, вещь весьма полезная.

>Блин, а почему такие ограничения?

Чтобы не засирать память слишком большим кешем.

Спасибо, прочитал уже.

Обидно, что в треде появляются идиоты, которые и прочитать-то не удосуживаются, не то что понять, и начинают орать прописные истины про equals, которые вобщем-то всем понятны, в том числе и автору.