Wie ich bereits in früheren Artikeln dargelegt habe, interessiert mich eine zeitgemäßere Art der BeanInfo-Erstellung ohne IDE-Vendor-Lockin...

Bisher hatte ich damit auch bereits einigen Erfolg - allerdings gab es immer noch eine Anforderung, die die Technik nicht erfüllen konnte: Die Generierung klappte nur mit den Annotations in der verarbeiteten Klasse - definierte eine der Oberklassen Methoden, Properties oder Events, wurden die bei der Generierung ignoriert.

Bisher konnte man sich hier lediglich dadurch behelfen, dass man die gewünschten Features in der abgeleiteten Klasse mit Methoden überschrieb, die die Methoden der Oberklasse aufriefen und diese dann mittels entsprechender Annotations markierte. Das führt natürlich zu Code-Verdopplungen, die unschön sind.

Schwerer wog allerdings der Fall, dass Strings - also zum Beispiel DisplayNames - die aus ResourceBundles geholt wurden zu Konflikten führten, wenn die Oberklasse und die abgeleitete Klasse dazu verschiedene ResourceBundles benutzten - die generierte BeanInfo ließ nur genau ein ResourceBundle zu.

Diese Einschränkungen fallen mit der neuen Version des AnnotationProcessor weg: Jetzt werden die Annotations der Oberklasse ebenfalls zur Generierung der BeanInfo herangezogen und es ist möglich, in jeder der Klassen ein eigenes ResourceBundle zu laden - der Annotation-Processor benutzt fürs Lookup eine spezielle ResourceBundle-Implementierung.

Die entsprechenden Änderungen in der Implementierung sind natürlich auch in das GitHub-Repository gewandert...

Um diese Funktionalität nutzen zu können, muss die Oberklasse allerdings für den Annotation Processor verfügbar sein - das bedeutet, dass die bereits kompilierte Klasse im Klassenpfad verfügbar sein muss oder - falls die Oberklasse noch nicht übersetzt wurde - dass der Quelltext beim Generatorlauf verfügbar sein muss.

Artikel, die hierher verlinken

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

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