[jsr294-modularity-eg] Runtime model

[Glyn Normington]

Further to my comments below, I'd like us to explore why loading a legacy 
class into a superpackage would be deemed to be changing, rather than 
compatibly extending, its semantics?

Andreas? Alex?

Glyn

glyn_normington at uk.ibm.com wrote on 05/06/2007 09:10:27 AM:

> 
> 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 
> 
> 
> 
> 
> _______________________________________________
> 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/20070614/918b315f/attachment.html