The property java.system.class.loader is supposed to allow JVM users to change the default class loader to another class. org.apache.bcel.util.ClassLoader cannot be used with this property. Setting -Djava.system.class.loader=org.apache.bcel.util.ClassLoader provokes this at load time. Error occurred during initialization of VM java.lang.Error: java.lang.IllegalStateException: recursive invocation java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed mode) this bug also applies to SVN-HEAD.
This link might provide additionnal informations: http://www.mail-archive.com/bcel-dev%40jakarta.apache.org/msg00451.html
hmmm. I attempted to do as you suggest, but can't seem to shake the java.lang.Error: java.lang.IllegalStateException: recursive invocation error. could getParent() be returning org.apache.bcel.util.ClassLoader, in this case? Unfortunately the error occurs before debugging begins. Any ideas?
To reproduce: public class EmptyMain { public static void main(String[] args) { } } neumann@Silvester:/tmp$ javac EmptyMain.java neumann@Silvester:/tmp$ java -Djava.system.class.loader=org.apache.bcel.util.ClassLoader -cp /home/neumann/Libs/bcel-5.1/bcel-5.1.jar:. EmptyMain Error occurred during initialization of VM java.lang.Error: java.lang.IllegalStateException: recursive invocation neumann@Silvester:/tmp$ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed mode) A tentative patch will soon follow.
Created attachment 17501 [details] Tentative patch. This is a tentative patch. It may not well be the solution to the problem, but it does remove the IllegalStateException error. I think the problem is that, once initSystemClassLoader is called (it's in java.lang.ClassLoader), no class should depend load java.lang.ClassLoader or you get a indirectly recursive call of initSystemClassLoader.
Now that I think of it, my idea of the source of the problem is probably wrong so disregard the explanation after the patch. The patch, though, still solves the problem.
tentative this looks ok ...I am not 100% but since it solves the problem I've just committed it
Created attachment 18930 [details] Patch for ClassLoader constructor I created a subclass of org..ClassLoader (lets call is SLoader) and tried to use it as the system class loader, but it gave me the same error as described in the initial comment. The class looks like this: public class SLoader extends ClassLoader{ [...] public SLoader(java.lang.ClassLoader deferTo) { super(deferTo, new String[]{ "java.", "javax.", "com.sun.", "sun."} ); } [...] } The JVM calls the above constructor when the class is passed with the -Djava.system.class.loader VM argument. This constructor then calls the constructor of the org..ClassLoader public class ClassLoader extends java.lang.ClassLoader { [...] public ClassLoader(java.lang.ClassLoader deferTo, String[] ignored_packages) { this(ignored_packages); this.repository = new ClassLoaderRepository(deferTo); } [...] } As you can see, there is no explicit call the any constructor of the java..ClassLoader class. This causes its default constructor to be invoked, which tries to resolv the parent class loader by calling java..ClassLoader.getSystemClassLoader() which causes the loop in the class loader hierarchy. The appended patch fixes this by explicitly invoking the java.lang.ClassLoader.ClassLoader(ClassLoader parent) constructor which does not use the getSystemClassLoader() method. A question about the bug reporting process: Should I REOPEN the bug and then set it RESOLVED/FIXED again?