Java Programming

Virtuelle Realitäten wie Second Life werden ja schon für Geschäftsmeetings (z.B. Vorträge) genutzt. Sub arbeitet mit Project Wonderland an einer Platform, die speziell für die Zusammenarbeit in Teams ausgelegt ist.

Hier ein nettes Demo Movie der Telefon Integration in Wonderland. Und eine ältere Demo des "virtuellen" Sun Gebäudes MPK20.

Das ganze ist verspielt, und es muss sich erst zeigen ob Konferenzteilnehmer dadurch wirklich Produktivität gewinnen und nicht verlieren, aber unterhaltsam ist es allemal.

Heute finden an der Uni-Karlsruhe gleich zwei interessante Termine statt. Die Java User Group Karlsruhe musste deswegen in den Raum -102UG in der Informatik Fakultät ausweichen, dort gibt es um 19:15Uhr (-21:15) einen Vortrag von Dr. Patrick Schemitz (Netpioneer GmbH) zum Thema Grundladen [Web] Security Auditing.

In -101UG spricht Dr. York Sure von SAP Research im Rahmen der GI/ACM Regionalgruppe Karlsruhe über Internet of Services. Dabei geht es um den Einsatz von Semantischen Technologien bei der Vermarktung von Internet Services.

Beide Termine finden sich auf dem IT-Kalender des Stadtblog KA. Dort findet sich auch eine Ankündigung für Morgen: Gründung des "Verein der Karlsruher Software-Ingenieure" um 16:00-18:00 am FZI. Näheres dazu in der Presseerklärung von FZI, KIT, adrena objects, 1&1, SAP und HsK.

Ich werde wohl bei der JUG-KA vorbeischauen heute Abend und mir Morgen die Info Veranstaltung ansehen.

Dieses mal nur schnell einen Pointer zu einer Artikelserie von Jeroen Borgers auf InfoQ. Ich weise ausdrücklich darauf hin dass der erste Teil des Artikels nicht ohne den zweiten Teil genossen werden sollte.

• Threading Optimizations in Java
• Do Java 6 threading optimizations actually work? - Part II

Zusätzlich möchte ich noch auf den Micro Benchmark Runner von Brent Boyer verweisen. Dieser spart ein wenig die manuelle Korrektur und Anpassung der Warmup-Phasen und liefert aussagekräftige statistische Auswertungen. Die developerWorks Artikelserie geht auf diese Verfahren auch noch etwas genauer ein:

• Robust Java benchmarking, Part 2: Statistics and solutions
• Companion site

Das Thema der null Referenzen in Java, insbesondere als Rückgabewert von Methoden ist umstritten. Generell führt es zu einer erhöhten Gefahr von (aussagelosen) NullPointerExceptions.

An manchen stellen kann man diese einfach vermeiden: finder die eine Liste von Objekten zurückliefern sollten eine leere Ergebnismenge (die ohne Fehler zustande gekommen ist) nicht mit einem null; Rückgabewert signalisieren, sondern mit einer leeren Collection: "return List.EMPTY_LIST;".

An anderen Stellen ist die Vermeidung von null nicht immer unumstritten. Auf die Diskussion will ich mich hier jetzt garnicht einlassen. Deswegen habe ich hier eine einfache Policy - falls null Rückgabe Werte doch zulässig sein sollten:

Wenn schon null als Rückgabe Wert einer Methode, so darf dies nur passieren wenn:

1. im Javadoc erwähnt wird "@returns the Object requested or null"
2. der null Wert im Code durch ein explizites "return null;" angegeben wird.

