Virtual machines

We all know that Java uses a „virtual machine“ that is it simulates a non-existing hardware which is the same independent of the real hardware, thus helping to achieve the well known platform independence of Java. Btw. this is not about virtualization like VMWare, VirtualBox, Qemu, Xen, Docker and similar tools, but about byte code interpreters like the Java-VM.

We tend to believe that this is the major innovation of Java, but actually the concept of virtual machines is very old. Lisp, UCSD-Pascal, Eumel/Elan, the Perl programming language and many other systems have used this concept long before Java. The Java guys have been good in selling this and it was possible to get this really to the mainstream when Java came out. The Java guys deserve the credit for bringing this in the right time and bringing it to the main stream.

Earlier implementations where kind of cool, but the virtual machine technology and the hardware were to slow, so that they were not really attractive, at least not for high performance applications, which are now actually a domain of Java and other JVM languages. Some suggest that Java or other efficient JVM languages like Scala would run even faster than C++. While it may be true to show this in examples, and the hotspot optimization gives some theoretical evidence how optimization that takes place during run time can be better than static optimization at compile time, I do not generally trust this. I doubt that well written C-code for an application that is adequate for both C and Java will be outperformed by Java. But we have to take two more aspects into account, which tend to be considered kind of unlimited for many such comparisons to make them possible at all.

The JVM has two weaknesses in terms of performance. The start-up time is relatively long. This is addressed in those comparisons, because the claim to be fast is only maintained for long running server applications, where start-up time is not relevant. The hotspot optimization requires anyway a long running application in order to show its advantages. Another aspect that is very relevant is that Java uses a lot of memory. I do not really know why, because more high level languages like Perl or Ruby get along with less memory, but experience shows that this is true. So if we have a budget X to buy hardware and then put software written in C on it, we can just afford to buy more CPUs because we save on the memory or we can make use of the memory that the JVM would otherwise just use up to make our application faster. When we view the achievable performance with a given hardware budget, I am quite sure that well written C outperforms well written Java.

The other aspect is in favor of Java. We have implicitly assumed until now that the budget for development is unlimited. In practice that is not the case. While we fight with interesting, but time consuming low level issues in C, we already get work done in Java. A useful application in Java is usually finished faster than in C, again if it is in a domain that can reasonably be addressed with either of the two languages and if we do not get lost in the framework world. So if the Java application is good enough in terms of performance, which it often is, even for very performance critical applications, then we might be better off using Java instead of C to get the job done faster and to have time for optimization, documentation, testing, unit testing.. Yes, I am in a perfect world now, but we should always aim for that. You could argue that the same argument is valid in terms of using a more high-level language than Java, like Ruby, Perl, Perl 6, Clojure, Scala, F#,… I’ll leave this argument to other articles in the future and in the past.

What Java has really been good at is bringing the VM technology to a level that allows real world high performance server application and bringing it to the main stream.
That is already a great achievement. Interestingly there have never been serious and successful efforts to actually build the JavaVM as hardware CPU and put that as a co-processor into common PCs or servers. It would have been an issue with the upgrade to Java8, because that was an incompatible change, but other than that the JavaVM remained pretty stable. As we see the hotspot optimization is now so good that the urge for such a hardware is not so strong.

Now the JVM has been built around the Java language, which was quite legitimate, because that was the only goal in the beginning. It is even started using the command line tool java (or sometimes javaw on MS-Windows 32/64 systems). The success of Java made the JVM wide spread and efficient, so it became attractive to run other languages on it. There are more than 100 languages on the JVM. Most of them are not very relevant. A couple of them are part of the Java world, because they are or used to be specific micro languages closely related to java to achieve certain goals in the JEE-world, like the now almost obsolete JSP, JavaFX, .

Relevant languages are Scala, Clojure, JRuby, Groovy and JavaScript. I am not sure about Jython, Ceylon and Kotlin. There are interesting ideas coming up here and there like running Haskell under the name Frege on the JVM. And I would love to see a language that just adds operator overloading and provides some preprocessor to achieve this by translating for example „(+)“ in infix syntax to „.add(..)“ mainstream, to allow seriously using numeric types in Java.

Now Perl 6 started its development around 2000. They were at that time assuming that the JVM is not a good target for a dynamic language to achieve good performance. So they started developing Parrot as their own VM. The goal was to share Parrot between many dynamic languages like Ruby, Python, Scheme and Perl 6, which would have allowed inter-language inter-operation to be more easily achievable and using libraries from one of these languages in one of the others. I would not have been trivial, because I am quite sure that we would have come across issues that each language has another set of basic types, so strings and numbers would have to be converted to the strings and numbers of the library language when calling, but it would have been interesting.

In the end parrot was a very interesting project, theoretically very sound and it looked like for example the Ruby guys went for it even faster than the the Perl guys, resulting in an implementation called cardinal. But the relevant Perl 6 implementation, rakudo, eventually went for their own VM, Moar. Ruby also did itself a new better VM- Many other language, including Ruby and JavaScript also went for the JVM, at least as one implementation variant. Eventually the JVM proved to be successful even in this area. The argument to start parrot in the first place was that the JVM is not good for dynamic languages. I believe that this was true around 2000. But the JVM has vastly improved since then, even resulting in Java being a serious alternative to C for many high performance server applications. And it has been improved for dynamic languages, mostly by adding the „invoke_dynamic“-feature, that also proved to be useful for implementing Java 8 lambdas. The experience in transforming and executing dynamic languages to the JVM has grown. So in the end parrot has become kind of obsolete and seems to be maintained, but hardly used for any mainstream projects. In the end we have Perl 6 now and Parrot was an important stepping stone on this path, even if it becomes obsolete. The question of interoperability between different scripting languages remains interesting…

Share Button



Das Konzept der Rundung kennt man grundsätzlich. Aber versuchen wir es etwas systematischer zu erfassen.

Man hat eine Menge M von Zahlen und eine Teilmenge N \subseteq M davon, deren Elemente in der verwendeten Programmierumgebung dargestellt werden. Dazu hat man noch eine Metrik d : M \times M \rightarrow \Bbb R_+, (x, y) \mapsto r=d(x,y)>=0. Man verlangt normalerweise noch gewisse Eigenschaften von d:

  • Positive Definitheit: d(x,y) = 0 \iff x = y
  • Symmetrie: d(x,y)=d(y,x)
  • Dreiecksungleichung: d(x,z) \le d(x,y) + d(y,z)

