4 ms·

A bigger issue I think is Java's need to box values, primitive or otherwise. For example, even an ArrayList of integers creates an object for each one. IMHO, th

A bigger issue I think is Java's need to box values, primitive or otherwise. For example, even an ArrayList of integers creates an object for each one. IMHO, the Java runtime has many of the design hallmarks of a dynamic language, with strong (generic) types somewhat bolted on.

peter_lawrey 4y ago
A friend of mine is working at Oracle on collections that support primitives e.g. List<int>, Set<long> https://openjdk.org/jeps/8261529 https://openjdk.org/jeps/8261529
WastingMyTime89 4y ago
It’s not always obvious what’s actually boxed and what isn’t however. The JVM tries to do clever optimisation. For example, I’m fairly certain that when you manipulate an array of primitive numerical values, they are not actually unboxed before each operation before being boxed again.
- kjeetgill 4y ago
  Hmmm. As much as I hate having to fix boxing problems, I usually find it pretty obvious when boxing can occur. Pretty much any time a variable/parameter type or a function return type uses capitalized Integer, Long, Boolean, etc. instead of lowercase int, long, boolean, etc. boxing is probably occurring. Those ... and assigning those to Object or Number. I think that's exhaustive. You can pretty much grep through and remove them from 90 % of coffee with a little refactoring and replacing HashMaps with specialized ones. Only if there's null returns or ConcurrentHashMaps involved does it get tricky. An array of primitives like byte[] or long[] isn't Byte[] or Long[]. The former don't cause boxing. Maybe you're thinking of ArrayList<Byte>?
  - WastingMyTime89 4y ago
    > Pretty much any time a variable/parameter type or a function return type uses capitalized Integer, Long, Boolean, etc. instead of lowercase int, long, boolean, etc. boxing is probably occurring. That probably occurring hides a lot of complexity. That’s my original point. Optimisations are happening especially when Integer and Long are involved. There are sometimes actually less boxing than you would expect reading the code.
    - kjeetgill 4y ago
      True, but I'd argue you should treat those probable boxing situations and definitely boxing and remove them.
zbentley 4y ago
> the Java runtime has many of the design hallmarks of a dynamic language, with strong (generic) types somewhat bolted on. I'd say it's the opposite. Dynamic languages largely use boxing as the indirection mechanism for their highly dynamic type systems, since it works well there. But boxing isnt synonymous with type flexibility, and Java uses it for other reasons (mostly).
- grumpyprole 4y ago
  The Java runtime provides runtime type information for all types, and extensive reflection is available, including for example invoking arbitrary code. Very dynamic and a significant problem for static analysis, optimisation and security.

peter_lawrey 4y ago

A friend of mine is working at Oracle on collections that support primitives e.g. List<int>, Set<long> https://openjdk.org/jeps/8261529 https://openjdk.org/jeps/8261529

WastingMyTime89 4y ago

It’s not always obvious what’s actually boxed and what isn’t however. The JVM tries to do clever optimisation. For example, I’m fairly certain that when you manipulate an array of primitive numerical values, they are not actually unboxed before each operation before being boxed again.

kjeetgill 4y ago
Hmmm. As much as I hate having to fix boxing problems, I usually find it pretty obvious when boxing can occur. Pretty much any time a variable/parameter type or a function return type uses capitalized Integer, Long, Boolean, etc. instead of lowercase int, long, boolean, etc. boxing is probably occurring. Those ... and assigning those to Object or Number. I think that's exhaustive. You can pretty much grep through and remove them from 90 % of coffee with a little refactoring and replacing HashMaps with specialized ones. Only if there's null returns or ConcurrentHashMaps involved does it get tricky. An array of primitives like byte[] or long[] isn't Byte[] or Long[]. The former don't cause boxing. Maybe you're thinking of ArrayList<Byte>?
- WastingMyTime89 4y ago
  > Pretty much any time a variable/parameter type or a function return type uses capitalized Integer, Long, Boolean, etc. instead of lowercase int, long, boolean, etc. boxing is probably occurring. That probably occurring hides a lot of complexity. That’s my original point. Optimisations are happening especially when Integer and Long are involved. There are sometimes actually less boxing than you would expect reading the code.
  - kjeetgill 4y ago
    True, but I'd argue you should treat those probable boxing situations and definitely boxing and remove them.

zbentley 4y ago

> the Java runtime has many of the design hallmarks of a dynamic language, with strong (generic) types somewhat bolted on. I'd say it's the opposite. Dynamic languages largely use boxing as the indirection mechanism for their highly dynamic type systems, since it works well there. But boxing isnt synonymous with type flexibility, and Java uses it for other reasons (mostly).

grumpyprole 4y ago
The Java runtime provides runtime type information for all types, and extensive reflection is available, including for example invoking arbitrary code. Very dynamic and a significant problem for static analysis, optimisation and security.