[jsr294-modularity-eg] superpackage files
Alex.Buckley at Sun.COM
Thu Apr 12 09:40:43 EDT 2007
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.
More information about the jsr294-modularity-eg