New class loader code for generated classes in 1.5R4 to fix bug 166530 causes a regressions when used with some JDK 1.4 releases as was reported by Anreas Rozek: After having "installed" Rhino 1.5r4 on my system, many of my old Rhino scripts fail to run any longer. Reason: Java class lookup seems to be broken! Here are some facts: - Java classes and interfaces within JAR files or directory trees (within my "ClassPath") are no longer found - although they are definitely present - unpacking JAR files (or moving directory tree contents) into a folder such as $JavaHome/jre/lib/classes solves the problem - however, I would even have to unpack the Rhino library (js.jar) - going back to Rhino 1.5r3 immediately solves the problem as well - I'm currently running Sun JDK 1.4.0_03 - but the problem exists as well under 1.4.0_02, 1.4.0_01 and 1.3.?_06 (don't remember the version number) I already had a similar problem with "BeanShell" (www.beanshell.org) and JDK 1.4.1 a few weeks ago - I then deci- ded to go back to 1.4.0_03 as this solved most of the problems. Later, a colleague ran into similar class loading problems and had to go back to 1.4.0 as well...(very strange) - I'm running Win98SE, she was running WinXP Professional
It seems the regression is caused by a JDK bug on Win98 when it returns for Rhino classes loaded from CLASSPATH variable a class loader that can only load classes from Rhino jar or system locations and can not find classes from other components of CLASSPATH. On the other hand a class loader returned by Thread.getContextClassLoader() is able to find classes from all CLASSPATH components and since Rhino 1.5R3 uses that for class loading, the problem only appeared in 1.5R4.
Created attachment 116297 [details] [diff] [review] Use Thread.getContextClassLoader as the last resort to find classes The patch does not restore 1.5R3 since it used Thread.getContextClassLoader() initially and only then it tried a class loader for Rhino classes leading to various problems. The patch instead uses Thread.getContextClassLoader() as a last attempt to find the required class thus preserving child-parent class loader semantics between generated and Rhino classes.
I commited the patch, for verification I asked Anreas Rozek to check it, let see what he will report.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Can we mark this one Verified? Have we heard from Anreas?
Marking as verified assuming that silence of Anreas Rozek means it is OK for him...
Status: RESOLVED → VERIFIED
Targeting as resolved against 1.5R4.1
Target Milestone: --- → 1.5R4.1
You need to log in before you can comment on or make changes to this bug.