Comment by morcus

3 days ago

It's because the collection types (and generics) don't support primitives, only objects. So you been to stuff the primitives into objects to use them with a lot of the standard library.

One of the more amusing bugs I had to figure out resulted from the fact that some of the autoboxed values get cached, resulting in peculiar behaviour when someone managed to reflectively change the boxed primitive value...

i.e. something like:

  Integer x = 42
  highlyQuestionableCode(x);
  println(x); // "24" WAT?

I'm a fan of JEP-500...

https://openjdk.org/jeps/500

That doesn't sound very pleasant.

  • Well, it was annoying until autoboxing came in.

      // Before autoboxing
      list.add(new Integer(42));
    
      // After autoboxing
      list.add(42);
    

    Mostly it's a non-issue now. If you're desperately cycle/memory constrained you're likely not using Java anyway.

    • You can get pretty good performance out of Java these days, so long as you know to avoid stuff like boxed primitives and the streams api, as they generally have god-awful memory locality, and generally don't vectorize well.

      3 replies →

    • If you're desperately cycle/memory constrained you're likely not using Java anyway.

      Java Cards would like to have a word with you. But yeah I know what you mean.

  • There are libraries, like fastutil, that provide collections for primitive types.

  • Either the same of this feature or always hiding the boxing (e.g. a Python int is actually a wrapper object as well, with some optimizations for some cases like interning) is the case in almost all languages.

    • I personally use Julia, which does not have such boxing issues. Rust, C, C++, and Fortran also avoid boxing like this. Perhaps Go is also free from such boxing? Python does it, that's true.