DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43794>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43794 ------- Additional Comments From [EMAIL PROTECTED] 2007-12-17 23:36 ------- The error message in question is produced in org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(String compilerType, Task task) after Javac.execute() calls compile() which calls it. The search in getCompiler(..) is compiler type specific, but it looks like you are running java-6 on linux or unix, so you get the common case where it calls doesModernCompilerExist() and if this returns false, it throws the error. Interestingly, this method doesn't appear to use either java.home or JAVA_HOME directly. Instead it tries to load it in two ways, returning false if both fail - Class.forName(MODERN_COMPILER); - CompilerAdapterFactory.class.getClassLoader().loadClass(MODERN_COMPILER) where MODERN_COMPILER = "com.sun.tools.javac.Main" I would think those two are usually equivalent, so the question is how CompilerAdapterFactory.class (and presumably Javac.class) could get loaded in a classloader that doesn't have tools.jar on it's classpath. The message should just say something like "Can't find com.sun.tools.javac.Main on the classpath that loaded the javac task. Make sure tools.jar from the JDK is on the classpath." It seems like the bootclasspath and classpath task attributes could also be used to supplement the search. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
