Benutzer Diskussion:Frakturfreund

Auf dieſer Seite kannſt Du gerne ${\mathfrak {Fraktur}}$ ${\mathfrak {mit}}$ ${\mathfrak {mir}}$ ${\mathfrak {reden!}}$

Dieſe Benutzerdiskuſſionsſeite dient der perſönlichen Kommunikation mit dem Benutzer Frakturfreund. Wenn du mich hier anſprichſt, antworte ich auch auf dieſer Seite. Wenn ich dich auf einer anderen Seite angeſprochen habe, antworte bitte auch dort! Falls du mich vertraulich anſprechen möchteſt, kannſt du mir auch eine E-Mail ſchreiben. Ich werde dir dann via E-Mail antworten.

Bitte klicke hier, um ein neues Diskuſſionsthema zu beginnen
und unterſchreibe deinen Beitrag mit --~~~~

Hinweiſe

Diskutiere bitte ſachlich und freundlich!
Greife niemanden perſönlich an.
Gehe von guten Abſichten aus.
Bitte beachte die Richtlinien und Konventionen ſowie die
Hilfe zu Diskuſſionsſeiten!

Archiv

2009 2010
Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

ProGuard

Letzter Kommentar: vor 15 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

Hi! Ich hab Deine Änderung in ProGuard zurückgesetzt. Meines Wissens nach ist ProGuard vor allem ein Tool für Obfuscation und nicht eine API, die von einem Java Programm heraus aufgerufen wird. Auch die Homepage spricht von "ProGuard is a command-line tool with an optional graphical user interface" Wennst andere Infos hast bitte um Diskussion (würde mich interessieren). --Sebastian.Dietrich 10:09, 9. Jan. 2010 (CET)Beantworten

Hallo Sebaſtian, erſt einmal herzlichen Dank für Deine ausführliche Begründung Deines Reverts auf meiner Diskuſſionsſeite! Und ich muſs Dir Recht geben, da habe ich im Eifer des Gefechtes mal wieder etwas übertrieben … wie Du ſelbſt geſchrieben haſt, iſt ProGuard vor allen Dingen dafür gedacht, um in den Deployment-Prozeſs einer Java-Anwendung eingebunden zu werden (je nach perſönlicher Vorliebe über die GUI/Kommandozeile/Ant-Schnittſtelle) und nicht als Bibliothek zur Laufzeit. Nur dieſe Wege ſtehen auch in der offiziellen (und leſenswerten!) Dokumentation, alſo ſollte die WP hier keine Theoriefindung praktizieren, weshalb Proguard definitiv nicht in die Kategorie:Java-Bibliothek gehört. Nochmals Danke für die Korrektur!

Aber um doch noch etwas fachzuſimpeln: Nur, weil die Nutzung von ProGuard als API offiziell nicht vorgeſehen iſt, heißt das noch lange nicht, daſs man es nicht doch ſo benutzen könnte ;) … ſchließlich ſteht das Programm unter der GPL, ſo daſs der Quelltext gleich mitgeliefert wird (auch wenn man ſelbſt noch javadoc ausführen muſs/ſollte, es iſt alſo wirklich nicht als API gedacht). Der Quelltext iſt zwar ſehr umfangreich, aber durchaus gut ſtrukturiert und verſtändlich, ſo daſs es eigentlich nicht weiter ſchwer bzw. aufwendig iſt, die entſprechenden Klaſſen (proguard.classfile.ClassPool, proguard.optimize.Optimizer, …) direkt zur Laufzeit aus einem normalen Java-Programm heraus aufzurufen.

Ich ſelbſt habe mal einen Java-Spieleſchiedsrichter für ein Programmierturnier geſchrieben, der die Spieleprogramme (alſo die Abgaben der Teilnehmer) dynamiſch über Refection ermittelt und dann über einen URLClaſsloader inſtanziiert hat; da ich alſo eh’ ſchon die Claſs-Objekte vorliegen hatte, habe ich dann aus reinem Intereſſe auch mal Proguard »dazwiſchengeſchaltet« um zu ſehen, ob es ſich auf die Spielſtärken auswirkte (bei einigen tat’s das tatſächlich!).

Ich könnte mir aber durchaus auch andere ſinnvolle Real-World Anwendungsbeiſpiele vorſtellen; etwa einen Slim-Client, der ſich bei jedem Programmſtart erſtmal die aktuelle (Client-)Programmverſion in Form von ſerialiſierten Claſs-Dateien übers Netz herunterlädt … es wäre doch nett, wenn der Client (oder noch beſſer: gleich der Server) die vollautomatiſch ſelbſt mit Proguard optimieren würde … oder in Verbindung mit der Java Compiler API.

Aber wie geſagt, jetzt ſpreche ich doch ins Blaue und gerate ins Schwärmen … aber ProGuard iſt ein wirklich tolles – und nützliches – Programm :). Java-laſtige Grüße, --Frakturfreund 18:57, 9. Jan. 2010 (CET)Beantworten

Danke für die ausführliche Info. Habe selbst mit ProGuard keine Erfahrung - ein Diplomand von mir hat mal 16 verschiedene Obfuscators miteinander verglichen. ProGuard 4.3 hat damals (gegenüber den kommerziellen Tools) aber nicht so toll abgeschnitten: "Die Obfuscation verlief reibungslos, das transformierte Beispielprogramm funktionierte ohne Fehler, jedoch ein wenig langsamer (etwa 15%). Durch das Verschieben von Methoden konnte die Klassenzahl von 3 auf 2, die Packagezahl von 2 auf 1 verringert werden. Die Transformation bewirkte außerdem eine Veränderung aller Namen von Methoden, Klassen (mit Ausnahme der Main Klasse) und Variablen. Die Klassendateien konnten mit beiden Decompilern geöffnet werden. Dadurch, dass keine Kontrollfluss-Obfuscation durchgeführt wurde, war es einfach die Funktion des Programms zu verstehen. Auch eine String-Encryption hat gefehlt, was weitere Informationen über die Funktionsweise preisgab."

Aber darum gehts ja hier nicht - wichtig war mir mal nur, dass es nicht als API gekennzeichnet wird, denn zu einer API gehört ja mehr als dass das Ding prinzipiell aus einem Programm heraus aufrufbar ist (sonst wäre ja jedes OpenSource Programm eine API).

--Sebastian.Dietrich 09:13, 10. Jan. 2010 (CET)Beantworten

P.S. Ich werde mal die Alternativen auch in den Artikel schreiben - nicht dass ich Werbung dafür machen möchte (für die Alternativen gibts ja gar keine Artikel) - aber damit wäre das Theme "CodeObfuscators in Java" vollständiger. Spätermal kann man die ja in "Liste der CodeObfuscators für Java" rausziehen...