[jsr294-modularity-eg] superpackage files

[Alex Buckley]

Eugene Vigdorchik wrote:
> Alex Buckley wrote:
>> As for the location itself, you seem to be saying that it should be
>> based on the names of member packages, not the name of the
>> superpackage itself. Is that right?
> Yes, I think it would allow the IDE to determine if the class is
> visible from certain place without the need to specify where 
> super-package.java for that class might exist. While a separate
> option for super-package.java is perfectly ok for invoking a
> standalone compiler, having the user configure the location of all
> super package files in the IDE will be too painful.

If I understand your previous mail correctly, the mapping from any 
*single* class to the super-package.java file with the class as a member 
would be one-to-many. That means quite a lot of work for a programmer to 
discover the super-package.java, but it would at least be possible given 
just a fully-qualified class name.

However, we expect a programmer to discover which superpackage has a 
given class as a member by reading the Javadoc. The principle of least 
surprise lets them take the superpackage name, apply the convention for 
name->filesystem mapping, and discover super-package.java there.

The only time an IDE will need to ask for the location of 
super-package.java is when it imports source files without corresponding 
classfiles. But I think a type in package A.B.C will probably be a 
member of a superpackage that, in practice, lives in directory A, or 
A/B, or A/B/C, or the directory above A, so the IDE can heuristically 
search those locations. The IDE knows when it has found the right 
super-package.java file for a given type in A.B.C, of course.

>> If so, what  happens when unrelated superpackages each require 
>> super-package.java to live in the same location?
> That would amount to having multiple superpackages declaration in one
> super-package.java. So super-package.java would be not about 
> declaring a single superpackage, but rather telling how a package is
> split into superpackages.

The case where a package is split into superpackages is one scenario, 
but a superpackage may in general have many packages as members. 
Depending on how a superpackage membership spans different packages, we 
could get used to seeing a single super-package.java file high up in the 
directory structure containing many superpackage declarations. That's 
starting to look more like the basis of a deployment module's 
definition. Since a superpackage does have a name and is first-class in 
the language (and VM), I prefer the simple approach of storing one 
superpackage in one super-package.java file.

Alex