Jax 2013

This blog post is about my visit at the JAX 2013 in Mainz, one of the biggest Java conferences of europe. As an exception this time the post is written in german and not english.

In der letzten Woche hatte ich durch meinen Arbeitgeber die Möglichkeit, die JAX 2013, eine der größten Java-Konverenzen Europas in Mainz zu besuchen. In diesem Blogpost möchte ich über Vorträge berichten, die ich besucht habe.

JavaFX

Enterprice Anwendungen mit JavaFX (8)

Adam Bien berichtete in seinem Vortrag “Enterprice Anwendungen mit JavaFX (8)” recht unterhaltsam von seinen Erfahrungen mit Enterprice Anwendungen und den Dingen, die bei dieser Klasse von Anwendungen seiner Ansicht nach relevant sind. Er kam zu dem Schluss, dass hier JavaFX in vielen Fällen eine lohnenswerte Alternative zu den klassischen Webtechnologien sein kann.

Im Verlauf des Vortrags stellte er anschließend seine Vorstellung davon vor, wie Entwickler Oberflächen mit JavaFX entwickeln sollten. Trotz anfänglicher Skepsis sieht er vor allem FXML, die XML-Basierte Beschreibungssprache für JavaFX ab Version 2, als ein sehr gutes Werkzeug an. Mit FXML lässt sich eine Oberfläche deklarativ beschreiben und dynamisch von JavaFX aus laden. In der FXML-Datei kann der Name einer Controller-Klasse angegeben werden, der dann von JavaFX automatisch instanziiert wird und der per Dependency Injection die benötigten Referenzen auf UI-Elemente erhält. Adam Bien sieht hier das Prinzip der Inversion of Control sehr gut umgesetzt.

Da für FXML-Dateien auch ein sehr reichhaltiger und ausgereifter WYSIWYG-Editor namens SceneBuilder existiert, sieht er diese Vorgehensweise bei der Entwicklung von Desktop-Oberflächen als vorteilhaft an.

Die einzige Lücke, die in diesem Mechanismus noch besteht, ist die Verwendung von echter Dependency Injection für die Anbindung der Backend-Logik. Der DI-Mechanismus von JavaFX injected nämlich nur UI-Elemente aus der FXML-Datei in den Controller, andere Abhängigkeiten wie Services werden nicht automatisch eingefügt. Da die Instanziierung des Controllers ebenfalls von JavaFX übernommen wird, kann der Entwickler auch nicht einfach per händischer Dependency-Injection per Konstruktor die Abhängigkeiten hineinreichen.

Glücklicherweise ist der DI-Mechanismus von JavaFX relativ leicht erweiterbar und so stellte Adam in seinem Vortrag auch das von ihm entwickelte Mini-Framework Afterburner.fx vor, welches einfache DI auf simple Art und Weise umsetzt und dabei, wie andere DI-Frameworks auch, die ‘javax.inject’-Annotationen verwendet.

Wer schon immer mal sehen wollte, wie einfach ein DI-Framework sein kann, der sollte sich unbedingt den Quellcode von Afterburner.fx auf Github anschauen. Das ganze Framework besteht nämlich nur aus 2 relativ kleinen Klassen.

JavaFX vs. Html5

Im Vortrag “JavaFX vs. Html5” zeigt Björn Müller einige Anwendungsfälle auf, bei denen HTML5 (in Kombination mit JavaScript) seiner Ansicht nach nicht die passende UI-Technologie ist, sondern klassische Desktop-Oberflächen besser geeignet sind. Er bezieht sich vor allem auf große, umfangreiche Business-Applikationen mit umfangreichen Eingabemasken und mehreren Hundert Screens. Als Beispiele nennt er Anwendungen aus dem Bereich der Logistik und Lagerverwaltung.

Als Gründe nennt er nicht nur die nach wie vor bessere Performance von Desktop-UI’s, sondern vor allem die Entwicklungseffizienz, d.h. wie schnell die Entwickler die entsprechende Funktionalität liefern können.

Als eine mögliche Lösung für die Entwicklung großer Business-Applikationen stellte Björn anschließend das von ihm entwickelte Framework CaptainCasa vor.

CaptainCasa stellt eine Verbindung des UI-Frameworks JavaFX mit dem Serverseitigen Komponenten-Modell von JavaServer Faces her. Denn obwohl JSF in den meisten Fällen zur Entwicklung von HTML-Oberflächen genutzt wird, ist es prinzipiell unabhängig von der tatsächlichen benutzten View-Technologie.

