Benutzer Diskussion:Frakturfreund/Archiv/2010

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Benutzer Diskussion:Frakturfreund/Archiv/2010#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Benutzer_Diskussion:Frakturfreund/Archiv/2010#Thema_1

ProGuard

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)

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)

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)

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...

So, meine Antwort kommt zwar recht ſpät, aber beſſer ſpät als nie …

In der API-Frage haben wir definitiv einen Konſens gefunden, ProGuard iſt keine Bibliothek.

Was den Vergleich mit kommerziellen Alternativen angeht, kann ich mich dazu nicht wirklich kompetent äußern, da ich mich hier bisher auf die freien Vertreter beſchränkt habe … in dieſer Teilmenge ſcheint es mir aber das Beſte zu ſein, vor allen Dingen da man recht viel konfigurieren kann. Auch was den konkreten Vergleich angeht, kann ich mir kein Urteil anmaßen, obwohl man ſich über die genauen Zahlen ſicherlich ſtreiten könnte … mir ſcheint nur die Grundgeſamtheit von nur drei Klaſſen etwas zu klein zu ſein. Ich teſte da lieber an ›echten‹ Anwendungsfällen mit einer höheren Anzahl von Klaſſen, etwa dem Cortado-Applet zum Abſpielen von Ogg-Theodora-Dateien. Dabei iſt mir bſpw. aufgefallen, daſs die optimierte JAR-Datei 30% ſchneller als das Original iſt – wenn ich die Client-VM benutze. Bei der Server-VM war hingegen kein ſignifikanter Unterſchied zwiſchen den beiden mehr vorhanden. Was die Güte der Obfuscation angeht, ſo läſſt ſich wohl ſo ziemlich jede JAR-Datei knacken, es iſt nur eine Frage des Aufwandes, der aber durch jeden Verſchleierer merklich erhöht wird. Und beim Deployment von freier Software iſt dieſer Schritt naturgemäß ſogar überflüſſig, da hier nur die Verſchnellerung und Verkleinerung des Endproduktes intereſſant iſt.

Kurzum: Den Artikel um eine Liſte von Alternativen zu ergänzen, halte ich für eine gute Idee, ſchon der inhaltlichen Ausgewogenheit halber. Nur zu! Viele Grüße, --Frakturfreund 02:57, 14. Jan. 2010 (CET)

PS: Mit der Neo-Taſtaturlayout kann man auch direkt … statt ... tippen, von den ganzen programmierrelevanten Sonderzeichen ganz zu schweigen … ;-)

Archivierung dieses Abschnittes wurde gewünscht von: Frakturfreund 23:50, 3. Feb. 2010 (CET)

Hallo

he:Toda raba/dt.:danke schön. (Stadtentwicklung und Stadtplanung in Heilbronn) Greetings--Messina 12:15, 19. Mai 2010 (CEST)

Keine Urſache, gern geſchehen! Ich verſuche möglichſt, jeden von mir geleſenen Artikel irgendwie zu verbeſſern, was dann aber meiſtens nur auf irgendwelche typographiſche Kleinigkeiten hinausläuft (einfach da mir das am flüſſigſten von der Hand geht), aber Kleinvieh macht ja auch Miſt ;). Alſo weiterhin frohes Schaffen (apropos: ſchöner Artikel!) wünſcht --Frakturfreund 06:57, 20. Mai 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Frakturfreund 11:27, 11. Mär. 2011 (CET)

Zum Geburtstag

Auspusten

wünsche ich Dir alles Gute, Gesundheit, Glück, Zufriedenheit und weiterhin viel Freude und Erfolg im realen Leben aber auch in Wikipedia. Feier aber nicht zu wild!!! --Pittimann besuch mich 09:09, 23. Jun. 2010 (CEST)

Vielen herzlichen Dank für die Glückwünſche! Und die Feier wird garantiert nicht zu wild werden – eigentlich iſt ſie nur ein Vorwand, um ſich heute Abend den ganzen Fußballfans zu entziehen ;). --Frakturfreund 15:18, 23. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Frakturfreund 11:27, 11. Mär. 2011 (CET)

Wikipedia:Schreibwettbewerb/Publikumspreis

Hi Frakturfreund,

deine Stimme zum Publikumspreis ist eingegangen und verbucht, vielen Dank für deine Teilnahme. Das Ergebnis wird voraussichtlich am 1. November öffentlich gemacht, schau doch dann einfach nochmal vorbei. Grüße, --fl-adler •λ• 00:11, 31. Okt. 2010 (CEST)

Habe ich inzwiſchen getan – es war intereſſant zu ſehen, was den anderen Wikipedianern am Beſten gefallen hat. Und auch wenn meine Favoriten diesmal eher nicht abgeräumt haben, bekommt man durch den Publikumspreis auf jeden Fall viele ſchöne Anregungen, um ſich mal wieder ſo richtig in der Wikipedia feſtzuleſen :). --Frakturfreund 11:27, 11. Mär. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Frakturfreund 11:27, 11. Mär. 2011 (CET)