You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Steve Loughran <st...@apache.org> on 2005/09/16 12:37:51 UTC
corrupt jar files and javac
I would guess from this trace that there is a bad JAR file somewhere in
my (long, convoluted, m2-tasks created) classpath, something breaking javac.
the problem of course is that javac isnt helpful enough to tell me which
file. I have tried unzipping everything, but of course, ant's <unzip>
task doesnt complain at all, and nor, apparently, does <jar> and <exec
executable="jar" />.
what else do I have to track this down?
compile:
[depend] The class
org.smartfrog.services.deployapi.transport.config.Axis2ServiceImpl_Stub
in file
/home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes/org/smartfrog/services/deployapi/transport/config/Axis2ServiceImpl_Stub.class
is out of date due to
org.smartfrog.services.deployapi.transport.config.Axis2Service but has
not been deleted because its source file could not be determined
[core:javac] Compiling 13 source files to
/home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes
[core:javac] java.lang.IndexOutOfBoundsException
[core:javac] at
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
[core:javac] at
com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1562)
[core:javac] at
com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1518)
[core:javac] at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
[core:javac] at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:614)
[core:javac] at
com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:1612)
[core:javac] at
com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:794)
[core:javac] at
com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:963)
[core:javac] at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:1726)
[core:javac] at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1649)
[core:javac] at com.sun.tools.javac.tree.Tree$Select.accept(Tree.java:993)
[core:javac] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:256)
[core:javac] at com.sun.tools.javac.comp.Attr.attribType(Attr.java:284)
[core:javac] at
com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:655)
[core:javac] at
com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:539)
[core:javac] at com.sun.tools.javac.tree.Tree$Import.accept(Tree.java:401)
[core:javac] at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:383)
[core:javac] at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:395)
[core:javac] at
com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:506)
[core:javac] at
com.sun.tools.javac.tree.Tree$TopLevel.accept(Tree.java:386)
[core:javac] at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:383)
[core:javac] at
com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:777)
[core:javac] at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
[core:javac] at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:614)
[core:javac] at com.sun.tools.javac.comp.Enter.complete(Enter.java:448)
[core:javac] at com.sun.tools.javac.comp.Enter.main(Enter.java:426)
[core:javac] at
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:382)
[core:javac] at com.sun.tools.javac.main.Main.compile(Main.java:592)
[core:javac] at com.sun.tools.javac.main.Main.compile(Main.java:544)
[core:javac] at com.sun.tools.javac.Main.compile(Main.java:58)
[core:javac] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[core:javac] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[core:javac] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[core:javac] at java.lang.reflect.Method.invoke(Method.java:585)
[core:javac] at
org.apache.tools.ant.taskdefs.compilers.Javac13.execute(Javac13.java:55)
[core:javac] at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
[core:javac] at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
[core:javac] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: corrupt jar files and javac
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 16 Sep 2005, Steve Loughran <st...@apache.org> wrote:
> Why dont we set default="preserve" rather than default="add" on the
> zip tasks, on the basis that it may break BC, but it is probably a
> bug to have this problem anyway?
I know I closed a bug report with similar symptoms a while ago. Yes,
BC was the reason.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: corrupt jar files and javac
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Steve,
I am working in an environment where all makes are done with
"duplicates=preserve". Now I think such a change does break BC.
BC is a huge advantage of ant. Where I am working, a lot of makes have
been switched from Ant 1.4 to Ant 1.6 with only 2 tiny problems,
which were a different behavior for "user properties" ( ant
-D"someprop=value") and one protected method of the Zip task which had
changed signature.
Cheers from Frankfurt,
Antoine
Steve Loughran wrote:
> Steve Loughran wrote:
>
>>
>> I would guess from this trace that there is a bad JAR file somewhere
>> in my (long, convoluted, m2-tasks created) classpath, something
>> breaking javac.
>>
>> the problem of course is that javac isnt helpful enough to tell me
>> which file. I have tried unzipping everything, but of course, ant's
>> <unzip> task doesnt complain at all, and nor, apparently, does <jar>
>> and <exec executable="jar" />.
>>
>> what else do I have to track this down?
>>
>> compile:
>> [depend] The class
>> org.smartfrog.services.deployapi.transport.config.Axis2ServiceImpl_Stub
>> in file
>> /home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes/org/smartfrog/services/deployapi/transport/config/Axis2ServiceImpl_Stub.class
>> is out of date due to
>> org.smartfrog.services.deployapi.transport.config.Axis2Service but
>> has not been deleted because its source file could not be determined
>> [core:javac] Compiling 13 source files to
>> /home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes
>>
>> [core:javac] java.lang.IndexOutOfBoundsException
>> [core:javac] at
>> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
>> [core:javac] at
>
>
> The corruption is caused by duplicate .class files in the JAR.
> Fortunately it was one of my projects, and by changing the presetdef
> for jar to default="preserve" and rebulding it went away. If the
> defect was in a JAR file that I was autoloading from the network
> repositories, I would have been stuffed.
>
> Why dont we set default="preserve" rather than default="add" on the
> zip tasks, on the basis that it may break BC, but it is probably a bug
> to have this problem anyway?
>
> -steve
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: corrupt jar files and javac
Posted by Steve Loughran <st...@apache.org>.
Steve Loughran wrote:
>
> I would guess from this trace that there is a bad JAR file somewhere in
> my (long, convoluted, m2-tasks created) classpath, something breaking
> javac.
>
> the problem of course is that javac isnt helpful enough to tell me which
> file. I have tried unzipping everything, but of course, ant's <unzip>
> task doesnt complain at all, and nor, apparently, does <jar> and <exec
> executable="jar" />.
>
> what else do I have to track this down?
>
> compile:
> [depend] The class
> org.smartfrog.services.deployapi.transport.config.Axis2ServiceImpl_Stub
> in file
> /home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes/org/smartfrog/services/deployapi/transport/config/Axis2ServiceImpl_Stub.class
> is out of date due to
> org.smartfrog.services.deployapi.transport.config.Axis2Service but has
> not been deleted because its source file could not be determined
> [core:javac] Compiling 13 source files to
> /home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes
> [core:javac] java.lang.IndexOutOfBoundsException
> [core:javac] at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
> [core:javac] at
The corruption is caused by duplicate .class files in the JAR.
Fortunately it was one of my projects, and by changing the presetdef for
jar to default="preserve" and rebulding it went away. If the defect was
in a JAR file that I was autoloading from the network repositories, I
would have been stuffed.
Why dont we set default="preserve" rather than default="add" on the zip
tasks, on the basis that it may break BC, but it is probably a bug to
have this problem anyway?
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org