Udvikler: Derfor skal du bruge Javas moduler

Illustration: mkabakov/Bigstock
Java 9's modulforslag er vedtaget, men kan det bruges til noget? Freelance-udvikler Christian Damsgaard hælder til et »ja.«

Tidligere på måneden kunne styregruppen bag Java ånde lettet op, da et forslag om at indføre moduler i Java 9, som er sprogets kommende version, endeligt blev vedtaget efter megen besvær og tovtrækkeri.

I den kommende version 9 handler den store nyhed om at skære koden i bidder, eller rettere sagt i moduler, som er et begreb, der ligger et trin højere en Javas medfødte modularisering ved hjælp af pakker. Modularisering på højere niveau end pakker giver en række fordele. Det kan gøre kørselsmiljøet mindre, ved kun at kræve de klassebiblioteker som rent faktisk benyttes i koden.

Christian Damsgaard, som er freelance-udvikler og mangeårig bestyrelsesmedlem i brugerklubben Javagruppen, er overvejende positiv overfor modulariseringen, også selv om den valgte model ligger langt fra øvrige eksisterende modulariseringsmetoder i Java:

»Jeg synes det er godt: gennemarbejdet og meget veldokumenteret, i forhold hvad man ellers møder. Jeg har tidligere brugt JBoss’ modulsystem. En stor udfordring med enterprise-servere er, at containeren kommer med en JVM og et væld af biblioteker, deres egne og tredjepartsbiblioteker. Når du får brug for en anden variant af et bibliotek, kommer du ud for store udfordringer for at få din udgave af biblioteket med.«

Læs også: Kæmpe omlægning i Java 9: Sådan bliver koden skåret i bidder

I en Java-enterpriseserver (JEE) indlæses koden via forskellige classloaders, og det kan nemt blive meget komplekst. Disse problemer kan Java 9’s modularisering ikke løse, påpeger Christian Damsgaard.

Af samme grund har både IBM og Red Hat har talt for en anden moduliserings-løsning, og det var årsagen til modstanden mod Java 9-forslaget i første omgang. Nu er modul-forslaget vedtaget, og så må enterprise-servernes behov komme til en anden gang.

»Man har sagt: Den bro krydser vi senere.«

Læs også: Red Hat og IBM giver sig: Java 9 kommer til september

Nu handler det om det muliges kunst. Modul-forslaget har været så lang tid undervejs, at der var behov for at levere et resultat:

»Ellers blev man nok lidt til grin i miljøet.«

Bedre styr på versioner

Der er altid nogen, som vil mene, at nye måder at gøre tingene på ikke passer ind i deres verden, men nogle af interessenterne meler også deres egen kage, synes Christian Damsgaard.

»Når det er sagt, så synes jeg at man nu har meget bedre håndtering af afhængigheder i Java-miljøet. «

Her kunne udviklerne tidligere anvende systemer som Maven og Gradle, der er to build-systemer til Java.

»Nu er ideen bagt ind i systemet, og det giver mulighed for bedre indkapsling af moduler.«

Hvis man i Java 8 bruger en Jar-fil, der indkapsler Java-kode i en slags zip-fil, kan man tilgå hele koden. Det gælder for eksempel også sun.misc.*-klasserne i Javas kørselsbibliotek rt.jar, som det egentlig ikke er meningen, at udviklerne skal benytte. Med modulerne i Java 9 bliver det muligt at nægte adgang til bestemte klasser og pakker.

»Som biblioteksudvikler kan man meget bedre sige: De her klasser må brugeren anvende, og de her klasser er private. Så bliver det nemmere at ændre i den private kode, uden at knække afhængighederne til brugerne.«

Det giver en nemmere hverdag for biblioteksudviklere, som ikke skal tænke på en utilsigtet anvendelse af bibliotekskoden.

Et andet problem opstår, når et kørselsmiljø anvender de samme biblioteker flere gange. Christian Damsgaard har ofte brugt megen tid på at gennemgå sit projekts classpath, som er en liste af biblioteker, der skal indlæses i et Java-program, med henblik på at få en bestemt version af et bibliotek med.

»Nu kommer der alarmer, når classpath’en indeholder dubletter.«

Det er en god ting, for det gør problemet synligt.

Alle kan bruge Java 9-moduler

»Det er et modulsystem til masserne, som alle kan bruge. Jeg sidder selv i organisation, hvor vi genbruger på tværs. Her bruger vi Jar-filer, men jeg vil anbefale, at man i forbindelse med migrering til Java 9, bruger modul-funktionalitet. «

