11 Sep 2013 JavaOne Shanghai

This year July 24-27 I was invited to speak at the first JavaOne conference held in Shanghai, China. Over the four days the conference delivered a concentrated dose of Java and helped me get a good overview of the current state of Java across all versions. It also showed that the divide between where Oracle thinks Java is going and the reality as I see it day-to-day is getting bigger, with Oracle selling the image of a bright future for Java where I see Java slowly loosing ground against other programming languages.

In the last couple of years JavaOne has branched out from it’s base in San Francisco to feature satellite conferences all over the world, the closest to Shine’s home Australia being Shanghai. There were actually three conferences rolled into one: JavaOne, Oracle OpenWorld and Oracle Partner Network Exchange. I assume this was done to create a single big event, and the numbers Oracle presented sounded big: all conferences combined boasted over 350 session, 54 sessions of these were for the JavaOne. A total of 18,000 participants supposedly signed up for all three conferences. There may have been that many sign-ups, but I certainly didn’t see 18,000 people at the venue. From my judgement there were closer to 4,000 participants at all three conferences, with about 1,000 of those attending the JavaOne.

Most of the presentations were done by Oracle employees with just a few presentations -like the one I did – from people outside of Oracle. This meant that Oracle was able to repeat their message about the great future of Java over and over again. To Oracle Java is alive and well with 9 million Java developers and 200 Java User Groups worldwide, and has a great future ahead. As a long-time Java developer my view is a little different, with Java having lost some of it’s appeal because of slow adaptation of new technologies.

Java EE 7

There were several presentations on Java EE 7, and being an enterprise developer this topic was most interesting to me. This version 7 of Java EE was finalised only in June 2013, and is the first version released under the stewardship of Oracle. The three pillars Oracle wants to address with Java EE 7 are HTML 5, developer productivity, and meeting enterprise demands.

HTML 5

Oracle is trying not to miss the boat on the HTML5, JavaScript, and single-page app trend and beefs up support for these technologies in Java EE 7. There are several enhancements to existing APIs and some new APIs to cater for this.

Websocket API

New is the WebSocket API to support low latency, bi-directional client-server data exchange over a single TCP connection. The API defines both an annotation-driven and an interface-driven approach for endpoints, their lifecycle events, and the message passing. As an example for a websocket application Oracle demonstrated a simple chat client with 15 lines of code.

Even though websockets only cater for special applications such as chat clients I think it is very important to show that Java is a sensible platform for this. Standardisation in the Java EE specification gives such a signal, but as always the specification lags far behind the emergence and distribution of new technologies. The open-source community is much quicker to react to new trends, and Shine was previously able to build a powerful and robust chat application on the basis of the open-source Atmosphere framework with great success.

JAX-RS 2.0

The new version 2.0 of JAX-RS has a few enhancements over the 1.1 predecessor. For one it adds a client API to build web service clients to communicate with REST web services. To me this doesn’t sound like a great addition considering that the more likely clients for REST services are HTML5 rather than Java applications.

Aside from the client API the RESTful server API is extended via aspects to allow development of cross-cutting concerns. The implementation is done using interceptors and filters. They can be completely configured using annotations, which makes the easier to use than old-fashioned filters configured in the web.xml.

JSR 303 Bean Validation can now be applied to any PoJo, including JAX-RS PoJos. This allows programming by contract, as the validation framework enforces a contract of valid parameters. This validation of REST parameters via annotations is quite powerful, and is already available outside of JavaEE 7 when using Spring MVC to build REST services. 

JSON API

Completely new is an API to standardise working with JSON. JSON is the de-facto standard for data exchange on the web, and supporting this format is crucial. Unfortunately the specification only covers the streaming API and an object model API, while JSON binding has not been addressed yet. In reality it is the binding that is most beneficial to enterprise developers, while the streaming- and object-model API are more interesting to framework developers. Being the data exchange format of choice in the web now this lack of JSON binding support leaves Java developers to use non-standardised frameworks such as Jackson or Eclipselink for full JSON support.

This version of Java EE again is trailing far behind the definition of these important standards in a timely manner similar to the way it missed defining object-relational mapping or dependency injection in time before.

Developer Productivity

The next topic that was supposed to be addressed by Java EE 7 is developer productivity. I am not sure if I would call developer productivity a pillar of JEE 7, because really there was not much to talk about in terms of productivity improvements. Rather than a pillar it seemed more like an evolutionary step with more annotations being utilised to reduce the need for boilerplate code, and more default options being available for less configuration of common use cases.

Meeting Enterprise Demands

To meet the demands of enterprises there are two additions to Java EE 7: JMS version 2.0 and Java Batch processing.

JMS 2.0

