Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Java in 2019 - Some Predictions

Java in 2019 - Some Predictions

This item in japanese


2018 has been a very interesting year for Java, as we discussed in InfoQ's roundup of the year.

As we move into 2019, let's take a look at some of the things to watch for in the New Year in Java and related technologies, and have some fun by trying to predict what might happen.

DISCLAIMER: These are merely personal predictions by the author, and not official statements or roadmaps of any kind, from Oracle, InfoQ or anyone else.

Java 11 starts to see small, but significant adoption

This might be the least controversial prediction on this list. Java 9 and 10 saw virtually no deployment to production. Many teams seem to be waiting for a post-8 LTS release to arrive, and now that it's here, a small but steady adoption of Java 11 will begin to appear.

A big driver for this adoption will be microservices and containerized applications, both of which are significantly easier with Java 11 than Java 8. Greenfield deployments of brand-new apps will be the obvious place for teams to begin adopting Java 11.

Prediction: Java 11 is roughly 10% of the overall reported Java production installations at the end of 2019.

No large-scale porting of existing applications from 8 to 11

Until now, the Java upgrade path for applications was fairly clean. Moving from 6 to 7 or from 7 to 8 was, in almost all cases, totally painless. The same cannot be said for the 8 to 11 upgrade - significant work is usually necessary to move a non-trivial application onto the new version.

Very few application groups have the resources to undertake a port, a rearchitect and a full retest of their applications just to stay on the current version of Java. As a result, I do not expect to widespread porting of Java 8 applications to Java 11, without some other compelling external reason to do so.

Prediction: No specific quantifiable prediction.

No analogue of the Python 2 / Python 3 divide

Much has been said about the possibility that with the advent of modular Java, the ecosystem will fragment along the lines of the Python 2 / Python 3 split experienced by that community.

I do not expect this to occur for several reasons - but the main one is that Java 11 is not a fundamentally different language, at a syntactic or a semantic level. Python syntax and the meaning of key datatypes (e.g. Unicode strings or longs) does change between versions, so library and application authors must consciously choose which language version is being targeted, and this choice pervades the entire ecosystem on a per-project basis.

In the Java case, on the other hand, it is the choice of the application owner whether to embrace modularity or not; and the choice of the library developer as to whether to deploy as modules, and if so, which fallbacks to offer to Java 8 applications. The workaday Java programmer continues much as before, and programs in basically the same language whether the project they are working on is targeting Java 8 or 11.

Prediction: No specific quantifiable prediction.

Continued gradual adoption of Graal

For those projects which have moved to Java 11, interest is likely to grow in the Graal project. This includes the next-generation JIT compiler, which may reach (or even surpass) the C2 compiler (aka -server) for Java 11 in 2019.

That Graal-JIT will, sooner or later, surpass C2 seems obvious - Graal's design (especially the fact that it is implemented in Java) means that it is relatively easy for the Graal team to implement any new optimization that could be implemented in C2.

The umbrella term "Graal" also includes Oracle's semi-open GraalVM project for polyglot runtimes. However, it is important to note that Graal-JIT is only available for Java 11 and up, whereas GraalVM only covers Java 8.

Therefore, the user community for Graal may well form two disjoint groups - one focused on performance of Java 11 applications, and one focused on polyglot apps leveraging the Java 8 ecosystem.


  • 30-40% of Java 11 applications are using Graal-JIT in their Java 11 production deployments
  • Making Graal the default JIT compiler is seriously discussed for Java 13 but ultimately not implemented
  • GraalVM production deployments remain rare, but are increasingly being experimented with by application teams.

OpenJDK becomes the market leader for Java runtimes

Oracle is ending their ownership of the OpenJDK 8 project, and Red Hat has offered to take over as leaders. The same may well be true of the OpenJDK 11 project, as that project will be relinquished by Oracle when Java 12 is released.

Many developers miss the fact that Oracle's LTS offerings are only for paying customers, so in the future the only free-as-in-beer support offerings for Java 8 (and 11, once Java 12 is released) will come from non-Oracle organizations, such as Red Hat, Amazon, Azul Systems and the multi vendor, community-driven AdoptOpenJDK project.

With no further free updates to OracleJDK being made available to the community, then I expect to see a rapid transition to OpenJDK as the production platform of choice for Java applications.

The good news is that for serverside applications (& increasingly for desktop Java apps as well), OpenJDK is a drop-in replacement for Oracle's JDK.

Prediction: Over 50% of both Java 8 and Java 11 production runtimes are using OpenJDK rather than Oracle JDK, at the end of 2019.

Release of Java 12

Java 12 is feature-frozen and is due to be released in March 2019. Barring a major incident, it is hard to see that this will not ship on time.

It is not a long-term support release, and is unlikely to see wide adoption (just as Java 9 and 10 were not widely adopted).

Prediction: Java 12 releases on time, and has rounding-error production deployments at the end of 2019.

Release of Java 13

Java 13 is due to be released in September 2019. No details are available of any features currently targeted at this release.

As with Java 12, it is a feature release, not an LTS release. Accordingly, there is no reason at this time to suppose that it will not ship on time. Equally, it is unlikely to see wide adoption, with teams instead focusing on moving Java 11 into production.

Prediction: Java 13 releases on time, and has rounding-error production deployments at the end of 2019.

Value types does not ship as preview in Java 13

