Mark, I don't think that is sufficient for everyone who must support older
class formats.

I can think of three intersecting requirements that an existing project
might have:

1) Wants to assign an official module name when used in the modulepath
(forward looking requirement)
2) Doesn't want to make JDK 9 a minimum version (thus no module-info.class)
3) Doesn't want to change the filename for historical purposes (especially
in a Maven repo)

Specifying the module name in the Manifest provides a suitable transition
path here. It's a relatively easy win for a developer. I propose it for
your consideration.

Cheers,
Paul

On Wed, Mar 9, 2016 at 2:05 PM, <mark.reinh...@oracle.com> wrote:

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

Reply via email to