Algoritmer og datastrukturer A.1 Filbehandling på bit-nivå

Transkript

1 Vedlegg A.1 Filbehandling på bit-nivå Side 1 av 9 Algoritmer og datastrukturer A.1 Filbehandling på bit-nivå A.1 Filbehandling på bit-nivå A.1.1 Sammendrag Klassen BitInputStream gjør det mulig å lese en fil (og andre datasekvenser) på bitnivå, dvs. lese én og én bit, eller et variabelt antall biter, om gangen. Tilsvarende gjør klassen BitOutputStream det mulig å skrive til en fil (og andre ut-enheter) bitvis. Dette sammendraget inneholder en kort diskusjon av det viktigste i de to klassene. En mer detaljert gjennomgang av class BitInputStream finner du i Avsnitt A.1.2 til Avsnitt A.1.6 og av class BitOutputStream i Avsnitt A.1.7. En instans av BitInputStream kan knyttes til en fil med navn "innfil.xyz" enten ved hjelp av en konstruktør eller ved hjelp av en fabrikasjonsmetode (eng: factory method): BitInputStream inn = new BitInputStream("innfil.xyz"); BitInputStream inn = BitInputStream.fromFile("innfil.xyz"); Klassen bruker et internt buffer (med standardstørrelse på 4kb) for å effektivisere fil-lesingen og har på lik linje med andre stream-klasser en close-metode som skal brukes når fil-lesingen er ferdig. Lesingen av biter skjer normalt med en av flg. tre metoder: public int readbit() public int read() public int readbits(int numberofbits) Den første metoden leser én bit om gangen og returnerer 0 hvis det var en 0-bit og 1 hvis det var en 1-bit. Den andre metoden leser nøyaktig 8 biter (1 byte) og fungerer slik som read er beskrevet i class InputStream i java.io. Den siste metoden leser et ønsket antall biter og de blir returnert som de bakerste bitene i et heltall. Resten av heltallet (de forreste bitene) består kun av 0-biter. Metoden kan maksimalt lese 31 biter om gangen, dvs. parameterverdien numberofbits må være mindre enn eller lik 31. Alle de tre read-metodene returnerer -1 hvis det er færre biter igjen enn det som skal leses. For den første read-metoden, der det skal leses én bit, betyr det at vi har kommet til slutten (end of file). Hvis -1 kommer som returverdi fra de to andre read-metodene, behøver ikke bety at vi har kommet til slutten av filen. Det betyr bare at det er færre biter igjen enn det antallet som ønskes lest. Metoden int available() forteller til enhver tid hvor mange biter som er igjen. I enkelte anvendelser er det gunstig å kunne «legge tilbake» en eller flere av de bitene som nettopp har blitt lest. Klassen har tre metoder for dette: public void unreadbit() public void unreadbits() public void unreadbits(int numberofbits)

2 Vedlegg A.1 Filbehandling på bit-nivå Side 2 av 9 Den første legger tilbake den sist leste biten, den andre resten av de leste bitene og den siste legger tilbake et ønsket antall av de sist leste bitene. Det kan aldri legges tilbake flere biter enn dem som sist ble lest. Metoden int unreadsize() forteller til enhver tid hvor mange biter som kan legges tilbake. Se mer om dette på Java API-en for class BitInputStream. En instans av BitOutputStream knyttes til en fil med navn "utfil.xyz" enten ved hjelp av en konstruktør eller ved hjelp av en fabrikasjonsmetode (eng: factory method): BitOutputStream ut = new BitOutputStream("utfil.xyz"); BitOutputStream ut = BitOutputStream.toFile("utfil.xyz"); Også denne klassen bruker en buffer-teknikk for å effektivisere bithåndteringen og filskrivingen. Her har byte-bufferet en standardstørrelse på 4kbb. Det er helt essensielt at en instans av BitOutputStream «lukkes» ved hjelp av close-metoden når fil-skrivingen er ferdig. Et kall på close sørger samtidig for at klassens interne bufferere «tømmes», dvs. at alt som ligger der skrives ut. Skrivingen av biter kan skje med hjelp av en av flg. fem metoder: public void write0bit() public void write1bit() public void writebit(int bit) public void write(int b) public void writebits(int value, int numberofbits) Hver av de tre første metodene skriver ut nøyaktig én bit. Den første en 0-bit, den andre en 1 -bit og den tredje skriver ut den siste biten i parameterverdien bit. Det betyr f.eks. at write1bit() og writebit(1) vil ha samme effekt. Metoden write(int b) skriver ut nøyaktig 8 biter (1 byte), dvs. de 8 siste bitene i parameterverdien b. Den fungerer slik som write er beskrevet i class OutputStream i java.io. Den siste metoden skriver ut et ønsket antall biter, dvs. de siste numberofbits biter (maksimalt 32) fra parameterverdien value. Se mer om dette på Java API-en for class BitOutputStream. A.1.2 Sekvenser av biter og class BitInputStream En fil er en sekvens med byter. Men hver byte består av 8 biter og dermed kan vi også se på en fil som en sekvens av biter. Det er imidlertid ikke mulig å lese biter enkeltvis fra en fil og det er heller ikke mulig å skrive en og en bit til en fil. Ved filbehandling er en byte den minste enheten vi kan arbeide med. Det vil imidlertid være situasjoner der det er aktuelt å arbeide både med biter enkeltvis og med bitsamlinger med et variabelt antall biter. Dette kan vi gjøre ved hjelp av bitoperatorene i Java. Ved hjelp av dem kan vi også lage egne klasser for filbehandling der skriv- og lesmetodene arbeider med et variabelt antall biter. Klassen BitInputStream er spesiallaget for å kunne arbeide med sekvenser av biter eller med det som også kalles en strøm (eng: stream) av biter. En fil kan betraktes som en sekvens eller strøm av biter. Men det er også andre eksempler. I en byte-tabell (eng: byte array) ligger bytene fortløpende bortover og dermed (1 byte = 8 biter) blir det en sekvens av biter.

