Learn from Java Champion Ben Evans: Beyond Java 8

In our special Java Daily edition, we’d like to introduce you to Ben Evans. He was kind enough to share his experience on 9 Java related questions. Ben Evans is a technologist, author, speaker and educator. He co-founded jClarity, an application performance startup (acq MSFT). He is a Java Champion and the Java/JVM Track Lead […]

by Dreamix Team

June 29, 2021

8 min read

Java Special Daily ben Evans - Learn from Java Champion Ben Evans: Beyond Java 8

In our special Java Daily edition, we’d like to introduce you to Ben Evans. He was kind enough to share his experience on 9 Java related questions.

Ben Evans is a technologist, author, speaker and educator. He co-founded jClarity, an application performance startup (acq MSFT). He is a Java Champion and the Java/JVM Track Lead at InfoQ. Ben is a best-selling technical author and an award-winning speaker on a wide range of technical topics including technical architecture, performance, concurrency, and related subjects.

Java Daily: Next Java LTS is almost here, but what is the adoption rate of the current one, Java 11?

Ben Evans: Java 11 has steadily increased in popularity since its release, almost 3 years ago. That increase has accelerated noticeably in the last year. At New Relic, we can directly observe the Java versions in use by our customers who choose to have their JVMs share that information with us. That information shows that we anticipate Java 11 to be almost 50% of the Java market by the time Java 17 LTS is released – it will just about overtake Java 8 by the time of the release.

Java Daily: Can the new Java LTS version replace Java 8 as a dominant one in the Java world?

Ben Evans: Java 8 is a solid release and many applications do not see the need to migrate from it. Java 11 LTS is also an excellent release, and I haven’t seen any serious problems migrating to it, provided that library dependencies are also upgraded when the JVM is updated.

I believe that Java 17 LTS will also be a very solid release, but I do anticipate that there will be some initial problems, due to the lack of availability of library dependencies that work with Java 17 (although there has been some great efforts by Oracle and the community to mitigate this possibility). So I think that after some “bedding-in” time, Java 17 will be an excellent choice for Java developers. I would not recommend trying to go straight from 8 to 17 – I would always upgrade to 11 first!

Java Daily: What is your most exciting feature of the upcoming Java 17?

Ben Evans: If we are talking about a feature that only arrived as part of Java 17, then I’d have to say Sealed Classes. However, I have been watching the version usage numbers for a couple of years now, and I have never seen any non-LTS release that ever scored above about 1.5% usage – so the vast majority of teams are only upgrading from LTS to LTS.

So, if we’re actually asking “What is the most exciting Post-11 feature?” then the answer, for me, is JFR Event Streaming. At New Relic we had support for this feature when it launched as part of Java 14 but because very few people use anything other than LTS it never got much usage. I can’t wait for it to be part of an LTS and start getting the recognition it deserves. I wrote about it for Oracle’s Java magazine, link here.

I will also admit to being a little disappointed by the incompleteness of Project Amber in this release. It’s a great thing that we have Records and Sealed Classes, and Switch Expressions, but the Pattern Matching feature is not really present at all (apart from as a tiny hint in instanceof). If the trends we’ve seen so far continue, then the power of this significant feature will not see widespread use until the next LTS – which is Java 23, in 2024. I think that’s a shame, and that it would have been better to delay the LTS version until a final version of Amber could have been included.

Java Daily: Is the Java module system already making some significant impact?

Ben Evans: Modules are a long-term, slow burn feature. I’ve shipped software based on them, and the feature really does help, not just in enabling things like jlink and native compilation, but also in making it easier to build well-architected services.

However, for many existing codebases there is no benefit, and only a lot of work, in trying to retrofit modules. Although, I would always advocate for greenfield projects – and especially new OSS libraries – to be modular from the start.

Java Daily: Can the Java module system be considered as an alternative to OSGi?

Ben Evans: No, not really. The Java module system is a fundamental part of the JVM that is also exposed to user space. OSGi is a purely user-level system, and it’s very clever but it has different goals, such as application servers and doing things like hot reload of services without the JVM existing.

Java Daily: What is your opinion about GraalVM JIT?

Ben Evans: We need to be very clear about terms. There are 2 separate things:

  1. The Graal JIT. This is an experimental JIT compiler for OpenJDK that uses JVMCI. It’s a lot of fun – it’s a JIT compiler so it turns Java bytecode into machine code. But it is itself written in Java bytecode, so the first thing that it does is… JIT-compile itself. This is a neat trick and has some advantages, but it never really reached production quality and it has a lot of additional memory and other overhead. So, whilst people initially hoped it could be used as a replacement JIT for OpenJDK that never happened – and in fact from Java 17 LTS onwards it is no longer shipped.
  2. GraalVM. This is a completely separate project from Oracle Labs. It is not based upon the HotSpot JVM from OpenJDK – and instead has different goals – running multiple different languages within the same execution environment and also native compilation of languages, such as Java, that are not commonly thought of as native-capable.

