Locating a class file from a class loader by name

[Rafael Winterhalter]

Hi Alan,
thanks for your quick answer. I am less worried about the generated code
then I am about the generation process.

For example, a ClassFileTransformer might want to instrument all classes
that implement a certain interface. For this, the transformer needs to
parse the provided class file, extract the interfaces and locate their
class files and so forth in order to resolve the type hierarchy. For this,
it is now possible to query the ClassLoader which is an argument provided
to the transformer. I do not know how I would access the module at this
point or get hold of the class file.

Also, I would expect that a Java agent that worked in Java 8 would also
work in Java 9. If I had to use Java 9 APIs in order to patch my
application, I would be required to offer two versions of my library, one
for Java 9+ and one for Java 8-. That would be unfortunate.

Do I see this correctly?
Thank you, best regards, Rafael

2015-11-13 17:00 GMT+01:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 13/11/2015 12:04, Rafael Winterhalter wrote:
>
>> Hello,
>>
>> I recently started testing several byte code manipulation frameworks
>> against a recent build of Jigsaw and found a common problem of all of
>> these
>> libraries. I am myself the developer of Byte Buddy (
>> https://github.com/raphw/byte-buddy) and I know most tools for code
>> manipulation fairly well. I hope that this mailing list can provide me
>> some
>> me advice on patching my library and providing help to other maintainers.
>>
>> Especially in the context of using the instrumentation API, it is often
>> not
>> possible to do reflection on load classes. Rather, code manipulation tools
>> read Java class files and parse these files for exposing classes using a
>> similar API but without the possibility to invoke a method or to read a
>> field.
>>
>> Typically these tools read Java class files by querying a class loader for
>> the class file, e.g.:
>>
>> ClassLoader.getSystemClassLoader("java/lang/Object.class");
>>
>> This does not longer work using Jigsaw and I wonder how one is now
>> supposed
>> to locate a class file. Do I need to find all runtime images and query
>> each
>> single one? How would the path be for such a class file?
>>
>> Java agents that do byte code instrumentation with java.lang.instrument
> should continue to work, this goes for both load-time and dynamic
> instrumentation and also where the code is instrumented to calling into
> supporting classes on the class path. There is still work to do for the
> scenario where agents modify the classes with references to types in other
> modules but that will come in time.
>
> As regards ClassLoader.getResourceXXX (which I think is what you mean)
> then it continues to search the class path as before. It doesn't however
> locate resources in named modules because they are encapsulated. The same
> named methods in java.lang.Class to get resources allow code to get at
> resources in its own module but not other modules. As to how to get at
> resources in named modules then there are a few ways but the simplest for
> now is to look at java.lang.reflect.Module getResourceAsStream.
>
> -Alan
>
>