3 Vedlegg A.1 Filbehandling på bit-nivå Side 3 av 9 A.1.3 Instansiering av BitInputStream Klassen BitInputStream har fire konstruktører og to fabrikasjonsmetoder (eng: factory methods): public BitInputStream(InputStream in) public BitInputStream(String filename) public BitInputStream(InputStream in, int size) public BitInputStream(String filename, int size) public static BitInputStream fromfile(string filename) public static BitInputStream frombytearray(byte[] b) BitInputStream bruker et internt buffer for å gjøre fil-lesingen mest mulig effektiv. Når bufferet er tomt blir det fylt ved hjelp én leseoperasjon. Dermed blir antallet leseoperasjoner kraftig redusert. En fil kan ligge på en harddisk, på en diskett, på en CD eller kanskje på Internett. Operasjoner på slike yttre enheter går alltid vesentlig saktere enn operasjoner internt i datamaskinen, og derfor er det lønnsomt å ha få av dem. De første konstruktørene trenger en InputStream eller et filnavn som parameter og bruker en standardverdi på 4kb (= 4096 byter) som intern bufferstørrelse. I de to neste kan en selv velge bufferstørrelse. Det er plattformavhengig hva som er den mest gunstige bufferstørrelsen. Det henger sammen med hvor mange byter det er mulig å lese fra f.eks. harddisken i én leseoperasjon. En bufferstørrelse på 4kb vil kunne fungere bra i de fleste tilfeller. De to fabrikasjonsmetodene er litt annerledes. Den første knytter en BitInputStream til en fil med oppgitt filnavn, og bruker standard bufferstørrelse. Den andre bruker en byte-tabell som den bitsekvensen det skal leses fra. Der blir bufferstørrelsen satt lik byte-tabellens lengde så sant den ikke er større enn standard bufferstørrelse. Hvis vi skal knytte en instans av BitInputStream-klassen til en fil med navn "innfil.xyz", kan vi gjøre det på en av flg. to måter: BitInputStream inn = new BitInputStream("innfil.xyz"); BitInputStream inn = BitInputStream.fromFile("innfil.xyz"); Programkode A.1.3 a) Gitt at vi har flg. sekvens eller strøm av biter: Figur A.1.3 b) Det er tilsammen 48 biter. Vi kunne f.eks. tenke oss at det er de første 48 bitene (dvs. de første 7 bytene) på filen "innfil.xyz". Men det er også mulig å lage en byte-tabell som gir oss den samme sekvensen. De første 8 bitene er Dette kan tolkes som tallet 103 (= ). De neste 8 bitene er og det blir 89 (= ). Osv. Dermed vil flg. byte-tabell gi oss bitsekvensen i Figur A.1.3 b): byte[] b = {(byte)103,(byte)89,(byte)110,(byte)-27,(byte)98,(byte)-100}; Vi knytter en instans av BitInputStream-klassen til byte-tabellen b på en av flg. to måter:

