5 ms·

You can compile your Java code into an executable which doesn't require Java to be present. Advantages would be reduced memory footprint and quicker startup tim

You can compile your Java code into an executable which doesn't require Java to be present. Advantages would be reduced memory footprint and quicker startup times, which could be ideal for microservices started on demand instead of constantly running. That being said, the people at Spring don't recommend it for production use yet. Here's what they have to say about it: "While GraalVM is now GA, GraalVM native image feature which allows ahead-of-time compilation of Java applications into executable images is only available as an early adopter plugin, so we don't consider it production ready yet." https://github.com/spring-projects/spring-framework/wiki/GraalVM-native-image-support https://github.com/spring-projects/spring-framework/wiki/Gra...

bmc7505 6y ago
> You can compile your Java code into an executable which doesn't require Java to be present. Wasn't this feature already supported in JDK 14 with the jpackage tool? https://openjdk.java.net/jeps/343 https://openjdk.java.net/jeps/343
- nsonha 6y ago
  I believe because dead code elimination isn't currently possible with JVM, "package to binary" would mean including the whole (or most of) JVM with your program.
- vbsteven 6y ago
  If I understand correctly, the difference between jpackage and GraalVM is this: Jpackage bundles a small Java VM (with only the features you use) together with your compiled bytecode into a single executable. When it runs it starts up the VM and executes bytecode on that VM exactly the same as it would be if you were to run a jar on a preexisting JDK/JRE installation. Graal compiles your full app ahead of time into a native code binary. There is no bytecode/translation happening at runtime. That is why GraalVM advertises faster startup and lower memory footprint. So there are essentially 3 ways to run JVM (Java/Scala/Kotlin/...) code: * compile into bytecode jar -> requires existing VM runtime * compile into bytecode jar + bundle VM runtime -> no dependencies required, runs as the previous option * compile into native binary -> no dependencies required, runs native, starts and runs faster
  - bmc7505 6y ago
    Makes sense, thanks for clarifying!
  - vips7L 6y ago
    > Jpackage bundles a small Java VM (with only the features you use) together with your compiled bytecode into a single executable. When it runs it starts up the VM and executes bytecode on that VM exactly the same as it would be if you were to run a jar on a preexisting JDK/JRE installation. This is incorrect. Jpackage creates an installer which will unpack the VM image and any other resources. I've tried it with a small CLI tool and it actually doesn't work that well (at least on Windows).
- brabel 6y ago
  It's actually jlink that is already available and creates a minimal JVM with your application code that you can distribute as OS-specific bundles... jpackage, which is still in beta (and doesn't work very well, I've tried it recently), will take the output of jlink and turn that into some common OS-specific packages, like RPM, Debian and dmg.
  - vips7L 6y ago
    > and doesn't work very well, I've tried it recently) This is my experience as well. After installation, my installed app just didn't do anything.
erik_seaberg 6y ago
Static linking is back in fashion, but it means many stale copies of the guts of Java are present, where before we had just one complete and managed copy. It's very similar to bundling your own libc when pretty much every system already has one.
- brabel 6y ago
  You're not wrong, but with Java evolving rapidly, we're in a situation where there are dozens of commonly used JVM versions in the wild... being able to ship the most recent JVM (which can be as little as 25MB depending on which JDK modules you depend on) with your application not only allows you to benefit from using modern language features, but it also makes your application safer by using the latest runtime with the most up-to-date security fixes, not to mention performance and testing becomes a lot easier when you only have one JVM version to worry about. Also, you can have both options. I have a somewhat popular Java app that I distribute as a tiny jar (300KB, requires Java 9+) and as a stand-alone app (packaged with jlink, around 35MB including JDK 11) - and users can choose which one they want.
gunnarmorling 6y ago
As a counter-point, Quarkus [1] has mature support for building Java apps as native binaries via GraalVM, with a large number of extensions that enable 3rd party libraries to be used in native binaries, and people use this successfully in production. Issues from the past, like lack of debug symbol support with GraalVM CE, have also been resolved by now. Shameless plug for one real-world usage: the search feature of my personal blog is built as a GraalVM native binary, running as a serverless app on AWS Lambda [3]. Disclaimer: I work for Red Hat, who sponsor the development of Quarkus [1] https://quarkus.io/ https://quarkus.io/ [2] https://quarkus.io/guides/ https://quarkus.io/guides/ [3] https://www.morling.dev/blog/how-i-built-a-serverless-search-for-my-blog/ https://www.morling.dev/blog/how-i-built-a-serverless-search...
- nobleach 6y ago
  While what Quarkus promises sounds delightful, the actual dev experience is still not something I'd recommend. The amount of libraries one can use is still very limited. The compiler errors when one chooses to step outside of the approved list of supported libraries, are very cryptic (or non-existent). In my case, I tried to use Apache Freemarker for templating. I could've tried Quarkus' own templating library, but it didn't exist at that time. What was worse, I had to shut down nearly every app on my 16 Gigabyte, 6-core machine to compile the image! If I didn't do that, compilation would fail with no useful info. The Quarkus team does a wonderful job of demoing a Hello World example. I was just unable to achieve the same success. I love what they're trying to build, so I'll check back with regularity. Our one Quarkus app is using OpenJDK 1.8 for the time being.
  - gunnarmorling 6y ago
    Agreed that the experience when trying to native-enable existing libs isn't the greatest. Altough those things are rather reported by the GraalVM compiler rather than Quarkus. The working model and assumption is that somebody goes through this once and then either contributes changes to the library in question back upstream or provides a Quarkus extension for that library, sparing others from that hassle. That RAM consumption sounds definitely over the top; if you still have the context, logging an issue would be very welcomed. That said, there's many libraries enabled by Quarkus (see quarkus.io/guides/), so every essential functionality should be covered by now. Still a question of course whether your specific library in a given space (like FreeMarker vs. Quarkus Qute) already is supported. In any case, thanks for checking back in regularly, things might look better next time already, as the framework evolves rapidly.

