Nicht nur ich bin selbstreferentiell. Auch die bayrische Staatsparteizentrale der CSU schaut nach, ob über die Tributzahlungen berichtet wird:

  mail.csu-bayern.de - - [14/Nov/2005:14:16:24 +0100] "GET /blog/ HTTP/1.0" 200 78849 
  "http://www.google.de/search?hl=de&q=bayerischer+weihnachtsbaum&meta=" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 

Im Bereich der Entwicklung von Java APIs ist die Verwendung der Klasse java.io.File zu vermeiden. Insbesondere dann, wenn ausschliesslich Konfigurationsdaten ausgelesen werden sollen (read-only). File definiert immer eine Referenz auf eine Datei im Dateisystem des Rechners, auf welchem ein Programm gestartet wird. Dies bedeutet, dass Konfigurationsdaten in diesem Dateisystem abgelegt sein müssen. Soll ein solches Programm auf vielen Rechnern gleichzeitig arbeiten, beispielsweise in einer Clusterumgebung, wird hier das Deployment unnötig erschwert. Zwar ist es möglich, dass die Konfigurationsdaten über ein Netzwerkdateisystem wie zum Beispiel NFS oder CIFS in das Dateisystem des Rechners gemounted werden. Abhängig von einem Dateisystem ist man trotzdem. Ebenso ist die Verwendung von File in Containerumgebungen (Web oder EJB) problematisch, da hier die Einstellungen des SecurityManagers, der Benutzung der API einen Strich durch die Rechnung machen kann.

Um in diesem Bereich die Virtualisierung zu verbessern, ist auf java.io.File komplett zu verzichten. Auf Konfigurationsdaten soll vielmehr mit einer Kombination aus java.net.URL und java.io.InputStream (oder Reader) zugegriffen werden. Diese beiden erlauben eine stärkere Unabhängigkeit der Daten von Ort und Zugriffstechnik.

Sind die Daten zu gross oder lassen unsauber definierte APIs die Verwendung von InputStream und URL nicht zu, dann sollte man überlegen, ob diese nicht vor der Benutzung der API in ein temporäres Verzeichnis zu kopieren sind. Den Ort des temporären Verzeichnisses, welches das Betriebssystem zur Verfügung stellt, kann man mittels des System-Properties java.io.tmpdir ermitteln. Hierbei ist allerdings Vorsicht geboten, wenn sich die API auch in einem Container deployen lassen soll, da es zu SecurityExceptions kommen kann. Zu beachten ist ebenfalls, dass die Daten in diesem Fall in ein Verzeichnis zu schreiben sind, dessen Name einen starken Zufallsbestandteile enthält. Dies soll Angriffe mittels bereits vorhandener und modifizierter Daten verhindern.

APIs, die auch Daten in Dateien schreiben müssen, sollen ebenfalls auf File verzichten. Hier ist es angebracht ausschliesslich die Datenströme aus java.io, oder alternativ die NIO-API, zu verwenden.