On 04/25/2017 08:31 AM, Alan Bateman wrote:
On 25/04/2017 14:16, Michael Nascimento wrote:
:
and also the fact
packages must be defined by a single module even if they are not
exported,
because it was considered nearly impossible to track in real world
scenarios.
Keep in mind that this is not a module system limitation, instead it is
just a consequence of defining all modules on the application module
path to the application class loader. Containers or applications using
the API doing dynamic configurations and creating module layers can put
modules in their own namespace to avoid conflicts between concealed
packages.
Someday then we might get to the point where modules on the application
module path could be assigned to different class loaders but it has huge
implications and would take an entire release to shake out issues.
I tend to disagree with the assertion that there would be huge
implications. Libraries and applications have been coping with multiple
class loaders for many, many years, so this nothing new for them. There
are no real compatibility implications, as the JPMS ecosystem does not
yet exist. There are certainly no detrimental security implications (on
the contrary, security should be marginally improved in the security
manager situation as getting class loaders for other classes requires
special permissions).
What exactly *are* the huge implications of this approach? My attempts
to get to the bottom of this on the spec experts list have gotten
nowhere, so hopefully I'll have better luck here.
BTW: The reasons why there are conflicts between concealed packages is a
good discussion point for another thread.
-Alan
--
- DML
