Typer i programmeringsspråk brukes for å bestemme hva det er lov å gjøre med en verdi eller objekt. Ved å deklarere typen til variabler, parametre, attributter/felt og returverdier til metoder, så kan kompilatoren og utviklingsverktøy sjekke om operasjoner og metoder er brukt riktig (i hvert fall ikke ulovlig).


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:

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

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:

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:

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

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

Det er jo opplagt for oss at s i praksis kan ha verdien til o, men tilordningen er likevel ulovlig, siden typen til o ikke garanterer at det alltid er tilfelle. Sammenlign med eksemplet til høyre.

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

Her er det like opplagt at selv om s som oftest i praksis kan ha verdien til o, så vil det ikke alltid gå, og dermed må det anses som ulovlig.

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.

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,v2,v4,v6 deklarert som over (v3 og v5 er ekskludert siden de er ulovlige):

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 setter altså 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);
}
 

method-metoden finnes i to varianter: den ene tar et Object-argument, og den andre tar et String-argument. Hvis den andre skal kunne kalle den første med et objekt som Java vet er en String, så kan man caste typen til Object. Da velges den første metoden og ikke den andre, og en unngår evig rekursjon.


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

Anta følgende klasser, grensesnitt og metoder (diagram til høyre):

  • Klasse A deklarerer metoden A methodA().
  • Grensesnittet G deklarerer metoden G methodG(A)
  • Klasse B arver fra A, implementerer G og deklarerer metoden B methodB(A).
  • Klasse C implementerer G og deklarerer metoden C methodC(G).

Lenke til koden: A.java, B.java, C.java, G.java og Main.java

class A {
	A methodA()
}
interface G {
	G methodG(A)
}
class B {
	B methodB(A)
}
B --|> A
B ..|> G
class C {
	C methodC(G)
}
C ..|> G

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):

Spørsmålet i b) er hvilke av følgende uttrykk vil gi feil i editoren/ved kompilering (statiske typer) og hvorfor (anta at variablene a, b og c er deklarert til å være av klassene A, B og C):
 

De tre siste uttrykkene i b)-oppgaven var om casting (kallet til methodG i originalen er utelatt her, fordi det er greit i alle tilfeller):

Casting er altså ulovlig hvis det kan (be)vises at det alltid vil gi ClassCastException ved kjøring. Men merk at beviset må ta høyde for at det finnes klasser en ikke vet om (derfor ville den første av casting-uttrykkene (G) a, over vært lov selv om en ikke visste om B, siden enhver "ukjent" subklasse kan implementere et hvilket som helst grensesnitt).

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>();

Greit, siden ArrayList er en subtype av Collection og de er spesialisert til samme type.

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

Ikke greit, fordi spesialiseringene er forskjellig. Den andre setningen illustrerer hvorfor.