Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

What do the experts think about Java in 2019?

2019 promises to be an exciting year in Java, with changes taking effect in licensing models, the emergence of new technologies and more.

We reached out to industry experts, who share their perspectives on Java in 2019. We then asked internal Java experts at Rogue Wave to weigh in on the industry experts’ thoughts.

Java Module System

Note: This segment comes directly from Johan Vos, co-founder and CTO, cloud products at Gluon (Follow Johan: Twitter | LinkedIn)

The Java Module System and the new release cadence are big changes in the Java world. Java is well known for its stability and maturity. While the modular system and the 6-months releases in the longer term really help to achieve those goals, they might require different strategies from companies.

In the past, companies often had different strategies for the core JDK versus dependencies they use in projects. Changes in the JDK (installing updates) are typically done at a company-wide level, where changes in dependencies is something every developer is familiar with (e.g. bump the Spring version from 5.1.2 to 5.1.3).

It is much easier to manage life cycles of those dependencies, as this typically simply require changing one line in a build.gradle or pom.xml file. Obviously, installing a new JDK is more intrusive.

Decoupling of JavaFX from the core JDK

Note: This segment also comes directly from Johan Vos (see job title and profile links above).

The decoupling of JavaFX from the core JDK is a very interesting evolution. It is now much easier for developers to update JavaFX dependencies in their projects, and if something goes wrong they can very easily go back to a previous version, just by changing that one line in build.gradle or pom.xml.

There are still many things in the core JDK that would benefit from this decoupling. Removing something from the core doesn’t mean it is not maintained anymore, on the contrary. It makes it easier to develop, without having to worry about other components that are not related, but that require a very high level of expertise.

Note: Toomas Römer, CTO Rebel portfolio at Rogue Wave Software, had the following reaction to Johan’s comments:

In the long run, this is great, but it will take some time to actually become useful. End users will be presented with JDK-specific builds for a while because of this.

Oracle requires a paid subscription to use Java SE 8

As of January 2019, Oracle requires a paid subscription to continue to receive updates for Java SE 8.
Note: This segment comes directly from Charles Nutter, senior principal software engineer at Red Hat (Follow Charles: Twitter | LinkedIn)

The initial reaction to this was overplayed, I think.

Folks got used to deploying Oracle’s JDK updates long after newer versions had been released. Supporting multiple old versions is a massive resource drain on any company, and without a paid option it meant core JVM and Java implementers got pulled away to do maintenance.

Now, it will be less convenient for folks to have supported Oracle JDKs over the long term, but that in turn has opened up a whole new market for JDK support. Red Hat, Amazon, Zing, Google, Twitter all have their own JVM builds, and more and more companies are getting in on the support gig.

Oracle itself will be able to keep core Java developers working on Java and fund the support side via paid users. Add to that the fact that IBM has open-sourced their J9 JVM and you’ve got a nicely competitive field once again. Hopefully this will bring about a rebirth in research and interest in the JVM!

Note: Sander Sõnajalg, JRebel product manager at Rogue Wave Software, shared his thoughts:

Having open competition again in the JVM landscape is indeed interesting. This will probably keep Oracle’s pricing in check, as there are alternatives. For most companies, competition based on features and performance is probably not very relevant, as most of times JVM is the invisible underlying infrastructure that “just works”.

Probably the real difference between JVMs comes out for huge SaaS services (e.g. Netflix), where processing amounts are huge and the extra 1% of performance gain can have a large impact.
Support models

Note: Related to Oracle’s move to a paid subscription for Java SE 8, the thoughts below are from Johan Vos.

Developing core software requires skilled developers to work on it. Somehow, these developers need to be paid. I see a number of models popping up. In general, there seems to be a convergence where the latest version of Java software are free, and developers are encouraged to use those.

For companies that want long-term support for specific versions (e.g., if they can’t change every 6 months to new versions), there are options to get commercial support. I think this is a good thing, as it allows the companies funding the core development to keep investing in this core development.

This is something the industry needs to realize, though. The whole model requires a relation between code contributions and distributions. Simpy redistributing for free what other companies created in an open-source context is totally fine from a legal point of view, but it seems dangerous to me.

It makes more sense to buy support from the companies that are also heavy contributors to the open source projects, as this is the best guarantee that the open source project (e.g., Java, JavaFX) will be funded.

Note: Andres Luuk, JRebel product developer at Rogue Wave Software, shared his thoughts on support models:

The new support models will give the majority of small and medium web application developers a strong incentive to upgrade more often. In the past, they’d be stuck on the latest security update of whatever Java version they originally started out with.

Of course, now they might just be stuck on the LTS version. It will probably not affect the larger enterprises because they’re probably already paying for commercial support for Java, even if they never encounter any actual bugs.

Java and scientific applications

Note: This segment also comes directly from Johan Vos.

There is a huge area that is still relatively unoccupied. While you can use Java in scientific applications (there even exist great tools for it), there is sort of an image problem, where Java is often associated with “cloud-native” only.

However, Java is very well-suited for scientific applications and one of its biggest strengths is that it combines scientific opportunities with enterprise stability, scalability and security.

I expect to see more frameworks and libraries in the Java ecosystem that address data scientists and Quantum Computing developers. With those frameworks and libraries, developers can work on scientific issues first (e.g. create/experiment/test a great neural net or a quantum algorithm) and once the results are satisfying, the same code can be used to put this in production on enterprise systems.

Using Java from the beginning minimizes the risk that a project gets killed between the stage of prototyping and production.

Challenges for Java in containerization

Note: This segment comes directly from Charles Nutter.

The first and perhaps biggest challenge will be fitting Java apps into smaller and smaller containers. Everything’s going to tiny containers, sometimes containers that only run one “function” with one purpose.

Java is at a disadvantage because it was designed to be (or grew to become) a host for many containers in the form of web and EE apps. I think we’ll see Java evolve toward a process-per-service model that cuts down overall size and emphasizes fast startup and reduced warm-up times.

Note: Sander Sõnajalg shared his thoughts on Java and containerization:

Function-as-a-service (e.g., AWS Lambda) and microservices architecture is about going to the extreme with service granularity, where each service can be implemented in any given language.

If some other language will be more suitable for a specific small service (e.g., due to faster warm-up), it will probably get chosen over Java. Regardless of that, Java will continue to be the language of choice for large, integrated enterprise systems, where the inertia is huge and Java’s benefits are obvious.

Note: Andres Luuk adds:

I agree that there will be a focus on making services and applications smaller, especially for newer applications. And a faster start-up time will be important, but older applications will continue as they are.

Java challenge: Remaining standard, open, and relevant

Note: This segment comes directly from Charles Nutter.

A challenge in 2019 is keeping the platform itself standard, open, and relevant. There are many alternatives these days, from languages like Rust and Go that have grown up in this new container world, all the way to C# and .NET that have recently become true open source and were also designed for small profile and fast startup.

The JVM has an advantage in the open standards all the JCP members contribute to and the potential to host many different languages for different purposes, but it still is perceived as less free than the alternatives (often for good reasons). That’s going to be something for Oracle to work on.

Share your thoughts

Thanks for reaching the end of this post! We shared a lot of insights from Java experts. Now it’s your turn: what are your thoughts about where Java is headed in 2019? Share in the comments section below.

Thanks!