JAX London 2014: A retrospective
View from the top

Georges Saab on Java 8 and the goal of “creating a scalable and modular platform”

LucyCarey
eight

JAXenter gets an insider account of the development of what’s been billed as “the most significant release of Java in the past 10 years” from the Oracle VP of Software Development in the Java Platform Group.

The road has been long – two years, seven months and eighteen days, to be precise – but Java 8 is finally a working reality. In this interview, Georges Saab, Vice President of Software Development in the Java Platform Group at Oracle, gives us an insider account of the “conservative” development of what’s been declared “the most significant release of Java in the past 10 years”.

JAX: How many engineers/developers were involved in putting together the Java 8 release?

Saab: Putting together a major release like Java SE 8 is a huge community effort that extends beyond the boundaries a single company or organization. That makes it very hard to answer a question like that with definitive precision.

For example, at Oracle, the Java platform is developed at locations across the globe by hundreds of engineers. In fact, we are currently looking for additional people in places like Stockholm, Santa Clara or St. Petersburg. You can find out more about that at http://oracle.com/javajobs.

Beside the significant amount of work from engineers employed by companies like Oracle or IBM, the thriving OpenJDK community has received major contributions for JDK 8 from a number of researchers like Michael Ernst from the University of Washington, and strong individual contributors, like Stephen Colebourne. Michael and Stephen have contributed some of the major features in the new release with their work on the implementations and their leadership of JSRs 308 (Type Annotations) and 310 (Date and Time API) respectively. Last but not least, Doug Lea and his team have again contributed a number of significant concurrency updates to this release.

Going even further, the release wouldn’t be as polished as it is without the many Java developers, who were testing JDK 8 Early Access builds early on, and those providing substantial feedback on the new features, thanks largely to organized community-led efforts like Adopt A JSR and Adopt OpenJDK.

Going into the release, what were the key design goals, and to what extent do you feel you’ve succeeded in meeting them?

Our goals for Java SE 8 were driven by trends in the programming community and in hardware architectures led by our continued commitment to ensuring the broadest possible success of core Java technology in the years to come. The main themes we focused on for Java SE 8 were productivity, performance and the foundations necessary to provide modularity.

A major new Java programming language feature like lambdas hits the sweet spot in a number of those areas. It makes Java developers more productive, allowing them to use a now widely familiar programming construct to write more concise and clearer, yet more easily parallelizable code. By making it easier for developers to write correct code that can allow the JVM to exploit the full potential of the underlying multi-core hardware, Java SE 8 moves the needle on performance as well, with improvements across the board in the core class libraries and the HotSpot VM.

Last but not least, the ongoing work on modularization has allowed us to introduce a new feature in Java SE 8 called Compact Profiles. Initially, our plans for Java SE 8 were even bolder, and included Project Jigsaw as a major feature. While Project Jigsaw was postponed to Java SE 9, Compact Profiles were introduced to meet more immediate platform footprint scalability needs, building upon the work already done to prepare the JDK for modularization.

They allow applications using Java SE 8 to be delivered with a much smaller footprint using one of the three standardized Compact Profiles. In JDK 8, we have introduced a new a tool called jdeps to make it easy for developers to determine if they can take advantage of Compact Profiles in their applications.

What were the other features that you wanted to put into Java 8 which turned out not to be feasible? What were the reasons for these decisions, and can we expect to see them in Java 9? Can you give us an update of Jigsaw?

Stripped Implementations didn’t turn out to be infeasible from a technical perspective, but we ultimately needed a bit more time to ensure that the specification text and the associated legal framework allow the relevant use cases, while maintaining compatibility. We continue to work on this and hope to introduce it in a later update to Java SE 8, prior to Java SE 9.

We remain committed to the high level goal of creating a scalable and modular platform. Project Jigsaw is exploring and prototyping a simplified approach to achieve that goal, and work progresses towards making it part of Java SE 9.

How important was feedback from the Java community throughout the development process?

The feedback received from the community was extraordinarily important, given that this release introduces a major new language feature for the first time in almost a decade of the platform’s evolution, along with related changes in the core class libraries and the VM.

To take just one example, Brian Goetz, our Java Language Architect at Oracle and the spec lead on JSR 335 (Lambda Expressions for the Java Programming Language), and his team worked hard to involve the community early on through design and implementation discussions on mailing list in the OpenJDK community, via surveys and also through the JCP. The results speak for themselves: Lambdas are highly regarded in the Java community as one of the most exciting aditions ever to the core Java platform.

