[jsr294-modularity-eg] Runtime model

[Bryan Atsatt]

Glyn Normington wrote:
> 
> *Andreas Sterbenz <Andreas.Sterbenz at sun.com>* wrote on 14/06/2007 
> 06:35:48 PM:
> 
>  > Glyn Normington wrote:
>  > >
>  > > 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?
>  >
>  > Sure. I think we should start by examining the use cases. Some of the
>  > questions in my mind are:
>  >
>  > When is it is necessary to dynamically draft legacy classes into the
>  > superpackage?
> 
> To allow applications to support multiple versions of Java and 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.
> 
>  >
>  > Why are approaches that expose classes that are a member of a 
> superpackage
>  > and legacy classes as one "component" (module, bundle, etc.) not
>  > sufficient? They can coexist just fine.
> 
> Agreed, but this would delay the uptake of superpackages.
> 
>  >
>  > Another approach is static class file rewriting. When is that not 
> sufficient?
> 
> 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. I 
> agree class rewriting is probably sufficient, but I'm not sure the 
> significant extra complexity is necessary.


If by "static" here you mean at development time, then yes, this may be 
a reasonable solution: create a tool to take legacy classes and inject a 
superpackage name. This implies upgrading the class file version, 
doesn't it? If so, that may be more complex. Obviously it is easy to add 
an appropriate .spkg file to a jar or a module.

The use case I have in mind is the module developer who must bundle 
"legacy" binaries, but would like to limit external access to those 
classes. Since the module system relies on superpackages to impose 
access control, it will be impossible to support any export policy other 
than "all" without a mechanism to bind legacy classes into a superpackage.

While I think development time class rewriting is likely a decent 
solution, it would be unreasonably complex/expensive if deferred to 
runtime. Does anyone have a use case for binding legacy classes to a 
superpackage at runtime?

// Bryan

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