Over the years, many had predicted that Java was on the verge of dying and would soon be replaced by other, newer languages. Subsequently, there was a boom in contenders trying to usurp Java and claim the throne. Attempts were made by languages such as Python, Perl, C#, Ruby, etc. but Java weathered the storm and is still thriving today, two decades later.
Unfortunately, Java updates do not get much attention in the developer community. The last time everyone paid attention to it was when Java 8 was released, the delayed success of which made Oracle rethink its approach towards Java. In a fast-paced programming era, Oracle realized that staying relevant was the key to success and longevity. The team made several changes after that to achieve this.
This article discusses the approaches adopted by Oracle and its importance.
Past – What was not working for Java
Traditionally, Java had longer release cycles spanning multiple years. Although the relaxed time frame allowed the features to be well-tested, it came with considerable overhead. With higher expectations, the releases became feature-driven. Moreover, small features were overshadowed by more significant features. If a feature like ‘Lambda’ took two years to ship, small features had to wait for the shipping date even when they were ready within a couple of months. Eventually, they got ignored in the backlog.
Present – What changed over the past few years
Oracle devised key strategies to balance compatibility with consistency in their release cycles.
Change in Release cadence
Until Java 8, the release cycle was roughly three years, but from Java 9 onwards, they were shortened to six months. In just two years, Java moved from version 9 to version 14. This enabled smaller features to be released faster, allowing significant features to be shipped in any release cycle once they were developed. This reduced the release management overhead.
Assessed risk factors
A change in a programming language is permanent. Once it’s shipped, it cannot be rolled back. Unlike an application that can provide a hotfix, a language cannot. Hence, feature support in a language must be well designed and executed. One strategy adopted by Oracle was to release features in a “Preview” mode. This allowed the new features to be tested by a wider community. Any feedback or issues observed during this phase could be fixed before releasing it as permanent feature support. This is the reason why Java 9 and 10 were not Long-Term-Support (LTS). The features provided in these versions were community tested and then put into Java 11 as an LTS.
Future – What to expect
A study done on maven repository has found that almost 80% of applications are still using Java 8 despite being released in 2014. Moreover, the coding practices followed by many Java developers are laid out in the early 2000s. These practices include the way we write ‘switch cases,’ ‘instanceof Operators, ‘ etc. We need a shift in this style. Java developers need to adapt to new changes quickly and provide community support to drive Java towards its next features.
Let’s discuss a few major projects being worked on in OpenJDK. Understanding them will give us a broader picture of where Java is heading, what to expect, and how to keep ourselves updated.
Project Amber
This project concentrates on developer expectations and is driven via JEPs (JDK Enhancement Proposals) and bugs filed in JDK. You can consider JEP like the Java feature backlog. It includes small features targeted towards developer interests and in order to increase productivity. Currently, there are more than 300 JEPs in the discussion. ‘Local-Variable Type Inference (var),’ ‘Pattern Matching,’ and ‘Switch Expressions’ are the most popular JEPs delivered recently.
Ref: http://openjdk.java.net/projects/amber/
Project Valhalla
This is a very ambitious project. Project Valhalla plans to bring radical changes in the Java memory model. Since 2008 Java has been trying to redesign its memory model to accommodate new hardware changes. They have been successful in terms of GC, but progressive changes are still required in terms of how Java stores an object. Ten years ago, a memory fetch and the arithmetic operation had the same cost. Let’s understand this cost model. To define it loosely, modern hardware can perform 4 arithmetic operations per CPU clock cycle, whereas memory fetch requires 300 clock cycles. So, the cost ratio is 1:1000 when there is a ‘cache-miss.’ Java does a lot of boxing and unboxing; these are memory indirections. These indirections lead to high chances of ‘cache-miss’ and hence the performance impact. To overcome such scenarios, Java is introducing new features like ‘Value types,’ ‘Generic Specialization,’ etc.
Ref: http://openjdk.java.net/projects/valhalla/
Project Loom
Creating threads with less overhead, eliminating time taken for context switching are some of the primary objectives of this project. These are currently called ‘Fibers’ (Hence the name Loom). This project is in its nascent stages. With this project, Java will support ‘Virtual threads’ and ‘Structured Concurrency.’
Project Panama
This project concerns the incorporation of ‘Foreign APIs’ into Java. This is not JNI. Panama plans to provide a more JVM friendly approach towards accessing native methods. With this, a native method can be accessed using an annotation. This opens a new window for Java programs. Java can be easily integrated with OpenGL, System libraries, etc. Panama also plans to support call-backs from native methods to Java methods.
Ref: http://openjdk.java.net/projects/panama/
These projects bring a multitude of features to the table, and adapting to them at an early stage will shape the architecture and design for years to come. With such a rapid pace of development, it is our responsibility to stay well-informed about not only the upcoming features but also the ones that are phasing out. So to answer the question ‘IS Java Dead’ is still a tricky one. However, the new strategies adopted by Oracle might prove to be a boon for one of the most loved languages of the computer world.
Author
Nikhil Ronghe | Lead Software Engineer
Nikhil Ronghe is a Lead Software Engineer at GS Lab and has over 7 years of experience on backend development. Apart from experience on J2EE technologies he has worked on developing applications across Adobe Experience Manager, Android, and Web technologies. He has a keen interest in cloud and application security space.
