Guardsquare
How to setup libraryjars, if jmods are missing
How to setup libraryjars (for Java 24 and later), if jmods are missing (like Adoptium / Temurin is doing starting with Java 24, while enabling JEP 493 - see https://adoptium.net/blog/2025/03/eclipse-temurin-jdk24-JEP493-enabled/)?
If I understand the discussion in the adoptium/adoptium-support issue above correctly, there are still no Temurin builds with jmod files for recent JDK versions, but jmod files can be downloaded separately now. However, that is a bit cumbersome for local development and CI (see also related https://github.com/actions/setup-java/issues/804).
So I guess the main question is if there is a way to use ProGuard without jmod files. And if not, I guess one has to look into the general workarounds for downloading and setting up the jmod files for Temurin.
Our workaround is to download jmod files via https://github.com/download-maven-plugin/download-maven-plugin.
You can also use a JDK that has jmod files in place. Azul's distributions do, for example. There is plenty to choose from:
https://github.com/actions/setup-java?tab=readme-ov-file#supported-distributions
Our workaround is to download jmod files via https://github.com/download-maven-plugin/download-maven-plugin.
For simplicity do you just use the jmods for an arbitrary OS and architecture (e.g. Linux x64) regardless of what OS you are running on? While the jmods contain OS specific code, I guess it does not matter for ProGuard as long as you only compile against OS-agnostic public API of the JDK (?).
For reference, it seems the way R8 does it is to use the jrt:/ file system to load the JDK class files[^1]. Which seems to work even if the jmod files are not present.
Would it be possible for ProGuard to support that as well? (Should that be tracked in a separate issue?)
[^1]: Though they specify an additional classloader for jrt-fs.jar. Not sure if that is actually necessary when setting the java.home for the file system. It looks to me as if the file system can be requested within the current JDK and it will handle loading internally the file system from java.home. Or maybe they try to account for the currently running JDK not supporting jrt:/ (and the classloader acting as fallback)? Not sure if that is a valid / complete JDK though since the java.base documentation explicitly mentions the jrt:/ provider.
Edit: They probably do it to support running on JDK 8 while targeting a newer JDK, see also this comment in a different project and the description of JEP 220 mentioning jrt-fs.jar.
Our workaround is to download jmod files via https://github.com/download-maven-plugin/download-maven-plugin.
For simplicity do you just use the jmods for an arbitrary OS and architecture (e.g. Linux x64) regardless of what OS you are running on? While the jmods contain OS specific code, I guess it does not matter for ProGuard as long as you only compile against OS-agnostic public API of the JDK (?).
Same architecture, multiple OS (linux + windows) via Linux x64 jmod files.
For reference, it seems the way R8 does it is to use the jrt:/ file system to load the JDK class files1. Which seems to work even if the jmod files are not present.
That is one direction to look into indeed.
@piazzesiNiccolo-GS, I have created a proof-of-concept for that: #504 Hopefully that is useful for you.