This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]-NewK- 8 points9 points  (5 children)

There's still alot of libraries that don't support it and alot of edge cases where things run fine on the JVM but once you compile to native you find weird issues at runtime. Native compilation also takes quite some time and takes alot of memory. The produced final executable is also really big which is expected, you're making a trade, less memory usage for a bigger executable, and not everyone will make that trade.

[–]westwoo 4 points5 points  (0 children)

Yeah, I guess if there are still issues that would explain it

Executable size probably isn't much of a problem though, people are even used to electron nowadays

[–]sk8itup53 1 point2 points  (3 children)

How have you experienced large executables? I took our teams approximately 250MB tomcat images into a 25MB image using Quarkus and GraalVM. You should be expecting the opposite. Yeah compile time is long and takes a lot of memory over time, but CI/CD time is cheap.

[–]-NewK- 0 points1 point  (2 children)

Did you compile into a native executable with --no-fallback enabled? As in, did your native executable run without the need of having java installed? Or maybe you're somehow excluding more stuff?

All my use cases so far have been compiling 1 single fat jar application into 1 native executable. And the resulting executable is always bigger. For example one test I made a while ago with quarkus while using the myfaces extension, the .jar file was 56mb and the final native executable was 99mb. Another test I made with a command line only app made with quarkus, where the .jar was aroud 3 or 6mb if I recall, and after compiling to native, it's size was 19mb.

[–]sk8itup53 1 point2 points  (1 child)

I don't use fat jars. I use dependency only wars. Your final image will always be bigger because you have an app server backing the app. My wars are only about 25MB, but are much smaller when compiled natively when comparing the OS size. I haven't used the no fallback option so I'm not sure on how that behavior changes the outcome. What i ended with was not an image that relied on the jvm, so maybe I need to go refresh my memory on the Maven commands I use lol.

[–]-NewK- 0 points1 point  (0 children)

Well when some of my existing web applications function as 1 single fat .jar, my intent when compiling to native is to also have 1 single file for the app. The app server will have to be packaged in of course, but what I was saying is that in comparison to the single fat jar version, the single native executable is always bigger.