Request for Review: minor VM class loading change

[Karen Kinnear]

David,

Great question and I should have prefaced the code review with a better description of the motivation here.

With the JDK split into multiple modules, and each module loaded by a different module loader, it would
make sense for JDK classes to return a module loader in response to getClassLoader().

However, we would like to find a way to minimize the impact of the transition to modules on existing applications.

So we would like to ask the community's help in understanding how much code in the field depends on a null return 
from getClassLoader() and what special behavior that triggers. 

We understand that code today has to be able to handle a null return, and we have had to offer APIs on other classes
to work around not having a j.l.ClassLoader object, so yes, we expect there to be code that handles a null return. The
question is more whether there are code paths that depend on a null return for specific behavior, and what specifically
is that logic counting on.

And we would love suggestions on the best way to find out this information.

This set of changes and others to follow are intended to help set up an environment for experimenting with the impact
of that potential change.

thanks,
Karen


On May 17, 2012, at 1:03 PM, David M. Lloyd wrote:

> On 05/17/2012 11:51 AM, Karen Kinnear wrote:
>> 
>> Please review a minor change for the VM to handle a non-null base module loader. I've also
>> added a new (potentially temporary) API JVM_GetModuleLoader to allow us to incrementally clean up logic that assumes
>> that JVM_GetClassLoader returns null for the bootclasspath.
>> 
>> Within the VM, we will continue to use null to represent module classes loaded by the vm.
>> 
>> http://cr.openjdk.java.net/~acorn/non-null-module-loader/webrev/
> 
> So is the ultimate goal then to move away from having JDK classes always return null for getClassLoader()?  Or will that behavior remain?
> 
> 
> -- 
> - DML