developerblog

In so gut wie jeder Einsteigerlektüre für die Sprache Java wird gelehrt, dass Datenkapselung mit eine der wichtigsten Voraussetzungen für eine saubere, objetorientierte Programmierung ist. In der Regel genügt es den Autoren darauf hinzuweisen, dass Attribute als private oder protected deklariert und nur über entsprechende Zugriffsmethoden nach außen zum Lesen oder ggf. auch Schreiben erreichbar gemacht werden sollen. - Wenn man sich die Sprache Java etwas genauer ansieht, reicht dies allerdings leider nicht immer aus...

Da Java über das Feature der Reflection vefügt, ist es möglich, sich hierüber Informationen über die Methoden und eben auch Attribute einzelner Klassen zu informieren. - Dazu gehören natürlich auch diejenigen, die als private oder protected deklariert sind.

Angenommen, wir interessieren uns für den Inhalt des als private deklarierten Attributs value der Klasse String (auch wenn man da zugegebenermaßen auch einfacher dran kommen kann). Dann ist es möglich, eine Referenz auf dieses Attribut mit Hilfe der Methoden der Reflection-API zu erlangen:


Auf obige Weise erlang man natürlich erst generelle Informationen über das Attribut value, nicht allerdings den Inhalt des Attributs einer konkreten String-Instanz. Doch auch hier ist die Reflection-API hilfreich:


In der Standardkonfiguration wird ein solcher Zugriff allerdings mit dem Auftreten einer IllegalAccessException quittiert, was uns also noch nicht wirklich zu dem gewünschten Inhalt führt. - Hierzu ist noch eine kleine Veränderung notwendig. Über die Methode setAccessible des Field-Objetks ist es nämlich möglich, genau dieses prüfende Verhalten der Methode Field.get(Object) auszuschalten:


So ist es nun nicht nur möglich, den Inhalt des eigentlich versteckten Arrays auszulesen, sondern, da die Inhalte eines Arrays anders als ein Array selbst nicht als final deklariert werden können, denInhalt des Arrays auch zu verändern:


Die Ausgabe ist nun, nicht wie erwartet "Hans" sondern hat sich zu "Haus" verändern. Das Objekt vom Typ String, welches theoretisch zwar unveränderbar sein sollte, ist über einen kleinen Umweg auf einmal doch veränderbar geworden...

Eine totale Katastrophe ist dies für das Sichheitskonzept der Sprache Java natürlich nicht, denn durch setzen der "suppressAccessChecks"-Permission innerhalb des zuständigen SecurityManagers kann genau die für den Zugriff notwendige Field.setAccessible-Methode verboten werden. - Klar ist allerdings auch, dass die meisten (auch serverseitig eingestzten) Java-Umgebungen mit den Standardeinstellungen laufen, in denen gerade genau diese Änderung am SecurityManager nicht vorgenommen wurde...

Nachdem ich mich nun seit weit über zwei Jahrzehnten mit der Programmierung von Computern und seit ca. 1996 vor allem intensiv mit der Sprache Java beschäftigt habe, dachte ich, es wäre an der Zeit die eine oder andere Erfahrung, die ich in dieser Zeit selber machen durfte oder in fremden Code gefunden habe, in Form eines Blogs zu veröffentlichen.

Spannend finde ich dabei natürlich vor allem die kleinen Fallen und Details, über die man bei der Entwicklung kleinerer Systeme gar nicht (mehr) nachdenkt, da man sich vielleicht noch nie damit beschäftig hat, oder vielleicht schon wieder vergessen hat, dass es sie gibt, die bei genauerem Hinsehen aber doch zu größeren Problemen führen können, als man am Anfang vielleicht denken mag.

Über eine oder andere wird der eine oder andere vielleicht selbst schon gestolpert sein, das eine oder andere wird aber vielleicht auch neu sein. Wenn euch also was interessiert lest es einfach durch, oder lasst es sein.

Feedback über Dinge, die toll oder vielleicht nicht so toll sind, ist natürlich immer erwünscht. - Natürlich auch Anregungen zu Themen, die hier noch nicht zu finden sind, von denen ihr aber meint, dass sie schon immer einmal veröffentlich werden sollten...

Viel Spaß

euer developerblog (OK, das Name ist noch nicht optimal, aber es ist auch gar nicht so leicht, einen passenden Namen zu finden...)