correction below...
On Feb 7, 2007, at 9:06 AM, Geir Magnusson Jr. wrote:
On Feb 7, 2007, at 7:56 AM, Tim Ellison wrote:
Geir Magnusson Jr. wrote:
On Feb 7, 2007, at 7:00 AM, Tim Ellison wrote:
Rather than a hidden class loader we can filter the app
classloader's
delegation to the bootclassloader so it only gets an opportunity
to load
API types. Let me have a quick play ...
Yes - that's the same concept, but I can see how that's going to be
easier, because there's less machinery needed to figure out who is
asking. If you don't mind, I'll take a wack.
The hack I was thinking of is to override loadClass in
URLClassLoader,
and put a filter in there to only delegate to the parent if you
are the
system (i.e. what I would call the 'application') class loader and
the
package is one that you want to pick up.
Perfect. I was looking at stuffing it into the SubURLCLassloader
loadClass, but this is much cleaner.
My first pass through only allows JSE API types, but that likely
won't
be great as it doesn't account for people putting JUnit etc. on the
bootclasspath and expecting it to work out. We may need to flip it
around and have a list of explicitly hidden packages:
There are two ways I can think of :
A) Have a list of system-loader verboten (mx4j, xalan, etc...)
or
B) Two Phase :
1) list of things on the public surface of the Java SE API :
java.
javax.
etc
so we can fail-fast for the majority of stuff and then
2) A list of things that the VM knows is allowed because they were
placed on the bootclasspath or extension classpath by the user.
and if you don't match, it's forbidden.
I actually think that the first way is faster, since the list is
shorter (at least right now)
So the next question is for the non-static list (i.e. for option A
or the second phase of B).
This has to come from the VM, as the VM knows, and it's going to
get messy if you want to do sophisticated things w/ the
classloaders and such. (aka "OSGi")
So...
I'd like to add a new luni-kernel abstract class :
o.a.h.kernel.vm.VMUtillityBase.java
that has (depending on if we choose A or B) one of
String[] getAppAllowedSystemLoaderList() //or something
String[] getAppDeniedSystemLoaderList() //or something
that for the Allowed version has an empty list (maybe we put JUnit
in there...) and for the Denied version has mx4j, xalan
and a class
o.a.h.kernel.vm.VMUtility.java
that extends VMUtilityBase
so and use VMUtility in URLClassloader to get the list. This way,
there are no VM changes allowed now, VMs can then provide their own
"there are no VM changes *required* now"
o.a.h.k.v.VMUtillity to reflect user-added stuff on bootclasspath
and extentionclasspath, and in the future, we can add default
functionality to VMUtilityBase and use it immediately w/o requiring
changes to the VMs.
Does this make any sense?
geir
protected synchronized Class<?> loadClass(String className,
boolean resolveClass) throws ClassNotFoundException {
if (this == getSystemClassLoader()) {
int index = className.lastIndexOf('.');
String pkgName = index > 0 ? className.substring(0,
index) : "";
System.out.println("Checking visibility for " + pkgName);
if (!pkgName.startsWith("java.") && !pkgName.startsWith
("javax.")
&& !pkgName.startsWith("org.ietf.jgss")
&& !pkgName.startsWith("org.omg")
&& !pkgName.startsWith("org.w3c.dom")
&& !pkgName.startsWith("org.xml.sax")) {
throw new ClassNotFoundException(className);
}
}
return super.loadClass(className, resolveClass);
}
