streams - Por qué Java OutputStream.write() toma entero pero escribe bytes

metodo read java

Question

Estoy escribiendo un OutputStream, me di cuenta de esto en la interfaz de OutputStream,

   public abstract void write(int b) throws IOException;

Esta llamada escribe un byte al flujo, pero ¿por qué toma un entero como un argumento?

Answer 1

Así que puedes señalizar EOF:

"Observe que read () devuelve un valor int. Si la entrada es un flujo de bytes, ¿por qué no lee () devuelve un valor de byte? El uso de un int como tipo de retorno permite que read () use -1 para indicar que ha llegado al final de la corriente ".

http://java.sun.com/docs/books/tutorial/essential/io/bytestreams.html

Answer 2

En realidad he estado trabajando con bytes un poco últimamente y pueden ser molestos. Se convierten a ints a la menor provocación y no hay una designación para convertir un número en un byte, por ejemplo, 8l le dará un valor largo de 8, pero para el byte tiene que decir (byte) 8

Además de eso, (más o menos) siempre se almacenarán internamente como enteros a menos que estés usando una matriz (y tal vez incluso entonces ... no estoy seguro).

Creo que simplemente asumen que la única razón para usar un byte es i / o cuando realmente necesita 8 bits, pero internamente esperan que siempre use ints.

Por cierto, un byte puede tener un peor rendimiento, ya que siempre tiene que estar enmascarado ...

Al menos recuerdo haber leído que hace años, podría haber cambiado por ahora.

Como respuesta de ejemplo para su pregunta específica, si una función (f) tomó un byte y usted tenía dos bytes (b1 y b2), entonces:

f(b1 & b2)

no funcionaría, porque b1 y b2 se convertirían a un int, y el int no se podría convertir de forma automática (pérdida de precisión). Entonces tendrías que codificar:

f( (byte)(b1 & b2) )

Lo cual sería irritante.

Y no se moleste en preguntar POR QUÉ b1 y b2 conversos-¡He estado maldiciendo por eso un poco últimamente yo mismo!

Answer 3

Las clases de IOStream de Java han sido parte de Java desde 1.0. Estas clases solo tratan con datos de 8 bits. Mi suposición es que la interfaz fue diseñada así para que el método de escritura (int b) fuera llamado para los valores int, short, byte y char. Todos estos son promovidos a un int. De hecho, dado que la mayoría de las JVM se ejecutan en máquinas de 32 bits, la primitiva int es el tipo más eficiente para tratar. El compilador puede almacenar tipos como bytes utilizando 32 bits de todos modos. Curiosamente, byte [] realmente se almacena como una secuencia de bytes de 8 bits. Esto tiene sentido ya que una matriz podría ser bastante grande. Sin embargo, en el caso de valores primitivos únicos como int o byte, el último espacio ocupado en el tiempo de ejecución no importa realmente siempre que el comportamiento sea consistente con la especificación.

Más antecedentes:

http://www.java-samples.com/showtutorial.php?tutorialid=260

La suposición para las clases IOStream es que a la persona que llama solo le interesan realmente los 8 bits más bajos de datos, incluso cuando pasa un int. Esto está bien siempre y cuando la persona que llama sepa que realmente está tratando con bytes, pero se convierte en un problema cuando los datos subyacentes son realmente texto que utiliza alguna otra codificación de caracteres, como Unicode de múltiples bytes. Esta es la razón por la cual las clases Reader se introdujeron mucho tiempo atrás con Java 1.1. Si le importan los datos de texto y el rendimiento, las clases de IOStream son más rápidas, pero las clases de Reader son más portátiles.

Answer 4

Según javadoc para OutputStream , los 24 bits de orden superior son ignorados por esta función. Creo que el método existe por razones de compatibilidad: por lo tanto, no es necesario convertirlo primero en bytes y simplemente puede pasar un número entero.

Saludos

Answer 5

Tal vez sea porque los bytes están firmados de forma predeterminada, y los archivos almacenan bytes como valores sin firmar. Es por eso que read() devuelve un int - para dar 255 en lugar de -1 por $ FF. Al igual que con write(int) , no puede almacenar $ FF como 255 en un byte.