为什么使用资源的尝试需要局部变量？

Question

关于我的问题AutoCloseable包装器对java.util.concurrent.locks.Lock有任何风险吗？，我想知道为什么try- With语句需要一个命名的局部变量。

我目前的用法如下：

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

变量l在try块中未使用，只会污染命名空间。据我所知，类似的C# using-statement不需要局部变量。

是否有任何理由不能支持以下内容，并在try块末尾关闭匿名局部变量？

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

Answer 1

@McDowell评论中的链接在博客评论中揭示了乔·达西( Joe )的正确答案，达西领导的Java技术规范引入了“用资源进行尝试”的声明：

在JDK 7中，我们首先使用了一个具有资源的try-结构，这样可以为资源使用一个通用表达式，包括一个方法调用。然而，专家组在早期的审查草案(http://jcp.org/aboutJava/communityprocess/edr/jsr334/index.html)中发现 “未来对具有资源的尝试状态的一个可能的改变是放弃对资源指定为通用表达式的支持。不平凡的规范和实现复杂性来自于允许将通用表达式用作资源。一个可能是标识符或PrimaryNoNewArray的受限表达式可能就足够了。即使是允许标识符的更严格的限制，也可能提供几乎所有允许完整表达式(通过强制声明新的资源变量)的额外效用，从而降低边际实现和规范的影响。” 在JDK 7的末尾，我们想要的是资源的一个新变量声明，或者一个现有的最终/有效的最终变量。我们只有时间提供前者在7；在9，我们也提供后者。

Answer 2

在他们正在考虑的用例中，大多数需要访问块内的资源，例如，打开文件-读/写文件关闭文件。如果他们认为有很多局部变量未使用的用例，他们就不会做出这个设计决策。

至于为什么Lock不能自动关闭，我认为Doug并不太关心语法问题，他专注于解决这个难题。其他人总是可以在他的实用程序之上添加语法糖。

展望未来，资源的尝试很可能会过时，取而代之的是兰博达。例如

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

Answer 3

尽管我希望它不是，但其背后的理由是，试用资源的目的是严格针对必须处理的项目上的操作。它需要一个命名变量，因为它期望您在块内使用该变量执行一些操作。我猜这就像编译器说“如果你不打算真正使用资源，你为什么要尝试-使用-资源？”

现在你和我都很清楚，我们不想真正使用这个资源，相反，我们只是想确保它在我们完成的时候是关闭的，这样我们就不会让开发人员在锁定系统时运行。但就像很多事情一样，他们不得不做出设计决策，而我们却没有得到这个特性。