Wie bereits in einem früheren Artikel ausgeführt wollte ich untersuchen, ob es möglich wäre, BeanInfos per Annotations bereitzustellen, die über eine Fassade direkt zur Laufzeit ermittelt werden könnten, ohne explizite BeanInfo-Klassen zu benötigen

Zuerst die gute Nachricht - mit kleinen Änderungen an den BeanInfo-Annotations, die ich für die Behandlung mittels Annotation-Prozessor geschrieben hatte, ließen sich auch die grundsätzlichen Aspekte von BeanInfo mittels einer Introspector-Fassade realisieren.

Allerdings steckte hier dann der Teufel im Detail: Annotation-Attribute können keine beliebigen Typen aufweisen, Attribute von BeanInfos oder MethodDescriptors, oder, oder, ... verfügen über diese Einschränkungen nicht. Damit sind die zusätzlichen Eigenschaften gemeint, die man mittels getValue() abfragen kann.

Die Lösung mittels AnnotationProcessor war einfach: hier wurden für solche Fälle einfach String-Typen vereinbart - im Template wurden diese eingefügt und sie ergaben dann gültigen Java-Quelltext, der ausgewertet eine Instanz des eigentlich benötigten Typs ergab.

Die erste Hürde dieser Art stellte sich übrigens bereits bei der BeanInfo: Jede bringt die Möglichkeit mit, sich selbst durch ein Icon zu repräsentieren. Man kann das Icon durch einen String repräsentieren und innerhalb der Abfragemethode des Icons dann diesen String als Resource-Identifier interpretieren, über den das eigentliche Bild geladen wird. Die Information über den Typ (String) reicht aber nicht aus - man muss auch die Semantik kennen: Ein Resource Identifier für das Laden aus dem Klassenpfad muss anders aussehen als einer für das Laden aus einer URL. Dieses Problem kann man mit einer abstrakten Introspector-Fassade lösen, die von einer konkreten Implementierung verlangt, eine Methode zum Laden eines Icons über einen gegebenen Resource-Locator zu verlangen.

Leider lässt sich so aber nicht das Problem der anderen Objekte beliebigen Typs lösen... Dafür ist mir bisher nur der Umweg über BeanShell eingefallen. Das würde aber einer meiner Grundsätze beim Programmieren widersprechen: Keine neuen Angriffsflächen, die nur durch Featuritis erklärbar sind: Ein Programm, welches keine Scripting-Enging zur Laufzeit benutzt, müsste nur um BeanInfos nutzen zu können dann eine haben.

BeanInfos würden aber ohne Scripting zur Laufzeit möglich sein, wenn man auf die altbewährte Methode der Generierung über BeanInfo-Annotations und Annotation Processors zurückgreift - dann wird die Entscheidung zumindest für mich leicht...

Ich verfolge daher dieses Projekt nicht mehr weiter - das würde ich erst dann tun, wenn ich eine Alternative zu Beanshell oder generell Scripting finden würde.

Zum Schluss sei noch gesagt, dass in der vorliegenden Implementierung noch keine Lösung für die Anforderung gefunden wurde, die BeanInfo so zu gestalten, dass sie Internationalisierung - zum Beispiel für die ShortDescription - unterstützt. Auch hier müsste man zunächst noch Ideen entwickeln...

Hier noch einige nützliche Links:

Links

Artikel, die hierher verlinken