[jsr294-modularity-eg] Runtime model

[Andreas Sterbenz]

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.