View from the top

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

Lucy Carey
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