harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <m...@klomp.org>
Subject Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Date Sat, 05 Nov 2005 10:56:59 GMT
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.



Escape the Java Trap with GNU Classpath!

Join the community at http://planet.classpath.org/

View raw message