4 ms·

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 part

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.
  - vips7L 6y ago
    Isn't native-image memory consumption and compile time basically a known issue by the graal team?
- thu2111 6y ago
  Note that Quarkus starts very fast on Java 14 too. With JDK 14 their hello world app starts in about 600msec on my laptop. HotSpot got optimised a lot over the years and Quarkus gets some of its speed boost by just doing less dynamic stuff at startup.

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.
- vips7L 6y ago
  Isn't native-image memory consumption and compile time basically a known issue by the graal team?
thu2111 6y ago
Note that Quarkus starts very fast on Java 14 too. With JDK 14 their hello world app starts in about 600msec on my laptop. HotSpot got optimised a lot over the years and Quarkus gets some of its speed boost by just doing less dynamic stuff at startup.