Hört sich diese Überschrift reisserisch an? Auf jeden Fall. Man müsste jedoch eigentlich sagen: der Mac ist für viele Java-Entwickler ab sofort gestorben. Zwar hat Steve Jobs vor ein paar Jahren den Mac als beste Plattform für Java gepriesen, geglaubt haben das aber nur Leute die kein Java nutzen. Auf PPC-Rechnern ist Java schon immer fürchterlich langsam. Hinzu kommt, dass Sun leider keine eigenen JRE/JDKs für Mac OS X liefert.
Anscheinend ist diese Plattform jedoch so wichtig, dass Apple selbst Unterstützung anbietet. Bisher gab es also immer eine (halbwegs) aktuelle Java-Plattform. Die Version 6, für Windows/Unix/Linux bereits seit Dezember 2006 erhältich kommt erst heute auch für den Mac.
Der Skandal daran ist jedoch, dass es nur für 64Bit-Maschinen und nur für Intel-Macs herauskommt und damit auch nur unter Mac OS X 10.5 läuft. Apple hat im ersten Intel-Jahr haufenweise 32Bit-Intel-Maschinen unters Volk gebracht. Von den immer noch zahlreich laufenden G4/G5 PPCs ganz zu schweigen. Warum also diese massive Einschränkung die wohl 80-90% (eigene Schätzung) der Mac-Nutzer ausschließt? Ich weiß es nicht. Die folgen werden deutlich sein:
1. Will man mit dem aktuellen und doch schon eineinhalb Jahre alten Java auf dem Mac entwickeln, braucht man neue Hardware.
2. Jedes Java-Programm, das auf dem Mac laufen soll, muss mit Java 5 kompiliert werden! Derzeit mag das zwar noch in Ordnung sein. In spätestens einem Jahr wird das ganz anders aussehen.
3. Java 7 ist bereits in der Entwicklung und sollte ursprünglich diesen Frühling erscheinen. Durch die OpenSource-Umstellung wird sich das voraussichtlich auf Januar 2009 verschieben. Was macht dann Apple? Dauert es wieder über ein Jahr bis man auf dem Mac entwickeln kann? Und wird dann Leopard noch unterstützt?
Mein Fazit: Wenn dein Programm auf dem Mac laufen soll, lass die Finger von Java 6. Wenn du schon mit Java 6 entwickelst und dich gerade zu Tode ärgerst, weil endlich Java 6 da ist, aber auf fast keinem Mac läuft, beschwer dich bei Apple.
EDIT: Nachtrag. Es gibt einen inoffiziellen Port von Java 6. Eine echte Lösung ist das jedoch nicht. Zumal geht das nur unter X11.
April 30th, 2008
FindBugs ist ein Tool, um potentielle Fehlerquellen in Java aufzuspüren. Dabei arbeit es nicht auf dem Quelltext, sondern dem Bytecode. Damit muss nicht zwischen Java 1.4, 5 oder 6 unterschieden werden, da sich in den neuen Releases nur Sprachfeatures und etwas Syntax geändert haben. FindBugs ist kein Wunder- oder Allheilmittel. Es hilft jedoch lästige und häufig auftretende Fehlerquellen aufzuspüren. Bewerten und entscheiden muss der Programmierer nach wie vor selbst.
März 3rd, 2007
Heute hat Sun ihre Javaimplementierung offiziell unter die GPL gestellt. Damit verbunden sind das JDK sowie javac und HotSpot. Weitere Teile sollen folgen. Eine wichtige Ausnahme zur GPL ist, dass durch das Linken auf die Standardbibliothek das eigene Programm nicht unter GPL gestellt werden muss. Sinnvoll :D.
Dazu gibt es auch eine neue Webseite. Auf der sind alle Teile verlinkt. Ausserdem findet sich alles zu Java 6 (derzeit Beta 2) und auch Java 7.
November 13th, 2006
Bereits vorgestern habe ich den Artikel Reverse bit order geschrieben. Da es mein erster englischer Artikel ist, ist dieser hier mehr fuer die Robots. In dem kleinen Codebeispiel wird gezeigt wie man die Reihenfolge der Bits in einem Integer, Short oder Byte umdrehen kann. Es ist in Java programmiert, funktioniert aber auch in jeder anderen Programmiersprache.
August 21st, 2006
At "Summercamp 2006" at the University of Passau I was working with pupils on a simple Voice over IP application. They finished this task quite fast and after two days we had to give them something more complex. So they worked on recording and manipulating sound.
Then we had the problem of changing the order of bits efficiently. I do not mean a simple xor, so I give you an example:
0 0 1 1 0 1 0 0 : 52 (changing order of bits)
0 0 1 0 1 1 0 0 : 44
I tried a few things with build in Java classes but did not find the solution. So I took a pencil and tried a lot with boolean operators. It turned out that you can restrict it to two lines of code, with a surrounding for statement:
for (int i = 0; i i< size; i++) {
newInt = (newInt * 2 + (temp & 0x1));
temp = (temp / 2);
}
And because the members of our team where not familiar with these operators I wrote a whole Java class, which you can find here in my blog: BitFlip.java. The class requires a Java 5 compiler, because of the size constants. Feel free to use it in your projects.
August 19th, 2006
Beim Google Web Toolkit handelt es sich um eines der zahlreichen AJAX Frameworks. Deren gibt es hunderte. Alleine bei Sourceforge.net finden sich im Moment 108 kostenlose. Das macht die Auswahl und den Einstieg schwierig.
Jedoch dürfte klar sein, dass sich der Markt sehr schnell konsolidieren wird und sehr wahrscheinlich nur eine Hand voll relevanter Implementierungen übrig bleiben werden. Dazu zähle ich neben dem von Yahoo und dem bisher nicht veröffentlichten von Microsoft auch das Google Web Toolkit. Die Besonderheit an diesem Framework ist, dass keine einzige Zeile Javascript geschrieben werden muss. Man produziert praktisch alles in Java und hat dadurch viele der Vorteile der mächtigen plattformunabhängigen Sprache.
Wie das aussieht und was damit alles machbar ist findet sich, erstaunlicherweise wieder einmal bei IBM. Desweiteren handelt es sich um ein umfangreiches Tutorial: Google Web Toolkit Tutorial.
Ich selbst stehe dem AJAX Hype eher kritisch gegenüber und habe bisher auch fast nichts damit gemacht und erst recht nicht in Seiten eingebaut. Ungelöste Usability-Fragen (Zurück Button!) und nicht vorhandene Barrierefreiheit sind für mich ein Ausschlusskriterium. Hinzu kommt, dass bisher nicht klar ist wer sich letztendlich durchsetzen wird. Google hat in der jüngeren Vergangenheit jedoch gezeigt, dass Durchsetzen eine ihrer Stärken ist.
Juni 28th, 2006
Der AJAX Remote Desktop Viewer ist ein Proof of Concept, mit dem man von außen per HTTP auf den Desktop zugreifen kann. Es läuft etwas langsam und bietet bisher keinerlei Authentifizierung. Der Einsatz außerhalb des eigenen Netzwerks ist also nicht zu empfehlen. Interessant ist es auf jeden Fall, da man keinen extra Port freigeben muss. Alles geht über HTTP. Vnc ist natürlich nach wie vor besser.
Juni 21st, 2006
Wieder ein kleines Review eines Artikels aus der IBM Denkfabrik. Andrew Wilcox beschreibt darin was Profiling eigentlich ist, ich nehme an meine Leser wissen das :D, und geht auf Probleme mit aktuellen Profilern, wie den Performanceverlust, ein. Nachdem er die Anforderungen an einen “idealen” Profiler gestellt hat, kommt er zu dem Schluss man müsse ihn selber schreiben.
Hier gibt er dann sehr ausfürlichen und lauffähigen Code an. Allerdings handelt es sich um Java 5 AOP Code. Man sollte also mit der Aspect Orientierten Programmierung unter Java einigermaßen vertraut sein. Näheres findet man z.B. auf den Seiten des AspectJ Projekts der Eclipse Foundation.
Wem das alles zu viel ist und eigentlich nur den “idealen” Profiler sucht und sich im Dschungel der Angebote nicht mehr auskennt, kann sich JIP ansehen. Er stammt ebenfalls von Wilcox und der Code aus dem Artikel basiert darauf.
März 15th, 2006
Bei cs64s.com gibt es haufenweise C64 Klassiker. Dazu braucht es keinen Emulator, sondern nur einen Browser mit Javaunterstützung. Auf der Seite habe ich unter anderem Commando II wieder entdeckt. Hunderte anderer Perlen warten auf die nächste Mittagspause. Sogar einen Joystick kann man verwenden. Nur wer hat noch so einen alten robusten Knüppel?
Auf einem Apple Rechner geht es auch, wenn er denn schnell genug ist. Java ist unter OS X generell etwas langsam.
März 1st, 2006
In diesem Artikel vergleicht Barry Feigenbaum, Mitarbeiter von IBM, die drei GUI Toolkits SWT, Swing und AWT. Am besten ist wohl die Feature-Vergleichsliste. In der sieht man sofort ob ein Toolkit die gewünschte Funktionalität bereitstellt, oder nicht.
Sein Fazit fällt dann aber wieder ganz altbekannt aus. Er zieht Swing SWT vor, da es in Java integriert ist und nicht erst zusätzlich installiert werden muss. Er erwähnt ebenso die Komplexität von Swing, gesteht ihm aber auch die bessere Architektur zu. Gilt es aber die Anwendung nur für eine Plattform zu schreiben, so kann SWT mit der nativen Implementierung und Integration von betriebssystemabhängigen Komponenten punkten. Der Geschwindigkeitsvorteil ist je nach Rechnerausstattung auch nicht zu unterschätzen. Zwar läft Eclipse auf meinem 1.5 GHz G4 Powerbook trotzdem sehr langsam, aber wer weiß wie es mit Swing wäre.
Februar 27th, 2006