Thomas Muchs Java Blog

JAXB und HashMaps

2011-12-22T11:44:00.002+01:00

Die Technik ist zwar schon älter, aber vielleicht ist folgender Tipp trotzdem nützlich – zumal die entsprechende JAXB-Eigenschaft nicht sonderlich gut dokumentiert ist.

Wenn man Schlüssel-Wert-Paare aus einer XML-Datei in eine HashMap einlesen soll, ist das recht einfach, sofern man Einfluss auf die Struktur des XML-Dokuments hat und dieses in etwa so aussehen kann:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<meineEntitaet>
  <paarliste>
    <entry>
      <key>MeinSchlüssel</key>
      <value>MeinWert</value>
    </entry>
    <entry>
      <key>...</key>
      <value>...</value>
    </entry>
    ...
  </paarliste>
</meineEntitaet>

Die zugehörige Klasse muss dann wie folgt aufgebaut und mit JAXB-Annotationen versehen sein:

import java.util.*;
import javax.xml.bind.annotation.*;

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class MeineEntitaet {

  @XmlElementWrapper(name="paarliste")
  private Map<String,String> map
    = new HashMap<String,String>();

  public Map<String,String> getMap() {
    return map;
  }

  public void setMap(Map<String,String> map) {
    this.map = map;
  }
}

Die XML-Datei lässt sich dann mit folgender Anweisung in ein Objekt einlesen:

MeineEntitaet obj =
  JAXB.unmarshal(
    new File("beispiel.xml"),
    MeineEntitaet.class);
System.out.println( obj.getMap() );

Genauso einfach lässt sich natürlich auch eine HashMap als XML schreiben:

MeineEntitaet obj = new MeineEntitaet();
obj.getMap().put("MeinSchlüssel", "MeinWert");
// JAXB.marshal(obj, System.out);
JAXB.marshal(obj, new File("beispiel.xml"));

Während man den XML-Element-Namen der Schlüssel-Wert-Paare-Liste mit der Annotation @XmlElementWrapper konfigurieren kann, sind die Elemente entry, key und value fest benannt. Um auch diese Namen zu verändern, muss man einen eigenen XmlAdapter implementieren.

Message Driven Beans anhalten und starten

2011-11-28T12:55:00.004+01:00

Message Driven Beans (MDBs) werden meistens schon aktiv (d.h. vom Container aufgerufen, wenn über JMS Nachrichten für die Bean vorhanden sind), während das Deployment der Anwendung noch läuft. Das ist normalerweise unkritisch, aber es gibt Situationen, in denen man sicherstellen möchte/muss, dass die MDBs erst nach vollständigem Deployment (oder irgend einem anderen definierten Zeitpunkt) aktiv werden.

Nahezu jedes Messaging-System (JMS-Implementierung) bietet die Möglichkeit, über produktspezifische API oder externe Kommandos eine Queue anzuhalten und später wieder zu starten. Das betrifft aber die komplette Queue, d.h. es ist dann auch nicht mehr möglich, Nachrichten in die Queue zu schreiben.

Bei einigen Messaging-Systeme kann man daher via JMX die MBean einer MDB ermitteln und damit tatsächlich nur die MDB anhalten – also die Zustellung aus der Queue unterbinden. Das Schreiben in die Queue wäre dann immer noch möglich. (Das Problem, wie damit die MDB gleich zu Beginn des Deployments gestoppt wird, lassen wir mal außen vor.)

Leider sind beide Lösungen produktspezifisch. Eine portable Lösung ist bis inkl. Java EE 6 für Message Driven Beans nicht vorgesehen. Wie könnte eine selbst gebaute, portable Lösung aussehen?

Java SE 5 hat im Paket java.util.concurrent viele neue Klassen rund um Thread-Synchronisation und Sperren in die Java-Welt gebracht. Für unsere Zwecke ist ein CountDownLatch geeignet:

import java.util.concurrent.CountDownLatch;

@Singleton
public class AppStatus {

  private static final CountDownLatch startSignal
      = new CountDownLatch(1);

  public void waitForAppInitialized() {
    try {
      startSignal.await();
    } catch (InterruptedException e) {
      throw new RuntimeException(
        "Fehler beim Warten auf Sperren-Freigabe", e);
    }
  }

  public void setAppIsInitialized() {
    startSignal.countDown();
  }

  public boolean isAppInitialized() {
    return (startSignal.getCount() == 0L);
  }
}

Der CountDownLatch ist zu Beginn gesperrt. Zur Freigabe muss die Anwendung zu einem geeigneten Zeitpunkt die Methode setAppIsInitialized() aufrufen, beispielsweise in einem ServletContextListener oder in einem EJB-Timer.

Die zu blockierende MDB wartet dann bei jedem Aufruf zunächst darauf, ob die Sperre schon freigegeben wurde:

@MessageDriven
public class StartbareMDB implements MessageListener {

  @EJB
  private AppStatus status;

  public void onMessage(Message msg) {

    status.waitForAppInitialized();

    // ... der eigentliche MDB-Code ...
  }
}

Eine einfache, funktionierende Lösung mit Java-Bordmitteln.

Nachteil dieser Lösung ist, dass hier Threads des Containers blockiert werden. Man muss aufpassen, dass die Maximalzahl der blockierten MDB-Threads den Threadpool nicht überfordert (was ein Grund ist, warum man in Java EE-Containern nicht mit Threads herumspielen soll).

Außerdem ist der Performanceverlust nicht riesig, aber messbar. Für Höchstlastsysteme ist das also evtl. nicht geeignet. Zumal dort oft Clustering zum Einsatz kommt – und obige Lösung ist nur clusterfähig, wenn man sicherstellen kann, dass die Freigabe-Methode auf jedem Cluster-Knoten aufgerufen wird.

Als weitere (bewusste) Einschränkung ist zu beachten, dass der CountDownLatch nur einmalig nutzbar ist, er dient also wirklich nur als Start-Signal. Wenn man Message Driven Beans beliebig anhalten und starten möchte, muss man andere Sperren verwenden.

Fazit: Die hier vorgestellte Lösung funktioniert in vielen praktischen Situationen gut. Aber gibt es andere Ideen / Lösungen, die ähnlich einfach zu realisieren sind, die gezeigten Einschränkungen aber nicht aufweisen? Oder müssen wir auf Java EE 7 (oder eher 8) warten?

Java für Mac OS X 10.7 "Lion"

2011-11-24T12:44:00.004+01:00

Da Apple vor kurzem Java-Updates für Mac OS X veröffentlicht hat, gibt es an dieser Stelle eine kleine Erinnerung an die wichtige Änderung, die mit Mac OS X 10.7 "Lion" eingeführt wurde: Im Gegensatz zu allen anderen Mac OS X-Versionen davor (*) ist keine Java-Laufzeitumgebung mehr vorinstalliert.
(* Von der 10.0-Public Beta, die wir uns 2000 von der Apple Expo Paris mitgenommen haben, mal abgesehen.)

Beim ersten Aufruf einer Java-Anwendung erhält man einen Hinweis, dass die Java-Runtime benötigt wird. Bestätigt man dies, wird Java SE 6 heruntergeladen und installiert. Danach wird die ursprünglich aufgerufene Java-Anwendung gestartet.

Das aktuelle Java-Update von Apple enthält Java 1.6.0_29 und ist damit zeitlich erfreulich nah an Oracles Java 6-Update für andere Systeme. Java 7, für andere Systeme mittlerweile als erstes Update freigegeben, ist leider immer noch nicht final für Mac OS X verfügbar (immerhin gibt es eine Developer Preview von Oracle). Java 8, was sich derzeit noch in der Entwicklung befindet, ist aber schon als Build des OpenJDK 8 für Mac OS X erhältlich.

Zeitdauern berechnen mit TimeUnit

2011-10-25T22:31:00.002+02:00

Auf java.net ist gerade ein netter Blog-Artikel verlinkt, der das java.util.concurrent-Enum TimeUnit vorstellt. Aus diesem Anlass eine kleine Idee, wofür ich dieses Enum und seine Umwandlung-Methoden schon gut gebrauchen konnte. Wenn man Zeitdifferenzen berechnet, benötigt man häufiger Konstanten von folgender Art:

public static final long MS_PRO_TAG
             = 1L * 24L * 60L * 60L * 1000L;

Das funktioniert zwar, ist aber fehleranfällig, weil man sich bei Anzahl und Wert der Faktoren leicht vertun kann. Mit folgendem Ausdruck kann eine beliebige Anzahl Tage (hier: 1) in Millisekunden umgerechnet werden:

public static final long MS_PRO_TAG
             = TimeUnit.DAYS.toMillis(1L);

Ebenso lassen sich Sekunden in Stunden umrechnen etc.:

assert TimeUnit.SECONDS.toHours(7250L) == 2;

Wie der andere Blog-Autor schon schreibt: Eigentlich gehört dieses Enum ins Package java.lang (oder vielleicht noch besser nach java.util).

"reschedule-failed-timer" in GlassFish 3.1

2011-10-13T22:23:00.001+02:00

In Stateless Session Beans, Singleton Beans und Message Driven Beans kann der EJB-Timer-Service genutzt werden. Ab EJB 3.1 ist es dabei sehr einfach geworden, wiederkehrende Intervall-Timer mit der @Schedule-Annotation zu definieren (eine programmatische Definition ist natürlich weiterhin möglich).

Wenn ein periodischer Timer eine Exception wirft, wird GlassFish sofort noch zweimal versuchen, die Timer-Methode auszuführen. Werden auch diese Aufrufe mit Exceptions abgebrochen, stoppt GlassFish den Timer komplett, d.h. auch nach Ablauf des nächsten Intervall-Zeitraums erfolgt kein Aufruf mehr! Ich bin mir nicht sicher, ob dieses Verhalten von der EJB-Spezifikation gedeckt ist – intuitiv dürfte man aber vermutlich erwarten, dass Intervall-Timer zuverlässig ausgeführt werden.

Seit GlassFish 3.1 gibt es eine Server-Property "reschedule-failed-timer", mit der dieses Verhalten konfiguriert werden kann. Über das Konfigurationsprogramm asadmin kann man mit

asadmin set configs.config.server-config.ejb-container.ejb-timer-service.property.reschedule-failed-timer=true

einstellen, dass auch per Exception abgebrochene Timer nach Ablauf des nächsten Intervall-Zeitraums wieder aufgerufen werden. Durch den Aufruf wird in domain.xml folgender Abschnitt eingetragen:

<ejb-container session-store="${com.sun.aas.instanceRoot}/session-store">
  <ejb-timer-service>
    <property name="reschedule-failed-timer" value="true"></property>
  </ejb-timer-service>
</ejb-container>

Ohne das Setzen der Property bleibt ansonsten nur, den gesamten Timer-Methoden-Rumpf in try { ... } catch (Exception ...) einzufassen, damit garantiert keine Exception den Timer verlässt.

Oracle JDK7 für Mac OS X (Developer Preview)

2011-10-05T21:51:00.004+02:00

Nachdem Java SE 7 schon seit einigen Monaten für Windows, Linux und Solaris verfügbar ist und eine Portierung des OpenJDK 7 für Mac OS X begonnen wurde, bietet Oracle nun eine Vorabversion des JDK 7 für Mac OS X an.

Die Installation ist denkbar einfach: Nach dem Download der DMG-Datei zieht (kopiert) man die enthaltene Paket-Datei einfach ins Verzeichnis /Library/Java/JavaVirtualMachines. Fertig! Das Verzeichnis sollte bereits existieren, wenn man das letzte Apple-Java-Update installiert hat, ansonsten muss man es von Hand anlegen.

Die neue Version wird sofort von den Java-Einstellungen erkannt, ein Neustart des Systems ist nicht notwendig. Anwendungen müssen beendet und neu gestartet werden, um das neue Java nutzen zu können.

much$ /usr/libexec/java_home --version 1.7
/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home

much$ /usr/libexec/java_home -v 1.7 --exec java -version
openjdk version "1.7.0-ea"
OpenJDK Runtime Environment (build 1.7.0-ea-b211)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

Scala 2.9 und Akka 1.1

2011-05-12T20:49:00.001+02:00

Ein halbes Jahr nach der letzten Version wurde heute Scala 2.9 veröffenticht.

Wichtigste Neuerung sind sicherlich die parallelen Kollektionen, die z.B. beim Sortieren, Filtern und Durchlaufen automatisch mehrere Prozessorkerne nutzen. Sofern die dabei ausgeführten Funktionen hinreichend komplex sind, lassen sich durch die Parallelisierung deutliche Geschwindigkeitssteigerungen erreichen. "Normale" sequentielle Kollektionen lassen sich mit einem Methodenaufruf in eine parallele Kollektion umwandeln und umgekehrt.

Hilfreich für die alltägliche Programmierung ist auch der neue App-Trait, der den veralteten, nicht so mächtigen und teilweise problematischen Application-Trait ablöst. Mit dem App-Trait lässt sich auf einfache und elegante Weise der Programm-Einstiegspunkt schreiben – er ist also eine Vereinfachung der main-Methode (die man aber immer noch von Hand programmieren kann).

Diese und viele weitere kleine Verbesserungen sind genauer in der Ankündigung der neuen Version 2.9 beschrieben.