Value Types are the effort to bring a third type of fundamental value to the JVM, alongside primitive types and object references. The concept can be thought of as relaxing some of the rules of the Java type system, allowing composite data structures more similar to C structs, without the baggage, while retaining full Java type safety.

Brian Goetz, the Java language architect, uses the phrase: "codes like a class, works like an int" to describe how he envisages a typical developer will use the value types feature, once it has finally been delivered.

There has been sustained, continued progress towards value types, but as of the end of 2018, only experimental, very early-access, experts-only alpha prototypes have ever been produced.
This is not surprising - value types are one of the most fundamental and deep-rooted changes to the Java platform that have ever made.

The complexity and the ambition of this feature, and the corresponding sheer amount of engineering work necessary make it very unlikely that this will be delivered, even in an initial form in 2019.

Prediction: No form of Value Types is included, even as a Preview Feature in Java 13.

Initial version of match expressions ships as preview in Java 13

Switch expressions are a prerequisite for match expressions. Without an expression form present in syntax, it is impossible to deploy match expressions within the Java language. Indeed, without match expressions, there is very little point in introducing switch expressions at all.

Accordingly, I expect standardized switch expressions to be followed swiftly by simple forms of match expressions. The feature is likely to be limited to type matches only initially, with no destructuring or other advanced features.

Prediction: An initial, limited form of Match Expressions is included as a Preview Feature in Java 13.

Modest growth of Kotlin

The Kotlin language from JetBrains has attracted increasing interest from developers in recent years. In particular in the Android space, there has been an explosion, and a dominance of Kotlin for new projects on Android.

However, no comparable explosion has occurred in server-side Java, the traditional heartland for JVM languages. In 2019, I see continued gradual adoption of Kotlin, but not a flurry of projects / teams moving to it. There will be several high-profile projects that are publicly using Kotlin to build upon.

Prediction: Kotlin will continue to win fans in the core Java community, but will not break through, and will remain smaller than the Scala ecosystem.

Business as usual

The above highlights some of the changes at the bleeding edges of Java. However, in the rest of the Java world (the hinterland of Java) then it will be another year of more of the same. Java's IDEs, libraries and the rest of the ecosystem will basically continue on the same trajectory.

Java's solid position and momentum within the industry will continue to carry it forward without any major upsets.

Prediction: No specific quantifiable prediction.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Java11 and microservices

    by Enric Jaen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'd like to read more on how Java 11 will help develop microservices. Plz can you expand/refer on that?

  • migration from J8 to J11

    by Enric Jaen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There shouldn't be issues migrating to J11. Brian Goetz explains that a goal of Java is to be backward compatible.

  • One more prediction

    by Tam Mom,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    More Scala features will be copied to Java.

  • Re: migration from J8 to J11

    by Ben Evans,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm aware that in theory, it shouldn't be too bad to move. In practice, none of the migrations I've been involved with has been very easy.

  • Re: One more prediction

    by Ben Evans,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It's not really a question of "copied". Java is a mature, stable, heavily backwards compatible language that moves and evolves slowly. This is by design.

    All programming languages take ideas from one another, this is also by design. In Java's case, it also needs to standardize approaches not only at the language level, but also at the VM level.

    That is why, in Scala 2.12, for example, Scala's lambdas are rebased to build upon Java 8's (and use invokedynamic). Or how from 2.12 onwards stateless traits in Scala are just a Java 8 interface with default methods.

    If you prefer to think of it this way - Java is very, very cautious about misfeatures. If you prefer a language that wants to move faster and can tolerate potential design missteps, other languages may be a better fit for you. Other people may see it in a different way.

  • Re: Java11 and microservices

    by Ben Evans,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Building to a modules-first, modules-always design aligns well with microservices, and will help the microservices stay small. Being able to start a much smaller runtime (only include the modules you need) will help with footprint and startup. Java 11 has much better integration with containers. Java 11 has native HTTP/2 support. The version of G1 that is present in 11 is much, much better than the version in 8.

    Just a few quick reasons off the top of my head - for me, it's a no-brainer to start any new project in 11.

  • Re: Java11 and microservices

    by Bill ONeil,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Why would Java 11 specifically help you build microservices or what challenges are you having with versions lower than 11?

  • Re: Java11 and microservices

    by Hung Nguyen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hard question :)

  • Re: Java11 and microservices

    by Ben Evans,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think I covered this one in one of my earlier replies. :)

  • Re: Java11 and microservices

    by Will Hartung,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The bundled isn't awful, though I sort of question why it's there anymore with the removal of the Web Services stack. Being a package, it's technically not even reliable from a portability layer, but that mostly a non-issue. Many shied away from it due to that, but since the bundled Web Service stack required SOMETHING, as long as that remained, odds were good that the HttpServer would remain.

    While it's nice that Java is offering support for HTTP/2, the HttpServer development model (assuming HTTP/2 was crammed in to HttpServer vs something completely different), while usable, is painful enough that once you've done enough work to make it more usable, you're likely better off shopping elsewhere for an HTTP stack than the native Java one.

    It would be nice to be able to rely on and do real work directly with an HTTP stock bundled in the JDK. But the current HttpServer kind of falls through the cracks in this regard.

  • Re: Java11 and microservices

    by Ben Evans,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Will.

    The HTTP/2 stack is completely new as of Java 9 (and standardised in Java 11). It doesn't depend on the legacy stack (which, btw, is actually only HTTP/1.0) and is competitive / better than any existing third-party HTTP/2 libraruy that I'm aware of.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p