4 Vedlegg A.1 Filbehandling på bit-nivå Side 4 av 9 BitInputStream inn = new BitInputStream(new ByteArrayInputStream(b),b.length); BitInputStream inn = BitInputStream.fromByteArray(b); Programkode A.1.3 c) Her brukes b.length som bufferstørrelse i begge tilfellene. I det første tilfellet eksplisitt som parameterverdi og i det andre tilfellet implisitt i koden for fabrikasjonsmetoden. Det har ingen hensikt å bruke en bufferstørrelse som er større enn størrelsen på byte-tabellen. Vi kan også se på en tegnstreng som en bitsekvens siden hvert tegn kan ses på som 8 biter. Vi knytter en instans av BitInputStream til en tegnstreng på flg. måte: String s = "Dette er den første delen av en tekst."; BitInputStream inn = BitInputStream.fromByteArray(s.getBytes()); Programkode A.1.3 d) OBS En instans av klassen BitInputStream "lukkes" ved hjelp av metoden void close(). A.1.4 Read - metodene Vi antar nå at vi har en instans av class BitInputStream ved navn inn og at de første bitene i den tilhørende bitsekvensen er som Figur A.1.3 b). Det kan vi f.eks. få til ved hjelp av Programkode A.1.3 c). Klassen har tre lesemetoder: public int readbits(int numberofbits) public int read() public int readbit() Før lesingen starter vil bitsekvensen se slik ut: x Figur A.1.4 a) Symbolet x markerer gjeldende posisjon (eng: current position), og før noe er lest er gjeldende posisjon helt i begynnelsen av sekvensen. Vi leser så f.eks. 17 biter: int n = inn.readbits(17); // n får verdien Programkode A.1.4 b) De 17 leste bitene vil bli returnert som de 17 bakerste (minst signifikante) bitene i et heltall. Resten (de 15 forreste) vil garantert være 0-biter. I Programkode A.1.4 b) vil variablen n inneholde de 17 første bitene fra sekvensen og de ligger bakerst (markert med fet type). I tillegg vil gjeldende posisjon ha flyttet seg 17 posisjoner mot høyre slik som Figur A.1.4 c) under viser: x Figur A.1.4 c)

5 Vedlegg A.1 Filbehandling på bit-nivå Side 5 av 9 Vi kan gå videre fra Programkode A.1.4 b): n = inn.readbits(5); // n får verdien Programkode A.1.4 d) Variablen n innholder nå de 5 neste bitene og gjeldende posisjon er flyttet 5 posisjoner mot høyre slik som Figur A.3.4 e) under viser: x Figur A.1.4 e) Generelt gjelder at metoden int readbits(int numberofbits) leser et oppgitt antall biter, fra og med og gjeldende posisjon, og bitene blir returnert som de bakerste bitene i et heltall. Resten av heltallet (de forreste bitene) består av 0-biter. Internt i klassen vil gjeldende posisjon ha flyttet seg like mange posisjoner mot høyre som antallet leste biter. Det er imidlertid en restriksjon. Det er ikke mulig å lese flere enn 31 biter på en gang. Grunnen til at det ikke kan leses 32 biter er at -1 returneres når det er mindre enn numberofbits biter igjen. Dermed vil det ikke være mulig å skille på når -1 (dvs biter) er en bitene i en innlesing eller signaliserer at at det ikke er nok biter igjen å lese. Den neste read-metoden - int read() - leser nøyaktig 8 biter (1 byte) (og gjeldende posisjon flyttes 8 posisjoner mot høyre). Den er tatt med fordi class InputStream har en slik metode. F.eks. vil nå koden read() og koden readbits(8) ha samme effekt. Den siste metoden - int readbit() - leser én bit og returnerer 0 eller 1 avhengig av om den leste biten var en 0- eller 1 -bit. Internt flyttes gjeldende posisjon en mot høyre. Spesielt vil readbit() og readbits(1) ha samme effekt, men den første er litt raskere. Felles for alle de tre read-metodene er at -1 returneres hvis det er færre enn det ønskede antallet biter igjen i sekvensen. Dette behøver ikke å bety at vi har kommet til slutten på sekvensen (end of file). Hvis det f.eks. er 5 biter igjen i sekvensen og vi ber om å få lese 10, vil vi få -1 som returverdi. Metoden int available() forteller oss til enhver tid hvor mange biter det er igjen. Hvis metoden readbit() returnerer -1, så har vi kommet til slutten av sekvensen. Dette bruker vi i flg. programeksempel der det leses en og en bit fra en bitsekvens og bitene skrives ut som 0 og 1: byte[] b = // b gir oss bitsekvensen i figur A.1.3 b) {(byte)103,(byte)89,(byte)110,(byte)-27,(byte)98,(byte)-100}; BitInputStream inn = BitInputStream.fromByteArray(b); int n; while ((n = inn.readbit())!= -1) System.out.print(n); inn.close(); // utskriften blir det samme som bitsekvensen i Figur A.1.3 b) Programkode A.1.4 f)

