streamalism.org

1. Introduksjon

Har du noen gang hørt om Java EE? Hva med Java 2EE, J2EE, eller nå Jakarta EE? Faktisk, disse er alle forskjellige navn for det samme: et sett med spesifikasjoner for virksomheten som utvider Java SE.

I denne korte artikkelen vil vi beskrive utviklingen av Java EE.

2. Historie

I den første versjonen av Java var Java-utvidelser ganske enkelt en del av kjernen JDK.

Så, som en del av Java 2 i 1999, ble disse utvidelsene brutt ut av standard binærfiler, og J2EE, eller Java 2 Platform Enterprise Edition, ble født. Det vil beholde det navnet til 2006.

For Java 5 i 2006 ble J2EE omdøpt til Java EE eller Java Platform Enterprise Edition. Det navnet vil holde seg helt til september 2017, når noe større skjedde.

Se, i september 2017 bestemte Oracle seg for å gi bort rettighetene for Java EE til Eclipse Foundation (språket eies fortsatt av Oracle).

3. I overgang

Egentlig Eclipse Foundation lovlig hadde for å gi nytt navn til Java EE. Det er fordi Oracle har rettighetene over “Java” -merket.

Så for å velge det nye navnet stemte samfunnet og valgte: Jakarta EE. På en bestemt måte er det fortsatt JEE.

* Nytt navn kunngjort

Dette er fremdeles en historie i utvikling, og støvet har ikke lagt seg helt.

For eksempel, mens Oracle åpen kildekode, hadde de ikke all kildedokumentasjon. Det er fortsatt mye diskusjon om denne saken på grunn av juridiske problemer som gjør det vanskelig å åpne dokumentasjon med åpen kildekode relatert til for eksempel JMS og EJB.

Det er ikke klart ennå om ny Eclipse Foundation-dokumentasjon vil kunne referere til originalene.

Også, nysgjerrig, kan Eclipse Foundation ikke opprette noen nye Java-pakker ved hjelp av javax navneområdet, men det kan opprette nye klasser og underklasser under de eksisterende.

Overgangen betyr også en ny prosess for å legge til spesifikasjoner til Jakarta EE. For å forstå det bedre, la oss ta en titt på hvordan prosessen var under Oracle og hvordan den endres under Eclipse Foundation.

4. Fremtiden

Historisk sett, for at en funksjon skulle gjøre den til “EE”, trengte vi tre ting: en spesifikasjon, en referanseimplementering og tester. Disse tre tingene kunne leveres av alle i samfunnet, og en eksekutivkomité ville bestemme når disse var klare til å legge til språket.

For å bedre forstå den tidligere prosessen, la oss se nærmere på hva JSR, Glassfish og TCK er og hvordan de legemliggjorde nye EE-funksjoner.

Vi får også et glimt av hva vi kan forvente i fremtiden.

4.1. JCP og Now, EFSP

Tidligere ble prosessen der en ny EE-funksjon ble født kalt Java Community Process (JCP).

Java SE bruker fortsatt JCP i dag. Men siden EE har skiftet eierskap, fra Oracle til Eclipse Foundation, har vi en ny og egen prosess for det. Det er Eclipse Foundation Specification Process (EFSP), og det er en utvidelse av Eclipse Development Process.

Det er imidlertid noen viktige forskjeller, mest rundt "Transparency, Openenness, Shared Burden and Vendor Neutrality". EFSP-arrangørene ser for eksempel på samarbeidsgrupper som er leverandørneutrale, en sertifiseringsprosess som er selvbetjent, og en organisasjon som driver og styrer som et meritokrati.

4.2. JSR-er

I JCP var det første trinnet for å legge til en funksjon i EE å opprette en JSR- eller Java-spesifikasjonsforespørsel. JSR var litt som grensesnitt for en EE-funksjon. JCPs eksekutivkomité gjennomgikk og godkjente en ferdig JSR, og deretter ville JSR-bidragsytere kode den opp og gjøre den tilgjengelig for samfunnet.

Et godt eksempel på dette var JSR-339 - eller JAX-RS - som opprinnelig ble foreslått i 2011, godkjent av JCP i 2012 og til slutt utgitt i 2013.

Og mens samfunnet alltid kunne veie inn mens en spesifikasjon var under diskusjon, viste tiden at en implementerings-første tilnærming - som i tilfelle JSR 310, java.time, og Joda Time - pleide å skape mer aksepterte funksjoner og APIer.

Så, EFSP gjenspeiler denne førstevurderingen i sitt uttalte mål: "EFSP vil være basert på praktisk eksperimentering og koding først, som en måte å bevise at noe er verdig å dokumentere i en spesifikasjon."

4.3. Glassfisk

Da, som en del av JCP, trengte en JSR en referanseimplementering. Dette er litt som klasse som implementerer grensesnitt. En referanseimplementering hjelper utviklere av kompatible biblioteker eller andre organisasjoner som ønsker å lage sin egen implementering av spesifikasjonen.

For Java EE-funksjoner brukte JCP Glassfish for sine referanseimplementeringer.

Og mens denne sentraliseringen på Glassfish forenklet oppdagelsesprosessen for implementører, krevde denne sentraliseringen også mer styring og hadde en tendens til å favorisere en leverandør fremfor en annen.

Derfor krever ikke EFSP en referanseimplementering, men i stedet bare en kompatibel gjennomføring. Enkelt sagt, denne subtile endringen gjør at implementeringer inne i en sentral arkitektur, som Glassfish, vil ikke utilsiktet foretrekkes av stiftelsen.

4.4. TCK

Til slutt krevde JCP at EE-funksjoner ble testet gjennom Technology Compatibility Kit, eller TCK.

TCK var en serie tester for å validere en spesifikk EE JSR. For å si det enkelt, For å overholde Java EE, må en applikasjonsserver implementere alle JSR-ene og passere alle testene på den angitte TCK.

Her endres ikke mye. Oracle åpner TCK så vel som EE JSR. Selvfølgelig vil alle fremtidige dokumenter og TCK være åpen kildekode.

5. Konklusjon

Java EE har absolutt utviklet seg mye i løpet av disse årene. Det er hyggelig å se at det fortsetter å endre seg og forbedre seg.

Det er mange utfordringer foran oss, så la oss håpe på en jevn overgang.