Typischerweise sind die Zahlen, mit denen wir uns meistens beschäftigen, in der Welt der reellen und komplexen Zahlen gedacht, man kann also fast immer sicher sein, dass M \subseteq \Bbb C ist, meistens sogar M \subseteq \Bbb R oder wenn wir ehrlich sind sogar M \subseteq \Bbb Q. Dann ist normalerweise d(x,y) = |x-y|. Wer die komplexen Zahlen noch nicht kennt, denke einfach an reelle und rationale Zahlen, das ist das, womit wir normalerweise bewusst zu tun haben. Dabei sind natürlich Konzepte wie Rundung speziell in p-adischen Zahlen hochinteressant, aber dafür muss ich die erstmal erklären und das lasse ich heute…

Was stellen wir uns nun unter einer Rundung vor?
Vielleicht eine Abbildung
r: M \rightarrow N, x \mapsto r(x),
die mit gewissen Nebenbedingungen für jedes x jeweils so gewählt wird, dass d(x, r(x)) minimal ist.
Die Nebenbedingungen brauchen wir einerseits, um es eindeutig zu machen, wenn mehrere Werte y\in N existieren, für die d(x,y) minimal ist. Der klassische Fall ist das Runden auf ganzzahlige Werte und die Frage mit der 0.5. Wenn N eine Teilmenge der reellen Zahlen ist, was ja „meistens“ der Fall ist, hat man eine Anordung. Da kommen dann die folgenden Constraints zum Tragen (Beispiel immer mit Rundung auf ganze Zahlen):

|r(x)|\ge |x| Z.B. r(0.4)=1 und r(0.5)=1 und r(-0.5)=-1
|r(x)|\le |x| Z.B. r(0.6)=0 und r(0.5)=0 und r(-0.5)=0
r(x) \ge x Z.B. r(0.4)=1 und r(0.5)=1 und r(-0.5)=0
r(x) \le x Z.B. r(0.6)=0 und r(0.5)=0 und r(-0.5)=-1
Minimiere d(r(x),x), aber wenn es mehrere optimale Werte für r(x) gibt, wähle den am weitesten von 0 entfernten, z.B. r(0.4)=0 und r(0.6)=1 und r(0.5)=1 und r(-0.5)=-1
Minimiere d(r(x),x), aber wenn es mehrere optimale Werte für r(x) gibt, wähle den am nächsten an 0, z.B. r(0.4)=0 und r(0.6)=1 und r(0.5)=0 und r(-0.5)=0
Minimiere d(r(x),x), aber wenn es mehrere optimale Werte für r(x) gibt, wähle den größten, z.B. r(0.4)=0 und r(0.6)=1 und r(0.5)=1 und r(-0.5)=0
Minimiere d(r(x),x), aber wenn es mehrere optimale Werte für r(x) gibt, wähle den kleinesten, z.B. r(0.4)=0 und r(0.6)=1 und r(0.5)=0 und r(-0.5)=-1
Minimiere d(r(x),x), aber wenn es mehrere optimale Werte für r(x) gibt, wähle den mit gerader Endziffer. Achtung, dieser Constraint ist im „klassischen“ Fall anwendbar, aber nicht allgemeingültig. Z.B.: r(0.4)=0 und r(0.6)=1 und r(0.5)=0 und r(-0.5)=0 und (1.5)=2
Dieser Constraint ist im mathematischen Sinne nicht geeignet (oder nur mit hässlichen Verrenkungen), aber programmatisch können wir das: Wir nehmen r(x)=x und schmeißen eine Exception wenn nicht x\in N schon gilt.

Typischerweise denken wir im Dezimalsystem und dann wählen wir eine Zehnerpotenz 10^n mit n \in \Bbb N, also n \ge 0. Nun ist einfach
N = \{ x \in M : 10^n x \in \Bbb Z\},
also umgangsprachlich sind in N alle Zahlen aus M mit maximal n Stellen nach dem Komma. Diese Rundung funktioniert ganz gut mit so etwas wie LongDecimal in Ruby oder BigDecimal in Scala oder Java, wobei BigDecimal weniger Rundungsmodi anbietet als LongDecimal für Ruby.

Nun kommen wir zur Restklassenrundung. Wir gehen wieder von dieser Zehnerpotenz 10^n aus. Dann brauchen wir noch eine natürlich Zahl m \ge 2 und eine Menge von Resten R \subseteq \{0,...,m-1\}. Nun ist
N = \{ x \in M : 10^n x \in {\Bbb Z} \wedge \bigvee_{r \in R} 10^n x \equiv r \mod{m}\}.
Das bedeutet, wenn wir mit Nullen auf die angegebene Anzahl von Nachkommastellen auffüllen, das „Komma“ (normalerweise als „.“ geschrieben) weglassen und dann diese Zahl mit Rest durch m teilen, der dabei herauskommende Rest in R liegt.
In diesem Fall wird es mit dem ROUND_HALF_EVEN eventuell schwierig, da es undefiniert oder mehrdeutig werden kann. Aber wir müssen auch den Fall abdecken, dass die 0 nicht in R ist und Regeln angeben, wohin die 0 gerundet werden soll. Die Kandidaten sind hier mit selbsterklärenden Namen versehen:


Ein wichtiger Anwendungsfall ist hier m=10 und R=\{0, 5\}. So kann man in der Schweiz Geldbeträge auf Vielfache von 5 Rappen (0.05 CHF) runden. Dies wurde in Rundung bei Geldbeträgen bereits genauer beschrieben.

Share Button

Devoxx 2014

Im Jahr 2014 habe ich die Devoxx in Antwerpen besucht.

Hier sind ein paar Notizen dazu:

Was ist Devoxx?

  • Devoxx ist eine Konferenz der belgischen Java-User-Group
  • Belgien ist dreisprachig, Konferenz aber 100% in Englisch
  • Lokation in riesigem Kinokomplex guter Sound, gute Sitze, gute Projektoren, „cool“
  • 8 tracks, bei Keynotes „overflow“
  • Gut organisiert (dies Jahr sicher), unterhaltsamer als andere Konferenzen…
  • Schwesterkonferenzen:
  • Devoxx FR
  • Devoxx PL
  • Devoxx UK
  • Voxxed (Berlin, Ticino,….)

Themen & Hauptsponsoren

  • Java / Oracle
  • Android / Oracle
  • Startups, Business, IT in Großfirmen / ING-Bank
  • Java-Server, JBoss, Deployment / Redhat
  • JVM-Sprachen
  • Web
  • SW-Architektur
  • Security
  • Was sonst noch so ins Umfeld passt und sich jemand traut, vorzutragen…

