Cross-Platform-Development mit RapidClipse 4

#JAVAPRO #RapidClipse #Eclipse #Vaadin #Java11

Knapp zwei Jahre sind seit dem letzten Major Release RapidClipse 3.0 vergangen. Jetzt ist die neue Version 4.0 verfügbar. Hauptgrund für die lange Wartezeit waren gravierende Änderungen bei den Release-Zyklen von Java und Eclipse sowie der Wechsel auf eine neue UI-Basistechnologie bei Vaadin, was zu erheblichen Unklarheiten geführt hat. Mittlerweile weiß man wo es hin geht, es gibt eine klare
Roadmap und die Weiterentwicklung von RapidClipse hat wieder rasant Fahrt aufgenommen. Sogar die erste Alpha-Version der nächsten Version steht schon in den Startlöchern.

RapidClipse ist eine völlig lizenzkostenfreie Eclipse-Distribution, die Eclipse zur visuellen Java IDE für Cross-Platform-Development machen soll. Ziel ist kein geringeres als die Entwicklung von Unternehmensanwendungen mit Java und Eclipse stark zu vereinfachen, zu beschleunigen und letztendlich auch deutlich günstiger zu machen.

Voll integrierte Eclipse Java IDE

Einer der größten Kritikpunkte an Eclipse ist, dass man enorm viel Zeit braucht, bis man die IDE für seine Zwecke eingerichtet hat. Man muss spezielle Eclipse-Plugins downloaden und so konfigurieren, dass diese miteinander reibungslos funktionieren. Viele Entwickler haben damit schon Stunden und zum Teil Tage verbracht. Das könnte in Zukunft sogar noch schlimmer werden. Denn nach der Änderung des Java-Release-Zyklus erscheint nun alle 6 Monate eine neue Java-Version und sogar alle 3 Monate eine neue Eclipse-Version. Mit diesem Tempo können viele Eclipse-Plugin- und Tool-Hersteller jedoch nicht schritthalten. Es besteht die Gefahr, dass nach Eclipse-Updates das
eine oder andere Plugin einfach nicht mehr funktioniert, weil es die neueste Java- oder Eclipse-Version noch nicht unterstützt. In solchen Fällen muss man entweder auf das entsprechende Plugin verzichten oder auf die neueste Java- oder Eclipse-Version. Welcher Entwickler hat schon Lust, alle paar Monate seine IDE neu einzurichten und zu evaluieren, warum welche Plugins mal wieder nicht wie gewohnt zusammen funktionieren?
Genau das ist bei RapidClipse nicht mehr nötig. Denn Rapid-Clipse ist eine vollständig integrierte Distribution, so wie sich das viele Eclipse-Nutzer schon immer gewünscht haben. Alle benötigten Plugins sind nach dem Motto Plug-and-Play bereits vorinstalliert und perfekt aufeinander abgestimmt, sodass man nach der Installation ohne Konfigurationsaufwand sofort starten kann. Beim Anlegen eines neuen RapidClipse-Projekts werden zudem alle benötigten Dependencies automatisch aus dem Maven-Central heruntergeladen, u.a. JPA und Vaadin, sodass man sich auch darum nicht kümmern muss. Nach dem Download kann man auch offline entwickeln.

GUI-Builder für HTML5 Oberflächen

Mit RapidClipse entwickelte grafische Oberflächen basieren auf HTML-5. Um den Java-Entwickler nicht mit der Programmierung von HTML, JavaScript und JavaScript-Frameworks wie React oder Angular zusätzlich zu belasten, kommt in RapidClipse das UI-Framework Vaadin 7 zum Einsatz. Vaadin ist ein reines Java-Framework, mit dem man die gesamte HTML-Oberfläche in Java schreiben kann. Der Code und der Komponenten-Ansatz erinnern stark an good-old Swing . Erst zur Laufzeit wird die gesamte UI dynamisch auf dem Server erzeugt und an den Browser ausgeliefert. Darüber hinaus kümmert sich Vaadin um die gesamte Client-Server-Kommunikation, sodass man sich auch damit
überhaupt nicht befassen muss. Die von Vaadin zur Verfügung gestellte UI-Widgets basieren auf GWT-UI-Widget (GWT ehemals Google-Web-Toolkit), das für alle wichtigen Browser entsprechende Anpassungen out-of-the-Box mitbringt, sodass man sich auch mit diesem Thema nicht auseinandersetzen muss.

