bannkreis.de

import sun.misc.Unsafe

Ich weiss, ihr alten Super-Java-Cracks werdet wahrscheinlich über diese Geschichte milde lächeln...

Seit einiger Zeit verwenden wir XStream von Codehaus als Serialisierungslösung und sind eigentlich recht angetan. Es ist sehr simpel zu verwenden, logisch aufgebaut und bisweilen sehr zuverlässig. Es ist sogar in der Lage Referenzen auf andere im selben Zug serialisierte Objekte mit zu speichern und wiederherzustellen. Alles cool. Wäre da nur nicht dieses latente Misstrauen bezüglich des "magischen Parts" dieser Bibliothek. Sie braucht in der Regel keinerlei public-Konstruktoren oder Property-Setter um Klassen wiederherzustellen. Die sind einfach "wieder da", mit Daten aufgeblasen als wäre nie was gewesen.

Nun sind wir ja natürlich neugierig und bei einer Opensource-Lösung liegt ja nichts näher, als sich den Quellcode (der übrigens auch sehr übersichtlich organisiert ist - eine Seltenheit bei OSS) mal an den kritischen Stellen anzuschauen. Nicht schlecht gestaunt habe ich, als ich anstelle okkulter Voodoo-Beschwörungsformeln jenen Import (den aus dem Titel) in Sun14ReflectionProvider erblickte. Unsafe? Klingt irgendwie....ummm.....unsicher. Eher wie ein Scherz.

Ist es aber wohl nicht. Die Klasse ist vollgestopft mit Methoden a'la setString, getString, setInt, getInt. Alle erhalten als Parameter ein Objekt (dessen Feld gesetzt werden soll, public, private, scheissegal) einen Wert (der im Objekt gesetzt wird) und...

(Trommelwirbel)

...eine Speicheradresse.

(Tusch)

(Betretenes Schweigen)

Speicheradresse? In Java? Das nenne ich mal Unsafe. Gab es nicht neulich jemanden aus der Java-Gemeinde der gegen den gleichnamige Methoden-Modifier aus c# gewettert hat? Und jetzt haben wir seit Jahr und Tag (genauer: Seit Java 1.4) quasi dieselbe Hintertür unbekannterweise eingebaut. Zugegeben, nicht Teil des Standards, aber was heisst das schon. Übrigens, auch die IBM VM verfügt über dieselbe Klasse.

Übrigens, witzig auch was die Reflection-Klassen schon alles bieten, um Kapselung auszuhebeln. Mit folgendem Code macht sich XStream private Konstruktoren gefügig:

if (!Modifier.isPublic(constructors[i].getModifiers())) {
    constructors[i].setAccessible(true);
}

Und danach einfach kackfrech:

return constructors[i].newInstance(new Object[0]);

Ok, bauschen wir die Sache nicht mehr auf als sie wert ist. Die Kapselungsmechanismen von Java sollten Indikator dafür sein, wie APIs und einzelne Klassen zu verwenden SIND. Sollte man dennoch von dieser eingebauten Brechstange Gebrauch machen, so muss man natürlich a) wissen was man tut und b) einen guten Grund dafür haben. Serialisierung ist denke ich ein solcher.

Wer jetzt Bedenken anmelden will, dass dadurch dann die Stabilitäts-Mechanismen der VM ausgehebelt werden, von wegen Abstraktion des Speichermanagements, sollte sich bewusst machen, dass die mit dem Java Native Interface sowieso eine standardisierte Hintertür besitzen. Hier ist also keine zusätzliche Gefahr im Verzug.

Also alles cool.

(Schweigen)

Andererseits, das pure WISSEN über die Existenz dieser Möglichkeiten lässt mich darüber sinnieren, was für schöne Hacks dadurch möglich sind. Das nächste Mal, wenn irgendein Feld irgendeiner API mal nicht über nen public-Setter erreichbar ist schnapp ich mir kurzerhand die Brechstange und....


Bitte geben Sie hier Ihren Kommentar ein:

Verwende Markdown Syntax

Autor

About

Last comments

  • Oliver:
    Als Antwort auf "Anonym" vom 27. Dezember 2015 (..
  • anonym:
    Habbo als abzocke zu deklarieren finde ich schon..
  • anonym:
    Wenn du es dir leisten kannst und es dich glückl..
  • Jebote:
    ja sicher kommen alle auf diesen 5 jahre alten a..
  • Micha:
    @Ingo, na klar. Alles legitim und voll ok ;-) Mu..

Really currently consuming

Links

  • Mehr Whisky
  • Ich@last.fm
  • Ich@Twitter
  • Dina
  • Julia
  • Der Meister (nebst Frau Meister)
  • Rockender Webworker
  • Irgendwas mit Fischen