Re: dealing with ClassLoaders...
Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> wrote:
Martin Gregorie <martin@address-in-sig.invalid> wrote:
public class MAClassLoader extends ClassLoader
{
[ no snip ]
}
I hope this is useful info.
On further examination, I think it isn't as simple as that.
Essentially, this "empty" ClassLoader-subclass would pass
everything through to the parent classloader (or the pre-
mordial one, absent a parent) and thus not be associated to
any of the classes loaded through it, thus provide no
isolation at all.
My approach now is to override loadClass(String,boolean):
@Override // ClassLoader
public Class<?> loadClass( String name, boolean resolve)
throws ClassNotFoundException
{
Class<?> res = null;
if (name != null && name.startsWith(PACKAGE_PREFIX)) {
synchronized (this) {
res = m_classes.get(name);
if (res != null) { return res; }
byte[] classData = null; // TODO: get class data
res = defineClass(name,classData, 0, classData.length);
m_classes.put(name, res);
}
} else {
// if this fails, then so be it:
res = super.findSystemClass(name);
}
if (resolve && res != null) { resolveClass(res); }
return res;
}
// m_classes is Map<String,Class<?>> initialized to new HashMap<>()
The hole that remains is at the TODO marker in the code snippet.
I'd like to use system code to pull the byte[] or ByteBuffer out
of whatever jar-file or unpacked directory the whole app is deployed
to.
The then-branch of the big "if" is to solve a should-be-simple task:
Use the system class loader's code to locate the class, but let "this"
classloader end up being associated with it.
How can I do that?