2016/3/9 10:53 -0800, pbened...@apache.org: > SOTMS: > "We can, instead, treat org-baz-qux.jar as an *automatic module* by placing > it, unmodified, on the module path rather than the class path. This will > define an observable module whose name, org.baz.qux, is derived from that > of the JAR file so that other, non-automatic modules can depend upon it in > the usual way" > > I think more detail is necessary here. JARs stored in Maven, for example, > are not fully qualified. It's just a simple JAR name and version numbers > are typically included. > > So if commons-collections-4.0.0.jar is dropped into the module path, is the > module name "commons.collections.4.0.0"?
No, the name is "commons.collections", and the version string is "4.0.0". > PS: Please see my previous email where I propose the idea that the manifest > define the module name. This will allow jars to name themselves (i.e., > their own module names) in a cross-compatible JDK way when dropped into the > module path; ignored when on the classpath. I believe that's a better > solution than using the file name as the module name. That could work for new JARs but it won't work for all the JARs present on Maven Central today, and that's kind of the whole point of automatic modules. If you're willing and able to modify a JAR file then you might as well make it into a true module. - Mark
