[jsr294-modularity-eg] Runtime model

[Bryan Atsatt]

Andreas Sterbenz wrote:
> 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.

Wow. (Contrary to how I feel at the moment, I'll do my best to remain 
professional in my response here.)

I've been operating under the assumption that this process is a 
*collaboration*. Apparently that is mistaken.

I can only read your response to mean that you see the EG as nothing but 
  reviewers of the work product created by the spec lead(s). That 
certainly fits the pattern so far.

If this is in fact your intention, please let us know. Then each of us 
will be able to make an informed decision about continuing to "participate".

// Bryan

> 
>> 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
>