search

paketo-buildpacks / java

A Cloud Native Buildpack with an order definition suitable for Java applications
Apache License 2.0
122 stars 25 forks source link

Enable option and support to specify a different JVM as an environment variable. #690

Open srisek opened 2 years ago

srisek commented 2 years ago

Currently by default the liberica JVM is used by default. It would be nice to have a support to switch / use a different JVM with the java build packs.

Describe the Enhancement

If we are able to pass a environment variable to the paketobuildpacks/builder:base like BP_JAVA_JVM="azul-zulu" / BP_JAVA_JVM="eclipse-openj9" , the java buildpacks should have the support to overwrite and provide support for the requested buildpacks rather than defaulting to liberica.

Possible Solution

Enable selection of different JVM's with an environment variable.

Motivation

While using the paketobuildpacks/builder:base with the pack cli this can be feasible by using the --buildpack argument. But if we are trying to run Java based builds from a CI system like tekton which uses the /cnb/lifecycle/creator program from the base image there is not an option that can be set to use a different JVM.

dmikusa commented 2 years ago

Just an FYI, this is something we've been discussing and is on the roadmap. No timeline at the moment, but we understand that switching the JVM by modifying the buildpacks order is a non-obvious solution and has some downsides, like what you mentioned. Using an environment variable, as we do with application servers (Tomcat, Tomee, Liberty, etc...), is how we are trying to make JVM selection work.

It's not clear at this time if we will include every JVM in the default paketo-buildpacks/java composite buildpack. There are some factors here we still need to consider, like what that will do to the image size and layer count. We've discussed a.) including them all (best case) or b.) including a subset by popularity (i.e. top 5), but it's hard to define objective criteria on what to include and we know that this option will never please everyone.

Do feel free to drop any additional thoughts on this issue. Thanks for reaching out!

mstoodle commented 2 years ago

Hi this is definitely something we (Eclipse OpenJ9 and IBM Semeru Runtimes which is the binary distribution for OpenJ9) would be happy to help pursue. One may think a JDK is just a JDK, and since many JDKs are very much built solely from OpenJDK there is some truth to that. But OpenJ9 is a completely independent implementation of the entire JVM that's used to run Java code. So even if one believes the "JDK is just a JDK" line, OpenJ9 and IBM Semeru Runtimes still represent a much more substantially different runtime environment than other JDKs.

There are many users that choose to use OpenJ9 and Semeru Runtimes for its lower memory consumption and faster startup. Because IBM uses this runtime engine for most of its Java based software, that means those users include most of the Fortune 500 and a wide variety of developers across the Java ecosystem.

As an OpenJ9 project lead and the chief architect for Java at IBM, and on behalf of our large user base, I would like to request that at least the option of Semeru Runtimes be provided here, though I would also be happy with a generic JDK option to be available. Please let us know how we can help!

dmikusa commented 2 years ago

@mstoodle Thanks for the feedback & showing your interest here. The next step here and what's being worked on now is going to be to propose a Paketo RFC with the details of what we're planning. We'll make sure to post that link here so we can gather feedback on the proposed solution & make sure it meets everyone's needs. When it's ready, even just a 👍 on the proposal is helpful so we know we're on the right track.

After that, we can implement the solution proposed in the RFC. We'd absolutely welcome any help or PRs with the implementation. After the RFC is approved, we'll post some issues breaking down the work. Feel free to submit a PR for any of them. If you have questions about contributing or a specific issue, you can reach out on Github or on the Paketo Slack. If you want to help with the RFC, we'd welcome that as well, best to reach out on Slack there, #java. Thanks again.

mstoodle commented 2 years ago

Excellent! Thanks for all the detail on the next steps. I'll look forward to seeing the links you mention :) !

kevin-ortega commented 1 year ago

@mstoodle An RFC was opened for this issue and is under discussion.

https://github.com/paketo-buildpacks/rfcs/pull/267

cAhmad commented 3 weeks ago

@mstoodle An RFC was opened for this issue and is under discussion.

paketo-buildpacks/rfcs#267

Hi, any update on this issue? I can see that the associated RFC have been merged since Apr 19, 2023.