Java Programming

Immer mal wieder erreichen mich seltsame Blindbewerbungen. Ab und zu frage ich sogar nach, woher denn die Annahme stammt, ich würde Stellen anbieten. Bisher habe ich noch nie eine Reaktion erhalten. Deswegen nehme ich mir die Freiheit das Anschreiben einer solchen Blindbewerbung hier zur Unterhaltung wiederzugeben. Zum besseren Verständnis habe ich meine Gedanken eingefügt :)

Sehr geehrte Damen und Herren,

ich bewerbe mich bei Ihnen als Java/J2EE-Entwickler. Nach jahrelangem Studium [ohne Abschluss] mit Schwerpunkten Künstliche Intelligenz und Computergrafik und mit breit angelegter Informatik-Bildung, habe ich mich entschieden, meinen Schwerpunkt einer angehenden Arbeitstätigkeit im Java-Umfeld zu suchen.

Ich bin qualifiziert, die von Ihnen [nicht] angebotene Tätigkeit auszuüben, da ich bereits während meines Studiums Erfahrungen mit der Konzeptionierung und Realisierung von Software-Projekten, in Gruppen mit jeweils mehreren Personen [Ah, da hat doch Tatsächlich jemand die Seminare und Übungen besucht] gemacht habe. [Ich habe sonst keinerlei Praxiserfahrung]

Während des Studiums habe ich immer wieder mit Java programmiert, zumeist Applets [entsprechend Umfanreich waren diese Gruppenprojekte]. Bis vor kurzem befand ich mich in einer Java-Weiterbildungsmaßnahme [denn ich muss trotz Studium mich vom Arbeitsamt aushalten lassen], um die ich mich selbst seit langem bemüht habe [in der Zeit hätte ich sonst arbeiten müssen], da zum einen in Stellenangeboten frequentiert nach Java-Programmierern nachgefragt wurde, andererseits Java eine mir leicht zur Hand gehende Programmiersprache in Erinnerung geblieben war. [Ist zwar schon Jahre her, aber wenn es sonst keine Jobs gibt...]

Ich freue mich, wenn Sie mich zu einem Vorstellungsgespräch einladen würden. Für Rückfragen - auch per E-Mail - stehe ich Ihnen gern auch kurzfristig zur Verfügung.

Mit freundlichen Grüßen
Name der Redaktion bekannt

In einer Panik-artigen Aktion hat Sun einige neue Features gesammelt und als Update für Java 6 im Project Update-N oder Update 10 zusammengefasst. Darunter fallen Verbesserungen für die Installation (Inkrementeller Download), Beschleunigung von Grafik und Swing und ein neues Java Plugin (für Applets).

Am 15. Oktober fand dann die FCS statt, das Java SE 6 Update 10 ist jetzt zum Download verfügbar. Ich bin mal gespannt wie viele Probleme dieses mal auftreten werden in existierenden Anwendungen.

Interessant ist auch, dass Sun nach Jahren wieder (Anfang Oktober) ein JDK für Itanium anbietet. Die 64bit JVM wird für Linux und Windows angeboten. Im Bereich Tooling (VisualVM, JavaDB) und Plugin (Applet) sowie im Bereich Multi Media (Linux Alsa Sound) existieren allerdings starke Einschränkungen. Eignet sich so nur für den Server Einsatz. HP dürfte mit seiner JRE für IA64 aber deutlichen Optimierungsvorsprung haben.

In einer Panik-artigen Aktion hat Sun einige neue Features gesammelt und als Update für Java 6 im Project Update-N oder Update 10 zusammengefasst. Darunter fallen Verbesserungen für die Installation (Inkrementeller Download), Beschleunigung von Grafik und Swing und ein neues Java Plugin (für Applets).

Am 15. Oktober fand dann die FCS statt, das Java SE 6 Update 10 ist jetzt zum Download verfügbar. Ich bin mal gespannt wie viele Probleme dieses mal auftreten werden in existierenden Anwendungen.

Interessant ist auch, dass Sun nach Jahren wieder (Anfang Oktober) ein JDK für Itanium anbietet. Die 64bit JVM wird für Linux und Windows angeboten. Im Bereich Tooling (VisualVM, JavaDB) und Plugin (Applet) sowie im Bereich Multi Media (Linux Alsa Sound) existieren allerdings starke Einschränkungen. Eignet sich so nur für den Server Einsatz. HP dürfte mit seiner JRE für IA64 aber deutlichen Optimierungsvorsprung haben.

Update: InfoQ hat einen interessanten engl. Artikel.

Ich installiere gerade eine Java Anwendung in einem Windows 2008 Server.

Dabei verwende ich ein Windows XP als Host, Sun's VirtualBox als VMM und das Windows 2008 Core Edition liegt als dynamisch wachsende virtuelle Festplatte im VHD Format vor.

Jetzt trat das Problem auf, dass der Host nicht mehr genug Speicherplatz für das wachsende Image hatte. Dies wurde dem Java Programm sauber als IOException gemeldet, aber als Reason wird (verständlicherweise) kein "file system full" oder "no space on device" gegeben, sondern die Meldung:

"The drive cannot find the sector requested"

Dies ist verständlich, wenn man sich vor Augen hält dass der IDE Treiber den Fehlerzustand an das NTFS des Guests melden muss. Ein "Kann den Sektor nicht belegen" ist so ziemlich der passendste Fehler der man sich in der Schicht denken kann.

Dieser Bug ist übrigens extrem kritisch. Im Gegensatz zur Platznot im Filesystem - von der sich das Filesystem wieder erholen kann - sind Allocation Fehler von beliebigen Sektoren deutlich kritischer, insbesondere wenn das bei Filesystem Meta Blöcken passiert statt bei Datenblöcken. Schnell kann das Filesystem dann aussteigen. Dies wiederum ist der Tot des Servers, wenn es sich dabei um System-Partition oder Swap-Partition handelt. Diese Laufwerksarten sollte man also in einer virtualisierten Umgebung niemals auf eine virtuelle Disk mit uncommited Speicher legen. Sicher kann man damit etwas Platz sparen und wenn man das ganze überwacht passiert es selten. Aber wenn es passiert, so kann man den Guest erst mal rebooten (worst case).

Virtuelle Realitäten wie Second Life werden ja schon für Geschäftsmeetings (z.B. Vorträge) genutzt. Sun arbeitet mit Project Wonderland an einer Plattform, 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.