Class JdkLibraryResolver

java.lang.Object
com.iizix.app.builder.JdkLibraryResolver
public class JdkLibraryResolver extends Object
Resolves the library class path of a target JDK for use with the ProGuard -libraryjars option, independently of JDK vendor and of whether the JDK ships packaged modules (JEP 493 builds such as Eclipse Temurin 24+ do not).

Resolution strategy:

  1. If the JDK contains a jmods directory with java.base.jmod, that directory is returned directly (Oracle, Zulu, Corretto, Liberica, pre-24 Temurin, or a Temurin with the separate jmods artifact installed).
  2. Otherwise the class files of all modules are extracted from the JDK's lib/modules jimage via the jrt: filesystem into one jar file per module in a per-JDK-version cache directory below ~/.iizi/jdk-lib-cache, which is then returned. The extraction is performed once per exact JDK build and reused by all subsequent builds.
The returned directory is a drop-in replacement for <java.home>/jmods in iizi-proguard-settings.pro: ProGuard reads a directory class path entry recursively and unpacks the contained .jmod or .jar archives; module-info.class entries are already excluded from the extracted jars.

Notes:

  • Reading a foreign JDK's jimage works cross-version: the built-in jrt: provider loads lib/jrt-fs.jar from the target JDK when java.home points to another installation.
  • The extraction needs no network access and no elevated privileges, and works with any vendor and any runtime image, including jlink-produced images such as JustJ (which have no jmods and no download source at all).
  • Concurrent builds are safe: extraction runs in a temporary sibling directory that is atomically renamed into place; a lost rename race accepts the winner's cache.
Author:
Christopher Mindus

  • Method Details

    • main

      public static void main(String[] args)
      Command line tool for the build scripts: rewrites a ProGuard settings file for the executing JDK.

      Reads the ProGuard settings file given as the single argument and writes a sibling file with "-jmods" appended to its name. If the executing JDK is version 25 or later and lacks the jmods directory (JEP 493 build), every occurrence of <java.home>/jmods is replaced by the resolved library cache directory (see resolveLibraryPath(File,IAppBuildMonitor)), quoted if the path contains spaces. In all other cases (older JDK, jmods present, or no token in the file) the file is copied unchanged.

      NOTE: Must be run with the java executable of the TARGET JDK, since both the version check and the resolution use the executing JVM's java.home, e.g. from PowerShell: C:/java/x64/jdk25/bin/java -cp bin com.iizix.app.builder.JdkLibraryResolver iizi-proguard-settings.pro

      Parameters:
      args - The single argument: the ProGuard settings file to process.

    • resolveLibraryPath

      public static File resolveLibraryPath(File jdkHome, IAppBuildMonitor monitor) throws IOException
      Resolves the ProGuard library class path directory for a JDK.

      Returns the JDK's own jmods directory when present, otherwise extracts the module classes from the lib/modules jimage into the user cache (once per exact JDK build) and returns the cache directory.

      Parameters:
      jdkHome - The JDK home directory (the directory containing "release").
      monitor - The progress monitor, one work unit per extracted module (about 70 for a full JDK), null for none.
      Returns:
      The directory to use as ProGuard "-libraryjars" entry, containing either the vendor .jmod files or the extracted per-module jars.
      Throws:
      IOException - If the directory is not a JDK home, if extraction fails, or if the monitor requested cancellation.