...

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 blir utløst et unntak. Hvis en vet hva slags typer 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. Dette

Analyse og sjekk av typer basert på koden kalles statisk typing, siden typene til alle uttrykk kan 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:

...

• 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 metodeSomIkkeFinnesmetoden metodeSomIkkeFinnes.
• new Date() + 3, ikke lov fordi new Date() gir et objekt av typen Date, som ikke støtter + (selv om en kunne definert at det skulle gi en ny dato en viss tid fremover)

...

• 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 v2 faktisk 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.

Bruk av arv

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

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

Oppgave a)

 Hvilke av følgende deklarasjoner/initialiseringer vil gi feil i editoren/ved kompilering:
A a = new B();

B b = new A();

G g1 = new A(), g2 = new B(), g3 = new C();

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.

...