Die Serverseite kann damit klassisch mit JavaEE entwickelt werden, die UI wird mittels JSF und einer speziellen Tag-Library umgesetzt. Auf Client-Seite kommt statt dem Webbrowser jedoch ein JavaFX-Renderer zum Einsatz. Die UI ist damit nicht fest im Client implementiert sondern wird dynamisch auf Serverseite generiert und mittels eines XML-Datenaustauschformats zum Client gesendet, welcher aus diesen Informationen die Oberfläche aufbaut. Eingaben des Nutzers werden auf ähnliche Weise wieder zum Server gesendet und durchlaufen dort den bekannten JSF-Livecycle.

Für Entwickler, die bereits mit JSF zu tun hatten, ist der Lernaufwand deshalb relativ gering. Sie müssen sich nicht mit den Details von JavaFX ausseinander setzen, sondern können ihre gewohnten Serverseitigen Technologien aus dem JavaEE-Umfeld einsetzen. Neu ist lediglich die Tag-Library von CaptainCasa, die jedoch vom Prinzip her nicht wesentlich anders funktioniert, als bekannte JSF-Libraries.

CustomComponents in JavaFX

Gerrit Grunwald stellte in seinem Vortrag das wesentlich von ihm vorangetriebene Projekt JFXtras vor, welches eine Sammelstelle für JavaFX-Customcontrols darstellt. Er zeigte, welche Möglichkeiten JavaFX bietet um selbst Controls herzustellen oder vorhandene Controls anzupassen. Dazu zeigte er zunächst den prinzipiellen Aufbau von JavaFX-Controls, welche Interfaces und Dateien zu einem Control gehören und wie diese zusammenhängen. Allein dieser Einblick war für mich als Entwickler schon sehr spannend und lehrreich.

Als praktisches Beispiel nutzte er ein Control, welches eine LED-Leuchte darstellen sollte. Zum Erstellen der Grafiken benutzte er ein Vektorgrafikprogramm, welches SVG exportieren konnte. Die SVG-Datei convertierte er mit einem speziellen Tool in ein Format, welches direkt von JavaFX dargestellt werden kann und benutzte dieses als grafische Grundlage seines Controls. Anschließend musste noch die Logik des Controls implementiert werden, was er natürlich mit JavaFX-Bindings umsetzte.

OpenDolphin

Dierk König hat in seinem Vortrag das von ihm mitentwickelte Framework OpenDolphin vorgestellt. OpenDolphin ermöglicht es, eine Anwendung nach dem Shared Presentation-Model Muster zu entwickeln. Dabei wird das Presentation-Model, also sämtliche Daten, die die Benutzeroberfläche beschreiben, auf einem Server gehalten. Die Oberfläche des Clients verbindet sich mit dem Server und bindet sich direkt an dieses Presentation-Model. Serverseitige Änderungen an diesem Model sind dann unmittelbar auch auf Clientseite sichtbar. Das gleiche gilt äquivalent auch für Änderungen des Clients, die sofort zum Server synchronisiert werden.

Werden mehrere Clients mit dem Server verbunden, wird dadurch die UI der Clients untereinander ebenfalls synchron gehalten.

Dies war für mich auch der Hauptgrund, den Vortrag zu besuchen, da dieses ein ähnlicher Anwendungsfall ist, für den meine Arbeitskollegen und ich auch unser Framework SynchronizeFX erstellt haben. In unserer Applikation kommt es ebenfalls auf eine Synchronisierung der UI zwischen mehreren Instanzen an.

Im Detail betrachtet hat OpenDolphin jedoch einen anderen Ansatz. Es lässt sich zwar mit JavaFX verbinden, arbeitet intern jedoch mit einer eigenen Bindings-Implementierung, während unser Framework ausschließlich mit JavaFX-Bindings arbeitet.

Während bei unserem Framework der Hauptaugenmerk auf eine einfache Integration in JavaFX-Anwendungen lag, sieht OpenDolphin eines seiner wesentlichen Ziele darin, die leichte Austauschbarkeit von UI-Technologien zu unterstützen. Da beim Shared-Presentation-Model die einzige Verbindung zwischen Client und Server das gemeinsame Datenmodell ist, lässt sich dieses Ziel vergleichsweise gut erreichen.

