Warum erfordert try-with-resource eine lokale Variable?

In Bezug auf meine Frage Gibt es ein Risiko in einem AutoCloseable-Wrapper für java.util.concurrent.locks.Lock? Ich frage mich, warum die try-with-resource-Anweisung a genannt lokale Variable überhaupt.

Meine derzeitige Nutzung ist wie folgt:

try (AutoCloseableReentrantReadWiteLock.Lock l = _lock.writeLock()) {
    // do something
}        

Die Variable l wird innerhalb des try-Blocks nicht verwendet und verschmutzt nur den Namensraum. Soweit ich mich erinnern kann, das analoge C # using-Anweisung erfordert keine lokale benannte Variable.

Gibt es einen Grund, warum Folgendes nicht unterstützt werden konnte, mit einer anonymen lokalen Variablen, die am Ende des try-Blocks geschlossen wird?

try (_lock.writeLock()) {
    // do something
}        

Der Link im Kommentar von @McDowell verrät die richtige Antwort ein Blogpost-Kommentar von Joe Darcy, der führte die Java Technology Specification die die try-with-resources-Anweisung einführte:

Zurück in JDK 7 haben wir mit einem try-with-resources-Konstrukt begonnen, das es ermöglichte, einen allgemeinen Ausdruck für die Ressource zu verwenden, einschließlich eines Methodenaufrufs. Die Expertengruppe stellte jedoch bei der frühen Überprüfung des Entwurfs fest (http://jcp.org/aboutJava/communityprocess/edr/jsr334/index.html) das

“Eine mögliche zukünftige Änderung [to the try-with-resources statemenbt] stellt die Unterstützung für eine Ressource ein, die als allgemeiner Ausdruck angegeben werden soll. Nichttriviale Spezifikations- und Implementierungskomplexitäten ergeben sich daraus, dass zugelassen wird, dass ein allgemeiner Ausdruck als Ressource verwendet wird. Ein eingeschränkter Ausdruck, der ein Bezeichner oder ein PrimaryNoNewArray sein könnte, kann ausreichen. Selbst die strengere Einschränkung, nur einen Bezeichner zuzulassen, kann fast den gesamten zusätzlichen Nutzen bieten, einen vollständigen Ausdruck zuzulassen (über das Erzwingen der Deklaration einer neuen Ressourcenvariablen) bei einer viel geringeren marginalen Implementierungs- und Spezifikationsauswirkung.

Am Ende von JDK 7 wollten wir eine neue Variablendeklaration für die Ressource oder eine vorhandene finale / effektiv finale Variable. Wir hatten nur Zeit, ersteres in 7 bereitzustellen; in 9 bieten wir auch letzteres an.

Unter den Anwendungsfällen, die sie in Betracht gezogen haben, müssten die meisten auf die Ressource innerhalb des Blocks zugreifen, z. B. Datei öffnen – Datei lesen/schreiben – Datei schließen. Sie hätten diese Designentscheidung nicht getroffen, wenn sie dachten, dass es viele Anwendungsfälle gibt, in denen die lokale Variable nicht verwendet wird.

Was die Frage betrifft, warum Lock nicht automatisch geschlossen werden kann, denke ich, dass Doug Lea sich nicht allzu sehr um Syntaxangelegenheiten kümmert, er konzentriert sich auf die Lösung des schwierigen Problems. Andere können seinen Dienstprogrammen immer noch Syntaxzucker hinzufügen.

Mit Blick auf die Zukunft wird Try-with-Ressource wahrscheinlich aus der Mode kommen und durch Lambda ersetzt werden. Zum Beispiel

lock.withLock( ()->{ execute-while-holding-the-lock; } );

So sehr ich es mir auch wünsche, der Grund dafür ist, dass das Try-with-Ressourcen ausschließlich für Operationen an dem zu entsorgenden Gegenstand gedacht ist. Es erfordert eine benannte Variable, weil es erwartet, dass Sie etwas mit dieser Variablen tun, während Sie sich innerhalb des Blocks befinden. Ich denke, es ist so, als würde der Compiler sagen: “Wenn Sie nicht vorhaben, die Ressource tatsächlich zu verwenden, warum machen Sie dann einen Versuch mit Ressourcen?”

Jetzt wissen Sie und ich ganz genau, dass wir die Ressource nicht wirklich verwenden wollen: Wir wollen vielmehr nur sicherstellen, dass sie geschlossen ist, wenn wir damit fertig sind, damit keine Entwickler herumlaufen und das System sperren. Aber wie bei so vielen Dingen mussten sie Designentscheidungen treffen, und da wir in der Minderheit waren, bekamen wir das Feature nicht.

Ich denke, dass die Unfähigkeit, lokale Variablen zu verwenden, der Auslöser für Try-with-Ressource war.

Vor Java 1.7 musste man so etwas schreiben:

InputStream in = null;
try {
    in = ....;
} finally {
    if (in != null) {
        in.close();
    }
}

Hier gibt es 2 Nachteile:

1. finally block ist lästig und muss für jede schließende Ressource nullsicher sein
2. Wir müssen Ressourcen außerhalb des Blocks deklarieren, um nur darauf zugreifen zu können finally Block. Daher erweitern wir den Bereich, in dem die Variablen zugänglich sind, was eine schlechte Praxis ist.

Try-with-Ressource-Syntax löst beide Probleme:

1. finally Block wird überhaupt nicht benötigt.
2. Die Ressourcenvariable bleibt zugänglich in try Block nur, dh wo es bekannt sein sollte.

Aus diesem Grund muss die schließbare Ressource lokal sein. Andernfalls ist einer der Hauptnachteile der try-with-resource-Syntax “deaktiviert”.