6 Vedlegg A.1 Filbehandling på bit-nivå Side 6 av 9 A.1.5 Metodene skip og unread Det er mulig å hoppe over eller skippe (eng: skip) et antall biter. Det betyr at gjeldende posisjon i bitsekvensen flyttes (mot høyre) uten at bitene leses. Vi har to skip-metoder: public int skipbit() public int skipbits(int numberofbits) Den første - skipbit() - hopper over én bit om gangen og den andre hopper over et oppgitt antall biter. Metoden skipbits(int numberofbits) fungerer best når antallet biter som skal skippes ikke er veldig stort. Den kan imidlertid brukes til å skippe nærmest så mange biter vi vil. Antallet begrenses kun av datatypen int. Begge metodene har det til felles at returverdien er et antall, dvs. det antallet biter som ble hoppet over (eller skippet). Det er ikke mulig å hoppe lengre i bitsekvensen enn til slutten, dvs. én posisjon forbi siste bit. Hvis det er færre biter igjen i bitsekvensen enn det antallet som skal skippes, returneres det antallet som ble skippet. Det betyr spesielt at hvis vi har nådd til slutten av bitsekvensen, vil returverdien bli 0 uansett hvilken skip som kalles. Ta utgangspunkt i Figur A.1.4 e). Vi kan nå f.eks. be om å få skippet 13 biter: int k = inn.skipbits(13); // k får verdien 13 Det fører til at gjeldende posisjon flyttes 13 posisjoner mot høyre slik som Figur A.3.5 a) under viser: x Figur A.1.5 a) En unread legger biter tilbake (eng: pushes back) i bitsekvensen. Det som egentlig skjer er at gjeldende posisjon flyttes tilbake (mot venstre). Dermed blir unread en slags omvendt skip. Vi har tre unread-metoder: public void unreadbit() public void unreadbits() public void unreadbits(int numberofbits) Et kall på en unread krever at det har vært en forutgående read (eller skip). Etter en read kan en eller flere av de bitene som ble lest, «legges tilbake» i bitsekvensen, men det kan ikke legges tilbake flere enn de som ble lest. En skip leser egentlig ikke biter - den bare hopper over. Men det er tillatt med en unread også etter en skip, men det kan fortsatt ikke «legges tilbake» flere enn de bitene som ble skippet. I begge tilfellene (både etter en read og en skip) kan det av ulike årsaker normalt ikke legges tilbake flere enn 25 biter. Etter en read (eller en skip) kan en unread kalles flere ganger, men sammenlagt kan det ikke «legges tilbake» flere biter enn de som ble lest (eller skippet). Det betyr at gjeldende posisjon i bitsekvensen ikke kan flyttes lenger tilbake (mot venstre) enn til der den var før den forutgående read (eller skip) ble utført. Hvis det gjøres et forsøk på å «legge tilbake» flere biter enn det som er mulig, vil det kastes et unntak av typen IllegalArgumentException. Metoden int unreadsize() forteller hele tiden hvor mange biter som kan «legges tilbake». Den første metoden - void unreadbit() - legger den sist leste biten tilbake (dvs. flytter gjeldende posisjon en mot venstre). Den neste metoden - void unreadbits() - legger resten av bitene tilbake, dvs. enten alle bitene eller eventuelt de som ikke allerede har blitt lagt tilbake. Det som egentlig skjer er at gjeldende posisjon flyttes helt tilbake til der den var før siste

