harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Kunitz <k...@deine-taler.de>
Subject Re: [arch] VM/Classlibrary interface
Date Fri, 27 May 2005 22:53:26 GMT
On Fri, 27 May 2005, Geir Magnusson Jr. wrote:

> (Tomcat : I'd bet they fixed that (or will fix...))
> 
> Well, can't the VM just prevent non-kernel code from using them?  Maybe
> overhead too high?

You could play class loader games, however those could be
circumvented by just another customized class loader.

Doug Lea discussed the general issue in a message to this mailing
list already. IMHO the problem is, that you can make a class only
public, package-private or visible for a single class (e.g.
private static). Some finer grained controls might be usefil like
exporting a class to a particular package.

Doug referenced the paper
http://www.research.ibm.com/people/d/dgrove/papers/oopsla03.html
that discuesses a number of the issues involved and proposes a
solution based on a module concept. He referenced this page
http://www.cs.utah.edu/flux too.

He mentioned also that such features are planned for Java version 7.
Another approach right now might be to use metadata in the following way:

@Export("java.lang.*") public class VMObject {...

The bytecode linker could interpret the @Export annotation as an
override of public during resolution and prevent classes outside
of java.lang.* from linking VMObject by throwing a subclass
instance of IllegalAccessError. The compiler used should also be aware
of the @Export annotation.

If the @Export annotation is not supported by the VM or the
compiler a public class can still be linked from outside the
package, a package-private class will not. This way the author of
the class has even control over the failure mode.

Assuming that Harmony will support annotations, it shouldn't be to
complex to implement the feature, which doesn't require some
hard-coded magic or some new kind of configuration files.

Uli

Mime
View raw message