Ein Negativbeispiel ist dies hier (der Code mit der Entscheidungsfindung ist hier deutlich übersichtlicher als bei größeren Methoden mit state variablen in der Praxis:

public IThing getCarOrBike(int distance, Person p) {
  IThing ret = null;

  if (distance > 1000) {
    ret = new Car();
    ret.add(p);
  }

  if (distance > 100) {
    ret = new Bike();
    ret.add(p);
  }

  return ret; // BAD
}

Mit einem expliziten return wird dies klarer, entweder (die von mir oftmals bevorzugte Early-Out Variante):

public IThing getCarOrBike(int distance, Person p) {

  if (distance < 0 || p == null)
    throw new IllegalArgumentException("You must specify a person and positive distance");

  if (distance <= 100)
    return null; // pedestrian

  IThing ret;

  if (distance > 1000) {
    ret = new Car();
  } else {
    ret = new Bike();
  }
 
  ret.add(p);

  return ret;
}

Oder eine if/else Cascade:

/**
 * Return Transportation for given distance.
 * <P>
 * This will return instances of Car or Bike. If the distance
 * is short enough, null will be returned.
 *
 * @return null or new instance of Car or Bike with person added
 */
public IThing getCarOrBike(int distance, Person p) {
  IThing ret = null;

  if (distance > 1000) {
    ret = new Car();
  } else if (distance > 100) {
    ret = new Bike();
  } else {
    return null; // pedestrian
  }

  ret.add(p);
  return ret;
}

Wichtig ist dabei immer, dass im Code klar wird, was die Intention ist - also: soll null wirklich zurückgegeben werden oder wurde nur eine Fallunterscheidung vergessen. Wenn man sich dazu überwindet "return null;" zu schreiben, so ist es zugegebenermaßen manchmal etwas langatmiger, aber dafür eindeutig.

Eine Code Policy wie "jede Methode darf nur einen return punkt haben" ist übrigens nicht nur weil es dieses Idiom verbietet unsinnig. Das führt nur zu extremen Verschachtelungen. Dank Java finally gibt es dazu auch sehr selten Grund.

Übrigens versuche ich auch die returns innerhalb eines entsprechenden try/finally Blocks zu haben und vermeide "Alibi" returns am ende der Methode - die beschwichtigen nur erwünschte Warnings.

Bilder des ersten Tages der Open Expo in Karlsruhe habe ich auf meinem Ipernity account abgelegt.

Es war nicht allzu voll, die beteiligten Open Source Projekt-Aussteller haben sich aber sehr gut versorgt gefühlt. Mir persönlich hat eine Moderation und Betreuung der Redner gefehlt. Bis auf die Keynote von Mike Milinkovich (Executive Director Eclipse Foundation) waren die Vorträge teils Produkt/Marketing related und teils Vorträge von Praktikern. Witzigerweise haben die meisten davon auf Ihre High-Profile Kollegen die den gleichen Vortrag auf dem Linuxtag halten werden verwiesen.

Heute ist der erste Tag an dem die Veranstaltung parallel zur Webinale stattfindet, bin mal gespannt wie die Besuchsberichte so ausfallen. Ich werde heute nicht dort sein, dafür aber Abends als Gast auf dem Geek Girl Dinner (Fotos bei Mela).

Die Java User Group Karlsruhe veranstaltet einen Vortrag über den SAP Memory Analyser, der nun Teil der Eclipse Infrastruktur ist. Als Referent wird am Mittwoch 2008-05-07 19:15 der SAP Mitarbeiter Markus Kohler den Vortrag in der Informatik Fakultät der Uni-Karlsruhe halten.

Ankündigung bei Google Groups

Update: ein Artikel des Referenten gibt es in der Eclipse DZone.

Wie schon im ersten Teil beschrieben, muss man trotz der Platform Unabhängikeit von Java etwas über die Zielsysteme wissen, um grobe Fehler zu vermeiden:

/** save data as UTF-8 string to file. */
saveFile(String data, File file) throws IOException, UnsupportedEncodingException {
  OutputStream out = null;
  bytes[] b = data.getBytes("UTF-8");
  try {
    out = new FileOutputStream(file);
    out.write(b);
  } catch(IOException ioe) {
    System.err.println("Cannot save data in UTF-8 to file " + file + ": " + ioe);
    throw ioe; // notify upper layer about problem
  } finally {
    silentClose(out); out = null;  // BANG, problem unterdrückt.
  }
}

silentClose(OutputStream out) {
  if (out != null)
    try { out.close(); } catch (Exception ignored) { }
}

In diesem Fall wird zwar richtigerweise im Fehlerfall der Output Stream geschlossen und die dabei eventuell auftretende Exception ignoriert, aber viel kritischer ist der Fall in dem im try block keine Exception aufgetreten ist, aber dafür dann das close() fehlschlägt.

Es muss damit gerechnet werden dass im close() auf einem OutputStream eine IOException auftreten kann - sogar sehr häufig - der Grund dafür ist, dass zum einen der Stream einen flush() vor dem close() durchführen wird. Dazu kommt noch, dass die close() Methode der letzte Zeitpunkt ist, in dem ein IO Fehler gemeldet werden kann. Bei NFS ist es z.B. so, dass der client wartet bis der Server den Empfang bestätigt hat. Und dabei kann natürlich eine Menge schiefgehen. Auch quota Überschreitungen können zu einer IOException führen.

Es hilft etwas als letztes Statement im try-block einen flush() durchzuführen, aber es besteht weiterhin ein Risiko dass close() fehlschlägt. Eine wichtige Regel lautet also: bei Streams in die geschrieben wird kann close() einen Fehler werfen, diese darf nicht ignoriert werden (sonst gehen Daten verloren)!

saveFile(String data, File file) throws IOException, UnsupportedEncodingException {
  OutputStream out = null;
  bytes[] b = data.getBytes("UTF-8");
  try {
    out = new FileOutputStream(file);
    out.write(b);
    out.close(); out = null;
  } catch(IOException ioe) {
    System.err.println("Cannot save data in UTF-8 to file " + file + ": " + ioe);
    throw ioe;
  } finally {
    silentClose(out); out = null;
  }
}

Im Falle von NFS ist obiger Code ausreichend. Nach dem close() ist es garantiert, dass die Daten permanent gespeichert sind. Bei lokalen Filesystemen wird diese Garantie von den gängigen Betriebsystemen NICHT gegeben. Die Daten können auch nach einem close() nur im lokalen Buffer Cache des Filesystems (RAM) liegen und erst nach einiger Zeit (typischerweise 5 Sekunden) an die Hardware Schicht übergeben werden. Dies ist zwar gut für die Performance, aber ein potentielles Fenster für Datenverlust - und eventuell Korruption des Anwendungszustandes.

Wie dies zu vermeiden ist, betrachte ich im nächsten Teil (der kein Jahr auf sich warten lassen wird:)

Offener Brief von Neil Wilson (directorymanager.org) über seine Freisetzung bei Sun und den Druck der auf die (gekündigten) Project-Owner der OpenDS (LDAP Server) Community ausgeübt wurden.

Wie Neil beschreibt ist das sicher ein Beipspiel für sich verselbständigendes Middle Management das den Sinn für die Realität verloren hat, aber... wieviel dieser Manager gibts bei Sun noch?

(via Ben Rockwood)

Eduard Hildebrandt stellt in seinem Blog deutschsprachige Java Blogs vor. Er macht dies in Form eines Interviews. Bisher hat er drei Blogs vorgestellt, darunter auch das IT-Blog.

In dem Zusammenhang habe ich noch mal über die von mir gewählte Sprache des Blogs nachgedacht, und muss sagen, ich bin immer noch nicht 100% sicher ob es eine gute oder schlechte Entscheidung war. Auf der einen Seite ist das Bloggen in Deutsch geringfügig einfacher und bedingt durch die kleinere Auswahl an Blogs wird man im eigenen Sprachraum doch schneller wahr genommen. Auf der anderen Seite jedoch habe ich viel Kontakt mit US Partnern, Kunden und Kollegen... da ist ein fachliches Blog hilfreich. Momentan liegen die Pläne das Blog zweisprachig zu führen allerdings auf Eis.

Zur Zeit klebe ich noch etwas an der Java 1.4 Version - weil sich ein konservativer Umgang mit der Nutzung von neuen Features immer als positiv zeigt. Inzwischen gibt es aber su gut wie keinen Grund mehr die Entwicklung auf Java 1.4 auszurichten. Auch die exotischten Platformen kommen inzwischen mit einem Java 5 daher.

Zudem werden spührbar mehr kritische Bugs nur noch für Java 5 und Java 6 gefixed, so zum Beispiel der Berüchtigte ClassCircularityError Bug, der in Java 5.0 Update 8 endlich beseitigt wurde.

Während wir also schon einige Zeit nun Java 5 als Mindestvoraussetzung haben findet Java 6 schon eine gewisse produktive Verbreitung. Deswegen hier mal wieder einen Link auf interessante Hotspot Optionen:

http://www.md.pp.ru/~eu/jdk6options.html

(von Eugene Kuleshov) Ich hatte solche Links ja bereits für Java 1.4 hier im Blog veröffentlicht und habe oft selbst darauf zurückgegriffen (Weblog - statt Bookmarks, ein ganz ganz altes Konzept!).

Einige meiner Punkte die ich durch die Tests der T1000 herausfinden möchte sind:

• Wie ist die IO-Performance der internen Platte
• Wie stark macht sich die geringe Takt-Frequenz bei Single-Thread Nutzung bemerkbar
• Wie gut lassen sich Java Anwendungen parallelisieren
• Wieviele Hidden Floating Point Operatione finden sich in Java

Allerdings werden Sie sich noch etwas gedulden müssen, da ich noch auf Dienstreise in Göteborg bin.

Übrigens haben sich in der Zwischenzeit schon mehrere Sun Mitarbeiter gemeldet, um mich Willkommen zu heissen. Sie haben mir Pre-Sales Unterstützung angeboten, auf Resourcen hingewiesen und mich zum bloggen meiner Erfarungen auf dem Systemhelden.de Blog eingeladen. Ich habe dort jetzt auch ein HELDENProfil.

Die ganze Story zum sun Try&Buy:

• Part I - Die Online Registrierung
• Part 2 - Der Sales Anruf
• Part III - Willkommen
• Part IV - Frightening Freight

Aber genug von der Arbeit, hier ein paar Impressionen aus Göteborg:


Fotos aufgenommen von einer Fähre die mit 24h Nahverkerskarte (50,- SKR) als Hafenrundfahrt benutzt werden kann.

Endlich kommt von SAP wieder News zu Ihrer eigenen JVM. Vor einiger Zeit gab es ja Berichte über eine JVM die optimiert ist auf den isolierten Betrieb von Anfragen, mit einem Shared Speicher Bereich und verbesserten Management Funktionen.

Das Ergbnis ist in diesem SDN Blog Artikel von Oliver Schmidt.

Die Investition in Java Entwicklung scheint sich gelohnt zu haben. Hier sollte man weiterhin ein Auge drauf werfen...

• Advanced Tracing and Monitoring
• Improved Full Thread Dumo
• JIT Native Code Debugging
• Java Debugging on Demand
• Heap Dump (Markus Kohler)
• Multi Instance Support

In einem Blog Artikel beschreibt Joshua Bloch einen Bug in der binary-search Implementierung der Java Klassenbibliothek und schliesst die Ausührung mit der Bemerkung:

The binary-search bug applies equally to mergesort, and to other divide-and-conquer algorithms. If you have any code that implements one of these algorithms, fix it now before it blows up. The general lesson that I take away from this bug is humility: It is hard to write even the smallest piece of code correctly, and our whole world runs on big, complex pieces of code.
We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it. We must program carefully, defensively, and remain ever vigilant.

Lesebefehl für jeden Entwickler: wird sind manchmal einfach zu arrogant und unkritisch mit unserem Code. Es geht jetzt weniger um den speziellen Fehler (ich hatte den Fehler in der Zeile vermutet aber eher bei der Rundung als beim Überlauf, und das obwohl ich normalerweise versuche solche Additionen zu vermeiden)
sondern mehr um die Tatsache dass so ein trivialer Quelltext einen Fehler enthalten kann der fast 9 Jahre unbemerkt ist (und dabei Millionen von Anwendern hat, sogar in mehreren Lehrbüchern zu finden ist).

Danke an Peter Luschny (de.comp.lang.java) für den Link. Dort hält man das ganze übrigens für einen PR Gag für sein neues Buch, das jetzt auch schon auf meiner Wunschliste steht.

Marc Fleury schreibt in einer Mail an Kunden und Partner:

I am writing to you today to announce that the Red Hat acquisition of JBoss has closed and we now are officially a part of the largest independent open source company. I am excited about this news and the great opportunity that it represents. We are entering a new era in the technology industry that puts customers back in charge of their destiny, where innovation and value replace lock-in and costly proprietary-vendor software licenses. Together, we believe we can change the economics of the industry, delivering unmatched value to our customers and partners by creating better software faster, systematically driving down costs and simplifying IT

B*LLSH*T. Meine Reaktion war, dass er damit in jedem Bullshit-Bingo gewinnt.

Es hat einige Zeit gedauert bis Microsoft eine Alternative für das Deployment von lokalen Anwendungen per Web Browser hatte. In der Java Welt gibt es hierfür Java Web Start, das mittels JNLP Protokoll erlaubt einen lokalen Cache zu füllen, und eine Anwendung in einer (einfachen) Sandbox auszuführen.

Microsoft plaziert ClickOnce als .NET 2.0 Technology. Sie haben damit den großen Vorteil dass das Sandboxing durch die umfangreichen .NET Möglichkeiten sehr weitgehend eingestellt werden kann. Ganz im Gegensatz zum JWS, wo die Integration in den Security Manager ziemlich mager ausgefallen ist.

Ich habe noch keine Erfahrung mit ClickOnce, im JWS Umfeld kenne ich das Problem, dass das Debugging und fixen von JWS Installationen sehr Support Aufwändig ist. Die JWS Implementierung des Sun JDKs ist hier nicht sonderlich gut gelungen.

Wir verteilen einen Admin Client auf diese Art und Weise, und weil wir damit oftmals die ersten in einem Unternehmen sind haben wir immer wieder die Freude dysfunktionale JWS Installationen zu debuggen. Ich glaube durch die stärkere Integration hat Microsoft dieses Problem bei Ihren Installern nicht. Und es wird sicher nicht mehr lange dauern bis auch Firefox einen Mime Handler für application/x-ms-application aufweisen kann.

Eventuell könnte es dann sogar Sinn machen Java Anwendungen auf diesem Weg an Microsoft Desktops zu verteilen.