tyyppimuunnokset, Stream, String[Buffer]

tyyppimuunnokset, Stream, String, StringBuffer

Tässäpä sitten hieman asiasta:

1. Mitä tekee String -luokan getBytes() ?

huom: vakiovastaus kysymykseen löytyy jokaisesta Javan oppikirjasta, ja yleensä kaikissa samalla tavalla puutteellinen / väärin.

Sen tiedänkin jo ihan täsmällisesti, mitä tuo getBytes() tekee silloin, kun ko. merkkijonon kaikki merkit kuuluvat US-ASCII -merkkivalikoimaan (koodit 1..127).

Mutta jo se, että merkkijonossa esiintyy Ä ja Ö -kirjaimia, aiheuttaa sen, että tuon getBytes -metodin toimintatapa ei olekaan ihan itsestäänselvää.

vinkki: esim:

String a = "Tämä";
byte[] b = s.getBytes();

nyt tuon b:n length palauttaa 4 !!!

Javan char -tyyppihän on 16 bittiä ja se tallentaa itseasiassa merkin UNICODE -koodin (=16 bittiä), joka USASCII -merkkien osalta on sama kuin ASCII -koodi tallennettuna 7 alimpaan bittiin, jolloin 9 ylintä bittiä ovat kaikki nollia.

Joku tänne palstalle kirjoittanut oli kokeillut, ja tullut siihen tulokseen, että merkkijonovakiot tallentuvat .jar -tiedostoon utf8 -enkoodattuna, jolloin siis USASCII -merkit ottavat yhden tavun ja esim Ä tai Ö 2 tavua / merkki.

Mutta koska em. b:ssä on 4 tavua, ei se voi käyttää utf8 -koodausta, sillä utf8 -koodauksella merkkijonon "Tämä" ottama tila olisi 6 tavua.

Jos taas merkit 0..255 muunnetaan getBytes() -metodilla aina yhdeksi tavuksi (?), niin mitä getBytes() sitten tekee esim. jollekin thaimerkille ta esim. kreikkalaiselle aakkoselle ?

USASCII:n ulkopuolisten merkkien osalta getBytes():n toimintattapa on siis varsin epäselvä.

2. Eräiden ohjelmointioppaidden mukaan varsinkin J2ME:ssä tulisi välttää olioiden tarpeetonta luomista. Käytännön ohjelmoinnnissa tämä on aika vaikeaa, koska esim. String -tyyppi on ns. immutable, eli kun siihen tehdään muutoksia, niin "muutos" on vain illuusio, eli itseasiassa luodaan uusi merkkijono muutettua sisältöä varten ja vanha jää roskienkeruun harmiksi.

StringBuffer ?

Omassa koodissa voisi tietysti käyttää StringBuffer -luokkaa Stringin sijasta aina kun voi. Mutta esim. käyttöliittymäkomponentit kuitenkin tarvitsevat tiedon yleensä String -muodossa, eli kokonaan String -tyyppiä ei oikein voi välttää.

3. Tyyppimuunnokset / Stream...

ilmeisesti Javassa ei voi tedä suoraa tyyppimuunnosta samoin kuin esim. Delphissä:

T4Bytes = Array[0..3] of Byte;

var
a : T4Bytes;
b : Integer;

begin
b := $11223344;
Integer(a) := b;
end;

Javassa siis vaihtoehdoksi jää (ainakin):

byte[] a = new byte[4];
int b;

b = 0x11223344;
a[0] = b & 0xFF;
a[1] = (b >>> 8)& 0xFF;
a[2] = (b >>> 16)& 0xFF;
a[3] = (b >>> 24)& 0xFF;


Mutta onko tämä todella ainoa vaihtoehto javassakaan ?

mitä, jos kirjoitat Streamiin muuttujan b (tyyppiä int) ?

Jos nyt siirretään Streamin osoitin 4 tavua taaksepäin, eikö nyt voitaisi lukea Streamista muuttuja a ?

Onko javan Stream -luokkien lähdekoodi jossain luettavissa, olisipa kiva nähdä, miten asia on Stream -luokkien toteutuksessa hoidettu!

Eikös Stream -luokkiin voi kirjoittaa (tai niistä lukea) lähes mitä tyyppiä tahansa ?

Onko noissa käytetty jotain "oikotietä" vai perustuuko koko homma siihen, että Stream -luokkaan voi kirjoittaa vain yhden muuttujan kerrallaan, ja ko. muuttuja on aina jotain yksikäsitteisesti määriteltyä tyyppiä, joten Stream -luokan toteutuksessa on täytynyt käsitellä kukin alkeistyyppi erikseen, vai ?

Kommentteja ?