Wannawork

Mittlerweile sind es einige Monate her, seit dem ich mich zuerst über Java 6 auf dem Mac gefreut habe um dann entsetzt festzustellen, das leider die Version echt unbrauchbar ist.

Nachdem ich nun neun Monate gewartet habe, habe ich am Wochenende mal probiert, den TV-Browser auf dem Mac auf Java 6 zum laufen zu bringen. Leider ohne erfolg. Es gab leider zwei sehr große Probleme:

1. Grafikfehler – Die farbliche Hinterlegung von Sendungen funktionierte nicht vernünftig. Teilweise waren statt der gerade laufenden Sendung einfach alle Sendungen blau hinterlegt.
2. Abstürze – Das war das schlimmere Problem. Alle paar Minuten ist die Anwendung abgestürzt mit einem Java-Core-Crashlog. D.h. einem Fehler in der Java Runtime.

Ich bin auch nicht der einzige, der diese Probleme hat. Beschwerden über diese zwei Punkte gibt es überall im Netz.

Apple hat vor einigen Jahren damit geworden, das der Mac die beste Plattform zum Entwickeln unter Java ist. Dies stimmte auch. Aber mittlerweile ist der Mac eigentlich die letzte Plattform, auf der man Java entwickeln will. Schade. Sehr schade.

Soylatte, der OpenJDK-Port für den Mac ist leider auch (noch immer) nicht die erste Wahl als Ersatz. Es ist einfach noch nicht so weit. Und wenn man sich ansieht, wie schnell es damit geht, sieht es so aus, als ob das Projekt eine nette Idee war, aber nicht wirklich fortgeführt wird .

Update: Anscheinend haben die Grafikfehler etwas mit den Abstürzen zu tun. Die Anzeigekomponente des TV-Browsers provoziert irgendwie Crashes in der VM. Die Methode fillRect, die Vierecke zeichnet, ist eventuell anfällig für Abstürze unter bestimmten Randbedingungen

Update 2: Okay, das sollte nun gefixt sein. Danke Bananeweizen!

Eine kleine Empfehlung an alle Java-Entwickler:

Effective Java: A Programming Language Guide (Java Series)

In dem Buch werden Best Practices in Java vorgestellt. Und das nicht zu knapp. Einige davon wird jeder bestimmt kennen, aber so in geballter Form bestimmt nicht. Dieses Buch sollte wirklich jeder Java-Entwickler besitzen und immer griffbereit haben.

Alternativ kann man auch noch bei Angelika Langer einige Artikel lesen, aber das ist nur ein Bruchteil von dem Inhalt des Buches.

Kaufen !

SwingLabs is a great resource for everyone who wants to make their java applications look as nice as possible. The main swingx-package is available in the main maven repository using this dependency:

But sadly Swingx-ws is missing. At the moment only weekly snapshots exist on the SwingLabs-Homepage.

Today I uploaded swingx-ws to my own little maven2 repository because it will be used in a little application I am playing with .

You can add swingx-ws to your project with this lines:

You have to add this repository to your project:

This little application is done in less than 20 Lines of Code:

Some Links about the map component:

• Building Maps into Your Swing Application with the JXMapViewer
• Mapping Mashups with the JXMapViewer
• Example Applet

http://grails.codehaus.org/

Ich habe letzte Woche in der Firma meine erste Grails-Applikation deployed. War keine sehr komplexe Anwendung, nur ein paar Formulare und Listen, aber gut genug für einen ersten Test in Grails.

Grails hat, genauso wie Rails, als Kern-Paradigma “Convention over Configuration”. Auf Deutsch gesagt legt Grails fest, wo welche Dateien liegen. Dies minimiert den Konfigurations-Aufwand auf ein absolutes minimum und man kann sofort loslegen.

Jeder, der schon mal eine Spring-Konfigurations-Datei geschrieben hat, oder begonnen hat, Hendriks Tutorial zu lesen, wird verstehen, warum ich denke, das dieses Vorgehen für die meisten Anwendungen besser geeignet ist, um schnell Ergebnisse zu erzielen.

Ein hübscher Nebeneffekt der Vorgaben ist, das jede Anwendung gleich strukturiert ist. Auspacken und wie zuhause fühlen.

Aber warum Grails nutzen, wenn man doch gleich Rails nutzen kann? Nun ja, das habe ich mich zu beginn auch gefragt, aber nachdem ich jetzt ein bisschen damit rum gespielt habe, muss ich sagen, das Grails schon einige Vorzüge gegenüber Rails hat.

Der wichtigste Vorzug ist die gesunde Basis: Grails baut auf Spring, Hibernate und einigen weiteren bekannten Java-Bibliotheken auf. Es ist also alles schon erprobt und für einen JavaEE-Entwickler bekannt. Der andere Vorteil gegenüber Rails ist das Deployment auf einen Java Application Server. Man muss nicht einen Rails-Server neben dem Glassfish-Server laufen lassen. Und zuletzt kann man vorhandene hausinterne Java-Klassen und Bibliotheken in Grails nutzen und umgekehrt.

Einige Nachteile gibt es natürlich auch. Capistrano ist nicht vorhanden, aber mit den War-Files geht’s fast genauso bequem. Leider gibt es keine Migration-Files, sprich: Grails kann Tabellenstrukturen zwar verändern, aber sollten Daten von Spalten in andere Datentypen migriert werden, kann man dafür kein automatisch ablaufendes Skript erstellen, das während des Deployments der Anwendung ausgeführt wird. Es gibt aber Plugins, die sowas in Grails ermöglichen, nur habe ich die noch nicht getestet.

Natürlich sollte man Grails nicht immer einsetzen, bei sehr großen, komplexen Anwendungen wäre es bestimmt Fehl am Platz. Aber die entwickelt man ja nicht alle Tage. Die meisten Anwendungen sind kleinere Tools. Und gerade diese kann man so noch schneller entwickeln.

http://java.dzone.com/new…est-release-eve

Yesterday Apple finally released Java 6 for Mac OS 10.5.2. The whole community waited years to this day. But the release is broken because of several reasons.

Read more…