Zeitgleich wurde die Gründung der Firma Typesafe bekannt gegeben, in der sich die Gründer und Entwickler von Scala und Akka zusammentun, um Dienstleistungen rund um die Scala-Technologie anzubieten. Als Berater stehen dieser neuen Firma recht bekannte Java-Größen wie James Gosling und Doug Lea zur Seite. Neben Dienstleistungen bietet Typesafe den Typesafe Stack an, ein vorkonfiguriertes Paket mit Scala 2.9 und Akka 1.1.

Akka ist eine Ereignis-gesteuertes Rahmenwerk, mit dem sich verteilte Anwendungen entwickeln lassen. Die Geschäftslogik bleibt dabei frei von den technischen Aspekten der Parallelisierung, Kommunikation, Ausfallsicherheit etc. – ideal für typische Server-Anwendungen. Bekannt geworden ist Akka durch die eigenen, hochskalierbaren und robusten Aktoren (Actors).

Im Typesafe Stack 1.0 sind sowohl die Aktoren von Scala als auch die von Akka mit ihrer bisherigen Funktionalität enthalten. Für zukünftige Scala-Versionen ist aber wohl geplant, diese Funktionalitäten zusammenzuführen.

Monaden in Scala

2011-03-20T21:28:00.007+01:00

Am vergangenen Wochenende habe ich beim MATHEMA Campus 2011 einen Vortrag über Monaden in Scala gehalten (Folien hier).

Monaden sind ein etwas sperriges Konzept, das in rein funktionalen Sprachen wie Haskell u.a. für eine vernünftige Ein-/Ausgabeprogrammierung notwendig ist. Für Scala sind Monaden vielleicht nicht ganz so wichtig, aber auch mit Scala kann man sinnvoll monadisch programmieren – und das Schöne daran: Über die ganze komplizierte mathematische Theorie dahinter muss man sich keine Gedanken machen. Im Gegenteil, wer schonmal ein bisschen Scala programmiert hat, wird dabei vermutlich (unbewusst) auch Monaden genutzt haben.

Was sind diese Monaden? Ein abstrakter Datentyp für verkettbare Berechnungen mit folgenden Eigenschaften:

Ein Typkonstruktor wie List[A] (mit z.B. List[Int] als Ausprägung).
Eine Funktion, um einen Wert im Typ "einzuwickeln". Das kann der Konstruktor sein, z.B. new List(1) bzw. List(1), aber häufig wird diese Funktion return, unit, lift oder pure genannt.
Eine Funktion, um die enthaltenen Werte zu verrechnen, aber nach der Berechnung im Typ verpackt zu lassen. Übliche Namen sind bind oder (in Scala) flatMap.

Die Monadengesetze müssen von den Funktionen eingehalten werden, aber das lassen wir mal außen vor. Klingt kompliziert? Schauen wir uns das in der Praxis an:

case class MiniMonade[A](wert:A) {

  def flatMap[B](f: A => MiniMonade[B]) = f(wert)

  def map[B](f: A => B): MiniMonade[B]
     = MiniMonade(f(wert))
}

Die Mini-Monade soll also genau einen Wert des generischen Typs "A" speichern und verarbeiten können. Listen sind auch Monaden und können entsprechend beliebig viele Werte verarbeiten. In unserer Monade ist zusätzlich noch die Funktion map implementiert, damit wir Objekte dieser Klasse in den for-Comprehensions von Scala einsetzen können. Und genau das ist auch der häufigste Anwendungsfall für Monaden in Scala:

val m1 = MiniMonade(2)
val m2 = MiniMonade(3)

val erg = for { x <- m1; y <- m2 } yield x*y;

println( erg )

In dieser for-Comprehension werden alle Werte aus den beiden Monaden-Objekten miteinander mit x*y verrechnet und landen anschließend (durch die Magie der Monaden-Funktionen) wieder in einem Monaden-Objekt. Da unsere Objekte jeweils nur einen Wert speichern, wird nur 2*3 berechnet:

HeartOfGold:~ much$ scala MiniMonade.scala
MiniMonade(6)

Das scheint unnötig viel Aufwand für eine simple Multiplikation zu sein... Aber folgendes Beispiel dürfte – so oder in ähnlicher Form – jeder schonmal programmiert haben, und das ergibt sicher mehr Sinn:

val zeilen = List(10,20)
val spalten = List(1,2)

val summen = for {z <- zeilen; s <- spalten} yield z+s;

println( summen )
// List(11, 12, 21, 22)

Andere gebräuchliche monadische Typen sind (neben vielen weiteren) Map und Option, und alle diese Klassen können in einer for-Comprehension kombiniert werden.

Die Verwendbarkeit in for-Comprehensions ist in Scala sicherlich der wichtigste Grund, warum man geeignete eigene Klassen monadisch machen sollte. Würden wir noch withFilter und foreach implementieren, könnten wir unsere Monade außerdem in weiteren for-Varianten einsetzen.

Beim diesjährigen Herbstcampus werde ich einen Einsteiger-Vortrag (OO-Vorkenntnisse reichen) zu diesem Thema halten.

Freie Icons für Web-Oberflächen

2011-02-09T20:44:00.009+01:00

Gute Web-Oberflächen zeichnen sich nicht nur durch durchdachte, einfach zu verstehende HTML-Formulare aus. Sie sollten auch ansprechend – "schön" – aussehen, weil die Benutzer dann garantiert lieber mit der Web-Anwendung arbeiten als mit lieblos gestalteten Seiten.

Ein wichtiger Aspekt dabei sind klar gestaltete Symbolgrafiken (Icons) – sei es für Status-Anzeigen oder für Schaltflächen. Wenn man künstlerisch nur eingeschränkt begabt ist, greift man besser auf fertige Grafiken zurück, als langweilige und schlecht zu erkennende Symbole selber zusammenzupixeln.

Seit langer Zeit nutze ich daher immer wieder gerne die famfamfam-Icons von Mark James. Die Mini- und Flaggen-Icons sind dabei komplett Public Domain, können also beliebig verwendet werden. Und auch die 1000 Silk-Icons stehen kostenfrei selbst für kommerzielle Anwendungen zur Verfügung. Der Autor bietet sie unter der Creative Commons Attribution 2.5-Lizenz an (wahlweise auch unter der Lizenz-Version 3.0) und verlangt lediglich einen Link auf seine Web-Seite.

Vielen Dank für die Blumen – äh – Icons!

OpenJDK 7 für Mac OS X

2011-01-14T20:07:00.003+01:00

Nachdem Apple vor knapp zwei Monaten Unterstützung für das OpenJDK-Projekt angekündigt hatte, wurde die Mac OS X-Portierung am Montag dieser Woche als offizielles OpenJDK-Projekt angenommen – und nur einen Tag später hat Apple den ersten offenen Code in das Projekt eingebracht. Im Wesentlichen entspricht diese erste Veröffentlichung der BSD-Portierung. Apple hat derzeit nur den Build-Prozess verändert, um ein Universal Binary mit einem .jdk-Bundle zu erzeugen, das zur neuen Java-Verzeichnisstruktur von Mac OS X passt (und entsprechend nach der Installation automatisch erkannt wird).

Jeder kann nun zum Mac OS X-Port beitragen und sich das aktuellste OpenJDK aus den Quelltexten bauen. Voraussetzung dafür sind u.a. Mac OS X ab Version 10.6.5 sowie Xcode ab Version 3.2.5. Genaueres ist im Wiki beschrieben; dort kann man auch den aktuellen Projekt-Status einsehen.

Wer das JDK 7 einfach ausprobieren möchte, ohne es selber bauen zu müssen, kann sich ein fertiges DMG von Google Code herunterladen. Der Installer für den Mac OS X-Branch enthält sowohl eine 32- als auch eine 64-Bit-JVM. Nach der schnellen und vollkommen unproblematischen Installation kann man das JDK 7 mit den üblichen Kommandos im Terminal testen:

much$ /usr/libexec/java_home --version 1.7
/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home

much$ export JAVA_HOME=`/usr/libexec/java_home -v 1.7`
much$ $JAVA_HOME/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-b00)
OpenJDK 64-Bit Server VM (build 20.0-b03, mixed mode)

much$ /usr/libexec/java_home -v 1.7 --exec java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-b00)
OpenJDK 64-Bit Server VM (build 20.0-b03, mixed mode)

Für grafische Frontends wird noch kein Cocoa, sondern nur X11 unterstützt. Zum Ausprobieren der neuen Sprachfeaturen (Strings im switch etc.) reicht das aber vollkommen aus.

Wie bereits erwähnt wird das OpenJDK 7 automatisch von den Java-Einstellungen in Mac OS X erkannt. Wegen der noch unvollständigen Cocoa- bzw. Mac OS X-Integration sollte man die neue Version aber noch nicht als Default setzen, d.h. besser am Ende der Liste belassen.

VisualVM 1.3.x statt Eclipse TPTP?

2010-11-30T21:39:00.005+01:00

Vor zwei Wochen wurde bekannt gegeben, dass das Eclipse-Projekt für Test- und Performance-Werkzeuge – TPTP – nach dem kommenden Update auf Version 4.7.2 (geplant für Februar 2011) nicht mehr weiterentwickelt wird.

Einer der Aspekte, die mir an TPTP gefallen haben, war das Probekit, mit dem man kleine Java-Schnipsel an bestimmte Stellen einer Java-Klasse (Methoden-Ein- und -Ausgang etc.) einweben lassen konnte, um die Klassen zur Laufzeit genauer zu untersuchen.

Ein möglicher Ersatz steht schon in den Startlöchern. Mitte des Jahres wurde VisualVM 1.3 veröffentlicht, das mittlerweile in der Version 1.3.1 verfügbar ist. Darin enthalten ist das Tracer-Plugin, mit dem sich diverse "Probes" für eine laufende Anwendung aktivieren lassen, die dann synchron untereinander auf einer Zeitleiste dargestellt werden:

Derzeit gibt es nur vordefinierte Probes für Swing, JavaFX sowie für diverse weitere Pakete der Standard-Klassenbibliothek (Collections, I/O etc.). Das Tracer-Framework soll sich aber einfach mit eigenen Probes erweitern lassen (auch wenn ich noch keinen Link zu einer aktuellen Entwickler-Dokumentation gefunden habe) – und vielleicht gibt es ja in absehbarer Zeit eine Probe zum AOP-mäßigen Einweben von kleinen Code-Stücken? Dieser Wunsch muss erlaubt sein, schließlich ist ja bald Weihnachten :-)

Ob man VisualVM separat herunterladen muss oder ob es im installierten JDK bereits enthalten ist, kann man auf der Release-Übersicht herausfinden. Das aktuelle Java 6 Update 22 bringt leider immer noch die ältere VisualVM-Version 1.2.2 mit.

Oracle bringt Java SE 7 für Mac OS X

2010-11-15T18:07:00.003+01:00

... und Apple wird auch in Mac OS X 10.7 "Lion" noch die eigene Java SE 6-Implementation bereitstellen. Das sind kurz zusammengefasst die Ergebnisse der letzten Tage.

Nachdem es vor drei Wochen recht düster für die Zukunft von Java auf Mac OS X ausgesehen hatte, weil Apple die eigene Java-Implementierung abgekündigt, aber keinen Ersatz als Perspektive geboten hatte, sieht es nun so aus, als ob wir genau die Lösung bekommen, die von vielen favorisiert wurde: Apple bringt die meisten Teile seiner Java-Implementation als Open Source in das OpenJDK-Projekt ein, und Oracle wird daraus – beginnend mit Java SE 7 – offizielle Java-Releases für Mac OS X bauen.

Es ist noch nicht ganz klar, wann Java SE 7 für Mac OS X verfügbar sein wird und wie die Quelltexte im Detail zur Verfügung gestellt werden. Aber die Zukunft für Java auf Mac OS X dürfte damit sichergestellt sein.

Nebenbei hat Apple in der Pressemitteilung bekannt gegeben, dass auch das im nächsten Jahr erscheinende Mac OS X 10.7 "Lion" noch die eigene Java SE 6-Implementation enthalten wird, so dass für die Übergangszeit auf Oracles Mac-Java-Implementation eine klare Perspektive besteht.

Na also. Warum denn nicht gleich so?

Scala 2.8.1

2010-11-11T21:35:00.003+01:00

Vorgestern wurde mit nur wenigen Tagen Verspätung Scala 2.8.1 freigegeben.

Neben zahlreichen Bugfixes enthält das Update vor allem eine verbesserte Version von Scaladoc. Ein Ergebnis dieses Werkzeugs ist beispielsweise die API-Dokumentation der Scala-Standard-Bibliothek.

Scala 2.8.1 ist vollständig binärkompatibel mit der vorangegangenen Version 2.8.0 (was davor durchaus nicht selbstverständlich war, nun aber erklärtes Ziel zur Stabilisierung der Softwareentwicklung mit Scala ist).

Seit heute liegt außerdem die Scala IDE für Eclipse in einer aktualisierten Version vor. Durch die Binärkompatibilität der Scala 2.8.x-Versionen kann man erstmalig die neueste Scala IDE einsetzen und damit bestehende Projekte wahlweise weiterhin mit Scala 2.8.0 übersetzen, bis eine Umstellung auf 2.8.1 geeignet erscheint.

@Deprecated Java für Mac OS X

2010-10-21T22:11:00.001+02:00

Es musste ja irgendwann passieren: Nachdem schon Flash in Ungnade gefallen war, hat Apple nun keine Lust mehr auf Java...

