Kommentare zu: JAVA-Klassen ohne LANG zu überlegen INSTRUMENTieren

Von: Boris Petrovic

Boris Petrovic — Mon, 27 Apr 2009 13:15:29 +0000

Beitrag zum Thema finde ich sehr interesant. Ich habe auch manche Überlegungen mit java.lang.instrument in diese Richtung gemacht. Mir blieb immer dieser lätzten Schritt modify painlich. Bytecodes auswendig zu lernen finde ich nicht besonders toll. BCEL und änlichen Frameworks scheinen nicht kompatibel mit java.lang.instrument zu sein (oder täusche ich mich).
Wäre sehr insteresant ein konkretes Beispiel mit modify zu sehen.

Gruss
Boris

Von: Metadaten, oder: Warum man Volt und milliVolt nicht einfach addieren kann. | universal.adapter

Tue, 09 Dec 2008 08:49:44 +0000

[...] Mechanismus’ (siehe java.lang.instrument) eingewoben. Eine Einführung in diese Thematik ist hier zu finden. Um nun die Konsistenz zwischen Daten und Metadaten zu wahren muss einfach jeder [...]

Von: Tobias Nebel

Tobias Nebel — Tue, 25 Nov 2008 21:32:30 +0000

@Christoph
Also prinzipiell wollte ich hier nur einen Einstiegspunkt in Bytecode-Engineering aufzeigen. Detailiertere Betrachtungen sind insofern schwierig, da diese in die verschiedensten Richtungen ausschweifen könnten:
eine Instrumentierung könnte ja eine Vielzahl erdenklicher Veränderungen am vorhandenen Bytecode vornehmen…von Analysen, wie sie Profiler durchführen, über ergänzende Funktionalitäten, wie in der Aspekt-orientierten Programmierung, bis hin zur kompletten Neugenerierung von Klassen oder -bestandteilen ist da mehr drin, als man sich auf die Schnelle einfallen lassen kann. Hier sei ‘mal dezent auf meinen nächsten Blog-Artikel verwiesen

Also was den Performanz-Vorteil gegenüber Compilern angeht geb’ ich dir soweit Recht, dass eine umfangreiche Analyse echt Zeit frisst! Wenn allerings überschaubare Sachen insturmentiert werden, dann kommst du sicher ohne Compiler besser. Abseits von der Performanz hast du durch die Bytecode-Analyse natürlich noch die Möglichkeit, Vorgänge auf der Bytecode-Ebene in die Java Sprachebene zu heben (du kannst so beispielsweise das Laden von Werten auf den Stack nachvollziehen).

Was unimplementierte Bytecode-Befehle angeht kann ich dir nicht wirklich viel sagen, da diese selbst für mich Neuland sind. Laut Spec sind diese Befehle einfach nur “reserviert” und “derzeitig unimplementiert”. Meine Vermutung wäre deshalb, dass (zumindest was die “Volks-VM” angeht) hier einfach garnichts passiert.

Viele Grüße!
…und ich hoffe dass wir jetzt ‘ne heiße Diskussion losgerissen haben

Von: Christoph Schmidt

Christoph Schmidt — Tue, 25 Nov 2008 17:18:13 +0000

Interessante Sache, wobei, wenn ich mir das Rudiment so anschaue, ja doch die Frage nach der notwendigen Mächtigkeit der modify()-Methode bleibt.
Um darin sinnvoll instrumentieren zu können, muss man sich entweder auf ‘markante’ ByteCodes verlassen (soweit ich mich erinnere gibt es ein paar reservierte, aber nicht genutzte ByteCodes in der Spec – wäre mal interessant zu wissen, was eine Standard-JRE mit einem solchen ByteCode macht – sofern die JRE da nicht streikt, könnte man für die Instrumentierung eventuell dort ansetzen.) oder den übergebenen Code selbst vollständig analysieren – beliebig mächtige Instrumentierung benötigt am Ende also vielleicht doch die selbe mächtige (aufwendige) Analyse des Codes wie beim Kompilieren. Ich kann mir dementsprechend gut vorstellen, dass beliebig mächtige Instrumentierungen nicht _viel_ schneller sind als die Arbeit mit dem Compiler. Allerdings bleibt natürlich der Dynamik-Aspekt als großer Vorteil..

Viele Grüße