¿Por qué ServerSocket.setSocketFactory estática?

Question

Estoy tratando de usar un SocketImpl personalizado con SSL en Java. Por eso necesito configurar el socket factory de ServerSocket. Ahora me doy cuenta de que es estático, lo que me crea problemas ya que quiero proporcionarle algunos parámetros que difieren entre cada instancia ServerSocket. ¿Alguien sabe la razón detrás de hacerlo estático? Para mí, se siente como una restricción innecesaria que solo introduce más estado global en tu aplicación.

Actualización Parece haber alguna confusión sobre por qué esto es una molestia. El problema que esto crea es que me obliga a usar la misma fábrica en toda la aplicación. ¿Qué sucede si quiero usar el SocketImpl predeterminado en un lugar y uno personalizado en otro? Eso no se puede hacer sin recurrir a algunos feos trucos de reflexión, porque la fábrica no se puede cambiar una vez que se ha establecido. Tampoco puedo hacer que mi fábrica cree la implementación predeterminada porque SocksSocketImpl es un paquete privado.

Answer 1

SocketImpl es una clase abstracta que proporciona una interfaz para implementaciones de socket de personalización. Las subclases de SocketImpl no son con la intención de crear una instancia explícita. En cambio, son creados por SocketImplFactory. La motivación para este diseño es permitirle cambiar el tipo predeterminado de socket utilizado por una aplicación completa por llamando a Socket.setSocketImplFactory(), por lo que es innecesario reescribir todo su código de red. Los sockets personalizados son necesarios para las características tales como SSL y firewall tunneling. Desafortunadamente, la naturaleza global de de setSocketImplFactory() es bastante limitado, ya que no le permite usar múltiples tipos de sockets dentro de una única aplicación . Puede solucionarlo subclasando Socket y utilizando el constructor SocketImpl protegido que se introdujo en JDK 1.1.

Referencia: http://www.devx.com/tips/Tip/26363

Answer 2

Para mí parece que tener este setter estático lo hace más fácil de usar, porque no es necesario tener una instancia de ServerSocket y le permite configurar la fábrica de Socket sin tener que hacer referencia a ella. Creo que hacer que setter global sea realmente más fácil de implementar, ¿por qué es complicado para ti?

Answer 3

Mira el Constructor of ServerSocket

Si la aplicación ha especificado una fábrica de sockets de servidor, el método createSocketImpl de que la fábrica está llamado a crear la aplicación toma real. De lo contrario, se crea un socket "simple".

Por lo tanto, tiene que ser estático, porque existe la necesidad de configurar la fábrica si desea que se use cuando está creando una nueva instancia de un zócalo.

Answer 4

se puede esperar una fábrica no estático para saber cómo crear una instancia de la clase personalizada mágicamente?

Answer 5

Esto me parece un caso clásico de Factory Pattern, en el cual se proporciona un objeto de fábrica personalizado con configuraciones que dictan cómo se crean las instancias de una determinada clase. Tiene mucho sentido que los métodos que manipulan las fábricas sean estáticos, ya que la fábrica actúa como un "metaobjeto", que dirige la creación de otros objetos.

Tener una fábrica de cada instancia simplemente no tendría sentido desde el punto de vista del diseño. ¿Cuál sería el sentido de tener una fábrica diferente por instancia? ¿Planea crear instancias de ServerSocket desde otras instancias? Si desea configuraciones diferentes, solo tendrá que suministrar una fábrica diferente cada vez.

Answer 6

Es bastante desagradable, pero podría crear un DelegatingSocketFactory que busque una copia de seguridad de la pila de llamadas a quién lo llamó y cree un SocksSocketImpl (utilizando el reflejo para ordenar la accesibilidad) o utilice el Ice4J. ¡Esto cuenta como un truco de reflexión!