JCP for you and me

Azul Systems CTO on Lambda binging and upping Java community input

Hartmut Schlosser
coffee.1

Gil Tene explains why he’d like to see wider participation in putting together final Java builds, and why we‘re going to see some overuse of certain Java 8 features.

Alternative JVM builders Azul Systems CTO and Co-Founder Gil
Tene has been putting together Java based products since the
mid-nineties. In this interview, originally published in the April
edition of
JAX Magazine
, he casts his incredibly experienced eye over the
latest incarnation of the platform, and tells us what he’d like to
see on the roadmap towards Java 9.

JAX: What do you think are the most important
things that Java 8 will bring to the JVM?

Tene: I think that there are two or three
different important things with Java 8 – and only one of
them is an actual feature of the Java 8 platform. What is probably
very much talked about it the addition of lambda expressions as a
feature in Java 8.

I think it will be an attractive new way for developers to write
code, and it will also drive adoption of Java 8, probably faster
than we’ve seen any previous versions of Java adopted since Java 5.
That’s primarily because this really is the first new programming
feature in Java since Java 5 – basically, something that really
changes how people write code. In Java 5, we had additional
Generics, which changed a lot in how people wrote code for
collections and other things.

The changes we’ve had to the platform since then have been in
extending libraries and capabilities and other things here and
there, but mostly they were very small increments. This was a big
increment. You write different when you use Java lambda expressions
now than you did before.

So that’s a major feature I’m sure anybody else you would talk
to would mention. The other very important thing that Java 8 brings
is that it is the first Java release in a very long time to arrive
on a predictable, pre-announced schedule.

That is a big thing. If you look at the last three
releases of Java, things took longer than they should have, or than
were expected. Dates flipped multiple times, it was very difficult
to predict when anything would happen…and as a result, anybody
using Java (which is most of the world) basically had to make an
educated as to when transitions would happen, when to plan their
projects and to look ahead as to when something could happen. When
you’re an IT organisation, you want to have a year or two of
visibility into these things so you can plan.

There were certainly a couple of feature shifts
though. There were certain things that people wanted and they were
planning to have in the Java 8 release which are not there, and
have been pushed out to Java 9 or to a later
release.

I think that’s a very
positive thing, because for the first time the release date and the
ability to release something on plan with the visibility – I think
it was about a year ago they said when the release would be, and it
has come out on time -which is admirable.

You could that Java 8 was defined as the thing that would be
released on March 18th 2014. And that is a change in behaviour. Up
until now, Java releases were done when they were done. In the
early years that happened rapidly, but for the last seven or eight
years there hasn’t been a predictability to Java major releases,
and that affects how everybody plans their budgets. I’m very
hopeful that this will remain the case. The official plan is to
have a two year release cycle, with Java 9 happening two years from
now, Java 10 happening two years from then…and for those release
trains to include certain features that you’ll have visibility into
roughly a year ahead of time. I think that’s a very, very positive
thing that Java 8 is the first occurrence of that, in the long
run.

What do you think will be biggest adjustments for
users of Java 8?

Honestly? I think the biggest thing will be learning how to read
it – because other people will be writing code in it, and you’ll
see library code in examples, so everybody’s going to have to learn
how to read the syntax.

Again, the last time that happened was when Generics were added
in Java 5. This always happens with new features – there’s a cool
new feature and everybody starts using it for everything. It will
be an interesting learning curve on where it is useful, and where
it is not a good idea, and where it shouldn’t be done.

We’re going to see very quickly that there will be a learning
curve. At first everybody will be using lambda forms just because
they are there, and then we’re going to have all the bugs that
happen because this wasn’t a good idea, and then we’re going to
have the use of them where they make sense, and where they’re a
good idea, and the lack of use of the regular syntax in other
places. That happens always when new features are added. You have
nine million Java programmers out there I believe, and that creates
a time to learn what the right things are.

Is there anything in Java 8 that you think could
have been done differently, and why do you think this
is?

I don’t have much negative to say about Java 8 – I do
have things I’d like to see done in Java 9, and I would like to see
them done differently.

I think with Java 8, as I said, the focus was delivery, and it
should have cut into a lot of other things. But there are several
features and things that I think are important focuses going
forward.

