[jsr294-modularity-eg] Runtime model

[Bryan Atsatt]

Glyn Normington wrote:
> 
> *Bryan Atsatt <bryan.atsatt at oracle.com>* wrote on 28/06/2007 11:28:30 PM:
> 
>  >
>  >
>  > 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?
> 
> Yes - the one above! ;^) If we only support the development time class 
> rewriting solution, then in that scenario, I suspect an application 
> developer would probably choose not to bother with superpackages rather 
> than have to build, ship, and maintain a separate version of the 
> application specifically for Java 7 and beyond.

Excellent point. I agree. While development time binding might be 
functionally equivalent, the user experience is substantially different 
and burdensome.

> I'd estimate this would defer the widespread adoption of superpackages 
> by 7-10 years. (This may seem pessimistic, but I think the majority of 
> application developers are only just becoming comfortable hard 
> pre-req'ing Java 5 and the generics JSR was at roughly the stage JSR 294 
> is at now about 7 years ago. Plus I'd expect the rate of migration to 
> new releases to slow down rather than speed up in the future.)

Right. Sun is even working on an additional release model for the 
specific purpose of enabling slower uptake of updates.


So. Let me invert the question: why *not* support runtime binding?

There are several obvious approaches:

1. A Superpackage.bindClass() method that takes a class file and 
produces a new class file.

2. A new String parameter "superpackageName" on ClassLoader.defineClass().

3. A new Superpackage parameter on ClassLoader.defineClass().


// Bryan

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