The easy solution for #AvoidConcealedPackageConflicts, #MultipleModuleVersions

[Alan Bateman]

On 03/03/2017 16:43, David M. Lloyd wrote:

> :
>
> Any previous compatibility argument regarding class loader arrangement 
> is already moot, since class loading behavior is different enough now 
> that user code already does not work as it did.  There is no longer 
> any reasonable expectation that user code which uses its own class 
> loader to locate resources and classes will find classes that that 
> code cannot find via class resolution, which indeed is the entire 
> point of modularity.
I'm not sure what you mean by "does not work as it did". There is an 
area where great care has been taken to avoid significant changes as it 
has the potential to break too much existing code. Specifically, the 
arrangement of the 3 built-in class loaders and class loading has not 
changed. The limited changes in this area with compatibility impact are:

1. The JDK's application class loader is no longer a URLClassLoader that 
can potentially break code that assumes the implementation type.

2. The modules for a few non-core components (e.g. java.corba and 
java.sql) are defined to the platform class loader rather than the boot 
loader. This potentially breaks a few cases where code creates a custom 
class loader with `null` as the parent and assumes that all Java SE 
types are visible via that loader.

The potential for breakage with these implementation (not JPMS) changes 
is why they have been in JDK 9 for a long time and in EA builds since 
2015 to give any impacted libraries and tools as much time as possible 
to adjust.

-Alan