7 ms·

Java objects have functionality beyond dispatch tables. Synchronization is one. You can also have x != y where x and y are different objects with the same value

Java objects have functionality beyond dispatch tables. Synchronization is one. You can also have x != y where x and y are different objects with the same value.

Someone 15y ago
For integers, implementations are allowed to have unique instances for every value (and must have unique ones for some small values). A conforming implementation can extend that to 'all integers' (It might break existing programs, but such programs would not be standard conforming). I do not know whether the standard currently allows for code that is guaranteed to produce Double's with equal values that are not object.Equal to each other, but I doubt that making that impossible will introduce many problems.
tsotha 15y ago
>You can also have x != y where x and y are different objects with the same value. May be true, but it's not guaranteed one way or the other. In the Oracle JVM the smaller integers are cached such that new Integer(10) == new Integer(10) but new Integer(1000) != new Integer(1000)
- teraflop 15y ago
  Actually, "new Integer()" is guaranteed to always return a new, distinct object. The caching only comes into play during autoboxing conversions, or when you call Integer.valueOf().
  - tsotha 15y ago
    Ah, you're right. I was thinking of autoboxing, i.e. Integer a; Integer b; a = 10; b = 10; a == b; // true a = 1000; b = 1000; a == b; // false
kingkilr 15y ago
The only issue that comes up is synchronization, because it requires maintaining identity, localized escape analysis alleviates a lot of the burden here, but the fact remains that anytime you escape an Integer you'll need to allocate it, because you might want to synchronize on it, without the synchronization issue you can come up with schemes to avoid allocating even if the object does escape. Every other issue can be handled by a compiler optimization (either AOT, or JIT).

Java objects have functionality beyond dispatch tables. Synchronization is one. You can also have x != y where x and y are different objects with the same value.

Someone 15y ago

For integers, implementations are allowed to have unique instances for every value (and must have unique ones for some small values). A conforming implementation can extend that to 'all integers' (It might break existing programs, but such programs would not be standard conforming). I do not know whether the standard currently allows for code that is guaranteed to produce Double's with equal values that are not object.Equal to each other, but I doubt that making that impossible will introduce many problems.

tsotha 15y ago

>You can also have x != y where x and y are different objects with the same value. May be true, but it's not guaranteed one way or the other. In the Oracle JVM the smaller integers are cached such that new Integer(10) == new Integer(10) but new Integer(1000) != new Integer(1000)

teraflop 15y ago
Actually, "new Integer()" is guaranteed to always return a new, distinct object. The caching only comes into play during autoboxing conversions, or when you call Integer.valueOf().
- tsotha 15y ago
  Ah, you're right. I was thinking of autoboxing, i.e. Integer a; Integer b; a = 10; b = 10; a == b; // true a = 1000; b = 1000; a == b; // false

kingkilr 15y ago

The only issue that comes up is synchronization, because it requires maintaining identity, localized escape analysis alleviates a lot of the burden here, but the fact remains that anytime you escape an Integer you'll need to allocate it, because you might want to synchronize on it, without the synchronization issue you can come up with schemes to avoid allocating even if the object does escape. Every other issue can be handled by a compiler optimization (either AOT, or JIT).