CDI Expert Group veröffentlicht 2. Early Draft Release
Es wurde viel über die mangelnden Fortschritte in den verschiedenen Java EE 8 Expert Groups diskutiert. Einige der wenigen Gruppen, auf die das nie zutraf, ist die CDI Expert Group. Diese hat nun das 2. Early Draft Release (EDR) veröffentlicht, und alle Entwickler sind aufgerufen, ihr Feedback zu geben.
- Thorben Janssen
Es wurde viel über die mangelnden Fortschritte in den verschiedenen Java EE 8 Expert Groups diskutiert. Einige der wenigen Gruppen, auf die das nie zutraf, ist die CDI Expert Group. Diese hat nun das 2. Early Draft Release (EDR) veröffentlicht, und alle Entwickler sind aufgerufen, ihr Feedback zu geben.
Die von Antoine Sabot-Durand (Red Hat) geführte Expert Group hat sich von Anfang an durch ihre kontinuierliche Arbeit und Offenheit gegenüber der Community ausgezeichnet. Das setzt sich auch mit der Veröffentlichung des zweiten Early Draft Release fort. Bis zum 14. Oktober haben alle Entwickler noch die Möglichkeit, das neue Release auszuprobieren und mit ihrem Feedback die CDI-2.0-Spezifikation mitzugestalten.
Bugfixes, Verbesserungen und neue Features
Das EDR2 Release bringt neben verschiedenen Bugfixes und Verdeutlichungen bestehender Formulierungen auch einige neue Features. Die für CDI-Anwender interessantesten drei Neuerungen möchte ich hier kurz vorstellen.
Annotationen einfacher instanziieren
Annotationen können in Java nicht direkt instanziiert werden. CDI bietet jedoch die Möglichkeit, Beans dynamisch zu finden, und Entwickler müssen dabei häufig Qualifier-Annotationen instanziieren, um die Auswahl der zur Verfügung stehenden Beans einzuschränken. Dies wird durch einen kleinen Trick ermöglicht, bei dem eine Ableitung der AnnotationLiteral-Klasse für die spezifische Annotation erzeugt wird. Der folgende Codeschnipsel zeigt ein Beispiel für ein AnnotationLiteral der Default-Annotation.
final class DefaultLiteral extends AnnotationLiteral<Default> implements Default { }Mit dem EDR2 liefert die CDI-Spezifikation nun AnnotationLiterals für häufig verwendete Annotationen. Diese müssen somit nicht mehr von vielen Projekten implementiert werden, was das dynamische Finden von Beans vereinfacht.
Vereinfachte asynchrone Events
Die bereits mit dem EDR1 eingefĂĽhrten asynchronen Events wurden im Rahmen des EDR2 vereinfacht. Nun werden asynchrone Events nur noch von asynchronen Observern verarbeitet und nicht wie bisher auch von den synchronen. Die folgende Tabelle zeigt einen Ăśberblick ĂĽber die neue Verarbeitung der Events.
|
@Observers |
@ObservesAsync |
|
| fire() | Ja | Nein |
| fireAsync() | Nein | Ja |
Damit werden synchrone und asynchrone Events vollständig voneinander getrenntm und deren Verarbeitung wird somit für Entwickler einfacher verständlich. Dies bedeutet allerdings auch, dass zwei unterschiedliche Events ausgelöst werden müssen, wenn eine synchrone und asynchrone Verarbeitung der Events ermöglicht werden soll. Wie so oft in der der Softwareentwicklung muss man sich hier für das kleinere der beiden Übel entscheiden, und dies ist nach meiner Meinung gut gelungen.
Observer programmatisch deaktivieren
Das programmatische Deaktivieren von Observern wurde durch das HinzufĂĽgen einer veto()-Methode zum ProcessObserverMethod-Interface stark vereinfacht. Beim Deployment einer Anwendung feuert der CDI-Container fĂĽr jeden registrierten Observer ein Event mit diesem Interface. Um einen Observer zu deaktivieren, muss nun nur noch auf das entsprechende Event gelauscht und die veto()-Methode aufgerufen werden. ()
