Kategorien
JavaFX Scala

JavaFX 2.0 in Scala, Groovy, Closure

Nette Aussichten: Hier die Slides von einem Vortrag der Java One. So nett JavaFX Script war, ich werde es nicht wirklich vermissen. Wichtig ist allerdings ein brauchbares GUI Framework, mit dem sich einfach(!) coole GUIs erstellen lassen, die dann auch noch auf den Zielplattformen performant(!) laufen. Damit lohnt es sich vielleicht schlussendlich mal für kommerzielle, Anbieter ihre Apps in Java zu schreiben. Obwohl, der Bonus der Plattformunabhängigkeit ist erst einmal weg. Apple spielt nicht mehr mit und zieht sich scheinbar vollständig in das eigene, kleine Steve Wonderland zurück, Google kocht seine eigene Java Suppe…

Ich denke, es hängt viel davon ab, wie der Rechtsstreit zwischen Google und Oracle ausgeht. Kann man mit JavaFX Apps für WebPads und Fernseher entwickeln oder halt nur für Desktop PCs? Letzteres wäre ziemlich mager, da ohne Apple nur noch Windows mit einem relevanten Marktanteil bleibt und was ist dann an Java für kommerzielle Entwickler interessanter als .NET?

Jetzt haben wir jedenfalls eine aufgeteilte Welt: Server Java von Oracle und IBM sowie GUI-Java mit Google und Android. Mein Traum sind ja nach wie vor Apps, die auf allen Devices laufen. Ich persönlich fände es hübscher, wenn sich Google auf „richtiges“ Java einließe. Ich könnte aber auch damit leben, eine GoogleVM für kleine Apps zu installieren. Mit WebPads und TVs sind die Grenzen zum PC nur noch minimal. Also baut entweder Google etwas, das auf allem läuft oder einigt sich mit Oracle und kann auf die Desktopressourcen, die bereits in OpenJDK eingeflossen sind, zurückgreifen. In ein paar Monaten sind wir schlauer… 😉

Kategorien
Architektur JPA Tools

Datenbanken sind langsam

Klar sind sie das. Datenbanken machen IO und IO ist generell nicht so wahnsinnig schnell. Und Datenbanken sind unendlich kompliziert und generell mit enorm viel Wartung verbunden und eigentlich total Überflüssig.

Für diese Probleme sehe ich bei meinen Codereviews immer wieder mehr oder minder originelle Lösungen.

Lösung: Alles im Speicher

Man verwaltet einfach alle Daten in einem großen Objektbaum, der dann hin und wieder auf die Festplatte serialisiert wird. Bei Programmstart wird das serialisierte Objekt mit allen Daten einfach geladen und Rock ’n‘ Roll.

Das funktioniert von mir aus einigermaßen mit der berühmten „Video Verwaltung“, die man gerne mal während des Studiums baut, und mag auch noch in kleinen Startups funktionieren, die einen Onlineshop mit 1000 Artikeln haben, aber da liegt dann auch schon das Problem: Bleibt es bei 1000 Artikeln, ist das Startup irgendwann Geschichte und die Lösung hat bis zum Schluss funktioniert. Der schlimmere Fall: das Startup wächst und irgendwann hat man 1 Mio Artikel. Die passen jetzt irgendwie nicht mehr in den Speicher. Mal ganz davon zu schweigen, dass das Serialisieren eines riesigen Objektbaums auf die Festplatte nicht wirklich transaktional ist. Das bedeutet, wenn etwas schief geht, geht es schief und die Daten sind weg. Konkurrierende Schreibzugriffe (Datensätze werden von mehreren Personen gleichzeitig bearbeitet) sind zwar total gut mit Time Slots zu lösen (von 9-11 Uhr darf nur die eine Abteilung ihre Daten bearbeiten, von 11-13 Uhr die nächste), aber das ist bei vielen Datensätzen nicht mehr wirklich praktikabel.

Also merke: Die Problemstellung der Video Verwaltung als Hausaufgabe während des Studiums war dazu da, grundlegende Datenstrukturen zu erklären und nicht als Lösungsvorschlag für kommerzielle Anwendungen.

Lösung: Ich suche alles selbst

Spätestens seit Hibernate ist es total einfach, Objekte statt direkt auf die Platte in eine Datenbank zu schreiben. Das ist schon mal gar nicht so schlecht. Der Vorteil ist, dass man nun Datensätze einzeln und in einer Transaktion speichert. Wenn da mal was nicht klappt, fehlt ein Datensatz, die restlichen Daten sind noch intakt. Auch können jetzt alle Abteilungen gleichzeitig an den Daten arbeiten. Das beste aber, der Code sieht fast wie normales Java aus. Die bösen Sachen übernimmt beispielsweise JPA für uns. Und da das alles so total nach Java aussieht und man total bekannte Datenstrukturen wie Listen aus der Datenbank kriegen kann, kann man da mit der hübschen for-Schleife aus Java 5 durchiterieren und sich die Daten mit if-Abfragen raus suchen, die einen interessieren.   Alles was man braucht, ist für jede Tabelle eine „finde Alles“ Methode und ab geht’s. Man kann sogar total nett mit dem Collection Framework seine Daten nach eigenen Kriterien sortieren.

Das ganze hat nur ein Problem: es ist total ineffizient und produziert Unmengen von absolut unnötigem Code.

Datenbanken machen Datensachen!

Eben weil man meist nur bestimmte Datensätze braucht, und diese nach bestimmten Kriterien sortiert sein müssen, haben vor ungefähr 500 Jahren schlaue Computerwissenschaftler die Abfragesprache (Query Language) erfunden. Ganz, ganz kalter Kaffee? Das ist schon so lange her, das kann heute gar nicht mehr rocken?

Viel, viel schlimmer: Die Sache wird seit Generationen an allen Ecken und Enden verbessert, aktualisiert, modernisiert. Man könnte davon ausgehen, dass es ziemlich schwer wird, sich als Allrounder mit einem Menschen anzulegen, der den ganzen Tag nichts anderes macht, als sich mit effizienter Datenhaltung zu beschäftigen. Im Fall von Datenbanken lagt man sich da aber mit Generationen von Entwicklern an, die unglaublich viele Arbeitsstunden in die Technik versenkt haben – und ja, die ganze Mühe kommt auch wieder raus, wenn man seine Abfragen über die dafür vorgesehene Sprache formuliert.

Klar, die muss man dafür erst mal lernen, aber der Aufwand dafür ist deutlich geringer, als das Rad jedes mal neu zu erfinden. Ein netter Einstieg in SQL ist beispielsweise Einführung in SQL. Von SQL zur Abfragesprache von JPA ist es kein weiter Weg und ein bisschen SQL können, hat noch niemandem geschadet.

Datenbanken können das wofür sie gebaut sind unverschämt gut: Daten verwalten. Und sie sind beispielsweise in Form von MySQL oder Postgesql frei verfügbar.

Selbst die klassische Video Verwaltung lässt sich super mit einer Datenbank erledigen. Natürlich will man für so eine einfache Desktopanwendung nicht unbedingt einen Datenbankserver installieren. Dafür gibt es dann embedded Datenbanken, wie z.B. DerbyDB.

Wenn man also Sachen mit Daten machen muss, nimmt man sich eine Datenbank – die kann das schon.