java.io.FileDescriptor.FileDescriptor()的 JavaDoc说:
构造一个(无效的)FileDescriptor 对象。
如果构造函数没有目的,为什么它的访问级别没有声明为package-private?
java.io.FileDescriptor.FileDescriptor()的 JavaDoc说:
构造一个(无效的)FileDescriptor 对象。
如果构造函数没有目的,为什么它的访问级别没有声明为package-private?
此构造函数是公共的,因为它在java.io
.
new FileDescriptor()
在 JRE 7u4 Linux x86 中使用的类:
java.io.FileInputStream
java.io.FileOutputStream
java.io.RandomAccessFile
java.lang.UNIXProcess
java.net.AbstractPlainDatagramSocketImpl
java.net.AbstractPlainSocketImpl
java.net.ServerSocket
sun.net.sdp.SdpSupport
sun.nio.ch.FileChannelImpl
sun.nio.ch.FileDispatcherImpl
sun.nio.ch.IOUtil
sun.nio.ch.PipeImpl
sun.nio.ch.SctpServerChannelImpl
sun.nio.ch.ServerSocketChannelImpl
sun.nio.ch.UnixAsynchronousServerSocketChannelImpl
sun.nio.fs.UnixChannelFactory
有一种sun.misc.SharedSecrets
方法允许程序员将 a 的状态更改为FileDescriptor
有效状态(此代码段可在 中找到java.io.FileDescriptor
):
static {
sun.misc.SharedSecrets.setJavaIOFileDescriptorAccess(
new sun.misc.JavaIOFileDescriptorAccess() {
public void set(FileDescriptor obj, int fd) {
obj.fd = fd;
}
public int get(FileDescriptor obj) {
return obj.fd;
}
public void setHandle(FileDescriptor obj, long handle) {
obj.handle = handle;
}
public long getHandle(FileDescriptor obj) {
return obj.handle;
}
}
);
}
这意味着任何可以访问的代码SharedSecrets
(即 JRE 本身)也可以创建自己的 valid FileDescriptor
,因此应该被允许访问FileDescriptor()
。但是,没有办法将构造函数的访问权限限制为仅限 JRE 类,因此它是公共的。
您的答案可以在类级别文档中找到:
@因为JDK1.0
这也是“为什么 Number 是抽象类而不是接口”、“Vector 为什么要同步?”等问题的答案。
那些旧的类可能有也可能没有@Deprecated 警告,但Java 在删除不推荐使用的功能方面确实很软。像这样的 Cruft 不断出现,因为这些类很有用,但内部 Java 升级过程往往不会删除不推荐使用的方法,而是保留它们,因为自最初的 Java 版本以来一直保持向后兼容性。