Files.newInputStream () inkonsequentes Verhalten, wenn der Zielpfad ein Verzeichnis ist?

HINWEIS: Bitte führen Sie den genauen Code unten aus; keine Anpassungen davon, insbesondere, verwenden Sie nicht File , da dieser Fehler an die neue java.nio.file API gebunden ist

Okay, das ist nicht wirklich eine "Frage, die eine Antwort braucht", sondern ein Ruf nach Zeugen ...

Szenario:

• haben ein Verzeichnis auf Ihrem Betriebssystem, was auch immer es ist, von dem Sie wissen, dass Sie Zugriffsrechte haben - im Unix-Sprachgebrauch haben Sie zumindest Lesezugriff darauf (was bedeutet, dass Sie die darin enthaltenen Einträge auflisten können); Im folgenden Code wird angenommen, dass der Pfad, der von System.getProperty("java.io.tmpdir") repräsentiert wird, der Rechnung entspricht;
• haben ein Oracle JDK oder OpenJDK, 7+ installiert ; damit Sie java.nio.file zu Ihrer Verfügung haben.

Nun, was der folgende Code macht ist ziemlich einfach: Er versucht Öffnen Sie ein neues InputStream in diesem Verzeichnis mit Files.newInputStream() . Code (auch verfügbar hier ; meine Kommentare wurden hinzugefügt):

OK, jetzt, wenn Sie diesen Code ausführen, geschieht dies für die folgenden JRE / OS-Kombinationen:

• Linux x86_64, Oracle JDK 1.8.0_25: IOException (is a directory) bei FAIL_READ ;
• Linux x86_64, Oracle JDK 1.7.0_72: IOException (is a directory) at FAIL_READ ;
• Mac OS X x86_64, Oracle JDK 1.8.0_25: IOException (is a directory) bei FAIL_READ ;
• Windows 7, Oracle JDK 1.8.0_25: AccessDeniedException bei FAIL_OPEN (!!).

Ehrlich gesagt, weiß ich nicht, was ich mit diesem Code tun soll. Wie ich in der Einleitung gesagt habe, suche ich hier nach Zeugen. Ich werde OpenJDK diesbezüglich sicherlich einen Fehler melden, das scheint ziemlich ernst zu sein. Ich habe auch die Mailingliste nio-dev über dieses Problem geschickt.

Nun, zu einer Frage hätte ich eine: Was ist mit einem IsDirectoryException im JDK (erbt FileSystemException )? Ich habe es tatsächlich in einem meiner Projekte definiert, um ein solches Problem zu berücksichtigen. Ich bin nicht sicher, warum dieses Problem von den "Java-Typen" nicht berücksichtigt wurde ...