streamalism.org

1. Inleiding

In dit artikel bespreken we de nieuwe op tijd gebaseerde releases van Java en de impact op alle soorten ontwikkelaars.

Wijzigingen in het releaseschema omvatten het bijwerken van de levering van functies en ondersteuningsniveaus voor versies van Java. Over het algemeen verschillen deze wijzigingen duidelijk van de Java die sinds 2010 door Oracle wordt ondersteund.

2. Waarom zesmaandelijkse releases?

Voor degenen onder ons die gewend zijn aan Java's historisch langzame release-cadans, is dit een behoorlijk belangrijke afwijking. Waarom zo'n ingrijpende verandering?

Oorspronkelijk definieerde Java zijn belangrijkste releases rond de introductie van grote functies. Dit had de neiging om vertragingen te veroorzaken, zoals we allemaal hebben meegemaakt met Java 8 en 9. Het vertraagde ook de taalinnovatie, terwijl andere talen met strakkere feedbackcycli zich ontwikkelden.

Simpel gezegd, kortere release-periodes leiden tot kleinere, beter beheersbare stappen voorwaarts. En kleinere functies zijn gemakkelijker toe te passen.

Zo'n patroon past goed in de huidige omstandigheden en stelt JDK-ontwikkeling in staat om te werken in agile methodologieën die vergelijkbaar zijn met de gemeenschap die het ondersteunt. Het maakt Java ook competitiever met runtimes zoals NodeJS en Python.

Natuurlijk heeft het langzamere tempo ook zo zijn voordelen, en dus speelt de releasecyclus van zes maanden ook een rol in een groter raamwerk voor ondersteuning op de lange termijn, waar we in hoofdstuk 4 naar kijken.

3. Versienummer wijzigen

Een mechanisch aspect van deze wijziging is een nieuw versienummer-schema.

3.1. JEP 223 Version-String Scheme

We zijn allemaal bekend met de oude, gecodificeerd in JEP 223. Door dit schema werden de versienummers oplopend en werd extra informatie doorgegeven.

 Werkelijke hypothetische vrijgavetype lang kort ------------ ------------------------ Beveiliging 2013/06 1.7.0_25- b15 7u25 Minor 2013/09 1.7.0_40-b43 7u40 Beveiliging 2013/10 1.7.0_45-b18 7u45 Beveiliging 2014/01 1.7.0_51-b13 7u51 Minor 2014/05 1.7.0_60-b19 7u60

Als we rennen java -versie op een JVM voor versie 8 of ouder, zien we zoiets als:

> java -version java-versie "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, gemengde modus, delen)

In dit geval zouden we kunnen raden dat dit voor Java 6 is, wat correct is, en de 27e update, die fout is. Het nummeringsschema is niet zo intuïtief als het lijkt.

Kleine releases waren veelvouden van 10 en beveiligingsreleases vulden al het andere. Meestal zien we de korte string toegevoegd aan onze lokale installaties, zoals JDK 1.8u174. De volgende release kan zijn JDK 1.8u180, wat een kleine release zou zijn met nieuwe fixes.

3.2. Nieuw Version-String-schema

Het nieuwe versie-tekenreeksschema zal “versienummers herschikken om niet compatibiliteit en significantie te coderen, maar eerder het verstrijken van de tijd in termen van releasecycli,”Aldus Mark Reinhold in de JEP.

Laten we er een paar bekijken:

9.0.4 11.0.2 10.0.1

Op het eerste gezicht lijkt dit een semantisch versiebeheer te zijn; dit is echter niet het geval.

Met semantisch versiebeheer is de typische structuur $ MAJOR. $ MINOR. $ PATCH, maar Java's nieuwe versiestructuur is:

$ FUNCTIE. $ TUSSENTIJDS. $ UPDATE. $ PATCH

