Transcript
Beckwith: I am Monica Beckwith. I am the JVM Architect at Microsoft, and been working with HotSpot JVM in the field of OpenJDK, and Sun JDK, and everything for a long time now. In this panel, I want to be talking about Java 17, and everything that has led us to where we are today.
O'Leary: My name is Kristen O'Leary. I'm a Senior Developer Relations Engineer at Google. I work in Google Cloud and I work on Java client libraries, all open source, all fun stuff, particularly on cloud native databases.
Ritter: I am the Deputy CTO at Azul. I'm Simon Ritter. I have been working with Java really right from the very beginning, because I joined Sun Microsystems way back in 1996, about the same time that JDK 1.0 came out. I've followed it all the way through the Sun years, the Oracle years, and now at Azul.
Preddy: A developer advocate working for Microsoft, who uses a Macintosh with a Chrome browser, who advocates Java. The irony is not lost on me.
What Is (JEP) Java Enhancement Proposal?
Beckwith: What is a JEP, the Java Enhancement Proposal? Because I know we will talk about JEPs here, how many JEPs went into Java 17?
Ritter: JEP is interesting, because if you look at the way that Java has developed, we have the Java Community Process. This was something that was started, it was probably around 2004, 2005 maybe, by Sun Microsystems. It was a way of trying to address the needs that developers had in terms of having a more formal standard for Java that wasn't necessarily just controlled by Sun. They started the Java Community Process, and we have what are called JSRs, Java Specification Requests, which are different aspects of Java. There's an expert group for that. I'm on the expert group for the Java SE standard, which was really the way that we used to develop the new features in Java. Because we've moved to an open source model with OpenJDK, what we've seen is that the developers want to have more contributions from outside of just a few companies. They created this idea of JDK Enhancement Proposals. JEPs are all about reasonable sized pieces of work that would take a fair amount of time to actually create, and anyone who's a committer in terms of OpenJDK, so it's not just Oracle, anyone who has committer status can submit a JEP and propose an idea for a new feature that will go into Java, whether it's in a language, whether it's in the libraries, whether it's in JVM. It's a 3-year plan for how Java can evolve. That's the best way of describing JEPs.
Java Release Cadence, and (LTS) Long Term Support
Beckwith: You talk about 3-year plan. There's also this whole release cadence, and recently, actually, there was a slight reduction in the duration of the LTS, I think. Kristen, would you like to talk about the release cadence or even what LTS means and where we are in our LTS cycle?
O'Leary: LTS is Long Term Support. What that means is every so often certain releases, 17 being one of them, is going to be supported longer than a non-LTS one. A lot of times, developers will choose just to pin on LTS versions, because they know it'll be supported in the long term. Then in terms of release cadence, it's funny, just anecdotally, I remember, I believe it was after Java 8 was released, the release cadence really picked up. It was much more frequent than I remembered before that. I do remember there was a big gap between 7 and 8, and then all of a sudden, it's like 9, 10. Now we're all the way up to 17. I want to say it's every six months. It's exciting to see so many new versions pop out more frequently, new JEPs getting released, whether in preview or GA.
Preddy: I think what happened was people got so used to the cadence, they said more, and they want those features out of preview and in their hands. Then Mark Reinhold actually said, this is working, let's just go quicker, and poor developers probably who were under Oracle were like, "No, please, just we're not managing right now."
Ritter: I think that because the switch happened at JDK 9, and Oracle will tell you that JDK 9 was the last major release of Java, meaning it had multiple years of effort behind it. We had long periods between different JDK releases, 6 to 7 was the longest one, I think. It was over four years between releases of Java. Now we're doing one every six months, which is really much faster than we've ever seen before. It seems to be working really well. One of the real benefits of that is the fact that we can have this idea of preview features where we introduce a feature but without making it part of the standard straightaway. Soliciting feedback, getting people's opinion on whether it works or not. Then still having time to make changes before it actually gets put into the standard.
Preddy: One of the things I really miss completely is in-lab events, and being able to do, and just have that vibrancy with the ecosystem. Right now, when I bring up code, there's not that same feeling that you have that, what IDE are you using? Are you using that IDE? Look what I'm using over there. There's a little bit of competition that developers have with it. I miss that greatly. Simon would bring up NetBeans, and I'll bring up Visual Studio Code and we would have that little like tease there. I miss that.
Ritter: I have actually made the switch. I've moved away from NetBeans. IntelliJ.
O'Leary: I'm IntelliJ also.
Beckwith: I'm still NetBeans. I love NetBeans.
Ritter: I love NetBeans. My problem is that it's not quite keeping track of the changes quite as quickly as it needs to. I was trying to use 17 features, and it's not quite there yet with NetBeans, so IntelliJ. I should try Visual Studio but it's a little tough.
Preddy: No, Visual Studio Code.
Ritter: Visual Studio Code.
Preddy: That's the smaller version of the monolith though, and we've just hit 1 million users. If you think about it, 6 million Java developers, where one in six of them use Visual Studio Code with Java.
Java 17 Preview Features
Beckwith: Simon, you mentioned about using Java 17 features. Were you talking about preview or you were just talking about one that actually made it into 17?
Ritter: In that case, it was preview features because I was looking at the pattern matching for switch. I'm doing a workshop and I was trying to test out some of the code I was using for that. I needed to be able to use that. It was like, yes, I'm going to use IntelliJ for that.
Top Features from Java 11 to Java 17-Plus
Beckwith: Rory, how about you? What features, let's start with 11, up until 17, and of course the preview, so 17-plus. If you had to list top three, what would your first one be?
Preddy: I'm all about the Benjamins when it comes to cloud. I work for a small startup out of Seattle, Microsoft, and we have a magnificent cloud. With that cloud, we have all of these features, and a lot of them are billed per second. When developers come to me, they go, that's great, make it quicker, make it faster, and everything. I've been following the garbage collections, and everyone has all of these metrics. The first thing, you want to know what a developer does, and all of the Java champions, they go, "I've got this and that and that. Then I make it go quicker," and everything like that. That's great and everything, but pop it on each cloud and then tell them how many milliseconds it runs. The biggest problem is that this all runs on containerized hypervisors. The garbage collector runs great in that, now pop it on a Docker, and a Docker, and a Docker Compose, and see if it runs there. We're still looking at how we can actually make better cost savings for our customers with all of these garbage collectors. I'm really following that that heavily.
Second of all, I speak to millions of developers who have just started with Java, and records is a great way to say we're sorry about the boilerplate. We know you can't let that go, but the getters and setters we got rid of them a little bit with records. It's a great way. I've been saying this ever since my cousin C# got getters and setters. I said to them we'll get it eventually. We got it. I'm really keen with records. Finally, also, I love the idea that the flight recorder and the profiler is included, as standard though. Java developers are only as good as the code that they're proud of. They should be proud enough to actually go in, look at all of their code and say, I'm using strings when I should use chars or lists when I should use these collections. That's a great, for me, an opportunity to improve the performance.
Beckwith: Kristen, how about yourself, any features that you would like to talk about?
O'Leary: I will bring up something else that I think is really just a nice to have convenience feature, the string formatting. Basically, let's say you're dealing with something like a JSON string, which is indents and many lines just to print out some blob, or object, or whatever, that can get annoying to paste into code if you want to just set it equal to a string. With the string formatting, you can do three quotes at the top, put in all your text, and then three quotes at the bottom, and it just looks nicer in your code. Again, this is probably anything related to performance or optimizations or anything. To me, as someone who reads code, I think it's a lot nicer. I think it's also going to come in handy a lot with things like unit testing, where you're parsing in mocks out JSON, something rather just to test your code. I definitely think it's worth checking out. I think it just makes the developers readable life easier, or someone who's reviewing your code. It's just as much nicer to look at and just is, I think, a really nice addition.
Ritter: Obviously, I reiterate what both Rory and Kristen already said. Records, it's just a great thing. I still struggle to think that we've taken so long to get the idea of a tuple in Java, and just the ability to represent something like that in a simple way. It's great to see records and make life a lot easier and reducing the amount of boilerplate code. I do like multiline strings or text blocks, as we call them, and the ability to make your life easier in that respect. The other thing that I really like is helpful null pointer exceptions. Again, it's like, how has it taken us 25 years to figure out that it'd be really nice to figure out where a null pointer actually happened, in terms of, is it a.b.c. whatever. That's nice that we now have that ability to see where the null pointer actually happens in a chain, of course. There's lots of nice little things that they've done in terms of making life easier for developers around reducing the amount of boilerplate code. Records is a good example of that. Pattern matching, and the introduction both with instance of and now as we've seen with JDK 17 in switch statements and switch expressions, as well. It's all things like that that just make life for developers much easier, removing some of those rough edges.
How JEP Gets Accepted for Release
Beckwith: How does JEP get accepted for next release? How is the project management for each JEP?
I can start with that. I know Azul also has contributed to multiple ones. There are a few proposals by Azul as well. The whole thing about JEP is that you have a project or you have a project in mind that you think you can contribute to. You can also go from mere discussion to actual realization of the project that you are proposing. For example, Microsoft, we proposed the Windows on Arm port. The way we did this was that we made sure that we had something working. We did our tests, so we had a CI/CD pipeline working. Then we went out to the community saying that, we would like to contribute this to the community, because we have products that will need Java to work on them, especially the Surface Pro X's. The community was very open in that they wanted something that would work, of course, on Windows on Arm, but also this big contribution that we had, they were very helpful in accepting it.
The JEP goes from the proposal state to various different ones, where it has to be accepted, it has to be proposed to target. Then it has to be implemented and then targeted. It goes through various phases. If you go to the JEP, I think we are at JEP 2.0. Please feel free to read about the different steps it goes through. Then right after that JEP was proposed, we also got this JEP from Azul Systems, which was actually MacOS on Arm64. Since we did the initial, making it more general code base with respect to Arm64, MacOS could be plugged in as well. That's one of the JEPs that made into Java 17.
JEP Proposals from Azul Systems
Simon, would you want to talk about the newer proposals that Azul has contributed to?
Ritter: JEPs are an interesting idea, because there's millions of developers who use Java. What you don't want is to suddenly make lots of changes to it in a way that affects things like backwards compatibility, and makes it harder for developers. The idea is that you have to be very careful in terms of the changes that you make. That means that when JEPs are proposed, you have to have a good idea of what's actually going to happen. It has to be done in a way that the rest of the OpenJDK community can look at it and say, yes, that actually makes sense. I think we were the first company to actually add a JEP, other than Oracle, to the JDK, and we literally added one method to the thread class. The amount of work that involved was really quite substantial. That was good, because you don't want people adding methods to thread or runnable or core classes, and just saying, "I think this is a good idea, let's put it in there and see what happens." We had to go through a number of steps to make that work. Really, the thing with JEPs, is you need to demonstrate that this will work. You actually have to come with code, not just an idea, come with code, come with the proof of concept, make sure that it all works, and you can demonstrate it. Then prove to people that that will actually work and can be taken into the OpenJDK as a whole. It's a nice process. It works well in terms of keeping Java moving forward, but not in a way that people can just throw ideas in and go, "Let's try this. Let's try that," sort of thing.
Java Upgrade Process and New Version Rollouts
Beckwith: Can we talk about the upgrade process and rolling out the newer Java versions to the dev team? I think that it depends on different organizations, and how the dev team likes to keep up with it, and the dependencies on underlying libraries and other API calls that they make, if they have moved to the next level or not. I think it ties into the next question, why are there so many orgs still at Java 7 and 8?
Preddy: I help advocate Codespaces. One of the features that Codespace has is Remote Containers. It's a feature that came there and GitHub Codespaces uses. What Remote Containers does is that it allows you to spin up a Docker instance, and you can test your instance. You can run an entire environment on it. GitHub Codespaces, you can go from 2 CPUs all the way to 32 CPUs. I'm drunk on power right now, because it means that I've got all of these projects on my GitHub repos, and I don't have to take my little MacBook Pro, and I don't have to install 30 different versions of JDK. Any time I can just spin up an instance, see what breaks, if it does break, and then bring it home to old Mackie here and say, "I know what I'm getting." We've seen a lot of movement into containers, making that life easier with testcontainers also. Why not just your entire environment and spin it up? Get started on that GitHub Codespaces now, and I can help you through that. It's just the way that we're moving there. Why do I have to work on one reproducible environment? I think I've got 7 JDKs on my MacBook and just floating around there, but probably about another 40 in GitHub Codespaces right now, which I don't have to worry about, they're cattle to me rather than petts. I love that.
Ritter: I think looking at the question there, so people are talking about still running JDK 7 and JDK 8. I know that we come across a lot of customers who are running older versions of Java. We support JDK 6, but we talk to customers who are still running 1.4.2, 1.3, which is a little bit scary. I think the idea is that you need to think about how to migrate the big switches from 8 to 9-plus, because you have to adapt to the idea of modularity. That does introduce some interesting things. It's more to do with the encapsulation of internal APIs that has an impact on how you can move your applications across. A lot of work has been done with that. Now people are really focusing on moving from 8, which is a Long Term Support release. They were moving to 11, which was the previous Long Term Support release and now 17 is the current Long Term Support release. It's this idea that we do have these specific releases that have extended updates available for them. Those are the ones that people who are looking for that longevity of using that particular platform, they're focusing on those. Not necessarily moving to 15, 16, 18, 19, and so on, but just focusing on those ones that do have extended updates available to them.
O'Leary: I think the important thing here, and why Java 17 in particular is so exciting is because it's LTS and I think we all understand and can empathize with the pain of I can't upgrade right now because XYZ. I've certainly been there myself in previous lives, and totally get it. I think that's why also it's just exciting to see that 17 is LTS, and with this increased release cadence, hopefully we'll get more LTS at this velocity.
Ritter: Yes, because that was one of the big changes with the release of 17, we've seen that Oracle has proposed, I believe probably now accepted, we're moving from three years between Long Term Support releases to two years between Long Term Support releases. The next one is going to be JDK 21.
Beckwith: That's what somebody was saying that by the time their org reaches 17, Java will reach its 100th version, which is weird. For the longest time, we were stuck on JDK 7, because I was always on the performance team, so keeping up with the next releases, as well as maintaining the performance and other things and relating performance updates. Those used to exist back then. Just thinking about how Java is moving faster than I can keep up with it is so surreal for me, as I'm working on the old team, got used to those things.
Ritter: I just worked out actually that in 2025 we'll have JDK 25.
Beckwith: I did not realize that Azul was the first non-Oracle company to propose a JEP.
Ritter: I think we should be fair there. I don't think we're the first to propose a JEP. I think we're the first to actually get one accepted into the OpenJDK.
It was interesting to see how much work was involved, which I actually think was a good thing, because it means that the governance of OpenJDK, and the progression of Java is very well controlled. We're not just adding things and throwing things in just because we think, it'd be nice to do this or do that. I do have to say that people like Brian Goetz and Mark Reinhold and John Rose, who are really the architects of the OpenJDK, they do a fantastic job in terms of marshalling all of these ideas, because people keep coming up with loads of great ideas. "Yes, let's do this. Let's do that. Let's include multiple inheritance. Yes, let's not. Let's include operator overloading. No, let's not do that." Things like that.
Java Preview Features, Incubators, and Deprecation
Beckwith: Simon, you mentioned about previews and incubators. Other than pattern matching, would you want to talk about some incubators that you have tried in the past, and they have changed or they have been removed because that has happened as well.
Ritter: We haven't seen any removed. I think that's probably unlikely. In an extreme situation, we could get to the point where a feature, really people don't like it, and so they actually remove it. Again, I think the architects are knowledgeable enough that they understand which things actually make sense. We've definitely seen the feedback from developers, has had an impact. If we look at something like switch expressions, that was the first one that came in as a preview feature. They suggested that for the combination of the old style syntax with a switch expression, it was to use break with a value which will be returned from the expression. It's overloading of the break operator, and it will work because you can break from a switch statement, you can break to a label out of a loop. A label can't start with a number, so you can use a break with a number to break out of a switch expression. People thought that was a bit too much overloading. They said, let's use something else. The developers went back and they said, we'll use yield instead of break. That does make things clearer. I think that's a great example of how feedback from developers has shaped the way that the JEP works in the end, a new feature works in the end. We've seen other examples of that with multiline strings, with the inclusion of a couple of new escape characters and things like that. It definitely works really well.
Beckwith: Rory, what about either the preview features or incubators or even the deprecation and removal of some features that were already there, for example, the RMI, or anything like that, that you would like to talk about?
Preddy: I was trying to think the last time I actually ran an RMI activation. The first time I actually used Java, CORBA was still a thing. We would create our ORB there, and I'd connect to a bank, and I would suck money out, and I'd do other things. I was like, "No, don't take that away. I made my living off that, don't take it away." When that left, I was like, ok, maybe that's a good thing. Then the worst thing ever was when getting rid of those XML binding libraries, because I didn't realize how many people actually were using them, and how many libraries, and suddenly Java 9 just murdered everything. I was like, we need to go to JSON. That set me back a long time. I'm sure there's still some libraries right now that are broken completely, by using that. People still on Java 8, and going, there's something going on there and happening there, and I can't move over. They are still breaking changes. I speak to customers around just all the way back from Java 8.
The RMI activation, it just brings back memories. It also shows me about the new RPC memory that we're going to include now. I'm very keen about that, because distributed versus localized and everything, it's like ebb and flows in PCs. You get a strong PC or a strong server, and we move from that, now we're going back to somewhere, and somewhere has memory, and we're going to go use its memory rather than localized memory there. Really keen to see what's happening up there. That means then an IoT device like here that might have memory, I can speak to it in Java, and I can get it to do stuff. I'm really keen about that.
Beckwith: The XML binding stuff, there are some benchmarks. People know about SPEC Benchmarking Committee, so their benchmark SPECjbb2015, and then SPEC SERT, and they had so many dependencies. SPEC SERT had a dependency on [inaudible 00:33:18]. It's always interesting to see how they break and how we adapt. The benchmarks are still there. They just adapted to the changes.
O'Leary: One that I can think of, which was a while ago, I was actually working on a talk for some conference. This was when 9 was, I don't think released yet, but it was just about to be released, so I was using it. Obviously, this was a while ago. I was doing where they change the reflection rules and what you could do with reflection, and what you were and not allowed to do. I remember on certain calls, the first time I was using a JDK 9 build, it failed, saying error, you can't use, I think it was [inaudible 00:34:13], or whatever it was. Then a couple weeks later, I was practicing my presentation, I must have gotten a newer version of the JDK. I assumed because of feedback, they actually softened it, so it wasn't a failure anymore, it was a warning. Where previously you had to manually override it in the command line saying it is ok, just give me a warning, don't fail, whereas they switched the warning to the default. I thought that was pretty interesting of how the strictness of these new rules around reflection changed, I presume, based on feedback and people saying, "We can't migrate our code that quickly. Stop failing on us. Give us a warning first and give us some more time." That's the one that comes to mind, again, a couple of years ago, but thought it was pretty interesting.
Ritter: That was actually why JDK 9 got delayed twice was because there was a lot of feedback on the effect of encapsulating the internal APIs and reflection. OpenJDK developers actually had to go back and say, yes, we're going to break too much stuff if we do this straightaway. It's interesting because JDK 17 has actually changed that slightly as well. They introduced what they call the big kill switch, which was the --illegal-access flag, which was introduced in JDK 9. The default in JDK 9 was to allow access, so you could still do all the things you could do before. Then in JDK 16, they turned it to deny, so that turned off access by default, but you could still turn it back on again. In JDK 17, they've basically made the illegal access flag now do nothing. They've restrained things even more. Some things are still available, like sun.misc.Unsafe, you can still actually get access to. That is one thing that is actually important about JDK 17 is that you need to test your applications. Because if they do use any of the internal APIs or reflection in a particular way, they may actually break now or not working the way you expect them to.
Beckwith: Kristen, when you mentioned about your presentation, I was doing a presentation on G1 Garbage Collector, and I wanted to be fancy and show logs. Prior to JDK 9, GC logs were pertaining to each garbage collector, and the verbosity would be like whatever the garbage collector wants to share. Then we went to unified logging, which is great, but it broke all my parsers and everything. I had this presentation and I knew exactly what I wanted to do, but I just wanted to show this print adaptive size policy, which is more verbose output of how the GC adapts. I wanted to show it in JDK 9, because it was the super cool thing to do. Then I was like, I don't know how to put. There is, of course, the log itself, but then the parser has to extract certain values from the log, and then plot it. That's what I was doing. It's interesting. It worked out really well in the end. The panic that I had, like, I have to change my parsers. These plotters were JFreeChart based and everything. Fun times. Unified logging is a big step in the right direction, although we do see things changing slightly, but I think the parsers are easy. I can use the same G1 parser for parallel GC and CGC and everything like that with very few modifications.
Azul Prime and Zulu
Ritter: I work for Azul, so we do Java, so either what we call Zulu, which is our build of OpenJDK, or what we call Prime, which is our enhanced build of OpenJDK that does high performance, low latency, high throughput type applications.
See more presentations with transcripts