In den Release Notes zum gestern erschienenen "Java for Mac OS X 10.6 Update 3", das Java SE 6 auf Version 1.6.0_22 aktualisiert, findet sich an prominenter Stelle der Hinweis, dass Apples eigene Java-Implementation ab sofort als veraltete Technologie gilt und in künftigen Mac OS X-Versionen fehlen könnte.

Auch wenn direkt unter dieser Ankündigung beschrieben ist, dass und wie mit diesem Update Java Virtual Machines (JVMs) anderer Hersteller leichter ins System eingebunden werden können (was ich in einem folgenden Blog-Eintrag beschreibe) und auch die exakte Wortwahl der Apple-Java-Abkündigung fast impliziert, dass ein anderer Hersteller in die Bresche springen wird – gesichert ist dies nicht.

Bis also Oracle oder IBM oder irgendwer sonst (Google?) offiziell bekannt gibt, dass sie eine Java-Implementierung für Mac OS X anbieten werden, müssen wir leider davon ausgehen, dass Java auf dem Mac tot ist.

Dies dürfte extrem negative Auswirkungen auf den Einsatz von Macs in Unternehmen haben, da dort Java-Anwendungen häufig in der einen oder anderen Form benötigt werden. Ebenso wird der Mac damit für Bildungseinrichtungen und insbesondere Hochschulen uninteressant, da dort oft Java als Lehrsprache eingesetzt wird. Und die Java-Entwickler-Gemeinde, in der sich (zumindest gefühlt) überdurchschnittlich viele Mac-Anwender befinden, wird sich neue Hardware-Investitionen und Upgrades auf kommende Mac OS X-Versionen gut überlegen.

Zu hoffen bleibt, dass die Ankündigung nur eine Kommunikations-Katastrophe mit schlechtem Timing war. Andererseite werden, sofern man diversen Internet-Quellen glauben darf, Java-Anwendungen für den kommende "Mac App Store" nicht akzeptiert werden, da es sich um veraltete Technologie handelt. Und das sieht dann schon eher nach Absicht aus...

Abwarten und Kaffee trinken.

Hibernate 3.6 mit performanterem Envers und ohne Java 1.4

2010-10-14T12:50:00.004+02:00

Gestern gab es das zweite, große Hibernate-Release in diesem Jahr: Hibernate 3.6. So kurz nach Hibernate 3.5, das vor allem die JPA 2.0-Kompatibilität brachte, bringt die neue Version nicht sehr viele neue Features mit, sondern hat vor allem dringend notwendige interne Änderungen und Re-Implementierungen erfahren:

Java 1.4 wird nicht mehr unterstützt, Voraussetzung ist nun also Java 5.0 und neuer.
Das interne Typsystem wurde überarbeitet. Vor allem Implementierungen benutzerdefinierter Mapping-Typen müssen nun vermutlich angepasst werden.
Wer XML-Mappings verwendet, sollte die DTDs von http://hibernate.sourceforge.net/ auf http://www.hibernate.org/dtd umstellen.
Und schließlich enthält das mitgelieferte Envers eine neue Audit-Strategie, ValidityAuditStrategy. Damit kann nun nicht nur der Anfangszeitpunkt einer Revision gespeichert werden, sondern auch der Endzeitpunkt. Während das Speichern dadurch etwas mehr Zeit und eine zusätzliche Spalte in der Datenbank-Tabelle benötigt, wird das Lesen historischer Daten deutlich performanter.

Scala-Roadmap, -Literatur u.a.

2010-10-07T21:27:00.001+02:00

Es tut sich was im Scala-Universum. Laut Roadmap soll noch in diesem Monat Version 2.8.1 veröffentlicht werden. Zeitlich sieht es gut aus, denn die Version liegt bereits als zweiter Release Candidate vor. Mit diesem kleinen Update werden hauptsächlich Fehler beseitigt, die sich durch die starken internen Änderungen beim Sprung auf Version 2.8 eingeschlichten hatten.

Das nächste größere Update wird Scala 2.9 sein, das für Anfang kommenden Jahres geplant ist. Darin sollen vor allem parallele Kollektionen enthalten sein.

Um Firmen bei der Einführung von Scala und bei der Migration von älteren Scala-Versionen zu unterstützen, hat Martin Odersky, der Erfinder der Sprache, vor kurzem Scala Solutions gegründet. Ein guter und notwendiger Schritt, damit Scala im kommerziellen Umfeld die Akzeptanz findet, die diese Sprache verdient! (Scala-Workshops kann man natürlich auch anderswo buchen ;-)

Und noch ein bisschen Werbung in eigener Sache: Der Galileo-Verlag hat heute mein Buch "Scala. Der Schnelleinstieg für Entwickler." angekündigt, das im kommenden Jahr erscheinen wird. Bis zur Veröffentlichung bleibt noch genug zu tun, aber es macht Spaß, nach über fünf Jahren mal wieder ein Buch entstehen zu sehen :-)

Eclipse 3.6 und @SuppressWarnings("unchecked")

2010-09-28T17:09:00.001+02:00

Eclipse 3.6 ist schon seit einiger Zeit auf dem Markt, aber die ganzen neuen kleinen Features entdeckt man oft erst nach und nach.

Ergänzend zu einem früheren Posting habe ich gerade gesehen, dass die "Quick Fix"-Funktion bei einer "Type safety"-Warnung nun nach Möglichkeit anbietet, die passende Annotation direkt an die Variablendeklaration zu schreiben (und nicht nur über die gesamte Methode):

Nett!

Ant Filter-Copy-Task und Zeichenkodierung

2010-07-31T12:22:00.008+02:00

Ein Eintrag aus der Rubrik "kleiner Fehler, große Wirkung": Resource-Properties-Dateien wurden für eine Web-Anwendung mit einem Ant-Skript aus den Projektordnern in die passenden Ordner der Web-Applikation umkopiert. Bei manchen Properties-Dateien wurden die darin enthaltenen Umlaute im Browser manchmal (je nach Applikations-Server und je nach Rechner, auf dem die Web-Anwendung gebaut wurde) falsch dargestellt.

Ursache des Problems war ein copy-Task, der die Datei nicht 1:1 umkopiert, sondern mit einem filterset bestimmte Token ersetzt hat. Je nach Systemeinstellung kamen dann in der Web-Anwendung Umlaute (bzw. allgemein Sonderzeichen) an, die im Browser korrekt angezeigt werden konnten – oder eben nicht.

Die Lösung des Problems ist, bei Filter-Copy-Tasks die Kodierung explizit anzugeben, damit nicht die System-Default-Kodierung verwendet wird (die Doku erwähnt dies am Ende des Dokuments). Bei Properties-Dateien ist ISO-Latin-1 (ISO-8859-1) meist eine erste, gute Wahl (sofern die gesamte Web-Anwendung nicht auf UTF ausgelegt ist):

<copy
   todir="${webapp}/WEB-INF/classes"
   file="${src}/MyResources.properties"
   encoding="ISO-8859-1"
   overwrite="true">

   <filterset>
      <filter token="COMPILETIME" value="${DSTAMP}-${TSTAMP}"/>
   </filterset>

</copy>

Entstanden ist der Bug wohl durch Copy&Paste, wobei aus einem fileset – ohne Filterung und damit ohne die Notwendigkeit, eine Zeichenkodierung anzugeben – ein filterset wurde.

Scala 2.8 und Lift 2.0

2010-07-14T18:49:00.005+02:00

Knapp ein dreiviertel Jahr nach der letzten offiziellen Version 2.7.7 ist es heute endlich soweit: Scala 2.8 wurde veröffentlicht! Neben zahlreichen Bugfixes gibt es viele Neuerungen:

leichtgewichtigere, performantere Aktoren
Unterstützung für Continuations
verbesserte XML-Bibliothek
Überarbeitete Kollektions-Bibliothek und Array-Implementation
Benannte und Default-Argumente
Package-Objekte
bessere Unterstützung für (verschachtelte) Java-Annotationen
deutlich verbesserte Scala-Interpreter-Shell (REPL), u.a. mit Tab-Eingabevervollständigung
u.a.

Die Werkzeuge Sbaz und Scaladoc liegen in Version 2 vor, der Decompiler Scalap wurde an aktuelle Sprachkonstrukte angepasst. Die Scala IDE für Eclipse wurde intensiv überarbeitet, wodurch sie nun u.a. besser in die Java-Werkzeuge von Eclipse eingebunden ist.

Bereits vor zwei Wochen wurde das Scala-Web-Framework Lift 2.0 veröffentlicht. Neben der bisher schon sehr guten Ajax- und Comet-Unterstützung gibt es u.a. folgende Neuerungen:

NoSQL-Unterstützung (für MongoDB und CouchDB)
Performante JSON-Unterstützung mit einer eigenen DSL
REST-Unterstützung
Einbindung von JTA, LDAP u.a.
das Simple Build Tool sbt wird unterstützt und
die Lift-Programmierung wurde insgesamt vereinfacht.

Zum Schluss ein bisschen Werbung in eigener Sache: Wer mehr über Scala erfahren möchte, darf gerne an meinem nächsten Scala-Workshop teilnehmen, der Ende November in Köln stattfindet!

One more thing...

NetBeans 6.9 inkl. JavaFX Composer

2010-06-15T22:34:00.010+02:00

Heute hat Oracle/Sun NetBeans 6.9 fertig gestellt und veröffentlicht. Eines der wichtigsten neuen Merkmale dürfte der nun standardmäßig integrierte JavaFX Composer sein, mit dem sich Formulare und Grafiken für JavaFX 1.3 visuell erstellen lassen:

Mal abwarten, wie sich der GUI-Editor in der Praxis bewährt. Aber die ersten Versuche sehen recht vielversprechend aus.

Im Bereich "Java EE" ist die Unterstützung für den JSR-299 (CDI) sowie für Spring 3.0 erwähnenswert. Außerdem ist der Application Server GlassFish in der Version 3.0.1 integriert.

JavaFX 1.3

2010-05-31T11:37:00.008+02:00

Nur der Vollständigkeit halber... Bereits Ende letzten Monats hat Oracle/Sun JavaFX 1.3 veröffentlicht. Die wichtigsten Neuerungen sind

neue Controls (u.a. endlich eine ChoiceBox)
neue, brauchbare Layouts
bessere CSS-Unterstützung
bessere Performance und weniger Speicherverbrauch.

Beschreibungen und Zusammenfassungen der Änderungen und Neuerungen finden sich u.a. hier, hier und hier.

Wichtiger für die Akzeptanz von JavaFX ist m.E. aber, dass mit der Beta-Version von NetBeans 6.9 der JavaFX Composer mitgeliefert wird, mit dem Benutzeroberflächen (GUIs) – sowohl Masken als auch Grafiken – visuell zusammengestellt werden können.

Die Migration bestehender Java FX 1.2-Anwendungen auf die neue Version ist hier beschrieben.

Hibernate 3.5 mit JPA 2.0 und Envers

2010-04-20T22:10:00.013+02:00

Einige Wochen war es ruhig in diesem Blog, aber mit der Veröffentlichung unseres aktuellen Projekts Klaas 1.0 hatten wir alle Hände voll zu tun :-)

In der Zwischenzeit wurde nach vielen Monaten der Entwicklung Ende März endlich Hibernate 3.5 fertiggestellt. Mittlerweile steht sogar schon das erste Bugfix-Release Hibernate 3.5.1 zur Verfügung.

JPA 2.0 wird nun vollständig unterstützt, und mit Envers ist eine Bibliothek zur automatischen temporalen Datenhaltung (Historisierung bzw. Versionierung) enthalten. Außerdem wurde die Abhängigkeitsverwaltung der Hibernate-Teilprojekte vereinfacht, denn aufeinander abgestimmte Versionen der Hibernate-Annotationen, des Hibernate-EntityManagers und von Envers sind nun im Hibernate-Core-JAR enthalten.

Closures in JavaScript

2010-02-26T10:51:00.005+01:00

Nachdem ich schon Beispiele für Closures (Funktionsabschlüsse) in JavaFX und Scala vorgestellt hatte, schauen wir uns dasselbe Beispiel in JavaScript (ECMAScript) an:

// closures.js

function zaehlerMitStartwert(startwert) {
  return function() {
    return startwert++
  }
}

next1 = zaehlerMitStartwert(10)
next2 = zaehlerMitStartwert(20)

document.writeln( next1() )   // 10
document.writeln( next2() )   // 20
document.writeln( next2() )   // 21
document.writeln( next1() )   // 11

Sehr viel mehr gibt es dazu eigentlich nicht zu sagen, außer dass es

wirklich so einfach ist (was auch zu Problemen führen kann)
schon seit den ersten JavaScript-Versionen (und damit seit über 10 Jahren) zur Verfügung steht und
im Gegensatz zu JavaFX Script und Scala dynamisch typisiert ist; zudem ist keine zusätzliche lokale Variable nötig, weil der Übergabeparameter startwert bereits eine veränderbare Variable ist. Beides ist im Hinblick auf stabile, wartbare Software nicht unbedingt als positiv zu bewerten.

Viele moderne JavaScript-Bibliotheken machen starken Gebrauch von solchen Funktionsliteralen und Closures, beispielsweise jQuery.

Hibernate/JPA, hashCode() und Eclipse

