Perché Java OutputStream.write() Prende Integer ma scrive Byte

Question

sto scrivendo un OutputStream, appena notato questo nell'interfaccia OutputStream,

public abstract void write(int b) throws IOException; 

Questa chiamata scrittura un byte nel flusso, ma perché ci vuole intero come un argomento?

Answer 1

In realtà ultimamente ho lavorato con i byte un po 'e possono essere fastidiosi. Si convertono in upts alla minima provocazione e non c'è designazione per trasformare un numero in un byte - per esempio, 8l ti darà un valore lungo 8, ma per byte devi dire (byte) 8

Inoltre, saranno (più o meno) sempre archiviati internamente come intevi a meno che non si stia utilizzando un array (e forse anche allora .. non sono sicuro).

Penso che basti pensare che l'unico motivo per utilizzare un byte è l'I/O in cui sono effettivamente necessari 8 bit, ma internamente si aspettano che tu usi sempre gli Ints.

Tra l'altro, un byte può eseguire peggio dal momento che ha sempre da mascherare ...

Almeno io ricordo di aver letto che anni fa, avrebbe potuto cambiare da ora.

Come esempio risposta per la tua domanda specifica, se una funzione (f) ha preso un byte, e si aveva due byte (B1 e B2), quindi:

f(b1 & b2) 

non avrebbe funzionato, perché b1 & b2 verrebbe convertito in up ad un int, e l'int non potrebbe essere down-convertito automaticamente (perdita di precisione). Quindi dovresti scrivere il codice:

f((byte)(b1 & b2)) 

Quale sarebbe irritante.

E non preoccupatevi di chiedere PERCHÉ b1 & b2 up-converte - Ho fatto un po 'di maleducazione ultimamente io stesso!

Answer 2

in base a javadoc per OutputStream, i 24 bit di ordine superiore vengono ignorati da questa funzione. Penso che il metodo esista per ragioni di compatibilità: quindi non è necessario convertire prima il byte e si può semplicemente passare un intero.

riguarda

Answer 3

Così si può segnalare EOF:.

"Si noti che read() restituisce un valore int Se l'input è un flusso di byte, perché non legge() restituisce un valore di byte ? Utilizzare un int come un tipo di ritorno consente a read() di usare -1 per indicare che ha raggiunto la fine del flusso. "

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

Answer 4

Le classi Java iostream sono stati una parte di Java, in quanto 1.0. Queste classi si occupano solo di dati a 8 bit. La mia ipotesi è che l'interfaccia sia stata progettata in questo modo in modo che il metodo one write (int b) venga chiamato per i valori int, short, byte e char. Questi sono tutti promossi a un int. Infatti poiché la maggior parte delle JVM funzionano su macchine a 32 bit, la primitiva int è il tipo più efficiente da gestire. Il compilatore è libero di memorizzare tipi come byte usando comunque 32 bit. È interessante notare che byte [] è in realtà memorizzato come una sequenza di byte da 8 bit. Questo ha senso dal momento che un array potrebbe essere abbastanza grande. Tuttavia, nel caso di singoli valori primitivi come int o byte, lo spazio finale occupato in fase di esecuzione non è importante purché il comportamento sia coerente con le specifiche.

più di fondo:

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

Il presupposto per le classi iostream è che il chiamante si preoccupa veramente solo circa più bassi 8 bit di dati, anche quando si passa in un int. Questo va bene finchè il chiamante sa che ha a che fare con i byte, ma diventa un problema quando i dati sottostanti sono in realtà testo che usa qualche altra codifica di caratteri come Unicode multi-byte. Questo è il motivo per cui le classi Reader sono state introdotte più indietro con Java 1.1. Se ti interessano dati di testo e prestazioni, le classi IOStream sono più veloci, ma le classi di Reader sono più portabili.

Answer 5

Forse perché i byte sono firmati per impostazione predefinita e i file archiviano i byte come valori non firmati. Ecco perché read() restituisce un int - per dare 255 anziché -1 per $ FF. Lo stesso con write(int), non è possibile memorizzare $ FF come 255 in un byte.