JVMTI GetModuleByPackageName -- plans for Instrumentation API equivalent?

[Alan Bateman]

On 22/06/2016 11:16, Michael Rasmussen wrote:

> Hi
>
> With the addition of GetModuleByPackageName added to JVMTI ([1], [2]),
> are there any plans to add similar functionality to the
> Instrumentation API (or somewhere else)?
>
>  From ClassFileTransformer we now get the Module for the class that is
> currently being transformed, but a very common scenario when
> transforming a class that is being loaded, is the need to get
> information about other classes used by that class; classes which
> might not have been loaded yet, meaning we need to get the bytes
> somehow.
>
> A common approach to this pre-jigsaw, was simply to translate the
> classname to a filename and ClassLoader::getResourceAsStream; but with
> named modules, this is no longer the case, we now have to know which
> Module that class is in in order to get the bytes
> (#ClassFilesAsResources, #ResourceEncapsulation etc).
>
> Adding a GetModuleByPackageName equivalent method would go some way to
> help with this issue.
>
GetModuleByPackageName is being added to JVM TI because 
ClassFileLoadHook cannot be changed to add a new parameter and it would 
too messy to introduce a different callback. It's much cleaner in the 
java.lang.instrument API as the Module is passed to the 
ClassFileTransformer.

As to whether yet more APIs are needed then I think it would be better 
to wait until the #ClassFilesAsResources/#ResourceEncapsulation issues 
are discussed.

-Alan