Proposal to add Oracle GraalVM and update GraalVM CE buildpack

[fniephaus]

Summary

Add a RFC for updated GraalVM buildpacks.

edit by @anthonydahanne : Rendered output of the RFC

Use Cases

Build Java applications with GraalVM Community Edition and Oracle GraalVM.

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: fniephaus / name: Fabio Niephaus (e18e5a6, 7f9900a, c11f6de, 420c715, fcd5f4d)

[sdeleuze]

Hey Fabio, thanks for this proposal. I will have a deeper look once back from PTO.

In the meantime, could you please fulfill the CLA requirements to make this PR mergeable?

[fniephaus]

I will have a deeper look once back from PTO.

Thanks, enjoy your time off!

could you please fulfill the CLA requirements to make this PR mergeable?

I'm already on it :)

[sdeleuze]

After having a look to the proposed RFC, and discussing with some members of the Spring team, looks like we are in favor of such proposal, both from the perspectives of aligning Buildpacks with the new GraalVM versioning/naming and to make it possible for Buildpacks users to be able to leverage Oracle GraalVM which brings a significant performance boost.

There are various aspect to discuss, including about the legal of the Oracle GraalVM license, so if the Buildpack team is in favor of moving forward, maybe worth discussing that in a meeting.

[dmikusa]

I talked with the other @paketo-buildpacks/java-maintainers about this and in general, we're in favor.

The primary concern is that we can't really retire a buildpack. It's pretty difficult to even rename one. Users reference them directly in their scripts/pom.xml/build.gradle etc... and we don't have a way to notify users*. It leaves the choice of a.) not updating the buildpacks anymore leaving users unaware that updates have stopped or b.) doing something drastic to break their builds and get the user's attention. Neither are good options, and we'd only want to do that in a very extreme case.

What we would propose is this instead:

1. The graalvm buildpack remains as it presently is. It is effectively the GraalVM Community buildpack. We can rename this in the README and in the metadata, just not the buildpack ID.

2. We presently have an oracle buildpack. It ships the Oracle JVM that's under the free license. https://github.com/paketo-buildpacks/oracle. We believe that the most natural place for Oracle's GraalVM release to go would be in this buildpack. This also ensures consistency of behavior across buildpacks because we have the Bellsoft Liberica buildpack which operates in this way (i.e. provides a JVM or Native Image tools). It also keeps the naming of our buildpacks consistent, because we try to name them after the vendor not what it installs.

This would leave the user experience like this:

1. A user wants to build a Java app with Oracle's JDK. The user would pick the oracle buildpack, we would install the Oracle JDK, compile the app, install the Oracle JRE in the runtime container, and the user would run the resulting image that contains Oracle's JRE.

2. A user wants to build a Java app with Oracle's GraalVM. The user would pick the oracle buildpack, we would see that the user wants to do a native image build and install Oracle's GraalVM instead of JDK, we do the Java build & the native image build, and generate the image. The user would run the image, which would just contain the resulting native image binary.

3. A user has been building a GraalVM app with the graalvm buildpack and GraalVM Community. The user now wants to switch to Oracle's GraalVM. The user just changes out the buildpack from graalvm to oracle. No additional env variables or settings are required. When the user rebuilds, we'll detect the difference. Install the Oracle GraalVM tools and rebuild the app using them. It should all be very seamless.

As far as the implementation goes. It should be relatively simple. Minor changes in the main.go file of the Oracle buildpack, as well as adding some metadata for the new dependencies & CI jobs to keep the new deps up-to-date. All-in-all, it should not take a lot of work.

Having said all that, we absolutely want to comply with all naming/licensing requirements for Oracle's software. If we can't take the above proposed path for that reason, or any other reason please let me know. Happy to continue discussing options.

Thanks

---

• we can post stuff on our blog/slack/twitter till the cows come home, but inevitably there is some segment of users that won't see it

[fniephaus]

I talked with the other @paketo-buildpacks/java-maintainers about this and in general, we're in favor.

Glad to hear!

The graalvm buildpack remains as it presently is. It is effectively the GraalVM Community buildpack. We can rename this in the README and in the metadata, just not the buildpack ID.

We presently have an oracle buildpack. It ships the Oracle JVM that's under the free license. https://github.com/paketo-buildpacks/oracle. We believe that the most natural place for Oracle's GraalVM release to go would be in this buildpack. This also ensures consistency of behavior across buildpacks because we have the Bellsoft Liberica buildpack which operates in this way (i.e. provides a JVM or Native Image tools). It also keeps the naming of our buildpacks consistent, because we try to name them after the vendor not what it installs.

Yes, that sounds reasonable to me. I wasn't aware that a buildpack can provide two different setups based on the capability requested by the user.

Having said all that, we absolutely want to comply with all naming/licensing requirements for Oracle's software. If we can't take the above proposed path for that reason, or any other reason please let me know. Happy to continue discussing options.

Considering there already is an oracle buildpack that distributes Oracle JDK, I don't see any problems.

[dmikusa]

It sounds like we're all basically in agreement here. Here's what I'd propose to move this forward:

1. @fniephaus - You need to sign the CLA. If you follow the instructions above -> Proposal to add Oracle GraalVM and update GraalVM CE buildpack #294 (comment) it'll walk you through it. Hopefully, that's feasible. If not, we'll have to rescind this PR and submit a new one.
2. If you haven't yet, please take a look at Add Oracle GraalVM oracle#144. I have a reference implementation for the PR that you can try out. There's a comment with the pack build command, halfway down. Copy & try that with some apps. (If you had issues before, try again please, I republished it as an amd64 image so it should work everywhere now)
3. If you have any comments on the RFC, please drop them here. Let's shoot to have them all in by 2023-09-16, or at least reach out if you need more time.
4. If you're satisfied with everything, please give this issue a review + approve.

Thanks!

[fniephaus]

Yes, we are. Thanks for following up, @dmikusa.

1. @fniephaus - You need to sign the CLA

I'm still working on this. I hope I can provide an update by the end of the week. 🤞

If you're satisfied with everything, please give this issue a review + approve.

Will do! Again, thank you for your work.

[fniephaus]

You need to sign the CLA.

I have made progress on this and hope we can finally get this done this month. :)

[dmikusa]

@fniephaus - Just wanted to check and see how things are going with the CLA? Does it look like you'll be able to get that signed?

Also, do you have any other thoughts on the RFC? If it looks good, can you review & approve? I'll work on getting approvals from the maintainers as well. Then we can hopefully get this merged when you're able to get the CLA signed.

Sorry, I forgot we hadn't updated the actual RFC yet. I made some suggestions based on my comment above. If you're OK with those, please commit them.

Thanks

[fniephaus]

Just wanted to check and see how things are going with the CLA? Does it look like you'll be able to get that signed?

I still think so, yes. Sorry for the delay, I really hope we can get this done in the next few days.

Sorry, I forgot we hadn't updated the actual RFC yet. I made some suggestions based on my comment above. If you're OK with those, please commit them.

Thanks! I will take a look.

[gbaso]

Hello team. I look forward for an oracle graalvm buildpack! However I want to raise an issue I think was not considered during the design of this PR.

While switching between Oracle JDK and Oracle GraalVM based on native capabilities is great, there are other use cases for using Oracle GraalVM as a non-native JRE. Specifically, enabling optimizations of the polyglot truffle runtime for embedded languages.

Please consider giving the option to choose Oracle GraalVM even when native compilation is not requested.

[dmikusa]

While switching between Oracle JDK and Oracle GraalVM based on native capabilities is great, there are other use cases for using Oracle GraalVM as a non-native JRE. Specifically, enabling optimizations of the polyglot truffle runtime for embedded languages.

This was considered, but unfortunately, it's not a use case we'll be able to support with the initial implementation.

I'm confident it's something we'll be able to support down the road based on other workstreams we have planned. It's just going to take a little longer.

[arana3]

Per Oracle GraalVM's FAQ page, after one year, Oracle GraalVM reverts to the existing OTN license. In that license agreement, there is a stipulation for customers who have not purchased Java SE:

If You do not have an existing license for Oracle Java SE Subscription or Oracle Java SE Desktop Subscription then Oracle grants You a nonexclusive, nontransferable, limited license to internally use the Programs, subject to the restrictions stated in this Agreement, only for the purpose of (i) OCI Use and (ii) developing, testing, prototyping, and demonstrating Your application.

I suggest proposal update to Buildpack should mention paid licensing is required upon expiry of Early Adopter license.

[shaunsmith]

There’s no way to retroactively change the license of Oracle GraalVM versions released in the past. New versions of an LTS release are made available under GFTC for three years following the OpenJDK schedule. After three years, subsequent minor versions will be released under the OTN license. But meanwhile, another GFTC licensed LTS will be released every two years, so the simplest thing to do to stay on a free to use release is to upgrade to the latest LTS. Since LTS releases overlap for one year there’s plenty of time to migrate and stay on free. See this blog for more discussion: https://blogs.oracle.com/java/post/graalvm-free-license

[dmikusa]

Thanks for clarifying @shaunsmith!

If there is interest, we could talk about adding support/lifecycle notifications with the buildpack. We do that for a few other buildpacks. For example, with the Spring Boot buildpack we have integration with the support product lifecycle for Spring projects, allowing the buildpack to notify users when they're coming up on an EOL or when they've got EOL software. It's not in the scope of this RFC, but just thought I'd mention it as a possibility as we've seen that help users keep other software up-to-date more easily.

[shaunsmith]

An EOL notification would be an excellent way to prompt people to upgrade before support comes to an end!

[fniephaus]

This RFC is finally unblocked by the CLA. I used the opportunity to revise and simply the RFC a bit. Please take another look!

[robdimsdale]

@paketo-buildpacks/java-maintainers any other approvals / comments?

From Working Group meeting 11/28:

• waiting for response from CFF legal. No recent updates.

[anthonydahanne]

@robdimsdale : there are no objections from Cloud Foundry lawyers.
@dmikusa please update your PR to make it clear (log warning for example) to the user that they chose purposely to use GraalVM (since it's not the default), hence they accept its license

This RFC can be merged now. Thank you all for your patience!

[dmikusa]

Thanks @anthonydahanne

We have the necessary votes (3 of 3 Java maintainers approve), so this RFC passes.