In der Demo hat er ein Beispiel vorgeführt, bei dem eine JavaFX-Anwendung und eine HTML5/JavaScript-Anwendung miteinander synchronisiert waren und jeweils die geänderten Daten des anderen Clients anzeigen konnten.

JSF / CDI

Neues aus JavaServer Faces 2.2

In diesem Vortrag hat Andy Bosch über Neuerungen im neuen JavaServer Faces Standard 2.2 berichtet. Er hat dabei 4 wichtige Haupt-Features im Detail erklärt und weitere Nebenfeatures genannt.

Die 4 “Big Ticked Features”, wie er es nannte, sind:

HTML5 Support

Wie der Name vermuten lässt, handelt es sich hierbei um eine bessere Integration von HTML5-Features in JSF. Zwar war es auch bisher schon möglich, mit JSF HTML5-Dokumente auszuliefern und auch die neue HTML5-Tags zur semantischen Strukturierung von Webseiten ließen sich ohne weiteres benutzen.

Probleme gab es jedoch z.B. mit den von HTML5 definierten data-* Attributen, mit denen in HTML5 jedem Element beliebige Meta-Informationen mitgeliefert werden können. Dies soll im neuen JSF besser unterstützt werden.

Resource Library Contracts

Für JSF 2.2 war ursprünglich geplant, Multi-Templating zu unterstützen, d.h. es sollte möglich sein, mehrere Themes für eine Anwendung zu definieren und einfach, auch zur Laufzeit, auszutauschen. Ideen eines Marketplaces, auf dem Templates und Themes gehandelt werden könnten, standen im Raum. Letztlich hat sich jedoch gezeigt, dass diese Ideen nicht alle in der gesetzten Zeit umsetzbar waren. Gewissermaßen eine abgespeckte Version ist nun unter dem Namen “Resource Library Contracts” im neuen JSF 2.2 Standard enthalten.

Mit Resource Library Contracts wird definiert, dass in einer JSF-Anwendung unter ‘META-INF/contracts’ Verzeichnisse angelegt werden können, die einem Template entsprechen. In diesem Verzeichnis sollen alle zum Template gehörenden Dateien untergebracht werden, also XHTML-, CSS-, JavaScript- und sonstige Dateien.

Es wird weiterhin ein gewisser Formalismus definiert, welchen Standards diese Templates folgen sollten, damit ein einfaches Austauschen auch zur Laufzeit möglich ist. Dieser Formalismus ist allerdings nicht besonders streng, weshalb nicht garantiert werden kann, dass das Austauschen ohne Anpassung funktioniert.

Letztlich ist es trotzdem die Aufgabe des Entwicklers, sicherzustellen, dass bestimmte Template-Abschnitte vernünftige Bezeichner besitzen, die in allen Templates identisch sein müssen, damit Elemente ausgetauscht werden können.

Faces Flows

Mit Faces Flows soll es in Zukunft einfacher werden, Seiten zu implementieren, die eine festgelegte Abfolge besitzen, wie zum Beispiel Wizards, Bestellprozesse oder ähnliches.

Dafür wird ein neuer CDI-Scope FlowScope definiert, der genauso lange gültig ist, wie die Seiten des Flows angezeigt werden. Die Definition, welche Seiten zu einem Flow gehören, soll dabei deklarativ erfolgen, d.h. die einzele Seite weiss nicht unbedingt, dass sie zu einem Flow gehört. Dies soll die Wiederverwendbarkeit erhöhen.

Neue JSF-Tags ermöglichen ausserdem die detailierte Steuerung des Flows z.B. mittels Bedingungen/Switch Anweisungen und der Definition eines Start- und Ende-Punkts.

Stateless Views

Das “Stateless Views”-Feature wurde von Andy Bosch im Vortrag nicht sehr euphorisch vertreten. Er machte eher den Eindruck, dass dieses Feature nicht wirklich wichtig oder sinnvoll wäre. Es geht darum, bestimmte Views zu definieren, die keinen serverseitigen Zustand besitzen. Das Ziel dahinter ist, die Performance und den Speicherverbrauch zu minimieren.

Andy hatte jedoch bezweifelt, dass Stateless-Views dazu beitragen können, diese Ziele nennenswert voranzubringen, da schon der Partial-State-Saving-Mechanismus, der bei JSF 2 Einzug gehalten hat, den zu speichernden und übertragenden Zustand auf ein nötiges Minimum reduziert.

