What are you wishing or waiting for in Java?
Java grants new wishes every six months in feature releases.
Wishing or Waiting?
I made a wish in 2004 for lambdas to find their way into Java. I waited for a decade for lambdas to arrive, and they eventually arrived. Java has been a much better programming language to work in ever since. Lambdas, method references, and default methods were all amazing features in Java 8 that library developers could use to develop even better products. Java 8 kind of gave me everything I ever wanted in Java, except for eight tiny little things with generics.
In the rest of this blog, I will explain a wish we are still patiently hoping will arrive in the the JDK one day, but that we decided over a decade ago to not wait for. Waiting for the feature would have hamstrung development of Eclipse Collections primitive collection support. Not waiting was absolutely the right decision for the library. Eclipse Collections users have been able to leverage a plethora of Functional Interface type combinations with lambdas for the past decade. This combination of Functional Interfaces will likely not be found anywhere else. I’m sure many developers have had to create a smaller number of their own named Functional Interfaces when they needed them, just as we have in Eclipse Collections. Java Stream did exactly the same thing with IntStream, LongStream, and DoubleStream, just on a smaller scale than we did in Eclipse Collections.
Library first, Valhalla later
Lambdas implemented with nominal types simultaneously created a tremendous opportunity, and unfortunate deficiency for Java. Java has support for lambdas, but does not have support for Generics Over Primitive Types. We have Object and primitive collections in Eclipse Collections, and wanted our Functional Interfaces to work with all combinations of primitive types.
We decided to solve this problem in the library, as we couldn’t wait for the language to have support for primitives in generics. Sometimes library developers are faced with the difficult decision of incurring cost and implementing something today, that may be made much simpler in the future with improved language support. We made the decision to implement primitive collections with a feature-rich API around 2012 (pre-lambda days), so the cost of implementing the interfaces has long been paid off in my opinion. Code generation using StringTemplate made the problem much easier to implement.
Below is an image depicting one dimension of the resulting cost of supporting all primitive types in Functional Interface type combinations in Eclipse Collections. This mind map shows the explosion of types that occurred for one set of Functional Interfaces called Procedure. Procedure is the equivalent of Consumer in the JDK. Ideally, there should only be two Procedure Functional Interfaces in Eclipse Collections — Procedure and Procedure2. As the diagram below shows, there are a lot more than two Procedure types in Eclipse Collections.
Note, Procedure has a void return type. The picture for Predicate would be equally and painfully annoying to draw, because Predicate has a boolean return type. The picture for Function which has a variable return type would be too painful for any human to draw by hand. You just need to imagine it is really bad. Yes, Eclipse Collections did the hard work of generating all of the Functional Interface types to support primitives for Procedure, Predicate, Function, and Comparator. Note: Click the links to see the actual code generated interfaces in JavaDoc.
I created a much abbreviated version of this picture in a table in the book Eclipse Collections Categorically. The table requires you to imagine replacing a wildcard (?) with combinations of boolean, byte, char, short, int, float, long, double and sometimes Object. This shows why Function is even worse. It has an extra ? to deal with in the type names for the return type (see row 2 and 4 below).
The resulting explosion takes eight rows from this table and results in hundreds of named types being code generated to support primitives in Functional Interface types. If the support for generics for primitives eventually arrives in Valhalla, we would only need to have eight Functional Interface type in Eclipse Collections.
The types probably have very little meaning for folks reading this blog, without knowledge of the Eclipse Collections API and how these types are encountered and/or used by developers. Below, Example 21 from the Kindle edition of Eclipse Collections Categorically shows two methods that use primitive functional interfaces that are code generated. The method select on an IntList takes an IntPredicate. As explained in comment 2, an inlined lambda is used here, so the method parameter type is never seen in the code by the reader. The method collect on IntList takes an IntToObjectFunction<Integer>. As explained but not visible in comment 4, an inlined method reference is used here, so the method parameter type is never seen in the code by the reader.
If we had waited for Valhalla to solve this type explosion problem for Eclipse Collections, we would still be waiting unfortunately. We decided to go library first, and worry about how we can possibly reduce the number of necessary types later when Valhalla with Generics Over Primitive Types arrives in some form. The Valhalla strategy has progressed and evolved over the last decade. Thankfully, we committed to and have stuck with our approach delivering much appreciated primitive collection support to our user base. It was an expense to “bite the bullet” over a decade ago and code generate all of these Functional Interfaces, but it was a one time expense. Since then we’ve been able to focus on API development and evolution on our Object and primitive container types. Lambdas and method references are available in so many magical combinations of types for Eclipse Collections.
So if we’re not waiting for Valhalla, what have we been waiting for in Java for Eclipse Collections?
We’ve been waiting for Java 17!
Wait… what? Why Java 17? What about Java 21 or the soon to be released Java 25?
Core Java library development necessarily lags behind application development in terms of language version usage. We’ve been developing using Java 11 for Eclipse Collections development for the past couple of years, but honestly there are not that many interesting language features for Eclipse Collections in 11 compared to 17. Eclipse Collections 11.x was compiled using Java 8, which is now eleven years old. Java 11 is now almost 7 years old. Java 17 is only 4 years old! Development in Eclipse Collections on Java 17 will now feel like driving in a certified pre-owned car! It might have 40K miles on it, but it is super reliable and still goes vroom!!! We are excited by the upgrade!
Eclipse Collections just went through a rapid upgrade cycle in order for us to adopt Java 17 in a release and development. Eclipse Collections 11.1 was released on Java 8, almost three years ago. Eclipse Collections 12.0 was just released on Java 11 a few weeks ago. Eclipse Collections 13.0, which is identical in features to 12.0, was released on Java 17 three days later. Development on Eclipse Collections 14.x is baselined to Java 17.
Note: The release notes and release blog for Eclipse Collections 12.0 and 13.0 are still forthcoming. Stay tuned!
We’ve been waiting for four years to upgrade Eclipse Collections development to Java 17. With the imminent release of Java 25 in September, and the completion of the Eclipse Collections 12.0 release, we decided to have another major Eclipse Collections release to just uptick the version of Java we use to compile. Upgrading to a new language version is straightforward for us in Eclipse Collections, as we continue testing against LTS versions of JDK, the current JDK release, and the current early access (EA) version of OpenJDK.
There are some features in the language in Java 17 that we can now use to simplify code in Eclipse Collections. Pattern matching for instanceof is one feature, Java Records, and Sealed Types are some others. If Pattern Matching for Switch wasn’t in preview in Java 17, we would use that in the Iterate and other utility classes as well. I hope the upgrade is another reason for developers to consider using and contributing to Eclipse Collections. The library continues to evolve thanks to folks from the open source community.
Stop wishing and waiting for unicorns
Java continues to evolve at a rapid pace. If you are waiting for something specific and epic to arrive (like Valhalla), you may be waiting for a bit still. You may also get something slightly different than you originally wished for when it arrives. I feel like we are closer than ever to seeing some major changes in the language from Valhalla, but I’m glad that we did not wait for it for Eclipse Collections. I’m excited to see if it will eventually help us reduce the number of interfaces and classes we have to support in Eclipse Collections today.
A healthy horse you can ride today is better than the unicorn you are wishing might arrive one day.
Java is great today, no matter what version you use. Java has been great since Java 8 in my opinion, and continues to get better with each release. Eclipse Collections started out its existence developed using Java SE 1.4. I will save you the trial and tribulation stories of adding generics support to Eclipse Collections in its proprietary form when I worked at Goldman Sachs after Java 5 arrived. Java 8 was, for obvious reasons, my favorite release with my most important wish granted — lambdas. It even came with a few awesome extra wishes I didn’t make including default methods, method references, and Java Stream.
If you’re wishing you had a more feature-rich collections API available in Java today, I have great news for you. That already exists in third-party library form, just not in the JDK. Eclipse Collections has been evolving a feature-rich collections API for over twenty years solving mission critical problems for applications and libraries. If you want to learn more about the Eclipse Collections API, I can recommend my book, Eclipse Collections Categorically. There are other free learning options like blogs, katas, reference guide and the Eclipse Collections README as well.
On the Valhalla waiting front, I am happy for the work to get done well instead of fast. It is, after all, an “epic refactor”, and we need it to be both useful and not break all the apps we’ve written the past 25 years. Evolution is hard and takes time. When enough interesting functionality from Valhalla arrives, I will likely advocate to get Eclipse Collections development upgraded as soon as possible so we can begin leveraging it.
Thank you for reading!
I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions. I am also the author of the book, Eclipse Collections Categorically: Level up your programming game.
Thank you for being a part of the community
Before you go:
- Be sure to clap and follow the writer ️👏️️
- Follow us: X | LinkedIn | YouTube | Newsletter | Podcast | Twitch
- Start your own free AI-powered blog on Differ 🚀
- Join our content creators community on Discord 🧑🏻💻
- For more content, visit plainenglish.io + stackademic.com
