Typer

Typen til en verdi eller et objekt bestemmer hva en kan gjøre med verdien eller et objekt, dvs. hvilke operasjoner en kan utføre eller metoder en kan kalle. F.eks. kan en bruke + mellom tall og mellom String-objekter, men ikke mellom Date-objekter. For hver type kan en liste opp hva som er lov og ikke, og hvis en gjør noe ulovlig så vil det typisk bli utløst et unntak. Hvis en vet hva slags type verdier en har å gjøre med i et uttrykk eller setning, så kan en også sjekke at de blir brukt riktig. Og hvis dette kan sjekkes av kompilatoren eller utviklingsverktøyet, så kan en unngå at det blir feil ved kjøring, fordi en nektes å skrive og kjøre kode som ikke er korrekt iht. typene.

Analyse og sjekk av typer basert på koden kalles statisk typing, siden typene til alle uttrykk sjekkes uten (dynamisk) kjøring av koden. Det krever litt mer innsats av programmereren, som må gjennomgående må oppgi typer, men gir mye tilbake i form av større trygghet for at koden virker, samt at utviklingsverktøyet kan være mer hjelpsomt (komplettering av navn, halvautomatisk retting av feil osv.). Merk at det finnes analyseteknikker som kan bygges inn i både språk, kompilatorer og verktøy som kan redusere mengden typeinformasjon programmereren må legge inn selv.

Java har en rekke innebygde typer, både verdityper og objekttyper. I tillegg kan man definere nye typer, som man jo gjør når man skriver nye klasser (og grensesnitt). Her er noen eksempler:

• boolean - sannhetsverdier, som støtter logiske operasjoner som AND (& og &&) og OR (| og ||) 
• int - helttallstype som støtter aritmetiske operasjoner som +, -, *, / og % (rest)
• double - desimaltallstype som støtter aritmetiske operasjoner som +, -, *, / og % (rest)
• java.lang.String - tegnsekvensklasse som støtter + for sammensetting (spleising) og en rekke metoder for å hente ut tegn/delsekvenser og for å lage nye String-objekter
• java.util.ArrayList - objektsekvensklasse som har en rekke metoder for å endre å sekvensen (endre, legge til og fjerne elementer)

Basert på dette kan en f.eks. avgjøre hvilke av følgende uttrykk som er lov og ikke:

• 1 + 2, lov fordi 1 og 2 begge er av typen int, som støtter + (resultatet blir 3)
• "1" + "2", lov fordi "1" og "2" er av typen String, som støtter + (resultatet blir "12")
• "1".length(), lov fordi "1" er av typen String og String har metoden length() (uten parametre)
• "2".charAt(2.0), ikke lov fordi selv om "2" er en String og String har metoden charAt, så tar charAt en int som argument og 2.0 er en double-verdi.
• ("1" + "2").metodeSomIkkeFinnes(), ikke lov fordi "1" + "2" gir en ny String, og String har ikke metoden metodeSomIkkeFinnes.
• new Date() + 3, ikke lov fordi new Date() gir et objekt av typen Date, som ikke støtter + (selv om det teknisk sett er mulig å definere at det skulle gi en ny dato en viss tid fremover)

Typer og uttrykk

Et viktig poeng er at når en vet typen til verdiene/objektene som inngår i et uttrykk (såkalte deluttrykk), så vet en også noe om typen til resultatet. F.eks. vet en at 1 + 2 gir en int fordi int + int generelt en ny int. Dermed vet en også at (1 + 2) + 3 er lov og gir enda en int. Ved å jobbe seg innenfra og ut i et uttrykk, så en dermed finne typen til uttrykket som helhet. F.eks. vil (1 + 2) + "3" gi en String, fordi (1 + 2) gir en int og int + String gir en (ny) String. Dermed er også ((1 + 2) + "3").length() lov, fordi String.length() er lov.

Konvertering av tall

Når en blander talltyper, f.eks. int og double, så har Java regelen at da omgjøres tallene først til samme type, før operasjonen utføres. Typen som velges er slik at en ikke mister sifre eller desimaler. Ved beregning av 1 + 2.0, altså int + double, så blir int-verdien 1 først omgjort til double-verdien 1.0 før de legges sammen. Hvis en i stedet hadde gjort om double-verdien til int, så kunne en potensielt mistet desimaler og det hadde ikke vært bra.