Hier die gesamte Feature-Übersicht JSF 2.2.

Apache Deltaspike

Apache Deltaspike ist eine Sammlung von Erweiterungen für “Contexts and Dependency Injection” (CDI). Es ist aus den Projekten Seam 3 und Apache CODI hervorgegangen und soll diese beerben. Im Vortrag von Mark Stuberg wurde das Projekt vorgestellt und einige Beispiele gezeigt.

Beyond PrettyFaces - Einführung in Rewrite

Christian Kaltepoth stellte in seinem Vortrag das Framework Rewrite vor, welches aus dem JSF-Framework PrettyFaces hervorgegangen ist. PrettyFaces hatte mir schon in einigen JSF-Projekten gute Dienste geleistet, weshalb es schön war, einmal direkt von einem der Entwickler einen Einblick zu bekommen.

PrettyFaces ist eine Bibliothek für JavaServer Faces, die einen URL-Rewrite-Mechanismus bereitstellt, um die URLs, die eine JSF-Anwendung benutzt, nach den Wünschen des Entwicklers anzupassen. Ziel ist es, die teils langen und “hässlichen” URLs, die JSF von Haus aus nutzt, durch hübsche und kurze URLs zu ersetzen. Statt ‘www.example.org/faces/article/overview.xhtml?articleId=1234’ könnte dann z.B. die URL ‘www.example.org/articles/1234’ benutzt werden. Damit wird gleichzeitig die verwendete UI-Technologie ein wenig versteckt. Vor allem aber können so Links erzielt werden, die sich als Bookmarks vernünftig speichern lassen.

“Rewrite” setzt dieses Ziel fort. Es wurde aus dem ursprünglichen Framework PrettyFaces herausgelöst und kann als Nachfolger verstanden werden. Rewrite versteht sich nicht mehr nur als Erweiterung für JavaServer Faces sondern als allgemeines URL-Rewriting-Framework für Java. Die Unterschiede, die auch im Vortrag gezeigt wurden, betreffen vor allem die Art und Weise der Konfiguration. Bei PrettyFaces hat der Entwickler die Wahl zwischen einer XML-Konfigurationsdatei und Annotationen direkt an den JSF-ManagedBeans. Da die letztere Variante aber sehr unübersichtlich ist und ein zentraler Ort zur Übersicht über alle Rewrite-Regeln vorteilhaft ist, wurde bei uns in Projekten immer die XML-Konfiguration eingesetzt. Diese hat jedoch auch ihre Nachteile, vor allem die geringe Flexibilität, mit der Regeln geschrieben werden können.

Bei Rewrite wird dieses Problem gelöst, in dem eine Fluent-API zur Beschreibung der Regeln mitgeliefert wird. Damit kann der Entwickler seine Regeln in Java-Code formulieren und ist bei Refactorings abgesichert. Er kann aber trotzdem alle Regeln an einer zentralen Stelle im System sammeln oder aber auf verschiedene Klassen aufteilen, wenn das notwendig sein sollte. Der Entwickler hat also die volle Kontrolle.

Aus meiner Sicht ist dieser Ansatz sehr vielversprechend und sollte unbedingt im Auge behalten werden.

Slides

JSF Performance

Im Vortrag von Thomas Asel wurden einige typische Performance-Probleme von JavaServer Faces aufgezeigt und mögliche Lösungen analysiert.

Das potentielle Problem von JSF ist, dass auf Serverseite zu jedem Request ein relativ umfangreicher Lifecycle durchlaufen wird, bei dem ein Komponenten-Baum der UI aufgebaut und bearbeitet wird.

Es stellte sich heraus, dass die Größe des Komponentenbaums einen entscheidenden Einfluss auf die Performance der Applikation hat. Je größer der Komponentenbaum, desto länger braucht JSF für die Abarbeitung des Lifecycles. Interessanter Weise gibt es hier offensichtlich starke Unterschiede zwischen den beiden JSF-Implementierungen. Bei der Referenzimplementierung Mojarra kann man einen exponentiellen Zusammenhang zwischen der Größe des Komponentenbaums und der Verarbeitungsdauer feststellen, was dazu führt, dass bei relativ großen UI’s Mojarra recht lange braucht. Die alternative Implementierung Apache MyFaces zeigt ein anderes Verhalten. Zum einen ist die Geschwindigkeit durchgehend deutlich höher als bei Mojarra. Zum anderen ist hier ein Linearer Zusammenhang zwischen Größe des UI und Verarbeitungsdauer zu sehen, was dazu führt, dass der Geschwindigkeitsvorteil umso größer ausfällt, je größer der Komponentenbaum ist.

