VisualVM 1.3.x statt Eclipse TPTP?

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

... 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

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

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

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.

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")

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!