Scala und Java8

  • Viele Features von Scala sind mit java8-Lambdas auch in Java verfügbar
  • Problem: verschiedene Implementierung, Interoperabilität
  • Bestrebung Scala weiterzuentwickeln damit lambdas von Java und von Scala besser miteinander interoperabel sind.


  • Konzept aus der Kategorientheorie (5% der Mathematiker machen Algebra, 5% der Algebraiker machen Kategorientheorie, aber für funktionale Programmiersprachen plötzlich relevant)
  • Monoid (+, *, concat,…)
  • Funktor
  • Monad (de: Monade)
    Wikipedia de
    Wikipedia en
  • (T, \eta, \mu)
  • Beispiel List mit einem Functor F: (A\rightarrow B)\rightarrow (List[A]\rightarrow List[B])
    \mu ist flatten: List[List[A]]\rightarrow List[A]; \eta: A\rightarrow List[A]

Probability & Decisions

  • Thema: Software für automatische Steuerung
  • Heuristik auf Wahrscheinlichkeitstheorie
  • False positives / false negatives: was tut weh? (meistens beide…)
  • Wahrscheinlichkeitstheorie und Verwendung gut erklärt


  • Clojure ist eine andere JVM-Sprache
  • Ein Lisp-Dialekt, zu erkennen daran, dass der Quelltext überwiegend aus runden Klammern besteht (+ (* 3 4) (* 5 6))…
  • Funktionales Paradigma stark unterstützt
  • Dynamische Typisierung (für uns: Alles als „Object“ deklariert, implizite Casts bei Methodenaufrufen)
  • Nach Java selbst, Scala, Groovy und Javascript die mir am fünfthäufigsten begegnende JVM-Sprache


  • „No one at Google uses MapReduce anymore“
  • Google hat das verallgemeinert
  • Optimierungen: spare Schritte, fasse zusammen etc.
  • Als Cloud-Service angeboten (Cloud Dataflow)

Key Note ING

  • ING versteht sich als „open bank“
  • Nicht gemeint, dass das Geld „offen“ rumliegt, aber offen für neue Ideen
  • Schnittstelle zur Bank ist Mobile-App
  • IT hat viel Einfluss („IT driven business“)
  • Man schaut, was gut machbar ist
  • Agile Prozesse (Scrum) vs. Enterprise IT
  • Umbau der IT auf diese agilen Prozesse schrittweise
  • „Enterprise IT is what does not work“

Material Design

  • Vortrag über GUI-Design mit Android und Web
    Material Design
  • Visuelle Ideen für beide Plattformen verfügbar
  • Polymerdesign für Web

SW-Architektur mit Spring

  • Spring 4.1
  • „works with WebSphere“
  • DRY
  • Lambda aus Java8 kann viele APIs vereinfachen statt anonymen inneren Klassen mit einer Methode
  • Generic Messaging Interface (war JMS nicht schon das???)
  • Caching, Achtung beim Testen abschaltbar
  • Testen auf
  • Spring funktioniert mit Java gut, mit Groovy auch (aus demselben Haus…) mit Scala „experimentell“


  • High-Level testing-Framework
  • Verwendet Java8-Features (Lambda etc)
  • Beschreibung in natürlicher Sprache
  • Failure-Meldungen lesbar
  • Wie Cucumber…
  • Zufallsquelle konfigurierbar (extrem wichtig für manche Tests!!)

Builtin Types of Scala and Java

  • In Java gibt es „primitive“ (long, int, byte, char, short, double,…)
  • Probleme bei Arithmetik mit int, long & Co:  Überlauf findet unerkannt statt
  • Mit float und double Rundungsfehler
  • Mit BigInteger, BigDecimal, Complex, Rational fehleranfällige, umständliche und unlesbare Syntax
  • In Scala kann man a=b*c+d*e auch für neu definierte numerische Typen schreiben.
  • Anmerkung dazu: Oracle-Java-Leute finden Idee von Operator-Überladen für numerische Typen inzwischen interessant, solange man nicht Exceptions mit Collections multipliziert und durch Swing-Komponenten dividiert…
  • Spire library

Zukunft von Java (9, 10, …)

Teil I

  • Q&A-Sitzung (Fragen per Twitter schreiben)
  • Numerische Typen sind Thema. Dass primitive Typen sich so verhalten wie heute und quasi der „default“ sind, wird sich nicht ändern
  • Thema Generics und Type-Erasure (wo ist das Problem)?
  • Jigsaw vs. Jars vs. OSGi  noch offen, aber jar bleibt
  • Jigsaw-Repository  Wird man wohl bei maven-Central, Oracle funktioniert nicht so, dass sie jigsaw-Repository für third-Party bei sich hosten

Teil II

  • Benchmarking mit Java schwierig wegen hotspot-Optimierung
  • JMH gutes Tool dafür
  • Neue Ideen immer schwierig umzusetzen, weil man kompatibel zu alten Versionen sein will.
  • Java bekommt vielleicht „repl“

Teil III

  • Collection literals (für Java 7 versprochen!!!) sind für Java8 nicht gekommen, für Java9 unwahrscheinlich
  • Mit Value-Types aber eher zu haben, daher nicht vorher…
  • Für Set und List mittels
    new TreeSet(Arrays.asList(m1, m2, m3,…., mn))
    schon heute einigermaßen darstellbar
  • Für Maps wenn man sowas wie Pair-hätte, was wiederum auf „Tupel“ aufbaut, die kommen werden, wenn es Value-Types gibt

Teil IV

  • Tail-Recursion kann nun optimiert werden
  • Wegen Security-Manager, der Stacktrace analysiert hat, lange nicht möglich
  • C und Lisp können das seit Jahrzehnten…
  • Aussage: Generics sind schwierig, aber wenn man sie mal verstanden hat, sind sie leicht… Also „dranbleiben“
  • Covarianz und Contravarianz (Bei Array falsch gelöst)

Teil V

  • Arrays 2.0: Indizierung mit long möglich, ein bißchen wie List, aber mit Array-Syntax… (Studien und Papers, nicht konkret)
  • Listen haben heute extrem-Implementierung ArrayList und LinkedList. Wir wollen „sophisticated“ List vielleicht Hybrid
  • Checked-Exceptions: kritisches Thema, schwierig mit Generics und mit Lambda. Zu viele Exceptions sind checked. Z.B. bei close()

Semantische Quelltextanalyse

  • Hilfreich für High-Level-Testing-Tools
  • Statische und dynamische Analyse
  • Dataflow-Analyse: ungeprüfte Daten von außen  SQL-injection, aber auch CSS, HTML, JavaScript, JVM-Sprachen/Bytecode

Funktionale Ideen in Java

  • Funktional:
  • Funktionen oder Methoden sind „first class citizen“
  • Higher order Functions (konnte schon C)
  • Closure
  • Immutability (Funktion gibt immer dasselbe raus)
  • Unter der Tischdecke „lazy“-Konstrukte
  • Bei großen Strukturen immer Frage: Immutability vs. Performance
  • Aber Funktional ist Thread-freundlicher

