Skip to content
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

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

Open
srisek opened this issue Jul 12, 2022 · 6 comments
Labels
type:enhancement A general enhancement

Comments

@srisek
Copy link

srisek commented Jul 12, 2022

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.

@srisek srisek changed the title Enable option and support to specify a different JVM as environment variable. Enable option and support to specify a different JVM as an environment variable. Jul 12, 2022
@dmikusa dmikusa added the type:enhancement A general enhancement label Jul 13, 2022
@dmikusa
Copy link
Contributor

dmikusa commented Jul 13, 2022

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
Copy link

mstoodle commented Aug 15, 2022

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
Copy link
Contributor

dmikusa commented Aug 16, 2022

@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
Copy link

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

@kevin-ortega
Copy link

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

paketo-buildpacks/rfcs#267

@cAhmad
Copy link

cAhmad commented Nov 6, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

5 participants