Damit man seine Oberflächen nicht per Hand codieren muss, bietet RapidClipse einen professionellen GUI-Builder (Abb. 1), der keine Wünsche offenlässt. Auch anspruchsvollste UIs lassen sich auf einfache Weise umsetzen. Für die Konstruktion von Formularen, Menüs, Table-Views, Suchmasken und häufig benötigter Master-Detail-Views gibt es intuitive Wizards. Besonders hilfreich ist der Assistent für die Konfiguration und Formatierung von Tabellen und Generated-Columns. Auch Autorisierung- und Authentifizierung, Internationalisierung und UI-Persistierung werden unterstützt. Bei jeder Aktion im GUI-Builder wird sofort Code generiert. RapidClipse erzeugt gut strukturierten Java-
Code, ermöglicht aber auch die deklartive UI-Entwicklung mit XML (Listing 1) – letzteres funktioniert auch bidirektional, d.h. Änderungen im XML-Code werden automatisch im GUI-Builder umgesetzt. Die ebenfalls generierten Button-Events bilden den Übergang zwischen generiertem und eigenem Code – der individuellen Businesslogik.

Der Vorteil des GUI-Builders macht sich vor allem in agilen Projekten stark bemerkbar, bei denen man am Anfang prototypisch vorgeht und auch später noch viele Anpassungen und immer wieder Änderungswünsche umsetzen muss, bis die finale Oberfläche steht. Java-Entwickler sind rar. Der Markt ist leer und die Gehälter steigen immer weiter. Deshalb ist es unwirtschaftlich, wenn Java-Spezialisten zumindest bei sehr GUI-lastigen Projekten grafische Oberflächen händisch codieren müssen. Mit RapidClipse sind auch reine Designer und Entwickler ohne sonderlichen Java-Background (z.B. 4GL-Entwickler, Wirtschaftsinformatiker, Mediengestalter etc.) in der Lage, die gesamte UI-Entwicklung zu übernehmen, sodass sich die ohnehin oft überlasteten Java-Spezialisten im Team voll auf den komplexeren
Serverteil konzentrieren können und dadurch spürbar entlastet werden. Der gesamte Entwicklungsprozess wird dadurch industrialisiert und somit effektiver und kostengünstiger, was zu einer höheren Zufriedenheit aller Team-Mitglieder führt. Matthias Wenzl, Geschäftsführer von Caweco in München, erläuterte in seinem Vortrag auf der letztjährigen JCON, dass es für sein Team unmöglich wäre, die Vorgaben seines Auftraggebers Allizanz SE – sowohl zeitlich, als auch vom Umfang her – ohne RapidClipse GUI-Builder umzusetzen.

(Listing 1)
<x:constraints zpos=”0″ width=”100%” height=”100%” />

<XdevHorizontalLayout x:name=”horizontalLayout”>

  <x:constraints zpos=”0″ width=”100%” height=”100%” />

  <XdevTextField columns=”5″ x:name=”textField”>
    <x:constraints weightx=”0.0″ width=”0px” height=”0px” />
  </XdevTextField>

  <XdevButton caption=”Search” x:name=”Button”>
    <x:constraints weightx=”0.0″ width=”0px” height=”0px” />
    <x:event>click.buttonClick</x:event>
  </XdevButton>

</XdevHorizontalLayout>

Erweiterte Hibernate-Tools für Eclipse

Bei der Datenbankentwicklung setzt RapidClipse voll auf den JPA-Standard (Java-Persistence-API), auf Hibernate als ORM-Framework und liefert standardmäßig die Eclipse-JBoss-Hibernate-Tools mit aus – aber mit interessanten Erweiterungen! JPA ermöglicht es, Objekte in einer relationalen Datenbank persistent zu speichern und zu laden. Allerdings handelt es sich bei JPA lediglich um die Spezifikation. Die wichtigsten Implementierungen dafür sind Hibernate als de facto Standard sowie EclipseLink als Referenzimplementierung. Diese werden auch als ORM-Framework oder kurz OR-Mapper bezeichnet. Voraussetzung für den Einsatz von JPA ist, dass das gesamte Datenbank-Datenmodell auch auf der Java-Seite in Form eines Java-Klassenmodells implementiert ist. Diese Arbeit nimmt einem das Eclipse-Tooling ab.
Im Idealfall kann man auf der grünen Wiese starten und zu allererst die Entity-Klassen in Java implementieren. RapidClipse bietet dafür einen Entity-Assistenten, der die Entity-Klassen (inkl. Data-Access-Objects) generiert und automatisch annotiert (Abb. 2). Per Hibernate-Export kann man sich dann die gesamte Datenbank automatisch generieren lassen.

