Locating a class file from a class loader by name

[Rafael Winterhalter]

Hi Alan,

thank you for your feedback. I agree that the current way of implementing a
class file lookup is not a fail-safe solution but it works for almost all
real use-cases and has therefore become a standard approach used by a lot
of code. I wanted to make sure that you are aware of the dependence on such
class file lookup of code generation libraries and their heavy use in
enterprise software. Of course, we will adapt the new APIs into our
software but as these libraries are non-commercial and developed after
hours, the adoption process will take some time. Currently, all of cglib,
Byte Buddy or Javassist do not function with Jigsaw when running the test
cases of their current stable build because of null pointer exceptions
triggered by unsuccessful class file lookups and I would not know how to
fix this problem.

I will continue to test Jigsaw pre-releases and hope that the mentioned
APIs allow for migrating the libraries such that I can offer a version of
Byte Buddy that supports Jigsaw rather sooner than later.
Best regards, Rafael

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

> On 14/11/2015 16:07, Rafael Winterhalter wrote:
>
>> Hi Alan,
>>
>> As for your suggestion to rather retransform/redefine classes, this would
>> unfortunately not be a feasible alternative for most applications that I
>> have seen. The HotSwap functionaltiy does not allow to add fields or to
>> override methods of super types as the class layout cannot be changed.
>> Also, many code generation frameworks function by renaming existing methods
>> and by reimplementing the same methods to call a user method. The renamed
>> methods can then be invoked by injecting a proxy class into the user code
>> that makes the original code available using a standard interface. If the
>> user method is non-static, this dispatcher also needs to be stored within a
>> new field of the class being instrumented.
>>
> Yes, I'm aware of the limitations to redefine/retransformClasses, I was
> pointing out that refransformClasses will invoke the ClassFileTransformer
> with the class bytes and may be the most reliable way to get them.
>
>
>> It is correct, of course that a class file does not always exist so the
>> above approach might fail but in practice this is not a problem. Users do
>> normally only want to instrument specific classes of their application via
>> Java agents that are available on the class path and not runtime generated
>> code.
>>
>> As for the necessity to locate class file, cglib can be named as another
>> example (used by e.g. Spring, Hibernate, Mockito) which needs to parse
>> class files to determine the target of a bridge methods. For this, cglib
>> calls:
>>
>> Class<?> clazz = ...
>> clazz.getClassLoader().getResourceAsStream(clazz.getName().replace('.',
>> '/') + '.class');
>>
>> If this would return null as it does with the current build of Jigsaw,
>> most real-world applications would stop to function. Therefore my concern
>> with the current implementation where the above call to the class loader
>> returns null.
>>
> The current proposal is that resources in named modules be encapsulated.
> There is discussion on EG list for JSR 376 on this topic. The
> ClassLoader.getResourcesXXX do of course work exactly as before for
> resources on the class path or loaded by custom other class loaders.
>
> A general point on frameworks is that we expect they will need need at
> least some changes to work with modules.
>
> -Alan
>