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
