autoboxing

Autoboxing is rather scary. While I fully understand the difference between == and .equals I can't but help have the follow bug the hell out of me: final List<Integer> foo = Arrays.asList(1, 1000); final List<Integer> bar = Arrays.asList(1, 1000); System.out.println(foo.get(0) == bar.get(0)); System.out.println(foo.get(1) == bar.get(1)); That prints true false Why did they do it this way? It something to do with cached Integers, but if that is the case why don't they just cache all Integers used by the program? Or why doesn't the JVM always auto unbox to primitive? Printing false false or true

I want to convert a primitive to a string, and I tried: myInt.toString(); This fails with the error: int cannot be dereferenced Now, I get that primitives are not reference types (ie, not an Object) and so cannot have methods. However, Java 5 introduced autoboxing and unboxing (a la C#... which I never liked in C#, but that's beside the point). So with autoboxing, I would expect the above to convert myInt to an Integer and then call toString() on that. Furthermore, I believe C# allows such a call, unless I remember incorrectly. Is this just an unfortunate shortcoming of Java's autoboxing

The following compiles without any problem boolean flag = true; Boolean flagObj = flag; Now imaging the following scenario interface ITest{ Boolean getStatus(); } class TestImpl implements ITest{ public boolean getStatus(){ // Compile error: return type is incompatible return true; } } My question is about the compile error at the mentioned line. My Interface mentions return type as Boolean but the implemented method returns boolean ( the literal ) My question is, if Boolean and boolean are compatible then why the compiler is complaining ? Doesn't the autoboxing apply here ? You can only

Please help me understand this piece of code in the kotlin docs:- val a: Int = 10000 print(a === a) // Prints 'true' val boxedA: Int? = a val anotherBoxedA: Int? = a print(boxedA === anotherBoxedA) // !!!Prints 'false'!!! Now, I understand that first int a = 10000 then in the next line it is comparing it using === . Now the question is why when it assigned boxedA=a , it checked if it is null using int? . Can it just be written like this:- val boxedA: Int=a Please if I'm understanding it the wrong way, someone guide to check the right place or explain it a bit for me. when it assigned boxedA =

I'm a little confused by a warning that my Eclipse IDE is currently writing next to every expression where types are autoboxed or autounboxed: The expression of type x is boxed into X The expression of type X is unboxed into x Is this a warning I should react on? I thought autoboxing was a Java language feature - but now I seem to get warnings everytime this feature is used. I don't think Eclipse does this by default (mine does not), but you can turn it on or off using Preferences > Java > Compiler > Errors/Warnings > Potential programming problems > Boxing and Unboxing Conversions. It should

Please consider 2 cases: //1 Short s = 10; //obviously compiles //2 takeShort(10); //error - int is not applicable //where: static void takeShort(Short s) {} I assume that case 1 is changed by compiler to : short _temp_s = 10; Short s = Short.valueOf(_temp_s); Could you please explain what compiler is trying to do in case 2, so it does not compile ? If it is not trying to apply autoboxing as it does in case 1, then why ? EDIT Reference to JSL in johnchen902 answer explains compiler's behaviour. Still not exactly clear why JLS does not support "A narrowing primitive conversion followed by a