Transcript
Greco: This session is all about JDK choice and what's the criteria for making your JDK choice. This is planned to be an AMA, but it's not really an AMA - it's sort of an AUAJC: ask us anything about JDK choice. Before we get started on questions from the audience, let's go to Jeanne [Boyarsky], to Sai [Donthi], and to Simon [Ritter], and to Tony [Printezis]. Just introduce yourselves and then we can start.
Boyarsky: I'm Jeanne Boyarsky, I'm the Java track lead. You've been hearing from me all day and I work for a bank in New York City.
Donthi: I'm Sai Donthi. I work for a bank in New York City as a Java application developer.
Ritter: I'm Simon Ritter. I work for Azul.
Printezis: My name is Tony Printezis. I work for #twittervmteam.
Greco: And is what, co-author of G1, designer of G1?
Printezis: The first one. Original implementer of CMS.
Six-Month Release Cadence
Printezis: A different speaker this morning said during his presentation they've been having the six-month Java release cadence for a couple of years now. It's been fantastic. Who thinks that it's been fantastic?
Greco: This is the six-month release train. How many people like the six-month release train?
Boyarsky: I like it because Java is in the news more often and because it forces the three-year release train, which is the one I care about. I'm only going to use an LTS and knowing when that is coming is valuable to me.
Donthi: I like it, definitely, from an application developer perspective, because they get to be on top of what's happening new and also, we can catch up with other languages. From a firm perspective, it's not going to be helpful because it introduces a lot of new additional costs. Also, in a large firm, like where I work, it's not easy to change production systems.
Ritter: From my point of view, I like it because it's great for our business. Actually, I do think it's good from the point of view of having predictable release cadence and I think that we are getting features faster now. From that point of view, I do quite like it, but I do know that having that faster release cadence, as you said, a lot of organizations can't change JDK every six months. That's just not practical, so it is going to be a challenge for a lot of people.
Printezis: I agree with that. Six months I think is a bit too fast. I think at Twitter we are able to move a little bit faster than a lot of other organizations, I would claim, but we still cannot move to having every release every six months. One year will be a hard sell, a year-and-a-half maybe.
Choosing a JDK
Greco: You work in a major organization and your manager says, "We have to choose a JDK." He says, "Please choose a JDK for us." What do you do?
Boyarsky: My company cares a lot about paying for long-term support using both definitions of the word support, which limits us to one of several companies. Currently, we're still using Oracle because we had a long support contract and it hasn't come due yet. The next time it comes due, we do have to start thinking about that decision of does it make sense to stay with the one we're on, or change? I think the things we're looking at are first of all, what kind of support is given, and does it match what we need? Because we care about both patches and being able to go to someone if we have a problem.
Then we would look, as a secondary factor, to cost, both per developer seed and per CPU. Oracle charges a very small amount per developer seed and a very large amount per CPU, and we would need to see where we stand on that and how it relates to what other vendors provide. Additionally, with the introduction of cloud, Oracle's JDK is extremely unfriendly when you try to run it in something like Docker, and that's an increasing concern for us.
Donthi: From my perspective, within the firm that I work, there is a very centralized Java platform. Pretty much every application Java developer will use that particular platform to build their code and deploy to production, which means all the development teams get the support for free. They won't have to spend individually from their line of business or the budgets. There's a central team that takes care of this. That also means that if there is a change that has to be done, the central team will take a year or two to get there. We are not in Java 9 yet in production through the central team.
Greco: Nor should you be.
Donthi: No, I'm clear about it. We are still in Java 8 from the central team.
Boyarsky: Yes, but you're going to go to 9? You're not going to turn to 11?
Donthi: That's right, sorry. Yes, we are going to go to 11 directly. On the other side, there are a few teams who are experimenting with the latest Java versions directly, but then that comes with the responsibility that that team takes total responsibility for production support and signing a separate contract with Oracle, which they don't want to do obviously. With that, within the firm that I work, it is going to be from one LTS to another LTS.
Greco: Sai [Donthi], just one point on that. If you have different groups that have different support contracts, does that mean one group would have an Oracle contract, and one group would have - not that they would - an Amazon contract?
Donthi: Yes. Actually, that's true. Simon Ritter will be very happy as well because we are their customers. There are groups within the organization which use Azul because of high performance, so there's a separate contract with Azul for that team, specifically.
Greco: Certainly, Azul is really good for the low-latency applications. For, say, general-purpose computing, is it typically the Oracle contract or is it other vendors?
Donthi: I think the majority would be Oracle contracts. Other than that, if a particular team needs a separate JVM for specific purposes, then they would go out and sign a separate contract with the company.
Boyarsky: I thought of one more thing whilst I was talking that's really important, which is the length of supporting a JDK. We are just getting the tail end one of our applications off Java 6 now. While most of the JDK commercial companies still support Java 6, not all do. That's something to look at to make sure that we're going to have Java 7 and Java 8 support for a really long time.
Ritter: Actually, I believe we're the only people who still support JDK 6.
Supporting the JDK
Participant 1: You're all talking about supporting the JDK. It's fine but can you just illustrate a case where you really needed to have support on a JDK?
Ritter: I can give you an example of that. This is where we talk about the difference between maintenance and support. Maintenance is the idea of providing the updates, backport it from the code that Oracle contributes to the most recent release. Support is where, like you say, you have an issue, you ring up somebody and you say, "Look, something doesn't work, and we need it to be fixed." I can give you a good example of one that we dealt with. One of our customer is Workday and they deployed the JDK into their environment. They actually experienced a problem which turned up in a certain situation. They reported it through the open JDK bug reporting mechanism and Oracle closed it. It could not reproduce because it was a very complex environment, that they needed to actually generate that.
What our engineers did was say, "Ok. We will try and fix it." We were faced with quite a difficult situation because Workday, obviously, have a lot of proprietary data and they couldn't just give us access to their machines. We had to either use heavily scrubbed log files or we had a webcast type interface into their system where we could get very minimal information. We were able to actually figure out what the problem was and then generate a fix for that. But you're right, the number of people who actually find problems in the JDK that need fixing, which are not dealt with through the OpenJDK and Oracle, are quite small. If it is something that affects you, then it could be a significant thing.
Printezis: We have a slightly different scenario because we have our own VM team, so we support ourselves. My team's customers are actually our Twitter developers. It's not common, but quite frequently we'll have some issue in production, like the service hitting some edge case in either the libraries, or in the GC, or in the VM. Having some expertise to go there, understand what's going on, maybe add custom observability or custom observability features to try to work out what's going on and then going to fix it, is actually valuable for us. Smaller companies maybe cannot afford to have a VM team, but having somebody that can do that - you're welcome, Simon [Ritter] - is really important.
Greco: That's interesting. On the panel here, we have two people from companies that are users of JDK. We have a vendor. Then, Tony [Printezis], you guys decided to roll your own, right? What was the rationale?
Printezis: The decision was made before my time, I joined the team maybe about a year later. That was almost six years ago. I can probably imagine how the conversation went. It was, "Twitter is getting bigger. Move to the JDK. We would like some support," for the reasons I just described, actually. "Ok. How much does it cost?" Then you get an estimate. We have several data centers, thousands and thousands and thousands of machines per data center. Unfortunately, I can't disclose that number. I'm sure the bill has been quite astronomical.
They said, "Maybe we can hire some engineers and OpenJDK contributors to actually maintain it." Six years later, it's been working great. In fact, now that we'll have to be more active in supporting our JDK and doing a bit more work than we did before, it has actually now become even more important. Just as a summary, cost is definitely important. I still need to do the calculation of how much it would have actually cost to get support for a year given the number of machines we have, and then how much our team costs and maybe ask for a percent of the difference.
Cost is important, also speed is important for us - speed as in there is an issue, we're there, we're on call. We can immediately answer it, and we have the expertise to resolve issues and understand what's going on and try to help out developers. Once, when some team hit an issue in production in the JDK, and the issue might not might have been our own fault - I will not confirm that - we literally had a new release of the JDK within a couple of hours. That resolved the issue. I'm not picking on you, but I don't think you can get such a fast turnaround from a vendor.
Criteria for Choosing a JDK
Participant 2: Historically, we have just used OpenJDK for years and never had to use support and stuff like that. I'm trying to understand and get an overview of other than support and the costs behind that, what are the alternatives and considerations companies need to take when they choose the JDK provider?
Boyarsky: I alluded to one earlier, which was performance. Another one which is low-hanging fruit is, if the provider you’re using for something else is providing a JDK, so if you're on Amazon, you should probably use their JDK. In a lot of cases, it probably won't matter, and using a common one makes sense. If you have a special use case, you probably know about it already, or you will encounter it and then you'll know about it. I'm curious to see what everyone else thinks on this one.
Ritter: The key thing that's really affected this whole decision process is the changes that Oracle made around about the time that JDK 9 came out. In addition to saying that they were moving to a six-month release cadence, they also said that they were going to stop doing long-term support for free. Long-term support from Oracle is only for the Oracle JDK. OpenJDK doesn't have the concept of long-term support. I'm actually in the process of writing a blog post about this. OpenJDK is the source code for the JDK.
Depending on who is the project lead for each project, there will be support for a period of time if somebody wants to lead that project, because Oracle now resigned the leadership of the project after six months - every project. Then it's up to somebody else to take over. In the case of 11, Andrew Haley of Red Hat has taken over. He also did the project lead for 8. He was the project lead for 7 and in fact, he was project lead for 6. He then resigned from that and Andrew Brygin took over from Azul to be the project lead of that. That's how we were able to still provide support for those.
The key thing now is deciding where you get your updates from, because the updates are the key thing. If you want to carry on using JDK 8, you certainly can because the license allows you to use it for free, but Oracle is not providing updates to JDK 8 unless you pay them for a Java SE subscription. The question is, who do you go to for your updates? There are a variety of providers. Obviously, there’s Azul, we do that as a commercial business. There's AdoptOpenJDK, jClarity. There's IBM with J9, there's Red Hat, there's Amazon. It's surprising, there are actually people who are popping up who are providing support for the JDK. Pivotal is one who came out recently. Alibaba has a JDK that they provide support for. There are a couple of Russian guys as well who do it. There's actually a range of different JDKs that you can choose from now. The idea is that they're all building mostly from the OpenJDK source code. The question is how you get the backporting of the fixes into that particular version.
Boyarsky: Talking about the vendors, at Code One last year, Red Hat got up and talked about how they were leading the support of everything, and then IBM announced they were taking over. Do any of you know if that's going to continue?
Ritter: One thing we need to be very careful about here - and this is something that is quite precise - is Red Hat is not the lead of the project. It's Andrew Haley who works for Red Hat. It's actually important to make that distinction because the OpenJDK is a project that has contributors to it. Even though Andrew Haley works for Red Hat, he is not actually representing Red Hat in that capacity. It's not Red Hat who is leading it, it's Andrew Haley who's leading it.
Ensuring Compatibility
Pepperdine: We have all these sources for OpenJDK, and this is a question we keep running into: how do we ensure compatibility from each of the sources right now? Because effectively, we forked - or haven't we? Opinions on that? Have we forked? - I think Twitter has forked, Alibaba has certainly forked. Has Amazon forked? Has Azul forked?
Ritter: Effectively, yes.
Pepperdine: Is a TCK actually adequate to prove compatibility anymore? And if so, where do we go next?
Boyarsky: I have a follow-up question about defining fork because some of these forks don't have a future, in that Azul has their Java 8. They're not building Java 9 on top of Java 8. They're maintaining it until eventually, Java 8 goes away. So those forks are less worrisome than something like the Hudson-Jenkins split. Can you be precise?
Pepperdine: Every time they patch a problem in Java 6, the question is do they port that patch forward to Java, whatever? Does that patch actually get contributed back to OpenJDK so that it becomes part of the base? Not Azul, but this is a question for across the board.
Ritter: I'll have another go answering that one. The thing that we're looking at is the eventual consistency. To give you an example, Azul independently backport fixes from the current release into older releases because we have an SLA that we provide to our customers that says that within a certain time, we will ensure that you have those updates. We can't rely on OpenJDK to do that for us because this is an open-source project, so we don't know who's going to do it. Sure, Red Hat does it, but we can't rely on that, so we effectively fork the JDK to backport those fixes. But once other people do that and the fixes are upstreamed into the OpenJDK project, then we will effectively abandon that fork and we will go to using the standard OpenJDK project. That's what I say about eventual consistency.
Pepperdine: That's a backport of the fix. What about the fixed back that's not pushed forward? Backporting I understand. Upstreaming is the issue. You find a problem that sticks that really hasn't been found in 9 or 10.
Ritter: Right. What we do with that is, because we're maintaining 6, we will actually upstream it into 6 and then we will look at whether it affects later versions. Then the idea would be to try and contribute that to the other newer versions.
Boyarsky: I'm going to add to that from the customer point of view, that this seems like an issue that I'm unlikely to care about. I care about fixes from the point of view of I'm on the latest with respect to security holes, and I believe that everybody is fixing the security holes in their fork, I hope. If I personally encounter a defect at my company that's being fixed, I care that that's fixed, and that I'm going to be on top of to make sure it gets ported in.
Ritter: Security is a little bit of an easier thing. From a consistency point of view, security is easier. The reason I say that is because there is the OpenJDK vulnerability group. That is the group that was started by Oracle, which also has a number of other JDK, JVM vendors involved in it. You've got people like Twitter, you've got people like Azul, Red Hat, IBM, all the usual suspects are there. The security fixes are actually developed within this group. It's not just Oracle who is developing the fixes and testing them. It's the whole group that's doing that. Everybody who's basically building a JDK has advanced access and advanced knowledge of what's happening in terms of security fixes. Pretty much all the vendors are going to have the same thing, the same baseline, in terms of security patches when the next update comes out. It's more the bug fixes that are a little bit of an issue in terms of backporting and so on.
Boyarsky: Security fixes are what get me to update every quarter. If there was a bug fix, I would call whatever the behavior was. "That's how Java 8 works," and deal with it until it's time to upgrade again, but security I have to upgrade for.
Pepperdine: We've had experiences where moving between different VMs actually creates things where all of a sudden, your memory is inflated considerably or you have other performance regressions because it's in a particular environment, because you're using particular features and things like that. These are things that are absolutely not caught by the TCK right now. The question comes back to, if we have forked, how do we really ensure compatibility because I think you want to make sure that your application behaves the same way if I go from one fork to the other?
Ritter: The TCK is a lot of tests. There are 150,000 tests in TCK. What it does is it tests compatibility from a functionality point of view. It's a functional set of tests. What you're talking about is non-functional. You're talking about memory, memory usage is non-functional.
Pepperdine: That was an example, but there are all kinds of other things that we talked about.
Ritter: TCK, we're testing its functionality. From a nonfunctional point of view, that's open to interpretation because of course, the JVM spec says you have to do certain things. It doesn't say how you have to do them. There's a lot of leeway there for how things actually happen. I don't think there's an easy way of actually being able to define a test suite that would test non-functional requirements because the fact that it's ambiguous in terms of the spec.
Boyarsky: Wasn't this always a problem? IBM had a JDK in Web Co35 that certainly behaved differently from the Oracle JDK, and I know because my automated builds would be different.
Ritter: Yes. I was going to say, the whole point of building Zing was to make it behave differently.
Participant 2: I get, from this discussion, how a good actor in the community would be behaving in terms of - there's an issue found, we put it in our own supported JDK, and then we backport the fix upstream. Then from there, hopefully it gets backported to the older versions. But maybe for Oracle's case, do we have any insight as to what the heck they're doing? Because they're basically creating their own fixes and then not open-sourcing them after the first six months of support have gone away. Now it's up to the community to maintain. How are we going to get to eventual consistency there?
Printezis: That's not true, though. They do open-source them. If they don't open-source them, they release the one that you want. If there is an issue, they eventually will push the fix to - what's the current...? - the 13.
Participant 2: Yes. Bleeding edge. The problem is backports don't always backport cleanly, right?
Printezis: Absolutely. That's a problem. Eventual consistency could be on the latest Java, but maybe not 8. Kirk [Pepperdine] is probably right. Probably half will fork.
Boyarsky: I think it's a problem. I think it's a question of how significant is it of a problem? I suspect it's a bigger problem in the ecosystem that Kirk [Pepperdine] lives in than the ecosystem that I live in, just because you're dealing with lower level stuff all the time.
Ritter: One of the problems that we face as well is that because Oracle only contributes the source code patches to the current release of the JDK - at the moment that's 12, and will shortly be 13 - what we can do is we can take those source code patches and we can then backport those two older versions. That sometimes is harder than it might seem because, of course, things change. Backporting those fixes can get harder the further back you go.
We also face another big problem which is that since JDK 9, Oracle has started removing things as well. That becomes a problem because if something doesn't exist in JDK 12, there will be no security patches or updates or bug fixes for that, so there's nothing to backport. It makes the problem of how to address potential security flaws and bug fixes harder the further forward we go, because of this issue of the fact that things are being removed. If you take JAX-WS for example, that's gone. If there's a bug found in that, Oracle is not fixing it, so somebody else has to fix it. That's the thing that is going to cause more issues as we move forward.
Pepperdine: Are we saying that we're almost viewing an end state of this ecosystem of eventual consistency outside of Oracle and Oracle is out in the heavens doing what it wants to do? Because that's basically what we're talking about here - long-term supported versions of Java. There will be times where you have no reference implementation of a security fix and then somebody will have to create that. It doesn't sound like Oracle is going to consume that from the open-source world, because they'll already have it built in their own way. I'm not sure what the state here is.
Ritter: Yes, as I was saying, I think these security issues for the current release are reasonably stable. But for older versions, where things disappear, that becomes more of an issue. You're absolutely right that we have to address that in some way.
Boyarsky: Is Oracle not a member of that security group? Because Oracle still has to patch their Java 8 and Java 11.
Pepperdine: But they are not open-sourcing that.
Boyarsky: I'm not asking about that. I'm asking about the private security group that the vendors are a member of and talking on.
Ritter: I suppose, because this is only something that's been going on for a short space of time, we probably haven't hit any situation like that yet, so it's not clear what would happen. I know that there has been some discussion. I think I can probably say this without revealing too much. For example, JavaFX has come up as something where some people have identified some things that need to be addressed, and so there's been a discussion around that. That is something which is no longer part of the Oracle JDK. Hopefully, that will be resolved.
JDK vs. JVM Compatibility
Participant 3: What is, in your perspective, the bigger problem, JDK compatibility or JVM compatibility? Because there are 10 vendors of JDK and 5 big JVMs in use. One access has different JDKs, where there are many forks. The other issue may be that there are multiple Java Virtual Machines, such as OpenJ9, the one from Azul, HotSpot from Oracle, and probably a few others.
Printezis: I think that's it right there, only three, but we can include Graal too. One of the differences between the JVMs is that the code base is largely different. Zing used to be once upon a time a HotSpot, but it has forked dramatically from it. The JVMs are basically more or less rewritten from scratch, where probably the OpenJDK libraries are probably based on the same code base. I would say it's harder for the JVMs to ensure compatibility.
Ritter: From a JVM perspective, you've really got two things. If you look at Zing from Azul, then what we did was we took HotSpot as our source base, and then we've replaced certain things in that. For example, we took all the garbage collectors out and we put in a thing called C4. We took out the C2 JIT compiler. We put in a thing called Falcon. We replaced certain sections of that.
The IBM side of things is completely different because that's a clean room implementation. The idea was that their engineers didn't look at the source code for HotSpot. They simply worked from the spec and built the entire JVM from scratch. From a compatibility point of view, that's where the TCK comes in because they test against TCK to ensure that functionally, the execution of byte codes work in the same way; the way that things are supposed to work from a JVM perspective, functionally works.
From the rest of the JDK, so JDK compatibility, I don't believe there's anybody who doesn't use OpenJDK as their source code base, because it was a new classpath. They tried rewriting their own libraries and that became Harmony, and that all disappeared. From the rest of the JDK perspective, it's just down to whether there are issues with backporting and fixes being done in a slightly different way.
Actions for When a New Version of Java Comes out
Greco: What happens when a new version of Java comes out, or a new version of Graal comes out? Tony [Printezis], you guys use Graal in production, right? or semi-production?
Printezis: We use it as a JIT.
Greco: I think it'd be interesting to find out what happens inside your companies when a new version of Java comes out? What exactly happens? What's the decision tree? What are the actions that take place? Not just roll out, but education and support? What happens? 13 is released, what happens? Does anything happen? Is it a regular train that's coming or is it a bullet train that's coming?
Boyarsky: I work on an express stop. When 13 comes out, literally, nothing happens. When 11 and 17 come out, something happens, and that's when the developers start looking at it, and we have some lunch and learn, and we start talking about features. What are the business drivers for wanting to upgrade? Is there something that's going to make things more efficient, like in Java 8, or is it that we're upgrading because we need to get off of Java 6 before it expires? We use that as input when we're talking to the business and the product owners about when we want to upgrade. Then we use the long-slow process of actually doing so.
Greco: What's the latency? You do all that work, the release comes out and you actually do a rollout? You make a decision? Is it days, months?
Boyarsky: It's not days and it's not weeks. It could be months for early applications. It's definitely years for later ones. Remember, we just got off Java 6, for the very last application. Remember, financial institutions are extremely conservative. You don't want them to lose your money.
Donthi: From my experience, what I've seen is when there's a new Java version, as I was mentioning earlier, there's a central team that will take a look at and then decide if the entire platform has to be upgraded to the new version or not. Secondly, all the applications are sent a list of things that will work or will not work. We're supposed to actually assess it and ask if a business application is implemented by that?
If so, there will be funding and sourcing discussions happening and you would submit a budget request saying, "This application will not be supported if this version is coming in." So we'll have to cater to this in terms of people and the cost that's required to upgrade the application. Then, if the decision was made to upgrade the Java JDK version, then that starts a developer evangelism, I would say. You would have people giving talks and then explaining how to utilize new features. That's increased, and then we do utilize a lot of Pluralsight and other platforms for the educational perspective as well. It definitely takes more than a year, I would say.
Boyarsky: One other thing. When I said months, those are only internal applications. We wouldn't do anything outward-facing within that time period. Then we're going to be very safe and careful. It's things like the cafeteria app and the rating system, and things that aren't going to be a big deal if they go down sooner than we do.
Updating the JDK
Greco: We have Simon [Ritter] and Tony [Printezis] - both vendors, internal and external, right?
Ritter: Yes. From my point of view, a new release of Java is just more work because we have to build a whole bunch of new versions of Java. I do have a question, actually, because we’ve got two people who are heavy users and conservative users, shall we say. One of the things that Oracle is pushing quite hard at the moment is the idea of continually updating the JDK, maybe not in deployments, but at least from a point of view of testing, so that when you go from 11 to 17, for example, you will have already tested with 12, 13, 14, 15, 16. You've done incremental advances, rather than doing a big 11 to 17 test and deploy. Is that something that you see would actually work for you, or is it just completely unrealistic to be able to do that, and you're going to go 11 to 17 as a big jump?
Donthi: I think the latter works for us. It's going to be 11 to 17. I don't think there will be effort put into doing 11 to 12 to 13 through that chain.
Boyarsky: Yes, same here. I was at Code One, I understand the benefits of going incrementally so you know what your problems are, but we're not going to do anything about them, so it's wasted effort. It's easier to let the community as a whole do it. I also want to speak for Coderanch because you mentioned that we're both conservative institutions. Coderanch is a forum, if it goes down, it's not a big deal. Our upgrade cadence there is when someone feels like it. It's not every six months, but it's not every three years either.
Printezis: At Twitter it's up to #twittervmteam to drive the move to the latest release. We've been on 8 for a while, so we are currently in the process of moving to 11. Simon [Ritter] was correct earlier, that the LTS concept is an Oracle concept. It's not on OpenJDK because with OpenJDK, you only get six months of updates. There are some advantages to be on an LTS, because maybe a lot of libraries will be only kind of LTS-compatible just for practical reasons.
For now, at least we're doing 11 because it's LTS and we are trying to test the first services with 11. A lot of them came up working okay. Some of them we had some issues with stuff that was removed and we're looking into dealing with those. We're working closely with our libraries team that writes all the libraries that most of our services use, like Finagle, which is our sequence RPC and a few other things, to make the changes to be 11-compatible.
After that, we're going to start moving services one by one to 11. When it's done, 8 is done. We don't have people lagging back to three releases. We try to move everybody to the latest one because we're a small team, and also the CSL team, which is the team that supports Finagle, is also a small team. They cannot support many, many releases, so we need to be on the latest.
Participant 4: Just out of curiosity, for the jump from 8 to 11 - because 8 is about LTS - is the primary blocker the compatibility, the breaking changes and stuff, or is some of that figuring out the support model now? What percentage? What is it, all one, all the other, or somewhere in the middle?
Boyarsky: For me it's what's the driver? From 8, it was easy to sell. We can develop faster, we've got lambdas. Even with Java 5 it was easier. With 11, there are a lot of new features, but there's not one that you can point to and be like, "That's why we want to upgrade." It turns into, "We want to upgrade eventually because we should." Because we're skipping 9, there are some changes that we need to think about even if we're not doing modules, like the changes to the directory structure or the JDK. It's a bigger upgrade, there is no urgency to start. There's not this list of things, but we'll do it eventually.
Donthi: I think, for us, to your first point, consistency is important. We will first want to test it if the application is working as is with current state, but then from a conversation perspective, the financials come first. The contracts happen first, and then the developers would get information saying that, "We do have a long-term support contract with Oracle now for the Java 11, so you guys can play around with it."
Boyarsky: I just want to answer the second part of the question about vendor support. We're both working for companies that pay for commercial support. It doesn't change if you're paying for commercial support already. There are now more vendors that are providing some commercial support than there were a few years ago, so you have options at renewal time. But the commercial model hasn't changed between 8 and 11. It's just the version number that you're on.
Ritter: I think the jump from 8 to 11, certainly in terms of talking to a lot of developers, one of the things that people are facing is the move to modules. It's not so much the fact that the JDK itself has been turned into a bunch of modules. It's more the fact that libraries and frameworks have to work with a module system, and specifically, the issue of the encapsulation of internal APIs, which means you have certain online flags that need to be set and things like that, which are causing some issues. A lot of the libraries now are gradually moving to that, so it's becoming less and less of an issue to move that. It's probably 50/50 as to whether it's a technical issue or whether it's a licensing support issue, and the move from JDK to JDK 11.
Printezis: For us, it's just a technical issue.
Faster Release Cycles
Participant 5: I want to go back to the cadence release, the six-month release pieces, and talk about the general market, developers who do not work with low-level virtual machine stuff, general, developers. I'm from Houston. Houston has more .Net presence because of the whole industry. Java developers are far and few between. With that being said, at least I have not come across developers who pay more attention beyond Java 8. That's what I've seen, unless other people see other things in the market.
With that being said, other points that I see: I have transitioned to do some front end development. I don't think so far we have talked about it in this talk. Last year, I transitioned to starting to use React, and I've been doing Java for about 15, 16 years. My perception is this cadense release of six-months is heavily to compete with Node, where Oracle lost Enterprise Java for whatever reason, and now they want to keep Java in the market. I'm not talking against Java, I'm still a Java developer, but general developers are not moving at the fast pace at which Java is moving.
This morning, I attended a session with Java about new features in Java. Most of the developers I come across do not even know about these features. They do look like syntactic sugar, the switch case and all these things, which is almost like year six, year seven, and whatever the hell all that is. I want to know everybody's opinion on that.
Boyarsky: I'm bursting with energy to answer this. There are a lot of parts to that question. First of all, there were a lot of reasons behind the increase in the release cadence, and a few of us have given flower presentations on it. But it's not about competing with Node; it's about improving Java. Some of the features that Brian mentioned are syntactic sugar or candy, if you think of them that way, but some of them like fibers are not. Fibers are completely functional. Some of the things that are syntactic sugar are copied from other languages, some of them are new to Java. It's a whole range of things.
I also want to comment about the "we're New Yorkers" thing. If I was working for a company that didn't pay for extended support, I would stay on the latest version of Java and upgrade every six months. I think that is a viable model if you're not working on something that's that mission-critical.
Printezis: Not everything is syntactic sugar. Fibers is one, also Valhalla and Panama are going to be very important and very useful changes moving forward, but they're taking a long time because they are very complicated.
Ritter: I think that what we're seeing at the moment is with a faster release cycle, there's, as you said, a lot of smaller features being delivered more quickly. The appearance we're getting at the moment is that there's not as much happening in some ways. But the idea of things like Valhalla, things like Loom, Panama, it means that there are some very big changes that are going to hit at some point in the future.
That's going to be that shift that we got with JDK 8, where suddenly we got lambdas and streams, and everybody went, "That's really cool. We want to use that." That's going to be the driver to get developers interested in moving to 16, 17, 18, whatever version it comes out in. On the enterprise side of things, that's a whole another discussion. We need another hour for that.
Boyarsky: I just want to say one more thing. If you look back to Java 1.4 or 1.5, it took developers years. I remember when 1.6 came out and I was still convincing people they should use regular expressions. I remember when 1.7 came out and I was still convincing people they should use generic. I don't think the idea that people aren't using new things yet, and some of the things Brian talked about haven't even been released, are significant. The other thing is, if you only look at the LTS's, you're not really at a faster release cycle. You're at a more predictable release cycle. That's something that's really important. We're getting insights into it every six months, but we're not all sitting here upgrading every six months.
Greco: The other thing is that JavaScript frameworks have updates every week. Every day. Is that a good thing or a bad thing? The world is different now and it's not just Java and JavaScript. The world is different. We have to move faster. It's just a fact of life. It's not necessarily competing with Node. It's just adapting to the modern world.
Participant 5: I wasn't specifically saying competing with Node, but that was one of the things I thought might be the case. I don't think all the developers are moving at that pace.
Greco: Sure, I agree. That's just the way it is.
See more presentations with transcripts
