Multiple versions of a non-exported dependency
Alan.Bateman at oracle.com
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