Updates

• 5. Januar 2018

Nachdem ich mich von Netbeans als IDE losgesagt und Idea in der Community Edition zugewandt habe, vermisste ich eigentlich nur eins: den schönen clicky-bunty-Editor für BeanInfo-Klassen. Daher die Idee, so etwas über Annotations zu realisieren...

Die bisherige Lösung dafür war eher eine Krücke - sie erzeugte zwar eine BeanInfo-Klasse, allerdings war diese nur wenig mehr als ein Skelett. Danach war noch einige Handarbeit angesagt, damit eine sinnvolle BeanInfo daraus wurde. Aber noch erschwerender war sicher die Tatsache, dass man eine einmal generierte und angepasste BeanInfo davor schützen musste, dass noch einmal "drüber generiert" wird - dadurch wären nämlich alle Anpassungen verlorengegangen.

Das ist besonders in Fällen hinderlich, in denen einer Bean neue Properties hinzugefügt werden: Dann muss man entweder die bestehende BeanInfo doch von Hand weiterpflegen oder nochmals generieren und darauf hoffen, dass man die händisch vorgenommenen Anpassungen durch ein kompetentes Merge-Werkzeug in die neue BeanInfo übernehmen kann.

Das Ziel musste also sein, die BeanInfo-Annotations so zu erweitern, dass alle Aspekte in einer BeanInfo-Klasse über Annotations abbildbar waren. Diese Aspekte mussten dann in einem weitaus umfassenderen Velocity-Template berücksichtigt und umgesetzt werden. Damit erübrigt sich jegliche Anpassung der generierten BeanInfo.

Damit dies wirklich so bleibt, wurde ein wenig weiter gedacht: Die BeanInfos sind inhärent multilingual: Es ist möglich, ein ResourceBundle anzugeben, das in der generierten BeanInfo benutzt wird. An allen Stellen, an denen ein String erwartet wird, kann per Annotation-Attribut auch ein String genutzt werden, der ein gültiges Java-Quelltextfragment darstellt und nach Auswertung einen String ergibt. Bestes Beispiel dafür ist die Internationalisierung: statt "huhu" kann man einfach schreiben:

i18n.getString("huhu");

Dieser Code wird an der entsprechenden Stelle in die BeanInfo generiert und erzeugt dann einen String, statt das vorgegebene StringLiteral nutzen zu müssen.

Eine weitere Facette dient der Abrundung: In einigen Positionen der BeanInfo-Klasse ist ein Exception-Handling nötig: dafür existiert ein weiteres Annotation-Attribut, das ebenfalls wieder ein gültiges Java-Quelltextfragment enthalten muss - in diesem Fall wird es statt des Standard-Exception-Handling eingesetzt.

Alle benötigten Klassen und Ressourcen werden in einem Github-Repository veröffentlicht werden.

Ein Ausblick sei an dieser Stelle noch gestattet: Es wäre schön, wenn man aus den Annotations Runtime-Annotations machen könnte: dann wäre es möglich, ohne BeanInfo generieren zu müssen die BeanInfo über eine Introspector-Fassade direkt zur Laufzeit zu erzeugen.

Aktualisierung vom 5. Januar 2018

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )