java - que - PrintWriter autoflush lógica desconcertante

printwriter in java stack overflow

Question

public PrintWriter (OutputStream out, boolean autoFlush) :

out - An output stream
autoFlush - A boolean; if true, the println, printf, or format methods
will flush the output buffer

public PrintStream (OutputStream out, boolean autoFlush) :

out - The output stream to which values and objects will be printed
autoFlush - A boolean; if true, the output buffer will be flushed
whenever a byte array is written, one of the println methods is invoked,
or a newline character or byte (''/n'') is written

¿Cuál fue el motivo para cambiar la lógica de autoflush entre estas clases?

Debido a que siempre se los considera idénticos a excepción de los momentos de codificación y "autoflush" sin flushing on print() apenas corresponde al principio de menor asombro, se producen errores tontos:
Creé un PrintWriter con autoflush activado; ¿Por qué no es autoflushing?

Answer 1

La razón por la que no fue la misma al principio fue probablemente solo un accidente. Ahora es compatibilidad hacia atrás.

Answer 2

Creo que la respuesta está en la historia de Java. El trío InputStream , OutputStream y PrintStream en PrintStream se remontan a Java 1.0. Eso es antes de que se incorporara un soporte serio para codificaciones de archivos y juegos de caracteres en el lenguaje.

Para citar el Javadoc:

"Un PrintStream agrega funcionalidad a otro flujo de salida, es decir, la capacidad de imprimir representaciones de varios valores de datos de manera conveniente. También se proporcionan otras dos características. A diferencia de otros flujos de salida, un PrintStream nunca arroja una excepción IOException; bandera que se puede probar mediante el método checkError ... "

Para resumir, es una conveniencia para generar resultados textuales, injertados sobre el nivel IO inferior.

En Java 1.1, se introdujeron Reader , Writer y PrintWriter . Todos ellos admiten juegos de caracteres. Si bien InputStream y OutputStream aún tenían un uso real (procesamiento de datos sin PrintStream ), PrintStream volvió mucho menos relevante, ya que la impresión por naturaleza es sobre texto.

El Javadoc para PrintWriter establece explícitamente:

A diferencia de la clase PrintStream, si el lavado automático está habilitado, se realizará solo cuando se invoque uno de los métodos println (), en lugar de cuando se produzca un resultado de un carácter de nueva línea. Los métodos println () usan la propia noción de separador de línea de la plataforma en lugar del carácter de nueva línea.

Dicho de otra manera, PrintWriter solo debe usarse a través de las API print*(...) , ya que escribir caracteres de nueva línea, etc., no debe ser responsabilidad del que llama, de la misma forma que lidiar con codificaciones de archivos y juegos de caracteres no es responsabilidad de quien llama.

Yo diría que PrintWriter debería haber sido java.io.Printer lugar, y no haber extendido Writer . No sé si se extendieron para imitar a PrintStream , o porque estaban estancados en mantener el idioma del diseño de la tubería.