De volgende gewone update krijgt het nummer 40 mee, en de drie daaropvolgende kritieke updates de nummers 45, 51 en 55. Daarna komt volgens planning de volgende gewone update die dan versienummer 60 heeft. “Met de recente toename in security-releases hebben we nummers overgeslagen en ook al releases moeten hernummeren”, kondigt Oracle aan in een supportdocument. “Om verwarring veroorzaakt door het hernummeren van releases te vermijden, stappen we over op een nieuw nummeringsschema.”

De ene update is de andere niet

Oracle geeft zijn gewone updates voor Java de benaming Limited Update (LU’s), terwijl beveiligingspatches voor kritieke gaten de naam Critical Patch Updates (CPU’s) dragen. Eerstgenoemde brengt nieuwe functies en non-security fixes, terwijl de tweede updatesoort alleen fixes voor kwetsbaarheden bevat. De LU’s krijgen voortaan nummers in de twintigtallen, zodat er daar tussenin ineens veel meer ruimte is voor CPU-nummers. Dat zijn dan echter niet gewoon de nummers tussen het ene en het volgende twintigtal.

Voorheen hanteerde Oracle oneven nummers voor de kritieke patches die het uitbracht. Deze zogeheten CPU’s (Critical Patch Updates) waren dan dus Java 7 Update 1, Java7u3, 7u5, enzovoorts. De normale updates kregen dan de even nummers: 7u2, 7u4, en zo verder optellend. De noodpatch die Oracle in januari dit jaar heeft uitgebracht, heeft namelijk roet in het eten gegooid.

Nummers opschuiven

Die securityfix is buiten het reguliere releaseschema uitgekomen en heeft een nummer ingenomen dat al ‘gereserveerd’ was, meldt Oracle in een supportdocument hierover. In augustus vorig jaar is ook al een hernummering uitgevoerd. Dat heeft niet alleen gevolgen voor de huidige Java 7-reeks maar ook voor voorganger 6. Door de hernummering van afgelopen zomer is de kritieke patch van oktober 2012 omgenummerd naar Java 7 Update 9 en Java 6 Update 37.

Voor het nieuwe schema handhaaft Oracle de oneven nummers voor CPU’s, maar berekent het die door vijftallen toe te voegen aan het versienummer van de voorgaande LU. En, indien nodig, nog een nummer erbij om toch weer uit te komen op een oneven nummer. Zo komt het softwarebedrijf dus op het zelf gegeven voorbeeld van de aankomende securityreleases 7u40, 7u45, 7u51, 7u50, gevolgd door LU 7u60 en dan weer CPU’s 7u65, 7u71 en 7u75.

Vanwege compatibiliteit

Het hanteren van twintigtallen voor de gewone updates en meervouden van vijf voor de kritieke beveiligingspatches geeft ruimte voor ongeplande tussenreleases die eventueel nog nodig kunnen zijn. Hernummering van reeds geplande latere releases is dan niet nodig, merkt Oracle op in het supportdocument. De nieuwe tellingsmethode geldt voor de Java-reeksen 7, 6 en 5. De twee laatstgenoemde oudere reeksen zijn alleen verkrijgbaar voor gebruikers met een Oracle-supportcontract.

Het complexe nieuwe nummersysteem is dus nodig vanwege de vele patches die Oracle moet uitbrengen voor het veelgeplaagde Java. Een betere, elegantere oplossing is in theorie wel mogelijk, aldus de softwaremaker in de FAQ over de nieuwe telling, maar dat is in de praktijk niet mogelijk. Java moet namelijk terugwaartse compatibiliteit hebben met systemen die er van uitgaan dat het versienummer bestaat uit een familienummer (7, 6 of 5) en dan een enkel update-nummer.

Kan (niet) eleganter

Een echte verandering om verschillende soorten releases te kunnen onderscheiden, moet dus wachten op een toekomstige Java-release. “Om incompatibiliteit met bestaande code te vermijden, moet een verandering in het formaat voor versies gedocumenteerd en gecommuniceerd worden met voldoende tijd voor software-ontwikkelaars om zich voor te bereiden op die verandering.” Dit lijkt erop te duiden dat een geheel nieuw versiesysteem niet al voor het veelvuldig uitgestelde Java 8 valt te verwachten. Die nieuwe release staat nu gepland voor 18 maart 2014.