I'm getting the error below during the Shrinking phase. The input jar is the output of the maven-assembly-plugin, a big jar that I would like to shrink in size.
Note: there were 62 unresolved dynamic references to classes or interfaces.
You should check if you need to specify additional program jars.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Note: there were 25 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclasscast)
Note: there were 412 accesses to class members by means of introspection.
You should consider explicitly keeping the mentioned class members
(using '-keep' or '-keepclassmembers').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclassmember)
Warning: there were 26072 unresolved references to classes or interfaces.
You may need to add missing library jars or update their versions.
If your code works fine without the missing classes, you can suppress
the warnings with '-dontwarn' options.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
Warning: there were 529 instances of library classes depending on program classes.
You must avoid such dependencies, since the program classes will
be processed, while the library classes will remain unchanged.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dependency)
Warning: there were 8453 unresolved references to program class members.
Your input classes appear to be inconsistent.
You may need to recompile the code.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedprogramclassmember)
Warning: there were 2 unresolved references to library class members.
You probably need to update the library versions.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedlibraryclassmember)
Note: you're ignoring all warnings!
Ignoring unused library classes...
Original number of library classes: 19467
Final number of library classes: 1656
Shrinking...
Shrinking...
java.lang.ArrayIndexOutOfBoundsException: 4
at proguard.classfile.editor.InterfaceDeleter.visitSignatureAttribute(InterfaceDeleter.java:162)
at proguard.classfile.attribute.SignatureAttribute.accept(SignatureAttribute.java:97)
at proguard.classfile.ProgramClass.attributesAccept(ProgramClass.java:547)
at proguard.classfile.editor.InterfaceDeleter.visitProgramClass(InterfaceDeleter.java:92)
at proguard.shrink.ClassShrinker.visitProgramClass(ClassShrinker.java:78)
at proguard.classfile.visitor.MultiClassVisitor.visitProgramClass(MultiClassVisitor.java:85)
at proguard.shrink.UsedClassFilter.visitProgramClass(UsedClassFilter.java:62)
at proguard.classfile.ProgramClass.accept(ProgramClass.java:358)
at proguard.classfile.ClassPool.classesAccept(ClassPool.java:124)
at proguard.shrink.Shrinker.execute(Shrinker.java:153)
at proguard.ProGuard.shrink(ProGuard.java:286)
at proguard.ProGuard.execute(ProGuard.java:112)
at proguard.ProGuard.main(ProGuard.java:507)
%java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
%uname -a
Darwin irmbp 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
I get the same exact problem on 5.1. I see it as a repeat of this supposedly fixed issue https://sourceforge.net/p/proguard/bugs/549/ But it does not seem to be fixed.
Last edit: Dave Brosius 2014-12-10
Valerio, do you have scala-library.jar in your product?
After enabling debug, and adding some sysouts of my own, i can give you some info on where it failed.
[proguard] InterfaceDeleter.visitSignatureAttribute with cls: ProgramClass(scala/collection/TraversableLike) and attr: SignatureAttribute[index=3 referenceClasses=[LibraryClass(java/lang/Object), LibraryClass(java/lang/Object), LibraryClass(java/lang/Object), ProgramClass(scala/collection/generic/HasNewBuilder), ProgramClass(scala/collection/generic/FilterMonadic), ProgramClass(scala/collection/TraversableOnce), ProgramClass(scala/collection/GenTraversableLike), ProgramClass(scala/collection/Parallelizable), ProgramClass(scala/collection/parallel/ParIterable)]] and delete: [true, true, false, false]
[proguard] InterfaceDeleter: type = <a:ljava lang="" object;repr:ljava="" object;=""> (2 referenced classes)
[proguard] InterfaceDeleter: type = Ljava/lang/Object; (1 referenced classes)
[proguard] InterfaceDeleter: type - Lscala/collection/generic/HasNewBuilder<ta;trepr;>; (1 referenced classes)
[proguard] InterfaceDeleter: type - Lscala/collection/generic/FilterMonadic<ta;trepr;>; (1 referenced classes)
[proguard] InterfaceDeleter: type + Lscala/collection/TraversableOnce<ta;>; (1 referenced classes)
[proguard] InterfaceDeleter: type + Lscala/collection/GenTraversableLike<ta;trepr;>; (1 referenced classes)
BUILD FAILED
/home/dave/dev/pgbu_platform-2.0/projects/ear/build.xml:97: java.lang.ArrayIndexOutOfBoundsException: 4
at proguard.classfile.editor.InterfaceDeleter.visitSignatureAttribute(InterfaceDeleter.java:160)
at proguard.classfile.attribute.SignatureAttribute.accept(SignatureAttribute.java:103)
at proguard.classfile.ProgramClass.attributesAccept(ProgramClass.java:547)
at proguard.classfile.editor.InterfaceDeleter.visitProgramClass(InterfaceDeleter.java:92)
My application is using scala-library.jar version 2.11.4
I have this line in my .pro file
-keep class scala.*</ta;trepr;></ta;></ta;trepr;></ta;trepr;></a:ljava>
This is the same problem as reported in bug #549:
https://sourceforge.net/p/proguard/bugs/549/
It is caused by a bug in the Scala runtime classes:
https://issues.scala-lang.org/browse/SI-8931
Some classes declare that they implement a number of interfaces, with the generic class signature inconsistently declaring that it implements those interfaces plus a few more.
I've marked the ProGuard bug as open-fixed because the Scala team has fixed the bug for an upcoming release. I don't have a work-around right now. You could try catching the exception and leaving the signature untouched -- the Scala runtime doesn't seem to be sensitive to it being inconsistent anyway.