[jsr294-modularity-eg] Runtime model

[Bryan Atsatt]

Andreas Sterbenz wrote:
> Bryan Atsatt wrote:
>> If the superpackage mapping could be done dynamically, then the OSGi 
>> runtime can take the burden from the developer, layering a superpackage 
>> over the legacy classes only when on Java 7.
> 
> This is a fine requirement. There should be nothing in the spec to prevent 
> OSGi from doing that and there is nothing in the current proposal that does.
> 
> The question is whether a mechanism that allows modifying legacy classes 
> should be part of the JSR 294 spec that every JDK and JVM implementation 
> has to implement or if this is something that can be left up to OSGi. 
> Given that language/VM spec changes have an extremely high cost and that 
> there are many more JVM implementations than OSGi implementations, it 
> would be cheaper to leave it to OSGi.


All we are talking about here is something as simple as a 
superpackegeName parameter on an overload of ClassLoader.defineClass().

The alternative is for OSGi and all other such systems (e.g. Oracle 
shared-libraries) to do fairly heavy-weight byte-code processing to 
inject that name.

Is it really that "costly" to support such a defineClass() overload? 
Most JVM licensees simply re-use generic parts of Sun's implementation, 
don't they?

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