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.
-Alan
