Happy New Year everyone!
For the last two years, I’ve started with a blog post (2017 link, 2018 link) giving my predictions for what will happen in the world of Java in the next twelve months. I saw no reason not to start this year in the same way.
Overall, from a technical perspective, I expect this year to be pretty quiet, as I’ll explain in each of the following sections. However, from a non-technical perspective, I think developers and users will need to make some choices about how they deploy Java applications.
As usual, I’ll break this up into the relevant technical sections and also review how accurate my predictions from last year were (or not, as the case may be).
Embedded Java
Technically, I don’t see much changing in this area. Oracle has completely dropped any development in this area and no longer supply binaries targeted at embedded applications using the very popular Arm architectures.
However, I will predict that the use of Java in embedded applications will grow this year. There are three reasons for this:
- Other companies are still providing JDK binaries for embedded applications. Obviously, we here at Azul are a big part of this and can provide Java for Arm processors (and therefore you can continue to run Java on the wonderful Raspberry Pi) as well as for PowerPC and MIPS. Let us know if you are interested in more details on these. Currently, this is JDK 8, but we will be releasing JDK 11 versions shortly.
- The realities of Moore’s law means that the memory requirements of a JVM (needing several Mb of RAM) are no longer a consideration in terms of additional cost.
- The Java Platform Module System provides a way to build custom Java runtimes for an application that only contain the modules required by the application, not all of the core class libraries (for more detail on this read my earlier blog post on the jlink command). This can easily reduce the space requirements of Java from hundreds of Mb to tens of Mb. This eliminates one of the major concerns for using Java SE in these environments.
Java ME
I think it’s safe to say that Java ME is the Norwegian Blue of Java technology. Although last year there was still some effort to keep things moving under the JCP, via the Java ME working group, this essentially ended in March. V2COM seem to be the only company still interested in pursuing this further, and I believe they are now working with the Eclipse Foundation on this.
My prediction for this year is that there will be no further development of Java ME or any real development of applications that use it. I doubt I will even include it in my predictions for 2020.
Java EE (now Jakarta EE)
2018 was a year of consolidation for Enterprise Java with the continued move of all the necessary IP, code and tests from Oracle to the Eclipse Foundation.
The Eclipse Foundation is now working through the details of how to create a standards process as a replacement for that of the JCP, which has been used up until now. As such, I would not expect to see any significant developments in this space. One possible exception to this is in the area of microservices and the Microprofile. Given the popularity of this architectural approach, I would expect to see further advances in this area for Java.
Java SE (Core Java)
I predicted at the start of last year that we would have two major releases of Java in 2018. Given the new release cadence for the OpenJDK project, I hardly needed a crystal ball to predict that! What is very good to see is that this new process is working perfectly. Both Java SE 10 and 11 were released on schedule, and the necessary JSRs were created, reviewed and approved at the same time. In line with this, the JCP has now finished the revision of the JSR process (through JSR 387) to make this simpler.
For this year, I will go out on a limb and predict that we will have two more major releases, JDK 12 and JDK 13. Again, this does not really put me on the same level as Nostradamus. JDK 12 is already in the ramp down phase, and I have been invited to join the Java SE 13 Expert Group along with the other usual suspects.
From a technical perspective, I think that both these releases will be evolutionary, rather than revolutionary. JDK 12 has a shiny new preview language feature in the form of switch expressions. Raw string literals had been planned for JDK 12 but has been withdrawn due to the need for further discussion on the best way to implement this feature. This again shows that the new release process works well. Rather than including a feature that wasn’t quite ready, the decision is made to delay it to a later release. My prediction is that this still will not be ready for JDK 13. Most of the changes I can see coming in JDK 13 will be more groundwork for the more prominent features that are being planned like Valhalla and Loom.
The Java Community Process (JCP)
I think this year will be a year of decision for the JCP. I attend most of the JCP Executive Committee (EC) meetings representing Azul, so I think I have a good perspective on this. Now that Java ME is no more and Enterprise Java has moved to the Eclipse Foundation Java SE is the only significant part left for the JCP. There are a couple of other JSRs in progress, but these are not significant in terms of the Java platform as a whole. Also, with Java SE, much of the work that used to be handled by the Expert Group has moved to the broader OpenJDK community in the form of JDK Enhancement Proposals (JEPs).
Ultimately, this does not leave much for the JCP to do. The EC has already reduced the number of face-to-face meetings this year from three to two. I could definitely see this becoming a single meeting before JavaOne (or Oracle Code One or whatever it is called this year).
The JCP is still vitally important to Java SE, as it provides formal specifications for the core Java platform, the TCK so that people can verify binary conformance to the specification and (most importantly) the grant of intellectual property rights to those people (like Azul) providing alternative binary distributions.
I suspect we may see more changes to the JCP in terms of the number of companies directly involved.
JDK Binaries
Moving away from the technical aspects of Java, how it is distributed and (more importantly) updated is the big thing that is changing this year. Later this month we will have the last public update to both JDK 8 and JDK 11. Although JDK 11 is a long-term support (LTS) release, this only applies if you are using the Oracle JDK, which is now released under a different license. This states that you can still freely use the Oracle JDK for development and testing but not in production. If you want a free for use in production binary from Oracle, you will need to use the Oracle OpenJDK binary (from jdk.java.net). None of these releases provide any form of long-term support.
My prediction is that, by the end of the year, most Java users will have moved away from the Oracle JDK. Several organisations (including, obviously, Azul) are now providing builds of OpenJDK with varying forms of support and backported fixes from the current release.
If you’re not already looking hard at which version of Java you will be using this year you should make that your new years resolution. From next month, if security patches are important to you (and they really should be), you will need to decide how you get these.
Conclusions
Overall then, my prediction is for a quiet year in 2019 for technical changes to Java but a very significant one for which versions of the JDK people are using.
Are you ready for the changes to Java in 2019?
