Eine freie Java-Bibliothek zum Lesen und Schreiben von CSV-Dokumenten ist Apache Commons CSV (https://commons.apache.org/proper/commons-csv/). Sie verwaltet unterschiedliche CSV-Formate wie Microsoft Excel, RFC 4180.

Auf der Webseite gibt es einen Download-Link für das Java-Archiv, doch am einfachsten ist die Einbindung über die Maven-POM-Datei – wir fügen folgende Abhängigkeit hinzu:

<dependency>

<groupId>org.apache.commons</groupId>

<artifactId>commons-csv</artifactId>

<version>1.5</version>

</dependency>

Über die Abhängigkeit bekommen wir neue Typen im Paket org.apache.commons.csv. Mit dem CSVPrinter lassen sich CSV-Dokumente korrekt erzeugen, und er behandelt auch Fluchtsymbole korrekt. Erzeugen wir ein CSV-Dokument im Speicher:

StringBuilder appendable = new StringBuilder();

CSVFormat csvFormat = CSVFormat.EXCEL.withHeader( „DisplayName“, „ISO3Language“ );

try ( CSVPrinter csvPrinter = new CSVPrinter( appendable, csvFormat ) ) {

for ( Locale l : Arrays.copyOf( Locale.getAvailableLocales(), 5 ) )

csvPrinter.printRecord( l.getDisplayName(), l.getISO3Language() );

}

Starten wir das Programm erscheint auf der Konsole:

DisplayName,ISO3Language

„“,

Norwegisch Nynorsk,nno

Arabisch (Jordanien),ara

Bulgarisch,bul

Kabuverdianu,kea

Lesen wir das Dokument wieder ein und greifen dazu auf die Klasse CSVParser zurück. Es gibt zwei Ansätze:

1. Da CSVParser ein Iterable<CSVRecord> ist, können wir direkt die Zeilen mit dem erweiterten for Das bietet sich für größere Datenmengen an.
2. Ist die Anzahl der Daten überschaubar, liefert getRecords() eine gefüllte util.List<CSVRecord> mit alle Zeilen. Das kann praktisch sein, denn eine List hat eine stream()-Methode, sodass die Zeilen praktisch als Stream<CSVRecord> weiterverarbeitet werden können.

Zum Programm:

try ( StringReader reader = new StringReader( appendable.toString() );

CSVParser csvParser = new CSVParser( reader,

CSVFormat.EXCEL.withFirstRecordAsHeader() ) ) {

for ( CSVRecord csvRecord : csvParser )

System.out.printf( „Record=%d – %s, %s%n“,

csvRecord.getRecordNumber(),

csvRecord.get( 0 ), csvRecord.get( 1 ) );

}

Die Ausgabe ist:

Record=1 – ,

Record=2 – Norwegisch Nynorsk, nno

Record=3 – Arabisch (Jordanien), ara

Record=4 – Bulgarisch, bul

Record=5 – Kabuverdianu, kea

In der Anfangszeit verursachte Microsoft einigen Wirbel um Java. Mit Visual J++ (gesprochen »Jay Plus Plus«) bot Microsoft schon früh einen eigenen Java-Compiler (als Teil des Microsoft Development Kits) und mit der Microsoft Java Virtual Machine (MSJVM) eine eigene schnelle Laufzeitumgebung. Das Problem war nur, dass Dinge wie RMI und JNI absichtlich fehlten[1] – JNI wurde 1998 nachgereicht. Entgegen allen Standards führte der J++-Compiler neue Schlüsselwörter wie multicast und delegate ein. Außerdem fügte Microsoft einige neue Methoden und Eigenschaften hinzu, zum Beispiel J/Direct, um der plattformunabhängigen Programmiersprache den Windows-Stempel zu verpassen. Mit J/Direct konnten Programmierer aus Java heraus direkt auf Funktionen der Win32-API zugreifen und damit reine Windows-Programme in Java programmieren. Durch Integration von DirectX sollte die Internet-Programmiersprache Java multimediafähig gemacht werden. Das führte natürlich zu dem Problem, dass Applikationen, die mit J++ erstellt wurden, nicht zwangsläufig auf anderen Plattformen liefen. Sun klagte gegen Microsoft.

Da es Sun in der Vergangenheit finanziell nicht besonders gut ging, pumpte Microsoft im April 2004 satte 1,6 Milliarden US-Dollar in die Firma. Microsoft erkaufte sich damit das Ende der Kartellprobleme und Patentstreitigkeiten. Dass es bis zu dieser Einigung nicht einfach gewesen war, zeigen Aussagen von Microsoft-Projektleiter Ben Slivka über das JDK bzw. die Java Foundation Classes, man müsse sie »bei jeder sich bietenden Gelegenheit anpissen« (»pissing on at every opportunity«).[2]

Im Januar 2004 beendete Microsoft die Arbeit an J++, denn die Energie floss in das .NET-Framework und die .NET-Sprachen. Am Anfang gab es mit J# eine Java-Version, die Java-Programme auf der Microsoft .NET-Laufzeitumgebung CLR ausführt, doch Anfang 2007 wurde auch J# eingestellt. Das freie IKVM.NET (http://www.ikvm.net) ist eine JVM für .NET und verfügt über einen Übersetzer von Java-Bytecode nach .NET-Bytecode, was es möglich macht, Java-Programme unter .NET zu nutzen. Das ist praktisch, denn für Java gibt es eine riesige Anzahl von Programmen, die somit auch für .NET-Entwickler zugänglich sind. Bedauerlicherweise wird das Projekt nicht weiterentwickelt.

Microsoft hat sich lange Zeit aus der Java-Entwicklung nahezu vollständig zurückgezogen. Es waren eher überschaubare Projekte wie der Microsoft JDBC Driver for SQL Server. Das Verhältnis ist heute auch deutlich entspannter, und Microsoft geht wieder einen Schritt auf Java zu. Zu erkennen ist das am Beitritt in die Jakarta EE Working Group und an der Unterstützung von Java-Applikationen in der Windows Cloud Azure.[3] Vielleicht gratuliert Microsoft irgendwann einmal Oracle, wie es auch Linux zum 20. Geburtstag gratuliert hat.[4]

[1] http://www.microsoft.com/presspass/legal/charles.mspx

[2] Würden wir nicht gerade im westlichen Kulturkreis leben, wäre diese Geste auch nicht zwangsläufig unappetitlich. Im alten Mesopotamien steht »pissing on« für »anbeten«. Da jedoch die E‐Mail nicht aus dem Zweistromland kam, bleibt die wahre Bedeutung wohl unserer Fantasie überlassen.

[3] https://azure.microsoft.com/de-de/develop/java/

[4] http://www.youtube.com/watch?v=ZA2kqAIOoZM

Lambda-Ausdrücke können lokale Variablen nur lesen und nicht beschreiben. Der Grund hat etwas mit der Art und Weise zu tun, wo Variablen gespeichert werden: Objekt- und statische Variablen „leben“ auf dem Heap lokale Variablen und Parameter „leben“ auf dem Stack. Wenn nun Threads ins Spiel kommen ist es nicht unüblich, dass unterschiedliche Threads die Variablen vom Heap nutzen; dafür gibt es Synchronisationsmöglichkeiten. Allerdings kann ein Thread nicht auf lokale Variablen eines anderen Threads zugreifen, denn ein Thread hat erst einmal keinen Zugriff auf den Stack-Speicher eines anderen Threads. Grundsätzlich wäre das möglich, allerdings wollten die Oracle-Entwickler diesen Pfad nicht gehen. Beim Lesezugriff wird tatsächlich eine Kopie angelegt, sodass sie für einen anderen Thread sichtbar ist.

Die Einschränkung, dass äußere lokale Variablen von Lambda-Ausdrücken nur gelesen werden können, ist an sich etwas Gutes, denn die Beschränkung minimiert Fehler bei nebenläufiger Ausführung von Lambda-Ausdrücken: arbeiten mehrere Threads Lambda-Ausdrücke ab, und beschreiben diese eine lokale Variable, müsste andernfalls eine Thread-Synchronisation her.

Grundsätzlich verbietet das Schreiben von lokalen Variablen aus Lambda-Ausdrücken heraus aber nicht jede Programmiersprache. In C# kann ein Lambda-Ausdruck lokale Variablen beschreiben, sie leben dann nicht mehr auf dem Stack.

Die invokeAll(…)-Methoden aus dem ExecutorService sind praktisch, wenn es darum geht, mehrere Aufgaben nebenläufig abzusenden, und später die Ergebnisse einzusammeln. Allerdings ist die Rückgabe vom Typ List<Future<T>> und wir werden nicht informiert, wenn ein Ergebnis vorliegt. Wir können zwar die Liste immer wieder ablaufen und jedes Future-Objekte mit isDone() fragen ob es fertig ist, aber das ist keine ideale Lösung.

Mit java.util.concurrent.CompletionService gibt es eine weitere Java-Schnittstelle – die keinen Basistyp erweitert – mit der wir ein Callable oder Runnable arbeiteten lassen können und später nacheinander die Ergebnisse einsammeln können, die fertig sind. Die Java-Bibliothek bringt mit ExecutorCompletionService eine Implementierung der Schnittstelle mit, die intern die fertigen Ergebnisse in einer Queue sammelt, und wir können die Queue abfragen. Schauen wir uns das in einem Beispiel an.

ExecutorService executor = Executors.newCachedThreadPool();

CompletionService<Integer> completionService =

  new ExecutorCompletionService<>( executor );

List.of( 4, 3, 2, 1 ).forEach( duration -> completionService.submit( () -> {

  TimeUnit.SECONDS.sleep( duration );

  return duration;

} ) );



for ( int i = 0; i < 4; i++ ) {

  try {

    System.out.println( completionService.take().get() );

  }

  catch ( InterruptedException | ExecutionException e ) {

    e.printStackTrace();

  }

}

executor.shutdown();

Der Typ ExecutorCompletionService erwartet im Konstruktor einen Executor, der den Code ausführen soll; wir setzen einen Thread-Pool ein. CompletionService hat zwei submit(…)-Methoden:

• Future<V> submit​(Runnable task, V result)
• Future<V> submit​(Callable<V> task)

Abgesendet werden vier Callable-Exemplare, die 4, 3, 2, 1 Sekunden warten und ihre Wartezeit am Ende zurückgeben. Natürlich wird als erstes das Callable mit der Rückgabe 1 fertig, dann 2, usw.

Für die Rückgaben interessiert sich unser Programm nicht, denn es nutzt die take()-Methode. Insgesamt hat CompletionService drei Entnahme-Methoden:

• Future<V> take()
  Liefert das Ergebnis von der ersten abgeschlossenen Aufgabe und entfernt es von der internen Queue. Liegt kein Ergebnis an, wartet die Methode.
• Future<V> poll()
  Liefert das Ergebnis von der ersten abgeschlossenen Aufgabe und entfernt es von der internen Queue. Liegt kein Ergebnis ist, wartet poll() nicht, sondern liefert null.
• Future<V> poll​(long timeout, TimeUnit unit)
  Wartet wir take() auf ein Ergebnis, doch kommt es nach dem Ablauf von timeout nicht, liefert die Methode wie poll() als Rückgabe null.

Was der Schnittstelle fehlt ist eine Methode, die die verblendende Anzahl liefert. Wir müssen in unserem Code daher einen Zähler als extra Variable einführen.