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

[mark.reinhold at oracle.com]

2015/10/12 8:30 -0700, peter.kriens at aqute.biz:
>> 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.

I understand the principle, but in this case I think it's trumped by the
goal of readability.  In practice package-info.java files aren't good
for very much, so people tend to ignore them.  Putting all of a module's
export clauses in one obvious place, morever, makes it easy to tell, at
a glance, what it exports for external use.

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

Yes, this information could be gathered at build time and inserted into
module-info.java or .class (or whatever) files, so I agree that run-time
overhead need not be an issue.

- Mark