by marginalia_nu
2 subcomments
- > 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.
 
- 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.
 
- Am I wrong to have expected this to be about using Golang in Java, in some way?
 
- 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.
 
- 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.
 
- > 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.
 
by itronitron
0 subcomment
- 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.