Scenario 1:
Imagine we have a 3rd party JAR in our application plug-in's lib directory, and necessary CLASSPATH added so that it's classes may be used in our code.Most of these code libraries allow dynamic loading of classes. In order to get that through with Eclipse,most of us are aware of the trick:

Thread currentThread = Thread.currentThread();
ClassLoader oldLoader = currentThread.getContextClassLoader();

try
{
  currentThread.setContextClassLoader( XyzTest.class.getClassLoader());

  //Call the library code
}
...
...
finally
{
  currentThread.setContextClassLoader( oldLoader);
}


Scenario 2:
It is a good practice to have 3rd party library JARs wrapped up in a different plugin, and to make other application plug-ins dependent on that, so that, each of these application plug-ins do not need to have those library files individually added to their classpaths,and duplicate them.

Having said this, let's think of putting the XML parser library, Digester jars from Apache, in a plugin org.xyz.lib . I am not going into the details of how to make 3rd party jars wrapped up in a separate plugin. There are lots of articles on that in this forum, as well as other forums.
We have our application plug-in, say org.xyz.abc , and we make it dependent on org.xyz.lib

Now, let's say we start using the Digester functions. Everything compiles well, but when we try to run the application, we get a run-time error, java.lang.ClassNotFoundException

Putting our old trick in action :

Digester digester = new Digester();
...
...

Thread currentThread = Thread.currentThread();
ClassLoader oldLoader = currentThread.getContextClassLoader();

try
{
  currentThread.setContextClassLoader( XyzTest.class.getClassLoader());
  digester.parse(...);
}
...
...
finally
{
  currentThread.setContextClassLoader(oldLoader);
}

also doesnot seem to help at all, and we get the same error.

Investigating closely, we see that the current scenario is different from the first one. The class loader of the Digester class, is definitely not the same as the class loader of the currently executing application plug-in's class, because Digester is sitting on a different plug-in,and classloaders in eclipse are different for different plug-ins.
Fortunately Digester has 2 public methods:
setUseContextClassLoader(boolean use) and
setClassLoader(java.lang.ClassLoader classLoader)

Either one would make things work:

1. If we wish to use setUseContextClassLoader(boolean use) , then code should look something like this:

Digester digester = new Digester();
...
...

Thread currentThread = Thread.currentThread();
ClassLoader oldLoader = currentThread.getContextClassLoader();

try
{
  currentThread.setContextClassLoader( XyzTest.class.getClassLoader());
  digester.setUseContextClassLoader(true);
  digester.parse(...);
}
...
...
finally
{
  currentThread.setContextClassLoader(oldLoader);
}

2. Using setClassLoader(java.lang.ClassLoader classLoader) , the code would be much smaller, because Digester does the remaining job

Digester digester = new Digester();
...
...

try
{
  digester.setClassLoader( XyzTest.class.getClassLoader());
  digester.parse(...);
}
...
...

Depending on your 3rd party libraries,you need to decide which to use. Now unfortunately, if the 3rd party libraries do not provide similar methods as shown above, and always internally uses a statement like this.getClass().getClassLoader() to obtain the current classloader, then I think we are in trouble and cannot package it in a separate plug-in. Rather we then need to package with individual plugins as was shown for Scenario 1 .

6 replies so far ( Post your own)