$ FUNCTIE is wat we zouden kunnen zien als de hoofdversie, maar wordt elke zes maanden verhoogd, ongeacht compatibiliteitsgaranties. En $ PATCH is voor onderhoudsreleases. Maar hier houden de overeenkomsten op.

Eerste, $ TUSSENTIJDS is een tijdelijke aanduiding, gereserveerd door Oracle voor toekomstige behoeften. Voorlopig zal het altijd nul zijn.

En ten tweede, $ UPDATE is op tijd gebaseerd zoals $ FUNCTIE, maandelijks bijwerken na de laatste feature release.

En tot slot worden volgnullen afgekapt.

Dit betekent dat 11 is het releasenummer voor Java 11, uitgebracht in september 2018, 11.0.1 is de eerste maandelijkse update-uitgave in oktober, en 11.0.1.3 zou een hypothetische derde patchrelease zijn van de versie van oktober.

4. Meerdere versie-distributies

Laten we vervolgens kijken hoe we de juiste versie kunnen kiezen.

4.1. Stabiliteit

Simpel gezegd, Java heeft nu een snel kanaal, elke zes maanden, en een langzaam kanaal, elke drie jaar.Elke derdejaarsrelease wordt een LTS-release genoemd.

Op het snelle kanaal geeft de taal functies uit tijdens incubatie. Deze taalfuncties stabiliseren zich in de LTS-release.

Dus voor bedrijven die volatiliteit kunnen omarmen in ruil voor het gebruik van nieuwe functies, kunnen ze het snelle kanaal gebruiken. Bedrijven die stabiliteit waarderen en kunnen wachten met upgraden, kunnen upgraden bij elke LTS-release.

Door te experimenteren met JDK-versies, kunnen ontwikkelaars de beste oplossing vinden.

4.2. Ondersteuning

Er is natuurlijk ook een kwestie van ondersteuning. Wat moeten we doen nu de ondersteuning van Java 8 is beëindigd?

En zoals eerder besproken, komt het antwoord in LTS-versies, Java 11 is de meest recente LTS-release en 17 is de volgende. Updates zullen beschikbaar zijn en worden ondersteund door leveranciers zoals Oracle en Azul.

Als we de steun van de gemeenschap kunnen vertrouwen, dan hebben Redhat, IBM en anderen hun steun uitgesproken voor het toepassen van bugfixes voor OpenJDK. Het AdoptOpenJDK-project biedt ook vooraf gebouwde binaire bestanden voor OpenJDK.

4.3. Licenties

Een gebied van verwarring voor sommigen is het verschil tussen OpenJDK en Oracle JDK.

Volgens Brian Goetz zijn ze eigenlijk nagenoeg identiek, en verschillen ze alleen in de gevallen waarin bugfixes en beveiligingspatches zijn opgepikt.

OpenJDK fungeert als de bron van de meeste afgeleide JDK's en blijft gratis. Vanaf Java 11 zal Oracle commerciële licentiekosten in rekening brengen voor de Oracle JDK, inclusief aanvullende ondersteuning en services.

4.4. Fragmentatie

Bij meer frequente releases kan fragmentatie een probleem worden. Hypothetisch gezien zou iedereen nog meer dan nu op verschillende versies van Java kunnen draaien met verschillende functies.

Containerisatie kan dit natuurlijk helpen aanpakken. Van Docker en CoreOS tot Red Hat's OpenShift, containerisatie biedt de benodigde isolatie en dwingt niet langer één installatielocatie voor Java om op de hele server te gebruiken.

5. Conclusie

Concluderend kunnen we veel meer verwachten van het Java-team bij Oracle met een regelmatige release van Java om de zes maanden. Als Java-ontwikkelaar is het vooruitzicht van elke zes maanden nieuwe taalfuncties opwindend.

Laten we enkele implicaties in gedachten houden terwijl we beslissen wat ons upgradekanaal is als we ondersteuning en licenties nodig hebben, en hoe we met fragmentatie om kunnen gaan.