> I could show you benchmarks and memory savings of using primitive collections instead of boxed collections. If you need to see these to be convinced of the benefits of primitive collection support in Java, then you probably don’t need support for primitive collections in Java. No need to read any further. Please accept this complimentary set of eight boxes for your collection travels.
This is intellectually lazy. The performance characteristics of boxed vs unboxed primitives isn't forbidden knowledge from the necronomicon that only the select few are ready to partake in. Even if you think it's obvious, if you can back up an argument, go back up that argument. It makes your case stronger, it shows you know what you are talking about.
If not for other people, do it for yourself. Things that are too obvious to bother checking is generally where we're most likely to be wrong about things. This is true in life in general but it's especially true with the JVM and it's continuously evolving performance characteristics.
I can believe it’s less of an issue for primitive smaller than long/double where the boxing/unboxing can be hidden through tagged values. But long and double specifically will always end up larger and slower. But the JVM doesn’t do this - instead it caches boxed representations of -128 to 128, true and false. This means any collection of not Boolean and not short/char will inherently at least use much more ram and have overhead accessing it.
That's a good start that explains some of the memory overhead (along with the sizable Java object header), but we also need to take into account memory locality to explain why this is so much slower.
Main memory access is at worst case order of 100x slower than a cached read. With boxed primitives you very often looking and main memory access, whereas naked primitives can (when the planets align) amount to cached memory access.
Tagged pointers don't buy as much performance as you'd expect in Java. That's because the JVM is highly multithreaded, and the Java memory model guarantees memory safety (unlike in Go, for example). So every pointer load from RAM will need a check for the tag bits. And you end up with your code full of branches.
From practical experience, JVMs have had an option to use compressed pointers for inner fields for two decades ( https://wiki.openjdk.org/display/HotSpot/CompressedOops ). It saves a bit of RAM, but often results in slower code.
I have an unpopular opinion. I simply do not read anything on medium anymore. I in fact have a ublock rule that blocks the site so I do not accidentally go there or give them traffic anymore.
I saw go in the title so I just checked the HN comments first.
It's especially confusing for native English speakers because 'go' should only be capitalized when it's the first word in the sentence or being used as the name of something (such as the Go programming language)
And it's also confusing why people keep posting walled off articles on HN.
No specialised generics at first, and this "beta" Early Access flattens only tiny objects on the heap, but changes to both will come later. Most of the foundation is there.
Looking forward to when Valhalla and generics specialization obviates these concerns -- but, every time I watch a presentation by Remi Forax he makes a joke or remark about what a hard problem it is and how long it will take. (Hope this doesn't get him in trouble!) https://youtu.be/JI09cs2yUgY?si=WBiXRpnir9HhNNfK
> Maybe you can afford to wait for Project Valhalla to arrive and finally build the applications and libraries you really want to build
Or just use one of many languages that support generics over primitive types right now?! I get it, I also write Java but if some application would benefit greatly from some feature another language has, I don’t really think too much about it. Having a few languages under your belt is really good, and most companies these days know that and have at least a couple of “approved” languages. People normally can learn a new language fairly quickly. With AI now it’s easier than ever.
It's not really possible to switch to another language without giving up one or more of:
- Free, high quality concurrent GC
- Advanced JIT with best-in-class runtime optimization of dynamic dispatch and virtual methods
- Depth of the Java ecosystem and tooling
I've written some fairly large applications where I dropped in these primitive-specialized collections when needed, it really presented no issues and was quite a bit simpler than a leap to an entirely new language and runtime. They can be composed fairly easily into AoS style data structures.
To be honest the bigger headache from the current lack of value types comes from not being able to work with more involved temporary objects without the JIT giving up on escape analysis and putting them on the heap, which requires putting hacky approximations of out params in local fields. I'm optimistic this is going to be one of the earlier optimizations delivered by Valhalla.
Year ago I wrote a very simple SAT solver in Java. I initially used List but later primitive arrays to represent my formulas and clauses. The change made a modest and measurable difference, but I agree with the author's suggestion that if you don't already care about the difference in boxed and primitive performance then you're likely fine using the standard Java collections.
Thanks, I've mostly used fastutil lately because it seems to be best maintained. I'll have to look at carrotsearch labs though, I like the approach of a clean break with java.util.collections.*.
Eclipse Collections also comes with an API that seems nicer than the one provided by the standard library - so it might be worth checking out even if you're not interested in primitives.
> I could show you benchmarks and memory savings of using primitive collections instead of boxed collections. If you need to see these to be convinced of the benefits of primitive collection support in Java, then you probably don’t need support for primitive collections in Java. No need to read any further. Please accept this complimentary set of eight boxes for your collection travels.
This is intellectually lazy. The performance characteristics of boxed vs unboxed primitives isn't forbidden knowledge from the necronomicon that only the select few are ready to partake in. Even if you think it's obvious, if you can back up an argument, go back up that argument. It makes your case stronger, it shows you know what you are talking about.
If not for other people, do it for yourself. Things that are too obvious to bother checking is generally where we're most likely to be wrong about things. This is true in life in general but it's especially true with the JVM and it's continuously evolving performance characteristics.
I can believe it’s less of an issue for primitive smaller than long/double where the boxing/unboxing can be hidden through tagged values. But long and double specifically will always end up larger and slower. But the JVM doesn’t do this - instead it caches boxed representations of -128 to 128, true and false. This means any collection of not Boolean and not short/char will inherently at least use much more ram and have overhead accessing it.
That's a good start that explains some of the memory overhead (along with the sizable Java object header), but we also need to take into account memory locality to explain why this is so much slower.
Main memory access is at worst case order of 100x slower than a cached read. With boxed primitives you very often looking and main memory access, whereas naked primitives can (when the planets align) amount to cached memory access.
Tagged pointers don't buy as much performance as you'd expect in Java. That's because the JVM is highly multithreaded, and the Java memory model guarantees memory safety (unlike in Go, for example). So every pointer load from RAM will need a check for the tag bits. And you end up with your code full of branches.
From practical experience, JVMs have had an option to use compressed pointers for inner fields for two decades ( https://wiki.openjdk.org/display/HotSpot/CompressedOops ). It saves a bit of RAM, but often results in slower code.
More recently, the new ZGC collector started using colored pointers, there's a good presentation about it: https://inside.java/2025/10/06/jvmls-zgc-colored-pointers/ It's also been a mixed bag, performance-wise.
This is extremely well trodden ground, and he's right. The world doesn't need him to spend time explaining that water is wet.
And I think he's also acknowledging that not everybody has an application that needs these performance optimizations.
I have an unpopular opinion. I simply do not read anything on medium anymore. I in fact have a ublock rule that blocks the site so I do not accidentally go there or give them traffic anymore.
I saw go in the title so I just checked the HN comments first.
Am I wrong to have expected this to be about using Golang in Java, in some way?
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo
https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...
Yes, "Go in a box" isn't exactly idiomatic english usage, in addition to the capitalisation mentioned be a sibling.
It's a stupid language name. You are correct.
I look forward to my next programming language ,"the"
I think you could get more attention to it by calling it "Al", short for "A language"
I guess the title is confusing to non-native speakers, especially the part after the comma.
It's especially confusing for native English speakers because 'go' should only be capitalized when it's the first word in the sentence or being used as the name of something (such as the Go programming language)
And it's also confusing why people keep posting walled off articles on HN.
I'm a highly literate native speaker...
Had same expectation and read through half the article before realizing it was not Golang related.
Go, not Golang.
Golang is called Go, though. "The Go Programming Language". So I see how in a programming-related blog post people can get confused by the word Go.
You can start trying the first part of Project Valhalla today (with a ready-made JDK build): https://inside.java/2025/10/27/try-jep-401-value-classes/
No specialised generics at first, and this "beta" Early Access flattens only tiny objects on the heap, but changes to both will come later. Most of the foundation is there.
Looking forward to when Valhalla and generics specialization obviates these concerns -- but, every time I watch a presentation by Remi Forax he makes a joke or remark about what a hard problem it is and how long it will take. (Hope this doesn't get him in trouble!) https://youtu.be/JI09cs2yUgY?si=WBiXRpnir9HhNNfK
> Maybe you can afford to wait for Project Valhalla to arrive and finally build the applications and libraries you really want to build
Or just use one of many languages that support generics over primitive types right now?! I get it, I also write Java but if some application would benefit greatly from some feature another language has, I don’t really think too much about it. Having a few languages under your belt is really good, and most companies these days know that and have at least a couple of “approved” languages. People normally can learn a new language fairly quickly. With AI now it’s easier than ever.
It's not really possible to switch to another language without giving up one or more of:
- Free, high quality concurrent GC
- Advanced JIT with best-in-class runtime optimization of dynamic dispatch and virtual methods
- Depth of the Java ecosystem and tooling
I've written some fairly large applications where I dropped in these primitive-specialized collections when needed, it really presented no issues and was quite a bit simpler than a leap to an entirely new language and runtime. They can be composed fairly easily into AoS style data structures.
To be honest the bigger headache from the current lack of value types comes from not being able to work with more involved temporary objects without the JIT giving up on escape analysis and putting them on the heap, which requires putting hacky approximations of out params in local fields. I'm optimistic this is going to be one of the earlier optimizations delivered by Valhalla.
C#?
Year ago I wrote a very simple SAT solver in Java. I initially used List but later primitive arrays to represent my formulas and clauses. The change made a modest and measurable difference, but I agree with the author's suggestion that if you don't already care about the difference in boxed and primitive performance then you're likely fine using the standard Java collections.
Thr article doesn’t mention GNU Trove, which has addressed this use case. Trove has been around so long it’s homepage is still on Soureforge.
I have a few more primitive collection libraries in my bag if someone would like to shop around:
- PCJ: https://pcj.sourceforge.net/
- fastutil: https://github.com/vigna/fastutil
- HPPC: https://labs.carrotsearch.com/hppc.html
PCJ was last updated in 2003 and is now quite long in the tooth though.
Thanks, I've mostly used fastutil lately because it seems to be best maintained. I'll have to look at carrotsearch labs though, I like the approach of a clean break with java.util.collections.*.
The Agrona Java library from the Aeron people has some primitive optimized collections too: https://github.com/aeron-io/agrona
> For better or worse, we’ve had them in Java for over 30 years.
Just in case someone wants to feel old. C was younger when Java 1.0 was launched than Java is now.
Also worth mentioning the Cern Colt API...
https://dst.lbl.gov/ACSSoftware/colt/
https://en.wikipedia.org/wiki/Colt_(libraries)
https://link.springer.com/chapter/10.1007/978-1-4302-0854-9_...
Eclipse Collections also comes with an API that seems nicer than the one provided by the standard library - so it might be worth checking out even if you're not interested in primitives.
FYI this has nothing to do with the Go language :)
And here I was, wondering if it was about embedding go in a java program... ahah.