Aus diesen Erfahrungen können zwei Bausteine zur Verbesserung der Performance gewonnen werden:

  1. Wenn möglich, sollte Apache MyFaces als Implementierung gewählt werden. Dies ist allerdings nicht immer möglich. Zwar kann bei allen Enterprise-Servern die JSF-Implementierung getauscht werden, oft sind hier jedoch praktische Einschränkungen durch Support-Verträge gegeben, die verfallen wenn der Server umkonfiguriert wird.

  2. Der Entwickler sollte unabhängig von der Implementierung die Größe des Komponentenbaums möglichst klein halten. Vor allem bei Custom-Komponenten ist Vorsicht geboten. Zum Beispiel sollten reine Wrapper-Komponenten vermieden werden.

Neben der reinen JSF-Verarbeitung existieren noch weitere Stellen, bei denen auf die Performance Einfluss genommen werden kann. Vor allem die Übertragung von zahlreichen großen Dateien zum Client nimmt viel Zeit in Anspruch. Um diesem Problem zu begegnen, können JavaScript- und CSS-Dateien zunächst zu je einer Datei zusammengefasst werden und diese kombinierten Dateien “minifiziert” werden. Es wurde jedoch gezeigt, dass dabei auch Vorsicht geboten ist und umsichtig geplant werden muss, um tatsächlich einen Vorteil zu erlangen. Würde man z.B. sämtliche JavaScript-Dateien des gesamten Projekts zu einer einzelnen Datei kombinieren. Es wird jedoch in der Regel nicht überall sämtlicher Code benötigt sondern nur ein Teil davon. Es bietet sich hier z.B. an, Bibliotheken wie jQuery und natürlich jsf.js, die JavaScript-Library von JSF selbst, zu einer Datei zusammenzufassen, da dieser Code in der Regel überall gebraucht wird.

Wichtig ist auch die Integration der Kombinierungs- und Minifizierungsschritte in den Build-Prozess, da man während der Entwicklung ja die Quelltexte in einem vernünftig lesbarem Format erhalten möchte. Im Vortrag wurden einige Tools genannt, die diese Vorgänge z.B. in einen Maven-Build-Schritt erledigen.

Weiterführende Informationen zu den Performancemessungen sind hier zu finden.

more...

SynchronizeFX Demo and HowTo

I’ve done a little demo application and a step-by-step tutorial for SynchronizeFX.

The demo consists of a small server application with a simple domain model and a client application that shows a slider control that is synchronized.

On the server there is a domain model that contains a DoubleProperty named sliderValue. This model is transfered to the client applications and will be synchronized between the applications.

On the client we have a view containing a Slider control. This control is bound bidirectionally to the model value so that when the user is dragging the slider at first the value changes in the local instance of the domain model and is synchronized to the server after that.

The SynchronizeFX library ensures that the domain model is synchonized automatically. This means that the change of one client is instantly send to all other clients.

screenshot of the client

The whole step-by-step tutorial and the source code can be seen at github: https://github.com/saxsys/SynchronizeFX/tree/master/demos/sliderdemo

more...

SynchronizeFX

At saxsys I’m part of a team that is developing a digital scrumboard with JavaFX. One of the key features is the instant synchronization of the UI state between different boards over the network. When you drag a task note at one of the boards it moves instandly on the other board too.

logo

For this feature we had developed a small library and I’m very pleased that we can now release this library as a free open source project called “SynchronizeFX”. You can find the code at github: https://github.com/saxsys/SynchronizeFX.

The key idea is that we synchronize models that are build up on JavaFX’s Properties. At the moment the synchronization over the network is done with websockets but other technologies are possible too.

more...

Markdown formatted License files

