[jsr294-modularity-eg] Exported packages and wildcard expansion
glyn_normington at uk.ibm.com
Tue Apr 24 05:34:41 EDT 2007
Thanks Andreas. I'm happy to wait for the separate compilation strawman to
see how these concerns are addressed.
Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 23/04/2007 17:40:38:
> Glyn Normington wrote:
> > The current strawman allows a package to be exported by specifying a *
> > wildcard such as example.foo.myapp.*. The wildcard is expanded by
> > This places some constraints on separate compilation. The superpackage
> > must be compiled at a point in time when all the classes belonging to
> > the package are (a) known and (b) available to javac.
> > So some scenarios must be handled carefully. Suppose two developers
> > collaborating to produce a superpackage and both are contributing
> > classes to an exported package. It is not sufficient for them to share
> > the superpackage source file and any shared code. They must also share
> > the full set of contributed classes so that javac can perform the
> > correct expansion.
> This is what the separate compilation proposal that is the other aspect
> JSR 294 was designed for. It will allow developers to reference code at
> compile time with only signatures being available but not the full
> or class files.
> We are working on producing a strawman proposal as we did for
> superpackages, but we are not quite there yet. In the meantime, the best
> description of the idea can be found in Gilad's blog  and his JavaOne
> presentation from last year .
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-eg