Aber es fehlen unter anderem Namensräume und eine umfassende Unicode-Unterstützung. Außerdem machen einige APIs einen sehr unaufgeräumten Eindruck. Das soll sich mit der im 1. Quartal 2008 erscheinenden Version 6 ändern.

Interessante Beiträge zum Thema PHP6 finden sich unter:

• php.net – Minutes PHP Developers Meeting
• Visualhype – Änderungen in PHP6
• entwickler.com – PHP6: Was uns erwartet
• Jero – Taking a look at PHP 6

Dieses “Stück” ist natürlich nicht von William Shakespeare. Tatsächlich stammt der Text aus der Feder Peter Nillius’. Geschrieben in der Programmiersprache Shakespeare. Diese gehört zu den sogenannten esoterischen Programmiersprachen. Meistens handelt es sich um Programmiersprachen mit möglichst unverständlicher Syntax. Im Fall von Shakespeare geht es darum das Programm wie ein Shakespeare-Stück aussehen zu lassen. Beispielsweise übernehmen die Figuren aus unserem Stück die Rolle der Variablen.

Wer sich etwas näher mit der Shakespeare Programming Language auseinandersetzen will sollte einen Blick auf die Homepage werfen. Es lohnt sich. Zumindest für Programmierer.

Das Programm berechnet übrigens die ersten n Glieder der Fibonacci-Folge.

Diese Klasse verwendet man in etwa so:

01  String date = "41.01.2007";
02  DateFormat df = DateFormat.getDateInstance(
         DateFormat.MEDIUM,
         Locale.GERMANY);
03  try {
04    Date d = df.parse(date);
05    System.out.println(df.format(d));
06  }
07  catch (ParseException ex) {
08    System.out.println("ungültiges Datum");
09  }

Jeder kann auf den ersten Blick sehen, dass der 41.01.2007 ein ungültiges Datum ist. Man möchte meinen, dass der Aufruf in Zeile 04 zu einer Exception führen muss. Falsch gedacht. Tatsächlich werden die “Ãœberschüssigen” Tage und Monate einfach zum Datum dazuaddiert. Aus dem 41.01.2007 wird so der 10.02.2007 und aus dem 4235.18.1900 wird folgerichtig der 03.01.1913.

Dieses Verhalten mag zwar in manchen Situationen recht praktisch sein, spätestens bei der Validierung von Benutzereingaben sieht die Sache anders aus. Wenn ein Benutzer ein solches ungültiges Datum eingibt, war es wahrscheinlich ein Tippfehler.

Schuld an dem Schlamassel ist der nachsichtige (engl.: lenient) Parser in DateFormat. Diese Nachsichtigkeit kann man dem Parser glücklicherweise austreiben, indem man die Methode setLenient(boolean lenient) mit dem Paramter false aufruft.

Und so funktioniert das Programm, wie erwartet:

01  String date = "41.01.2007";
02  DateFormat df = DateFormat.getDateInstance(
         DateFormat.MEDIUM,
         Locale.GERMANY);
03  df.setLenient(false);
04  try {
05    Date d = df.parse(date);
06    System.out.println(df.format(d));
07  }
08  catch (ParseException ex) {
09    System.out.println("ungültiges Datum");
10  }

Warum der Parser standardmäßig den nachsichtiges Parser verwendet bleibt offen.

So ist es mit der Klasse java.awt.Desktop beispielsweise möglich den Standardbrowser des Betriebssystems zu starten und eine URL anzeigen zu lassen.

Puristen werden zurecht aufschreien. Was hat eine Desktop-Integration in einer (pseudo)plattformunabhängigen Programmiersprache zu suchen? Die Antwort: Es ist eine sinnvolle Ergänzung. Trotzdem stellt sich die Frage ob es wirklich notwendig ist mit Desktop-Komponenten die ohnehin schon mit unzähligen APIs überladene Java Distributionen noch weiter aufzublähen.