GraalVM for Java Developers: The Ultimate Beginner’s Guide
Transcript:
How to turn your Jaw project into a cool Lego construction set that will make kids envious. The answer is, GraalVM. GraalVM Is it just another JVM? Well, actually not. It is much more Want a performance boost? Try out grow VM JEP compiler. Want an almost instant startup? Give a try to GraalVM native image. Want to mix and match various languages? Try out the truffle framework. In this video, we'll look at all three components and get the answers to the questions. What, why, how and where.
GraalVM JEP compiler is a dynamic compiler written mainly in Java and based on top of Hotspot JVM, but as opposed to Hotspot C1 and C2 compilers, it includes more optimizations. More aggressive inlining data flow analysis, better escape analysis, and so on. As a result, it can provide better performance for some workloads than C one and C two compilers. You can run your code on Graal VM just like on any other JVM. No code refactoring, no incompatibilities. All dynamic features of Java are supported TCK verification, all JVM goodies, such as the variety of Garbage Collectors and so on. But your program can potentially run faster, have better throughput, and require less resources. Any limitations? Well, of course, it's not a magic pill. Some applications will have the same performance. In some cases, you may have to tune the GraalVM compiler for better results. How do you use Graal compiler? Simply download the GraalVM distribution and use it just like any other JDK to run and compile your application. Spoiler alert: there is not one but several GraalVM distributions, but I will reveal the difference later in this video. Stay tuned! Alright, we accelerated Java coup, but what if you want to write polyglot applications or run your own language on top of GraalVM?
In come the Polyglot API and the Truffle Framework. The Truffle Framework is a tool for building tools and implementations of programming languages that you can run on top of GraalVM. There are several ready implementations for GraalVM : GraalPy for Python, GraalJS, TruffleRuby, GraalWASM, and even GraalVM LLVM runtime for C and like. And you can implement your own language and truffle. How about implementing Brain____ truffle and using it in your Java app? Sounds like a cool weekend project. Well, jokes aside, truffle lets you implement various languages in one application and benefit from them all. And you can also build language agnostic tools such as profilers or debuggers. All right, but what about the polyglot API? It lets you embed code from the guest languages into a host Java application or embed Java code into the application written other languages. You can run code from any language implemented on truffle in a host Java Applic. Any limitations, traps, caveats. I know it sounds too good to be true. So here are some things to consider. Implementing your own language sounds cool, but it's not a one hour task. You get the tools, but you have to carve the sculpture yourself. Not all the tools and libraries for guest programming languages are available, but otherwise, GraalVM makes your Java app a hospitable host for any guest language.
Just don't let them quarrel our politics. Here comes the most hyped part of GraalVM. GraalVM Native Image. GraalVM native image compiles Java application at build time and turns it into a platform specific, fully compiled and optimized executable. That starts up almost instantly, so there's no warmup or memory overhead. It doesn't require a JVM to run. It has smaller footprint. And it has a smaller attack surface because all unrequired components were cut off during the compilation. Native image can be very useful in serverless environments. Last most GraalVM limitations are related to native image. It requires more effort to use a grom native ture with Java applications that rely heavily on Java dynamic features. Although it's not impossible, it means that you may have to tame a dragon or two. It may not be suitable for applications deeply tied into the JVM internals, and it is not a JVM, meaning there is no dynamic performance optimization as there is no JEP compiler at run time. There is a limited choice of garbage collectors. And you will have to get a knack for debugging and profiling native images. So how do you deal with reflection and its dynamic? Friends, you need to specify all cases of, uh, the usage of dynamic features in a special. Config file that will be read by the native image compiler. You can use the tracing agent that will track all the usages of dynamic features while you run your application in a test environment through all possible execution paths, and then it'll create a file automatically. But unfortunately, even the tracing agent may not always notice the usage of the dynamic features. What can I say? This is an exciting journey and if you really need what awaits you at the end, it is definitely worth going through. And now as promised, what is the difference between GraalVM distributions?
Cut to the Chase GraalVM community is free open source and is suitable for most use cases. Oracle GraalVM offers more optimizations, but it may not be free in some cases. Please read the license carefully. Plus, there are two downstream distributions of GraalVM Community Edition. Liberica Native Image Kit by BellSoft and Mandrel by Red Hat. Liberica Native Image Kit is recommended by Spring and is used by default in spring build pack. It also provides builds with Java effects. Manl includes only the native image part and is optimized for cos. So if you want to use a free version, but you may need technical support somewhere in the future. I suggest you try out these bad boys about the updates. Oracle GraalVM LTS is updated for free for three years and after that you have to either migrate to a newer LTS version or pay for support. GraalVM community provides updates only for the latest Java version, Liberica Native Image Kit and Mangel receive support for LTS versions for a longer period of time.
Consult their product support cycles. Let's summarize implementations applied to native image. There is no dynamic performance optimization. The choice of garbage collectors is limited, and the build process is resource and time consuming. When to use Jeep or native image. Git compiler is great for long running AppCDS and dynamic workloads. Native image is optimal for serverless computing and services characterized by short runs. Can we combine polyglot and native image? Generally? Yes, but all solutions must support a AOT mode. Sounds complicated. Well, actually it's not. Just choose a component and try it out. I hope I convinced you that grow is not just another JVM. It is a powerful solution for various engineering needs. Try out the component that best fits your needs and see it in action on your project. Don't forget to like, subscribe, and until next time.
