Hi Rodrigo, On Fri, 2005-11-04 at 17:53 -0200, Rodrigo Kumpera wrote: > I see 2 options here: > > -Allow for some implementation stuff to package private > -Have a org.apache.harmony, or something else, package tree where all > implementation stuff will reside. > > In the first case, only trusted code will be allowed to access such > code by using reflection. Otherwise the SecurityManager will stop it. > > In the second case, we will need some classloading hacks to forbid > application code to access public classes on the org.apache.harmony > tree.
Indeed. And it is most convenient to use both. You use the first (VM package private classes) when you need to have a tight coupling between the helper/vm class and the public implementation class. You use the second if you only need a helper class that doesn't need tight coupling with the public implementation class. As it turns out you don't need class loader hacks to forbid "application code" to access these public classes. A user defined class loader loadClass() method needs to handle SecurityManager.checkPackageAccess() when a security manager is installed. And since any class can only access another class through loading the class directly or indirectly through its own class loader this can be used to deny any access to classes not loaded by the bootstrap class loader. See the GNU Classpath ClassLoader createSystemClassLoader() method for an example of how this works. See the various classes in vm/reference for examples of the first. The gnu.classpath package contains some of the "public but inaccessible" classes like StackWalkers, System property accessors, etc. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