Bruk av + og konvertering til String

+-operatoren brukt på String-objekter håndteres spesielt. Hvis typen på minst én side av + er en String, så blir begge sidene omgjort til String ved å kalle String.valueOf som igjen kaller toString(), før de spleises sammen. Blanding av + med String, tall og andre tall-operatorer kan være forvirrende og gi overraskende feil:

• "en" + 2 + 3 + "fire" tolkes som (("en" + 2) + 3) + "fire", som gir ((String + int) + int) + String som igjen gir String som gir verdien "en23fire" som resultat.
• "en" + 2 - 3 + "fire" tolkes som (("en" + 2) - 3) + "fire", som gir ((String + int) - int) + String som igjen gir typefeil, siden  String - int ikke er lov.
• "en" + 2 * 3 + "fire" tolkes som ("en" + (2 * 3)) + "fire", som gir (String + (int * int)) + String som igjen gir String som gir verdien "en6fire" som resultat.

Deklarasjoner

Java krever at en oppgir typer i deklarasjoner av både variabler og metoder, og det er grunnlaget for å finne typen til alle uttrykk. Typen i deklarasjoner er både en hjelp for oss når vi leser koden og for kompilatoren og verktøyet til å sjekke om koden vår er lovlig. Typen til en variabel begrenser oss på to måter:

1. hva slags verdier variabelen kan tilordnes, dvs. typen til høyresiden av en tilordning (evt. initialisering)
2. hva man siden kan gjøre med variabelen, dvs. hvordan den kan inngå i uttrykk

Variabler og tilordninger

Hvis en variabel har deklarert til en type T, så kan den bare tilordnes verdien av uttrykk som har samme type T eller en subtype. Hvis en tenker (og det bør du gjøre) på typen til en variabel som en garanti om hva en kan gjøre med den, så er det jo greit at verdien er en subtype og dermed kan mer, men ikke greit om den er en supertype som kan mindre. Eksempler:

• String v1 = "Java", lov siden høyresiden har samme type (String) som v1 er deklarert som.
• Object v2 = "Java", lov siden høyresiden er en subtype (String) av typen som v2 er deklarert som.
• String v3 = new Object(), ulovlig siden høyresiden er en supertype (Object) av v3 sin type (String).
• Comparable<String> v4 = "Java", lovlig siden typen til høyresiden er en subtype av v4, ved at String implementerer Comparable<String>-grensesnittet.
• String v5 = new Date(), ulovlig siden høyresiden (av typen Date) ikke har noe til felles med v5 sin type (String).
• String v6 = null, lovlig siden null kan gis en hvilken som helst referansetype.

Det er mulig å konstruere eksempler som det kan virke som burde gå, men som ikke gjør det:

Object o = "Java";
String s = o;

Object o = null;
if (Math.random() <= 0.99999) {
	o = "Java";
} else {
	o = new StringBuilder();
}
String s = o;

Merk at det tillates litt fleksibilitet ved bruk av tall, siden de (som nevnt over) noen ganger kan konverteres uten fare for å miste siffer eller desimaler. Feks.

• double d = 1, lov siden 1 sin type (int) alltid kan konverteres greit til double.
• int i = 2.0, ulovlig siden 2.0 sin type (double) ikke alltid kan konverteres til int, og på tross av at 2.0 kan konverteres.

Variabler i uttrykk

Typen til en variabel brukt i et uttrykk er typen den er deklarert som (statisk type), ikke typen til verdien den faktisk har (dynamisk type)! For verdityper som boolean, int og double, så gjør ikke det noen forskjell, men for referansetyper, altså klasser og grensesnitt, så er det pga. arv helt vesentlig. Antar en har variabler v1-v5 deklarert som over:

• v1.compareTo("C++"), lov siden typen til v1 er String, som har metoden compareTo(String).
• v2.compareTo("C++"), ulovlig siden typen til v2 er Object, som ikke har metoden compareTo(String), selv om verdien til v2faktisk er en (referanse til en) String, som har det.
• v4.compareTo("C++"), lov siden typen til v4 er Comparable<String>, som (selvsagt) har metoden compareTo(String) (uten å vite noe om implementasjonen).
• v6.compareTo("C++"), lov siden typen til v6 er String, som har metoden compareTo(String), selv om verdien til v6 i praksis er null og en får utløst unntaket NullPointerException ved kjøring.

