ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 26404] New: - jikes compiler adaptor doesn't support modern jikes options
Date Sat, 24 Jan 2004 22:33:21 GMT
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: dev@ant.apache.org
        ReportedBy: dmartin@fame.com


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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message