2010-02-16T18:40:00.006+01:00

Entitäten in Hibernate/JPA haben oft einen synthetischen (technischen) Primärschlüssel, der im folgenden Beispiel als Long id implementiert wird. Sofern es keine zusätzlichen fachlichen Schlüsselkandidaten gibt, muss man die hashCode()-Methode für Hibernate/JPA so implementieren, dass sie ausschließlich mit dieser Id arbeitet. (Es gibt auf hibernate.org eine lange Diskussion zu diesem Thema, denn die "offiziell" vorgeschlagene Variante, "halb-eindeutige" Felder zu verwenden, macht in der Praxis meistens mehr Probleme als die Id-Variante.)

Damit man hashCode() (und das zwingend dazu gehörende equals()) nicht immer wieder von Hand neu schreiben muss, bietet Eclipse über Source > Generate hashCode() and equals() die Möglichkeit, die beiden Methoden mit wählbaren Attributen zu generieren. Eine Beispiel-Entität könnte dann wie folgt aussehen:

@Entity
public class Datensatz {

  @Id @GeneratedValue
  private Long id;

  // weitere Felder, Getter, Setter, equals() etc. ...

  /**
   * Von Eclipse 3.5 generiert.
   */
  @Override
  public int hashCode() {
    final int prime = 31;
    int result = 1;
    result = prime * result
              + ((id == null) ? 0 : id.hashCode());
    return result;
  }
}

An sich liefert die Hashwert-Berechnung mittels Primzahlen eine gute Streuung, und der automatisch generierte Code beachtet auch, dass die Id null sein kann – nämlich bei noch nicht in der Datenbank gespeicherten (persistierten) Objekten.

Nun testen wir diese Entity-Klasse:

@Test
public void testAddToHashSet() {

  Set<Datensatz> menge = new HashSet<Datensatz>();

  Datensatz ds1 = new Datensatz();
  Datensatz ds2 = new Datensatz();

  assertTrue("Menge sollte leer sein", menge.isEmpty());

  menge.add(ds1);

  assertTrue("Menge sollte ein Element besitzen",
             menge.size() == 1);
  // ok

  menge.add(ds2);

  assertTrue("Menge sollte zwei Elemente besitzen",
             menge.size() == 2);
  // immer noch 1... Ups!?!
}

Immer, wenn man Assoziationen im Objekt-Modell aufbaut, bevor die Datensätze gespeichert sind (also z.B. bei Unit-Tests wie im obigen Beispiel), tritt das gezeigte Szenario auf. Wir haben hier zwei Objekte, die beide keine Id (=null) besitzen. Es sind aber trotzdem zwei nicht identische Objekte in separaten Speicherbereichen, die beim Persistieren entsprechend zwei Datensätze mit unterschiedlichen Primärschlüsseln (Ids) erzeugen würden. Leider kann sich das HashSet nur eines der beiden Objekte merken – und auch beim Persistieren einer Assoziation ginge so eines der Objekte verloren!

Eine Anpassung der generierten hashCode()-Methode ist denkbar einfach. Statt bei einer nicht vorhandenen Id die Zahl 0 für die Hashwert-Berechnung zu verwenden, nehmen wir den Hashwert des Objekts, der bei nicht identischen Objekten in den allermeisten Fällen unterschiedlich ist:

@Override
public int hashCode() {
  final int prime = 31;
  int result = 1;
  result = prime * result
     + ((id == null) ? super.hashCode() : id.hashCode());
  return result;
}

Eine vergleichbare Implementierung nutze ich seit Jahren ohne Probleme, weshalb ich diese Variante pauschal für die praktikabelste halte. In Einzelfällen mögen natürlich speziellere Implementierungen sinnvoller sein.

HTML-Accesskey mit CSS darstellen

2010-02-03T21:43:00.003+01:00

Mit dem Standard-HTML-Attribut accesskey lassen sich Tastaturkürzel (Shortcuts) definieren, mit denen man den Eingabefokus auf die zugehörigen Eingabeelemente setzen kann:

<label for="nachname" accesskey="n">Nachname:</label>
<input id="nachname" type="text">

Mit welcher Tastenkombination der Fokus gesetzt wird, ist browser- und systemabhängig. Obiges Kürzel aktiviert man im IE/Win mit Alt+N, im Firefox/Win mit Shift+Alt+N, im Firefox/Mac mit Ctrl+N, in Safari/Mac mit Ctrl+Alt+N...

Natürlich sollte man dem Anwender auch anzeigen, dass Tastaturkürzel vorhanden sind. Man kann diese Information zwar noch einmal statisch in den HTML-Quelltext schreiben (zusätzlich zum accesskey-Attribut). Mit einer einfachen CSS2-Regel kann man aber auf solche redundanten Angaben verzichten und die Kürzel an allen label-Elementen darstellen lassen, bei denen accesskey gesetzt ist:


label[accesskey]:after {
  content: " [" attr(accesskey) "]";
  text-transform: uppercase;
  color: #999999;
  font-size: x-small;
}

Die CSS-Regel basiert vor allem auf einem Attribut-Selektor und einem Pseudo-Element. Dadurch wird nach (:after) jedem label-Element, bei dem das accesskey-Attribut vorhanden ist, der Wert des Attributs in Großschreibung (uppercase) in den Dokument-Inhalt (content) eingefügt:

An sich sind diese Techniken recht alt, die entsprechenden Standards wurden schon vor Jahren offiziell verabschiedet (die HTML 4.01-Spezifikation ist über 10 Jahre alt, CSS 2 ebenso). Was macht dieses Thema wieder aktuell?

Google hat vor kurzem angekündigt, ab dem 1. März dieses Jahres ältere Browser-Versionen und insbesondere den Internet Explorer 6 (IE6) nicht mehr in seinen Web-Anwendungen zu unterstützen.
Dieser – eigentlich längst überfällige – Schritt dürfte auch andere Anbieter dazu bewegen, neuere IE-Versionen (oder Alternativen wie Firefox) vorauszusetzen. Und dann könnten auch endlich IE-Nutzer von Web-Standards wie den Attribut-Selektoren profitieren, die der IE6 leider seit Jahren ignoriert.

Closures in Scala

2010-01-31T13:24:00.010+01:00

Als funktionale Sprache unterstützt Scala Funktionen höherer Ordnung (first-class functions) und Funktionsabschlüsse (Closures). In dem Beitrag über Closures in JavaFXScript hatte ich bereits gezeigt, wie dort Closures definiert und genutzt werden. Wie programmiert man nun Closures in Scala?

// closures1.scala

def zaehlerMitStartwert(startwert: Int): (() => Int)  = {
  var n = startwert
  def nplus1(): Int = { n=n+1; n }
  nplus1
}

val next1 = zaehlerMitStartwert(10)
val next2 = zaehlerMitStartwert(20)

println( next1() )
println( next2() )
println( next2() )
println( next1() )

Wir definieren eine Funktion zaehlerMitStartwert(), die den Startwert als Int-Parameter übergeben bekommt. Rückgabe dieser Funktion ist eine Funktion, die keine Parameter hat, aber einen Int-Wert zurückgibt.

Innerhalb der äußeren Funktion legen wir eine Zählvariable n an, da der Übergabeparameter startwert unveränderlich ist. Dann definieren wir eine verschachtelte Funktion nplus1(), die auf die Zählvariable n eins draufzählt und als letzten Ausdruck der Funktion das hochgezählte n zurückgibt. Hier findet der Funktionsabschluss statt - das Binden der Variablen n, die als lokale Variable in der umgebenden Funktion definiert ist. Als letzten Ausdruck in der äußeren Funktion geben wir die Funktion nplus1 als Ergebnis zurück.

Das ganze geht auch etwas kürzer und "funktionaler", wenn man die innere Funktion nicht explizit definiert, sondern als letzten Ausdruck der äußeren Funktion gleich ein entsprechendes Funktionsliteral hinschreibt:

// closures2.scala

def zaehlerMitStartwert(startwert: Int) = {
  var n = startwert
  () => { n=n+1; n }
}

val next1 = zaehlerMitStartwert(10)
val next2 = zaehlerMitStartwert(20)

println( next1() )
println( next2() )
println( next2() )
println( next1() )

Beide Skripte liefern dieselbe Ausgabe:

HeartOfGold:~ much$ scala closures2.scala
11
21
22
12

Wenn man den Scala-Interpreter mit scala -savecompiled closures2.scala aufruft, erhält man ein JAR-Archiv, in dem man sich die generierten Java-Bytecode-Dateien anschauen kann. In diesem Fall werden vier class-Dateien erzeugt.

Scala-Servlets

2009-12-27T11:57:00.005+01:00

Ein schönes Beispiel dafür, wie sich gewohnte Java-Programmierung in Scala "anfühlt", sind Servlets:

package com.muchsoft.scala.servlets

import javax.servlet.http.HttpServlet
import javax.servlet.http.{HttpServletRequest => Request,
                           HttpServletResponse => Response}

class MeinErstesScalaServlet extends HttpServlet {

  override def doGet(request: Request, response: Response) {

    val ausgabe =
      <html>
        <head><title>Hallo Scala</title></head>
        <body>
          <h1>Hallo Scala-Welt!</h1>
        </body>
      </html>

    response.getWriter().print(ausgabe)
  }
}

Das sieht doch fast wie Java aus, oder? Nicht ganz: Beim Import können wir Umdefinitionen vornehmen, das override vor der Methodendefinition ist zwingend notwendig, zudem ein Schlüsselwort und keine Annotation. Der Rückgabetyp der Methode doGet() ist nicht angegeben und entspricht dadurch dem Java-void. Für Scala hätten wir vor die öffnende geschweifte Methodenklammer :Unit= schreiben können.

Innerhalb von doGet() legen wir das XML-Literal ausgabe an (als nicht änderbaren Wert mit val; mit var angelegte Variablen versucht man in funktionalen Sprachen zu vermeiden). Dieses XML-Literal schreiben wir ganz normal in den Ausgabestrom des Response-Objekts. Der Typ von ausgabe ist scala.xml.Elem.

Die Struktur der Web-Applikation entspricht dem JavaEE-Standard:

Der vom Scala-Compiler erzeugte Java-Bytecode landet in WEB-INF/classes. Die Scala-Standardbibliothek scala-library.jar (aus dem Scala-Installationsverzeichnis) muss in WEB-INF/lib mit ausgeliefert werden. In WEB-INF/web.xml mappen wir die Klasse com.muchsoft.scala.servlets.MeinErstesScalaServlet auf die URL "hallo.scala". Nach dem Bereitstellen (Deployment) z.B. in Tomcat oder GlassFish kann das Servlet im Web-Browser dann mit der URL http://localhost:8080/halloscala/hallo.scala aufgerufen werden.

Zum Übersetzen der Servlet-Klasse muss sich noch die Servlet-API auf dem Build-Path (Classpath) befinden. Dazu kann man z.B. aus dem Tomcat-Installationsverzeichnis servlet-api.jar oder aus dem GlassFish-Verzeichnis javaee.jar als externe Bibliothek einbinden.

Nun verbessern wir das erste Scala-Servlet und trennen Darstellung und Steuerung etwas besser voneinander:

class MeinZweitesScalaServlet extends HttpServlet {

  def ausgabe =
    <html>
      <head><title>Hallo Scala</title></head>
      <body>
        <h1>Hallo Scala-Welt!</h1>
        <p>Zeit auf dem Server: {jetzt} </p>
      </body>
    </html>

  def jetzt = new java.util.Date

  override def doGet(request: Request, response: Response) {
    response.getWriter().print(ausgabe)
  }
}

ausgabe ist nun eine Funktion außerhalb von doGet(), die auf die Funktion jetzt zurückgreift, um einen aktuellen Zeitstempel auszugeben. Beide Funktionen sind ohne Parameterklammern definiert und müssen daher ohne Klammern aufgerufen werden. Hätten wir die Funktionen mit leeren Parameterklammern definiert, hätten wir es uns beim Aufruf aussuchen können, ob wir die Klammern hinschreiben oder nicht. Es hat sich die Konvention herausgebildet, die Klammern bei der Definition wegzulassen, wenn eine Funktion keine Nebenwirkungen (Seiteneffekte) hat.

Für eine "vollständige" Web-Applikation fehlt noch ein Formular. Bitteschön:

class MeinDrittesScalaServlet extends HttpServlet {
 
  def ausgabe(benutzername: String) =
    <html>
      <head><title>Hallo Scala-Welt</title></head>
      <body>
        <h1>Hallo {benutzername}</h1>
        <p>Zeit auf dem Server: {jetzt}</p>
        <form method="GET" action="hallo3.scala">
          <p>Wie heißt Du?
          <input name="benutzer" />
          <input type="submit" value="Abschicken" />
          </p>
        </form>
      </body>
    </html>

  def jetzt = new java.util.Date

  override def doGet(request: Request, response: Response) {
 
    val param = request getParameter "benutzer"

    val benutzername =
      if ((param == null) || (param.isEmpty))
        "Scala"
      else
        param capitalize

    val antwort = ausgabe(benutzername)

    response.getWriter().print(antwort)
  }
}

ausgabe() bekommt nun einen String-Parameter übergeben, der in doGet() anhand des Request-Parameters "benutzer" ermittelt wird. Statt des ?:-Operators von Java, den es in Scala nicht gibt, verwenden wir ein besser lesbares if-else, das in Scala ein Ausdruck ist und entsprechend ein Ergebnis liefert.

