java.io.FileDescriptor.FileDescriptor()のJavaDocは次のように述べています。
(無効な)FileDescriptorオブジェクトを構築します。
コンストラクターの目的がない場合、アクセスレベルがパッケージプライベートとして宣言されていないのはなぜですか?
java.io.FileDescriptor.FileDescriptor()のJavaDocは次のように述べています。
(無効な)FileDescriptorオブジェクトを構築します。
コンストラクターの目的がない場合、アクセスレベルがパッケージプライベートとして宣言されていないのはなぜですか?
このコンストラクターは、の外部で使用されるため、パブリックです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自体)も独自の有効なコードを作成できるFileDescriptor
ため、アクセスを許可する必要があることを意味しますFileDescriptor()
。ただし、コンストラクターのアクセスをJREクラスのみに制限する方法はないため、パブリックです。
あなたの答えはクラスレベルのドキュメントで見つけることができます:
@since JDK1.0
これは、「Numberがインターフェースではなく抽象クラスである理由」、「Vectorが同期される理由」などの質問に対する回答でもあります。
その古いクラスには@Deprecated警告がある場合とない場合がありますが、Javaは非推奨の機能の削除が非常にソフトです。このようなCruftは、クラスが有用であるために表示され続けますが、内部Javaアップグレードプロセスは非推奨のメソッドを削除しない傾向がありますが、最初のJavaリリース以降ずっと下位互換性を維持するためにそれらを維持します。