[jsr294-modularity-eg] Runtime model

[Glyn Normington]

A use case for allowing unrecompiled legacy classes to belong to 
superpackages is for applications that need to support multiple versions 
of Java but exploit superpackages on Java 7. We should remember that at 
least in the first few years of Java 7, the world will be mainly at Java 5 
or 6 and application writers won't want to restrict their market to a 
fraction of the total.

If we don't support this use case, then the only applications that will 
exploit superpackages are those which are being written from scratch or 
rewritten specifically for Java 7. This will be a small minority of 
applications until the world is mainly at Java 7 in, perhaps, a decade or 
so. Seems a shame to put most applications off for so long. ;-)

Whether this use case is supported by re-defining the semantics of 
existing compiled code or automatically re-writing the classes is a detail 
we can work out if we agree we should support the use case.

Glyn

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 05/06/2007 07:54:05:

> Bryan Atsatt wrote:
> > 
> > Given a class that represents a superpackage at runtime:
> > 
> > public class SuperPackage {
> 
> We have not really gotten to details of the reflective API yet. Alex and 
I 
> will send out a proposal soon.
> 
> > So far, this seems pretty straightforward. But how would this work if 
> > the class *doesn't* name its enclosing superpackage? (I'm assuming 
here 
> > that supporting such legacy classes is an important requirement.)
> 
> I am not sure what you mean by that. If a class file does not say that 
it
> belongs to a superpackage, the class does not belong to a superpackage.
> Such existing class files will work fine in a JDK 7 / superpackage 
> environment and behave exactly as they behaved before.
> 
> As with all past updates to the Java language and VM specifications, we 
> cannot and should not change the semantics of existing compiled code.
> 
> That is why we are making it easy to migrate existing code to 
> superpackages: all you have to do is create one file 
(super-package.java) 
> and recompile. Or if you don't want to do that, one could come up with 
> with a tool that takes an existing set of class files and creates a 
.spkg 
> file and rewrites the classes to include the superpackage membership 
> information.
> 
> Of course, you don't have to migrate all existing code at once (or at 
> all). Classes that are a member of a superpackage and classes that are 
not 
> will happily interoperate in all the right ways. That includes legacy 
> classes packaged with the classes of a superpackage in a deployment 
module 
> (JSR 277 or otherwise).
> 
> Andreas.
> 
> _______________________________________________
> 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/20070605/1386135a/attachment.html