50 new things in Java8

Teil I

  • Lambda (s.u.)
  • Streams (s.u.)
  • Default-Implementierungen in Interfaces
  • Date/Time (wie Joda-Time)
  • Optional (besser als null)
  • Libraries können mit Lambda arbeiten
  • Parallel (mit Vorsicht verwenden)

Teil II

  • String.join()
  • So was wie „find“ in Unix/Linux
  • Comparator schreiben einfacher
  • Maps of Maps, Maps of Collections einfacher
  • Sortieren besser: quicksort statt mergesort, parallelisierbar

Groovy für Android

  • Problem bei JVM-Sprachen außer Java: Bibliothek muss in jeder App mitkommen
  • Lösung: Tool zum jar-optimieren
  • Zweites Problem: dynamische Sprachen müssen auf Device „on demand“ kompiliert werden
  • Lösung: „statisch“ Programmieren, dynamische Features möglich, aber nicht performant


  • Lambdas sind anonyme Funktionen
  • Idee gegeben: Interface XY mit einer Methode uvw()
  • Statt
    XY xy = new XY() {
    public long uvw(long x) { return x*x }
    XY xy = x -> x*x;
  • kürzer, lesbarer, wartbarer, man kann Interface oft sparen
  • Closure bedeutet, dass (final-)Variablen aus dem umgebenden Kontext dort eingebunden werden
  • Instanz-Methoden sind eigentlich auch Closure, sie binden die Instanz in der sie definiert sind Closure-mäßig ein.


  • Streams sind im Dunstkreis von Collection, Iterable, Iterator, aber was anderes
  • Erlauben Methoden, die „Funktion“ auf alle Elemente loslassen
  • Elegant programmierbar sind Dinge wie
    • Summe
    • Produkt
    • Maximum
    • Erstes / Letztes Elment mit Eigenschaft
    • alle mit Eigenschaft
    • alle transformierten Elemente
  • Sinnvoll: nicht dasselbe wie Iterable, Iterator, Collection,…


Share Button

Memory bei Java-Zeichenketten

Es hat von Java 1.6 nach Java 1.7 eine für den Memoryverbrauch relevante Änderung gegeben.
Bis Java 1.6 wurde bei substring eine Zeichenkette konstruiert, die das selbe interne Array von Zeichen (char) referenziert und nur andere Werte für Anfang und Länge enthält. Das hatte den Vorteil, dass in vielen Fällen Memory gespart wurde, weil man die Teilzeichenkette nicht nochmal speichern musste. Auch das Umkopieren wurde gespart. Nun war es aber wichtig, in manchen Fällen so etwas wie
String mySubString = new String(origString.substring(3, 5));
String mySubString = origString.substring(3, 5);
zu verwenden, wenn nämlich origString sehr viel länger als mySubString war und sehr viel früher obsolet wurde als mySubString. Wer das vergessen hat, hat so ein Memoryleak gebaut.
Das wurde in Java 1.7 „gefixt“, nun wird das Array mit den Zeichen intern immer kopiert, weil die Entwickler nicht verstanden haben, mit diesen beiden Möglichkeiten richtig umzugehen. Leider hat man nun aber die andere Möglichkeit nicht mehr zur Verfügung.
Was kann man tun, wenn man eine Memory-intensive Applikation schreiben will, in der viele langlebige Zeichenketten vorkommen, die Teil einer längeren, ebenfalls langlebigen Zeichenkette sind?
Die erste Frage ist immer, ob man mit der neue Implementierung nicht doch leben kann.
Da die Zeichenkette sehr tief in Java verankert ist, kann man sie nicht so leicht ersetzen bzw. muss etwas hässlicheren Code schreiben, um explizit die eigene Zeichenkette zu verwenden. Wenn nötig ist das aber machbar: Man nimmt von gnuClasspath java.lang.String und refactored das zu einem anderen Package- und Klassennamen. Daraus lässt sich dann leicht das gewünschte bauen. Wichtig sind Konversionsroutinen nach java.lang.String in beide Richtungen.


Share Button

Getter und Setter

In der objektorientierten Programmierung gilt es als fortschrittlich, getter und setter zu verwenden, statt auf Attribute direkt zuzugreifen, weil das einem die Flexibilität gibt, später auf berechnete Attribute umzuschwenken. Etwas hässlich ist das, weil die getter und setter, etwas willkürlich den Attributnamen mit so einem vorangestellten „get“ oder „is“ oder „set“ und eventueller Umwandlung der Groß- und Kleinschreibung einzelner Zeichen versehen. Eine subtile Besonderheit ist, dass es verwirrend wird, wenn Attributnamen mit „get“, „is“ oder „set“ beginnen. Gerade Boolean-Attribute ist man versucht mit „hasSomething“, „isSomething“, „doesSomething“, „canSomething“, „mustSomething“,… o.ä. zu benennen, was dann zu dem Getter „getIsSomething()“ oder „isIsSomething()“ führt. Oder man lässt in dem Fall das Präfix weg, aber nur beim Getter…

Schöner ist es, wenn man Getter und Setter natürlich bennen kann, wie das z.B. in C#, Ruby und Scala der Fall ist: Man schreibt den Getter so, als würde man das Attribut public machen und darauf zugreifen, aber hat durch die entsprechenden Sprachkonstrukte die Möglichkeit, die Getter und Setter durch andere Implementierungen zu ersetzen, wenn der Bedarf besteht. Es gibt sicher wichtigeres, aber das ist zumindest schöner, lesbarer und deshalb weniger fehleranfällig. Und sprachlich auch sauberer als diese „halb-magic“-Bedeutung von „get…“, „set…“ und „is…“.

Im Grunde genommen sind aber auch Zugriffe auf Listen und Maps oft eine Art Getter und Setter:
y=a.get(pos) könnte man auch als y=a[pos] schreiben wollen, entsprechend a.put(pos, x) auch als a[pos]=x. Dasselbe gilt für Maps mit u=m.get(k), was schöner und intuitiver als etwas in der Art von u=m[k] wäre. Oder statt m.put(k, v) so etwas wie m[k]=v. Aus genügend abstrakter Sicht ist das nicht so wichtig, aber wenn die Lesbarkeit sich verbessert, macht man weniger Fehler und so hat man pragmatisch gesehen einen kleinen Qualitäts und Effizienzgewinn mit der Zuweisungsschreibweise.

Nun sind aber Setter in Wirklichkeit oft problematisch. Es ist immer gut, Objekte immutable zu haben, weil man sie dann problemloser zwischen Threads herumreichen kann, ohne dass es zu Fehler bei gleichzeitigen Zugriffen kommen kann. Nun stellt sich aber die Frage, wie man dann das Objekt konstruieren soll. Ein Konstruktor mit positionalen Parametern ist zwar möglich, aber oft nicht sehr lesbar, wenn die Parameterliste nicht völlig überschaubar und klar ist. So etwas wie benannte Parameter könnte sehr viel helfen. Ein anderes Muster ist es, ein temporäres Objekt mit Settern aufzubauen und dann daraus das eigenteliche unveränderliche (immutable) Objekt zu generieren. Man kann dafür spezielle Setter nehmen, die jeweils das veränderte Objekt zurückgeben und das etwa so etwas schreiben wie
SomethingImmutable s = new SomethingTemp().setX(x).setY(y).setZ(z).toSomething(),
was nicht superschön ist, aber wenn man auf Java Wert legt, doch eine Möglichkeit.

Hier zeigt sich auch, warum es so schön ist, wenn man Listen und Maps und vielleicht andere Collections einfach mit allen Elementen konstruieren und dann gleich immutable machen kann. In Java geht das für Listen immerhin schon mit
Collections.immutableList(Arrays.asList(a, b, c, d, e, f, g, h))
machen. Wobei diese Konstruktion relativ neu ist und wegen der Konstruktionsphase Collections nicht defaultmäßig immutable sein können. Immerhin könnte man ein
definieren. Oder eine Methode auf List
Schöner (klarer, lesbarer, weniger fehleranfällig) wäre es aber, wenn man das als
[a, b, c, d, e, f, g, h]
schreiben könnte. Für die Ausgabe von Listen mittels toString() wird so etwas ja schon verstanden. Für das Konstruieren von Maps gibt es in anderen Programmiersprachen auch Schreibweisen, die etwa so aussehen wie
m = { k1 => v1, k2 => v2, k3 => v3, k4 => v4}.
Will man sich normalerweise dafür interessieren, welche Map-Implementierung jetzt genommen wird? So etwas ließe sich als
m = new TreeMap{k1 => v1, k2 => v2, k3 => v3, k4 => v4}
schreiben. Solche Dinge waren für Java 8 vorgesehen, sind aber wohl in letzter Minute rausgeflogen oder auf Java 9 verschoben worden.

Share Button

Java 8

Java 8 ist erschienen.
Das bedeutendste neue Feature sind die Lambda-Expressions, die es unter anderem erleichtern, funktional zu programmieren.

Share Button

Widersprüchliche Dependencies

Wenn man größere Applikationen entwickelt kommt man irgendwann einmal an den Punkt, wo verschiedene Libraries, die man gerne verwenden möchte, ihrerseits von anderen Libraries abhängen. Da kommt dann auch schonmal dieselbe Library mehrfach vor, nur leider mit unterschiedlichen Versionen. Man probiert dann immer gerne, ob es nicht eine Version gibt, mit der beide funktionieren und manchmal hat man Glück, bis dann eine dritte kommt. Im Prinzip ist es möglich, auch so etwas zu lösen, aber es ist schon konzeptionell nicht so einfach und in der Praxis auch etwas mühsam, wenn es überhaupt gelingt. Zum Glück ist es in vielen Fällen möglich, einfach die neueste der verlangten Versionen zu nehmen, aber manchmal geht das nicht, sei es, weil die Version wirklich überprüft wird und eine bestimmte verlangt wird oder sei es, weil diese beiden Versionen wirklich an einer Stelle inkompatibel sind, die dummerweise noch verwendet wird.

In Java gibt es dafür einen Ansatz, eigene ClassLoader zu verwenden. Hier ein kleines Beispiel, in dem eine Klasse X drei Objekte aus verschiedene Klassen Y instanziiert. Diese Klassen Y sind alle im selben Package, aber in verschiedenen Jars.



public class X {
    public static void main(String args[]) {
        try {
            ClassLoader c0 = Thread.currentThread().getContextClassLoader();

            URL cpa = new URL("file:///home/bk1/src/class-loader/A/A.jar");
            URL cpb = new URL("file:///home/bk1/src/class-loader/B/B.jar");
            URL cpc = new URL("file:///home/bk1/src/class-loader/C/C.jar");
            ClassLoader ca = new URLClassLoader(new URL[]{ cpa }, c0);
            ClassLoader cb = new URLClassLoader(new URL[]{ cpb }, c0);        
            ClassLoader cc = new URLClassLoader(new URL[]{ cpc }, c0);
            Object a = ca.loadClass("Y").newInstance();
            System.out.println("a=" + a + " a.class=" + a.getClass());
            Object b = cb.loadClass("Y").newInstance();
            System.out.println("b=" + b + " b.class=" + b.getClass());
            Object c = cc.loadClass("Y").newInstance();
            System.out.println("c=" + c + " c.class=" + c.getClass());
        } catch (Exception ex) {
            throw new RuntimeException(ex);

2. A/

public class Y {
    public String toString() {
        return "Feuer";

Dies landed kompiliert in A.jar

3. B/

public class Y {
    public String toString() {
        return "Wasser";

Dies landed kompiliert in B.jar

4. C/

public class Y {
    public String toString() {
        return "Erde";

Dies landed kompiliert in C.jar

Und das ist die Ausgabe:

a=Feuer a.class=class Y
b=Wasser b.class=class Y
c=Erde c.class=class Y

Natürlich sollte man dies bevörzugt Frameworks überlassen, statt es selber zu programmieren. Aber grundsätzlich ist das Problem durchaus lösbar.

Share Button

Datenbanken und unveränderliche Objekte


Ein beliebter Ansatz in der funktionalen Programmierung, aber auch teilweise in der objektorientierten Programmierung ist es, Objekte nach Möglichkeit unveränderlich (engl. „immutable“) zu machen.

Speziell für Applikationen mit Multithreading ist das sehr nützlich, aber grundsätzlich erleichtert es auch im Griff zu haben, wie der Informationsfluss ist und unerwartete Seiteneffekte zu verhindern. Ich will das hier nicht als Dogma postulieren, denn es gibt durchaus legitime Verwendungen von veränderlichen Objekten, aber man sollte sich auf jeden Fall bewusst sein, was das bedeutet und ob sich die Veränderbarkeit (engl. „mutability“) in dem Fall überhaupt lohnt.

Unterscheiden muss man noch die echt unveränderlichen Objekte und diejenigen, die nur durch einen Wrapper oder ein zweites Interface unveränderlich weitergegeben werden, obwohl es noch für einen Teil des Codes Zugriff auf ein Interface gibt, das Veränderungen zulässt. Der typische Fall sind zum Beispiel Collections in Java, die in einem Objekt leben und mit Methoden dieses Objekts verändert werden können, aber die nur als immutable gewrappt herausgegeben werden.


import java.util.*;

public class A {
    List l = new ArrayList();
    public void addStr(String s) {

    public List getList() {
        return Collections.unmodifiableList(l);

Obwohl also die mit getList() herausgegebenen Liste selbst immutable ist, kann sie mittels add aus A noch verändert werden.

Interessant wird es aber nun, wenn man eine Datenbank ins Spiel bringt.
Datenbank-Inhalte werden in irgendeiner Weise auf Objekte abgebildet. Ob das nun mit Automatismen passiert oder explizit mit Mechanismen wie JDBC, DBI o.ä. und ob es spezifische Objekte oder generische universelle DB-Content-Objekte oder Collections sind, spielt keine so große Rolle, es gibt solche Objekte oder Datenstrukturen.

Nun können sich Datenbankinhalte ändern. Das kann durch die Software, auf die wir uns hier beziehen, selbst passieren, aber auch von außen. Allein das ist schon eine gewisse Komplikation, wenn man es genau anschaut. Die Objekte, mit denen sich die Software befasst, sind dann nämlich schon veraltet. Das kann so akzeptabel sein, wenn man darauf verzichtet, auf Software- oder Frameworkebene ein Caching von solchen Objekten aufzubauen und das Caching allein der Datenbank überlässt, die das im Gegensatz zu Frameworks oder anderer Software, die die Datenbank nur nutzt, problemlos transaktionskonform kann. Schön ist es dann natürlich wieder, wenn die DB netzwerkmäßig nicht zu weit von der Applikation weg ist, sonst ist der Cache leider auf der falschen Seite der Netzwerkverbindung…

Wenn also in der Software die Objekte so kurzlebig sind, dass man ausschließen kann, dass sie veralten, dann kann man sagen, dass sie hinreichend mit dem Stand in der Datenbank übereinstimmen. Mit Transaktionsisolation „serializable“ oder „phantom-read“ und dann innerhalb von einer Transaktion sind diese Objekte, die man in derselben Transaktion gelesen hat, garantiert noch aktuell. Wenn nicht bestimmte OR-mapping-Muster für Collections vorkommen, ist das schon bei „repeatable-read“ der Fall. Man lebt also gut mit „immutable“-Objekten, solange diese nur aus der Datenbank gelesen (SELECT oder READ) werden. Auch das Löschen (DELETE) kann man sich noch vorstellen, aber in diesem Fall muss man schon darauf achten, dass das betreffende Objekt nicht noch an zu vielen Stellen der Software in Gebrauch ist, obwohl es in der Datenbank schon gelöscht ist. Wenn man aber sowieso sicherstellt, dass diese Objekte, die Datenbankinhalte darstellen, nicht länger leben als die entsprechenden Transaktionen, dann sollte auch das handhabbar sein. Auch das Erzeugen neuer Objekte und das Anlegen der entsprechenden Daten in der Datenbank (INSERT oder CREATE) ist möglich.

Schwierig wird es aber mit dem Ändern von Daten in der Datenbank (UPDATE). Bei gängigen OR-Mappings funktioniert das so, dass man das entsprechende vorher gelesen Objekt ändert und dann speichert, in der Hoffnung, dass das Framework die Unterschiede herausfindet und ein entsprechendes Update, eventuell auch eine Kombination aus Updates, Inserts und Deletes initiiert. Das wird mit unveränderbaren (immutable) Objekten schwierig. Man kann auch da Wege finden, aber das geht dann leicht auf Kosten der Eleganz des Frameworks und man hat sich auf jeden Fall damit auseinanderzusetzen, dass die Objekte jetzt auch innerhalb der Transaktion veralten und durch solche mit den aktualisierten Inhalten ersetzt werden müssen.

Die provokante Frage ist, ob man das Update überhaupt braucht. Natürlich braucht man das, aber auch hier kann man genauer schauen, welches die Fälle sind, wo das wirklich so ist und wann andere Ansätze besser sind.
Ein klassisches Beispiel ist eine Software, die irgendwelche Buchungen und irgendwelche Personen verwaltet. Das kann eine Bankensoftware sein, wo man Konten hat. Oder ein Billingsystem einer Telefongesellschaft, wo man die Rechnungen für Kunden generiert und verwaltet. Man hat dort oft so eine Buchungstabelle, in der grundsätzlich nur Datensätze eingefügt werden und niemals Daten gelöscht oder verändert werden, wenn wir einmal Fragen der Archivierung sehr alter Daten ausklammern. Dazu hätte man gerne noch einen Kontostand. Den kann man strenggenommen immer berechnen, indem man einfach alle Buchungen für das Konto aufaddiert. Leider ist die Software dann nachher langsam und für keinerlei praktische Zwecke brauchbar, aber theoretisch sehr schön. Man braucht also schon einen effizienten Mechanismus, um Kontostände zu ermitteln. Vielleicht kann jede Buchung den aus ihr resultierenden Kontostand beinhalten und man muss nur nach der neuesten Buchung suchen. Das ist gefährlich, weil zwei etwa gleichzeitig erzeugte Buchungen sich auf denselben Vorgängerkontostand beziehen. Mit Transaction-Isolation „serializable“ wäre das nicht passiert, aber das bremst natürlich die Datenbank schon sehr aus, ausgerechnet bei der größten Tabelle, in der die ganze Arbeit läuft und wo es sowieso schon den Performance-Flaschenhals gibt. Man kann auch auf Datenbankebene eine Lösung implementieren, etwa mit Triggern oder Materialized Views, wo jedes Insert in der Buchungstabelle ein Update des entsprechenden Kontostands bewirkt. Das hat den Vorteil, dass beliebige DB-Zugriffe von beliebiger Software richtig verarbeitet werden, solange man in der betreffenden Buchungstabelle Delete- und Update-Zugriffe unterbindet. Der Nachteil ist aber, dass die Businesslogik sich jetzt auf die Datenbank und die Applikation verteilt. Das kann man akzeptieren, wenn man das als eine Art abstrakten Constraint ansieht, der von der Datenbank „aktiv“ eingehalten wird. Oder man kann es vermeiden, indem man auf Applikationsebene eine entsprechend Funktionalität zum Einfügen einer Buchung einführt, die den Kontostand anpasst. Wiederum wird das zu falschen Ergebnissen führen, wenn man erlaubt, dass eine zweite Buchung für dasselbe Konto eingefügt wird, während schon eine Transaktion für das Einfügen einer Buchung für das Konto läuft. Man sieht also, dass die richtige Lösung dieser Buchungstabelle nicht einfach ist. Wenn dann noch hinzukommt, dass die Buchungen wiederum zu Transaktionen gruppiert sind, also z.B. die Gutschrift auf einem Konto in derselben Transaktion wie die Abbuchung von einem anderen Konto laufen soll, dann wird es schon interessant, wie man das System so baut, dass es absolut zuverlässig und korrekt ist, auch unter Last, und doch auch performant ist. Und in der Applikation muss man nun mit Konto-Objekten, die den Kontostand enthalten, sehr vorsichtig sein, weil dieser Kontostand veraltet, sobald eine Buchung dazukommt.

Die Tabelle oder die Tabellen mit den Personen, Adressen werden gerne mit Updates aktualisiert, wenn sich Daten ändern. Leute heiraten, ändern die Telefonnummer oder ziehen um. Aber ist das wirklich der richtige Weg? In Wirklichkeit weiß man von dem Umzug schon etwas vorher und hat vielleicht am Umzugstag selbst keine Zeit, das zu erfassen. Und in Wirklichkeit muss das System auch Fragen beantworten können, wie den Namen und die Adresse des Kunden zu der Zeit, als Buchung 23571113a stattfand. Vielleicht kann man Adressänderungen auch als „Buchungen“ speichern, mit einem Gültigkeitsbeginn. Dann wird die Adresse für einen Kunden ermittelt, indem man den Adresseintrag für die Kundennummer sucht, der das größtmögliche Gültigkeitsdatum hat, das gerade noch nicht in der Zukunft liegt. Mit dem Ansatz muss man in dieser Tabelle vielleicht tatsächlich nur neue Datensätze einfügen, wenn sich etwas geändert hat. Und wenn ein Kunde gelöscht wird, dann fügt man einen Datensatz ein, der beinhaltet, dass der Kunde ab einem bestimmten Datum „gelöscht“ ist, aber man kann noch bei Bedarf Daten liefern.

Das Schöne ist nun aber, dass Daten, die in der Datenbank „immutable“ sind, also keine Updates erhalten dürfen, in der Software auch problemlos immutable sein können (und sollten) und dass man sie auch langlebiger als eine Transaktion machen kann. Vorsicht ist aber immer geboten, weil komplexe Objekte in der Applikation sich auch allein durch Inserts in einer Datenbanktabelle ändern würden, wenn etwa eine Collection enthalten ist. Man muss also das OR-Mapping genau kennen, egal wie faszinierend diese Automatismen auch sein mögen. Im Fall von einer Kundenadresse muss man die gültige Adresse immer in Verbindung mit einem Timestamp behandeln, der beim ermitteln der gültigen Adresse eingesetzt wurde. Wenn dieser Timestamp veraltet ist, muss man auch die Adresse neu abfragen, wobei es im Gegensatz zu den Buchungen die Adressänderungen selten auf die Mikrosekunde des Umzugszeitpunkts ankommt, solange man die Konsistenz wahrt und nicht in der Woche des Umzugs wilde Mischungen aus der alten und der neuen Adresse verwendet.

Share Button

Mehrfache Interfaces mit inneren Klassen

Die im Beitrag über Multidispatch angedeutete Möglichkeit, mit inneren Klassen oder Wrappern anderen „equals()“ und „hashCode()“-Methoden anzubieten, sollte vielleicht etwas genauer gezeigt werden. Als Beispiel dient hier einmal Java, aber die Thematik ist auch in Scala, Ruby, Perl, C# und anderen Sprachen vorhanden, weil es gängig ist, dass die Hashtabellen gerne mit einer einer bestimmten Kombination aus hashCode() und eqals() zusammenarbeiten. Das zwingt dazu, diese beiden Methoden nach der gängigsten Verwendung in Hashtabellen zu definieren.

Die Idee lässt sich aber auch anwenden, um verschiedene Interfaces mit derselben Klasse zu implementieren.

Das Prinzip sieht so aus:

public interface A {
    public int fa(int x);

public interface B {
    public int fb(int x);

public class X implements A {

    public int fa(int x) {
    private class Y implements B {
        public int fb(int x) {
             return fa(x) % 999;
    public B getAsB() {
        return new Y()

Man kann also die Implementierung von B in der inneren Klasse Y vorsehen und dabei auf alle Methoden und Attribute der umgebenden Klasse zugreifen. Die Referenz auf die umgebende Klasse ist bei allen Instanzen der (nicht-statischen) inneren Klasse implizit dabei.

Hier ein Beispiel für verschiedene hashCode() und equals-Methoden:

public interface StringPair {
    public String getLhs();
    public String getRhs();

public class StringPairImpl implements StringPair {
    private final String lhs;
    private final String rhs;

    public StringPairImpl(String lhs, String rhs) {
        assert lhs != null;
        assert rhs != null;
        this.lhs = lhs;
        this.rhs = rhs;

    public String getLhs() {
        return lhs;

    public String getRhs() {
        return rhs;

    public int hashCode() {
        return lhs.hashCode() * 91 + rhs.hashCode();

    public boolean equals(Object obj) {
         if (this == obj) {
             return true;
         } else if (! obj instanceof StringPairImpl) {
             return false;
         } else {
             StringPairImpl other = (StringPairImpl) obj;
             return this.lhs.equals(other.lhs) && this.rhs.equals(other.rhs);

    private class IgnoreCase implements StringPair {

        public String getLhs() {
            return lhs;

        public String getRhs() {
            return rhs;

        public int hashCode() {
            return lhs.toUpperCase().hashCode() * 91 + rhs.toUpperCase().hashCode();

        public boolean equals(Object obj) {
             if (this == obj) {
                 return true;
             } else if (! obj instanceof StringPairImpl) {
                 return false;
             } else {
                 StringPairImpl other = (StringPairImpl) obj;
                 return this.lhs.toUpperCase().equals(other.lhs.toUpperCase())
                     && this.rhs.toUpperCase().equals(other.rhs.toUpperCase());

    public StringPair getWithCaseIgnored() {
        return new IgnoreCase();

Die innere Klasse bietet also eine Implementierung desselben Interfaces, aber hashCode() und equals() ignorieren diesmal Groß- und Kleinschreibung.

Eine andere Möglichkeit wäre es bei Collections, eine immutable-Variante über eine innere Klasse anzubieten und eine getImmutable()-Methode einzubauen. Das ist aber bekanntlich nicht der Weg, den die JDK-library gewählt hat.

Was man aber dabei auch sieht: Leider muss man sehr viel „unnötigen“ Code schreiben, der eigentlich offensichtlich ist, aber eben doch nicht fehlen darf. Das erschwert sowohl das Schreiben als auch das Lesen des Codes, vor allem aber die Wartbarkeit. So wird die an sich gute Idee der inneren Klassen teilweise wieder verwässert.

Share Button

OR-mappings: Hibernate & Co.

Die meisten Software-Projekte verwenden eine Datenbank. Es ist immer eine Herausforderung, die Datenbank und die Software zusammenzubringen, weil das zwei verschiedene Welten sind, die ihre eigene Entwicklung genommen haben.

Hierzu haben sich ganz verschiedene Ansätze etabliert.

  • DB-zentrisches Vorgehen: Ein starker DBA oder ein starkes DB-Team fängt zunächst an, das Datenmodell zu erstellen. Die Software muss sich daran anpassen. Für die performance-kritischen Zugriffe erhalten die Entwickler Unterstützung von einem DBA.
  • Eine Variante davon ist die Verwendung des Active-Record-Patterns, wo die Objekte aus der Datenbankstruktur generiert werden. Dieses Active-Record-Pattern verwendet man bei Ruby on Rails.
  • OR-zentrisches Vorgehen: Man verwendet objekt-relationale Mapper und definiert Klassen in seiner Software und ein paar XML-Dateien oder Annotationen dazu und hofft dann, dass der OR-Mapper nicht nur relationale Daten in Objekte und Objekte in relationale Daten wandelt, sondern dass auch noch gleich das Datenmodell und die Zugriffe automatisch generiert werden. Das ist der typische Ansatz bei Hibernate, JDO, Eclipselink etc.
  • Auch in der Rails-Welt versucht man es oft und gerne ohne DBA und lässt das DB-Schema generieren.
  • Man verzichtet auf die relationale SQL-Datenbank und arbeitet mit NoSQL-Datenbanken, die oft etwas näher an der Software liegen

Letztlich muss man sich aber die Fragen beantworten, ob man die Datenbank in den Mittelpunkt stellt und die Software passend zur Datenbank entwickelt oder ob man die Software in den Mittelpunkt stellt und die Datenbank nur als eine Art Persistenzmechanismus dafür verwendet.

Dann kommt die zweite Frage ins Spiel, wie man die objektorientierte, prozedurale und funktionale Welt der Software mit der relationalen Welt der SQL-Datenbanken oder der jeweiligen Struktur der NoSQL-Datenbanken zusammenbringt.

Eine dritte Frage taucht auf, ob man auf Softwareebene Caching-Mechanismen einbaut. Das muss man nicht, aber Hibernate verspricht einem so etwas gut zu können und auch bietet sogar Caching auf der Platte an, nicht nur im Memory.

Die erste Frage ist legitim und kennt wohl keine allgemeingültige Antwort. Man kann durchaus von einer Datenbank im Mittelpunkt ausgehen, wenn diese von mehreren Applikationen genutzt wird oder wenn man davon ausgeht, dass die Daten wesentlich langlebiger als die Software sind. Das könnte bei einer Kundendatenbank so sein. Oft behilft man sich mit dem Versprechen, dass es eine Export-Funktionalität gibt und wenn man dann irgendwann die Software umstellen will, kann man die Daten als XML exportieren und gleich in die neue Software übernehmen. Das kann Routine sein, ich wäre aber skeptisch und würde diese Migration sorgfältig planen und testen. Wahrscheinlich wird es nicht so einfach und so billig, wie man gehofft hat.

Die zweite Frage ist auch recht relevant. Man hat ja nicht nur Objekte in Relationen zu übersetzen, sondern muss sich auch mit Transaktionen auseinandersetzen und mit der Frage, wie tief man große Objekte mit vielen Unterobjekten wirklich lesen und schreiben will. Hier werden gute Antworten schwierig. Liest man sie nur in kleine Portionen, stößt man später auf Probleme, weil Unterobjekte fehlen, z.B. LazyLoadingException in Hibernate. Man muss hierfür eine Lösung finden und diese konsequent umsetzen. Ein radikaler Ansatz, der etwas umständlich ist, aber recht zuverlässig funktioniert, ist die aggregierten Objekte zu entkoppeln und stattdessen nur Schlüsselfelder zu speichern. Beim Zugriff muss man sie dann explizit mit dem Schlüsselfeld holen und stellt so sicher, dass sie aktuell sind. Hier stellen sich natürlich auch interessante Konsistenzfragen, wenn man Daten aus der Datenbank miteinander kombiniert, die von verschiedenen Zeitpunkten stammen und die deshalb nicht mehr notwendigerweise miteinander konsistent sind.

Ein beliebter Ansatz ist, recht viel in den Hauptspeicher zu laden und darauf zuzugreifen. Damit landen wir bei dem dritten Thema, dem Caching. Eines sollte zunächst einmal klargestellt werden: Wenn man eine relationale SQL-Datenbank benutzt und sich dabei auf das Caching des OR-Mapping-Frameworks verlässt, dann verlässt man die transaktionale Welt. Man handelt sich sehr viele Probleme ein, weil Fragen der Konsistenz nicht mehr einfach handhabbar sind, schon gar nicht auf DB-Ebene. Das lässt sich scheinbar in den Griff bekommen, wenn man sagt, alle Zugriffe laufen über die Applikation und die Datenbank ist nur noch eine Persistenzschicht. Nun laufen aber mehrere Threads gleichzeitig und man stößt dann auch noch in diesen heiklen Bereichen auf Hibernate-Fehler. Eclipselink, JDO, etc. sind da wohl nicht wesentlich anders. Kurz gesagt, das Caching ist für veränderliche Daten bestenfalls kaum handhabbar, aber ich gehe sogar soweit, dass das konzeptionell nicht korrekt ist. Nun kann man natürlich so etwas wie „Stammdaten“ haben, die sich selten verändern. Die lassen sich tatsächlich im Memory halten, wenn es einen Prozess gibt, diesen Cache aufzufrischen, wenn sich die Stammdaten ändern, vielleicht sogar mit einem Neustart der Applikation. Ja, das will niemand zugeben, dass man so etwas heute braucht, aber besser zweimal im Jahr die Applikation neu starten als zwei Monate im Jahr obskure Fehler suchen, die durch unsauberes Caching und Fehler im OR-Mapping-Framework entstehen.

Zusammenfassend kann man sagen, dass diese OR-Mapper durchaus zumindest in der Java-Welt ihren Bereich haben, wo sie nützlich sind. Aufpassen sollte man aber bei sehr großen Tabellen und bei sehr stark miteinander verknüpften Tabellen und vor allem beim Caching von veränderlichen Daten. Hier lohnt es sich, etwas mehr Aufwand zu treiben, denn der scheinbare Komfortgewinn durch den OR-Mapper existiert hier nicht oder nur zu einem unverhältnismäßig hohen Preis.

Share Button