¿Por qué el constructor de java.io.FileDescriptor es público?

Question

Javadoc para java.io.FileDescriptor.FileDescriptor() dice:

construye una (no válido) FileDescriptor objeto.

Si no hay un propósito para el constructor, por eso es que es el nivel de acceso no declarados paquete-privada?

Answer 1

Este constructor es público porque se usa fuera de java.io.

clases usando new FileDescriptor() en x86 JRE 7u4 Linux:

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 

hay un método sun.misc.SharedSecrets que permite que el programador para cambiar el estado de un FileDescriptor a una válida (este fragmento encontrado en 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; 
       } 
      } 
     ); 
    } 

Esto significa que cualquier código que se puede acceder SharedSecrets (es decir, el propio JRE) puede también crear su propio válida FileDescriptor, y por lo tanto se debe permitir el acceso a FileDescriptor(). Sin embargo, no hay forma de restringir el acceso de un constructor a solo clases JRE, por lo que es público.

Answer 2

Su respuesta se puede encontrar en la documentación de nivel de clase:

@since JDK1.0

Ésta es también la respuesta a preguntas como "¿Por qué es el número de una clase abstracta en lugar de una interfaz", "¿Por qué está sincronizado Vector?", Etc.

Las clases que son tan antiguas pueden tener o no advertencias @Deprecated, pero Java ha sido muy suave en la eliminación de las características obsoletas. Cruft como este sigue apareciendo porque las clases son útiles, pero el proceso interno de actualización de Java tiende a no eliminar los métodos obsoletos, sino a mantenerlos, ya que mantiene la compatibilidad con versiones anteriores desde la versión inicial de Java.