Java's tidsbaserede udgivelser

1. Introduktion

I denne artikel vil vi diskutere de nye tidsbaserede udgivelser af Java og indvirkningen på alle typer udviklere.

Ændringer i udgivelsesplanen inkluderer opdatering af funktionslevering og supportniveauer for versioner af Java. Samlet set er disse ændringer tydeligt forskellige fra Java, der har været understøttet af Oracle siden 2010.

2. Hvorfor seks måneders frigivelse?

For dem af os der er vant til Java's historisk langsom frigivelseskadens, er dette en ret betydelig afgang. Hvorfor en så dramatisk ændring?

Oprindeligt definerede Java sine store udgivelser omkring introduktionen af ​​store funktioner. Dette havde en tendens til at skabe forsinkelser, som dem vi alle oplevede med Java 8 og 9. Det bremsede også sproginnovation, mens andre sprog med strammere feedback-cyklusser udviklede sig.

Kort sagt fører kortere frigivelsesperioder til mindre, mere håndterbare skridt fremad. Og mindre funktioner er lettere at anvende.

Et sådant mønster passer godt sammen i de nuværende forhold og giver JDK-udvikling mulighed for at arbejde i agile metoder, der ligner det samfund, det understøtter. Det gør Java også mere konkurrencedygtigt med driftstider som NodeJS og Python.

Selvfølgelig har det langsommere tempo også sine fordele, og derfor spiller seks måneders frigivelsescyklus også en rolle i en større Long Term Support-ramme, som vi ser på i afsnit 4.

3. Version nummerændring

Et mekanisk aspekt af denne ændring er en ny version-nummerordning.

3.1. JEP 223-version-strengordning

Vi kender alle den gamle, kodificeret i JEP 223. Denne ordning gjorde versionsnumre inkrementelle og videreformidlede ekstra information.

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

Hvis vi løber java -version på en JVM til version 8 eller ældre ser vi noget som:

> java -version java version "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, blandet tilstand, deling)

I dette tilfælde kan vi gætte, at dette er for Java 6, som er korrekt, og den 27. opdatering, som er forkert. Nummereringsskemaet er ikke så intuitivt, som det ser ud.

Mindre frigivelser var multipla af 10, og sikkerhedsudgivelser fyldte alt andet. Typisk ville vi se den korte streng tilføjet til vores lokale installationer, såsom JDK 1.8u174. Den næste udgivelse kan være JDK 1.8u180, hvilket ville være en mindre udgivelse med nye rettelser.

3.2. Ny version-strengordning

Den nye version-streng-ordning vil “omarbejdede versionsnumre for ikke at kode for kompatibilitet og betydning, men snarere tidens gang i form af frigivelsescyklusser,”Ifølge Mark Reinhold i JEP.

Lad os se på nogle:

9.0.4 11.0.2 10.0.1

Med et hurtigt blik ser det ud til at være semantisk versionering; dette er imidlertid ikke tilfældet.

Med semantisk versionering er den typiske struktur $ STOR. $ MIN. $ PATCH, men Java's nye versionstruktur er:

$ FUNKTION. $ INTERIM. $ UPDATE. $ PATCH

$ FUNKTION er, hvad vi måske tænker på som den store version, men øges hver sjette måned uanset kompatibilitetsgarantier. Og $ PATCH er til vedligeholdelsesudgivelser. Men det er her lighederne stopper.

Først, INTERIM $ er en pladsholder, reserveret af Oracle til fremtidige behov. Indtil videre vil det altid være nul.

Og for det andet $ OPDATERING er tidsbaseret som $ FUNKTION, opdateres månedligt efter den seneste funktionsudgivelse.

Og til sidst er efterfølgende nuller afkortet.

Det betyder at 11 er frigivelsesnummeret til Java 11, udgivet i september 2018, 11.0.1 er den første månedlige opdateringsudgivelse i oktober, og 11.0.1.3 ville være en hypotetisk tredje patchudgivelse fra oktoberversionen.

4. Flere distributioner af versioner

Lad os derefter se på, hvordan man vælger den rigtige version.

4.1. Stabilitet

Kort sagt, Java har nu en hurtig kanal hvert halve år og en langsom kanal hvert tredje år.Hver tredjeårsudgivelse kaldes en LTS-udgivelse.

På den hurtige kanal frigiver sproget funktioner i inkubation. Disse sprogfunktioner stabiliserer sig i LTS-udgivelsen.

Så for virksomheder, der kan omfatte volatilitet i bytte for at bruge nye funktioner, kan de bruge den hurtige kanal. For virksomheder, der sætter pris på stabilitet og kan vente med at opgradere, kan de opgradere ved hver LTS-udgivelse.

Eksperimentering med JDK-versioner gør det muligt for udviklere at finde den bedste pasform.

4.2. Support

Der er naturligvis også spørgsmålet om støtte. Nu hvor Java 8-support er gået ned, hvad gør vi?

Og som diskuteret tidligere kommer svaret i LTS-versioner, Java 11 er den seneste LTS-udgivelse, og 17 er den næste. Opdateringer vil være tilgængelige og understøttet af leverandører som Oracle og Azul.

Hvis vi kan stole på støtte fra samfundet, har Redhat, IBM og andre erklæret deres støtte til anvendelse af fejlrettelser til OpenJDK. AdoptOpenJDK-projektet giver også forudbyggede binære filer til OpenJDK.

4.3. Licensering

Et område med forvirring for nogle er forskellen mellem OpenJDK og Oracle JDK.

Faktisk er de næsten identiske og adskiller sig kun, i hvilke fejlrettelser og sikkerhedsrettelser er blevet plukket, ifølge Brian Goetz.

OpenJDK fungerer som kilden til de fleste afledte JDK'er og forbliver gratis. Fra og med Java 11 opkræver Oracle kommercielle licensafgifter for Oracle JDK med yderligere support og tjenester inkluderet.

4.4. Fragmentering

Med hyppigere udgivelser kan fragmentering blive et problem. Hypotetisk kunne alle køre på forskellige versioner af Java med forskellige funktioner endnu mere end nu.

Naturligvis kan containerisering hjælpe med at løse dette. Fra Docker og CoreOS til Red Hats OpenShift giver containerisering den nødvendige isolering og tvinger ikke længere en installationsplacering, hvor Java kan bruges på tværs af serveren.

5. Konklusion

Afslutningsvis kan vi forvente meget mere fra Java-teamet på Oracle med en regelmæssig frigivelse af Java hvert halve år. Som Java-udvikler er udsigten til nye sprogfunktioner hver sjette måned spændende.

Lad os huske nogle af konsekvenserne, når vi beslutter, hvad vores opgraderingskanal er, hvis vi har brug for support og licensering, og hvordan vi skal håndtere fragmentering.


$config[zx-auto] not found$config[zx-overlay] not found