I like markdown. And I like open source software. To combine both I created a [github repository](https://github.com/lestard/markdown_license_files] that contains some of the widespreaded free software license files formatted with markdown. When you use this files in github projects with the file ending of “.md” they are nicely formatted on the github page.

At the moment I have this license files in the repo:

Feel free to copy them as you like.

screenshot from github

more...

Lecture 'Test-Driven-Development and Dependency Injection' at HS-ZIGR

I had the chance to give a lecture for students of the masters degree for computer science at the University of Applied Sciences Zittau / Görlitz. The title of the course of lectures was “Webdevelopment in practice” and my part was a lecture on the topic “Test driven Development and Dependency Injection”.

At first I talked about the advantages of automatic tests in professional software development. I described the different types of tests like unit tests and integration tests. One of the main points was that “real” unit tests only test the component itself and not the surrounding environment. To achive this you need to replace all dependencies of a class with mock objects to be able to simulate an environment for your tests.

Based on this insight I described the design pattern dependency injection as this pattern is the best way to be able to replace dependencies of a component. In the lecture I didn’t use a framework for dependency injection but explained how you can implement dependency injection by hand. I showed the different styles of dependency injection like “constructor injection”, “field injection” and “setter injection” and explained why in my opinion constructor injection is the most advantageous choice.

After the basics I showed the test driven way of developing software. Writing your test before the implementation is leading to better testable code and in most cases to lesser coupling between components. I personally think that one of the biggest points of doing TDD is that it helps me to focus on the requirements of the software and not the implementation. I think about how a class should be used by a developer. This leads to a better API for every class.

The last part of the lecture was a chapter about testing anti-patterns. I explained that using static methods in java is only aceptable when they are stateless and there are no side-effects. Otherwise you can’t be sure about the state of your application when executing the test. The same is true for the Singleton design pattern.

Another testing anitpattern in my opinion is using final for classes or methods as in this cases it is harder to use mocking in the tests.

Exercise

In addition to the lecture there was an computer exercise afterwards. The students had to try out TDD in practice. The exercise was taken from the german book “Das Java-Praktikum” (dpunkt.verlag, 2008, from Reinhard Schiedermeier and Klaus Köhler). This is a book with small exercises to learn and practise java programming. In the book it’s not done with TDD but in my opinion the exercises are great for this purpose.

The task was to write a class that encapsulates a specific point in time and gives the user and easy way to handle and visualize this instance of time.

The code of the test and the implementation can be found on github: https://github.com/lestard/tdd-example-clocktime.

more...

Coding-Content - TmpMail

Coding doesn’t only belongs to my day-to-day work but is also one of my favorite hobbies. And like other hobbies it’s fun to make a competition out of it. So last week I participated at the Leipziger coding contest. There where 4 categories: PHP, JavaScript and two times Java. I have chosen the second java category where the task was to develop a “fake email” application.

You can find the code here: https://github.com/lestard/tmpmail

Task: Temporal email addresses

The user of the application should be able to register herself with her private email address. After that the user can create temporal email addresses whose messages are redirected to the private email address of the user.

There are several use cases for this application: First of all you can use this temporal email addresses for registration at online shops, forums and so on where you don’t want to use your private email address to prevent spam emails.

Another use case would be to use this application for testing purposes by software developers. They could check whether there own application is sending emails the correct way.

Implementation

My implementation is based on the JavaEE technology stack. I have used JPA2/Eclipselink as persistence framework with an HSQLDB inmemory database.

Dependency-Injection is done by CDI/Weld. In addition I used the Seam Solder library to handle events of the servlet container.

The handling of SMTP is done with the SubethaSMTP library.

The frontend is based on JSF 2.1 and MyFaces as implementation. Besides this PrettyFaces and PrimeFaces where used.

The whole application was developed test driven. For this purpose FEST-Assert and Mockito where used. Additionally Weld-SE was used for integration tests.


p.s. At the end I won the contest and got a Lenovo Thinkpad Edge as an award :-)

more...

Talk about BeanValidation at JavaUserGroup Görlitz

Once again I gave a talk at the JavaUserGroup Görlitz. This time the talk was about “JSR-303 BeanValidation”.

BeanValidation is a part of JavaEE that is used for validation of data. You use java annotations to describe restrictions and constraints for your java classes. The validator can then evaluate these annotations and give you an answer whether your objects are “valid” or “invalid”. At the moment there are 3 ways to use this validation.

  1. By hand. To do this you use an instance of the Validator class and use the method “validate”. As the result you get a collection of ConstraintViolation objects for every violation. When this collections is empty your object is considered to be valid.

  2. When using JavaServer Faces 2 (JSF) as frontend framework validation can be done automatically. You have nothing to do but to put an BeanValidation implementation (Hibernate Validator or Apache BVal) on the classpath or use an JavaEE compatible application server.

  3. When you are using JavaPersistence API (JPA) to persist your data validation is also done automatically. Everytime an Entity with BeanValidation annotations gets persisted by the EntityManager the validation is done in the first place.

