为什么autocoseable是Closeable的基本接口（反之亦然）？
据我所知，Closeable接口大约是从Java1.5开始的，而AutoCloseable是在Java1.7中引入的。
我想理解的是为什么Closeable扩展了AutoCloseable而不是相反？这样做是不是因为向后依赖（不能更改可关闭接口），即AutoCloseable需要比Closeable有更广泛的例外？还是我的逻辑错了，事情应该是这样的？
共有1个答案
通过这种方式，实现closeable的所有用户代码都将自动实现autocoseable，这允许他们自动受益于try-with-resources语法。
-
我今天遇到了一些奇怪的事情。下面的代码编译意外，运行正常。 但这一条给出了编译错误 有人能解释一下这种行为吗？
-
问题内容： 在一个Android应用中，我将此代码添加到 onCreate（） 进口是： 代码可以编译，但是出现异常： 在不同的上下文中，故障会导致（即 _java.lang.ArrayStoreException：java.net.Socket无法存储在类型为java.io.Closeable []的数组中_ ）。 我想念什么吗？知道该怎么办吗？ 编辑 类似，当按原样使用时，它会导致 java.
-
下面的代码通过一些位黑客执行快速平方根倒数运算。该算法可能是由硅图形在20世纪90年代初开发的，它也出现在了《雷神之锤3》中。更多信息 然而，我从GCC C编译器那里得到以下警告:取消引用类型双关指针将违反严格的别名规则 在这种情况下，我应该使用，还是？
-
Mesos是一个两级调度程序。当然，它从每台机器获取资源信息，并将其提供给顶级调度器，这样像kubernetes这样的框架就可以用来跨机器调度容器，但是kubernetes本身可以跨机器调度容器（在这方面不需要Mesos）。那么Apache Mesos能做的Kubernetes做不到或反之亦然的事情有哪些呢？
-
问题内容： 为什么我的内部类中没有接口？为什么是天生的？抱歉，如果这是一个愚蠢的问题，我已经尽力一遍又一遍地用Google搜索，但似乎无法将其包裹在脑海中。如为什么不能在内部类/局部类中声明这些？ 同样作为一个确认，我们在接口中可以包含静态最终变量的原因是因为它们未指定状态或任何此类实现权？如果我们输了而只使用了final，那么我们需要一个没有意义的实例，因为您无法实例化接口。抱歉，我真的很困惑，
-
# 11.1 接口是什么 Go 语言不是一种 “传统” 的面向对象编程语言：它里面没有类和继承的概念。 但是 Go 语言里有非常灵活的 接口 概念，通过它可以实现很多面向对象的特性。接口提供了一种方式来 说明 对象的行为：如果谁能搞定这件事，它就可以用在这儿。 接口定义了一组方法（方法集），但是这些方法不包含（实现）代码：它们没有被实现（它们是抽象的）。接口里也不能包含变量。 通过如下格式定义接