In terms of actual news, this year’s JavaOne conference had not very much to offer. It was a party – celebrating 20 years of Java, and at the same time a confirmation of the strength of the Java platform.
Java is reconfirmed as the #1 programming language (both TIOBE index and PYPL index say so) and the evolution of the platform is demonstrated. Java is not the coolest kid on the block – following every trend, leading the hype cycles and offering the latest and greatest and bleedingest edge. Java is solid and evolutionary and enterprise level. While some in the community showed disappointment for this perceived lack of vigor and daring, the majority of attendees seem to appreciate that this steady evolution of Java means that they can carry their skills forward for quite some time to come.
When you think about it, it is quite a feat that companies such as IBM, RedHat and Oracle – for all their own reasons – drive forward the Java platform (programming language, JVM, Enterprise Edition, Embedded) and the community around it. The result of their labors is that I can continue to benefit from Java – even when the world of IT has changed dramatically since Java first came out. As long as I evolve along with Java, I get to benefit from multicore chip architectures, WebSockets and HTTP/2, from REST & JSON, from functional programming paradigms and real time embedded processing and many other recent and upcoming trends and developments. Apparently, what is good for Java is good for IBM and Oracle and also not too bad for me.
The yearly appeal from Oracle – and before that from Sun Microsystems – to the community to join in and help further Java struck home with me for perhaps the first time. Oracle – and the other major parties involved – have a limited number of resources. They are not all knowing either. Opinions, experiences, suggestions and contributions to specification designs really can make a difference. With all the flaws in the process and the political machinations around it, the evolution of the biggest programming language on the planet is still pretty much done in the open – and it is quite easy to be a part of that. Having influence is not that hard; with only a limited number of voices joining in the discussion, I – and you as well – and join in easily and be heard. Complaining about the perceived lack of progress of aspects of Java is not your only option – you can be a part of it. It is not some sort of hallowed forum that thinks about the next steps – well, maybe it is, but that is not all there is. I feel now, more than ever, that I can make contribution.
Modularity is first of all about the Java runtime. Its aim: making it possible to pick only the pieces of the JRE your application need. So for example a tiny JRE can be embedded with an application. Part of [the complexity of this] modularity is the legacy the Java platform is carrying around. The platform is 20 years and has always had backwards compatibility. Even to technologies that are now really outdated or ideas that seemed like good ones a long time ago. An overhaul of the Java platform is not easy, because of the size, the complexity and the fact that compatibility has to be respected – at least to some point
Modularity was originally planned for Java SE 7 but could not be completed in time and nor could it for Java SE 8. It simply was too hard. During this more than 5 year period, a lot working has been done in terms of cleaning up the core libraries and figuring out a way to get the modularity covered. With Java SE 9 now around the corner, the dust has settled and project JigSaw is close to delivering on the promises – including right sized JRE and the end of Classpath-hell.
The concept of a module is introduced into Java. Modules explicitly describe what they offer (their public API), and what they need (dependencies), hence dependencies can be verified and resolved automatically during all phases of development. For those of you familiar with SCA (Service Component Architecture): a module seems very similar to a service component.
Modules bundle together one or more packages and offer stronger encapsulation than jars. Each module specifies dependencies on other [higher level] modules. By default, all classes/types inside a module are hidden to the outside world. Each module exposes specific packages for external consumption. The module system also includes a services layer that can bind service providers and consumers through interfaces. Think of it as inversion of control where the module system fulfills the role of service registry.
Modularity will affect custom applications created on the Java platform, and the way that they are built and delivered. It will also have a large impact on the Java platform itself.
The Java SE 9 Platform Specification will divide the platform into a set of modules. An implementation of the Java SE 9 Platform can contain all of the platform modules or, possibly, just some of them. The only module known specifically to the module system is the base module, which is named java.base. The base module defines and exports all of the platform’s core packages, including the module system itself. The base module is always present. Every other module depends implicitly upon the base module, while the base module depends upon no other modules. The remaining platform modules will share the “java.” name prefix and are likely to include, e.g., java.sql for database connectivity, java.xml for XML processing, and java.logging for logging.
Some other new features in Java SE 9 and JDK 9 that got some air time are:
• HTTP/2 and WebSocket support (JEP 110)
• Light Weight JSON API (JEP 198)
• Money and Currency API (JSR 354)
• Common Logging System for all JVM components (JEP 158)
• Improved Lock Contention mechanism (JEP 143)
• Segmented Code Cache (JEP 197)
• Datagram Transport Layer Security (DTLS) (JEP 219)
• Stack-Walking API (JEP 259)
• JShell – the interactive Java language shell (project Kulla)
– HTML 5 (JEP 224)
– Simplified Doclet API (for plugins into JavaDoc generator)
– JavaDoc Search
• Finalize Project Coin (JSR 334, JEP 213)
• Private interface methods
Note that Java SE 9 is feature complete in December 2015. General availability is scheduled for September 2016, right before next year’s JavaOne conference. OpenJDK builds for release 9 are available for download and experimentation: http://openjdk.java.net/projects/jdk9/. The roadmap is shown below.
Two special projects were highlighted during the JavaOne opening keynote session – Valhalla and Panama. Both demonstrate the ongoing evolution of the Java platform. Both are long term projects on which various large Java stakeholders collaborate, to ensure the continued relevance of Java. They are for the greater good – if maybe not at the shiny frontier of latest application development.
Project Valhalla reassess Java – at a rather fundamental level – in light of modern hardware: When Java was first designed – CPU architectures were very different from today. The numbers of cores and threads were far smaller and for example in the mid ‘90s, a memory fetch was about as expensive as a calculation operation. Today, memory fetches can be more than a 100 times as expensive. Project Valhalla looks to improve the JVM to leverage current hardware.
In this particular example, a special type of Class is considered called value class – code like an object (but no inheritance), perform like a primitive. Memory fetches are frequently done in Java when objects are retrieved. When an object is really nothing but a value holder, having to treat it like an object with a pointer to a memory address for accessing it becomes quite expensive. With value types, most of this overhead goes away. Other features under consideration are Reified Generics (retaining their actual type at runtime), Generic Specialization (List<int> would be valid & highly efficient) and ‘volatile’ enhancements.
Project Panama (http://openjdk.java.net/projects/panama/) deals with the Foreign Function Interface that allows external, non-Java libraries (such as DLLs on the Windows platform) to be integrated into Java programs. Today, such integration is supported – but it is hard and painful. Project Panama will make such interaction much smoother and efficient.
Java EE 7 was released back in 2013. Only this year did Oracle WebLogic achieve full Java EE 7 compliance with the 12.2.1 release. At the same, the first few EE 7 APIs were implemented in WebLogic quite some time ago. Here is a trend that will continue with Java EE 8 – and not just with Oracle WebLogic: Java EE application servers will take on some new APIs when these become available – and not wait for the full Java EE 8 release (Spring 2017). Full Java EE 8 compatibility can take considerable time though.
The Java EE 7 platform is fully supported at this point by IBM WebSphere, TmaxSoft JEUS, RedHat WildFly, Cosminexus Hitachi Application Server and Oracle’s Glassfish and WebLogic Server.
Java EE 8 seemed to have cloud as a major theme – the way it was presented a couple of years back. And especially standardization of cloud platform management APIs. That theme seems no longer to apply. Another theme was ‘Project Avatar’ and special support for HTML5 and rich client web development. That too seems to have vanished. At this point, there is no real core theme with Java EE 8. There is evolution in most APIs – for example around new adjacent technologies such as HTTP/2 and Java SE – and there are some new entirely APIs (Model-View Controller, Java EE Security). And there is one API that just missed the boat for Java EE 7 (JCache).
The latest release of GlassFish 4 – the reference implementation of Java EE 7 – was published in October 2015. Updates to the Java EE 7 specifications for JAX-RS, JMS, CDI and WebSocket were absorbed in this release. Most components were updated in some way – primariuy with fixes and security updates.
The reference implementation for Java EE 8 will be GlassFish 5. Early builds can be downloaded and tried out from http://download.oracle.com/glassfish/5.0. Java EE 8 – and GlassFish 5 – is slated for Spring 2017.
Java ME Embedded
The really large numbers with Java arise when talking about the number of devices that run Java. Most of them – billions actually – are pretty small devices that run the small edition of the Java platform, called Java ME Embedded. These devices are nowadays typically equated to the things in the Internet of Things. That is one of the key themes from Oracle with Java ME Embedded: it helps power the intelligent edge of the internet of things.
Devices range from very small to quite big. They measure and sense and collect data to be reported to higher up. And the smarter they are, the more preprocessing – like filtering and aggregation – they can do, preventing the chain from being needlessly overwhelmed. They also display and actuate, based on signals received down the command chain (that is – from right to left in the overhead illustration). The smaller the device, the smaller the Java runtime available for creating local smartness. And that is where Java ME Embedded comes in: a small footprint, yet a proper (in step with Java SE) Java platform.
And with upcoming releases, Java ME Embedded Platform will grow even closer to the modular Java SE 9 platform. The roadmap for Java ME Embedded looks as follows:
The rapid evolution is obvious, as well as some of the themes: software provisioning, memory usage, security, specialized platform support and IoT. A number of Oracle specific elements are part of this roadmap – Developer Cloud Service, IoT Cloud Service.