Transcript
Verburg: This is a panel on which Java should you choose for what reason, or which OpenJDK variant should you use for what reason and what's been going on in the past year with the release cadence and some licensing changes from Oracle, which may or may not impact your decision. What I'll do shortly is I'll get everyone to introduce themselves and tell them which company or which organization, their background, etc., is from.
But just to level set with the audience here, who here understands what the new release cadence is about with Java, with OpenJDK? Over Vista. How many people don't know? Okay, so there's a few people. How many people do not understand the new licensing changes that have come in for Oracle's Java? There's few of you, okay. What we may actually do is get Donald to start on that case - that's probably a good idea. Right. So very quick introductions. Hi, I'm Martijn Verburg. I am hosting this track and I also nominally run AdoptOpenJDK, which is a new community provider of OpenJDK binaries.
Ritter: I am Simon Ritter, ex of Sun, ex of Oracle, now of Zulu systems who do the Zulu JDK.
Hailey: I'm Andrew Hailey, the lead engineer of Red Hat's Java platform team, but I am also the project lead for the OpenJDK 8 and OpenJDK 11 updates project. I'm responsible for the upcoming releases of both of those things. I'm also on the OpenJDK governing board. I will try, throughout all of my answers to all of this, to make it fairly clear which of these hats I'm wearing at the time when I answer the question.
Hellberg: I'm Stephen Hellberg. I'm with IBM. I've been caring for IBM's Java but also now look after the OpenJDK with Eclipse, open J9.
Smith: I'm Donald Smith. I run Java SE product management at Oracle. I think I've come the furthest from these four too, so my brain I think is in the local time zone, and I think I've moderated the coffee and alcohol to the right level. So bear with me though if I start down a path and lose my train of thought. Since Martijn [Verburg] mentioned the licensing changes, let me just do the quick level set that I usually give when I'm about to give a presentation.
There are basically three things going on right now in the Java ecosystem. The first one is end of public updates of Java 8. So this is an Oracle thing. End of public updates is an Oracle thing. It was a Sun thing before that. We've gone through end of public updates to Java 4, 5, 6, 7, and now we're going through it for Java 8. I remember when end of public updates of Java 4 was happening and Java 5 was being released. Everybody was in a panic because Java 5 had generics, and it was going to be impossible to migrate up to it and everybody was frustrated and upset. At Oracle I've led the end of public updates to Java 6. I've done it for Java 7. We're going through it right now with Java 8. So that's the first thing that's happening. It's a long-standing process.
The second thing that's going on right now is we changed the release cadence, starting the Java 9 release since September of 2017. We did the first release after that six months later under the new cadence. We spent a couple of years discussing that at OpenJDK and within the JCP so that we could streamline the processes to make sure that we could do the new release cadence. We had to do that to keep up with modern application development. I'm very unapologetic about the new release cadence because, doing major releases every three to five years, having a three to five-year window to get a feature out, it's just not sustainable anymore. It worked great in the '90s. It even worked great in the 2000s, but I want to be on the stage with five Java vendors talking about their products and solutions and not be talking about, "Is Java still relevant in the world of node?" We need to keep relevant. A release cadence of six months is how we keep relevant in the cloud.
Then, the third thing is, and again this is an Oracle thing, we started to sell the way we do support for Java at Oracle as a subscription. That replaced a legacy perpetual license product. We used to sell this product for $5,000 a processor. Now we sell it for 25 bucks a month. Again, that has nothing to do with the release cadence or the end of public updates. We've been selling licenses and support - well, Sun started it with Java for Business.
So somehow that fact that we're now selling as a subscription gets conflated in this, and it's confusing to me why, because it has nothing to do with the other things, right? Subscriptions are how companies buy software now. The perpetual license is a legacy thing and so we've just modernized that as well. It probably went longer than you would've hoped, but I hope that's a good level set.
Verburg: We're good. This is Q&A from the audience time really, so you hopefully have been thinking all day about the questions you have about this. I think there's a handheld mic somewhere. Here, right next to me. Do we have a room volunteer here? We do now. If there are no questions we're going to leave really early.
Can the Oracle JDK Run in Production?
Participant 1: Thanks for the introduction, Donald. Definitely I see a lot of confusion around the Oracle aspect of charging. One question I get asked a lot by clients is, "Can I run the Oracle JDK in production?" I know I can run it for dev locally. As soon as it goes to production can I do that at all now?
Smith: Any Oracle JDK release that you've downloaded as of now under the BCL, yes. You can keep running that in production for as long as you want. By the way, there's an LJC JUG meeting tomorrow night. It's a couple of stops up on the train. I will be giving the two-hour version of that one or two-minute preamble that I just gave. One of the things that I will go into there is, Oracle has started to produce OpenJDK builds. Until Java 9, Oracle considered OpenJDK as a place where you work on Java SE source code and not as a thing. We had the Oracle JDK. OpenJDK was where we worked on the source code and where others created OpenJDK builds and releases.
But starting with Java 9, the roadmap we laid out is the Oracle JDK will become, after a couple of releases, so we're going to see that now, as the commercial builds for commercial supported customers and then we will have our OpenJDK builds under the GPL license. So with Java 11 the binaries are interchangeable, the Oracle JDK and OpenJDK. And that's great because now it's a lot easier to switch between JDK providers and then you can look at what you value in terms of support and stability and performance going forward.
I think we've had a pretty successful transition. It's taken about a year. I know it's created some confusion because 9 and 10 weren't interchangeable, but now that we're at 11, going forward, it's very straightforward. Oracle will produce an OpenJDK build and an Oracle JDK build, which is licensed commercially.
Hailey: Yes, I can speak to that a bit because it's important to clarify what happens after Oracle ends its support for the OpenJDK builds, because that's where I come in. What we're doing as a community is we will continue to do security updates for the OpenJDK 8 and OpenJDK 11 platforms. So yes, you can continue to run the old perpetually licensed OpenJDK binaries, but quite frankly you'd have to be pretty brave because you're not getting security updates. If you want those security updates, you're going to have to come to the OpenJDK builds.
Smith: Well, yes, or get a subscription.
Hailey: Or pay Oracle. I mean, come on.
Smith: And for what it's worth, this pattern has existed for almost a decade, because when we did end of public updates of Java 6, Andrew and Red Hat and Andrew took over the OpenJDK 6 updates project, and then if you wanted an Oracle JDK 6 update you had to pay Oracle for it. It was a commercial-only thing, and we've supported that commercially right up until the end of last year. Then we did the exact same thing with Java 7 a few years ago where Andrew and Red Hat took over the 7 updates project, and then Simon [Ritter] at Azul.
Ritter: I was going to say it's actually Andrew. Not me because it's Andrew at Azul who's taken over the project leadership so clearly...
Smith: Of 6?
Ritter: Yes, of 6. You have to be called Andrew to be allowed to work on ...
Smith: Azul took over 6. You have Azul looking after 6, you have Red Hat looking after 7. When I say look after, I'm just speaking project leadership. There are obviously many hands involved in that, and now we're going through that with Java 8, and because of the way the cadence comes together in a perfect storm, it's 8 and 11 at the same time. So then going forward, our belief is that people will get on the new release cadence with Java 12 and 13. I know that sounds scary if in your mind you're thinking the six-month release is the feature release. If you think of them as a major release and, "Oh, my God. It's going to be really hard to keep up," I understand, but I think time is going to show that getting on the six-month cadence is actually going to be quite doable, very straightforward. Trisha [Gee], in her talk earlier if you went, she had some anecdotes about that, which are giving me some more optimism. I'll even say Java 13 doesn't even have a JEP targeted to it yet, so it may actually be the single easiest update when it comes out. Hopefully, we get a JEP or two in there. We'll see.
Ritter: I was going to say because 12 has only got - was it six, seven JEPs? It's quite a minor.
Smith: I think Java 12 is going to be the easiest migration between releases that there's been.
Hailey: And that's not a bad thing. The great thing about having updates at fixed times is that all of the different projects that are coming along can evolve in their own timeframe. They'll be released, not just because there's a Java release coming, but because they're really ready to go, we've talked to everybody, we've got a community behind it, and then we'll do it. So occasionally some are going to be light, which JDK 12 certainly is. We've got some really big-ticket items coming down the pipe. Projects Panama and Loom, for example, and we don't quite know when they're going to be ready but they will be and they'll be lovely when they come.
Ritter: I think what will be quite interesting as well is - I know Trisha asked this in her session and I know when I talk about this subject I ask this as well. So just polling the audience. Who here is using JDK 8? Who's using JDK 7? 6? Anybody using anything older than 6?
Smith: Liar.
Hellberg: If this had been in Asia there would be just a few in the audience.
Ritter: Anybody using JDK 9 in production? What about 10? One. What about 11? That's as I would expect. It's just interesting to see. Last question from me. Who's planning on migrating to 11? Interesting. There was a question over there.
OpenJDK and Security Updates
Participant 2: You mentioned that the OpenJDK project would take over security updates when Oracle stops providing them. What's the time frame for how long that will continue?
Hailey: You know what? I should've actually written this down. I think JDK 8 is going till at least 2022 or '23, we've said.
Smith: Well, so this is where it's important to tie it to a vendor. It's not necessarily the OpenJDK project, because as we've seen with Java 6, Red Hat stopped supporting Java 6 to real customers a couple of years ago, even before the end of support from Oracle and then Azul kind of took over the OpenJDK leadership part of it.
Hailey: Well, it is important though to say when we are prepared to guarantee, by swearing on a stack of bibles, that it's perfectly possible that after that date, 2022 or '23, I can't remember, then somebody else will take over, but I can promise you that the OpenJDK 8 updates project will be going for that long.
Participant 3: So for four or five years?
Hailey: Yes.
Smith: Yes.
Verburg: 2023 is what we've publicly stated.
Hailey: Thank you, okay. I should know this, I know.
Smith: I'll share it like a support secret. If history is any indicator, every even number release seems to far outlive the odd number releases, and I think Java 8 is going to end up being supported by someone probably including an OpenJDK, probably until the end of 32 bit time.
Hailey: Yes.
Smith: I'm not exaggerating. I believe that.
Hailey: I didn't get into this business to do vintage software support for the rest of my career, but this is kind of what it's looking like.
Smith: Like Trisha said, though, at some point, being still on Java 8 will be a liability but at some point, from a dinosaur perception perspective, but at the same time you would be shocked at what 1.4 is still powering.
Ritter: I found people on 1.3.
Hailey: It's perhaps worth speaking a bit to that, because most of you in the room here are not involved in the business of doing the kind of security updates that we do for OpenJDK. Generally speaking, when we get a security bug, we have a very good look at it and we see if it is a bug on older versions of the JDK and we see how far back we can go. With some of them, probably with the majority, because bugs get fixed in older versions over time, it's less likely that they will be affected, but sometimes some of the bugs can go back a long, long, long way so we have to back port them.
Now, the problem is that the JDK code base mutates over time as it gets better. It gets more complicated. Sometimes it gets simpler, but not very often. It gets harder and harder to back port those security patches, and sometimes there can be a delay where we look at this and we think, "Oh, my goodness. This is really scary to try to back port this fix." Do we actually want to do it? Are we going to end up breaking stuff? And eventually these things will get fixed but sometimes it's quite complicated.
So when you keep an old Java release in production for a long time, yes, we'll keep supporting it. Yes, we'll keep fixing the bugs, but it is all starting to get a bit marginal after a while. JDK 8 is fine. Older versions, well, maybe.
Ritter: I'd just like to add a little bit to that, because one of the things we're going to see moving forward is also a difference, and what I mean by that is that if you take JDK 11, is a good example. The java.se.ee aggregated module was removed completely from JDK 11, which means there's no more COBOL, there's no more JAXB, there's no more JAX-WS. Now, the impact of that is also the fact that because that source code is no longer in the OpenJDK project moving forward, there will be no security fixes for those things. There will be nothing to back port. You need to be aware of that kind of thing as well, in terms of thinking about using older versions because of the implications again of the security fixes. If there was something that did affect those, how would you get a fix for it?
Implementing Open JDK or AdoptJDK
Participant 4: One question from me. Just with the number of options you've got on the implementation of OpenJDK or AdoptJDK, there's also another one that's sort of come up now that we've found, is Corretto with AWS. How does that fit in with it? We're just sort of trying to find that out.
Smith: We'll let Andrew speak to that one.
Hailey: I am in very close contact with the developers of Corretto. They have two classes of patches that they make through OpenJDK. One class which they think is genuinely beneficial to the whole community, generally beneficial to OpenJDK in terms of correctness and performance and so on, and they send all of those upstream to OpenJDK. There are some other weird things that are more to do with running it inside the Amazon platform, and generally speaking they can keep those to themselves and they do. So there is no pressure between Corretto and OpenJDK. They are active contributors and we are doing our best to work with them and we're doing pretty well.
Smith: That's not at all how I thought you were going to answer that.
TCK
Participant 5: I apologize for being probably a bit out of date on this, but I was under the understanding that as part of taking, for example, AdoptOpenJDK, there was a TCK, there was a correctness suite, you mentioned correctness, that needs to be open or available. Could you just explain that for me please?
Verburg: In order to prove that your implementation meets the Java specification, you should run your implementation against the TCK.
Ritter: You must.
Verburg: You must. Sorry, yes, you must. There are two ways you can get ahold of the TCK. One is commercially. So you go talk to Oracle and you enter a commercial arrangement with them. The other is called the OCTLA. I won't bore you with the details but it's effectively a community version of the TCK which you can request from Oracle. If you enter the right type of agreement then you can freely go run that TCK and many people do. I believe Azul has done it in the past.
Hellberg: Yes, there are dozens of companies.
Verburg: There's dozens of people at the moment. At AdoptOpenJDK we are still working with Oracle in terms of us getting access to that TCK. So we do not have it yet. And unfortunately we can't comment on that further, because things like arranging a TCKX is actually a legal matter and so neither side will ever comment on it until it gets resolved by one or the other.
Tool Support for Java 8 Applications
Participant 6: Now that part of the runtime is being removed from Java 11, is there any tool support for me for a given Java 8 application that will tell me if anything's being used that is not available anymore? Apart from just running it, but maybe the execution part is not being ...
Smith: Yes, we have Jdeps tool, and there is some other tool that goes with it.
Ritter: Jdeprscan.
Smith: That's it. It'll look at your code and tell you what's changing or has changed or will change to the degree that we know.
Hellberg: But you've got to run the right Jdeps tool in relation to the version of Java which you intend to run with, right? I don't know how cumulative Jdeps necessarily are. So, if our questioner was taking the Jdeps from Java 11, is there a mode which actually rolls up the results of 9, 10, and 11?
Smith: I believe so.
Hellberg: Jdeps is your friend.
Ritter: Jdeprscan is the one that will tell you anything that you've used is deprecated. If you're on JDK 8, for example, you can't run Jdeps on JDK 8 because that's not using modularity. But if you use Jdeprscan, you can take a JAR file that's been compiled on JDK 8, run Jdeprscan on that and it will give you a report of the deprecated APIs that have been used in that JAR file, so you would know what things potentially could be a problem as you migrate from 8 to 11 or later.
Hellberg: And the Jdeps tool is being shipped with the JDK's Java, right?
Man: Transitive tendencies as well? Those things that you referenced, the libraries you're using,?
Verburg: If you run the Maven plugin, yes, it'll do transitive as well. AdoptOpenJDK ported those two tools to be Maven plugins as well, thanks to a chap called Patrick Reinhart. So you can run those.
Smith: Is Patrick the guy who has - there's a GitHub page where he maps out a table and you can click any two versions and it'll tell you the API differences?
Verburg: That's the one, yes.
Smith: That's pretty handy. I can imagine that being something that could plug into GitHub at some point too.
Verburg: Absolutely. There's a JDK API dev tool as well at AdoptOpenJDK GitHub so you can just find that tool as well. That'll help you as well. Other questions?
Support
Participant 7: If you're finally ready to move off Java 8 and you're not actually totally averse to paying Oracle, what are the factors that might determine where you go thinking about [inaudible 00:24:25] support?
Verburg: So complicated. I'll say this from the AdoptOpenJDK perspective. AdoptOpenJDK as a community only provides effectively free support. There are a couple of companies who are offering commercial support for AdoptOpenJDK. IBM and jClarity which is very new. They fundamentally rely on the OpenJDK upstream project to provide the source code patches. So we're relying on Red Hat, Amazon, all the other partners. Of course IBM and JClarity have their own staff which contribute to that, but it is probably fair to say that we have nowhere near as many engineers as Oracle does directly when they go and patch OpenJDK and Oracle's JDK.
Ritter: And since you opened the door to a little bit of a commercial discussion, so at Azul, we have Zulu as our JDK. We do a community edition of that which is free. That is just a build like AdoptOpenJDK of whatever is in the OpenJDK repo at that time. For our Zulu enterprise edition, which is a commercial product, which comes with full support, we actually do the back porting of the fixes ourselves so that we can get those out very quickly after Oracle come out with the latest patch. So we have SLAs that are associated with that and we can do full commercial support around that at a very reasonable cost.
Hailey: I promised you I'd tell you which hat I'm wearing. I've now got the red one on. The thing that you should probably do is think about what support means. We've seen the word support used in all manner of different ways. There are some companies who've said, "We'll support such and such a piece of software." And you'll say, "Well, what does that mean? Does that mean I can talk to somebody when I get a problem? How do I report?" And it'll turn out in the end. All they actually mean by support is that every now and then they'll send you a product update.
Companies that are involved in professional support, generally speaking, you have to have people managing phones, that cost real money, you have to have people responding to bug reports, answering emails, and so on. So you need to know that there's actually a support organization there behind all of this money that you're paying. You also need to have some sort of confidence that the engineers working at this organization know what they're doing. Clearly, there's no question of that with Oracle who originated the Java platform. You can also look at OpenJDK. You can say, "Okay. Look at the OpenJDK sources. Look at the patches. Who is writing them? Where are these engineers? What companies do they work for?" Obviously, I wouldn't be saying that if I weren't very confident about the results that you would get from looking for Red Hat in the OpenJDK code base.
Hellberg: From the IBM perspective you've got the [inaudible 00:27:38] from adopt. That was built on the OpenJDK answer. But we've also provided the open J9 code base too, and that's an independent implementation. It's not a port of hot spot. We maintain the same experts there. The open J9 project is now the source for the same code fixes that effectively go into the IBM Java, which we've been supporting for, I don't know, not far off 20 years as well. That same team of people is still there. From that perspective, you can look at the functionality that the VMs provide and decide whether or not there are competitive technologies in relation to that. That might depend again on the nature of the platforms that you're wishing to target, the different processes and the rest of it.
Smith: I think, Andrew, I'd just like to add to what he said. I mean, I think he nailed it from my point of view as well. On the notion of support versus updates, I think that is important because there are a number of people that will say, "We will support you or we will give you free support." But what they really mean is, "We're going to provide free updates." I'm going to pick on Corretto for a minute since they're not here and since Andrew declined the opportunity to pick on them, and instead said nice things. Their FAQ clearly says, “If you have a problem with Java, please go ask the OpenJDK folks.” And what that really means is go ask Red Hat and Oracle, frankly. So you’ve got to look at that.
The other thing that I always encourage people who are looking at OpenJDK to do, is look at the history of the downloads, look at the time gaps for the stability performance and security updates from each other. So where you may be able to get it from Oracle or from another vendor, because if you look at that and there are several hundred days of lag between a security release on one of the platforms and not on the other. And we do all work together on security. There is an OpenJDK security work group, and a properly funded and motivated group. We can make sure we have the simultaneous release. We're very close to simultaneous release.
Then the other thing I like to point out is look at the vendor. Are they going to be around in three years? Are they going to be around in five years? Are they trying to push you into things that are maybe proprietary or vendor lock-in in a way that you might not expect? So is there some sort of technology or hook that at scale makes it difficult for you to transition to another JVM? Is the company about to go through a merger with another company where they may, at the executive level, have to decide which - when I first joined Oracle - sorry, I really thought you were throwing something at me. No, but seriously, when I first joined Oracle they had just bought BEA, and we had J Rocket and we had Hotspot. I've seen this before and we're going to see it again, I'm sure. I'm optimistic, but it's a question. It's a fair question.
Ritter: I think I'd also like to reiterate. No, believe me, I'm going in a different direction. I'd like to reiterate something that Donald mentioned there, which is that there is this thing called the OpenJDK vulnerability group. It's actually a closed group within the OpenJDK, which is quite important because they had to change the rules slightly because OpenJDK has the name open in it. But because it is dealing with security vulnerabilities, it can't be open. So everything has to be private, everything has to be encrypted, in terms of our communication. But the important thing about this is that all the key people who are doing work around Java in terms of JDKs and JVMs, are involved in this. So AdoptOpenJDK is in the vulnerability group, Azul's in it, Red Hat's in it, IBM's in it, Amazon's in it, SAP's in it. There is a list publicly available. So even though it's a nonpublic group, the lists of people who are in that group is available.
So it's important to know that there's lots of people working on security fixes as a group. It's not just Oracle having to shoulder all the responsibility of this. We do work and we get access to the fixes and know what's going on so that we can get these things out in a very meaningful way. I think that's a very strong point in terms of what Oracle have done to make this a reality so that it isn't just us trying to have to follow things that Oracle is releasing, through the OpenJDK, through the projects that they manage. So I think it's important to make that point.
Hellburg: And that working group is working along the lines of that, which exists in Apache and such places which take responsibility seriously, too. So it's operating on a very similar model.
The Next Long Term Release Version
Participant 8: If you're already on JDK 11 and you're looking for the next long term release version or a long time support version, which one would that be?
Ritter: 17.
Hailey: Panic has been sent across the internet. Oracle guides the most extraordinary lens to avoid talking about this because they will always say that, even Mark Reinhold will tell you this. He will say, "Well, these are just the official long term support releases that Oracle will be supporting long term." Of course any of you could go out on your own and decide to offer long term support for something else. However, nobody is going to do this.
Ritter: Actually I would like to disagree with you slightly on that, because Azul are actually offering what we call medium term support on builds 13 and 15. So if you wanted to use a feature from a build that's between the long term support releases, then we will continue to support 13 or 15 until 18 months after the next long term support release comes out so you have time to migrate to that. That's because we have a choice to do that. As you said, Oracle have chosen these releases. There's no requirement for everybody else to follow that. Obviously, the logic is that we follow the long term support release so it makes life easy for developers, but we're free to offer other long term support plans like that.
Smith: If you think our support matrix gets confusing you, should see Azul’s support matrix because they have medium term support.
Hellberg: And all of this is in the context you have to decide whether that's what long means anyway. This is partly in comparison with some of the other competitive runtimes out there. For example, Node.js, that's operating on a three-year lifecycle for each of its releases, but it's only really two and a half years that it's in support. You've got six months of development period. It's not long if you look at it on the perspective of how long was Java 5 or Java 6 around, but then again it comes back to the question of its relevance, in this new particular age of runtimes and all the other competitive foundations by which you could be building your application. Is it going to be long enough?
Smith: Yes, and the reason I hedged, by the way, 17 is 3 years, so our plan is every 3 years we will have a long term support release. The reason I hedge is maybe two years from now we're looking at the features that are coming in, and we know that there is a feature that people are going to really want to be part of the next LTS release. And by then we will have a much better picture of how confident people are of keeping up with the release cadence because I know, people are going to keep up with the release cadence. People that have got on 9 were quickly able to move to 10 and 11 and I believe 12. But still, there's a lot of hesitation. And I think it's going to take a couple of years. So, in a year and a bit, we'll have had a couple of years of the new release cadence. Hopefully when Trisha gives her talk next year and asks how many people are using Java 13, I guess, half of the room will go up because they will have moved along. And then we can decide more firmly where to target that next LTS.
Verburg: I think everyone will keep following along with the LTS idea except for, of course, Azul who just want to be a little bit different, but that's fine.
Hailey: Kind of like a soft boiled egg.
Verburg: Yes.
Hailey: Yes. I think there's some truth in that. There are some things coming down the pipe that are going to be really compelling. Things like project Loom, project Panama, and so on, that I think people are really going to want. My best guess about those is that they will go into some OpenJDK release as an experimental feature. They'll bake in there for a while. They'll stabilize well enough, and at that point I think the demand that we really want a long term support release with these features in there, is going to be pretty compelling because they make a really, really big difference to the way that people use Java.
Verburg: Especially if you are following things like Valhalla, if you're looking at where Value Types is going, it may make it to 17, it may not but it probably will make it somewhere in between 17 and 23 and you bet your bottom dollar that everyone's going to want to grab it as soon as it comes out, no matter what the version number is. I think that'll be one of the keystone ones.
Smith: That's what I keep reminding people that ask, "No, really? Six-month release cadence, really?" And I point out that you are on a six-month cadence and you just didn't really notice it, because 8AU20, 8AU40 were six months apart. But then the next thing I ask is, "Well, if we come up with Value Types and suddenly big data type applications are 50% faster, you're probably going to want to get on that."
How Free is Java?
Participant 9: Well, I was just interested in the title of this session, “Java is still free?” Is it actually any less free than it used to be now?
Hailey: It's more free.
Verburg: Yes, it's actually more free because, in a way, the three things that Donald mentioned at the start is really actually take an OpenJDK and made OpenJDK a lot more prominent than it was before. Previously people just went to Oracle and just got Oracle's Java and that was it. Now if by default you went to the Oracle Java download site and you were talking about Java 11 plus, you have to make a decision. Do you want that commercial Oracle Java, or do you want Oracle's OpenJDK build, or do you want an OpenJDK build from somewhere else? In a way it's made life a lot freer for everyone.
However, I will add a warning that for the people who are used to going to Oracle's Java and expecting to get a dollar free Java from 11 onwards, you just need to be aware that you now need to make a choice. Do you want their commercial support from day one, or do you actually really want an OpenJDK build instead? And that could be from Oracle or it could be from another vendor. That's the confusion in the marketplace, because there are a lot of enterprises who aren't following these conversations along, and I can almost guarantee tomorrow they're going to go to the Oracle website, download the Java, and they're going to write an angry blog post or something. That's the confusion we're trying to clear up for the whole industry.
Smith: And unfortunately, the register can't run an article that says, "Java, now more free than ever," and have people click on it. Or, "Oracle does something good by open sourcing all of its commercial features." That also doesn't get a lot of clicks.
Hailey: No, it doesn't. And the other thing that's really important for this whole idea of free, this is free as in freedom, freedom to innovate, freedom to have control over the platform. OpenJDK has opened up Java. If you look at the way that the process now works for developing the language, developing the platform, developing new features, it's all done in terms of open implementations, open sharing of ideas and so on. So you can get in there, you can argue, you can say, "That's the wrong feature. You shouldn't do it that way. You should do it this way." So the whole platform is progressing in an open way. It's a much, much healthier way of doing things, and that's all because of OpenJDK.
Ritter: I think I'd like to add a little bit to that because I absolutely agree. We moved away from having the Java SE specification through the JSRs, the JCP, as being the driver of the features in Java. As Andrew said, it's moved much more to the OpenJDK, making it more open. We now have the idea of the JDK enhancement proposals, or JEPs, which is really the way that features are proposed and developed for Java. That's really good because it does allow anybody who's committed to the OpenJDK project to submit a JEP. So if you're a committer and you've got an idea for something then you can do that. I know that Red Hat's done several, Azul's done one. Even Google’s got one in JDK 12, I think, or JDK 11.
So, there is this ability to have a more open process. We do still have the Java SCX group, I represent Azul on that, which is necessary because we need to have a standard based on what's actually developed so that we can test against it, and there's also intellectual property rights, things that need to be dealt with on that. But it does mean that having a much more open development process is a really good thing from that point of view.
Smith: So basically the implementation at OpenJDK, the specification via the JCP, and we've gone very much to implementation precedes specification, which I think is the far better way to develop.
Hailey: This makes a huge difference. The idea behind the specification, basically saying that you can deploy it and see what happens, is a huge deal and it means that I can honestly say to everybody in the room, "It's your Java. If you want Java to be different, you can do it. You can get involved, you can change things. The platform can be what you need. It's up to you."
Verburg: Except for changing null pointer exception to null reference exception, which I've tried four years running and I still get told no every time.
Hailey: I cannot begin to imagine why.
Moving to OpenJDK and Managing Cadence Releases
Participant 10: This may feed into what you're about to do, but I feel like I'm missing bits of the puzzle. So a couple of questions and maybe someone could summarize what the advice is. Firstly, I'm under the impression that I am on the fringes of JVM use in my organization, so I may have some of this wrong, but I'm under the impression that certainly using the Java JVM will be much more expensive going forward than it has been. Maybe am wrong about that, I see a big frowning. And secondly, there is this release cadence coming up that, although I hear your argument about a lot of people moving quite quickly, you also said earlier that there are still people on 1.3, 1.4 and my impression is the majority of people are on 7 and early 8. So what is the advice in terms of moving to OpenJDK and managing cadence releases, if it doesn't seem practical for organization?
Verburg: I think I can summarize it pretty quickly. If you are concerned about having to pay money from day one to a vendor, just go with an OpenJDK binary. So either get OpenJDK binary from Oracle, get an OpenJDK binary from AdoptOpenJDK, get Zulu community, whichever one of those that you want to go for. They're all so alike, the differences are just absolutely tiny in all practical terms. Just go with one of those. Then if you want to pay for commercial support, all of the providers here will happily take your check, will take your credit card. No problem. However, if you don't want to get called out on day one, do not go to the Oracle website and just blindly download without reading the license agreement from Oracle, which is what a lot of people are used to. That's my only advice.
In terms of the release cadence, continuous integration is your friend. At my company we've already set up the matrix, we've built everything from Java 6 all the way through to Java 13, and with the modern CI tools, it's really not that hard anymore. So just a tiny bit of engineering on your organization's behalf, and you just really won't get called out. It's just a bit of discipline.
Smith: Just a quick comment on the release cadence thing, where you said, "Well, how are we supposed to keep up with the release cadence if people are still running 1.3 or 1.4" Well, the good news is, even though we have a new release cadence if you're running 1.3 or 1.4, you can still keep running 1.3 or 1.4. Clearly your defense in depth situation and your use case is such where getting the latest stability performance and security updates don't matter, and you can continue in that way if you want to. So don't let the release cadence mean you have to do something if what you've been doing before has worked for you. I don't recommend that. Believe me.
Hellberg: I would also add that there's one thing here which is about your patch maintenance regime and, what you're doing to keep up currency. But the other thing to be concerned about is that some of these technologies fundamentally need an effort and are tied to only being able to support certain amounts of the security protocol without that. So, SSL is over in terms of SSL2, SSL3. Java 6 is gone, so TLS 1.0. It could just barely manage that, 1.1. That's weakened. In a sense, you're now looking at Javas that really only are able to support TLS 1.2, to be able to move forward.
So there was a capability, well, I guess, is what I'm driving at in relation to all these Javas. Even if you were to say, "Okay. I think my platform is as secure as I can make it." There is a certain threat, just to see it merely coming because it's non-traced. There's a sense in which you've got to take that seriously. Even if you were planning on saying, "Okay, that server, whatever it is, 1.3, 1.4, 1.5, whatever it is, it stays in that nicely locked room." The problem is you're going to have to protect it with Bastion hosts if you are serious about being able to keep up with the security protocols.
In other words, it depends where you're going to draw your moat in your castle, what level are you going to pull that up to, because there's a sense in which we're not just talking here about vulnerabilities, or rather weaknesses that Java potentially has. There's a sense in which the industry has a practice whereby we are assessing the exploitability of some of these things, as to whether the threat and the damage that goes with it, that comes back to a thing like CVSS score. It's the regime by which we do it. And to be perfectly honest, we found out those who are still running Java 1, because POS Double, if you remember it going way back when, was so easily exploitable by absolutely everybody. Everybody came out of the woodwork at that particular stage, and it didn't matter quite frankly whether it was out of support at that particular stage. You had so many people hurting because the exploitation was so trivial.
So there's a sense in here where you've got to have a serious view as to what the entrees is doing for those things too, right. You've got to watch what keys and all that type of thing as well. So if you are planning not to maintain that particular software stack, that's a choice, but you really do have to worry about the whole of the [inaudible 00:48:50] area, and it's not just about physical security [inaudible 00:48:53].
Ritter: I think coming back to your question about what to do in terms of the new release cadence, as you were saying, I think what you need to be thinking is stick with the long term support releases because you want stability across a longer period of time. Find a solution which provides you with the updates for that long term support release so you get the security patches in a timely manner. But then because of the fact that we're gradually moving to the next long term support release, test where possible with each intermediate release, so that when you get to the next long term support release, you're already well tested and it's a very small move in terms of making the jump to the next long term support release.
Verburg: We've pretty much run out of time. Any very quick closing statements? Like 30 seconds each? No? Okay. Thanks, everyone, for your time, and don't forget to go to the social link on the website if you're looking for tonight's social event. Thanks everyone who turned up to the Java and JVM trek this year. It's been an absolute blast, so thank you for your attendance and hope you have a great rest of your QCon.
See more presentations with transcripts
