Revisiting JDK-8161269

[Alan Bateman]

On 16/09/2016 08:36, David M. Lloyd wrote:

>
> OK.  For this issue though, would it not make sense to look at the 
> null parent class loader case in a specific and separate way: in the 
> past, such class loaders had access to all platform classes, so as a 
> compatibility factor it would not be unreasonable to take "null" in 
> this *specific* context to mean "platform class loader" and do this 
> translation inside the constructor?  Since the change that is really 
> occurring (in any real, observable sense) is that the "null" parent is 
> suddenly shrinking with respect to what it was going back far into 
> history, then the _compatible_ change would appear to be to provide a 
> new ClassLoader value that indicates "java.base (and optionally a few 
> more modules that can decrease over time)", which in reality maps to 
> the bootstrap class loader.  This way compatibility is maintained, and 
> the new (in the observable sense) functionality of having a more 
> limited parent CL is still available.
Fair point, these constructors could be changed to translate null to the 
platform class loader. That would need examination from a compatibility 
point of view too (esp. getParent). It would also create anomalies with 
other APIs where null is translated to the system class loader. However, 
I agree it's wroth exploring.

-Alan