ProGuard Probleme

[v Ralle v]

Hallo,

ich habe ein ziemlich nerviges Problem mit ProGuard, wenn ich eine .jar shrinken will. Ich fasse meinen Standpunkt kurz zusammen:

Ich habe eine ausführbare Jar, die ist um die 50 KB groß. Nun habe ich noch eine Funktionalität hinzugefügt, mit der man .ppt, .pptx und .odp Files lesen kann. Für diese Funktion brauche ich insgesamt 9 Libraries, wodurch die .jar auf 16MB anwächst.

Das ist natürlich viel zu groß, weil ich wirklich nur ein paar Klassen benutzen, die allerdings Abhängigkeiten zu anderen Libraries haben. Nun habe ich versucht das ganze mit ProGuard zu verkleinern - ohne Erfolg.

Ich benutze Eclipse als IDE und weiß schon nicht richtig, wie ich es am besten exportieren muss. Ich habe die 3 Optionen die Libraries in die .jar zu extrahieren, sie einfach in die .jar zu legen oder in einen Ordner neben die .jar.

Bei der ersten Variante macht Proguard Probleme und das Shrinken klappt einfach nicht. Bei der zweiten lässt der die Libraries in der .jar ohne sie zu shrinken und bei der dritten shrinkt er die .jar, allerdings lässt er auch die Libraries daneben und ich hätte sie allerdings gerne in der .jar geshrinkt.


Wie soll ich am besten vorgehen? Mein Ziel ist es, dass mein Programm so klein wie möglich ist und wirklich nur die Klassen aus den Libraries enthält, die es braucht und der Rest einfach rausfliegt. Wenn es ein anderes kostenloses Programm gibt, dass das kann, wäre ich auch zufrieden 🙂

Ich danke für jeden Tip!!!


Ich hänge auch mal die Fehlermeldungen zur ersten Variante an, vielleicht helfen sie. Ich habe versucht die Libraries auch nochmal extra anzugeben, allerdings hat das auch nicht geholfen.

Warning: there were 10494 unresolved references to classes or interfaces.
         You may need to specify additional library jars (using '-libraryjars').
Warning: there were 416 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.
Warning: there were 7 unresolved references to program class members.
         Your input classes appear to be inconsistent.
         You may need to recompile them and try again.
         Alternatively, you may have to specify the option 
         '-dontskipnonpubliclibraryclassmembers'.
Please correct the above warnings first.

 

[kay73]

Ich habe damals auch mal versucht, mit ProGuard eine Klassenbibliothek zu shrinken und damit mehr Schaden als Nutzen angerichtet. Sobald z. B. Reflection ins Spiel kommt (

Class.forName()

), kann ProGuard die Referenzen nicht mehr auflösen und fängt an zu warnen.

Ich würde folgendes versuchen: Packe alle verwendeten JAR libraries aus, so daß die .class-files irgendwo herumliegen. Dann füge einen Ant-Task hinzu, der Deine Projektklassen in ein JAR-File packt und hinter per JAR update die Libraryklassen dazupackt. Dann lass mal ProGuard rauf los.

 

[v Ralle v]

Danke für die Antwort. Ich habe das jetzt ausprobiert (musste mich erst zu Ant einlesen, hatte ich bisher noch nicht genutzt). Habe mit Ant meine Klassen kompilieren lassen, dann habe ich die extrahierte .class Files aus den Libraries hinzugefügt und mit Ant eine .jar gebaut.

Proguard hatte wieder die gleichen Probleme:

Note: there were 15 unresolved dynamic references to classes or interfaces.
      You should check if you need to specify additional program jars.
Note: there were 5 class casts of dynamically created class instances.
      You might consider explicitly keeping the mentioned classes and/or
      their implementations (using '-keep').
Note: there were 24 accesses to class members by means of introspection.
      You should consider explicitly keeping the mentioned class members
      (using '-keep' or '-keepclassmembers').
