Locating a class file from a class loader by name

[Alan Bateman]

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