Dlaczego konstruktor java.io.FileDescriptor jest publiczny?

Question

JavaDoc dla java.io.FileDescriptor.FileDescriptor() mówi:

Konstruuje (nieprawidłowy) obiektu deskryptora pliku.

Jeśli nie ma cel dla konstruktora, dlaczego nie jest to poziom dostępu uznane za pakiet-prywatnego?

Answer 1

Ten konstruktor jest publiczny, ponieważ jest używany poza java.io.

Ćwiczenia wykorzystujące new FileDescriptor() w 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 

Jest sun.misc.SharedSecrets metoda, która pozwala programiście zmienić stan na FileDescriptor do ważnego jeden (ten fragment znaleźć w 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; 
       } 
      } 
     ); 
    } 

Oznacza to, że każdy kod, który może uzyskać dostęp do SharedSecrets (np. Sam JRE), może również utworzyć własny poprawny FileDescriptor, dlatego powinien mieć dostęp FileDescriptor(). Jednak nie ma możliwości ograniczenia dostępu konstruktora tylko do klas JRE, więc jest on publiczny.

Answer 2

Twoja odpowiedź można znaleźć w dokumentacji poziomie klasy:

@since JDK1.0

Jest to również odpowiedź na takie pytania jak „Dlaczego Ilość klasą abstrakcyjną zamiast interfejsu” "Dlaczego wektor jest zsynchronizowany?", Itp.

Klasy, które są tak stare, mogą mieć lub nie mieć @Deprecated ostrzeżenia na nich, ale Java jest bardzo miękka w usunięciu przestarzałych funkcji. Cruft w ten sposób pojawia się, ponieważ klasy są przydatne, ale wewnętrzny proces aktualizacji Java raczej nie usuwa przestarzałych metod, ale zachowuje je, ponieważ zachowuje kompatybilność wstecz aż do początkowej wersji Java.