Link Details

I firmly believe that autoboxing should be removed from the language...

Well...not removed, but we should go back in time, and never add it in :-/

I would agree, the whole mess of syntactic sugar that is Java 5, generics, for each, even enums, roll them back and pretend they never happened. I think the phrase, "They only exist to the compiler" was the key indicator they were a mistake.

OMG so Java 5 IS a philosophical language.

To any guy that belongs to the JSR approval process: please stop adding stuff to Java and leave the wacky stuff to frameworks.

The generics are useful (though ugly and sometimes a pain), enums are ok but not overly useful, and the foreach is quite nice and very useful (though not really useful enough - why is there no way to do something like a foreach over a range of integers (to remove the usual counted loop)? Or even better, a foreach over something like a cross-product of ranges?).

But boxed types. Ewww! Ick! A very bad idea that is pretty much guaranteed to lead to even worse surprises than the one mentioned here.

submit it as a bug and move on... I think a better title for this post, Long.equals Bug?
Not sure how it turns into "Java 5 Is Inherently Flawed!1!"

There is nothing wrong with this behaviour. If you understand what is actually happening in this situation, it is quite simple. If you try to do the same thing in the old fashioned way you will get exactly the same result.

It has nothing to do with Java 5, there had been a bug report on that 3 years ago: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4814906 (filed against 1.4.1)

I agree that autoboxing (which has nothing to do with the behavior) is sometimes quirky, but when going back in time I'd go back to 1995 and remove the non-object types from the language.

A Long is not an Integer. When an Integer should be used as an long or a Long as an int longValue() or intValue() has to be called.

The issue had been raised in a podcast (Javaposse) a year ago and Josh Bloch replied to that (Hard to find the reference as podcasts cannot be googled) saying that although it was possible to solve this issue locally, it would create severe problems in other parts that are very hard (if at all) to fix.

Csar, absolutely correct. In my opinion, misunderstandings like this are a perfect case for the value of a good comp sci education.

The problem is in the fact that primitives are not Objects and vice versa. The problem of autoboxing would have been totally avoided if numbers would be by default Objects. Soo there would be no int, short,...but Only Integer, Short,...

Java 7+ (what I would like to see)

Integer a = 7;
Inteber b = 8;

Integer c = a + b; // it would be evaluated internally as a.add(b);

and

Boolean same = (a == b); // would be evaluated as a.equals(b)

soo there would be no possibility of such problem. And finnaly

if you can do

String hello = "hello".toUpperCase();

I would also like to see that one can do

Integer x = 9.squareRoot();

Of course not! Different objects are always different. Java does allow for one to change the compare functionality if one wants to change the comparrisons. Primatives are not objects, even with the magic

My point is - if we would get rid of primitives and make Java 100 % OOP language such as Ruby then, this problem with autoboxing would not have existed.