[jsr294-modularity-eg] Static compilation

[Glyn Normington]

"Michal Cierniak" <cierniak at google.com> wrote on 04/05/2007 20:57:14:

> JSR-277 already has a sealing assumption that would probably make my
> example not work although I must say that I haven't thought about this
> detail very much yet.  It's great that Rob's comments started this
> discussion and we can think of this issue in terms of JSR-294.  And
> yeah, if there are no problems with this, we should design in some way
> to seal module membership at the JSR-294 level to make writing static
> compilers easier.

Ok.

> 
> Glyn,
> I assume that OSGi provides mechanisms that make Rob and Vitaly happy?

Unfortunately, no. OSGi is essentially a (highly sophisticated) custom 
class loader network so is not sufficient.

Glyn

> 
> Michal
> 
> On 5/4/07, Glyn Normington <glyn_normington at uk.ibm.com> wrote:
> >
> > "Michal Cierniak" <cierniak at google.com> on 02/05/2007 17:52:32:
> >
> >
> >  > On 5/2/07, Glyn Normington <glyn_normington at uk.ibm.com> wrote:
> >  > > "Michal Cierniak" <cierniak at google.com> wrote on 01/05/2007 
18:33:07:
> >  > >
> >  > >  > We haven't talked about such details but my
> >  > >  > assumption was that it should be possible to dynamically load 
a
> > class
> >  > >  > that extends any non-final class including those classes that 
are
> > not
> >  > >  > exported.
> >  > >
> >  > > My expectation is different, as you may have guessed.
> >  >
> >  > Glyn,
> >  >
> >  > I think that your expectation is completely reasonable but I think
> >  > that we would need more mechanisms to enforce this problem because 
the
> >  > JSR-277 APIs as presented in the EDR allow you to arrive at the
> >  > problem described by me.  Here's some pseudocode that shows my
> >  > scenario (it's pseudo in the sense that I didn't look up carefully 
the
> >  > APIs or tried to compile it, so that are probably some typos 
there):
> >  >
> >  > class A {
> >  >   // class is in a module M and is not exported
> >  >   public void F() {
> >  >      ClassLoader cl = A.class.getClassLoader();  // M's classloader
> >  >      byte[] b = getBytes();  // bytes defining a class that 
subclasses A
> >  >      Class b = cl.defineClass("B", b, 0, b.length);
> >  >   }
> >  >   byte[] getBytes() { ...}
> >  > }
> >  >
> >  > In this example, I use A's classloader to create class B which is a
> >  > subclass of A.
> >  >
> >  > Dealing with classloaders is always tricky, so I may be missing
> >  > something here.  What do you think about my example?
> >
> > Thanks for the example as it makes discussion easier.
> >
> > I agree that more mechanisms would be required to enable static 
compilation,
> > but I would have thought any static compilation system would constrain 
the
> > contents of modules it was compiling pretty strongly to prevent the 
contents
> > (classes in this example) changing at runtime. I probably see things
> > differently to Rob Yates, but I wouldn't expect JSR 294 to provide a 
"free
> > ride" for a static compilation system - just give it the constructs to 
hang
> > off. I'd expect static compilation to check its own constraints of 
modules
> > it was compiling and also use some kind of sealing mechanism to 
preserve the
> > integrity of the compiled output.
> >
> > Glyn
> >
> >
> >
> >  ________________________________
> >
> >
> >
> >
> > 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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070505/eb62c22d/attachment.html