[jsr294-modularity-eg] superpackage files

[Alex Buckley]

Andreas and I are proposing that when a superpackage is stored "raw" on 
the filesystem, the JLS would:

- define a convention that the compiled superpackage definition lives in 
a file called "super-package.spkg".

- define a convention that super-package.java and super-package.spkg are 
located in a directory corresponding to the superpackage's name.

When .spkg files are not stored "raw" on the filesystem, as in Glyn's 
scenarios, the location of super-package.spkg is entirely up to the 
packaging format.

Alex

Glyn Normington wrote:
> 
> I would like to avoid too many constraints on the location of the 
> superpackage file as it will often be necessary to load the file from a 
> JAM or a JAR, for JSR 277 and JSR 291, or possibly from the network.
> 
> (Might it also be useful to generate the superpackage file on the fly in 
> some scenarios rather than have it reside in a physical location? I 
> wouldn't let that drive our design, but it's worth considering.)
> 
> Glyn
> 
> *Alex Buckley <Alex.Buckley at sun.com>* wrote on 12/04/2007 14:40:43:
> 
>  > 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
>  > _______________________________________________
>  > jsr294-modularity-eg mailing list
>  > jsr294-modularity-eg at cs.oswego.edu
>  > http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /
> /
> 
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg