Java EE drukner i sit eget fedt

Javas miljø til udvikling af virksomheds-programmer er oppustet, overvægtigt, træt og udpint. Så kontant lyder meldingen fra Rod Johnson, der står bag det konkurrerende miljø Spring.

Der skal nye boller på suppen, hvis Javas miljø til serverprogrammering EE (Enterprise Edition) skal overleve på sigt.

Det er den barske konklusion i et nyt blog-indlæg fra programmøren Rod Johnson, som står bag letvægtsmiljøet Spring, der på mange måder konkurrerer med det officielle JEE-miljø og dets sværvægter-spillere såsom IBM, Oracle og Sun.

JEE er oppustet, overvægtig, træt og udpint i sin nuværende version 5, men flere ting peger på, at det heldigvis bliver bedre i den kommende version 6, skriver Johnson på sin blog.

Den kommende Java EE 6-specifikation vil endelig tillade en større grad af modularitet, mener Johnson. Det vil få stor betydning for udviklerne og vil formentlig genskabe konkurrencen imellem de eksisterende JEE-implementeringer.

Kig i krystalkuglen

Rod Johnson tager også et kig i krystalkuglen og giver sit bud på en række forudsigelser om Javas enterprise-miljø:

  • Der vil komme mere ægte konkurrence indenfor applikationsservere, som følge af modulariteten i den kommende Java EE 6.

  • Den næste generation af applikationsservere vil blive mindre i omfang, gætter Johnson. Han peger på, at analytikere mener, at mange applikationer ikke har behov for en fuld JEE-server, men kan klare sig fint med Tomcat og et par ekstra komponenter fra JEE-miljøet.

  • Andre specifikationer vil få en rolle, end bare dem, som Javas standardiseringsgruppe JCP udstikker. Det gælder OSGi og kommende teknologier så som Service Component Architecture (SCA).

  • Markedet må se på hullet imellem Tomcat og WebLogic/WebSphere. De fleste Java-applikationer hører mest hjemme på Tomcats platform, mener Johnson, der peger på, at mange ønsker de operationelle og styringsmæssige funktioner, som de store implementeringer kan tilbyde, men uden den ekstra vægt, som disse funktioner ofte fører med sig.

  • Der vil komme bro over kløften mellem applikationsservere og Enterprise Service Bussen. Dette er en logisk konsekvens af væksten i middleware-komponenter, som blot er almindelige Java-objekter (POJO's). Han mener, at hans eget Spring-miljø allerede er i stand til at udrulle over forskellige miljøer, og det er der også behov for i hele JEE-platformen.

Hvad mener du?

Er der håb for Java EE, eller er det på tide at finde en anden platform for virksomheds-software i Java-verdenen? Giv dit besyv med i debatten herunder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kasper Sørensen

Denne kritik er hørt før, men som altid har Rod Johnson fat i den lange ende. Jeg er ved at være træt af al den kritik af JEE - ikke fordi den ikke er berettiget, men fordi kritikere tit ikke forstår at JEE ikke er den eneste udvej for enterprise java projekter. Netop Spring (eller for den sags skyld nogle af JBoss's frameworks) mener jeg er en fin fin erstatning og brillierer ved at være letvægt, administrérbar og først og fremmest testbar. Derfor er jeg glad for Rod Johnsons kritk - fordi den præsenterer løsningen og ikke bare problemet.

  • 0
  • 0
Martin Boel

Er det ikke lige at stramme livremmen?

Hvad koster det at inkludere et par extra jar's?

Personligt er det mest opstartstid der generer mig, men ofte kan man containeren samle ændringer op løbende, og så er det jo ikke noget problem.

Og at vi har nogle standarder med i værtøjskassen behøver vel ikke at betyde at man er NØD til at bruge dem.

Jeg blander gerne spring og JEE, og klipper og klisterer....

  • 0
  • 0
Martin Kofoed

Har en perfid numeorolog mon været på spil med det navn? :-)

Anyway, Rod's indvendinger var fuldt valide, da han første gang kørte road-show med dem i J2EE's velmagtsdage. I dag har Java EE5 adresseret utrolig mange af de punkter, som Rod stadig turnerer med. Egentlig utroligt at manden også har tid til at skrive software ...

Langt hen ad vejen gør Java EE5 det også muligt at anvende "convention over configuration", hvor man slipper for endeløse rækker af XML-konfigurationsfiler, hvis man kan leve med default settings (hvad man ofte kan). Sidst jeg checkede Spring, flyttede man groft sagt bare en masse kompleksitet ud af koden og ind i XML-filer. Det kan være fint nok, og ved hjælp af en masse magi kan ens beans så komme til at ligne pojos. Dem kommer en "ny" mand på projektet så lige til at køre refactoring på uden at ændre den tilhørende konfiguration => kaos.

Det er givetvis blevet anderledes nu. Men pointen er bare, at behovet for sådan noget som Spring Framework er væsentligt mindre i dag, end det var for 3-4 år siden. Men det har da fuldt fortjent fået en masse fans, og de holder vel fast.

Det er snarere projekter som Qi4J, der i dag skubber til den måde, vi opfatter Java på.

  • 0
  • 0
Log ind eller Opret konto for at kommentere