On 09/02/2016 10:27 AM, Alan Bateman wrote:
On 01/09/2016 21:04, cowwoc wrote:
Another possibility (not saying it's better, just putting it out there)
is to do the following:
1. Provide a tool like "javah" that would generate module-info.java
for
non-modularized JAR files.
Look at `jdeps --gen-module-info ..`. It's a starting point to create
a source file that is easy to edit (see the slide decks).
It's not difficult to write your own ModuleFinder that reads the
module declaration from elsewhere if you really want. If you are
willing to write a module declaration for each of the 100 JAR files on
your class path then more power to you. To be honest, the feedback
over the years has almost always been that developers don't want to
take responsibility for libraries maintained by others. This usually
means they won't want to write/maintain the module declaration for
libraries that they won't own, or they don't know enough about the
code in these components to be confident that the module declaration
is correct.
-Alan
Seems the main reason why automatic modules need to see the classpath
UNNAMED module
is there might be conflicting packages on that classpath which
modularization would be non trivial
(would require custom ModuleFinders, Layers and ClassLoader factories).
Yes, automatic modules help in such scenarios.
Will Java support classpath forever or there are plans to remove it?
Asking because if classpath would be removed some time in the future
such compromise (automatic modules) is just short term win affecting
many key design decisions.
Richard
