-
Notifications
You must be signed in to change notification settings - Fork 26
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
Enhancement: AppCDS support #166
Comments
More info here: https://www.morling.dev/blog/building-class-data-sharing-archives-with-apache-maven/ It would probably make sense for there to be a separate Gradle plugin for AppCDS, but the badass-jink-plugin could have an option to apply it as part of the build process. |
It does not work with -module-path, and it requires Shadow jar. I've tried only with badass-runtime, works flawless. Everything can be easily done with exec task on Gradle, although some libs like okhttp3 requires full exclusion from classes.txt so there is user knowledge involved about what is cached. |
Since Java 11, CDS also supports I added experimental support for CDS in badass-jlink 2.23.0 and badass-runtime 1.12.0:
It requires Java 11+ in badass-jlink and Java 13+ in badass-runtime. In the case of badass-runtime, the plugin does two things:
In the case of badass-jlink, the situation is simpler: only the base CDS archive of the image is needed, because the modular application is also part of the custom runtime image. I would love your feedback. |
Actually, a dynamic AppCDS archive also makes sense in the case of badass-jlink, when |
After reading Smaller, Faster-starting Container Images With jlink and AppCDS I'm thinking it might be possible to achieve faster startup in jlinked/jpackaged apps using AppCDS.
Would it make sense to add this to badass-jlink-plugin?
The text was updated successfully, but these errors were encountered: