http://nagoya.apache.org/bugzilla/show_bug.cgi?id=630
*** shadow/630 Fri Feb 16 14:27:26 2001
--- shadow/630.tmp.13888 Fri Feb 16 14:27:26 2001
***************
*** 0 ****
--- 1,134 ----
+ +============================================================================+
+ | Class loader for <java> with specified classpath incorrectly uses system c |
+ +----------------------------------------------------------------------------+
+ | Bug #: 630 Product: Ant |
+ | Status: NEW Version: 1.3 Beta 2 |
+ | Resolution: Platform: All |
+ | Severity: Major OS/Version: All |
+ | Priority: Medium Component: Core tasks |
+ +----------------------------------------------------------------------------+
+ | Assigned To: [EMAIL PROTECTED] |
+ | Reported By: [EMAIL PROTECTED]
|
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ OVERVIEW DESCRIPTION
+ --------------------
+
+ When using a specified classpath (by either the
+ classpath attribute or nested <classpath> elements)
+ with the <java> task, the AntClassLoader is constructed
+ so that the system class loader is used first. That seems
+ wrong.
+
+ Line 122 of ExecuteJava.java reads:
+
+ AntClassLoader loader = new AntClassLoader(project, classpath);
+
+ This constructs a class loader that consults the system
+ class loader first for classes.
+
+ It should read:
+
+ AntClassLoader loader = new AntClassLoader(project, classpath,
+ /*systemFirst*/ false);
+
+ After all, if the user has specified a classpath, he
+ presumably wants it to be used preferentially to load
+ classes.
+
+ STEPS TO REPRODUCE
+ ------------------
+
+ Create a file App.java:
+
+ ---
+ public class App {
+ public static void main(String[] argv) {
+ MyClass m = new MyClass();
+ }
+ }
+ class MyClass { }
+ ---
+
+ Compile this file, generating public class App and
+ package-scoped class MyClass. Put both into a jar
+ file, app.jar. List app.jar in your CLASSPATH
+ environment variable. Create a build.xml file:
+
+ <project name="bug" default="run" basedir=".">
+ <target name="run">
+ <java classpath="app.jar" classname="App"/>
+ </target>
+ </project>
+
+ Run ant.
+
+ ACTUAL RESULTS
+ --------------
+
+ BUILD FAILED
+
+ /home/saffron/kelly/junk/build.xml:4: java.lang.IllegalAccessError: try to
+ access class MyClass from class App
+ --- Nested Exception ---
+ java.lang.IllegalAccessError: try to access class MyClass from class App
+ at java.lang.reflect.Method.invoke(Native Method)
+ at org.apache.tools.ant.taskdefs.ExecuteJava.execute
+ (ExecuteJava.java:126)
+ at org.apache.tools.ant.taskdefs.Java.run(Java.java:260)
+ at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:123)
+ at org.apache.tools.ant.taskdefs.Java.execute(Java.java:87)
+ at org.apache.tools.ant.Target.execute(Target.java:153)
+ at org.apache.tools.ant.Project.runTarget(Project.java:898)
+ at org.apache.tools.ant.Project.executeTarget(Project.java:536)
+ at org.apache.tools.ant.Project.executeTargets(Project.java:510)
+ at org.apache.tools.ant.Main.runBuild(Main.java:421)
+ at org.apache.tools.ant.Main.main(Main.java:149)
+
+ EXPECETED RESULTS
+ -----------------
+
+ BUILD SUCCEEDED
+
+ BUILD DATE AND PLATFORM
+ -----------------------
+
+ Ant 1.3 Beta 2 built 16 Feb 2001 1.05pm PST on FreeBSD
+ 4.2 using FreeBSD JDK 1.2.2
+
+ ADDITIONAL BUILDS AND PLATFORMS
+ -------------------------------
+
+ Ant 1.3 Beta 2 built 16 Feb 2001 12.35pm PST on Windows
+ 98 Sun JDK 1.3.0.
+
+ ADDITIONAL INFORMATION
+ ----------------------
+
+ You can work around the problem by either removing the
+ classpath attribute from build.xml, or removing app.jar
+ from the CLASSPATH environment variable.
+
+ We'd rather not do that, though: we're shipping
+ build.xml files with the classpath attribute. Some
+ customers are have the problem-causing .jar file in
+ their CLASSPATH, and some don't. It's created a
+ support problem having to tell users to either remove
+ the .jar file from their CLASSPATH or edit the
+ build.xml file.
+
+ To repair the problem, modify line 122 of
+ ExecuteJava.java to read:
+
+ AntClassLoader loader = new AntClassLoader(project, classpath,
+ /*systemFirst*/ false);
+
+ This makes sense: the user has specified a classpath in
+ build.xml, so that one should be used preferentially.
+ Using the other constructor (which defaults systemFirst
+ to true) means that some classes may be loaded by the
+ system class loader, and some by the classpath
+ specified in build.xml.
