6 ms·

They don't say how they're implementing it. Given the compiler always knows the actual type of a primitive at compile-time, they can probably implement most of

They don't say how they're implementing it. Given the compiler always knows the actual type of a primitive at compile-time, they can probably implement most of the Object functionality by plugging in the class meta-info at compile-time. When a primitive would need to be boxed, Java programmers are already used to the performance implications of this. The only object functionality I can think of that would be hard to implement on primitives is wait/notify/synchronization, but I don't actually know how those are done in the JVM either. Even if these things turn out to be impossible to optimize at compile time, they're probably then betting on JIT functionality to detect primitive objects that are only used as primitives.

repsilat 15y ago
The "boxed primitive" types (Integer and so on) should be `final`. This means no inheriting from them, which means no polymorphism, which means their sizes and all operations on them are known statically. This means you can store them as values in the object with no fuss, and you can inline all of their access functions.
- cynicalkane 15y ago
  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).

repsilat 15y ago

The "boxed primitive" types (Integer and so on) should be `final`. This means no inheriting from them, which means no polymorphism, which means their sizes and all operations on them are known statically. This means you can store them as values in the object with no fuss, and you can inline all of their access functions.

cynicalkane 15y ago
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).