ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Lévy-Lambert <>
Subject AW: Suggestion for behavior change of <jar> (duplicate attribute ) WAS: Very odd issue with jar task
Date Sat, 06 Dec 2003 12:01:47 GMT
Hi Daniel,

thanks for reporting this problem. I agree with you that the default should
to be changed to "preserve", so that only users who know what they are doing
would be using the "add" option.

Let's see what other users and committers think about this issue.


-----Urspr√ľngliche Nachricht-----
Von: Armbrust, Daniel C. []
Gesendet: Freitag, 5. Dezember 2003 23:51
An: 'Ant Users List'
Betreff: Suggestion for behavior change of <jar> WAS: Very odd issue
with jar task

I finally figured this out...  The problem was happening because I had a jar
file with duplicate class files in it.

It turns out that javac will puke when it tries to load a class from a jar
file that exists in the jar file twice.

I filed a bug report with sun... They definitely shouldn't throw an
indexOutOfBounds exception when this occurs.

I also think there is something that should be changed in ant - this is what
caused me to get two class files in the jar file anyway.

The <jar> task has an optional argument of duplicate that takes the values
"add", "preserve" or "fail".
It defaults to "add".

Since the default can result in jar files that no java compiler can read, I
think that the default should be changed to "preserve".

Should I open a bug report, or should we just discuss this minor change



-----Original Message-----
From: Armbrust, Daniel C. []
Sent: Friday, December 05, 2003 1:51 PM
To: ''
Subject: Very odd issue with jar task

I have a very frustrating problem that I hope someone may be able to shed a
bit of light on....  Sorry for the lengthy post, but I wanted to get all the
details out here.

I am building a jar file which contains my compiled source files, and the
contents of several other jar files, with a task like this:

	<jar jarfile="${implAndDepend.jar}" basedir="${}"
      		<zipgroupfileset refid="packageJars"/>
      		<zipgroupfileset refid="axisJars"/>
      		<zipgroupfileset dir="">
 				<include name="${wsdlJava.jar}"/>

Those refid's are defined like this:

		<path id="allJars">
			<fileset dir="${externalLib.dir}" id="packageJars">
				<include name="log4j-1.2.6.jar"/>
				<include name="gnu-regexp-1.1.4.jar"/>
				<include name="castor-0.9.4.jar"/>
				<include name="castor-0.9.4-xml.jar"/>
				<include name="jdbc-se2.0.jar"/>
				<include name="jta1.0.1.jar"/>
				<include name="allToolsModified.jar"/>
				<include name="pgjdbc2.jar"/>

			<fileset dir="${externalLib.dir}/axis/" id="axisJars">
				<include name="**/*.jar"/>

This works fine, I end up with one big jar file.  I have done this for
several months without an issue.  The resulting jar file works fine when
used as a runtime library.

Now, I have another project that depends on this library.

My compile task in that project looks like this:

    <javac srcdir="${src}" destdir="${classes}">
    	<classpath path="${extLib}/implAndDepend.jar"/>

This has worked fine up until yesterday.  Now, when I run compile, I get
this exception:
Buildfile: D:\Eclipse Projects\general-workspace\ctsbackend\build.xml
    [mkdir] Created dir: D:\Eclipse
    [mkdir] Created dir: D:\Eclipse
    [javac] Compiling 8 source files to D:\Eclipse
    [javac] An exception has occurred in the compiler (1.4.2_02). Please
file a bug at the Java Developer Connection
(  after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in your
report.  Thank you.
    [javac] java.lang.IndexOutOfBoundsException
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at$ClassSymbol.complete(
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at$Select.accept(
    [javac] at
    [javac] at
    [javac] at$MemberEnter.visitImport(
    [javac] at$Import.accept(
    [javac] at$MemberEnter.memberEnter(
    [javac] at$MemberEnter.memberEnter(
    [javac] at$MemberEnter.visitTopLevel(
    [javac] at$TopLevel.accept(
    [javac] at$MemberEnter.memberEnter(
    [javac] at$CompleteEnter.complete(
    [javac] at
    [javac] at$ClassSymbol.complete(
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [javac] at
    [javac] at
    [javac] at java.lang.reflect.Method.invoke(
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at
    [javac] at
BUILD FAILED: file:D:/Eclipse
Projects/general-workspace/ctsbackend/build.xml:38: Compile failed; see the
compiler error output for details.
Total time: 891 milliseconds

I can't figure out what I changed between yesterday and today to make this
occur.  Here are some additional oddities:

If I use the <unjar> task to unjar implAndDepend.jar into a temp folder, and
then point the <javac> task to that folder for the classpath, everything
works fine.
If I manually (using winzip) unzip the file implAndDepend.jar, and then
rezip it with winzip, everything works fine.
If I execute jar -tf implAndDepend.jar it lists all the classes in the jar
file without any issues.

What could possibly be wrong with this jar file that is causing this


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message