Wenn diese dritte Servlet-Klasse in web.xml auf die URL "hallo3.scala" gemappt wird, kann der Aufruf im lokalen Applikations-Server mit http://localhost:8080/halloscala/hallo3.scala?benutzer=Thomas erfolgen.

In der Praxis wird man Servlets wohl eher nicht direkt programmieren, sondern ein Framework wie Struts, JSF, Wicket o.ä. einsetzen. Man sieht hier aber gut, wie problemlos man Scala in bestehende Java-(Web-)Anwendungen integrieren kann. Und wenn man Web-Applikationen so richtig funktional entwickeln möchte, kann man das Scala-Lift-Framework nutzen.

ECMAScript 5

2009-12-12T19:26:00.007+01:00

Bis vor ein paar Jahren musste man regelmäßig darauf hinweisen, dass Java nicht JavaScript ist, und JavaScript wurde als Programmiersprache – trotz Objektbasierung und funktionaler Aspekte – nicht ernst genommen. Mit Web 2.0 und Ajax ist dies seit einiger Zeit definitiv anders. JavaScript ist im Frontend akzeptiert, und es gibt keine ernsthaften Diskussionen mehr, ob man es im Browser deaktivieren soll. RIA kommt ohne JavaScript nicht aus.

Vor einer Woche wurde nun die Spezifikation von ECMAScript 5, dem offiziellen Standard für JavaScript, freigegeben. Die neue ECMAScript-Version wurde ziemlich genau zehn Jahre nach der letzten Version, ECMAScript 3, veröffentlicht (Version 4 wurde ausgelassen). Neben vielen kleinen Verbesserungen und einem "strict"-Modus ist nun auch JSON im Standard enthalten. Mit diesem Datenformat können JavaScript-Objekte kompakt durch das Netz übertragen werden.

Für mich ist ECMAScript insofern interessant, als es nun über zehn Jahre her ist, dass ich für den Web-Browser iCab eine JavaScript-Engine (Interpreter) zunächst auf Basis von ECMAScript 2, nach 1999 dann aufbauend auf ECMAScript 3 entwickelt hatte. iCab hat seine Rendering Engine (und damit auch die JavaScript-Laufzeitumgebung) zwar mittlerweile auf Apples WebKit umgestellt, aber die Implementierung einer so zentralen Browser-Komponente gab einen tollen Einblick hinter die technischen Kulissen auf das, wie das Web bis (und gerade) heute funktioniert.

Wie die Zeit vergeht...

Hallo Java EE 6!

2009-12-10T18:49:00.004+01:00

Dreieinhalb Jahre nach Java EE 5 hat Sun heute die endgültige Spezifikation von Java EE 6 freigegeben. Bestandteil davon sind u.a. die Spezifikationen von EJB 3.1, JPA 2.0 und JSF 2.0.

Der Download des Java EE 6 SDK enthält den Application Server GlassFish v3 als Referenzimplementation (neben Beispielen samt Dokumentation).

Ebenfalls verfügbar ist die an JEE 6 und GlassFish v3 angepasste Entwicklungsumgebung NetBeans 6.8. Eclipse-Anwender finden hier das entsprechende Plugin.

Wer bereits jetzt Java-Enterprise-Projekte auf Basis von JEE 5 entwickelt, dem dürfte die Umstellung auf die neue Version nicht allzu schwer fallen – sofern der eingesetzte Application Server kompatibel zur neuen Spezifikation ist.

Eine dreiteilige Einführung in Java EE 6 hat Sun hier veröffentlicht.

Eclipse 3.5 Galileo, Software-Updates und Proxy-Verbindungen

2009-12-08T20:47:00.007+01:00

Je nach Netzwerkumgebung gibt es mit Eclipse immer wieder Probleme beim Installieren von Plugins (über das Menü Help > Install New Software...) bzw. beim automatischen Aktualisieren bereits installierter Erweiterungen (über Help > Check for Updates). Grund sind meistens Proxies, die von Eclipse nicht unterstützte Protokolle verwenden, sowie Firewalls, die eigene Zertifikate für https-Verbindungen ausgeben.

Sofern man das Zertifikat der Firewall besitzt (eine Datei üblicherweise mit der Endung *.cer), kann man dieses in den Keystore der Java-Installation importieren. Welche Java-Installation von Eclipse verwendet wird, kann man unter About Eclipse > Installation Details > Configuration herausfinden. Unter Windows lautet der Aufruf des keytool-Kommandozeilenbefehls beispielsweise

C:\Programme\Java\jre6\bin\keytool -import -v
   -file PfadZumZertifikat
   -keystore C:\Programme\Java\jre6\lib\security\cacerts
Geben Sie das Keystore-Passwort ein: changeit

"changeit" ist das Standard-Passwort des KeyStores, sofern Sie es nicht geändert haben.

Ein anderes Problem stellen NTLMv2-Proxy-Server dar, die seit Eclipse 3.5 nicht mehr direkt unterstützt werden. Neben der korrekten Einrichtung der Proxy-Adresse und der Authentifizierungsdaten unter Preferences > General > Network Connections muss in der Datei eclipse.ini (im Eclipse-Programmverzeichnis) am Ende folgende Zeile hinzugefügt werden:

-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient

In Eclipse 3.5 war es in der o.g. Preferences-Seite zudem notwendig, den "Active Provider" auf "Native" zu stellen. In Eclipse 3.5.1 funktioniert auch die Einstellung "Manual".

Scala-Code als und in einer Java-Anwendung ausführen

2009-11-16T08:51:00.006+01:00

Compilierter Scala-Bytecode lässt sich problemlos in bestehende Java-Anwendungen integrieren. Möglich ist dies, weil der Scala-Compiler ganz normalen Java-Bytecode erzeugt. Als Laufzeitumgebung sollte dabei Java 5.0 oder neuer zum Einsatz kommen.

Dazu wird eine Scala-Installation benötigt. Am besten nimmt man den IzPack-Installer. Das Installationsverzeichnis heißt im folgenden Beispiel "scala-2.7.7".

object HalloScalaWelt extends Application {
  println("Hallo Scala!")
}

Dieses ausführbare Singleton-Objekt speichert man als Datei "HalloScalaWelt.scala", die nun übersetzt und ausgeführt wird:

HeartOfGold:~ much$ scalac HalloScalaWelt.scala
HeartOfGold:~ much$ ls Hallo*.class
HalloScalaWelt$.class    HalloScalaWelt.class
HeartOfGold:~ much$ scala HalloScalaWelt
Hallo Scala!

Bereits jedem Java-Einsteiger sollten diese Kommandos irgendwie bekannt vorkommen. Entsprechend führen wir die erzeugten class-Dateien ganz einfach als Java-Anwendung aus:

HeartOfGold:~ much$
  java -cp scala-2.7.7/lib/scala-library.jar:. HalloScalaWelt
Hallo Scala!

Unter Windows gibt man beim Klassenpfad (Option -cp oder -classpath) vor dem Punkt am Ende (= aktuelles Verzeichnis) ein Semikolon anstelle des Doppelpunkts an.

Ebenso einfach kann man Scala-Code in bestehende Java-Anwendungen integrieren. Man übernimmt einfach die compilierten class-Dateien und setzt scala-library.jar auf den Klassenpfad – fertig!

Die Benutzung von Klassen zwischen Java und Scala besteht meistens ganz einfach darin, wie gewohnt den (vollqualifizierten oder importierten) Klassennamen zu verwenden.

Java ME SDK 3.0 für Mac OS X

2009-11-13T08:19:00.002+01:00

Die Entwicklung von Applikationen für Java ME, der Java-Plattform für mobile Geräte, war unter Mac OS X ein eher schwieriges Thema. Wichtige Bestandteile des SDKs fehlten oder wurden nicht offiziell unterstützt (Anleitungen für "inoffizielle" Lösungen gibt es z.B. hier, hier oder hier).

Vor drei Wochen hat Sun nun endlich das Java ME SDK 3.0 als Early Access (EA) für Mac OS X 10.5.8 und neuer veröffentlicht. Das DMG enthält das komplette SDK als eine Applikation, die einfach per Drag&Drop in den Programme-Ordner installiert wird.

Die SDK-Entwicklungsumgebung basiert auf der NetBeans-Plattform und ermöglicht erstmalig CLDC-Entwicklung auf Mac OS X. Enthalten ist außerdem der JavaFX 1.2.1 Mobile Emulator.

VisualVM 1.2

2009-11-13T08:05:00.006+01:00

Nachdem im Oktober Version 1.2 des Monitoring- und Profiling-Werkzeugs VisualVM veröffentlicht wurde, folgte Anfang dieser Woche das Bugfix-Release 1.2.1. Beide Versionen basieren auf dem Profiler von NetBeans 6.7.1.

Neu ist u.a. die stabile Version des "Sampler"-Plugins, mit dem schnell ein einfaches (aber oft schon vollkommen ausreichendes) CPU- und Speicher-Profiling durchgeführt werden kann. Wie die übrigens Plugins muss auch dieses im Menü Tools > Plugins installiert werden:

Außerdem kann man nun endlich eventuell notwendige Proxy-Einstellungen innerhalb von VisualVM vornehmen. Weitere Änderungen und Ergänzungen sind hier aufgelistet.

Java EE SDK unter Snow Leopard installieren

2009-11-03T07:58:00.001+01:00

Mac OS X 10.6 "Snow Leopard" enthält Java SE 6 als einzige Java-Laufzeitumgebung (und nicht mehr Java 1.4, 5.0 und 6 wie Mac OS X 10.5). Das bringt ein Problem mit sich, wenn man Suns aktuelles Java EE 5 SDK Update 7 installieren möchte, denn das Installationsskript ist fest verdrahtet auf ein installiertes Java 5 angewiesen. Im System sind zwar die Ordner für Java 5.0 vorhanden, die verweisen aber auf die Java 6-Installation – und das reicht dem Skript leider nicht aus.

Im konkreten Fall haben wir das Archiv java_ee_sdk-5_07-mac-nojdk.zip (Download "GlassFish Java EE") ausgepackt und zu installieren versucht:

HeartOfGold:java_ee_sdk-5_07-mac-nojdk much$ chmod a+rx setup
HeartOfGold:java_ee_sdk-5_07-mac-nojdk much$ ./setup
Installer cannot find a suitable 1.5.x version of JDK under the
following directories.

1. /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
2. /Library/Java/Home

Please rerun with -javahome argument pointing to a valid 1.5 version of JDK.

Zum Glück ist die Lösung recht einfach (man muss dafür kein altes Java 5.0 aus Mac OS X 10.5 installieren). In der Skript-Datei setup ersetzt man mit einem Texteditor in Zeile 54 einfach am Ende der Zeile "1.5" durch "1.6":

54: javaVersion=`${TIGER_JAVAHOME} ... ${GREP} 1.6`

Das war es dann auch schon! Der Installer lässt sich nun auch mit Java 6 problemlos ausführen, und GlassFish läuft auch (bzw. gerade) mit dem aktuellen JRE hervorragend.

IntelliJ IDEA 9: Community Edition und Open Source

2009-10-15T19:57:00.001+02:00

Die Entwicklungsumgebung IntelliJ IDEA ist seit längerem der Geheimtipp für Java-Entwickler. Doch während Eclipse und NetBeans kostenlos erhältlich und weit verbreitet sind, schreckten viele vor dem dreistelligen Kaufpreis für eine IDE(A) zurück.

Mit der kommenden Version 9.0 wird IntelliJ IDEA nun Open Source und steht seit heute auch in einer kostenlosen Community Edition zur Verfügung. Mit dieser Edition kann Java SE, Groovy und Scala programmiert werden (inkl. Debugging, Refactoring, Testen, Versionsverwaltung etc.).

Für die Entwicklung von Web- und Enterprise-Applikationen wird die weiterhin kostenpflichtige Ultimate Edition benötigt, die neben aktuellen und künftigen Standards (Java EE 6 etc.) zahlreiche Programmiersprachen, Frameworks und Versionsverwaltungssysteme zusätzlich unterstützt.

Fazit: Für professionelle JEE-Entwicklung ist zwar nach wie vor die kostenpflichtige Ultimate Edition notwendig, aber zumindest kann sich nun jeder einen ausführlichen Eindruck von IntelliJ verschaffen. Und das hat diese Entwicklungsumgebung durchaus verdient.

Snow Leopard und Rosetta

2009-10-13T21:52:00.002+02:00

Schon seit den ersten Mac OS X-Versionen können Java-Applikationen in einer speziellen Verzeichnisstruktur als "normale" Mac OS X-Anwendung verpackt werden, so dass sie u.a. mit einem eigenen Programmsymbol dargestellt werden. Damit solche Application Bundles Java-Bytecode ausführen können, enthalten sie als nativen Mach-O-Startcode im Verzeichnis /Contents/MacOS/ die Datei JavaApplicationStub:

Führt man ältere, noch unter PowerPC (PPC) Mac OS X zusammengebaute Java-Application-Bundles unter Mac OS X 10.6 "Snow Leopard" aus, erhält man eventuell den Hinweis, dass man den auf der Snow-Leopard-Installations-DVD enthaltenen PPC-Emulator "Rosetta" installieren muss, um die Anwendung starten zu können. Obwohl Apple seit Mac OS X 10.4 alte PPC-JavaApplicationStubs erkennt und als 32-Bit-Intel-Prozess neu startet, muss dafür Rosetta installiert sein – und genau das ist seit Snow Leopard nicht mehr standardmäßig der Fall.