bmc7505 6y ago

> You can compile your Java code into an executable which doesn't require Java to be present. Wasn't this feature already supported in JDK 14 with the jpackage tool? https://openjdk.java.net/jeps/343 https://openjdk.java.net/jeps/343

nsonha 6y ago
I believe because dead code elimination isn't currently possible with JVM, "package to binary" would mean including the whole (or most of) JVM with your program.
vbsteven 6y ago
If I understand correctly, the difference between jpackage and GraalVM is this: Jpackage bundles a small Java VM (with only the features you use) together with your compiled bytecode into a single executable. When it runs it starts up the VM and executes bytecode on that VM exactly the same as it would be if you were to run a jar on a preexisting JDK/JRE installation. Graal compiles your full app ahead of time into a native code binary. There is no bytecode/translation happening at runtime. That is why GraalVM advertises faster startup and lower memory footprint. So there are essentially 3 ways to run JVM (Java/Scala/Kotlin/...) code: * compile into bytecode jar -> requires existing VM runtime * compile into bytecode jar + bundle VM runtime -> no dependencies required, runs as the previous option * compile into native binary -> no dependencies required, runs native, starts and runs faster
- bmc7505 6y ago
  Makes sense, thanks for clarifying!
- vips7L 6y ago
  > Jpackage bundles a small Java VM (with only the features you use) together with your compiled bytecode into a single executable. When it runs it starts up the VM and executes bytecode on that VM exactly the same as it would be if you were to run a jar on a preexisting JDK/JRE installation. This is incorrect. Jpackage creates an installer which will unpack the VM image and any other resources. I've tried it with a small CLI tool and it actually doesn't work that well (at least on Windows).
brabel 6y ago
It's actually jlink that is already available and creates a minimal JVM with your application code that you can distribute as OS-specific bundles... jpackage, which is still in beta (and doesn't work very well, I've tried it recently), will take the output of jlink and turn that into some common OS-specific packages, like RPM, Debian and dmg.
- vips7L 6y ago
  > and doesn't work very well, I've tried it recently) This is my experience as well. After installation, my installed app just didn't do anything.

erik_seaberg 6y ago

Static linking is back in fashion, but it means many stale copies of the guts of Java are present, where before we had just one complete and managed copy. It's very similar to bundling your own libc when pretty much every system already has one.

brabel 6y ago
You're not wrong, but with Java evolving rapidly, we're in a situation where there are dozens of commonly used JVM versions in the wild... being able to ship the most recent JVM (which can be as little as 25MB depending on which JDK modules you depend on) with your application not only allows you to benefit from using modern language features, but it also makes your application safer by using the latest runtime with the most up-to-date security fixes, not to mention performance and testing becomes a lot easier when you only have one JVM version to worry about. Also, you can have both options. I have a somewhat popular Java app that I distribute as a tiny jar (300KB, requires Java 9+) and as a stand-alone app (packaged with jlink, around 35MB including JDK 11) - and users can choose which one they want.

gunnarmorling 6y ago

As a counter-point, Quarkus [1] has mature support for building Java apps as native binaries via GraalVM, with a large number of extensions that enable 3rd party libraries to be used in native binaries, and people use this successfully in production. Issues from the past, like lack of debug symbol support with GraalVM CE, have also been resolved by now. Shameless plug for one real-world usage: the search feature of my personal blog is built as a GraalVM native binary, running as a serverless app on AWS Lambda [3]. Disclaimer: I work for Red Hat, who sponsor the development of Quarkus [1] https://quarkus.io/ https://quarkus.io/ [2] https://quarkus.io/guides/ https://quarkus.io/guides/ [3] https://www.morling.dev/blog/how-i-built-a-serverless-search-for-my-blog/ https://www.morling.dev/blog/how-i-built-a-serverless-search...

nobleach 6y ago
While what Quarkus promises sounds delightful, the actual dev experience is still not something I'd recommend. The amount of libraries one can use is still very limited. The compiler errors when one chooses to step outside of the approved list of supported libraries, are very cryptic (or non-existent). In my case, I tried to use Apache Freemarker for templating. I could've tried Quarkus' own templating library, but it didn't exist at that time. What was worse, I had to shut down nearly every app on my 16 Gigabyte, 6-core machine to compile the image! If I didn't do that, compilation would fail with no useful info. The Quarkus team does a wonderful job of demoing a Hello World example. I was just unable to achieve the same success. I love what they're trying to build, so I'll check back with regularity. Our one Quarkus app is using OpenJDK 1.8 for the time being.
- gunnarmorling 6y ago
  Agreed that the experience when trying to native-enable existing libs isn't the greatest. Altough those things are rather reported by the GraalVM compiler rather than Quarkus. The working model and assumption is that somebody goes through this once and then either contributes changes to the library in question back upstream or provides a Quarkus extension for that library, sparing others from that hassle. That RAM consumption sounds definitely over the top; if you still have the context, logging an issue would be very welcomed. That said, there's many libraries enabled by Quarkus (see quarkus.io/guides/), so every essential functionality should be covered by now. Still a question of course whether your specific library in a given space (like FreeMarker vs. Quarkus Qute) already is supported. In any case, thanks for checking back in regularly, things might look better next time already, as the framework evolves rapidly.