1. [...]Do you just want to introduce yourself and say what you've been doing recently at Azul?
Alex's full question: So hi. I'm here with Simon Ritter, Deputy CTO of Azul Systems at QCon London 2016. Simon, you are well known within the Java community. Do you just want to introduce yourself and say what you've been doing recently at Azul?
Yes. I joined Azul back in November last year as Deputy CTO and really, I describe that as being the understudy to Gil Tene who's the real CTO and a lot of what I'm doing is what I was doing before in terms of Java community, so appearing at conferences like this, presenting on Java and really helping developers to understand what's happening in the Java space because that's Azul is doing, we're focusing on the JVM so we want to help developers understand what's happening in the Java space.
Yes. I mean you can really say that we've only got two products, and both of them are JVMs. So on the one hand, we've got Zing which is our commercial high performance, low latency JVM and then we've got the Zulu project which is the build of the OpenJDK that we're doing as a binary distribution, purely built from OpenJDK, and making that available freely so that people can use that as an alternative to other binary distributions.
Alex: Recently, you announced the embedded Java though which is I think the first time a non-Sun/Oracle company has offered Java on embedded systems.
Yes, strictly speaking, that was on the ARM 32 architecture, so previous to that, we'd already done a build of the embedded version of Intel architecture so you could run on the Intel Galileo and do things with that but the big announcement as you said at Embedded World a couple of weeks ago, was that we now have support for ARM 32 and that means you can run it on the Raspberry Pi and if you want to do all those wonderful things with the Raspberry Pi then you can do that.
Yes. I must admit, I had a look last week of buying one but I hadn't actually got around to getting one yet: as soon as we get one, we'll start having a look and see what the benchmarks come out as; but it looks like kind of a good specification for developing embedded type applications, yes.
I think it's probably going to stay in the 32-bit for a while simply because you need to think to yourself -- what advantage does 64-bit give you in that space, and what would you need to use that for in terms of specific applications? So I think certainly for the time being that most things will be 32-bit and then as Moore's law and advances carry on, then yes, we'll move into the 64-bit space.
5. [...]What do you see is going to be the big bang feature of the Java 9 platform when it comes out?
Alex's full question: So back to its big brother, Java on the desktop and on the servers, Java has experienced resurgence recently with new releases coming out – Java 7, Java 8 and obviously further with Java 9 – and you're talking at QCon about Java 9 and some of the changes that are coming in here. What do you see is going to be the big bang feature of the Java 9 platform when it comes out?
I mean the real feature, the key feature has got to be project Jigsaw: modularity of the Java platform, the ability to modularize applications so that's really the key thing. There's a few other nice features that are coming along. There's some changes to streams, a few new APIs there. There's the REPL idea so that people can do quick editing and figuring out how things work, but Jigsaw is definitely the big thing that's coming in JDK 9.
6. [...]Do you think Jigsaw's going to come in Java 9? If so, when we might see that merging?
Alex's full question: At the moment, I think that Jigsaw development is on a separate branch from the main line, Java 9 development. Do you think Jigsaw's going to come in Java 9? If so, when we might see that merging?
Yes. In fact, what I believe from some of the e-mail I've seen recently is that the merge will happen within a couple of months [of March 2016]. I mean I don't know the exact date but I think it's probably going to be within a couple of months which is great because then obviously everything comes back into the main build. [Update: this was recorded at QCon London in March 2016, and since then, Jigsaw has been merged into the main Java 9 codebase.]
One of the nice things for us at Azul is I've been out there talking about JDK 9, that's wonderful. And I've been talking about Project Jigsaw and that's very nice but the build that we have of JDK 9 as an early access is from the main branch of the OpenJDK source code, so we don't actually have all of the Jigsaw pieces in it. As soon as the main tree gets Jigsaw merged into it, then we'll be able to provide an early access release of that which would be great for people to start experimenting with. [Update: Zulu 9.0.0.4 and above have Jigsaw available for early access testing]
Alex's full question: So I've been obviously going on about modularity being important for some time, and you've been pushing the agenda forward with Jigsaw as well. What do developers really need to think about in terms of modularity and how much designing in a modular fashion might impact?
The key thing I think is understanding that in terms of accessibility, public, which we are used to in Java meaning accessible anywhere in an application doesn't necessarily mean that anymore. So with a module, you can expose only classes and packages that you want to expose from that module.
So even though you've got a public class with public methods, if you don't expose that as available to other modules that have a dependency on that, then they won't be able to see it. So that means that public won't mean quite the same thing that people used to in the way that they've been developing code up until now. And so that's something that people are going to have to get used to. I think that's the biggest thing from a language and programming perspective is making that slight adjustment in terms of the understanding of accessibility.
8. How is that separation between modules enforced in Jigsaw?
Through the module system – so basically, when you have a dependency on a module, the JVM will look at that module. It will see what is made public and accessible from that module and then only things will be accessible to the other module that's got a dependency on it. So it's enforced by the JVM.
Alex: Is it enforced though at runtime or just at compile time – because you can imagine the compile time check would say, you can't compile against it but actually under the covers through reflection you can get to it.
No. It's definitely at runtime. It has to be at runtime as well otherwise as you say, you could kind of bypass some of these things.
No. I think that people will gradually start to adopt modules. I think it makes a lot of sense, and the ability for people to have this finer-grained control over the way the application works and the design of the application I think we'll see people gradually adopt it, yes.
Alex: How do people work with it if they don't want to adopt modules at the moment, because there are sort of generic modules that kind of normal application code will fit into.
Oh, yes. I mean if you want to continue using your code without the module system, then everything will appear very much the same way in that you can have your JAR files, you don't need to recompile those. You can just use them as JAR files and they can appear as if they were modules. So you don't need to convert them to modules in order to use them with JDK 9 so there's a kind of smooth migration path through that.
10. [...]Are those kind of things going to be hidden in Java 9 or removed in the future?
Alex's full question: How does some of the Java APIs change – I'm thinking like Unsafe obviously being the classical one that everyone raises but also something like the XML Apache parsers that we use to get a hold of for Base64 decoding. Are those kind of things going to be hidden in Java 9 or removed in the future?
So the way that's being organized is that there was originally an idea to encapsulate all the private APIs and then things like [sun.]misc.Unsafe would go away completely in JDK 9. That didn't prove to be very popular publicly because a lot of people said well, we've used these APIs and there’s no alternative in terms of the implementation so what are we supposed to do?
So Oracle decided that, okay we won't encapsulate those APIs straight away. What they would do is that certain APIs where there are alternatives will be encapsulated, but things like sun.misc.Unsafe will be left available so people can still use it. The idea is that in JDK 10 and potentially later, that will be migrated to a public API so that people have the same functionality available but through a public API rather than private API: at which point either sun.misc.Unsafe will be completely removed or it will be encapsulated so you won't be able to see it.
Alex: And some of the things that are coming in Java 9 like the VarHandles are really incremental replacements for part of the sun.misc.Unsafe functionality.
That's right, yes. It's the idea of trying to gradually provide the functionality in a way that allows people to move forward in a controlled way without breaking things at any particular point.
Yes. It's more of a sketch because there's a lot of details to go into and so with 50 minutes, what I'm trying to do is keep it at fairly high level. I'm talking about the changes to the APIs. So the encapsulation around things like sun.misc.Unsafe. I'm talking about what the basics of Jigsaw are in terms of how the module system is designed, dependencies, and exposing APIs and so on. And then I'll talk a little bit about some of the things that people would need to be aware of when they're developing code or migrating code to Jigsaw but with only 50 minutes, it's just not enough time to go into a lot of deep detail.
12. [...]I think you have OpenJDK builds going back to JDK 6?
Alex's full question: And coming back to the Zulu project. Zulu's the Azul supported version of OpenJDK; I think you have OpenJDK builds going back to JDK 6?
That's correct.
Alex: And presumably any security vulnerabilities and so on you back-port on there.
That's right.
13. [...]One would someone choose one versus the other?
Alex's full question: How would you compare the Zulu offerings from the Java that you can download from Oracle, for example. One would someone choose one versus the other?
Really, the idea is that we're just building from OpenJDK so from a platform perspective, if you're looking just for the JDK functionality, everything is there. There are some things like the [Applet] Plug-In, Java Web Start which we don't support and that is actually from my point of view a good thing because of the security issues so we don't support those things.
But other than that, the platform’s identical. If you've got a Java application, it will run without any changes on top of Zulu, so what we're really trying to do is give people an alternative to other JVMs. So if they want to run Java 6 with the back ported bug fixes in it, they can do that. If they want to run Java 7 with bug fixes back ported, they can do that. It's about giving people a choice.
14. [...]How do those garbage collectors compare with the commercial offerings that Azul have?
Alex's full question: I'm presuming these versions of Zulu come with the standard HotSpot garbage collectors, the G1 garbage collectors and so on, and ultimately I guess the new one that's coming out in Java 9. How do those garbage collectors compare with the commercial offerings that Azul have?
Yes. So obviously they are, as you said, the HotSpot versions. So it's either the Concurrent Mark Sweep or it's the G1 collector, all of the HotSpot ones, we have in the Zulu builds. In terms of the comparison, what we target with Zing is low latency so it's the idea of a pause-less garbage collector: no matter how big the heap is, then you're looking at very low pause times because of the way it works.
So you would have exactly the same type of footprint from a garbage collection perspective as you would have with HotSpot because it's the same code. Zing is much more targeted at low latency applications where you need that guarantee of not having long pause times.
Alex: Simon Ritter, thank you very much.