Die einfachste Lösung, die zudem Rosetta nicht benötigt, ist, den alten Stub im Application Bundle durch eine Kopie der aktuelle Version /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub zu ersetzen. Dieser neue Stub enthält Code für die drei derzeit unterstützten Prozessorarchitekturen:

Straylight:~ much$ file JavaApplicationStub
JavaApplicationStub: Mach-O universal binary with 3 architectures
JavaApplicationStub (for architecture x86_64):  Mach-O 64-bit executable x86_64
JavaApplicationStub (for architecture i386):    Mach-O executable i386
JavaApplicationStub (for architecture ppc7400): Mach-O executable ppc

Wenn eine Java-Anwendung eine bestimmte Architektur nicht benötigt (z.B. weil nachgeladene JNI-Bibliotheken dafür nicht compiliert wurden), kann und sollte der entsprechende Code mit /usr/bin/lipo entfernt werden.

Java in Mac OS X 10.6 "Snow Leopard"

2009-09-01T22:03:00.003+02:00

Der Schneeleopard ist also aus dem Käfig... Und während das nun "alte" Mac OS X 10.5 noch drei Implementierungen für Java 1.4, 5.0 und 6 mitbrachte, enthält Mac OS X 10.6 ausschließlich Java SE 6 (1.6.0_15) in einer 32-Bit- und einer 64-Bit-Version. Detaillierte Informationen zu beseitigten und bekannten Fehlern enthalten die Release Notes.

Damit auch Java 5-Anwendungen weitestgehend problemlos laufen, sind im Ordner /System/Library/Frameworks/JavaVM.framework/Versions noch die Unterordner 1.5 und 1.5.0 enthalten, aber beide sind Aliase (Symlinks) auf die Java 6-Implementierung.

Und obwohl QuickTime for Java schon seit längerem nicht mehr offiziell unterstützt wird, sind die QTJava-Bibliotheken immer noch vorhanden und funktionieren auch mit Java 6.

Mal abwarten, was die praktischen Erfahrungen in den kommenden Tagen zeigen.

Closures in JavaFX Script

2009-08-26T19:44:00.004+02:00

JavaFX Script (die Programmiersprache für Suns neue RIA-Technologie JavaFX) ist eine objektorientierte, deklarative und funktionale Programmiersprache.

Als funktionale Sprache unterstützt sie Funktionen höherer Ordnung (first-class functions) und Funktionsabschlüsse (Closures). Ersteres bedeutet, dass Funktionen selber Werte sind – sie können also als Parameter übergeben und zurückgegeben werden. Letzteres erlaubt den Funktionswerten, dass sie sich den Zustand ihrer Umgebung (die lokalen Variablen) bei ihrer Erzeugung merken können.

Für viele sind Closures seltsame Konstrukte und ihre Einsatzmöglichkeiten nicht offensichtlich. Daher im Folgenden ein kleines, relativ leicht verständliches Beispiel, in dem mehrere Zähler mit individuellen Startwerten erzeugt und benutzt werden:

// closure.fx

function zaehlerMitStartwert(startwert: Integer) {
  var n = startwert;
  return function(): Integer { return n++ }
}

var next1 = zaehlerMitStartwert(10);
var next2 = zaehlerMitStartwert(20);

println( next1() ); // 10
println( next2() ); // 20
println( next2() ); // 21
println( next1() ); // 11

Wer das Beispiel ausprobieren möchte, installiert sich das JavaFX 1.2 SDK und nutzt die Kommandozeile (oder NetBeans oder Eclipse mit dem JavaFX-Plugin):

Straylight:~ much$ javafxc closure.fx
Straylight:~ much$ javafx closure
10
20
21
11

Die ausgegrauten Elemente sind nicht wirklich notwendig und sollen nur das Skript für Java-Programmierer leichter verständlich machen. "return" ist an beiden Stellen optional, da der letzte Ausdruck in einer Funktion gleichzeitig deren Ergebnis definiert. Der Rückgabetyp ":Integer" der inneren, anonymen Funktion ist optional, da aus dem Datentyp des Ergebnisses der Rückgabetyp durch Typinferenz ermittelt werden kann.

Trotz (bzw. gerade wegen) dieser impliziten Typisierung ist JavaFX Script im Gegensatz zu Skriptsprachen wie JavaScript statisch und streng typisiert. Bereits der Compiler ermittelt also die Datentypen und Signaturen von Variablen und Funktionen, sofern sie nicht explizit angegeben sind. Im Beispiel hat die Variable n also den Datentyp Integer, die Variablen next1 und next2 haben den Typ function():Integer und zaehlerMitStartwert hat den Typ function(:Integer):function():Integer :-)

Wie funktioniert das Skript? Beim Aufruf der Funktion zaehlerMitStartwert wird eine Funktion zurückgegeben, die bei jedem Aufruf die Variable n um eins erhöht zurückgibt. Obwohl die Variable n zur äußeren Funktion gehört und damit beim Aufruf der zurückgegebenen Funktion mit next1() bzw. next2() eigentlich gar nicht mehr vorhanden ist, merkt sich die innere Funktion die lokale Variable separat für jede zurückgegebene innere Funktion – und genau das macht sie zur Closure.

Man kann sich Closures als Objekte vorstellen, die aus einer einzigen Methode/Funktion bestehen und wie Objekte zusätzlich einen Zustand haben. Schön sehen kann man dies an den generierten Java-Bytecode-Klassendateien: closure.class und closure$1.class. Die innere, anonyme Funktion wird für die JVM also einfach als innere, anonyme Java-Klasse closure$1.class abgebildet.

Closures sind prima geeignet, um damit z.B. Event-Handler zu definieren, denen man zusätzliche Informationen mitgeben kann (bei Farb-Setz-Buttons in einem Grafikprogramm beispielsweise die zu setzende Farbe). Dadurch kann man häufig auf das Schreiben von Event-Handler-Klassen verzichten, auch wenn dies in JavaFX Script ebenfalls möglich ist.

Vielleicht hat man es gemerkt: Ich halte JavaFX Script trotz des Namens ganz und gar nicht für eine Skriptsprache. Meines Erachtens wurde die Sprache vor allem deshalb so genannt, um zu zeigen, dass man damit in Wettbewerb zu Skriptsprachen wie Ruby tritt, die als agil und produktiv empfunden werden. JavaFX Script zeigt dabei sehr schön, dass sich Produktivität und statische, strenge Typisierung überhaupt nicht ausschließen müssen.

Hibernate 3.5 und JPA 2.0

2009-08-25T20:35:00.005+02:00

Vor wenigen Tagen wurde die erste Betaversion von Hibernate 3.5 veröffentlicht. Sofern der Download von SourceForge klappt, kann man damit viele der Neuerungen von JPA 2.0 ausprobieren.

Hibernate 3.5 bietet keine wesentlichen neuen Hibernate-Features, und auch für die Unterstützung der neuen JPA-Version wurden vor allem standardkonforme Schnittstellen für bereits vorhandene Hibernate-Eigenschaften bereitgestellt. Dies ist wohl auch der Grund, warum die Hibernate-Version nicht gleich auf 4.0 heraufgesetzt wurde.

Schön ist meines Erachtens, dass ab Version 3.5 die JARs für die Hibernate-Annotationen und den JPA-EntityManager Bestandteil vom Hibernate-Kern (Core) geworden sind. Und die Einbindung von Envers dürfte diese Versionierungs-Bibliothek zum heißen Kandidaten für den De-Facto-Standard bezüglich Versionierung/Historisierung/Auditierung mit JPA machen.

Lokaler Aufruf von @Remote in GlassFish

2009-07-22T23:09:00.007+02:00

GlassFish muss als Java EE 5-konformer Application-Server beim Aufruf von EJB-@Remote-Interfaces die Übergabeparameter und Rückgabewerte kopieren (serialisieren). Der Aufruf erfolgt also mit Wert-Semantik ("pass-by-value"), selbst wenn der Aufrufer und die aufgerufene Session-Bean innerhalb derselben JVM laufen ("co-located") und der Aufruf damit prinzipiell lokal erfolgen könnte (durch Über-/Rückgabe von Referenzen, entsprechend "pass-by-reference" genannt).

Obwohl GlassFish den eigentlichen Remote-Aufruf bereits gut optimiert, wenn sich Aufrufer und aufgerufene Bean auf demselben Server befinden, kostet das Kopieren der Parameter Zeit und Speicher. Wenn die Parameter große Datenmengen beinhalten, kann es sich daher als Performanz-Optimierung lohnen, die Parameter des lokalen Remote-Aufrufs entgegen der Spezifikation als Referenz übergeben zu lassen. Man muss dann aber bedenken, dass Änderungen an den Parameterdaten – wie bei @Local-Aufrufen – an allen Stellen sichtbar sind, die eine Referenz darauf halten.

Aktivieren lässt sich der lokale Aufruf von @Remote-Methoden in GlassFish für eine komplette Enterprise-Applikation (EAR) im sun-application.xml-Deskriptor wie folgt:

<sun-application>
  <pass-by-reference>true</pass-by-reference>
</sun-application>

Oder für einzelne EJBs in sun-ejb-jar.xml:

<sun-ejb-jar>
  <enterprise-beans>
    <ejb>
      <pass-by-reference>true</pass-by-reference>
    </ejb>
  </enterprise-beans>
</sun-ejb-jar>

Achtung: Zumindest GlassFish 2.1 scheint einen Bug zu haben, dass die Einstellung in sun-application.xml ignoriert wird, wenn sich in einem EJB-Modul (EJB-JAR) kein sun-ejb-jar.xml befindet. Abhilfe: Einfach einen (abgesehen vom Wurzel-Element) leeren Deskriptor ergänzen.

Und nochmal Achtung: Offenbar klappt die Optimierung nur innerhalb einer Anwendung (EAR), nicht aber zwischen mehreren separaten Anwendungen bzw. EJB-Modulen auf demselben Server.

Warum will man überhaupt eine nicht standardkonforme Referenz-Übergabe aktivieren? Kann man nicht besser @Local-Interfaces verwenden, die die erwähnten Performanz-Vorteile sowieso mit sich bringen? Ja, man sollte @Local-Interfaces nach Möglichkeit bevorzugen.
Es gibt aber Fälle, bei denen man nicht schon bei der Programmierung entscheiden kann bzw. möchte, wie die Bean-Aufrufe durchgeführt werden, beispielsweise weil man sich die Option offen halten möchte, ob Frontend (WAR) und Backend (EJB-JAR) gemeinsam in einem EAR oder aber separat bereitgestellt ("deployed") werden. Im Quelltext wird man dann die @Remote-Variante programmieren, hat aber mit dem pass-by-reference-Schalter später per Konfiguration die Möglichkeit, die Aufrufart einfach und schnell umzustellen.

Sinnvoll erscheint dies vor allem dann, wenn man viele EJBs entfernt aufruft und alle Aufrufe auf einen Schlag optimieren will. Wenn man dagegen nur wenige EJBs entfernt nutzt oder nur einzelne Aufrufe optimieren möchte, kann man die Aufrufart – wenn auch mit etwas mehr Aufwand – über die Standard-XML-Deskriptoren ändern. Eine mögliche Realisierung ist hier beschrieben.

Sein oder !sein, das ist hier die Frage

2009-07-16T20:04:00.009+02:00

Echte C-Freaks werden mich dafür verachten, aber ich finde ausgeschriebene boolesche Operatoren wie not, and und or einfach lesbarer als !, && und || (und ja, ich habe jahrelang C und C++ programmiert und weiß, wovon ich rede). Ein Beispiel:

  if (!liste.isEmpty()) { ... }

  if (not(liste.isEmpty())) { ... }

M.E. ist das Ausrufungszeichen beim Durchsehen des Quelltextes viel zu leicht zu übersehen (und Code wird normalerweise viel häufiger gelesen als geschrieben).

Während beispielsweise die EL beide Schreibweisen erlaubt, kennt Java leider nur die Symbol-Operatoren. Was tun? Zumindest für den Präfix-Operator not kann man statische Methoden definieren, die sich dann mittels statischer Imports wie in obigem Beispiel nutzen lassen:

  public static boolean not(boolean bval) {
    return !bval;
  }

  public static Boolean not(Boolean bval) {
    if (bval == null) {
      return null;
    }
    else {
      return !bval;
    }
  }

(Den kompletten Quelltext gibt es hier.)

Nur: Muss man sich diese Methoden selber schreiben, oder gibt es dafür bereits fertige Bibliotheken? Im Netz habe ich leider nichts passendes gefunden.

java_home oder /Library/Java/Home?

2009-07-09T19:52:00.003+02:00

Es ist immer wieder eine spannende Frage, wie man in Mac OS X die Standard-Java-Version einstellt bzw. wie man die für eine bestimmte Anwendung "richtige" Java-Version herausbekommt. Mac OS X 10.5 unterstützt derzeit bis zu drei verschiedene Hauptversionen (1.4.2, 1.5.0, 1.6.0), teils als 32-Bit-, teils als 64-Bit-Variante.

