[jsr294-modularity-eg] Runtime model

[Andreas Sterbenz]

Bryan Atsatt wrote:
>>
>> 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.

I am not a VM engineer, but they tell me that changes in this area are 
never easy and always more complicated than they may first appear. You are 
welcome to examine the HotSpot source if that sounds implausible 
(http://openjdk.java.net/groups/hotspot/)

Also, you are assuming that the VM would not have to do similar byte code 
processing/rewriting for superpackage reassignment. I don't think that is 
necessarily true because old e.g. v45.3 class file are subject to 
different rules and restrictions than current class files. Allowing them 
to join a superpackage could lead to unexpected future consequences in the 
spec and implementation. For example, HotSpot relaxes certain access 
control checks for old class files in some circumstances in order to work 
around a bug in a prehistoric version of javac. Should classes subject to 
those special rules really be allowed in a superpackage?

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

That tends to be true for the JRE libraries, but much less so for the JVM. 
Also, embedded and ME implementations tend to be less tied to the Sun 
reference implementations. I am told that neither BEA's JRockit nor IBM's 
various VMs ("Classic", J9, JikesRVM) share much code with HotSpot.
All these commercial and the various independent open source VM 
implementations would have to be modified.


Apart from those issues, static rewriting e.g. at JAR installation time 
seems preferable to runtime reassignment for other reasons. For one thing, 
it makes sure that you get the same behavior each time you start the 
application. With dynamic rewriting, the behavior could vary from run to 
run depending on how the runtime class loader is configured, which 
implementation and version of the runtime you are using, etc.

Making the semantics of a class depend on something that cannot be 
determined from the class file also has impacts tools. Any tool that 
relies on analyzing class files to determine the behavior of code might 
not function correctly. That includes compilers, static analysis tools 
(such as FindBugs), code transformers/obfuscators, etc.

For example, an application might compile correctly, but at runtime you 
could get an IllegalAccessError. Normally that would never happen as javac 
can perform access control checks based on the information in the source 
files and the class files. If superpackage membership is not determined 
until runtime, this is not possible.

Andreas.