streamalism.org

1. Introduksjon

I denne artikkelen vil vi diskutere de nye tidsbaserte utgivelsene av Java og innvirkningen på alle typer utviklere.

Endringer i utgivelsesplanen inkluderer oppdatering av funksjonslevering og støttenivåer for versjoner av Java. Samlet sett er disse endringene tydelig forskjellige fra Java som har blitt støttet av Oracle siden 2010.

2. Hvorfor seks måneders utgivelser?

For de av oss som er vant til Java's historisk langsom frigivelseskadens, er dette en ganske betydelig avvik. Hvorfor en så dramatisk endring?

Opprinnelig definerte Java sine viktigste utgivelser rundt introduksjonen av store funksjoner. Dette hadde en tendens til å skape forsinkelser, som de vi alle opplevde med Java 8 og 9. Det bremset også språkinnovasjon mens andre språk med strammere tilbakemeldingssykluser utviklet seg.

Enkelt sagt, kortere utgivelsesperioder fører til mindre, mer håndterbare skritt fremover. Og mindre funksjoner er lettere å ta i bruk.

Et slikt mønster passer godt sammen i dagens forhold og gjør at JDK-utvikling kan fungere i smidige metoder som ligner på samfunnet det støtter. Det gjør også Java mer konkurransedyktig med driftstider som NodeJS og Python.

Selvfølgelig har det lavere tempoet også fordelene, og så spiller seks måneders utgivelsessyklus også en rolle i et større Long Term Support-rammeverk, som vi ser på i avsnitt 4.

3. Versjonsnummerendring

Et mekanisk aspekt ved denne endringen er en ny versjonsnummerplan.

3.1. JEP 223 versjonsstrengskjema

Vi er alle kjent med den gamle, kodifisert i JEP 223. Denne ordningen gjorde versjonsnumrene inkrementelle og videreformidlet ekstra informasjon.

 Faktisk hypotetisk utgivelsestype lang kort ------------ ------------------------ Sikkerhet 2013/06 1.7.0_25- b15 7u25 Mindre 2013/09 1.7.0_40-b43 7u40 Sikkerhet 2013/10 1.7.0_45-b18 7u45 Sikkerhet 2014/01 1.7.0_51-b13 7u51 Mindre 2014/05 1.7.0_60-b19 7u60

Hvis vi løper java -versjon på en JVM for versjon 8 eller eldre, ser vi noe sånt som:

> java -versjon java-versjon "1.6.0_27" Java (TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07) Java HotSpot (TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

I dette tilfellet kan vi gjette at dette er for Java 6, som er riktig, og den 27. oppdateringen, som er feil. Nummereringsskjemaet er ikke så intuitivt som det ser ut.

Mindre utgivelser var multipler på 10, og sikkerhetsutgivelser fylte alt annet. Vanligvis ser vi den korte strengen som er lagt til lokale installasjoner, for eksempel JDK 1.8u174. Neste utgivelse kan være JDK 1.8u180, som vil være en mindre utgivelse med nye løsninger.

3.2. Ny versjon-strengordning

Den nye versjonen-streng ordningen vil "omstille versjonsnumre for ikke å kode kompatibilitet og betydning, men heller tidens gang, når det gjelder frigjøringssykluser,”Ifølge Mark Reinhold i JEP.

La oss ta en titt på noen:

9.0.4 11.0.2 10.0.1

Med et raskt blikk ser dette ut til å være semantisk versjonering; dette er imidlertid ikke tilfelle.

Med semantisk versjonering er den typiske strukturen $ STOR. $ MIN. $ PATCH, men Javas nye versjonsstruktur er:

$ FUNKSJON. $ INTERIM. $ OPPDATERING. $ PATCH

$ FUNKSJON er det vi kanskje tenker på som hovedversjonen, men vil øke hver sjette måned, uavhengig av kompatibilitetsgarantier. Og $ PATCH er for vedlikeholdsutgivelser. Men det er her likhetene stopper.

Først, $ INTERIM er en plassholder, reservert av Oracle for fremtidige behov. Foreløpig vil det alltid være null.

Og for det andre $ OPPDATERING er tidsbasert som $ FUNKSJON, oppdateres månedlig etter den siste utgivelsen av funksjoner.

Og til slutt blir etterfølgende nuller avkortet.

Dette betyr at 11 er utgivelsesnummeret for Java 11, utgitt i september 2018, 11.0.1 er den første månedlige oppdateringsutgivelsen i oktober, og 11.0.1.3 ville være en hypotetisk tredje oppdatering fra oktoberversjonen.

4. Flere versjonsdistribusjoner

Deretter, la oss se på hvordan du velger riktig versjon.

4.1. Stabilitet

Enkelt sagt, Java har nå en rask kanal hvert sjette år og en treg kanal hvert tredje år.Hver tredjeårsutgivelse kalles en LTS-utgivelse.

På den raske kanalen frigjør språket funksjoner i inkubasjon. Disse språkfunksjonene stabiliserer seg i LTS-utgivelsen.

Så for selskaper som kan omfavne volatilitet i bytte for å bruke nye funksjoner, kan de bruke den raske kanalen. For bedrifter som setter pris på stabilitet og kan vente med å oppgradere, kan de oppgradere ved hver LTS-utgivelse.

Eksperimentering med JDK-versjoner gjør at utviklere kan finne den beste passformen.

4.2. Brukerstøtte

Det er selvfølgelig også spørsmål om støtte. Nå som Java 8-støtten har gått ned, hva gjør vi?

Og som diskutert tidligere, kommer svaret i LTS-versjoner, Java 11 er den siste LTS-utgivelsen, og 17 er den neste. Oppdateringer vil være tilgjengelige og støttes av leverandører som Oracle og Azul.

Hvis vi kan stole på støtten fra samfunnet, har Redhat, IBM og andre uttalt seg om å støtte feilrettinger for OpenJDK. AdoptOpenJDK-prosjektet gir også forhåndsbygde binærfiler for OpenJDK.

4.3. Lisensiering

Et område med forvirring for noen er forskjellen mellom OpenJDK og Oracle JDK.

Egentlig er de nesten identiske, og de er bare forskjellige i hvilke feilrettinger og sikkerhetsoppdateringer som er plukket opp, ifølge Brian Goetz.

OpenJDK fungerer som kilden til de fleste avledede JDK-ene og forblir gratis. Fra og med Java 11 vil Oracle belaste kommersielle lisensavgifter for Oracle JDK med ekstra støtte og tjenester inkludert.

4.4. Fragmentering

Med hyppigere utgivelser kan fragmentering bli et problem. Hypotetisk kan alle kjøre på forskjellige versjoner av Java med forskjellige funksjoner enda mer enn nå.

Selvfølgelig kan containerisering hjelpe til med å løse dette. Fra Docker og CoreOS til Red Hats OpenShift, gir containerisering nødvendig isolasjon og tvinger ikke lenger ett installasjonssted for Java til å bli brukt på tvers av serveren.

5. Konklusjon

Avslutningsvis kan vi forvente mye mer fra Java-teamet på Oracle med en vanlig utgivelse av Java hver sjette måned. Som Java-utvikler er utsiktene til nye språkfunksjoner hver sjette måned spennende.

La oss huske noen av implikasjonene når vi bestemmer hva oppgraderingskanalen vår er hvis vi trenger støtte og lisensiering, og hvordan vi skal takle fragmentering.