7 Vedlegg A.1 Filbehandling på bit-nivå Side 7 av 9 read (eller skip). Den siste metoden - void unreadbits(int numberofbits) - legger det oppgitte antallet biter tilbake (dvs. flytter gjeldende posisjon tilsvarende tilbake). Ta nå utgangspunkt i Figur A.1.5 a), som vi fikk etter å ha skippet 13 biter (dvs. etter kallet inn.skipbits(13)). Vi ser på flg. kode: inn.unreadbits(9); // ok - det ble skippet 13 biter sist k = inn.unreadsize(); // k får verdien 4 ( = 13-9) n = inn.readbits(7); // de 7 bitene leses inn.unreadbits(); // de 7 bitene "legges tilbake" inn.unreadbit(); // feil!! - det er allerede lagt tilbake 7 biter A.1.6 Øvrige metoder Programkode A.1.5 b) Det er mulig å lese biter fra bitsekvensen uten at de blir fjernet. Det betyr egentlig at gjeldende posisjon holdes i ro etter lesingen. Det er to slike metoder: public int peekbit() public int peekbits(int numberofbits) Den første metoden - peekbit() - returnerer 0 eller 1 avhengig av om biten på gjeldende posisjon er en 0-bit eller en 1-bit. Gjeldende posisjon flyttes ikke etterpå. Den andre metoden - peekbits(int numberofbits) - leser et oppgitt antall biter fra og med gjeldende posisjon (og gjeldende posisjon flyttes ikke). Bitene returneres på samme måte som det den tilsvarende read gjør, dvs. som biter lengst til høyre i et heltall. Begge peek-metodene returnerer -1 hvis det er færre biter igjen i bitsekvensen enn det antallet som ønskes lest. OBS Etter en peek blokkeres muligheten til å «legge biter tilbake», dvs. at unread ikke er tillatt. Det må først utføres en read (eller en skip) før blokkeringen opphører. Den siste muligheten som klassen BitInputStream tilbyr er å legge helt nye biter inn i bitsekvensen, dvs. biter i tillegg til de som allerede ligger der. Det er tre metoder for det: public void insert1bit() public void insert0bit() public void insertbits(int value, int numberofbits) De to første legger inn én bit (0 eller 1) rett foran gjeldende posisjon og ny gjeldende posisjon blir der den nye biten er lagt. Den siste metoden legger de siste numberofbits fra value inn rett foran gjeldende posisjon, og ny gjeldende posisjon blir der den første av de nye bitene er lagt. Det er restriksjoner på hvor mange nye biter det kan legges inn. Rett etter en read (eller en skip) kan det minst legges så mange biter som ble lest (eller skippet hvis det ikke ble skippet mer enn 25 biter). I mange tilfeller kan det legges inn mer. Metoden int insertsize() forteller til enhver tid hvor mange nye biter som kan legges inn. OBS: Etter en insert gir unreadsize() en tilsvarende mindre verdi. A.1.7 class BitOutputStream BitOutputStream har fire konstruktører og to fabrikasjonsmetoder (eng: factory methods): public BitOutputStream(OutputStream out) public BitOutputStream(String filename) public BitOutputStream(OutputStream out, int size)

8 Vedlegg A.1 Filbehandling på bit-nivå Side 8 av 9 public BitOutputStream(String filename, int size) public static BitOutputStream tofile(string filename) public static BitOutputStream tofile(string filename, boolean append) BitOutputStream bruker interne buffere for å gjøre bithåndteringen og fil-skrivingen mest mulig effektiv. Når det interne byte-bufferet blir fullt skrives det automatisk ut ved hjelp av én skriveoperasjon. De første konstruktørene trenger en OutputStream eller et filnavn som parameter og bruker en standardverdi på 4kb som intern bufferstørrelse. I de to neste konstruktørene kan en selv velge bufferstørrelse. Det er plattformavhengig hva som er den mest gunstige bufferstørrelsen. Det henger sammen med hvor mange byter det er mulig å skrive til f.eks. harddisken i én skriveoperasjon. En bufferstørrelse på 4kb vil kunne fungere bra i de fleste tilfeller. Begge fabrikasjonsmetodene brukes standard bufferstørrelse. Gitt at vi vil skrive til en fil med navn "utfil.xyz". Hvis vi har en fil med dette navnet fra før blir den overskrevet (eller egentlig fjernet og erstattet med ny med samme navn). Vi kan knytte en instans av BitOutputStream-klassen til "utfil.xyz" på en av flg. to måter: BitOutputStream ut = new BitOutputStream("utfil.xyz"); BitOutputStream ut = BitOutputStream.toFile("utfil.xyz"); Programkode A.1.7 a) Av og til ønsker vi å skrive videre (bakerst) på en eksisterende fil, f.eks. filen "utfil.txt". Da settes append til true i fabrikasjonsmetoden. F.eks. slik: BitOutputStream ut = BitOutputStream.toFile("utfil.xyz",true); OBS: En instans av klassen BitOutputStream «lukkes» ved hjelp av metoden void close(). BitOutputStream har fem skrivemetoder: public void write0bit() public void write1bit() public void writebit(int bit) public void write(int b) public void writebits(int value, int numberofbits) De to første skriver ut, som navnet sier, én bit (0 eller 1). Det gjør også den neste, men der er det den siste biten i parameterverdien bit som skrives ut. Det betyr at f.eks. write1bit() og writebit(1) har samme effekt. Metoden write(int b) skriver ut nøyaktig 8 biter (1 byte), dvs. de 8 siste bitene i parameterverdien b. Den svarer til den vanlige write-metoden i class OutputStream. Den siste metoden skriver ut de numberofbits siste bitene fra parameterverdien value. Hvis vi skal skrive biter til en fil, vil det ofte skje at det tilsammen ikke blir et helt antall byter, f.eks. slik som i flg. eksempel: BitOutputStream ut = BitOutputStream.toFile("utfil.xyz"); ut.writebits(-1,9); // skriver ut 9 biter, dvs: ut.writebits(45,7); // skriver ut 7 biter, dvs: ut.writebits(22,5); // skriver ut 5 biter, dvs: ut.close(); // VIKTIG: Avslutt alltid med close()

