You are viewing content from a past/completed QCon
Session

Starting Fast: Investigating Java's Static Compilation Landscape

What You'll Learn

1Find out what are some options to start a Java application faster.

2Learn about Graal Substrate VM, Quarkus, Project Leyden, and others, how they can help starting a Java app faster.


We've always wanted fast startup for our applications but the meaning of "fast" has changed radically with the cloud revolution.  This increasing focus on fast startup has put greater pressure on the JVM to start faster and has driven the Java language to look at ways of delaying operations until they're needed.  New frameworks like Quarkus are changing how we develop applications by moving work from runtime to build time. No more classpath searches during startup to find annotations.  But that's not the whole story, Graal's SubstrateVM compiles entire applications into compiled images and OpenJDK has announced Project Leyden to focus on the statically compiled Java space.  What does this mean for you as a developer?  And for your application?  Find out why your technology choices today may affect the success at adopting these options.

Who are you targeting in this talk? What's the level that you're expecting to kind of hit on?

Definitely the architects and the senior developers: people who are deciding what the shape of the application is going to be in the future, how they're going to deploy it, how dense you can get your application, really how much memory it's going to take to deploy it, and all the characteristics that go into doing that deployment.

What are some things that you might recommend for someone to look at first?

To be well prepared for it, I think it makes sense to take a look at frameworks that are using Graal SubstrateVM. So take a look at Quarkus, take a look at the Micronaut, understand what's different about those frameworks compared to the traditional Java EE frameworks. And then if you really want to get in-depth, take a look at the Linux CRIU (Checkpoint Restore in Userspace) project, which checkpoints a Linux process allowing it to be restored from that point later. That will help lay the foundation for looking at what goes into making Java fast and ways that it may evolve in the future.

If I'm a Java developer, and come to your talk, what will I walk away with?

A sense of some of the pressures that are on the Java ecosystem. Everybody wants their application to start fast today. We've gone from wanting Java just to be fast, and now we want it to start fast as well. That puts pressure on the language and how the language evolves, how the VM evolves, and then also how the frameworks evolve. The ultimate solution in any of these approaches depends on what application developers are willing to adopt, what changes they're willing to make. As an application developer or as an architect, the ball is really in your court. If enough of you back a particular solution, that's likely to be the one that drives where the industry goes. Make sure that you take a look around and are picking the right one that you want to be using in the future.

Is this talk focused on specific solutions, implementations, or is it about techniques that you can apply to many different solutions?

It's more about understanding the landscape and looking at where time goes in a Java application. We know that class loading, in particular, takes a lot of time when you're trying to get your application started, loading classes, and of course initializing them. This talk is looking at what are the ways - the tools and approaches -  you can use to avoid paying those costs? It comes down to moving more work to build time versus doing it at runtime, or looking at techniques that allow you to check point your running application so you could do that work once and restart from that point next time.


SPEAKER

Dan Heidinga

Principal Software Engineer @RedHat

Dan Heidinga wears two hats: first as an Eclipse OpenJ9 project lead, and the second as a Red Hat employee. Fortunately, both of those hats let him hack on the OpenJ9 JVM which he's been doing since 2007. Along the way he's been part of the Expert Groups for multiple JSRS including JSR 292 ('invokedynamic') and JSR 335 ('lambda').  He currently has his hands in most new JVM features and all major Java releases. In the past he's spent entirely too long staring at Java bytecode while maintaining the verifier and still enjoys an occasional detour into Smalltalk development.

From the same track

View full Schedule

3 weeks of live software engineering content designed around your schedule.

Don’t miss out! Save your seat now

Register
TOP