For example, I think that the new features – the
lambda expressions, and the support for some functional language
capabilities – those are all great things, there’s nothing negative
about them, but I think that there’s not enough focus on Java 8,
and I’d like to see that focus regained in Java 9, on mainstream
performance and mainstream tooling for improved performance for
things that are not functional, that don’t use lambda expressions
etc.

A specific area I’ve been working on is memory
access patterns and ways of expressing more optimal memory access
patterns in Java that will allow it to compete better with C and
C++ where the same access patterns are already supported. You could
say learning not just from the cool new things in new languages,
but also from the low level speed things in existing languages is
something I think we need to do.

The additional thing is there’s the process thing –
that is the part of having more contributions from additional
external companies other than Oracle into the core Java SE
platform. We’re obviously one of the companies that are in that
community, and there are several things about the process as it
stands that make it very hard to contribute anything but fixes and
comments and reviews into the process.

If a company other than Oracle wants to bring a major feature
into the platform, it’s very hard right now, primarily because of
how the projects are run – today, everybody that wants to use and
ship Java 8 has access to the OpenJDK TCK tests for it, and
everything is available, but it’s
only been available on the final release, when everything’s already
done.

This means that contributions up to this point were mostly very
small and incremental. In the future, what I’m hoping to see is for
the early access to pass to community members so that we can do
just as massive or major changes and reliably add them to the
platform, rather than wait until the platform is released to add
anything.

As a member of the JCP, you’ve talked about the
importance of Oracle keeping its development open. How successful
do you think it’s been at this in the past few years? Has Java 8
been a positive demonstration of Oracle’s commitment to open
source?

I think that it’s been a good demonstration of openness and
process. I think that Oracle has done very well at keeping Java
development in the open. A lot of the worries people had when the
Oracle/ Sun acquisition happened several years ago, about whether
Java will become closed and a problem, has been addressed by the
actual behaviour of Oracle. I think that it’s doing the right
things.

As I mentioned, I think that there’s been a challenge around
having true community contribution. That challenge is mostly around
facilitating major contribution, as opposed to small and
incremental ones.

A way to think about it is this: the many individual
developers that contributed to OpenJDK that don’t work for Oracle –
there are no major companies that do that right now into the main
platform. Probably Azul and RedHat, and IBM to some degree, are the
companies you would look at for contributions outside
Oracle.

If you look at Java 8,
there are no significant features in the Java 8 platform that come
any company other than Oracle and Oracle employees. I think that
this has to do with some of the process issues that can be
improved. This is not a complaint though – it’s more of a
suggestion for future improvements.

There are already signs of this happening. For example, RedHat
has taken on a couple of projects in Open JDK. There have been new
projects created by external companies, so that’s a good sign – but
none of them have come to fruition as code that shows up in the
main platform, and I look forward to the results of them showing up
in the main platform in Java 9 or Java 10.

Do you feel that security concerns are still a
massive issue for Java in the browser?

I would say that Java is no less secure than other programming
languages that have generic capabilities. If you look at things
like the Windows platform and native plugins, all of them have
similar exposures.

It’s really the alternatives to Java that have emerged in the
form of things like HTML5 and JavaScript within the browser that
provide an inherently more secure environment. I don’t think Java
is any less secure than Flash or plugins in Windows that have been
around – it’s just that it’s got a lot more attention in the last
year or so because a lot of vulnerabilities that have probably been
around for a while were exposed.

If you look at processing, you don’t see that much Java in the
browser as a process. It’s more of a legacy thing, the way I see
it, than it is a current application thing, JavaFX being probably
the exception.

JavaFX – there’s a new version delivered with Java 8 – it is
aimed at more rich environments and potentially delivery through
browsers, so in that environment, we’ve yet to see how people pick
it up from a programming perspective. But I think that the security
issues really do come in the form of web vulnerability, and Java
happens to be one of the vectors, but there are many other vectors,
and when you take away the question of the web browser and you look
at enterprise applications or things on a desktop, Java tends to be
as secure or more secure than anything else – I don’t think it’s
got any extra insecurities.

How do you feel that Java 8 has shaped Azul
System’s roadmap going forward?

