[jsr294-modularity-eg] Static compilation

[Bryan Atsatt]

Michal Cierniak wrote:
> 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?

FYI: the defineClass() method can't be called quite this easily, since 
it is protected, but it can certainly be done with reflection.

> 
> Michal
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>