Existiert bereits eine Datenbank auf der man aufsetzen möchte, kann man sich umgekehrt mit dem Hibernate-Import die entsprechenden
Entity-Klassen dazu generieren lassen (Abb. 3). Das läuft allerdings meist nicht so reibungslos ab. Denn Hibernate unterstützt insgesamt rund 25 Datenbanken und Formate. Allein PostgreSQL besitzt 41 verschiedene Datentypen. Java kennt dagegen nur 9 primitive Datentypen. Beim Import der Tabellen-Metadaten kommt es deshalb regelmäßig zu Datatype-Mapping-Errors, weil der Importer datenbankspezifische Typen, z.B. MONEY, BLOB, CLOB etc., nicht automatisch auf geeignete Java-Typen mappen kann. Der Entwickler muss diese Probleme dann selbst auflösen und sämtlichen Entity-Klassen mit Hibernate-Annotations versehen. Auf StackOverflow findet man dazu 354 Einträge.
In RapidClipse wurde dieses Problem bereits in Version 2 gelöst. Für alle unterstützten Datenbanken gibt es eine vollständige Mapping-Strategie, die man bei Bedarf auch anpassen kann. Datatype-Mapping-Errors treten in RapidClipse also nicht mehr auf.

Einfache Datenbankabfragen

Datenbankabfragen werden bekanntlich in SQL formuliert. Das direkte Einbinden von SQL-Abfrage-Code als Strings in Java-Code bringt jedoch erheblich Nachteile mit sich, auch wenn Hibernate explizit Native-SQL unterstützt. Zum sind SQL-Strings nicht typsicher. Es gibt keine Autovervollständigung, keine Compiler-Checks oder Syntax-Highlighting durch die IDE und wenn der Code fehlerhaft ist, kann man das erst zur Laufzeit feststellen. Meist erhält man aber keine sonderlich aussagekräftigen Fehlermeldungen von der Datenbank. Zum anderen ist SQL-Code trotz SQL-Standard in der Praxis fast immer datenbankspezifisch. Soll die Anwendung später auch mal mit anderen Datenbanken funktionieren, muss man im schlechtesten Fall unzählige SQL-Strings anpassen. Das ist nicht nur eine Sissyphusarbeit, sondern zudem eine enorme potentielle Fehlerquelle und mit sehr viel Testaufwand verbunden.
JPA stellt deshalb mit JPQL (Java-Persistence-Query-Language) und JPA-Criteria zwei verschiedene Java-APIs für das Schreiben von JPA-konformen Queries in Java zur Verfügung. Im Vergleich zu Plain-SQL wirken beide sehr viel umständlicher. JPQL ist jedoch deutlich schlanker, übersichtlicher und wird deshalb in der Praxis häufiger verwendet. Großer Nachteil: JPQL ist ebenfalls nicht typsicher. Nur JPA-Criteria ist typsicher, der Code wirkt jedoch stark aufgebläht und sehr unübersichtlich – kein Vergleich mit Plain-SQL, siehe (Listing 3). Im Java-Umfeld findet man noch weitere Query-APIs von Drittherstellern, die man natürlich auch in RapidClipse verwenden kann. Diese sind aber entweder nicht JPA-konform oder lizenzkostenpflichtig.

Um das Problem zu lösen, stellt RapidClipse mit JPA-SQL eine Query-Language zur Verfügung, welche die Vorteile Typsicherheit, JPA-Konformität und Datenbankunabhängigkeit mit der Einfachheit von Plain-SQL vereint. Die Abfragen werden getrennt vom Java-Code in einem speziellen JPA-SQL Editor formuliert. Die JPA-SQL Syntax wurde eng an SQL angelehnt und ist deshalb einfach und schlank (Listing 2). Aus dem JPA-SQL Code generiert die IDE dann den typsicheren und datenbankunabhängigen JPA-Criteria-Code direkt als Methodenaufruf in die entsprechende DAO-Klasse (Listing 3). Auf Basis des Criteria-Codes generiert Hibernate dann zur Laufzeit vollautomatisch die SQL-Statements für die angebundene Datenbank. Vor allem in größeren Projekten mit hunderten Queries ist JPA-SQL eine große Hilfe und die spätere Unterstützung weiterer Datenbanken und sogar ein Datenbankwechsel ist jederzeit problemlos und ohne Zusatzaufwand möglich. JPA-SQL ist Open Source und kann auch unabhängig von RapidClipse verwendet werden.

