[jsr294-modularity-eg] Static compilation

[Michal Cierniak]

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.

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

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