JPPF Issue Tracker
Please log in to bookmark issues
CLOSED  Bug report JPPF-189  -  IllegalAccessError starting node with dependencies on common and server libs
Posted Sep 21, 2013 - updated Dec 27, 2014
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
  • Assigned to
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Category
  • Resolution
  • Priority
  • Reproducability
  • Severity
  • Targetted for
    icon_milestones.png JPPF 3.3.x
Issue description
When starting a node which has dependendencies on jppf-common.jar and jppf-server.jar, the following error is raised:
2013-09-21 08:05:43,440 [DEBUG][org.jppf.utils.JPPFDefaultUncaughtExceptionHandler.uncaughtException(44)]: Uncaught exception in thread Thread[main,5,main]
java.lang.IllegalAccessError: tried to access method org.jppf.server.node.remote.RemoteClassLoaderManager.<init>(Lorg/jppf/server/node/JPPFNode;)V from class org.jppf.server.node.remote.JPPFRemoteNode
  at org.jppf.server.node.remote.JPPFRemoteNode.<init>(
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
  at java.lang.reflect.Constructor.newInstance(
  at java.lang.Class.newInstance(
  at org.jppf.node.NodeRunner.createNode(
  at org.jppf.node.NodeRunner.main(

Steps to reproduce this issue
  • start a driver
  • start a node with jppf-common.jar and jppf-server.jar in its classpath
  • ==> an IllegalAccessError is is logged

Comment posted by
Sep 21, 08:27
The explanation of this issue can be found here ( When the node has jppf-common.jar and jppf-server.jar in its classpath, the class JPPFRemoteNode is explicitely loaded by the JPPF class loader, whereas for RemoteClassLoaderManager the class loader is not explicitely specified, thus it will be loaded by the main application class loader. Thus both classes are in different runtime packages, even though the package names are the same: they differ via the classloader.

The explicit loading of JPPFRemoteNode is done in org.jppf.node.NodeRunner.createNode() as follows:
String className = "org.jppf.server.node.remote.JPPFRemoteNode";
Class clazz = getJPPFClassLoader().loadJPPFClass(className);
The problem is that loadJPPFClass() bypasses the class loader delegation model and forces the specified class loader to load the class. Thus both classes end up loaded by different class loaders. So the fix is to use the default delegation model:
String className = "org.jppf.server.node.remote.JPPFRemoteNode";
Class clazz = getJPPFClassLoader().loadClass(className);
This works both with and without the common and server libs in the node's classpath.
Comment posted by
Sep 21, 09:24
Fixed. Changes committed to SVN:

The issue was updated with the following change(s):
  • This issue has been closed
  • The status has been updated, from Confirmed to Closed.
  • This issue's progression has been updated to 100 percent completed.
  • The resolution has been updated, from Not determined to RESOLVED.
  • Information about the user working on this issue has been changed, from lolo4j to Not being worked on.