Transition to Mandrel builder images by default

[zakkak]

Description

Hi all,

Due to oracle/graal#5303 that came up with the latest GraalVM release, the Quarkus team decided (see #29182) to transition Quarkus to using Mandrel builder images (which are not affected by oracle/graal#5303) instead of the GraalVM CE ones that were used by default till now, at least until the issue gets resolved in GraalVM CE. This will essentially change the current default value of quarkus.native.builder-image from graalvm to mandrel.

Taking the opportunity, the Mandrel team would like to propose the transition to become permanent and would like to hear your thoughts on that (especially if there are any objections).

Mandrel is a downstream GraalVM distribution with the main goal of providing a native-image release specifically tailored to Quarkus. Mandrel productized builds are also used by the Red Hat build of Quarkus.

This comes with the following benefits:

1. Better/More testing in terms of Quarkus coverage
2. Ability to create quick bugfix releases for major issues affecting Quarkus users
3. Ability to backport upstream master features to a release earlier if it seems to benefit Quarkus users, e.g. Only require libmanagement_ext if it's actually needed. graalvm/mandrel#444 and Backport c++ compatible mangling support to 22.3 graalvm/mandrel#445.
4. Smaller builder images (~550MB vs ~950MB)

However, it also comes with some possible drawbacks:

1. Starting with 22.3 Mandrel no longer ships JDK-11-based builds. Note however, that you can still build Java 11 projects using an OpenJDK 11 build and then create the native executable with Mandrel Java17 releases.
2. No polyglot, musl, llvm, static images, etc. support

On behalf of the Mandrel team (@galderz @jerboaa @Karm @zakkak)

[quarkus-bot]

/cc @Karm, @galderz

[ThoSap]

In our case, polyglot support is really needed for some projects, but we can always specify the quay.io/quarkus/ubi-quarkus-graalvmce-builder-image builder image in the application.properties/yaml.

[essobedo]

Same for the Camel ecosystem, the lack of support for non JVM-based languages and polyglot in Mandrel is an important limitation.

[essobedo]

The other main problem I see is the lack of Mac OS support graalvm/mandrel#114

[zakkak]

The other main problem I see is the lack of Mac OS support graalvm/mandrel#114

I don't see this as a main problem, since even with GraalVM as the default builder-image one still needs to use a local installation on Mac OS.

[essobedo]

@zakkak I'm not an expert so I guess that I misunderstand the problem/ticket. Do you have someone in the Mandrel team that uses a Mac OS? And if so, how does he prevent his UX from being affected by the fact that only Linux and Windows binaries are proposed? Is there some doc somewhere that explains the workaround?

[zakkak]

@zakkak I'm not an expert so I guess that I misunderstand the problem/ticket. Do you have someone in the Mandrel team that uses a Mac OS? And if so, how does he prevent his UX from being affected by the fact that only Linux and Windows binaries are proposed? Is there some doc somewhere that explains the workaround?

My understanding is that you (or anyone else) perform your development on MacOS using Quarkus and the question seems to be "How do I compile my Quarkus application to native using MacOS".

The answer to this really depends on the target architecture you want the native executable to run on:

Case 1: The target is MacOS itself

In this case you need to install GraalVM locally and configure Quarkus to use that instead of a builder image. Instructions on how to achieve this are available here. Note that this is necessary even if the default builder image is based on GraalVM, since the builder images only produce Linux compatible executables.

Case 2: The target is Linux

In this case you should use the default builder image (no matter whether that is using GraalVM or Mandrel). This will use a docker container (based on linux) to build the native executable and the resulting native executable won't be runnable on MacOS.

Case 3: The target is Windows

In this case AFAIK there is no solution, you need to build the native executable in Windows. Both GraalVM and Mandrel should work just fine.

So based on the above. The lack of MacOS support in Mandrel doesn't seem to affect the UX in a significant way, but please let me know if I am overlooking something.

[essobedo]

Thx for your answer, I better understand your point now.

I agree that there is no direct impact. It could only affect the UX of a developer using Mac OS if, for example, a test fails on the CI against the Mandrel distribution and not on the corresponding GraalVM version, in that case, he will need to launch the test inside a docker container instead of locally.

But in practice, to avoid that if we have some MacOS devs in a team and we want to keep the same distribution for each dev phase, we can still use the builder images of GraalVM.

[gemmellr]

The default has apparently already switched to Mandrel, should this still be open ? (I came looking for when exactly, and found this).

[zakkak]

+1 it looks like there are no issues so far with the transition. The docs seem OK as well, although it might be worth mentioning Mandrel in some headings that only mention GraalVM e.g. https://quarkus.io/guides/building-native-image#graalvm and https://quarkus.io/guides/building-native-image#configuring-graalvm but that's covered by #30745