> On Apr 25, 2017, at 8:44 AM, David M. Lloyd <david.ll...@redhat.com> wrote: > 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).
The real question is how are those ClassLoaders related. Do they have a common parent ClassLoader using the current hierarchical class loading scheme so that there would be at least one common class loader for shared classes, or are we talking about creating a virtual loader environment that looks more like JavaEE or other “container” environments where one could count on ClassLoader separation keeping any “static” class data from being visible to more than a single one of these ClassLoader instances. I use a tree based ClassLoader system in most of my applications which have plugins or other disconnected ClassLoading environments, and there will typically be a common ClassLoader parent between those ClassLoader instances and the java runtime. This mechanism along with a SecurityManager provides a great deal of separation and isolation for my applications. Gregg > 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
