Re:Rating 26 years of Java changes
by morcus on Saturday October 11, 2025 @04:11PM
(#45552275)
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.
[ Parent
| on HN ]
Re:Rating 26 years of Java changes
by JanisErdmanis on Saturday October 11, 2025 @04:21PM
(#45552362)
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.
Re:Rating 26 years of Java changes
by marginalia_nu on Saturday October 11, 2025 @04:44PM
(#45552525)
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.
Yeah, I know there are even oddballs using it for HFT and the like - I like Java a lot, but even I find that a bit peculiar.
Edit: actually, if someone here is using it for something like that I'd love to hear the rationale...?
Re:Rating 26 years of Java changes
by ivan_gammel on Sunday October 12, 2025 @01:51AM
(#45555622)
Not „oddballs“ for sure. Java established itself as the primary enterprise language for fintech in 2000s and since then there was and there is no reason to switch. It offers everything business needs including vast supply of workforce.
Re:Rating 26 years of Java changes
by marginalia_nu on Sunday October 12, 2025 @06:50AM
(#45557169)
I've worked adjacent to that space (high performance fin-tech java), enough that I feel qualified to answer.
It's mostly a trade-off. Java's tooling, reliability and ecosystem is some of the best around. Even though building high performance software in Java is a bit of a pain, looking at the bigger picture, it's often still worth it.
Re:Rating 26 years of Java changes
by commandersaki on Sunday October 12, 2025 @09:20AM
(#45558057)
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.
Re:Rating 26 years of Java changes
by JanisErdmanis on Saturday October 11, 2025 @05:25PM
(#45552845)
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.
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...