[jsr294-modularity-eg] superpackage files
Alex.Buckley at Sun.COM
Mon Apr 16 14:41:37 EDT 2007
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
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.)
> *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
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-eg