Java Integer Fun
-
OK, I assume that, as i, j, n and m are actually objects, and not primitive types, the correct way to compare them would be using the
equalsmethod thus:boolean b1 = i.equals(j);
boolean b2 = n.equals(m);But I still don't see why
i == j! Please put me out of my misery. :)
When I am king, you will be first against the wall.
See java.lang.Integer.valueOf(int i) method code which is used for auboxing. It return the same object for values in range -128 .. 127
-
Integer i = 1;
Integer j = 1;
Integer n = 1000;
Integer m = 1000;boolean b1 = (i == j);
boolean b2 = (n == m);Now, what are
b1andb2? Surprisinglyb1is true,b2is false. Of course, if you know why it works this way, it's totally obvious. But if you're a Java novice, the code can be pretty surprising :) Let's hope Microsoft will never introduce ugly hacks like this into .NET...
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT)Ok, so here's the solution why it works this way :) First of all, we are using
Integerwrapper classes instead of the primitiveinttype. When compiling, the integral values 1 and 1000 are implicitely converted toIntegerobjects (called auto-boxing, frominttoInteger). So, we got 4 differentIntegerinstances, right? No! :) The Java VM automatically packs "small" primitive values into identical objects (1 is small, 1000 isn't small). You can easily verify this by pasting the code above into a small testing project and fire up the debugger:iandjreference the same object, whilenandmreference different objects. The==operator is comparing references, thereforeb1is true (same references) andb2is false (different references). Currently "small" means any integer between -128 and 127. But according to Sun this can change to [-32768, +32767] in the future. This packing trick has been introduced to solve performance problems when doing arithmetic with wrapper classes.
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT) -
Ok, so here's the solution why it works this way :) First of all, we are using
Integerwrapper classes instead of the primitiveinttype. When compiling, the integral values 1 and 1000 are implicitely converted toIntegerobjects (called auto-boxing, frominttoInteger). So, we got 4 differentIntegerinstances, right? No! :) The Java VM automatically packs "small" primitive values into identical objects (1 is small, 1000 isn't small). You can easily verify this by pasting the code above into a small testing project and fire up the debugger:iandjreference the same object, whilenandmreference different objects. The==operator is comparing references, thereforeb1is true (same references) andb2is false (different references). Currently "small" means any integer between -128 and 127. But according to Sun this can change to [-32768, +32767] in the future. This packing trick has been introduced to solve performance problems when doing arithmetic with wrapper classes.
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT):wtf: :omg: :~ :wtf: :omg: :~ :wtf: :omg: :~ That is absolutely insane.
--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
-
Ok, so here's the solution why it works this way :) First of all, we are using
Integerwrapper classes instead of the primitiveinttype. When compiling, the integral values 1 and 1000 are implicitely converted toIntegerobjects (called auto-boxing, frominttoInteger). So, we got 4 differentIntegerinstances, right? No! :) The Java VM automatically packs "small" primitive values into identical objects (1 is small, 1000 isn't small). You can easily verify this by pasting the code above into a small testing project and fire up the debugger:iandjreference the same object, whilenandmreference different objects. The==operator is comparing references, thereforeb1is true (same references) andb2is false (different references). Currently "small" means any integer between -128 and 127. But according to Sun this can change to [-32768, +32767] in the future. This packing trick has been introduced to solve performance problems when doing arithmetic with wrapper classes.
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT) -
Integer i = 1;
Integer j = 1;
Integer n = 1000;
Integer m = 1000;boolean b1 = (i == j);
boolean b2 = (n == m);Now, what are
b1andb2? Surprisinglyb1is true,b2is false. Of course, if you know why it works this way, it's totally obvious. But if you're a Java novice, the code can be pretty surprising :) Let's hope Microsoft will never introduce ugly hacks like this into .NET...
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT)I'm glad I don't code java.
how vital enterprise application are for proactive organizations leveraging collective synergy to think outside the box and formulate their key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. But of course, that's all a "high level" overview of things --thedailywtf 3/21/06
-
Ok, so here's the solution why it works this way :) First of all, we are using
Integerwrapper classes instead of the primitiveinttype. When compiling, the integral values 1 and 1000 are implicitely converted toIntegerobjects (called auto-boxing, frominttoInteger). So, we got 4 differentIntegerinstances, right? No! :) The Java VM automatically packs "small" primitive values into identical objects (1 is small, 1000 isn't small). You can easily verify this by pasting the code above into a small testing project and fire up the debugger:iandjreference the same object, whilenandmreference different objects. The==operator is comparing references, thereforeb1is true (same references) andb2is false (different references). Currently "small" means any integer between -128 and 127. But according to Sun this can change to [-32768, +32767] in the future. This packing trick has been introduced to solve performance problems when doing arithmetic with wrapper classes.
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT) -
Integer i = 1;
Integer j = 1;
Integer n = 1000;
Integer m = 1000;boolean b1 = (i == j);
boolean b2 = (n == m);Now, what are
b1andb2? Surprisinglyb1is true,b2is false. Of course, if you know why it works this way, it's totally obvious. But if you're a Java novice, the code can be pretty surprising :) Let's hope Microsoft will never introduce ugly hacks like this into .NET...
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT) -
:wtf: :omg: :~ :wtf: :omg: :~ :wtf: :omg: :~ That is absolutely insane.
--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
Michael Dunn wrote:
That is absolutely insane.
We are talking about Java, remember... ;)
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Ok, so here's the solution why it works this way :) First of all, we are using
Integerwrapper classes instead of the primitiveinttype. When compiling, the integral values 1 and 1000 are implicitely converted toIntegerobjects (called auto-boxing, frominttoInteger). So, we got 4 differentIntegerinstances, right? No! :) The Java VM automatically packs "small" primitive values into identical objects (1 is small, 1000 isn't small). You can easily verify this by pasting the code above into a small testing project and fire up the debugger:iandjreference the same object, whilenandmreference different objects. The==operator is comparing references, thereforeb1is true (same references) andb2is false (different references). Currently "small" means any integer between -128 and 127. But according to Sun this can change to [-32768, +32767] in the future. This packing trick has been introduced to solve performance problems when doing arithmetic with wrapper classes.
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT)But what happens when the boxed value is modified? Does some kind of "Write on copy" thing happen in the background?
Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Integer i = 1;
Integer j = 1;
Integer n = 1000;
Integer m = 1000;boolean b1 = (i == j);
boolean b2 = (n == m);Now, what are
b1andb2? Surprisinglyb1is true,b2is false. Of course, if you know why it works this way, it's totally obvious. But if you're a Java novice, the code can be pretty surprising :) Let's hope Microsoft will never introduce ugly hacks like this into .NET...
_outp(0x64, 0xAD);and__asm mov al, 0xAD __asm out 0x64, aldo the same... but what do they do?? ;) (doesn't work on NT)The people who decided that should be euthanized as a service to humanity.
Software Zen:
delete this;