DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26404>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26404 jikes compiler adaptor doesn't support modern jikes options Summary: jikes compiler adaptor doesn't support modern jikes options Product: Ant Version: 1.6.0 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Modern versions of jikes support -extdirs and -bootclasspath, yet ant doesn't pass these options to jikes. (I'm sorry I can't give the jikes version number where this behavior changed; I'm using jikes 1.18) It gets worse: by default, ant puts rt.jar in the -classpath option submitted to jikes after the classpath options specified by <classpath> elements of the <javac> task. This can in certain cases lead to a compile which will fail with build.compiler=jikes but which succeeds with build.compiler=javac1.4, since with javac rt.jar will be implicitly part of the bootclasspath (since ant does not normally pass a -bootclasspath option) and therefore will be read before those jars listed as part of -classpath. Specifically, in one of our projects, one of the (proprietary) jars we were using contained an ancient implementation of javax.xml.parsers.SAXParser. Our code used a feature not present in this old implementation. When we ran ant with the javac1.4 compiler, all was fine, since rt.jar contains a newer implementation of javax.xml.parsers.SAXParser. With jikes, however, the build failed since the proprietary jar was processed before rt.jar. We have kludged this by modifying our <javac> task to say: <javac debug="${build.debug}" srcdir="${java.src}" nowarn="${build.compiler.nowarnings}" destdir="${builddest}"> <selector refid="non_test_java_src" /> <classpath refid="non_test_classpath" /> <compilerarg compiler="jikes" line="-extdirs ${java.ext.dirs} -bootclasspath ${sun.boot.class.path}" /> </javac> Suggestions for fixing this bug: 1. Implicitly, unless overridden by a bootclasspath option given to the <javac> task, jikes compilation should assume a bootclasspath value of ${sun.boot.class.path}. Likewise, extdirs should default to ${java.ext.dirs}. 2. If it is important to support jikes versions that don't support -extdirs or -bootclasspath, then when constructing the classpath line to pass to jikes, bootclasspath should precede classpath in the constructed classpath. If it's not important to support old jikes versions, or if a "jikesmodern" compiler type is introduced, or if the jikes compiler adaptor can determine that it's dealing with a modern jikes version some other way, then -bootclasspath and -extdirs should be passed as you'd expect. Basically, I think that this bug and the other currently open jikes bug (-g:none being necessary to disable debugging information) are a consequence of modern jikes versions behaving like the "modern" javac compiler, whereas old jikes versions behave like the "classic" javac compiler. Either the jikes compiler adaptor should detect the jikes version (this should probably be overrideable with some magic property), or the jikes compiler type should be split in two, or support for older jikes versions should be dropped. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