The Java User Group community, in particular, led by London’s LJC and other JUGs, organized hacking events to try out the new language features and APIs on real code, regularly providing some great feedback during the design and development of lambdas & the new date and time APIs.

What are you expecting adoption to be like for Java 8?

The new language and API features represent a major step forward for the platform as whole in terms of productivity and performance. In addition, developers of popular IDEs like Eclipse, IntelliJ IDEA and NetBeans have been working hard to provide great support for those new features in their upcoming releases.

We have seen tremendous excitement and activity around testing the weekly early access builds of JDK 8, and all indications are that the adoption curve will be faster than in past major releases – especially for new projects.

What new features / changes in this release do you think will be most challenging for developers (for example: Lambdas, ‘sugaring and desugaring’)?

I don’t believe that lambdas will be very challenging for Java developers. Due to the careful and thought-out way they have been introduced into Java SE 8, they feel like a natural extension.

There was one area that we rewrote from scratch in JDK 8: the new lightweight, high-performance JavaScript engine called Nashorn. Nashorn has replaced the old Rhino JavaScript engine in JDK 8. It has been developed with a strong focus on correctness and compatibility with the ECMAScript-262 Edition 5.1 language specification. So that may be an area, where if your JavaScript code inadvertently relied on some specification correctness issue in Rhino, you may find that Nashorn is stricter in its adherence to the specifications.

With the repeated shifting of deadlines, did you feel a lot of pressure to get this out on time for March? To what extent do you feel it may have impacted quality of the final build?

The extended schedule allowed us to add a few select features, especially in areas related to security. In general, we used the additional time to stabilize, polish and fine-tune the features we already had planned for Java SE 8. It also gave the broader Java community more time to evaluate Early Access builds, and report any potential show-stopper issues.

We have also used that extra time to reach out to developers of some popular open source community projects like Apache Lucene, Groovy and Scala and get their feedback on issues they considered as critical for their projects to be able to run on JDK 8. So I would say that we invested a lot of that additional time in improving the quality of the final build of JDK 8, with sufficient breathing space to be able to confidently hit the release date.

What would you say to people who say Java is too insecure to use in the browser – do you feel they are justified in their concern?

Maintaining the security worthiness of Java is a top priority for us. Over the last year, we have delivered a number of security improvements and new features through Oracle JDK 7 Updates, including Deployment Rule Sets and Exception Site Lists.

In addition, we have accelerated the release of security fixes for Java SE, aligning their schedule with the quarterly Oracle Critical Patch Update releases. A number of enhancements to default security when running Java apps in the browser have been introduced as well, providing more end user control and discouraging the execution of unsigned and self-signed applets.

Last but not least, we also introduced a new type of Java distribution, the Server JRE, which does not include a browser plugin at all, further reducing potential attack surface and potential confusion when evaluating server exploitation risk factors.

Can you tell us what’s on the roadmap towards Java 9?

Beyond the one obvious candidate with Project Jigsaw, there are a number of ideas being discussed in the OpenJDK community and elsewhere. Many of these ideas are gradually getting formulated and tracked through JDK Enhancement Proposals (JEPs).

At the moment, we are just integrating bug fixes and small enhancements into JDK 9, though, until a more complete picture of the proposed features emerges through the JEP Process.

Why was it important for you to include concepts for functional programming (closures, lambdas) in Java? How do you expect it to impact the community?

I expect the broader Java community to benefit from and embrace those concepts fairly quickly.

From the perspective of hardware trends towards increasingly multi-core architectures even in the embedded space, the ability to easily formulate maintainable, correct and if necessary, parallelizable code is a major and distinguishing feature for any mainstream programming platform.

Is Java 8 competing now with other functional JVM languages like Scala or Clojure?

While the new language and runtime features in Java 8 may end up bringing the various languages on the JVM closer together, I think that the different communities have rather different philosophies.

The trajectory on which the Java programming language keeps moving forward is one of measured and careful change. With millions of developers using this language, we have to very deliberately investigate the pros and cons of any proposed changes from a multitude of perspectives.

That conservative approach, on the other hand, also delivers a lot of reliability.

Author
Comments
comments powered by Disqus