Moving the Java Platform Forward

Mark Reinhold, Roberto Chinnici and Greg Bollella in the General Technical Session at JavaOne 2010

By Janice J. Heiss

The JavaOne 2010 General Technical Session, held Tuesday afternoon, left little doubt that the Java platform is alive, kicking, and heading into new territory with plenty of energy and brain power.

Mark Reinhold, Chief Architect, Java Platform Group at Oracle, led with a talk, “Java SE: The Road Ahead,” in which he began by reviewing the history of the platform and how, initially, releases with even numbers represented revolutionary change while odd numbered releases were more minor. This tradition was broken with Java 1.4 which had smaller changes; and Java SE 5, which manifested major transformations.

Reinhold observed that his team initially had plans to ship Java SE 7 from Sun in 2010. “And then the Sun set,” he quipped. “The question for now is: ‘We are under Oracle, we are under new management, we have new focus, we even have some new engineers. What do we do? I’ll answer this question by the end of my segment.”

So he spoke about Java SE 7, 8, and even, potentially, 9 exploring several themes.

Productivity. Java is a fairly productive language, but there are ways to help developers get more done with less code.

Performance. We have competitive performance from all the major VMs now, but the growth of multi-core processors presents a challenge.

Universality. The Java VM is not just for Java anymore with so many languages that Java should support.

Modularity. The platform is big and applications are constructed with little class paths full of jar files that are difficult to diagnose, debug and construct. This needs to be fixed.

Integration. Java from the beginning tended not to relate well to the particular platforms on which it is found.

Serviceability. Companies routinely deploy thousands of VMs across thousands of machines and need better ways to diagnose problems in running systems that were not necessarily configured at startup time to be diagnosed in any special way.

Reinhold said that these themes were not mutually exclusive and that some of the features he would discuss applied to more than one of these categories.

Reinhold quickly got under the hood and showed ways to improve code derived from Project Coin, led by Oracle’s Joe Darcy, which has the goal of determining which set of small language changes should be added to JDK 7.

He described a Project Coin proposal that addressed the problem of generics creating un-needed verbosity in hashmaps – something that could be reduced by introducing empty type parameters that better inform the compiler about how to proceed.

Clock rates have kept getting faster but have topped out in speed, something that does not contradict Moore’s Laws, which is about transistor power and not clock rates, Reinhold observed. Clocks are getting faster, processors are getting more numerous. The answer from the hardware architects has been multi-core – having more than one core on a chip. But data can saturate one core and leave the rest burning heat. How to grapple with this?