That’s an interesting question. You know, when I
mention the thing about a major feature of Java 8 is what date it
came out on? That’s a big thing, especially for a company like us
where all we do is Java. We release JVMs, so having a visibility
into when things actually happen is critical.

We have a roadmap, and had Java 8 suddenly slipped
by another seven months, that would have had a major impact on our
product lines. So that fact that’s released, and it’s released on
time, is a great thing, because it means that we can keep to our
plans.

As far as what it means to us from a product line
perspective, we’ve been releasing JVMs since Java 4, so we did 5,
and 6, and now 8, and in essence there’s nothing big or different
for us. We followed the Java SE standard, we released fully
compliant, fully compatible JVMs, and we plan to keep doing the
same. This just gives us the ability to do it in a more predictable
fashion, because there’s a predictable version to
follow.

Another thing that I would say is that at Azul, we
don’t really look at the Java SE standard as a release. Azul’s
products have their own versions, and when we release a new version
of an Azul product, we don’t apply it just to the latest and
greatest Java.

So it’s not just Java 8 that will get those
features, it’s every Java version that we currently support – right
now we support Java 6 and Java 7, and soon it will be Java 8 as
well. When we add a feature, it will appear for all those
versions.

The main reason for that behaviour is that it will
be a while before Java 8 is the majority of production time Java.
It just came out last month, and as a result, there’s a natural
adoption time, of people actually deciding to use the features, and
you’ll have earlier adopters than others.

Most of our customers still run Java 6 – I am
looking forward to seeing a strong shift to Java 8, but it’s not
going to happen next week. It’s going to happen over the next
couple of years.

Even if you put aside the natural maturation of the
product itself, there’s simply the questions of operations. People
have to move their codebases, and their production set-ups, and
their practices and monitoring and knowledge, and that takes
months, if not a couple of years.

So when we look at our customer base and we add some
new features, we are not in the mode where we say if you want the
new features, you have to move to Java 8.

You can have the new
feature on Java 6, 7, or 8, from our point of view, and the same
will happen when Java 9 comes out. Our actual support horizons for
JVMs is ten years, so if anyone still wants to be running Java 7
ten years from now, that’s OK by us. We think they
probably
should
have moved, but if they
have some operational reason otherwise, then we will still support
them.

Is there anything you’d really like to see
in Java 9?

I’m most interested in things around mainline performance, and
also support for improving the high-performance and off-heap
access. There’s an API in Java called “unsafe”, which is clearly
labelled as unsafe and shouldn’t be used, but people end up using
it very much for performance reasons.

There’s an effort underway under Open JDK that is
intended to provide an alternative to unsafe in Java 9, called a
“safe unsafe”. I’d very much like to see it done, because a lot of
our customers need it. I think another obvious one is Project
Jigsaw – hopefully that will make it into Java 9 within the time
frame.

I would like to see the issue of Java Generics addressed again,
from scratch. We have Generics in Java that was introduced in Java
5, and everybody knows and uses it, and its ageing .I think a
version two of Generics would be very useful, with a lot of lessons
learnt. That’s one major language feature I’m hoping to see.

Gil Tene

Gil Tene (Twitter: @giltene) is CTO and co-founder of Azul
Systems. He has been involved with virtual machine technologies for
the past 20 years and has been building Java technology-based
products since 1995. Gil pioneered Azul’s Continuously Concurrent
Compacting Collector (C4), Java Virtualization, Elastic Memory, and
various managed runtime and systems stack technologies that combine
to deliver the industry’s most scalable and robust Java platforms.
Gil also represents Azul Systems on the JCP (Java Community
Process) executive committee. Gil holds a BSEE from The Technion
Israel Institute of Technology, and has been awarded 28 patents in
computer-related technologies.

Author
Hartmut Schlosser

Hartmut Schlosser

All Posts by Hartmut Schlosser

Harmut Schlosser is the editor and online coordinator for Software & Support Media’s portals JAXenter.de, Windows Developer and PHP Magazin. He is a specialist in Java Enterprise-Technologies, Eclipse & ALM, Android and Business Technology. Before working at S&S Media he studied Music, Information Studies and French anthropology.
Comments
comments powered by Disqus