Angular shitstorm: What's your opinion on the controversial plans for Angular 2.0?
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