-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Oracle GraalVM #144
Add Oracle GraalVM #144
Conversation
If you want to try this, I have a demo image available at Ex:
|
First of all, thanks a lot for putting this PR together, @dmikusa! I'll go over it next week and probably come back with a couple of questions. I just tried to see whether I can use this to build a simple Spring app, but unfortunately, the build fails with the following error:
Not sure if this is me doing something wrong or a problem in your version of the |
🤦 No, that's cause I'm on an M1 Mac. I need to rebuild it on an AMD64 machine. I've updated the image, give it another pull and try again. It should work now. |
It does! Thanks a lot, @dmikusa! :) |
Will this be updated with new JDK 21 which has been released in the meantime? |
The demo image isn't going to be updated. That's just a proof of concept for the RFC. I'm hopeful that we can get the RFC approved soon though and get all of this merged into the actual buildpack. When that happens, yes we'll absolutely be including Java 21 support. |
I notice the PR discusses native-image, am I correct in understanding the same can't be used with as vanilla graalvm sdk? This might be good time to push for that support as spring 3.2 and java 21 are out so people will be looking at graalvm support with the free license. |
FYI, we have the RFC basically approved but are waiting on legal clearance because this is a new license. It's taking a while, but we have to follow the CFF's rules in this regard. As soon as we get clearance, I'm going to update and get this merged. |
This PR adds Oracle GraalVM support to the Oracle buildpack. This allows you to use Oracle GraalVM to build your native-image applications. Presently, it does not allow you to build JVM based applications with GraalVM. Instead, it will use the Oracle JDK for this. Signed-off-by: Daniel Mikusa <dan@mikusa.com>
Signed-off-by: Daniel Mikusa <dan@mikusa.com>
66c9aeb
to
d8769f7
Compare
Hello @dmikusa , I took the liberty to update your PR (rebase on |
hum; I've republished my
Solved, works fine, see: #144 (comment) and #144 (comment) |
Also, wrt to explicit messaging about Oracle license, I suggest we insert the messaging both in |
@anthonydahanne the Spring app you're trying to build uses 3.1.X. Don't you need 3.2.x for Java 21 support? |
Regarding the license notice, I thought the default bellsoft/liberica buildpack already has a similar one that can be adapted? It probably needs to mention the Liberica NIK EULA somewhere, no? |
- Adds a note to the license section to remind users it is their responsibility to read, understand, and comply with licenses for the software being installed - Updates the behavior section - Updates the buildpack.toml description Signed-off-by: Daniel Mikusa <dan@mikusa.com>
I pushed an update to the README to clarify the behavior now includes Native Image support. Also, I added a small blurb to the license section at the bottom. @fniephaus and @anthonydahanne let me know what you think about that. I'm not tied to the wording, I just want to make it clear the buildpack is just an installer and you as a user are responsible for ensuring compliance with all license requirements. |
@fniephaus I also thought of Spring Boot 3.2, and got the same result; probably something I missed with instrumentation of classes, I'll have a deeper look tomorrow @dmikusa thank you for updating the |
I ran successfully with Spring Boot 3.2 using spring-boot-maven-plugin + native-maven-plugin. The bindings and proxy are due to building behind corporate proxy. Here is my plugin setup: <plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<network>host</network>
<builder>paketobuildpacks/builder-jammy-tiny:latest</builder>
<buildpacks>
<buildpack>docker.io/anthonydahanne/oracle:4.0.0-anthony</buildpack>
<buildpack>urn:cnb:builder:paketo-buildpacks/java-native-image</buildpack>
</buildpacks>
<env>
<BP_JVM_VERSION>21</BP_JVM_VERSION>
<HTTP_PROXY>${docker.http.proxy}</HTTP_PROXY>
<HTTPS_PROXY>${docker.https.proxy}</HTTPS_PROXY>
<NO_PROXY>${docker.noProxy}</NO_PROXY>
</env>
<bindings>
<binding>
${project.build.directory}/platform/bindings/certificates:/platform/bindings/certificates
</binding>
</bindings>
</image>
</configuration>
</plugin>
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
</plugin> |
Thank you @mjhaugsdal !
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for putting this together. I only have a minor comment about a wording issue.
Would it work with spring maven plugin and packaging the container with the GraalVM JDK but without the native part? |
Co-authored-by: Fabio Niephaus <code@fniephaus.com>
@schrepfler Presently, no. If you were to install a JVM, it would give you Oracle's free JDK, not Oracle GraalVM JDK. Presently, this is only going to use Oracle GraalVM for building native-image. We are aware that folks are interested in the use case you mentioned, using Oracle GraalVM as a JVM. It's on the roadmap to support but requires more work. We wanted to get this out for folks to use in the meantime. |
Tested some builds from source/precompiled-jar, with Java 17 and 21. Looks good to me. |
Any updates on this, we'd like to give it a try as we've seen good performance improvement locally but as we strictly use springboot with the maven plugin and delegate to paketo we don't want to go outside of it's build ecosystem. |
@schrepfler please follow paketo-buildpacks/libjvm#431 for updates. |
Summary
This PR adds Oracle GraalVM support to the Oracle buildpack. This allows you to use Oracle GraalVM to build your native-image applications. Presently, it does not allow you to build JVM based applications with GraalVM. Instead, it will use the Oracle JDK for this.
Use Cases
This is a short spike on how we could possibly implement paketo-buildpacks/rfcs#294. The benefit of this approach is the simplicity and low amount of work it requires to get users to build native-image apps with Oracle GraalVM.
It does have the drawback mentioned in the commit message where you cannot at the moment select Oracle GraalVM to build JVM-based apps. It will continue to use Oracle JDK for that.
Checklist