Warning: there were 10494 unresolved references to classes or interfaces.
         You may need to specify additional library jars (using '-libraryjars').
Warning: there were 416 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.
Warning: there were 7 unresolved references to program class members.
         Your input classes appear to be inconsistent.
         You may need to recompile them and try again.
         Alternatively, you may have to specify the option 
         '-dontskipnonpubliclibraryclassmembers'.
Please correct the above warnings first.

Ich verstehe das einfach nicht.

Ich habe jetzt auch mal jShrink ausprobiert (die Evaluate Version) und die erfüllt ihren Job problemlos. Allerdings ist es mir zu heikel die erzeugt .jar hochzuladen, weil die Lizens ja nur zum Testen da war.

 

[v Ralle v]

Wirklich keiner mehr eine mögliche Idee?! =/

 

[Wildcard]

Ich habe eine ausführbare Jar, die ist um die 50 KB groß. Nun habe ich noch eine Funktionalität hinzugefügt, mit der man .ppt, .pptx und .odp Files lesen kann. Für diese Funktion brauche ich insgesamt 9 Libraries, wodurch die .jar auf 16MB anwächst.

Ich möchte fast wetten das die Lizenzen dieser 9 Libraries es dir nicht erlauben den Byte Code zu verändern.
Warum packst du nicht einfach per Pack200? Das ist viel einfacher, legal, und bringt wahrscheinlich auch mehr.
Pack200 - Wikipedia, the free encyclopedia

 

[v Ralle v]

Danke für den Tip, davon hatte ich bisher noch nicht gehört. Allerdings war der Erfolg nicht ganz so groß wie erhofft. Bin von 15,6mb auf 13,8mb gekommen. Ich hatte gelesen, dass bis 8mal kleinere Files erzeugt werden können?! Hab ich da was falsch gemacht? Hab das mit einer Testklasse probiert.

public static void main(String[] args) throws IOException {
		JarFile f = new JarFile(args[0]);
		Pack200.Packer packer = Pack200.newPacker();
		OutputStream out = new FileOutputStream(args[0] + ".packed");
		packer.pack(f, out);
		out.close();
	}

 

[Wildcard]

Hier stehen ein paar Tipps wie man aggressiver damit packt:
Pack200 and Compression for Network Deployment
Ausserdem sind deine Library Jars wahrscheinlich schon komprimiert, was AFAIK schlecht für die Kompressionsrate von pack200 ist.

 

[v Ralle v]

Richtig, deshalb denke ich auch, dass sich so viel nicht mehr rausholen lässt =/ Daher hab ich auch nur wirklich über Shrinken nachgedacht.

 

[Wildcard]

Hast du mal versucht der Anleitung zu folgen inklusive dem repack?
Wie gesagt, ich denke du wirst kaum eine Wahl haben, denn die meisten Lizenzen erlauben dir wohl keine Bytecode Manipulation (ausserdem wird die Fehlersuche anhand von Logs nahezu unmöglich).

 

[v Ralle v]

Jep, ich habe die eingerahmte Anleitung genommen. Und du wirst sehr wahrscheinlich recht haben, dass ich den Bytecode nicht manipulieren darf. Bleibt mir also nichts anderes übrig als die große .jar hochzuladen.

 

[Cola_Colin]

Da würde es sich eventuell anbieten, die libs nicht direkt in die jar hineinzupacken, sondern zumindest daneben zu legen, so dass du bei einem update deines eigenen codes nicht die ganzen 16mb wieder hin und her schieben musst.

 

[v Ralle v]

Das stimmt schon. Aber bei dem Programm handelt es sich um ein Gegenstück zu einer Android App. Die meisten Nutzer dieser App wollen alles so einfach wie möglich haben. Die meisten Windwos Nutzer werden sich schon erstmal wundern, dass es keine .exe Datei ist.

Also aus Usability Gründen will ich das nicht machen. Und außerdem kommen gar so viele Updates gar nicht 🙂 Aber guter Einwand, danke.