Jlink, som gør det muligt at skabe binære kørselsmiljøer med kun den kode, som programmet rent faktisk bruger, får også en opadvendt tommel fra Christian Damsgaard.

»Din applikations fodaftryk bliver ekstremt lille. Når den virtuelle maskine starter op, skanner den alle pakkerne, og det tager lang tid i tomgang.«

Det giver også mulighed for at compile koden til ‘født’ eller native kode. Det kan have betydning i forhold til Internet of Things, med meget små enheder, som blandt andet kan spare strøm i forhold til at skulle have et stort og tungt afviklingsmiljø på de små enheder.

Et andet område er mikrotjenester, hvor der kan være 50 eller 100 afhængigheder i et simpelt ‘hej verden'-program. Her kan Jlink skære fedtet fra.

Endeligt kan Jlink bidrage til hurtige opstart af den virtuelle maskine.

Bedre styr på moduler og versioner kan også hjælpe til bedre sikkerhed, så bibliotekskode med kendte sårbarheder nemmere kan identificeres i kørselsmiljøet.

Moduler vil komme gradvist

Men en god specifikation er ikke nødvendigvis nogen garanti for, at det vil blive en succes. Og Red Hat har ligefrem anbefalet, at man ikke bruger Java 9 til at kompilere kode med i fremtiden.

Christian Damsgaard siger:

»Der kommer til at gå nogle år. Det er et skridt på vejen. Biblioteks-udviklerne vil begynde at lave modul-baserede udgaver af bibliotekerne. Enterprise-udviklerne kommer ikke til at støde på det her før om to år,« lyder vurderingen.

Præmissen for at det bliver en succes er, at teknologien virker og er veldokumenteret. Og her tror Christian Damsgaard, at det nok skal gå. Sammenlignet med OSGI og JBoss-moduler, som kræver ekspertviden er Java 9’s for ‘menigmand', som Christian Damsgaard udtrykker det.

»Værktøjerne og dokumentation er lige til at gå til. Det er forholdsvist nemt. Men det vil ske gradvist. «

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ivo Santos

»Som biblioteksudvikler kan man meget bedre sige: De her klasser må brugeren anvende, og de her klasser er private. Så bliver det nemmere at ændre i den private kode, uden at knække afhængighederne til brugerne.«

Jeg aner intet om Java udover jeg kan skrive en meget simpelt 'hej allesammen' begynder modul, men!, da jeg læste følgende afsnit kom jeg til at tænke på at man burde overveje at benytte nogle af de tekniker som 'Visual Basic (VB)' benytter sig af.

Når jeg designer en VB dll fil så kan man sætte alle private klasser til at være private, og de klasser som kun må oprettes af den pågældende dll kan sættes til at være 'Public Non Creatable' altså kan man ikke i sit klient program oprette klasser af den type direkte.

Ud over det så kan man også definere funktioner til kun at være synlig indefor rammerne af det pågældende dll via 'Friend' ordet, så vidt jeg ønsker.

Derfor jeg tænkte at man burde indføre nogle af de tekniker som VB benytter sig af i Java moduler, eller er der noget jeg misforstå!!.

carsten guldhammer

Bortset fra at jeg for nogen år siden læste netop her på v2 om nog afhoppere fra java som havde lavet en ny konkurrent som kan det samme som java (hvis ikke mere) og som i tilgift skulle være langt mere simpelt at programmere i

Kan ikke huske hvad det heder, men har også hørt gennem arbejde at frem for andre sprog er java langt mere besværligt at ha med at gøre efter som en simpel kommando fylder flere sider lavet i java, hvor imod hos andre kan det laves på et par linjer

Rune Larsen

...at der stadig ikke er nogen håndtering af versionsafhængigheder mellem moduler.
Den indlysende løsning på det nuværende classpath hell er at tillade, at forskellige moduler afhænger af forskellige versioner af samme library. Det kommer måske efter yderligere 5 år?

Project jigsaw startede i 2012 og lader til at være blevet hijacket undervejs til at modularisere JVM'en internt fremfor at tilbyde et modul-system til det enorme, heterogene community af java-udviklere.

Millioner af spildte timer på at finde jar-versioner, som passer til alle dependencies fortsætter. Med deraf følgende opgraderingsfrygt og manglende sikkerhedspatches.

Det eneste gode ved java 9s defekte modul-system er, at bøvlet ved at lave store java monolitter med masser af dependencies, måske kan få folk til at bygge micro-services i stedet.

Log ind eller Opret konto for at kommentere