Multiple versions of a non-exported dependency

Alan Bateman Alan.Bateman at
Thu Sep 1 17:11:16 UTC 2016

On 01/09/2016 15:35, David M. Lloyd wrote:

> Yeah having the class path remain on the legacy application class 
> loader is demonstrably better for interop.  But new modules?  Does 
> that make sense?
Yes, specifically automatic modules where a JAR file is moved from the 
class path to module path without any changes. Also any library that is 
migrated to an explicit module. If the library is used to being on the 
class path today, and it's not in a world of hurt that is split packages 
or cycles, then the effort to make it an explicit module might be minimal.

> :
> Anyway using interoperability as an argument is very weak as long as 
> "export dynamic *" or any variation thereof is considered to be an 
> acceptable solution to #ReflectiveAccessToNonExportedTypes.  In order 
> to have proper interoperability for any reflection-using or reflected 
> module, you have to do this, which defeats the primary security 
> measure of modules.  Isn't this a much more likely interop problem 
> than putting modules (something that never existed before) into their 
> own class loaders?

Modules might be new but a lot existing code that will be migrated. I 
don't wish to engage on the #ReflectiveAccessToNonExportedTypes topic in 
this thread, mostly because that topic is still open on the JSR list and 
there are several overlapping threads already.


More information about the jigsaw-dev mailing list