[jsr294-modularity-eg] Runtime model
glyn_normington at uk.ibm.com
Fri Jul 20 05:51:51 EDT 2007
Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 19/07/2007 06:50:22
> Bryan Atsatt wrote:
> >> The question is whether a mechanism that allows modifying legacy
> >> should be part of the JSR 294 spec that every JDK and JVM
> >> 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
> >> 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
> > 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
> welcome to examine the HotSpot source if that sounds implausible
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
> Also, you are assuming that the VM would not have to do similar byte
> processing/rewriting for superpackage reassignment. I don't think that
> 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
> spec and implementation. For example, HotSpot relaxes certain access
> control checks for old class files in some circumstances in order to
> around a bug in a prehistoric version of javac. Should classes subject
> 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
> > don't they?
> That tends to be true for the JRE libraries, but much less so for the
> Also, embedded and ME implementations tend to be less tied to the Sun
> reference implementations. I am told that neither BEA's JRockit nor
> 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
> 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
> 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.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-eg