Bisher konnten Anwender die bevorzugte Java-Version getrennt für Applets und für andere Anwendungen (Web Start, Kommandozeile) mit /Programme/Dienstprogramme/Java/Java-Einstellungen konfigurieren. Alternativ konnte man natürlich auch die Umgebungsvariable JAVA_HOME setzen oder sich auf den festen Pfad /Library/Java/Home verlassen. Und weil diese Möglichkeiten immer noch nicht bei allen Anwendungen funktionierten, verbogen die ganz Wagemutigen diverse Symlinks im JavaVM-Framework (was aber auch nicht immer klappte und zu diversen Fehlern führte).

Bevor wir uns um die empfohlene Lösung kümmern, hier zunächst eine Warnung: Basteln Sie niemals an den Symlinks in /System/Library/Frameworks/JavaVM.framework (und in Unterordnern davon) herum! Auch dann nicht, wenn Sie viele gutgemeinte Tipps finden, wie man Current und CurrentJDK verbiegen kann... Apple weist seit langem darauf hin, dass diese Symlinks interne Implementationsdetails sind, die sich jederzeit ändern können.

Mit dem aktuellen Java-Update für Mac OS X 10.5 liefert Apple nun ein Kommandozeilenprogramm aus, mit dem sich die Benutzereinstellungen aus /Programme/Dienstprogramme/Java-Einstellungen auslesen lassen (beachten Sie, dass der Java-Unterordner in dem Pfad mit diesem Update verschwunden ist):


HeartOfGold:~ much$ /usr/libexec/java_home
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home

Ein Aufruf mit der Option -h zeigt alle erlaubten Optionen an. Eine Liste aller verfügbaren JVMs – in der in den Java-Einstellungen festgelegten Reihenfolge – erhalten wir mit --verbose:


HeartOfGold:~ much$ /usr/libexec/java_home --verbose
Matching Java Virtual Machines (4):
1.5.0_19 (i386):   /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
1.6.0_13 (x86_64): /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
1.5.0_19 (x86_64): /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
1.4.2_21 (i386):   /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Home

Man kann auch ganz gezielt nach einer bestimmten Java-Version und/oder Prozessorarchitektur fragen:


HeartOfGold:~ much$ /usr/libexec/java_home --version 1.6 --arch x86_64
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home

Sofern die gewünschte JVM nicht vorhanden ist, erhält man eine Fehlermeldung und eine hoffentliche passende alternative JVM:


HeartOfGold:~ much$ /usr/libexec/java_home --version 1.6 --arch i386
Unable to find any JVMs matching architecture "i386".
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home

Zurück zur Ausgangsfrage. Wie finden wir damit z.B. in einem Shell-Skript die passende Java-Version für eine Anwendung? Apple empfiehlt folgendes Vorgehen:

Prüfen Sie, ob /usr/libexec/java_home vorhanden ist, übergeben Sie optional die gewünschte Java-Version und werten Sie die Rückgabe aus.
Wenn das nicht erfolgreich war, verwenden Sie als Java-Home-Verzeichnis fest kodiert (!) das Verzeichnis /System/Library/Frameworks/JavaVM.framework/Versions/1.X/Home, wobei Sie "1.X" durch die gewünschte Versionsnummer (1.4, 1.5, 1.6) ersetzen.
Sollte das Verzeichnis nicht existieren, verwenden Sie /Library/Java/Home (und beten, das alles klappt).

100% perfekt ist das m.E. zwar nicht, denn Punkt 2 geht schief, wenn das Verzeichnis für Java 6 existiert, Java 6 aber nicht ausgeführt werden kann (das betrifft vor allem 32-Bit CoreDuo-Macs). Aber immerhin hat Apple nun dokumentiert, wie man künftig – und in den meisten Fällen auch bisher – zum korrekten Ergebnis gelangt.

Und was ist mit der Umgebungsvariable JAVA_HOME? Offenbar werten diverse Systemprogramme (wie /usr/bin/java) nicht nur die Rückgabe von /usr/libexec/java_home aus, sondern auch den Wert von JAVA_HOME. Wenn sich die Werte unterscheiden, kann das zu unerwartetem Verhalten führen... Insofern sollte mittelfristig auf das Setzen von JAVA_HOME besser verzichtet werden.

Da sich aber kurzfristig viele Anwendungen noch auf die Umgebungsvariable JAVA_HOME verlassen, ist es derzeit m.E. am besten, die Variable auf die Java-Version zu setzen, die auch in den Java-Einstellungen an oberster Stelle steht (auch wenn das erst einmal doppelten Konfigurationsaufwand bedeutet). Das Setzen der Variablen geschieht am einfachsten mit RCEnvironment, wodurch die Variable sowohl Shell-Skripten als auch GUI-Anwendungen bekannt ist:

Eine ausführliche Diskussion rund um java_home findet sich auf Apples Java-Mailingliste.

VisualVM 1.1.1 im JDK

2009-06-04T17:15:00.001+02:00

Letzte Woche hat Sun das JDK 6 Update 14 veröffentlicht. Darin enthalten ist unter anderem die aktuelle Version 1.1.1 von VisualVM, dem Werkzeug für Monitoring und einfaches Profiling. Derzeit ist damit also kein separater Download mehr erforderlich, um die vielen kleinen Verbesserungen und Bugfixes gegenüber der Version 1.0.1 zu erhalten, die seit dem JDK 6 Update 11 mitgeliefert wurde.

Sun hat übrigens vor einigen Wochen einen Blog-Wettbewerb zu VisualVM gestartet, der noch bis zum 24. Juni läuft. Dieses Blog läuft allerdings außer Konkurrenz, da es nicht auf Englisch geschrieben ist...

NetBeans 6.7 im nächsten Monat

2009-05-31T20:41:00.004+02:00

Die JavaOne startet in nicht einmal zwei Tagen – ein prima Termin, um NetBeans 6.7 zu veröffentlichen, das sich derzeit noch im Beta-Stadium befindet.

Die neue Version von Suns Entwicklungsumgebung bietet viele Neuerungen und Verbesserungen, u.a. einen erweiterten Profiler, die Unterstützung von GlassFish v3 sowie die Integration von Suns Entwickler-Portal Kenai.

Für Entwickler, die NetBeans unter Mac OS X nutzen, wird dies ein besonders schönes Release. Das Projektfenster wurde an das native Aussehen des Systems angepasst und erinnert nun deutlich an Xcode:

@SuppressWarnings("unchecked")

2009-04-29T23:06:00.002+02:00

Seit Version 5.0 kennt Java das Konzept der Generics, mit denen u.a. Kollektionen mit Typen parametrisiert und typsicherer gemacht werden können.

Leider lassen sich damit nicht alle Stellen perfekt absichern – insbesondere bei Hibernate bzw. JPA wird man beim Ausführen von Abfragen (Queries) immer wieder auf "Type safety"-Compiler-Warnungen stoßen:

An sich ist das kein Problem, denn mit der bestehenden API gibt es für den Compiler keine sinnvolle Möglichkeit, vom Query-String auf den Ergebnis-Typ zu schließen. Und Entwicklungsumgebungen wie Eclipse bieten die einfache Lösung an, diese unumgängliche Warnung mit der @SuppressWarnings-Annotation zu unterdrücken.

Nur leider schreibt Eclipse die Annotation immer vor die umgebende Methode, was alle weiteren – vielleicht wichtigen – Typ-Warnungen in der Methode ebenfalls unterdrückt:

@SuppressWarnings("unchecked")
public List<Benutzer> findAllBenutzer() {
   Query q = session.createQuery("from Benutzer");
   return q.list();
}

Das muss nicht sein! Sehen wir uns dazu den Quelltext der @SuppressWarnings-Annotation an:

@Target({TYPE, FIELD, METHOD, PARAMETER,
          CONSTRUCTOR, LOCAL_VARIABLE})
@Retention(RetentionPolicy.SOURCE)
public @interface SuppressWarnings {

LOCAL_VARIABLE bedeutet, dass wir die Annotation auch an eine lokale Variablendeklaration schreiben dürfen. Wenn wir also in der Methode eine temporäre Variable einführen, können wir das Unterdrücken der Warnung auf die eine relevante Zeile beschränken:

public List<Benutzer> findAllBenutzer() {
   Query q = session.createQuery("from Benutzer");

   @SuppressWarnings("unchecked")
   List<Benutzer> alle = q.list();

   return alle;
}

Für die JPA-Query-Methoden getResultList() und getSingleResult() gilt dies entsprechend.

Oracle kauft Sun

2009-04-21T20:49:00.005+02:00

Nun ist es also geschehen: Sun wird verkauft, und nicht etwa an IBM (die Übernahmeverhandlungen waren erst kürzlich gescheitert), sondern an Oracle.

Was dies für die Java-Technologie und die diversen Sun-Java-Produkte konkret bedeutet, bleibt abzuwarten. Immerhin ist Java seit langem gut in bestehende Oracle-Produkte integriert und dürfte für Oracle auch weiterhin von strategischer Bedeutung sein.

Spannend wird es für Suns Application Server GlassFish, der sich seit über einem Jahr deutlich steigender Beliebtheit erfreut. Hier ist zu hoffen, dass Oracle das Potential dieses nun dritten Application Servers im Produktportfolio kennt und nutzt. Berechtigt ist diese Hoffnung allemal, schließlich hat Oracle TopLink Essentials als JPA-Referenzimplementation zu GlassFish beigesteuert.

Serialisierbarer ByteArrayOutputStream

2009-04-08T19:44:00.004+02:00

Ein typisches Problem in einer mehrschichtigen Web-Anwendung besteht darin, eine Datei (beispielsweise ein auf dem Server generiertes PDF-Dokument) zum Client/Web-Frontend zu übertragen (oder nach einem Datei-Upload entsprechend umgekehrt). Die einfache Lösung mit Streams schlägt fehl, sobald Sender und Empfänger nicht mehr lokal in derselben Java Virtual Machine laufen, sondern entfernt in verschiedenen JVMs. Die Streams müssten nun entweder entfernt aufrufbar (Remote) oder aber serialisierbar (Serializable) sein – beides sind sie nicht. Die Serialisierbarkeit ist standardmäßig nicht vorgesehen, da Streams geräteabhängig sind.

Eine einfache Lösung für das Versenden kleinerer Binärdateien (wenige hundert KB) macht den Standard-ByteArrayOutputStream serialisierbar, was kein Problem ist, da der ByteArrayOutputStream eine reine Java-Speicher-Implementierung und somit geräteunabhängig ist. Der Sender kann den Stream wie gewohnt mit write() füllen, und der Empfänger kann den Stream mit den üblichen Methoden auswerten. In einem Servlet kann man den Stream z.B. mit baos.writeTo(response.getOutputStream()) direkt zum Client schicken.

Für die Implementierung des serialisierbaren ByteArrayOutputStreams reicht es nicht aus, die neue Unterklasse das Serializable-Interface implementieren zu lassen. Man muss zusätzlich noch die Methoden writeObject() und readObject() implementieren, die den internen Stream-Puffer explizit serialisieren:


public class SerializableByteArrayOutputStream
       extends ByteArrayOutputStream
       implements Serializable {

  private void writeObject(ObjectOutputStream stream)
        throws IOException {
    stream.writeInt( count );
    stream.writeObject( buf );
  }

  private void readObject(ObjectInputStream stream)
        throws IOException, ClassNotFoundException {
    count = stream.readInt();
    buf = (byte[]) stream.readObject();
  }
}

Der vollständige Quelltext der Klasse
SerializableByteArrayOutputStream kann hier abgerufen werden.

Wer eine umfassendere Lösung sucht oder große Dateien übertragen muss, sollte sich die RMIIO-Bibliothek anschauen.

Proxy-Konfiguration für VisualVM

2009-04-01T20:59:00.004+02:00

Wenn man mit VisualVM in einem Netzwerk arbeitet, das über einen Proxy ans Internet angebunden ist, hat VisualVM Probleme mit dem Nachladen seiner Plugins – was schade ist, denn dadurch verschenkt man die Hälfte der Möglichkeiten.

Der Proxy kann leider nicht in VisualVM selbst konfiguriert werden, sondern muss mit Aufrufparametern übergeben werden:

visualvm -J-DproxyHost=mein.proxy.com -J-DproxyPort=1234

Aber Achtung: Dies sind nicht die üblichen Java-Proxy-Parameter http.proxyHost und http.proxyPort! Das "http." fehlt jeweils.

Außerdem scheint die Konfiguration mit dem im JDK 6 mitgelieferten VisualVM nicht zu funktionieren. Mit dem separat herunterladbaren VisualVM 1.1.1 klappt es aber wie gewünscht.

Scala ist auch eine Oper

2009-03-28T20:12:00.001+01:00

... aber natürlich vor allem eine funktionale, objektorientierte Programmiersprache für die Java Virtual Machine :-)

Scala hat das Zeug dazu, die nächste große Sprache nach bzw. neben Java zu werden. Viele Ausdrücke lassen sich in Scala einfacher und kürzer als in Java schreiben, dennoch bleibt die statische und starke Typisierung wie bei Java erhalten. Ein großes Plus ist zudem die nahtlose Integration mit den unzähligen bestehenden Java-Bibliotheken. Und Scala ist nicht wirklich neu und nur irgendwie gerade cool, sondern bereits acht Jahre alt und stabil.