The new version 2.0 of JMS is a major overhaul of the JMS API, which has seen it’s last version come out over 10 years ago. The new API uses the autocloseable features introduced in Java 7, fluent interfaces, and more runtime exceptions to streamline JMS development. In the example code shown by Oracle 25 lines of JMS 1.1 code are reduced to 5 lines of code in JMS 2.0. This overhaul addresses the criticism of Java to be too verbose with too much boilerplate code.

Batch Processing

The new batch processing API for Java comes as quite a surprise to me. Batch processing has been around since the 1950s and is still widely used in corporations to process large amounts of data offline. Unfortunately none of this is currently done in Java, since other languages have much better support for these tasks. The introduction of batch processing to Java at this point seems like it is coming about 15 years too late, it should have been something introduced with the first versions of J2EE.

The architecture of batch jobs consists of individual steps, with each step in turn consisting of an item reader, and item processor, and an item writer. The container offers managed transactions and automatic checkpointing, the latter to be able to restart long-running jobs at any point should they have stopped unexpectedly. There is also a step type called batchlet that allows freestyle processing outside the read-, process-, write- schema.

The runtime environment for such batch tasks is a JEE 7 application server, and Glassfish is the reference implementation for the batch processing API. Interestingly the jobs are defined in an XML file, which gives the whole batch processing an air of yesteryear, but considering that batch processing had it’s heyday 50 years ago XML may actually seem new to those who work in that area.

The Three Pillars

To me the three pillars of JEE 7 taken together really don’t amount to much new stuff, an enhanced API here, a new API there, but nothing really major. Java EE is still playing catch-up to incorporate technologies already well established in other programming languages like JSON or web sockets. It shows that the JSR process is too slow to react to new trends in programming similar to the way the W3C standardisation of HTML 5 lags far behind its actual use. It seems like the standardisation processes currently in place for web technologies are too sluggish to keep up with the demands for new programming paradigms.

Java SE Embedded

There was a lot of talk from Oracle this year about Java SE Embedded. It seems like Oracle desperately wants a piece of the Internet of Things. The idea behind the Internet of Things is that physical objects are getting equipped with Internet capabilities so that they can be tracked and controlled via the Internet. Examples are light switches, temperature sensors, cars, heart monitors or stop lights. Oracle sees Java as the programming languages of choice for these devices, and to jumpstart this there were several sessions showing how to program the popular Raspberry PI using Java SE Embedded and Java FX.

This vision of ubiquitous Java on small devices has been around before, when Sun advocated Java services on small devices such as coffee machines and toasters that all communicate with each other around 1998. The vision never panned out, mainly because nobody understood why a coffee machine would communicate with a toaster. Java eventually found its home on large enterprise servers and coffee machines and toasters stayed disconnected for another 15 years.

I believe the new vision with Java at the centre of the Internet of Things is unlikely to pan out this time as well, this time because Java has to lost its appeal as a programming language. Devices of the Internet of Things can be programmed in any language, and newer platforms like Node.js, Python, or Go will have an edge over more established ones like Java or C#. Young developers exploring horizons like the Internet of Things don’t want to be bogged down by the historical baggage of established programming languages and the slow pace at which they evolve.

Adopt a JSR

During the conference Oracle underlined their commitment for user group involvement in shaping the Java language through the Adopt-A-JSR program. This program is aimed at Java User Groups across the world, and allows them to adopt a JSR (Java Specification Request) of their choice. Depending on their level of engagement they do things like test early reference implementation builds, file bugs, help build the reference implementation, all the way up to actively participate in the expert group.

Oracle seems to have recognised that involvement of the people using the language is crucial to the survival of Java, and tries to engage the community through this program as well as the establishment of satellite JavaOne conferences like this one in Shanghai. They want to emphasise that the community is the backbone of Java, something they neglected to show in the beginnings when the acquired Sun and Java.

Continuous Delivery

The main reason for traveling to Shanghai was that I was invited to do a presentation myself. My presentation was a case study of implementing Continuous Delivery at a major Australian retailer. Continuous Delivery strives to automate the software delivery process with the goal of rapid, reliable, low risk deployments with a push of a button. In this project we were able to set up such an automated push-button process to release into production any time with zero outage to the end user, and I wanted to share our experience.

I neither expected much turn-out nor did I expect much prior knowledge from the audience, and I was wrong with both. The room ended up nearly filled with about 200 people, and most seemed to have some prior experience with Continuous Delivery. The presentation went well and ended in a lively question-answer session that showed the great interest people had in the topic.

Conclusion

The JavaOne conference showed that Oracle continues to invest in the language, and that they are trying to keep in touch with new developments like the Internet of Things. The danger for Oracle I think is not to be taken seriously if they continue to act like everything is great while the reality for Java is more dire. Especially the standardisation process needs an overhaul for Java to be quicker to react to new trends for standards to remain relevant in the Java language.