[jsr294-modularity-eg] Runtime model

[Glyn Normington]

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 19/07/2007 06:50:22 
PM:

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

I have worked in approximately this area of J9 and the proposed 
overloading of defineClass doesn't sound too tricky. Sure there would be 
some unanticipated interactions which would need shaking out in the 
design, but I'd guess this would add a week or so to the overall JSR 294 
implementation effort, at least for J9 - I can't comment on HotSpot.

To me, that cost is justified by increasing the likely rate of adoption of 
superpackages.

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

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070720/6ec1f0bc/attachment.html