Re: dealing with ClassLoaders...

Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> wrote:


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?