The goal of Project Lambda is to formulate a proposal to add first-class functions, function types, and lambda expressions (informally, "closures") to Java, and to implement a prototype so as to enable broad experimentation. Project Lambda (http://openjdk.java.net/projects/lambda/) is led by Oracle's Alex Buckley and Brian Goetz.

Reinhold described a Lambda language feature that allows developers to add default methods to existing interfaces. “You can declare default methods into an interface. What comes before the default token looks like an ordinary method declaration; what comes after the default token is the name of a static method somewhere else. That static method will be invoked if you invoke the original method on an object implementing this interface and that objects class or superclass does not provide a filter method.”

Founding Principles of Java Design

Reinhold insisted that whatever direction the Java Platform may take, it must conform to certain principles.

Reading is more important than writing. You might need to be reading the code you are writing today three years from now and you would need to understand it. Or a colleague might need to understand it.

Simplicity matters. Things need to be comprehensible with a clear semantic model.

Java should try to be one language with the same meaning everywhere.

“As we evolve the language, we will do it cautiously with a long-term view,” he said. “We will add new features periodically. You will see more new features in the next few years than you have seen in the last few.”

Down the Road -- Adding Reification to the Language and the VM

Reinhold addressed a residual problem from generics and erasure, which entered the platform in Java SE 5: “We did generics with erasure for good reasons. But there are lots of corner cases and not so corner cases where it is painful.” He suggested that at some point, after Java SE 8, reification could be added to the language and the virtual machine, requiring deep VM changes. He explained that reification means the VM will have a representation at runtime of the generic type information that you see at compile time -- it will no longer be thrown away by the compiler.

What else might be done with the language over time? He explained that the fundamental differentiation in Java between primitive and reference types was important at the beginning for performance on available architectures but today it is not necessary. “Today,” said Reinhold, “there are well-known techniques for implementing languages with a unified set of primitive reference types. We ought to do that at some point.”

He suggested that POJOs should be easier to write and suggested that they needed to add features that make it easier to write code that can be seen and analyzed by the compiler or other static analysis tools.

With other languages able to run well on top of the VM such as Ruby and Python, there is a need to support the platform as well as the language. Ideas for supporting other languages are being explored in the Da Vinci Machine Project led by John Rose of Oracle. The particular one on the slate for Java 7 is the invokedynamic bytecode. This is brand new bytecode that is useless to Java programs but incredibly useful to the implementation of dynamic languages that allows developers to engage in very efficient dynamic method dispatch.

Reinhold spoke of his desire to write in Java source code the needed libraries and have the module system find and establish the libraries. “This is what we are doing in Project Jigsaw – introducing a new kind of file module,” he explained. The goal of the Project is to design and implement a simple, low-level module system focused narrowly upon the goal of modularizing the JDK, and to apply that system to the JDK itself.

He went on to discuss the desire to eliminate classpath, about new deployments of the Maven tool, and other matters.

Serviceability is an issue of JVM convergence that Oracle is addressing. “Oracle purchased Sun and has JRockit, a high performance VM; Sun has HotSpot, another high performance VM,” explained Reinhold. “They are written in different styles with different founding assumptions. They each have their strengths. HotSpot works well for both client and server applications. JRockit is highly tuned for enterprise applications stacks. Our plan for JVM convergence is to merge the two. So which code base do we go to? The answer came down to the fact that in the combined VM team we have more engineers who understand the HotSpot code base, so that is the code base we are going to go with. Performance and serviceability features from JRockit will be ported over to HotSpot over time.”

Shipping Java SE 7

So where is Java SE 7 headed? Reinhold described the cold hard analysis his team performed after integrating Sun and Oracle. The earliest they could ship Java SE 7 was in mid 2012. But a lot is already finished. Project Coin and invokedynamic are almost finished. A lot of little stuff is finished. But a lot, like Jigsaw and Lambda is not finished. So the decision was made to ship what can be shipped in mid 2011 as Java SE 7, and ship Java SE 8 in mid 2012.

“It’s a good, focused plan that will get the platform moving again, and that’s good news,” said Reinhold. “The clear intent is to have releases on a regular cadence every 8 to 24 months, possibly 36 months at the outside. A platform like Java, to stay alive, needs to keep moving. We are going to keep it moving.”

Roberto Chinnici – Java EE 6 Developments

Java EE Platform lead, Roberto Chinnici, took the stage and gave a summary of developments in Java EE 6, which includes much that is new. The Java EE 6 release of December, 2009, included:

Several new APIs:

Web Profile

Pluggability/extensibility

Dependency injection

Lots of improvements to existing APIs

Specifically, new and updated components include:

EJB 3.1

JPA 2.0

Servlet 3.0

JSF 2.0

JAX-RS 1.1

Connectors 1.6

Bean Validation 1.0

DI 1.0

CDI 1.0

Managed Beans 1.0

JAX-WS 2.2

JSR-109 1.3

JSP 2.2

EL 2.2

JSR-250 1.1

JASPIC 1.1

JACC 1.5

“Now is a good time to get started with Java EE 6, which is much bigger than any single product or company,” said Chinnici. “There are many vendors working on products implementing Java EE 6. This is the perfect time to get started; we are seeing faster adoption of Java EE than in prior releases. We have several APIs, and we defined a web profile for web application development. We also defined some powerful extensibility APIs that will make it simpler to adopt third-party libraries and frameworks and integrate them into your applications without having to do manual configuration. We standardized dependency injection. In general, we made improvements to existing APIs and made them work together much better than before.”

The Web Tier

A focus for Java EE 6 is the Web tier. Chinnici explained that servlets can now have annotations. Libraries can be discovered and self register with a container.

Defining the Java EE 6 Programming Model

All the APIs in the model have a two-layer pattern with a declarative layer with annotations which does most of the work and a programmatic layer that offers more advanced functionality. Annotations are additive – developers can pile them on a class and each one will specify a particular aspect and invoke some resources from the container which trigger some behavior. But they will not clash. More services can be added with more annotations.

This makes it possible to evolve code gradually and go from a plain Java class to an EJB to one with more services progressively without breaking any code or having to redo your application from scratch. It is a very smooth way to evolve your code as you need more services.

Dependency Injection

He described dependency injection as a type-safe model of injection, not a string-based one. It is integrated with the web tier functionality. It has the following features:

Powerful, type-safe model

Can be enabled per-module

Integrated with JSF, JSP, EJB, web tier

Friendly to pre-Java EE 6 resources and services

Event model

Deeply extensible

Arun Gupta Tooling Demo

Oracle’s Arun Gupta came to the stage for a tooling demo that is explained here.

A Cloud in Our Future

“There is something hanging over all our heads – the cloud,” observed Chinnici. “What are we going to do for the cloud? I see containers coming back, so when you are in a managed environment and want to scale and have elasticity and have easy upgrades and patching, you cannot grow your own infrastructure. The model where you develop bare bones servlet containers and call any library you want and open any sockets you want, is not going to work; it’s unmanageable and does not scale.”

He explained that Java EE has a lot to offer, with its container-based model and ability to expose services from applications and consume services and inject them into the client. Java EE scales well with large production clusters and has a comprehensive security model – all items needed in the cloud.

He suggested that Java EE needs to tighten up requirements for resource and state management and have better isolation between applications. New standard APIs are needed as technologies like non-relational database systems and caching become common in the cloud. Packaging is important to version applications that have multiple versions coexisting on a single cloud platform.

Chinnici’s presentation made it clear that he is eager to creatively deploy the resources of Java EE to meet the accelerating challenges of cloud computing and whatever else may be in store for us down the road.

Greg Bollella - Helping Embedded Engineers Help Us

Greg Bollella, Chief Architect, Embedded Java, at Oracle took the stage and provided us with his definition of embedded: It’s everything that is not card or mobile or TV, that has a general purpose processor and that the lay person would not identify as a computer. He referred to cars today as “distributed computing systems on wheels” and made it clear that this was not intended in any way as a joke.

“So cars, washing machines, traffic signals, aircraft radar systems, missile defense are the kinds of embedded devices I’m talking about today,” he explained. “The last time I checked, in terms of number of processors shipped, what I am calling embedded compares to general purpose processors at a ratio of about a thousand to 1. So for every laptop out there, there are a thousand embedded processors grinding away code that some people wrote. There is a lot of code, lot of processors, and lot of opportunity.”

There were three main parts to his talk: Java ME.Next, Java ME + Web and Project Verrazono.

Java ME.next

Greg first declared that Oracle is committed to modernizing and upgrading the ME platform. In October, his team will meet face to face in Germany with the JCP committee and present some proposals.

A key element to Java ME.next will be an effort to enhance compatibility between CLDC and CDC and SE in an effort to make the programming process seamless across the different platforms and APIs. Oracle is fully committed to ME.next support with future products as well.

Guiding Principles of the ME.Next Upgrade

Bollella focused on making the language, the VM and the runtime libraries operate seamlessly across the platforms. And he insisted that there would be zero business disruptions with complete backward binary compatibility with ME, CDC, and CLDC programs currently in existence. “We will not leave anyone out in the cold,” he stated. “We will offer optional packages as well, and add capabilities as necessary. And backward binary compatibility. The security models of CLDC will stay the same and we will not have any dynamic loading of classes there. For CLDC we will combine CDC and the foundation profile into one so they will not come as separate pieces any more.”

Java ME + Web

With so much JavaScript code and so many services on the web, the goal is to bring the two worlds together. He pointed to three models that enable this: Java on top; web on top; and a blended application.

With the Java on top model, developers write Java code and are able to access web content and web services.

With Web on top, developers write JavaScript code and create Java objects and use those objects as though they were in the JavaScript features.

A blended application is a runtime that will support both of those models.

“The LWUIT with xHTML is a Java on top model,” explained Bollella. “You write a midlet and access HTML features. The JSR 290 model involves writing from a Java midlet but being able to access more features from the web than with LWUIT and HTML. The blended model is one where you can write both ways: JavaScript to Java and Java to JavaScript. And have access to all of the web components.”

Java ME is moving in a direction where it can have a runtime that supports all of those models -- writing JavaScript code, getting to Java; writing Java code and getting to JavaScript code; and applications that blend all of those models together. The idea is that all of the components running underneath would be available to run all three kinds of apps at the same time.

Embedded Systems – Your Favorite Embedded Device to Hate

He then invited the audience to ponder their favorite embedded device that they love to hate. Greg readily admitted that he hates traffic signals: “They are everywhere and multiplying, and they are stupid. We all have the same experience -- sitting there waiting with the light red, and there is not a car in sight.”

He described how traffic signal controllers started with a round metal plate hooked up to a clock and concentric circles of threaded holes with pegs screwed into them that turned every two minutes to turn switches on and off. The problem was that it was disconnected from anything going on around it. Then the engineers got the sensors in the ground and cars would set them off. “The sensor knows you are there and the light knows you are there but it’s still red because it has to go through some algorithm to get to some end point,” complained Bollella. “It’s frustrating sitting there because as I’m waiting for the light to turn, I’m thinking about the assembler code chunking away in the digital controller waiting for some event to happen for me to get a green light.”

The problem is that the engineers lack the tools that would enable them to do a better job. “So,” said Bollella, “I’m on a mission to make life better for those embedded programmers, which in turn will make life better for me.”

He observed that in the early days of Java, there was personal and Embedded Java and the SE, ME, and EE platforms, which at the time, given the limitations of devices, was the right thing to do.

“But today we are rethinking that,” he said. “We want the programming environment across the platforms to be much more seamless. There is a lot of diversity in the embedded space and getting Java onto all of these things in a seamless environment is a real challenge.”

He has been working on a project with Audi and Stanford. “I’ve seen it in print where auto executives believe that the perceived value of a new vehicle is 70% in software and electronics,” he exclaimed. “Let me repeat that: 70% of the perceived value of a new car is in software and electronics. You guys won! Software rules – that’s the message. At some point in the future, the only job is going to be software developer. Everything is going to be software! Trust me. It’s coming.”

The problem, he insisted, is that the job of the embedded software developer is rapidly getting more difficult very rapidly, requiring more code, more complexity, and better tools and platforms.

Project Verrazano – Aggressive Testing

Bollella closed with a discussion of his Verrazano Project, which is a tool his team has built that he says, “takes a jar and a library and a VM and it tries to rip out everything the app doesn’t need and build a specific runtime for that application so we can test to make sure we got it right. We are being very aggressive.”

He closed with a demo of the Project.

Bollella will explore his work with Stanford and Audi in the Thursday morning Java Frontier keynote.