JImage missing in ToolProvider registration

[Alan Bateman]

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