(Listing 2) – Datenbankabfrage in JPA-SQL
findAllCustomerWhere()
{
select * from Customer where city = “London”
}

(Listing 3) – Generierter Abfrage-Code auf Basis von JPA-Criteria
public class CustomerDAO extends JPADAO<Customer, String> {
public CustomerDAO() {
  super(Customer.class);
  }

/**
* @queryMethod Do not edit, method is generated by editor!
*/
public List<Customer> findAllCustomerWhere() {
  final EntityManager entityManager = em();

  final CriteriaBuilder criteriaBuilder = entityManager.
  getCriteriaBuilder();

  final CriteriaQuery<Customer> criteriaQuery = criteriaBuilder.
  createQuery(Customer.class);

  final Root<Customer> root = criteriaQuery.from(Customer.class);
  criteriaQuery.where(criteriaBuilder.equal(root.get(Customer_.city),
criteriaBuilder.literal(“London”)));

  final TypedQuery<Customer> query = entityManager.
  createQuery(criteriaQuery);
  return query.getResultList();
  }
}

Bessere Performance durch Caching

Hibernate-Anwendungen sind standardmäßig eher träge. Deshalb liefert RapidClipse mit EH-Cache ein Caching-Framework aus, das als Hibernate-Second-Level-Cache verwendet. Abfrageergebnisse werden damit im schnellen Hauptspeicher vorgehalten, sodass nicht mehr bei jeder Abfrage ein vergleichsweise langsamer Festplattenzugriff erfolgen muss. Datenbankzugriffe werden dadurch spürbar beschleunigt und die gesamte Anwendung wird deutlich performanter. Sämtliche Einstellungen sind bereits vorkonfiguriert, sodass man keine schwerwiegenden Fehler machen kann.

Cross-Platform-fähige Anwendungen

Für das Deployment stellt RapidClipse ebenfalls ein Tooling zur Verfügung. Jedes Projekt lässt sich ohne zusätzliche Anpassung aus ein und derselben Codebase heraus als Web-Anwendung, hybride mobile App oder klassische Java Desktop-Applikation ausliefern. Egal für welche Variante man sich entscheidet, die Anwendung läuft immer auf dem Server, die UI ist immer HTML-5, die dynamisch auf dem Server generiert, an den Client ausgeliefert und in einem Browser gerendert wird. Die von RapidClipse erzeugten hybriden Apps, die auf iOS und Android laufen, bestehen aus einem nativen Teil (Cordova), der den Zugriff auf alle wichtigen Gerätefunktionen wie Kamera, Kontakte, NFC, Geo-Location, Barcode-Scanner, Bluetooth etc., sowie die Auslieferung über App-Stores erlaubt. Die HTML-Oberfläche wird von einem eingebetteten Browser im Fullscreen-Modus angezeigt. Wer keinen Mac besitzt, kann iOS Apps per integriertem Dienst in der Cloud generieren lassen. Die mit RapidClipse erzeugten Desktop-Applikationen basieren weder auf Swing, noch auf SWT oder JavaFX, sondern sind ebenfalls Hybride. Die Architektur ist identisch mit hybriden Apps. Die Applikation besteht aus einem nativen SWT-Window und einem eingebetteten Browser, der die UI rendert. Desktop-Anwendungen können wahlweise als Client-Server-Applikation oder Fat-Client ausgeliefert werden und sind plattformunabhängig unter Windows, Linux und Mac OS X lauffähig.

Neu in Version 4

RapidClipse 4.0 basiert auf der Eclipse Version 2018-12, unterstützt Java 11, basiert aber noch auf der Vaadin Version 7. Erst mit der nächsten RapidClipse Version soll der große Sprung bei der Vaadin Version kommen. Am GUI-Builder wurden Performance-Optimierungen durchgeführt, die Hibernate-Cache-Konfiguration für multiple Datenquellen wurde stark verbessert und es sind neue Datenquellen sowie zahlreiche JDBC-Treiber-Updates dazu gekommen. Last-but-not-least gibt es jetzt eine Integration für Google-Charts (Abb. 4). Für bereits bestehende Rapid-Clipse 3 Projekte besteht kein Migrationsaufwand beim Umstieg auf die neue Version. Alles in allem ist RapidClipse 4 eine solide Version ohne revolutionäre Neuerungen. Diese stehen aber in der nächsten Version an, die schon im Herbst verfügbar sein soll.

Wie geht es weiter

