Last week, I participated as a panelist for a London Java Community hosted discussion on "What's happening with Java." Panelists Kate Stanley (@KateStanley91), Bruno Borges (@brunoborges) and myself answered questions around this topic. The three of us bring various perspectives, including Java application development, platform development, JVM development, open source involvement and project management expertise. In this blog post, I've highlighted some of what was discussed. You can also view the discussion on YouTube.
One thing that we've all noticed is that Java developers are doing a great job bridging the great divide from Java 8 to 11+. From our observations as members of the Java community, there is greater general confidence around Java 11+ features in discussions and conference talks in the last year or so. For open source projects, introducing newer Java versions no longer seems to be a skill barrier for contributors.
Those observations are also reflected in the data. According to New Relic's "2022 State of the Java Ecosystem," 48.44% of Java users now use Java 11 in production, compared to 46.45% using Java 8. Just two years ago, 84.48% were still on Java 8.
Java's container story helps make upgrading versions easier, as well, since Java runtimes can be shipped alongside applications and not maintained on the server. We'll see how this impacts adoption time when the next LTS release, Java 21, comes out next year.
Another observation is that now that the 6-month release cycle has been in place for a few years, the panel observed more discussions around new language and incubation features. It's great to see the ownership the Java community feels around the future of the language.
Being familiar with changes between releases is the obvious answer.
But more than that, something developers struggle with is to justify the move to their leadership team. The answer shouldn't just be new APIs and language features, but instead: what is the benefit to the company and development team? The areas identified during this discussion were performance improvements, memory cost savings, technical debt, and appeal to new employees or contributors.
Performance and memory savings can help alleviate constraints around CI/CD, such as large test jobs, which can help improve developer productivity. Memory saving can also be helpful for applications running on premise where hardware is limited.
Another consideration is technical debt. Some teams will choose to ignore it more than others, depending on the longevity of the project. For applications that are invested in for the long term, keeping up with releases helps save developer time by making the work required to upgrade smaller. For example, users still stuck on 6/7/8 will have a huge jump when thinking about upgrading to Java 21 next year. Being this far behind can, in the worst case, lead to excess support expenses depending on your JDK provider. Upgrading to the latest LTS (Long Term Support) release is recommended, and tracking API removals and those deprecated for removal is an even better strategy.
Finally, using the latest Java is a great recruitment strategy. Developers want to work with companies using the latest technology to keep their skills up to date. Developers prefer to get paid to learn what's new, not be stuck on legacy technologies.
While these projects are gaining traction, most users still run traditional JVMs. Static Java requires some additional learning, especially because it relies on a closed world assumption, where classes cannot be loaded during runtime that are not already known by the application. This makes commonly used features like reflection tricky.
Recent happenings in the world of Static Java are OpenJDK's Project Leyden that has been ramping up in discussion on the mailing list in the past month. This project helps pave the way toward answering questions about standardizing static images in the Java language, and what technical approach will best accomplish its performance and footprint goals. It was recently announced that changes will be introduced incrementally, and constraints may at first be weaker than a fully closed world.
What technology is best depends on the application's use. There is no one size fits all for all types, including phone apps, web applications and desktop applications. The answer is to choose what makes the most sense for your platform, because the experience needs will be different for different audiences. Solutions that promise to generate all types of applications may not deliver well, especially in terms of performance.
A big thank you to the London Java Community and RecWorks Ltd for hosting this fun and insightful event. Look out for more articles on Java technology coming soon on DevZone.