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

[Peter Kriens]

> 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