Benutzeroberflächen im Kontext von Java haben bekanntermaßen eine schwierige Kindheit durchlebt. Die direkten Java-Oberflächentechnologien (AWT, Swing, SWT usw.) sind mittlerweile auf einem robusten Stand, der es ermöglicht, den Einsatz der Technologien in Projekten entsprechend argumentativ zu vertreten. Leider liegt der Fokus bei der Entwicklung von Oberflächen, basierend auf direkten Java-Technologien, jedoch nach wie vor eher auf „rock solid“ und nicht unbedingt auf „smart“. Auch JavaFX konnte nicht dazu beitragen, dass Java-Oberflächen das angestaubte Image der Vergangenheit abstreifen konnten. Gerade im Hinblick auf die heranrollende Welle von Smartphone- und Tablet-Anforderungen wird deutlich, dass man, basierend auf einer Plain Oracle Architecture, den daraus resultierenden Anforderungen nur bedingt gerecht werden kann. Auch der „Zero-Install“-Ansatz ist de facto nicht vorhanden. Für Shopanwendungen z. B., bei denen es wichtig ist, keine Benutzergruppe auszusperren, kommt der Griff zu einer reinen Java-Technologie nach wie vor nicht in Frage. Es sei jedoch auch bemerkt: Für echte Power-GUIs, bzw. Benutzermasken, die mehr können müssen, als nur einen Warenkorb anzuzeigen und grundsätzlich auf einen hohen Produktivitätsgrad ausgelegt sind, ist Java nach wie vor ein Topkandidat. Das beste Beispiel dafür ist die Eclipse IDE, die von Millionen von Entwicklern tagtäglich eingesetzt wird, um professionell Software zu entwickeln.
Für den Business-to-Business- bzw. Business-to-Consumer-Bereich gilt jedoch der Einsatz von Dritt-Frameworks aus den oben genannten Gründen als durchaus legitim, um optimale Resultate bei der Umsetzung der Kundenanforderungen erzielen zu können. Häufig taucht bei der Frameworkauswahl noch die grundsätzliche Frage „Standard oder nicht?“ auf. An dieser Stelle sei erwähnt: Im Bereich von „On top of Java“-Weboberflächen existiert ein solcher Standard (JSF), und die Auswahl eines Frameworks, das den JSF-Standard entsprechend unterstützt, garantiert im Gegenzug einen hohen Grad an Nachhaltigkeit. Leider bieten die meisten der aktuell am Markt verfügbaren JSF-Implementierungen jedoch nur ein relativ geringes Abstraktionslevel, sodass der Einsatz des JSF-Standards unter Umständen eine bremsende Wirkung auf die Entwicklung haben kann – der Entwickler steht also vor der Entscheidung: Entwicklungskomfort versus Standard. Im Rahmen dieses Artikels wurde der Komfort-Weg eingeschlagen. Vaadin unterstützt den JSF-Standard nicht – dafür kann die Anwendung jedoch komplett in Java geschrieben werden, ohne dass der Entwickler in irgendeiner Form mit JSF-Bibliotheken oder sonstigen JSF/JSP/HTML-Tags in Berührung kommen muss.
Das Vaadin-Framework stammt übrigens aus Finnland und weist eine kleine Historie auf. Vielleicht wird sich der eine oder andere Leser noch an das Ajax-Framework „IT Mill Toolkit“ erinnern. Dabei wurde für das clientseitige Komponenten-Rendering eine proprietäre Eigenentwicklung eingesetzt, die im Jahr 2007 aufgegeben und durch das Google Web Toolkit ersetzt wurde. GWT? Richtig. Vaadin verfolgt den Ansatz, dass man die Crux des clientseitigen Renderings mit sämtlichen Höhen und Tiefen an Google abtreten kann. Das passiert nach dem Motto: „Es langt, wenn sich die GWT-Jungs mit Themen wie Browserinkompatibilitäten herumschlagen. Wir konzentrieren uns auf den Server und die Kommunikation zwischen Client und Server.“ Auch das Lizenzmodell wurde im Rahmen des Architekturwechsels in eine Apache-2.0-Lizenz (open, free, do what you want) überführt. Danach wurde im Rahmen eines Rebrandings auch der alte Name „IT Mill Toolkit“ über Bord geworfen und durch „Vaadin“ ersetzt. Dass Vaadin für das Wort Rentier steht, ist dank Wikipedia schnell in Erfahrung zu bringen. Der Bezug zum Framework wird jedoch erst durch eine kleine Buchstabenrotation ersichtlich: Drehen Sie doch einfach mal das Vaadin-Logo um 90 Grad und Sie werden ein gehörntes Rentier erhalten.
Nach den Soft-Facts wird als Nächstes die Architektur des Frameworks beleuchtet, damit Sie anschließend im Rahmen der Demo-Implementierung das Big Picture kennen und wissen, was hinter den Kulissen des Vaadin-Frameworks passiert. Die Frameworkarchitektur ist in Abbildung 1 dargestellt.
