Has it been considered to apply the export modifier to the package-info.java?

[Remi Forax]

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