Perché Java OutputStream.write () accetta numeri interi ma scrive byte

Question

Sto scrivendo un OutputStream, l'ho appena notato nell'interfaccia OutputStream,

   public abstract void write(int b) throws IOException;

Questa chiamata scrive un byte nello stream ma perché accetta un intero come argomento?

Answer 1

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

Inoltre, saranno (praticamente) sempre memorizzati internamente come ints a meno che tu non stia usando un array (e forse anche allora ... non ne sono sicuro).

Penso che presumano praticamente che l'unica ragione per usare un byte sia l'I / O dove in realtà hai bisogno di 8 bit, ma internamente si aspettano che tu usi sempre gli ints.

A proposito, un byte può funzionare peggio poiché deve sempre essere mascherato ...

Almeno ricordo di averlo letto anni fa, ormai potrebbe essere cambiato.

Come risposta di esempio per la tua domanda specifica, se una funzione (f) ha preso un byte e hai avuto due byte (b1 e b2), quindi:

f(b1 & b2)

non funzionerebbe, perché b1 & amp; b2 verrebbe convertito in up in un int e int non può essere convertito in down automaticamente (perdita di precisione). Quindi dovresti codificare:

f( (byte)(b1 & b2) )

Che sarebbe irritante.

E non preoccuparti di chiedere PERCHÉ b1 & amp; b2 up-convertts - Ultimamente me ne sono pentito un po 'da solo!

Answer 2

Quindi puoi segnalare EOF:

" Nota che read () restituisce un valore int. Se l'input è un flusso di byte, perché read () non restituisce un valore byte? L'uso di un int come tipo restituito consente a read () di usare -1 per indicare che ha raggiunto la fine del flusso. & Quot;

http://java.sun.com/docs/ libri / tutorial / essenziali / IO / bytestreams.html

Answer 3

secondo javadoc per OutputStream , i 24 bit di ordine superiore vengono ignorati da questa funzione. penso che il metodo esista per motivi di compatibilità: pertanto non è necessario convertire prima in byte e si può semplicemente passare un numero intero.

Per quanto riguarda

Answer 4

Le classi Java IOStream fanno parte di Java dalla 1.0. Queste classi trattano solo 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, l'int primitive è il tipo più efficiente da gestire. Il compilatore è libero di memorizzare tipi come byte usando comunque 32 bit. È interessante notare che byte [] è davvero memorizzato come una sequenza di byte a 8 bit. Questo ha senso poiché 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 ha importanza, purché il comportamento sia coerente con le specifiche.

Più sfondo:

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

Il presupposto per le classi IOStream è che il chiamante si preoccupi davvero solo degli 8 bit di dati più bassi anche quando passa a un int. Questo va bene fino a quando il chiamante sa che ha davvero a che fare con i byte, ma diventa un problema quando i dati sottostanti sono in realtà testo che utilizza qualche altra codifica di caratteri come Unicode multi-byte. Questo è il motivo per cui le classi Reader sono state introdotte con Java 1.1. Se ti interessano i dati di testo e le prestazioni, le classi IOStream sono più veloci, ma le classi 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. Questo è il motivo per cui read () restituisce un int - per dare 255 invece di -1 per $ FF. Lo stesso con write (int) , non è possibile memorizzare $ FF come 255 in un byte.