Is Java in Jeopardy?

I wrote an article back in January of this year about Java called Does Java Has a Future? Yes, it Does, and I was so confident in this assumption that I even wrote the answer in the article’s title. It is disappointing for me to write something like this because I may have to change my stance on the matter. I still love Java. It has been (and still is) my favorite programming language since the day I started learning code in 1999. And, there was no looking back since then — I grew up along with it.

Java is still the most widely used enterprise programming language. But, how long will that be? There’s a lot of advances, development, and changes in popularity from Javascript frameworks and other Java alternatives. And, like adding fuel to the fire, the recent developments around Java are not helping. Some of the key developments include:

• Oracle to start charging the usage of Java
• Java EE and related projects are open-sourced and now to be managed by Eclipse Foundation

There is nothing wrong with both of the above features. It benefits Oracle’s business, and it frees up Java EE to open source and helps Java in the long-term.

So far, so good. But, the problem comes with ambiguities and lots of moving pieces. Both Oracle and the Eclipse Foundation should communicate better to the developer world and consumers of the Java platform on the changes.

Frankly, both developers and companies cannot wait forever to learn what the future looks like. If you are into any software development projects, a lot of planning, design, and architecture happens before a single line of code is written. If we also add all the software products that are written in Java, this becomes big and unmanageable.

Below, we will take a look at some of the major aspects of the future of Java.

Terminology, Projects, Charter, and Naming Conventions

Oracle chose the Eclipse Foundation to manage Java EE projects. Eclipse created these:

• The Eclipse Enterprise for Java (EE4J) ProjectTop Level Project Charter
• Eclipse Jakarta EE Platform The Eclipse Jakarta EE Platform project produces the Jakarta EE platform specification, which is an umbrella specification that aggregates all other Jakarta EE specifications.
• Jakarta EE working group, which manages these projects.
• But, Jakarta EE is the also new home of Cloud Native Java

What JDK Should you Use to Run EE4J Projects? Oracle JDK or Open JDK?

Eclipse Foundation projects are based on Java 8 EE, while Oracle will stop updates for Oracle JDK 8 in January 2019

• Basically, the Java EE platform is built on top of the Java SE platform. To run a Java EE-based application/program, you will need a JDK on your system. You will have two choices: use Oracle JDK or OpenJDK. While the entire Eclipse EE4J projects are based on the Java EE standards and use Java EE 8 as the baseline for creating new standards, it does not address which underlying JDK version will be used. Oracle JDK? Or, OpenJDK? 
• What JDK version will the Eclipse foundation use moving forward?
• Releases and version numbering for EE4J projects have not been announced yet.

Oracle Did not Donate API Documentation for Java EE

• While Oracle donated the Java EE projects to the Eclipse foundation, it did not donate the Official API documentation. This is still under discussion and is an uphill task for everyone in the Eclipse Foundation community to start writing from scratch. So, for some time, all of us will still be using: https://javaee.github.io/javaee-spec/javadocs/index.html.

Oracle to Start Charging for Java Usage in 2019

The Java price list can be found here.

• It’ll be about $25/core/month
• What about SaaS applications? Who will pay, how will be they charged?
• What about hosting providers? Let me add more complexity here. You are hosting a software product/solution for your customers and charge them for your software license, which runs on Java. Now, do I want to add Oracle’s Java charge to my customer? Or, will I pay? Should I rewrite contracts? Is this even feasible?
• All the hype and development happening around containers and scaling applications. How will this work? We pay for only one hypervisor. Can we have n-number of containers all running on Java?
• Companies have thousands of workstations (desktops, laptops, etc.) for their employees. Is Oracle expecting to charge every workstation that every company has? Are companies ready to pay?

Oracle’s Aggressive Java Release Cycles: a new Version Every Six Months

• This can be a good thing. Instead of waiting for new features and capabilities, users can get them a lot sooner.
• This also brings up many complexities. It is a very daunting task to upgrade the version of a core platform unless there is a strong reason. Large applications cannot just switch without a lot of testing. And, doing this every six months is next to impossible.
• Along with that, there will be a lot of work for hosting and SaaS-based providers to keep up with the versions and release cycles.
• Oracle has a new release process for it’s Java JDK. While we may see a release every six months, it’s not that easy for large applications to flip a JDK version just like that. Lots of testing needs to happen. And, imagine a large banking application that had to be upgraded. Who has the time and money to do this every six months? And, if we choose not to upgrade the version in 1–2 years, the version you are using could be DEPRECATED and/or not supported. Now, companies are forced to upgrade or have your code portable to that version.

So Much to Do

• As reported by one of the core members of the project, there will be 39 projects under the EE4J Project. 29 of them are created and are in different states. Approximately, there will be 110 repositories with more than half already transferred.

The Devil: “Update Your Java”

• If you are a Java developer, you know why I said “devil.” As developers, we tend to be very careful in upgrading our JDK version in our system. The build process used y tools, like Maven, IDE’s (IntelliJ, Eclipse), and used the underlying JDK/JRE versions configured in our systems. Of course, we can make changes in our IDE’s, but the default is crucial. Now, with all the above, developers need to be very cautious in using the right version to build their applications
• Enterprise-wide Java version — this is another big thing. Enterprises are also very careful of what JDK version their applications support and what their developers should use to build. And, the more versions released the more problems and confusions.

Alternatives

Having said this, Oracle and Java left us with one open-source option, OpenJDK. But, this solves only half of the problem. Developers and companies still need to embrace JakartaEE, JDK, and OpenJDK versions.

I really wish Oracle, the Eclipse Foundation, and sponsors could resolve these issues soon and provide clarity to developers and businesses.