Has it been considered to apply the export modifier to the package-info.java?
Remi Forax
forax at univ-mlv.fr
Wed Oct 14 13:46:09 UTC 2015
Good question,
the main drawback i see, is that it that you can not retrofit a non-module jar to a module jar just by adding one file.
Rémi
----- Mail original -----
> De: "Peter Kriens" <peter.kriens at aqute.biz>
> À: "Mark Reinhold" <mark.reinhold at oracle.com>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Lundi 12 Octobre 2015 17:30:43
> Objet: Re: Has it been considered to apply the export modifier to the package-info.java?
>
> > Why would this be more convenient?
>
> For the same reason it is more convenient to put the public/private modifier
> in the class source file instead of the package-info file?
>
> The subsidiarity principle says that you want to apply this information at
> the lowest reasonable level. People that then work in that package are
> directly aware of this information. The close this information is to the
> source, the better the chance it gets maintained. It also makes refactoring
> easier since it does not require a global overview. And it does not require
> typing the package name since this is already implied.
>
> When I meant zero overhead I included my conclusion that module-info.java
> cannot be a human editable file. In any practical situation it can only be
> generated from external (build) information. The module-info.java file just
> does not contain sufficient information (versions!) to drive a build so
> there MUST be another artifact that contains a superset of the module-info
> aspects. To prevent redundancy, the module-info should thus be generated.
> This required build step could then easily include the exported packages. So
> the only overhead would be in the build.
>
> Thanks, kind regards,
>
> Peter Kriens
>
>
> > On 5 okt. 2015, at 20:54, mark.reinhold at oracle.com wrote:
> >
> > 2015/9/28 9:57 -0700, peter.kriens at aqute.biz:
> >> The current proposal places the export in a module-info file. It would
> >> be much more convenient to place this as a modifier on the
> >> package-info.java.
> >>
> >> public package com.foo;
> >
> > Why would this be more convenient?
> >
> > Placing all of the export clauses in the module descriptor makes it easy
> > to see, by reading just one file, exactly what a module is exposing to
> > the outside world. Sprinkling them across package-info.{java,class}
> > files makes that much more difficult.
> >
> >> Since it seems inevitable that there is a tooling step this would
> >> require little effort and cause no runtime overhead.
> >
> > There would be some additional run-time overhead. In order to enforce
> > access control a JVM would have to search for and, if found, read a
> > separate package-info.class file for every package in a module. This
> > overhead might not be terribly significant, but it would be non-zero.
> >
> > - Mark
>
>
More information about the jpms-spec-observers
mailing list