Dersom du har arbeidet med et Java-prosjekt som student eller i arbeidslivet så er sjansen stor for at du har hørt om Spring. Det er et av de mest brukte rammeverkene ifølge en undersøkelse utført av Jetbrains. Spring brukes til å bygge både store og små Java-applikasjoner i hele verden. Prosjektet har gått fra å være et enkelt OpenSource-prosjekt til å arrangere sine egen konferanser. Det er et utrolig stort engasjement fra utviklere over hele verden som bidrar til å gjøre Spring til et utrolig rikt verktøy for å bygge applikasjoner. Spring er et WMvare-produkt og består per i dag av 23 prosjekter. Det kan fort bli overveldende å sette seg inn et såpass stort og omfattende rammeverk.
Bli kjent med Spring - Kapittel 1: Historien til Spring | Progit
I denne artikkelserien vil jeg forsøke å tilby en enkel og gradvis gjennomgang av Spring. Konseptene fremlegges med en hel rekke praktiske eksempler, kode og beskrivelser. I prosessen av å skrive disse artiklene har jeg ofte måttet arrestere meg selv for å skrive om relaterte prosjekter, teknologier og konsepter som går hånd-i-hånd med Spring. Det er et omfattende tema og noen ganger kan det være fristende å bevege seg inn i ‘the rabbit hole’ og utforske noe helt annet. Dersom du underveis i artikkelen leser noe som er uklart eller har en tilbakemelding av noe slag, så send meg gjerne en e-post.
Vi begynner med kapittel 1 som jeg har gitt navnet ‘Historien til Spring’. For å forstå hvorfor Spring er hvor det er i dag så er det viktig å forstå hvor det kommer fra. Det er ingenting som en god ‘origin story’ (med unntak av X-men Origins: Wolverine).
Mitt møte med Spring
Personlig ble mitt første møte med Spring en rotete affære. Jeg var en ung data-student i Oslo og var svært interessert i å bygge enkle websider med PHP og jQuery. Gleden over å friske opp nettleseren og se endringene delte jeg med alle mine studentvenner. Flere ganger daglig samlet vi oss rundt laptopskjermen til den av oss som hadde fått til noe spennende. Aller mest entusiasme var det når en animasjon fungerte som tiltenkt, etterfulgt av at koden ble analysert av resten av gruppen slik at de kunne få til noe lignende. For hver uke som gikk så ble grensene for hva som kunne oppnås med denne teknologien sprengt. Det var en utrolig morsom tid! Omtrent samtidig ble vi introdusert for Java. Det var litt annerledes enn PHP og møtet med dette objekt-orienterte språket ga ikke like mye feedback innledningsvis som en webside. På det tidspunktet manglet vi referansepunkter på hva det kunne brukes til. At Java kunne skrive navnet ditt og hvor gammel du var i en terminal var ikke helt det samme som en tøff webside.
Dette endret seg da vi startet å arbeide med et semesterprosjekt i JavaFX (et rammeverk for å lage grensesnitt). Etter noen uker opplevde vi å oppnå kule visuelle effekter også i Java. Nok en gang ble skjermer snudd og demonstrert til stor fornøyelse for resten. Vakre, interaktive applikasjoner som på den tiden kjørte vår versjon av Conway’s Game of Life simulering. Personlig begynte jeg å kjenne at jeg hadde sansen for Java. Jeg så meg ikke over skulderen idet jeg etterlot PHP-scriptene i Notepad++.
Mitt neste møte med Java ble en helt annen opplevelse. Denne gangen i form av et prosjekt der vi skulle opprette en rekke applikasjoner i Java ved hjelp av Spring rammeverket. Jeg minnes fortsatt at vi fikk et oversatt dokument med Spring Roo kommandoer. Dersom du ikke har brukt Spring Roo tidligere kan jeg melde om at det er et verktøy som kan kjøres i terminalen for å generere Spring applikasjoner. Mitt møte med dette var svært forvirrende. Dette skyldtes delvis at jeg på dette stadiet ikke var så komfortabel med terminalen. Jeg hadde, som folk flest, brukt GUI applikasjoner til å gjøre alt på datamaskinen. For det andre så forstod jeg ikke hva som skjedde og hvorfor det ble gjort på denne måten. Resultatet ble til at jeg fulgte kommandoene slavisk. Ved den minste feilmelding stoppet det helt opp og jeg forsto ikke feilmeldingen. Alle forslagene på StackOverflow bidro til å gjøre ting ekstra utfordrende for en ung utvikler med tidsfrist på en prosjektinnlevering. Her hadde det lønnet seg å forstå forskjellen på de forskjellige Spring prosjektene. Når det endelig fungerte så forsto jeg ikke hvorfor det fungerte.
Det er en ubehagelig følelse som oppstår når du ikke forstår noe og samtidig ikke vet hva du ikke forstår. Det er en tung kognitiv belastning som skaper stress og fullstendig fjerner gleden ved å programmere. Det er denne følelsen som har motivert meg nå, flere år senere, til å skrive dette innlegget slik at potensielle nye utviklere har et sted å lande. Først og fremst vil jeg myke opp overgangen fra å lære Java for første gang til behovet for rammeverk.
Hvor var du under millenniumsskifte?
Jeg husker godt hvor jeg var når klokken passerte midnatt 1. januar 2000. 10 år gammel sto jeg ute på balkongen hos min bestemor i Tønsberg. Fyrverkeriet lyste opp himmelen og det var like fint som året før. Kanskje enda mer fyrverki denne gangen. Jeg fikk lov til å plassere rakettene i glassflasken som min far hadde gravd ned i snøen i bakhagen. Deretter ble lunten tent og vi løp med raske skritt til resten av familien som sto på balkongen med tykke boblejakker over penklærne. Jeg kan også huske at det i dagene opp mot nyttårsaften var mye snakk om ‘millienium buggen’ som kom til å gjøre alle datamaskinene ubrukelige. Det skjedde heldigvis ikke. Det er vanskelig å sette seg inn i hodet til en 10 år gammel versjon av seg selv, men jeg er ganske sikker på at fotball og Nintendo tok en del plass. Det gjør det fremdeles.
Det som ikke hadde plass i hodet mitt denne dagen var publiseringen av J2EE 1.2 spesifikasjonene i desember 1999. J2EE er en forkortelse for Java Enterprise Edition. Dersom du tenker: «Hva er Enterprise Edition? Hva betyr det?» Så tenker vi likt. Her kommer en kort forklaring.
Det finnes fire forskjellige Java plattformer. Disse er:
Java Platform, Standard Edition (Java SE)
Java Platform, Enterprise Edition (Java EE)
Java Platform, Micro Editon (Jave ME)
JavaFX
Hver plattform består av en Java Virtuel Maskin (JVM) som kjører applikasjonen og et API med verktøy man kan benytte. Java SE er, som navnet tilsier, standard Java med kjerneverktøyene man kan forvente fra et programmeringsspråk. Java EE bygger videre på Java SE og tilbyr i tillegg API’er for å bygge applikasjoner i stor skala som er stabil, skalerer og sikker.
(Java ME tilbyr en virtuell maskin som krever lite minne slik at den enklere kan kjøres på mindre maskiner som blant annet mobiltelefoner. JavaFX er en plattform som tilbyr verktøy for å lage grafikk og media-applikasjoner.)
Java Enterprise Edition
J2EE inneholder 10 spesifikasjoner. Blant disse finner vi gamle travere som JavaServerPages (JSP), Enterprise JavaBeans (EJB) og Java Message Service (JMS). Sluttproduktet var basert på to eksisterende applikasjonsservere som ble utviklet hver for seg av henholdsvis Netscape og WebLogic. Sammen med Sun Microsystem samarbeidet selskapene om å lage en felles løsning. Andre aktører kunne også bygge sertifiserte implementasjoner av disse spesifikasjonene. Disse aktørene kunne da også bli med å bidra med å designe videre spesifikasjoner via et program som fikk navnet Java Community Process (JCP). Det var ikke mangel på aktører som bidro til J2EE. Rundt bordet fant du selskaper som IBM, Oracle, JBoss, Apache og RedHat som alle sammen ble en del av JCP.
Til tross for store selskaper i ryggen ble J2EE møtt med kritikk. Miksen av selskaper med ulike preferanser og ulike behov resulterte i det man kan argumentere for et tungt og kompleks sluttprodukt. Prosessen å lage en standard i et miljø hvor man må ta hensyn til alle behov og scenarioer kan være utfordrende, og langsomt.
J2EE krevde store mengder XML og konfigurasjonen var svært kompleks. Den store mengden XML-filer bidro til å gjøre det ekstra slitsomt å skrive kode. Sammenlignet med dagens løsninger var det også mye kode som måtte skrives for å få bygget applikasjonen. Utviklere synes samtidig det var tungvint å bruke tid og energi på å skrive konfigurasjon til spesifikasjoner de ikke brukte. Det var alt eller ingenting.
J2EE har gått igjennom flere iterasjoner og navnebytter i årene som fulgte. I 2006 ble hele prosjektet overhalt og byttet navn til Java EE 5. Denne versjonen bydde på en mye mer utviklervennlig måte å bygge applikasjoner med ‘konvesjon over konfigurasjon’. Historikken til J2EE hadde dog resultert i at færre aktører investerte tid i å bygge implementasjoner. Java EE 5 utviklet seg til Java EE 6 og rundt denne tiden ble Sun Microsystem kjøpt opp av Oracle som allerede eide flere av selskapene som tidligere hadde bidratt i JCP-programmet. Programmet ble redusert til kun tre store aktører, Oracle, IBM og RedHat, i tillegg til noen mindre aktører.
Når Java EE 7 ble publisert noen år senere i 2013 var det en etterlengtet opprydning av standarden. Det kan tenkes at færre aktører i JCP reduserte kompleksiteten og omfanget. Samtidig har de over de siste årene blitt inspirert av rammeverk som Spring, som oppsto i kjølevannet av kompleksiteten til de tidligere versjonene av J2EE. Java EE 8 var ment til å være den siste biten i puslespillet for Java EE, men grunnet ukjente årsaker så ble den forsinket og publisert med et svært redusert omfang. Oracle annonserte deretter i 2017 at de vil overføre Java EE til Eclipse Foundation som er en non-profit organisasjon. Java EE gikk deretter igjennom et nytt navnebytte og er i dag kjent som Jakarta EE.
For å forstå hvordan Spring Framework henger sammen med dette er vi nødt til å spole litt tilbake.
En ny vår
To år har passert siden millenniumsskiftet. Jeg minnes at jeg er lidenskapelig opptatt av Pokémon og at jeg tilbragte mer og mer tid på internett. Dette var første gang jeg leste og redigerte HTML-dokumenter. Jeg synes det var spennende og det var nok årsaken til at jeg mange år senere valgte nettopp den karriereveien. Min kunnskap om Pokémon var komplett og jeg ønsket å bygge en webside hvor jeg kunne samle alt. Fremgangsmåten var å kopiere kildekoden til serebii.net (som fremdeles holder koken) som var drømmenettsiden. Den hadde alt! Jeg studerte HTML-koden i timesvis! Mamma hadde investert i en smart printer som også kunne scanne bilder. Hun tenkte nok at den skulle brukes til å digitalisere fotoalbumene. Jeg hadde andre planer. Scanneren gikk varm mens jeg scannet inn samlingen av pokémonkort. Dessverre hadde jeg ikke alle kortene. På den tiden opplevde jeg det som den eneste måten å få tak i et bilde av selve kortet. Noen ganger skulle jeg ønske at jeg kunne formidle nåværende kunnskap til en yngre versjon av meg selv.
Samtidig som hjemmemaskinen var okkupert av eldste sønnen i huset, satt en person med navn Rod Johnson på sin maskin og forsøkte å skrive en bok om J2EE. Det var i denne prosessen at tanken om at det muligens finnes en bedre løsning oppstod. Boken ble utgitt med navnet ‘Expert One-on-One J2EE Design and Development’ og den inneholdt gode referanser og en hel mengde kodeeksempler. Juergen Hoeller og Yann Caroff leser begge boken og diskuterer koden seg i mellom over internett. De kontakter Rod Johnson og spør om de kan publisere koden som OpenSource. Yann gir prosjektet navnet ‘Spring’. En ny vår etter en lang vinter med J2EE. I 2003 slippes versjon 0.9 av prosjektet ‘Spring Framework’ og året etter lanseres versjon 1.0. Det skulle vise seg å bli et prosjekt som vokste mer enn noen hadde drømt om.
Hva gjorde Spring Framework annerledes?
Jeg besøkte Hollywood med min kone for første gang i 2014. I ettertid så er de sterkeste minnene alle gangene jeg så biler kjørte i hverandre, såkalte ‘fender-bender’. Jeg mener å ha observert tre stykker samme dag på relativ kort tid. Kombiner dette med de utallige kjøretøyene med synlige bulker konkluderte jeg med at dette er ganske vanlig her. Jeg håpet inderlig at det ikke ville forekomme med leiebilen vår. Det gjorde det heldigvis ikke.
Rod Johnson mynter begrepet ‘Hollywood principle’ i boken sin. Med dette mener han at det ikke skal være nødvendig at brukerens kode skal kalle på et bibliotek i et rammeverk. Rammeverket skal kalle brukerens kode. ‘Don’t call me, I’ll call you’. Denne tankegangen er sentral i Spring Framework og er mer kjent som ‘Inversion of Control’.
Spring erstatter nemlig ikke J2EE, men komplementerer det. Spring reduserte terskelen for å bygge enterprise applikasjoner ved å være et mer naturlig grensesnitt for brukeren. Hvor J2EE er designet for å være en standard, så er Spring et rammeverk som gjør standarden enklere å arbeide med. Kjernen i Spring Framework er det som er omtalt som ‘Spring Application Context’. Jeg liker å tenke på dette som en form for beholder (container). Denne beholderen skal fylles med Java-klasser, også kalt ‘Java beans’. Spring vil ved oppstart håndtere opprettelse av bønnene basert på den konfigurasjonen brukeren oppgir. Til sammenligning hadde J2EE Servlet containers som håndterte EJB komponenter, men Spring sin versjon ble sett på som en lettere utgave. Spring sin beholder var også designet til å støtte middleware som for eksempel håndtering av transakjoner og sikkerhet som bidro til et mer praktisk verktøy.
Spring utviklet seg raskt og i 2006 ble versjon 2.0 publisert. Denne versjonen gjorde det enda enklere å konfigurere via XML-filer. Året etter kom versjon 2.5 som introduserte muligheten for å konfigurere via annotasjoner direkte i Java-klassene. Dette kunne erstatte mye XML og svært mange satte pris på denne muligheten. Noen år senere, i 2012, slapp Spring versjon 3.2 som igjen reduserte behovet for XML med støtte for Java konfigurering.
For å leve opp til begrepet ‘don’t call me, I’ll call you’ så bruker Spring, bak kulissene, Java sitt Reflection API. Dette API’et gjør det mulig å hente informasjon om klasser og dens egenskaper og metoder under kjøring. Dette er et svært kraftig verktøy og det er ofte ikke det første man lærer. Java Reflection fortjener sin egen artikkel og jeg har notert det bak øret for et fremtidig skriveprosjekt. Når alle bønnene er lagt i beholderen kan Spring automatisk opprette alle klassene for oss. Dersom det er avhengigheter mellom klassene så vil Spring håndtere alt av organisering. Denne teknikken heter «Dependency Injection» og resultatet av dette er at komponenter er enklere å teste og lettere å gjenbruke. Dette vil bli demonstrert når vi sammen bygger en Spring-applikasjon. Før den tid må vi innom et av de viktigste prosjektene til Spring: Spring Boot.
Spring Boot
Dersom du tilfeldigvis hadde besøkt Spring sin Jira-tavle i 2012 så kan det hende at du la merke til Mike Youngstrom sitt innlegg med et ønske om å gjøre opprettelse av Spring sin webarkitektur enklere. Han starter innlegget med påstanden:
«As the enterprise development landscape grows more diverse the simpler the application framework the more likely developers are to adopt the framework.»
Det er vanskelig å være uenig. Selv om Spring Framework sin popularitet hadde økt enormt de siste årene så var det fremdeles en læringskurve å ta det i bruk. Det var for eksempel en fordel å kjenne til de indre mekanismene for å komme i gang. Med den konstante flyten av nye hippe open-source prosjekter så må man tilpasse seg for å være relevant. Nettopp dette gjorde menneskene bak Spring. Nesten et helt år senere, i 2013, responderer Phil Webb på vegne av Spring som følgende:
«Rather than fix this as part of the core Spring Framework we have decided to start a new project called Spring Boot that addresses this and a number of other issues.»
Hvorav Mike Youngstrom svarer med:
«Great! I'm excited to see how spring-boot looks.»
I dag, 8 år senere så er Spring Boot omtrent synonymt med Spring Framework og har bidratt til å gjøre det svært enkelt å raskt få opp en Spring applikasjon. Dette passer seg ypperlig i de fleste prosjekter, men størst effekt har det muligens hatt på hvor raskt man kan få opp en fungerende prototype. Kort fortalt så er Spring Boot en ferdig kurert pakke fylt med versjoner av biblioteker som fungerer godt sammen. Det er lagt opp basiskonfigurasjon basert på hva som er et godt utgangspunkt. Det vil si at du som utvikler ikke trenger å foreta deg noe før du trenger det. Spring Boot er ferdig satt sammen til å «bare fungere». Du fyller inn litt kode og Spring Boot ordner webserver, database, logging, metrikker og mye mye mer.
Spring Boot vil bli demonstrert i de neste kapitlene.
Status i dag
Spring er i dag ute med versjon 5. Denne versjonen introduserte støtte for blant annet Reactive Programming og funksjonell programmering med Kotlin. Versjon 6 av Spring Framework og versjon 3 av Spring Boot er på tapeten for publisering i 2022 og vil støtte Jakarta EE 9 som ble sluppet i 2020. Eclipse Foundation har utført et stort arbeid i forbindelse av overtakelsen av Java EE. Dette innebærer blant annet å endre navn på en del spesifikasjoner og pakkenavn. Endringer på navn gjør at det kreves en del mer fra rammeverk som Spring, men det var et nødvendig arbeid da ordet ‘java’ er eid av Oracle. Eclipse Foundation ser allerede videre mot publiseringen av Jakarta EE 10 sent i 2021 med mange spennende forbedringer.
Spring Framework 6 og Spring Boot 3 blir veldige viktige versjoner. Konkurrerende rammeverk som Micronaut og Quarkus som gir bedre ytelse ved oppstart har økt i popularitet. Som tidligere nevnt må man være tilpasningsdyktig dersom man skal overleve i et marked som endrer seg så hyppig.
Kilder
For å få en oversikt over historikken til Spring og J2EE har jeg benyttet med av flere gode kilder som jeg lister her. Jeg anbefaler å ta en titt på disse for mer utdypende informasjon som ikke hadde sin naturlige plass i denne korte oppsummeringen.
Øyvind Ahlstrøm
