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
