[jsr294-modularity-eg] superpackage files

[Glyn Normington]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070413/05dcabb9/attachment.html