So my opinion is that I’m a bit sad about the Graal compiler – it was fun to play with – but there are only so many resources available for development of the platform, and so f there are bigger opportunities for performance enhancements elsewhere (e.g. Valhalla, Panama) then so be it.

GraalVM is interesting as it could provide one approach to shipping native Java binaries for cloud environments (and beyond). I’m sure that the Oracle folks have other ideas, e.g. using it embedded in their database, etc, but the cloud use case is the one that interests me!

Java Daily: Since Java 8 a lot of new garbage collectors have arrived. When should we consider different garbage collectors from the default one?

Ben Evans: Of course, in Java 11, the default has changed – in 8 it’s Parallel, but in 11 it’s G1. You also need to check the size of your containers. If you’re running in a single core container then you’re probably getting Serial – and that is almost certainly not what you want. I would always give a Java app at least 2-core containers.

Leaving aside that important detail, let’s look at what the different GCs offer.

Parallel is the most efficient in terms of throughput, but it is not a pausable collector – once it’s started a GC cycle it must finish it and cannot be interrupted. It is also, in most cases, at least linear in heap size – so if you have a 20G heap, the pause time will be ~10x that of a 2G heap.

G1 is an excellent all-rounder (and much better on Java 11 than it is on 8) – it is a concurrent collector, so you must run it on a 2-core (or more) container, as it needs to run concurrently with your application. It can do a bit of GC cleanup, then stop, then start again later. This means that as long as your application isn’t making a mess (garbage) faster than G1 can handle, then everything will be fine – your heap will never be 100% clean, but it will never have to stop-the-world.

Those are the defaults. In almost all cases I would stick with them.

CMS is, these days, a legacy collector to be used only in Special Circumstances (and it was removed in Java 14). Its main use case is for Java 8 apps, where the pause times of G1 cannot be tolerated. My general advice is that if you have performance requirements that are so sensitive, then you should try migrating to Java 11 and using G1 there before doing a lot of work with CMS. Let’s put it this way – when I was an independent consultant, there were plenty of high-paying opportunities that basically boiled down to “Make CMS behave itself”.

ZGC and Shenandoah. These collectors are designed to be low-pause at all costs. As the Shenandoah JEP says: “This is not the one GC to rule them all.” – such a thing does not exist. “At all costs” can represent a significant overhead – how would you feel about paying an extra 20% on your AWS bill, due to having to run extra, or larger instances due to the overhead of your GC? In practice, these collectors are very rarely seen – among New Relic customers, I think we see maybe 0.1% of JVMs who are prepared to pay the potentially large extra costs that these collectors can cause.

Java Daily: Project Loom promises to change the way we work with threads. What is your opinion about Project Loom?

Ben Evans: Loom is a really interesting project. I’ve been following it since the earliest phases of its design, and I think what the Oracle folks – Ron Pressler and his colleagues – have done is pretty awesome. I wrote about it here: https://blogs.oracle.com/javamagazine/going-inside-javas-project-loom-and-virtual-threads
I think my only worry is, again, about timing. We now have the finalized list of features for Java 17 LTS – and Loom is not on it, not even as Preview. So, I’m worried about the amount of time it will be until Loom sees widespread use – but then again, maybe Loom will be the spur to make developers start making more use of non-LTS Java versions.

The other thing that I’m keeping in mind is that I’m not 100% sure how much use end user developers will make of Loom directly. I can easily see that it will be used by library and framework designers, but what about day-to-day usage in vanilla Java code? I guess the old Wiliam Gibson quote from Neuromancer – “The street finds its own uses for things” is true here as well.

Java Daily: Favourite technical and non-technical book ?

Ben Evans: Here are my favourites:

  • Technical: Expert C Programming by Peter van der Linden. I first read this book as a PhD student struggling to convert FORTRAN-77 code into C. Experimenting with software turned out to be more fun than understanding the numerical models I was supposed to be working on. It is perhaps not surprising that I never finished the PhD.
  • Non-Technical: Homage to Catalonia by George Orwell. I can’t decide whether it’s Orwell’s instantly recognisable descriptions of Barcelona and Catalonia, where I have made my home; or his service in the International Brigades fighting against Fascism that most speaks to me.

Is there anything else you would like to ask Ben Evans? What is your opinion on the questions asked? Who would you like to see featured next? Let’s give back to the Java community together!

Innovators by heart. Developers by passion. We’re Dreamix Team - a group of trailblazing techies trying to make the world a better place through technology. We provide custom software development, keep you updated on market and industry trends, and have a great time doing it.