Casting

Casting er en mulighet en har i Java for å "endre" typen til et uttrykk. Notasjonen er (T) expr, hvor T er en type og expr er et uttrykk. En altså setter typen en ønsker i parentes foran et uttrykk og samlet sett får en et nytt uttrykk av angitt type. En kan selvsagt ikke velge T fritt, det må jo være en sammenheng mellom T og typen til expr. Effekten av utførelsen av casting-uttrykk og hva som er lov og ikke, kan deles i to tilfeller:

1. Hvis T og typen til expr er tall-typer, så vil Java foreta en konvertering av tall-verdien fra den ene typen til den andre. Dette kan tvinge Java til å fjerne desimaler eller siffer, men en får lov for det er på eget ansvar. F.eks. vil (int) 2.5 gi int-verdien 2 som resultat siden desimaler fjernes, mens (byte) 256 vil gi byte-verdien 0 siden bare de laveste 8 binære sifrene beholdes.
2. Hvis T og typen til expr er referansetyper (klasser og grensesnitt), så vil det sjekkes om den faktiske verdien til expr er en instans av T eller en subklasse. Hvis ikke utløses ClassCastException. Objektet selv vil uansett ikke bli endret. Dette er altså en dynamisk typesjekk tilsvarende den instanceof gjør. Men i tillegg aksepterer altså Java at typen til uttrykket som helhet er T, som er den statiske typen. Hvis det kan bevises at en casting umulig kan gå, så får en feil allerede ved kompilering.

Eksempler:

byte b = (byte) 265; // greit, b blir 109, siden ekstra binære siffer fjernes
int i = (int) '0'; // greit, i blir 48, som er koden til tegnet '0'
int j = (int) Math.random(10) + 1; // j blir et tilfeldig heltall fra og med 1 til og med 10
Object o = (Object) "Java"; // unødvendig casting, siden uttrykket "Java" er Object allerede
String s = (String) o; // nødvendig casting, siden o muligens, men ikke nødvendigvis må ikke være String
String s = (String) new Date(); // ulovlig, siden et objekt umulig kan være en instans av både Date og String på samme tid

Den vanligste bruken av casting er såkalt downcasting, dvs. casting til en subtype, f.eks. så en kan bruke subtype-metoder:

Object o = ...
if (o instanceof String) {
   System.out.println("Lengden er :" + ((String) o).length());
}

 Det kan faktisk også være aktuelt å caste til en supertype, f.eks. hvis en ønsker å "velge" en bestemt metode av flere med samme navn (overloading):

void metode(Object o) {
	...
}
void metode(String s) {
	...
	metode((Object) s);
}
 

En kan også caste null-verdien, for å velge mellom ulike metoder med samme navn: metode((Object) null) vil kalle den første og metode((String) null) vil kalle den andre. Uten casting her vil det være tvetydig, og en vil få kompileringsfeil.

Bruk av arv

Ved bruk av arv, og spesielt kombinasjoner av extends og implements, så blir det lett forvirrende. Her er et eksempel fra oppgave 2 på ordinær eksamen 2010

Spørsmålet i a) er hvilke av følgende deklarasjoner/initialiseringer vil gi feil i editoren/ved kompilering (altså handler det om statiske typer):

• A a = new B(), går greit, siden uttrykket new B() gir en B som er en subklasse (arver fra) A
• B b = new A(), går ikke greit, siden en A ikke er en B
• G g1 = new A(), g2 = new B(), g3 = new C(), den første går ikke, siden en A ikke er en subklasse av (implementerer) G, mens de andre er greie, siden både B og C implementerer G

Generiske typer

Generiske typer som Collection og List gjør analyse av typer litt mer komplisert. Vi skal ikke dra hele historien her, men si at resonnementene over angående variabler og tilordninger holder så lenge typene er spesialisert til samme (element)type. Tilordningen under til venstre er lov, siden ArrayList er en subtype av Collection. Tilordningene i midten og til høyre er imidlertid ikke lov, siden spesialiseringen er forskjellig.

Collection<String> col =  new ArrayList<String>();

Collection<Object> col = new ArrayList<String>();
col.add(new Object()); // må jo være lov for col sin del, men går jo ikke med ArrayList<String> som verdi