问题标签 [try-with-resources]

我在 Java servlet 类中有一个 try-catch 语句。Netbeans 对此显示错误：

-source 1.6 不支持 try-with-resources（使用 -source 7 或更高版本来启用 try-with-resources）

我怎样才能摆脱这个错误？

我预计XMLStreamReader会AutoCloseable在 Java 7 中找到。但是，事实并非如此。没有（或不应该）改装 StAX 读/写器接口以实施是否有技术原因AutoCloseable？他们已经有了 close 方法，其意图与AutoCloseable.

使用带有 try-with-resources 构造的 Java 7u5，以下代码似乎会泄漏 jdbc 连接：

下一段代码按预期工作：

似乎在第一种情况下，该Connection.close()方法没有被调用。

我正在使用最新的 mysql 连接器。这是出乎意料的行为，对吗？

测试

以下测试不会打印CLOSED：

奇怪的是，如果execute()修改为return 0;thenCLOSED 将被打印。

javap -p -c Test.class 输出

我是.net 开发人员。最近，我对比较 java 和 c# 产生了兴趣。我发现 Java 的 try-with-resources 相当于 C# 的 using 块。但是，我无法完全理解它。我知道 C# 的 using 块是一种语言功能，编译器会为它生成代码。我想更多地了解 try-with-resources 并且对此有几个问题：

1. 它是类似于 C# 的 using 块的语言功能吗？

2. 以下内容的等效 JDK 6 代码是什么：

   /li>

3. 以下内容的等效 JDK 6 代码是什么：

   /li>

4. 什么是 C# 的 Reflector 或 ILSpy 工具的 Java 等价物？即反汇编Java字节码类文件并查看其Java代码的工具。

这个新的 Java 7 try-with-resources 结构非常好。或者至少，在一个例外出现并毁了我的一天之前，这很好。

我终于设法将它归结为一个可重复的测试，它只使用 JUnit+jMock。

运行这个例子，我得到：

阅读文档，他们似乎在说，如果您要向自身添加一个抑制的异常，那就是触发此错误的原因。但我没有这样做，我只是在使用 try-with-resources 块。Java 编译器然后生成看似非法的代码，这使得该功能实际上无法使用。

当然，当测试通过时，不会出现问题。而当测试失败时，就会发生异常。所以现在我已经解决了我最初发现的问题，我已经恢复使用 try-with-resources。但是下次发生异常时，我更希望异常是期望失败，而不是一个 Java 本身似乎没有充分的理由发出。

那么......有没有办法在这里得到正确的错误报告，而不放弃尝试资源？

在 Java 7 中使用 try-with-resources 时，是否可以保证.close()调用的顺序？

以下是来自 Oracle 的一些示例代码，展示了此功能：

两者都zf.close()将writer.close()被调用。订单有保障吗？

Java 7 try-with-resources语法（也称为 ARM 块（自动资源管理））在仅使用一个AutoCloseable资源时非常好、简短且直接。但是，当我需要声明多个相互依赖的资源时，我不确定什么是正确的习惯用法，例如包装它的 aFileWriter和 a 。BufferedWriter当然，这个问题涉及AutoCloseable包装某些资源的任何情况，而不仅仅是这两个特定的类。

我想出了以下三个替代方案：

1)

我见过的幼稚习惯用法是仅在 ARM 管理的变量中声明顶级包装器：

这很好，很短，但它被打破了。因为底层FileWriter没有在变量中声明，所以它永远不会在生成的finally块中直接关闭。它只会通过closewrapping 的方法关闭BufferedWriter。bw问题是，如果从的构造函数中抛出异常，close则不会调用它，因此FileWriter 不会关闭底层。

2)

在这里，底层资源和包装资源都声明在 ARM 管理的变量中，所以它们都肯定会被关闭，但底层fw.close() 会被调用两次：不仅直接调用，还通过 wrapping调用bw.close()。

对于这两个都实现的特定类Closeable（它是 的子类型AutoCloseable）来说，这应该不是问题，它们的合同规定close允许多次调用：

关闭此流并释放与其关联的任何系统资源。如果流已经关闭，则调用此方法无效。

但是，在一般情况下，我可以拥有仅实现AutoCloseable（而不是Closeable）的资源，这不能保证close可以多次调用：

请注意，与 java.io.Closeable 的 close 方法不同，此 close 方法不需要是幂等的。换句话说，多次调用此 close 方法可能会产生一些可见的副作用，这与 Closeable.close 不同，如果多次调用则要求无效。但是，强烈建议此接口的实现者使他们的 close 方法具有幂等性。

3)

这个版本理论上应该是正确的，因为只有fw代表需要清理的真实资源。本身不持有任何资源，bw它只委托给fw，所以只关闭底层就足够了fw。

另一方面，语法有点不规则，而且 Eclipse 发出警告，我认为这是一个误报，但它仍然是一个必须处理的警告：

资源泄漏：'bw' 永远不会关闭

那么，该采用哪种方法呢？还是我错过了其他一些正确的成语？

我使用 Linux Debian 2.6.32-5-amd64。我的 Eclipse 版本：4.2.0 我的 Java 版本：jdk1.7.0_07

当我构建我的项目时，我收到错误：

我将编译器合规级别设置为 1.7。怎么了？是问题吗？

我正在尝试编写一些具有以下基本形式的简单套接字代码 -

我的问题是套接字正在关闭，但我认为不应该。try-with-resources 创建了一个 BufferedReader，然后在我离开 try 块时自动关闭它，但由于某种原因，它也关闭了整个套接字！因此，当我稍后使用相同的套接字访问我的响应代码时，我得到了一个异常。有没有什么办法解决这一问题？还是我只需要不使用 try-with-resources （这不太理想）？

澄清：由于来自 Eclipse 的消息，我什至无法编译。第一个代码片段：input并且inputBuffer无法识别。第二个代码片段，Eclipse 要我切换开关“Compliance and JRE to 1.7”

我是 try-with-resources 的新手，我不太理解语法或我做错了什么。这是我的代码

finally 块不起作用，所以我想尝试

然而

• 我还应该将 BufferedReader 添加到try (...)...但是如何？

• 这也需要我将“Compliance and JRE to 1.7”切换。到目前为止，我不知道这意味着什么以及这将如何影响我的程序，在有人解释这一切意味着什么或者我做错了什么之前，我不愿意这样做。

编辑

我在 try 块之前移动了声明并用 null 初始化，这是“ok”吗？