In the talk I was showing some of the build-in annotations and how you can create your own custom constraints and custom validators to fit your needs. I also showed how you could include the Apache Commons Validator into the BeanValidation framework.

The Example code is available on Github: https://github.com/lestard/juggr_BeanValidation

The slides are available here and on Google-Drive

more...

Maven Archetype for CDI and JSF

Today I created a maven archetype for small JSF/CDI based applications. It creates a small web application that is meaned to be run on a Servlet Container and not on a JavaEE Application Server.

As you know on a servlet container there are no implementations provided for JavaEE-API’s like JavaServer Faces or JavaPersistence API. Therefore I added the needed dependencies in the archetype.

In addition there are some Testing libraries like JUnit, Mockito and FEST-Assert added too.

The configuration of the archetype is highly opinionated and contains the libraries I’m using regularly. It is intended for my own usage but as it doesn’t cost me anything to publish it to github you might find it usefull too.

Github: https://github.com/lestard/jsf-cdi-archetype

more...

Java Game ColorPuzzle

Today I like to show you a little java game I have written roughly a year ago. Back in that time I was looking at the Java-2D-API and Swing/Canvas and thought that the best way to learn this stuff is to write a little game. Thinking of an good example game idea was not that easy so I decided to recreate an existing JavaScript game that I had played some time ago. The problem is that I can’t remember what the original name was and where I found this game. :-(

screenshot

The gameplay is easy: You have a grid of squares like a chessboard but not in black and white. Instead the squares are randomly filled with one of 7 colors. At the beginning the player has control over the square in the top left corner. With the buttons on the right (one for every color) you can change the color of the square(s) you control. When there is a square with the same color in the direct neighbourhood of one of your controlled squares, this square is now also controlled by you. When you now click on one of the color-buttons, all squares controlled by you are changing the color again. The aim of the game is to control all squares with as little clicks as possible.

Like I said, the main reason to create the game was not to build a great new super game but to learn and exercise the programming language and framework. The game was working more or less but there was an exception with the painting of the component in rare cases. I wasn’t able to find the real reason for this exception and so I haven’t released the game.

Since then I haven’t worked on the game but some weeks ago I remembered the game and wanted to finish it. While looking at the code I found some code smells and bad design. When I would build a game like this from scratch today I would do many things differently.

As the first task I was looking at the unit-tests: I replaced EasyMock with Mockito and changed all asserts to used FEST-Assert. After this I refactored many classes and splitted the code into smaller pieces. While I didn’t know the concept of Dependency Injection back in the time I created the game, nowadays DI for me is one of the most important design patterns and so I modified the application to use CDI/WELD-SE. I changed the whole event-mechanism to also use the features of CDI-Events. With this modifications I was able to reduce the coupling between the components a lot.

The last modification was to change the way the canvas is repainted. The old version was using a game-loop with a repaint-mechanism that was more suitable for games that need a high framerate. As this is not the case for this game I changed it to used the default repaint mechanism of the swing components and removed the game loop. The exception that irrirtated me at first was now gone and so I thought it would be the right time to “release” the game now.

Another reason to create the game was the idea to create something like an “artificial intelligence” (of cause it’s not realy intelligent or clever) that can solve the game. I liked to test many strategies to build AIs and let them play against each other. I created a “Bogo” algorithm that chooses a color at random (referring to BogoSort) and a “Bruteforce” algorithm that tries every available color. At the moment this artificial intelligence feature is disabled but probably in the future I will create a UI for this.

Have fun with the game. Before I forget, of course the Code is free software under the GPL and can be seen on github. Feel free to look into it and tell me what you think.

more...

Another talk at the JUG Görlitz about JSF and CDI

Last year I already gave a talk about JavaServer Faces and Contexts and Dependency Injection at the Java User Group Görlitz. At the january meeting of the JUG Görlitz on january the 25th I gave another talk building upon the last one. This time I explained some other features of JSF and CDI, namely:

  • navigation in JSF
  • templates and reusing of facelets
  • Ajax with JSF
  • little example with PrimeFaces
  • CDI Producer
  • Observer Pattern with CDI
more...