On 20/10/2025 20:48, Joerg Michelberger wrote:
Hi there,
this is Jörg, the one who met Stuart Marks at Devoxx BE 2025.
We talked at Devoxx Antwerp about a flaw with the programmatic
accessibility of jimage in JDK21.
While it was with source/target 8 possible to compile and access the
Main of jlink/jimage/jmod, encapsulation with source/target 11 it is
not. But the intended new ToolProvider API which should make the three
accessible in a controlled way, lacks the Tool Registration of jimage.
Registration for jmod can be seen here:
https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jmod/Main.java#L53,
same for jlink. But jimage seems to be forgotten:
https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jimage/Main.java.
IMHO it is trivial to add registration for the jimage in code and
module definition and it seems that it also could be almost riskless
to be backported to JDK25/17/11.
The jimage tool is included in the JDK is for troubleshooting scenarios,
e.g. corrupt installations, allow support engineers extract class files
when hurting a bug or crash involving custom run-time images with
modified JDK classes or non-JDK modules. It's not a tool that we would
expect to see used by developers or used in builds. This is why this
tool does not have a man page and why the tool is not registered with
ToolProvider for "in-process" usages. So very different to tools such as
javac, javadoc, jar, jmod, jlink ... that are good candidates to use
with the ToolProvider API.
I think it would be useful if you could say a bit more about what you
are looking to do with the jimage tool. Are you just tooling for a way
to run all tools in bin "in-process" or is this something more real
where you are using the jimage tool to do something specific.
-Alan