9 Vedlegg A.1 Filbehandling på bit-nivå Side 9 av 9 Programkode A.1.7 b) I Programkode A.3.7 b) blir det skrevet ut = 21 biter. Her er det et problem. I det vanlige filsystemet er 1 byte den minste enheten for utskrift. BitOutputStream løser dette ved at biter fortløpende settes sammen til byter som så skrives ut. Dette går bra inntil vi skal avslutte. Da kan det være at vi ikke har nok biter til å fylle opp den siste byten. Systemet løser det selv ved at et tilstrekkelig antall 0-biter legges på til slutt. I Programkode A.3.7 b) der det eksternt kun ble skrevet ut 21 biter, vil det internt bli lagt til 3 ekstra 0-biter bakerst. Tilsammen 24 biter som utgjør 3 byter. Utskriftsfilen "utfil.xyz" vil derfor komme til å inneholde disse 24 bitene: Når en fil som er laget på denne måten, senere skal leses, vil problemet dukke opp igjen. Hvis det ligger en eller flere 0-biter bakerst på filen, så er det ikke mulig å vite om det er biter vi har skrevet ut eller om det er biter som systemet selv har lagt på. Hvis det er viktig å vite dette må vi «notere» et sted det antallet 0-biter som systemet har lagt på. Eventuelt kan vi i steden «notere ned» det totale antallet biter vi har skrevet ut. Metoden public int missingbits() forteller til enhver tid hvor mange biter som mangler for å kunne fylle den siste byten. Den returnerer et heltall i intervallet [0,7]. Hvis f.eks. den kalles rett før vi lukker, så får vi vite hvor mange 0-biter systemet kommer til å legge på bakerst. Det er særdeles viktig at vi lukker ved hjelp av metoden void close() når vi er ferdige med skrivingen. Hvis ikke kan vi risikere at ikke alle bitene blir skrevet ut til utstrømmen. Det kommer av at BitOutputStream bruker et internt buffer-system. Det interne byte-bufferet blir automatisk «tømt» (dvs. innholdet sendes til utstrømmen) når det er fullt. Men det vil normalt ligge noe igjen i begge de interne bufferne (bit-buffer og byte-buffer) når vi skal avslutte. Dette blir sendt til utstrømmen når vi kaller close(). Det vil kunne være situasjoner der vi må «tømme» bufferne selv om vi ennå ikke er ferdige med skrivingen. Metoden public void flush() er laget for dette formålet. En må være klar over at det da vil bli lagt på tilstrekkelige mange 0-biter bakerst slik at det blir et helt antall byter. Metoden int missingbits() vil også her fortelle hvor mange. Men i vanlig skriving til en utstrøm (f.eks. en fil) skal en normalt ikke bruke flush(). OBS: Det ligger et innebygd kall på flush() i koden for close(). Det er derfor ikke nødvendig å gjøre et eksplisitt kall på flush() før en avslutter med close(). Copyright Ulf Uttersrud, All rights reserved.