[jsr294-modularity-eg] Runtime model
bryan.atsatt at oracle.com
Wed Jul 18 16:26:56 EDT 2007
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,
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-eg