Seit jeher plagen sich Web-Entwickler mit Browser-Inkompatibilitäten herum. Da das Google-Web-Toolkit sämtliche Browser-Anpassungen mitbringt und anfangs die gesamte Arbeit dafür von Google geleistet wurde, hat Vaadin vor etwa 12 Jahren entschieden, seine UI-Widget-Palette auf GWT-Komponenten aufzusetzen.
Mit Web-Components gibt es jetzt erstmals einen W3C-Standard für UI-Komponenten, der das Problem inkompatibler Browser und JavaScript-Libraries endgültig beseitigen könnte. Web-Components basieren auf einer standardisierten Architektur, bringen ihren eigenen Code mit, lassen sich mit gewöhnlichen HTML-Tags in jede HTML-Seite einbinden, lassen sich mit beliebigen anderen Web-Components kombinieren – und sind sehr performant. Die meisten Browser unterstützten bereits Web-Components nativ. Das von Google entwickelte
Framework Polymer sorgt dafür, dass Web-Components auch in allen anderen Browsern funktionieren. Web-Components die UI-Technologie der Zukunft!

Bei Vaadin wurde dies sehr früh erkannt und man hat 2014 damit begonnen, völlig neue UI-Komponenten auf Basis von Web-Components zu entwickeln. Vaadin 8 war eine Art Übergangslösung. Die Version enthielt bereits das neue Databinding für Web-Components und einen Kompatibilitätsmodus zum Weiterbetreiben von Vaadin 7 Anwendungen, der allerdings nicht alle Vaadin 7 Features abdeckte, sodass Vaadin 8 in RapidClipse nie zum Einsatz kam. Mit Vaadin 10 wurde dann der gesamte auf GWT basierende UI-Stack endgültig durch die
neuen Web-Components abgelöst. Dieser Schritt kam jedoch verfrüht, denn für fast die Hälfte aller GWT-Komponenten gab es noch keine Web-Components. Neben Komponenten wie Accordeon, DateTimeField, PopupView, ContextMenu etc. fehlten auch sehr wichtige Komponenten wie Tree, RichTextAre und MenuBar. Das ist auch der Grund, warum RapidClipse 4 immer noch auf Vaadin 7 basiert. Auf der vergangenen Oracle Code One in San Francisco hat Vaadin erstmals offiziell kommuniziert, dass man den ursprünglichen Umfang an UI-Komponenten aus Vaadin 7 voraussichtlich erst mit Vaadin 14 wieder erreicht haben wird.

Nachdem darüber nun Klarheit herrscht, geht es auch in der RapidClipse Entwicklung wieder zügig voran. Der neue GUI-Builder für Web-Components ist bereits fertig und soll in Kürze als Beta frei gegeben werden. Die erste Developer-Preview verrät bereits, dass es keine abgeleitete UI-Komponenten-Palette (z.B. XdevButton, XdevTextField etc.) mehr gibt, sondern die Standard-Vaadin-Komponenten verwendet werden. Das Rapid-Clipse Framework wurde sogar vollständig neu geschrieben. Die einzelnen APIs wie Authentifizierung und Autorisierung, das Mobile-Kit etc., wurden entkoppelt und können dadurch durch andere Implementierungen ersetzt oder unabhängig vom
RapidClipse-Framework verwendet werden. Auch das bisher fest verzahnte Hibernate kann zukünftig problemlos durch einen JPA-Provider wie EclipseLink ersetzt werden. Die finale Rapid-Clipse Version soll laut Plan bis Mitte September verfügbar sein und auf der diesjährigen JCON, (24. bis 26. September 2019 in Düsseldorf) offiziell vorgestellt werden.

Geringe Systemvoraussetzungen

RapidClipse setzt für die Entwicklung lediglich Java-SE ab Version 8 und zur Laufzeit einen beliebigen Servlet-Container voraus. Für die interne Vorschau kommt Tomcat zum Einsatz. Die Distribution ist völlig lizenzkostenfrei für Windows, Linux und Mac OS X verfügbar. Runtime-Lizenzen gibt es ebenfalls keine. Das gesamte Framework ist Open Source.
Zielgruppe sind Anwendungsentwickler, die Unternehmensanwendungen unter großem Zeitdruck implementieren müssen und sich dabei nicht mit Low-Level-Programmierung aufhalten möchten, aber dennoch großen Wert auf eine solide und individuell anpassbare Architektur und Code-Basis legen. Insbesondere Anwender, die dringend veraltete Java Applets und Web-Start-Applikationen schnell und kostengünstig ablösen müssen, ist RapidClipse eine interessante Alternative.