RFR: 8354675: Create separate image builder for hermetic

Jiangli Zhou jiangli at openjdk.org
Tue Apr 15 14:28:59 UTC 2025


On Thu, 10 Apr 2025 16:13:47 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This is a start of a simple refactoring for moving hermetic handling into dedicated implementation classes. In this case I cover `ImageBuilder` and `ExecutableImage`. A similar change should be done for `ImageFileCreator` but that's for another PR.
> 
> @jianglizhou Please take a look. Thanks!
> 
> While at it I've observed the following:
> 
> 1. `<hermetic-image-file> --list-modules` doesn't seem to work. Shows [1] for me.
> 2. `strip -g <hermetic-image-file>` will destroy the image. Looks like [2]. Probably a drawback for tucking on the offset after the modules file? We might want to consider building in debuginfo handling into `jlink` itself. Like the `--strip-native-debug-symbols` plugin does (but doesn't work for hermetic, yet).
> 
> Thoughts?
> 
> [1]
> 
> $ ./demo-image -m mod.example/com.example.demo.Main
> [0.017s][warning][cds] Failed to open shared archive file (Not a directory)
> Hi
> $
> ./demo-image --list-modules
> [0.020s][warning][cds] Failed to open shared archive file (Not a directory)
> Exception in thread "main" java.lang.InternalError: Unable to detect the run-time image
> 	at java.base/jdk.internal.module.SystemModuleFinders.ofSystem(Unknown Source)
> 	at java.base/java.lang.module.ModuleFinder.ofSystem(Unknown Source)
> 	at java.base/jdk.internal.module.ModuleBootstrap.unlimitedFinder(Unknown Source)
> 	at java.base/jdk.internal.module.ModuleBootstrap.limitedFinder(Unknown Source)
> 	at java.base/sun.launcher.LauncherHelper.listModules(Unknown Source)
> 
> 
> [2] This is a build with `--with-native-debug-symbols=internal` (fastdebug)
> 
> $ ll -lh ./demo-image 
> -rwxr-xr-x. 1 sgehwolf sgehwolf 909M Apr 10 17:36 ./demo-image
> $ strip -g ./demo-image 
> $ ll -lh ./demo-image 
> -rwxr-xr-x. 1 sgehwolf sgehwolf 50M Apr 10 18:07 ./demo-image
> $ ./demo-image -m mod.example/com.example.demo.Main
> Error occurred during initialization of VM
> Failed setting boot class path.

@jerboaa thanks for the refactoring! This looks much cleaner than handling the hermetic case in `DefaultImageBuilder`. I recall @AlanBateman made similar suggestion during this week's hermetic meeting.

> <hermetic-image-file> --list-modules doesn't seem to work. Shows [1] for me.
strip -g <hermetic-image-file> will destroy the image. Looks like [2]. Probably a drawback for tucking on the offset after the modules file? We might want to consider building in debuginfo handling into jlink itself. Like the --strip-native-debug-symbols plugin does (but doesn't work for hermetic, yet).
Thoughts?
> 
> [1]
>
> $ ./demo-image -m mod.example/com.example.demo.Main
> [0.017s][warning][cds] Failed to open shared archive file (Not a directory)
> Hi
> $
> ./demo-image --list-modules
> [0.020s][warning][cds] Failed to open shared archive file (Not a directory)
> Exception in thread "main" java.lang.InternalError: Unable to detect the run-time image
>	at java.base/jdk.internal.module.SystemModuleFinders.ofSystem(Unknown Source)
>	at java.base/java.lang.module.ModuleFinder.ofSystem(Unknown Source)
> 	at java.base/jdk.internal.module.ModuleBootstrap.unlimitedFinder(Unknown Source)
>	at java.base/jdk.internal.module.ModuleBootstrap.limitedFinder(Unknown Source)
>	at java.base/sun.launcher.LauncherHelper.listModules(Unknown Source)

Looks like a case that has not yet been handled, but I'll test with our internal prototype to check if `--list-modules` also fails and if it's due to any patches that I missed to port for the branch. @jerboaa Could you file a bug for this? Thanks

> [2] This is a build with --with-native-debug-symbols=internal (fastdebug)
>
> $ ll -lh ./demo-image 
> -rwxr-xr-x. 1 sgehwolf sgehwolf 909M Apr 10 17:36 ./demo-image
> $ strip -g ./demo-image 
> $ ll -lh ./demo-image 
> -rwxr-xr-x. 1 sgehwolf sgehwolf 50M Apr 10 18:07 ./demo-image
> $ ./demo-image -m mod.example/com.example.demo.Main
> Error occurred during initialization of VM
> Failed setting boot class path.

Yeah, stripping the final image would corrupt the image. The linked launcher executable should be stripped first, then passed to jlink to create the final image. The `build-id` would be the same.

> > --list-modules doesn't seem to work. Shows [1] for me.
> > strip -g  will destroy the image. Looks like [2]. Probably a drawback for tucking on the offset after the modules file? We might want to consider building in debuginfo handling into jlink itself. Like the --strip-native-debug-symbols plugin does (but doesn't work for hermetic, yet).
> > Thoughts?
> > [1]
> > $ ./demo-image -m mod.example/com.example.demo.Main
> > [0.017s][warning][cds] Failed to open shared archive file (Not a directory)
> > Hi
> > $
> > ./demo-image --list-modules
> > [0.020s][warning][cds] Failed to open shared archive file (Not a directory)
> > Exception in thread "main" java.lang.InternalError: Unable to detect the run-time image
> > at java.base/jdk.internal.module.SystemModuleFinders.ofSystem(Unknown Source)
> > at java.base/java.lang.module.ModuleFinder.ofSystem(Unknown Source)
> > at java.base/jdk.internal.module.ModuleBootstrap.unlimitedFinder(Unknown Source)
> > at java.base/jdk.internal.module.ModuleBootstrap.limitedFinder(Unknown Source)
> > at java.base/sun.launcher.LauncherHelper.listModules(Unknown Source)
> 
> Looks like a case that has not yet been handled, but I'll test with our internal prototype to check if `--list-modules` also fails and if it's due to any patches that I missed to port for the branch. @jerboaa Could you file a bug for this? Thanks

@jerboaa, the issue exists in our current internal prototype also. The problem is due to the missing hermetic support in `SystemModuleFinders.ofSystem()`. Checking the logged bugs, I realized that I had noticed this issue while making the change for hermetic jimage (the modules) supported `.*(default|exempt)_.*policy` last March. It remained as unresolved.

I just pushed the following commit, which should resolve the issue:

https://github.com/openjdk/leyden/commit/de66378768dd6ac084b6cabc48cc986a283def36

src/jdk.jlink/share/classes/jdk/tools/jlink/builder/HermeticImageBuilder.java line 52:

> 50:     private final Set<String> modules = new HashSet<String>();
> 51: 
> 52:     public HermeticImageBuilder(Platform platform, Path hermeticImage) {

How about making `HermeticImageBuilder(Platform platform, Path hermeticImage)` argument ordering to be more consistent with `DefaultExecutableImage(Path home, Set<String> modules, Platform p)`:


HermeticImageBuilder(Path hermeticImage, Platform platform)

src/jdk.jlink/share/classes/jdk/tools/jlink/builder/HermeticImageBuilder.java line 94:

> 92:         private final Path imagePath;
> 93: 
> 94:         private HermeticExecutableImage(Platform platform, Path image,

Similar suggestion for `HermeticExecutableImage()` argument ordering:


HermeticExecutableImage(Path image, Set<String> modules, Platform platform)

-------------

PR Review: https://git.openjdk.org/leyden/pull/55#pullrequestreview-2758309777
PR Comment: https://git.openjdk.org/leyden/pull/55#issuecomment-2795067945
PR Comment: https://git.openjdk.org/leyden/pull/55#issuecomment-2797721568
PR Review Comment: https://git.openjdk.org/leyden/pull/55#discussion_r2038313318
PR Review Comment: https://git.openjdk.org/leyden/pull/55#discussion_r2038313780


More information about the leyden-dev mailing list