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.


Reply via email to