Zum Einstieg verwendet man am besten Eclipse 3.4 (das "Classic"- oder "Java EE"-Paket). Ein JDK 5.0 oder neuer sollte bereits installiert sein. Nun fehlt nur noch das Scala-Plugin, das man in Eclipse im Menü Help > Software Updates... mit der Update-URL

http://www.scala-lang.org/scala-eclipse-plugin

herunterladen lässt.

Wechselt man in die Scala-Perspektive, kann man unter File > New ein neues "Scala Project" anlegen. Wie aus Java gewohnt legt man ein Paket an und in diesem Paket dann ein "Scala Object" (!). Richtig gelesen, Scala unterstützt nicht nur Klassen, sondern auch einzelne Objekte. Wenn wir dieses Objekt von Application erben lassen, entspricht das der main-Methode in Java:

Scala bietet Typinferenz, d.h. man muss beim Deklarieren einer Variablen nicht zwingend den Typ angeben, wenn Scala diesen aus dem Kontext eindeutig ableiten kann. Die Variable ist dann trotzdem zur Übersetzungszeit typsicher, man kann also keine inkompatiblen Werte zuweisen:

Wie bei funktionalen Sprachen üblich, liegt eine der Stärken in der Listenverarbeitung. Listen können mit einer Java-ähnlichen Syntax angelegt werden (es geht auch funktionaler, siehe erster Screenshot):
val früchte = List("Äpfel", "Birnen", "Orangen")Entweder kann man die Liste dann mit einer Java 5-ähnlichen for-each-Schleife ausgeben:
for (frucht <- früchte) { println(frucht) }Oder man nutzt ein anonymes Funktionsliteral, eine sogenannte Funktion höherer Ordnung, die man als Wert an die foreach-Methode der Liste übergibt:
früchte.foreach(f => println(f))Da man den Punktoperator beim Methodenaufruf weglassen darf und println nur ein Argument erwartet, geht das auch noch kürzer:
früchte foreach println
Und immer daran denken: Auch wenn das so langsam nach einer Skriptsprache aussieht (und tatsächlich ähnlich schnell programmiert werden kann), haben wir hierbei statische, starke, vom Compiler geprüfte Typisierung!

Soweit fürs Erste, das sollte als Appetitanreger reichen :-)

Monitoring und Profiling mit VisualVM

2009-03-25T21:07:00.001+01:00

Am Wochenende habe ich einen kleinen Vortrag über VisualVM gehalten. Dieses nützliche Werkzeug ist seit dem Update 7 fester Bestandteil des JDK 6. Es bietet gute Überwachungsmöglichkeiten für laufende Java-Anwendungen (sowohl lokal als auch auf entfernten Rechnern). Beim Profiling kann es zwar nicht ganz mit kommerziellen Lösungen mithalten, bietet aber dennoch für viele Situationen vollkommen ausreichende Auswertungen (z.B. die Aufrufstellen einer Methode).

VisualVM benötigt Java 6 als Laufzeitumgebung, kann aber Anwendungen schon ab Java 1.4 überwachen. Faustregel: Je neuer die Laufzeitumgebung des auszuwertenden Programms ist und je lokaler sie läuft, desto bessere Informationen liefert VisualVM.

Leider liefert Apple VisualVM auch mit dem neuesten Update ihrer Java SE 6-Implementation nicht mit. Sofern man dieses Update eingespielt hat, kann man VisualVM 1.1.1 aber problemlos separat herunterladen und (durch Auspacken des ZIP-Archivs) installieren.

Da es gute Gründe gibt, als Standard-Java-Version unter Mac OS X derzeit noch 5.0 einzusetzen, muss man Java 6 beim Aufruf im Terminal explizit als Parameter angeben:

HeartOfGold:visualvm-1.1.1 much$ bin/visualvm --jdkhome /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/ &

Das Profiling funktioniert mit der Apple-Java-Implementierung noch nicht wirklich zuverlässig... Eventuell ist ein älterer Bug immer noch nicht vollständig korrigiert. Immerhin stehen die Monitoring-Möglichkeiten komplett und stabil zur Verfügung.

Mit dem neuen "Memory Sampler"-Plugin können aber zumindest Live-Speichervergleiche (Deltas) ermittelt werden, was einen wichtigen Aspekt des Memory-Profilings abdeckt. Und der Memory Sampler läuft zum Glück auch unter Mac OS X.

WebObjects-Anwendungen in Eclipse entwickeln

2009-03-18T20:55:00.003+01:00

Still und heimlich hat Apple vor ein paar Wochen eine Anleitung veröffentlicht, wie man WebObjects-Anwendungen in Eclipse mit den WOLips-Plugins entwickelt.

Zur Erinnerung: WebObjects ist Apples Enterprise-Framework zur Entwicklung skalierbarer Web-Applikationen. Von NeXT bereits 1996 veröffentlicht, ist es heute die Software-Basis u.a. vom iTunes Store. 2001 wurde das bis dahin in Objective-C entwickelte Framework komplett neu geschrieben – in Java. Entsprechend kann WebObjects 5.x problemlos mit Java SE oder innerhalb eines Java EE-kompatiblen Servers genutzt werden.

Nachdem Apple 2006 die Weiterentwicklung der eigenen, auf Xcode basierenden Entwicklerwerkzeuge eingestellt hat, unterstützt und verwendet Apple nun WOLips, eine OpenSource-Plugin-Sammlung für Eclipse, die die WebObjects-Entwicklertools nachbildet.

Java EE und JavaFX für Mac OS X

2009-03-16T21:15:00.002+01:00

Während nach wie vor Apple für das JDK (Java SE) unter Mac OS X verantwortlich ist und sich dabei nicht besonders gut um ältere Macs kümmert, sind andere Java-Technologien direkt von Sun für Mac OS X erhältlich:

das Java EE 5 SDK inkl. Sun Application Server (GlassFish)
das JavaFX 1.1 SDK inkl. NetBeans IDE 6.5

Beide Produkte können ab Mac OS X 10.4 genutzt werden, sowohl auf Intel- als auch auf PowerPC-G5-Macs – sofern Apples aktuellstes Java 5.0-Update installiert ist.

Als JEE-Umgebung eignet sich natürlich auch der JBoss AS 5.0, der ebenfalls problemlos unter Mac OS X betrieben werden kann.

Aktuelle Java-Versionen für Mac OS X

2009-03-12T22:01:00.009+01:00

Im Netz taucht immer wieder die Frage auf, welche Java-Versionen aktuell unter Apples Mac OS X genutzt werden können – gerade wenn Java-Entwickler ihre Programme nicht selber auf einem Mac testen können.

Für Mac OS X 10.5 sind die Java-Versionen 1.4, 5.0 und 6 direkt von Apple verfügbar und können über die Softwareaktualisierung ins System eingebunden werden (als JDKs, es gibt von Apple keine separaten JREs). Unter Mac OS X 10.4 war zusätzlich noch Java 1.3 nutzbar, dafür hat Apple für diese ältere Betriebssystemversion kein Java SE 6 herausgebracht.

Aber Achtung: Gerade Java SE 6, also die einzige Version, die Ende dieses Jahres noch nicht EOL sein wird, steht nur für 64-Bit-Intel-Macs zur Verfügung. Das sind solche mit Core2Duo-Prozessor. PPC-Macs und ältere Intel-Macs mit CoreDuos bleiben leider außen vor...

Standardmäßig ist für Applets und Java Web Start-Anwendungen so oder so Java 5.0 eingestellt. Mit dem System-Utility /Programme/Dienstprogramme/Java/Java-Einstellungen kann man dies ändern (siehe Bildschirmfoto).

Fazit: Java 6 ist in der Apple-Welt für Endbenutzer leider immer noch nicht wirklich angekommen. Wenn Ihre Java-Applikationen von möglichst vielen Apple-Nutzern eingesetzt werden sollen, sollten Sie derzeit noch Java 5.0 als Mindestanforderung voraussetzen.

Und nun noch ein paar technische Details:

Die aktuellen JDKs für Mac OS X haben die Versionsnummern 1.4.2_18, 1.5.0_16 und 1.6.0_07. Sie können mit den Software-Updates Java for Mac OS X 10.4 Release 7 bzw. Java for Mac OS X 10.5 Update 2 installiert werden (es gibt mittlerweile auch Release 8 und Update 3, aber dadurch wird nur Java Web Start aktualisiert und nicht nicht JDK-Version verändert).

Das Java-Update für Mac OS X 10.5 installiert übrigens auch auf CoreDuo-Macs Java SE 6, nur leider lässt sich das auf diesen Rechnern trotzdem nicht ausführen...

Seit einigen Jahren pflege ich eine detaillierte Liste von Mac OS X- und deren Java-Versionen inkl. der entsprechenden Download-Links.

Unabhängig von Apples Java-Versionen gibt es mit SoyLatte seit einiger Zeit auch eine Portierung vom OpenJDK für Mac OS X. Damit kann Java SE 6 nicht nur unter Mac OS X 10.5, sondern auch unter 10.4 genutzt werden. Allerdings ist auch SoyLatte nur für Intel-Macs verfügbar, und für grafische Ausgaben wird das für Mac-Oberflächen unübliche X11 anstelle von Cocoa genutzt.

Bleibt zu hoffen, dass Sun es (mit Apples Hilfe?) ab Java 7 schafft, selber wieder ein vernünftiges JDK für Mac OS X herauszubringen.

Das Swing Application Framework lebt!

2009-03-04T18:48:00.008+01:00

Desktop-Anwendungen mit Java zu entwickeln, war schon immer so eine Sache... Zwar gibt es die Swing-Bibliothek seit Ewigkeiten und deren GUI-Komponenten sind auch recht brauchbar. Was aber fehlte, war ein Framework, mit dem man den ganzen Lebenszyklus einer Desktop-Applikation einfacher handhaben konnte.

Auch wenn im Laufe der Zeit mit der NetBeans Platform und Eclipse RCP Alternativen entstanden sind, wollte Sun mit dem Swing Application Framework (JSR 296) eine reine Swing-Lösung anbieten. Der Ansatz war gut, doch leider wurde es um diesen JSR in den vergangenen Monaten sehr still - so still, dass der JSR vor kurzem in den Status "inaktiv" versetzt wurde.

Nun hat sich einer der Sun-Entwickler zu Wort gemeldet und verkündet, dass nun wieder aktiv an Swing und dem Swing Application Framework (SAF) gearbeitet wird. In der letzten Zeit gab es offenbar einfach wichtigere Dinge (vermutlich JavaFX?) zu erledigen.

Bei den neuerlichen Aktivitäten ist interessant, dass nicht mehr nur MDI-Anwendungen unterstützt werden sollen, sondern explizit auch die vor allem unter Mac OS X verbreiteten SDI-Applikationen (und auch die beim Mac üblichen Menüzeilen ganz ohne offenes Dokument-Fenster). Das lässt hoffen, denn bisher war für solche GUI-Anpassungen ein nicht unerheblicher Mehraufwand nötig.

Man darf gespannt sein, ob das Swing Application Framework Bestandteil von Java 7 sein wird, dessen Veröffentlichung mittlerweile für 2010 vorgesehen ist.

@EJB Dependency Injection für Struts 1.2/1.3 Action-Klassen

2009-02-23T21:50:00.000+01:00

Auch wenn das Web-Framework Struts - gerade in den Versionen 1.x - schon etwas in die Jahre gekommen ist und mittlerweile zahlreiche Alternativen zur Verfügung stehen (JSF, Struts 2, Wicket, Stripes, GWT, Eclipse RAP...), wird es immer noch häufig eingesetzt, gerade wenn in diesem Bereich viel Entwickler-Know-How vorhanden ist.

Unschön ist dabei allerdings die unnötig komplizierte Einbindung in aktuelle Java EE-Umgebungen, da zum Abfragen von Enterprise-Ressourcen (z.B. Session Beans) explizite JNDI-ServiceLocator-Aufrufe nötig sind.

In JEE-Standard-Klassen ("managed classes") wie Servlets und JSF Managed Beans steht dagegen Dependecy Injection (DI) zur Verfügung, wodurch man sich Referenzen auf Enterprise-Ressourcen nicht mehr aktiv holen muss, sondern automatisch bereitgestellt bekommt.

Mit meiner kleinen Bibliothek Struts-DI funktioniert dies auch innerhalb von Struts-Actions:


public class MyAction extends org.apache.struts.action.Action {

  @EJB
  private MySessionBean msb;

  @Override
  public ActionForward execute(...) throws Exception {

    String backendResponse = msb.myCall(...);
    ...
  }
}

Die dazu notwendige Konfiguration ist denkbar einfach. Anstelle des Struts-RequestProcessors wird in der struts-config.xml ein neuer RequestProcessor eingetragen:


<controller nocache="true"
 processorClass=
   "com.muchsoft.struts.annotations.RequestProcessor"/>

Dies ist unter Struts 1.2 das übliche Vorgehen, um sich in die Action-Verarbeitung einzuklinken. Mit Struts 1.3 funktioniert dies ebenso (der dort vorhandene Chain-Mechanismus wird nicht verwendet).

Neues Jahr, neues Blog

2009-02-20T16:24:00.000+01:00

Nachdem ich bisher unter http://www.snailshell.de/blog/ auf Englisch geschrieben habe, starte ich nun mein neues Java-Blog auf Deutsch. Viel Spaß damit!