JDK support for VM to read classes from modules in a module library

[Mandy Chung]

On 5/9/2012 10:29 AM, Rémi Forax wrote:
>
> In fact, this method is really useful, most of the tools that does 
> bytecode transformation at runtime
> (most O/R mappers, dynamic language runtimes, profilers, code coverage 
> tools, etc)
> are now required to compute the stack frame attribute which requires 
> to compute the lower upper bound
> of a set of types. For that, being able to crawle the type hierachy 
> without loading the static initializer
> is a must have. 

Thanks for the information, Remi.  In this case, the tool itself does 
the Class.forName, right?  i.e. the caller's class loader is the tool's 
class loader.  Bytecode transformation for modules is one area being 
investigated. In modules, the tool that does bytecode instrumentation 
would be loaded by a separate loader and it wants to load classes being 
instrumented without invoking the static initializer.    The key is that 
the tool module needs the ability to see the types in the modules being 
instrumented which is yet to be determined.   In any case, this is a 
good example that the new convenient method could help and simplify the 
code.

> interfaces can have a <clinit> if you initialize a static final field 
> that store something which is not
> a primitive type or a String, e.g. an ArrayList

Good point.  I was looking at the current list of platform MXBean 
interfaces (the ones that PlatformComponent class supports).  Since we 
can't (shouldn't) restrict any future mxbean interface to have a static 
initializer, I should revert this line and keep the initialize parameter 
to false.

Mandy