Canonical ondersteunt elf jaar oude OpenJDK 8 op Ubuntu Pro tot 2034

Ubuntu-maker Canonical ondersteunt OpenJDK 8 tot 2034 op Ubuntu Pro. Daarmee loopt de ondersteuning voor de opensourcevariant van Java liefst twintig jaar op het besturingssysteem.

Canonical schrijft op zijn blog dat het voor Ubuntu Pro-gebruikers tot 2034 beveiligingsondersteuning levert voor OpenJDK 8, dat in 2014 uitkwam. Ook OpenJDK 11, 17 en 21 worden ten minste tot 2034 ondersteund. Canonical committeert zich voor alle OpenJDK lts-builds aan minimaal tien jaar beveiligingsondersteuning.

Canonical belooft ook nieuwe OpenJDK-releases, wanneer die uitkomen, toe te voegen aan de volgende lts-release van Ubuntu. Niet-lts-releases van OpenJDK worden aan de volgende interim-releases van Ubuntu toegevoegd.

Reacties (38)

[com2,1ghz]

De stap van java 8 naar java 9 is gigantisch. Dan ook nog eens de stap van 11 naar 17 met de Javax naar Jakarta.

Nou vraag ik me af wat voor applicaties dit zijn. Java applicaties worden 9 van de 10 keer gebouwd in frameorks als Spring. Commerciele ondersteuning van de laatste versie van Spring loopt tot 2029. Je zit dus met zwaar verouderde libraries en frameworks met de bijbehorende vulnerabilities.

Ik vraag me echt af wie hier nou belang bij heeft. Of zijn dit weer van die swing desktopapplicaties die in de lucht moeten blijven?

[Reactie gewijzigd door com2,1ghz op 2 juli 2025 16:43]

[MartyD]

Begin 2025 gebruikte zo'n 23% van de organisaties nog steeds JDK8 https://devclass.com/2025/01/30/state-of-java-report-shows-strong-migration-from-java-8-rise-of-apache-spark/.

[TheMak]

Een probleem is dat het opgraden een puzzel is. Hardware, os, applicaties en clients hebben allemaal hun eigen eisen voor de versies van de ander, dat een puzzel wordt. Daarnaast zal politiek ook een rol spelen. Oracle heeft het liefste dat je hun os en cloudoplossibgeb gebruikt. Als ze allemaal java 8 ondersteunen, dan is dar puzzelstukje snel gelegd.

[supersnathan94]

Alleen voor de hele complexe applicaties die überhaupt nooit iets met life cycle management en onderhoud hebben gedaan. Dan ga je inderdaad snel achter de feiten lopen. Voor de meeste applicaties was 8 naar 9 en uiteindelijk 17 vrij snel te doen hoor.


Oracle moet je daarin gewoon links laten liggen want dat is 1 grote sterfhuis constructie geworden met de licentiebedragen die zij noemden.

[kozue]

Ik denk dat er zelfs nog plekken zjjn waar je JDK6 tegen komt. Toen 11 uit was hadden we hier nog een third party applicatie draaien die niks hogers wilde dan 6. En dan ook alleen Oracle JVM, niet eens OpenJDK. Gelukkig is die troep al jaren geleden naar de cloud van de aanbieder verplaatst. Dan is het hun probleem, niet de onze. Ik mag toch hopen dat ze ondertussen de migratie naar een hogere versie achter de rug hebben en niet nog steeds met 6 aan het doormodderen zijn.

[YopY]

Ik vind het eigenlijk een slechte zaak dat ze zo lang support aanbieden voor deze doelgroep, dan hebben ze geen incentive om hun zaak bij te werken en mee te gaan met de ontwikkelingen. En dat zal ze ook pijn doen omdat er steeds meer mensen zullen zijn die zeggen "ik wil niet meer met Java 8 werken", waardoor je hetzelfde probleem krijgt als met COBOL.

Natuurlijk, nieuwer is niet altijd beter, en ik heb ook mijn twijfels bij de nieuwere features die ze over de jaren toegevoegd hebben. Maar gebruik daarvan is optioneel.

Lang verhaal kort, bedrijven moeten hun zooi bijwerken ipv afhankelijk blijven van externe partijen als Canonical of Red Hat of wie dan ook die over de jaren steeds meer geld vragen voor de extended support.

En als developer moet je je software ontwikkelen met upgradebaarheid en lange termijn in het achterhoofd. Minimaliseer je afhankelijkheden op 3e partijen (frameworks, runtimes, libraries), hou je code up to date, zeker als er iets deprecated wordt, blijf je dependencies bijwerken, en zorg voor een goede lange-termijn beheer strategie.

[Snow_King]

Misschien moeten we software juist wel langer ondersteunen? Waarom niet 10 of 15 jaar of in dit geval wel 20?

upgraden is vaak heel complex en welke concrete winst is er na een upgrade?

[The Realone]

Maar wat is "software" en wat is "ondersteunen"? Is OpenJDK de software? Of is het OpenJDK 8? OpenJDK wordt nog altijd prima ondersteund, we zitten echter op versie 10 dacht ik. En dit geldt natuurlijk voor zoveel software. Software an sich wordt vaak aan de lopende band bijgewerkt. Dat gaat echt niet alleen om nieuwe features, maar vooral om bug- en security fixes. Is dat dan wat je moet verstaan onder "ondersteunen"?

En als dat zo is, hoe ver mag de software dan nog afwijken van het "origineel" na die jaren van ondersteuning? Lijkt me niet echt realistisch.

[xFeverr]

OpenJDK wordt nog altijd prima ondersteund, we zitten echter op versie 10 dacht ik.

10 is al heel erg lang verleden tijd. 24 is latest, 21 is LTS

[Snow_King]

Ik snap je punt, maar als Java 8 werkt en daar doe je enkel security fixes op, dan is het prima toch? Welke wchte winst is versie 9? Als eindresultaat

[supersnathan94]

upgraden is vaak heel complex en welke concrete winst is er na een upgrade?

Geen (significant minder) vulnerabilities zoals Log4Shell meer in je applicatielandschap.


Ga maar gewoon Life Cycle Management implementeren. Meeste spul kun je automatisch laten doorvoeren door iets als renovate. Ben je automatisch up to date. Tenzij compilatie of tests falen. Dan moet je wel even iets aanpassen.

[Ozzie]

Log4shell is een heel slecht voorbeeld, want dat was een vulnerability in Log4J. Niet in de OpenJDK. Dus zelfs als je de allernieuwste JDK 24 gebruikt icm met een kwetsbare log4j versie dan ben je nog steeds gewoon vatbaar. Zolang je gewoon de security updates op JDK 8 blijft toepassen en je de features in hogere JDK's niet nodig heb is er echt geen enkele goede reden om te upgraden naar een nieuwere versie. Pas na 2030 als er geen security patches meer uitkomen is dat het geval. Of in het geval van Canonical na 2034.

[kozue]

Behalve dan dat libraries er hun eigen ondersteuningspolicies op nahouden. Ik zit niet in dat java wereldje en weet dus niet welke JDK versies log4j allemaal ondersteunt in welke versie, maar ik kan me goed voorstellen dat de laatste versie van log4j niet meer werkt in antieke meuk als JDK8. Dan zit je dus aan een oude versie vast, inclusief de vulnerabilities die daar in zaten en al opgelost zijn in de nieuwste.

Plus dat een upgrade van een basislaag zoals de runtime vaak gepaard gaat met een upgrade van alle libraries (onder andere door dat support verhaal, vaak moet je wel naar een hogere versie als je wil dat het werkt op jouw nieuwe JDK).

[Ozzie]

Zoals ik al zei is Log4j een slecht voorbeeld, want zelfs de allernieuwste versie ondersteunt gewoon Java 8. Er kunnen natuurlijk wel andere libraries zijn waar geen support meer voor is, maar het ging over JDK8. Natuurlijk is het beter om gewoon regelmatig al je libraries te updaten, maar gewoon JDK8 gebruikten betekent niet automatisch vulnerabilities net zoals JDK24 gebruiken niet automatisch betekent dat nergens vulnerabilities meer inzitten. Als jij JDK24 gebruikt met een of andere library waar een kwetsbaarheid in zit dan kan dat net zo goed een veiligheidsrisico zijn, misschien wel een veel grotere.

[supersnathan94]

Log4shell is een prima voorbeeld als het alternatief is “geen updates”. Want dat is wat er wordt voorgesteld.

en log4J is natuurlijk veel te groot om niet te backporten naar 8, omdat het zoveel gebruikt wordt. Dit is precies zo’n gevalletje “leftpad” waar je eigenlijk maar een beperkte set aan alternatieven hebt.

als je nog op JDK8 zit loop je met een hoop libraries gewoon support en features mis. Dat het nu toevallig log4shell is dat niet relevant is maakt niet uit voor de premisse.


Lifecycle management is gewoon noodzakelijk.

[orvintax]

upgraden is vaak heel complex en welke concrete winst is er na een upgrade?

Nieuwe features, QOL veranderingen, efficientie verbeteringen, performance verbeteringen. Java heeft het imago dat het "oud" en descriptief is. Met nieuwe versies proberen ze dat soort dingen te verbeteren. Dan is het enigzins frustrerend als developer dat je daar niet gebruik van kan maken omdat we op een versie van 10+ jaar oud draaien.

Niet te vergeten dat het niet alleen de taal zelf raakt, maar ook de gebruikte frameworks en libraries.

[wiseger]

De meeste grote bedrijven werken met outsourcing en dan is het krijgen van ontwikkelaars voor java8 geen enkel probleem.

Verder wordt java8 dus gewoon ondersteunt en bijgewerkt met de laatste security updates.

Voor bedrijven geldt ook dat er sterk naar de kosten gekeken wordt en dat de resources schaars zijn. Ga je nog investeren in een systeem dat je binnen afzienbare tijd wil gaan vervangen? Of hou je het bij security updates?

Dat zijn gewoon legitieme afwegingen.

[metalmania_666]

Ik ken helaas nog voldoende gemeenten die werken met Java 8. En die maken lang niet allemaal gebruik van Spring als framework.
Het bedrijf waar ik werkte probeerde al heel lang gemeenten over te laten stappen op iig versie 11 (was in 2020)

[FreezeXJ]

Nadeel is dat Java 11 al End of Life is, en Java 17 over 2 jaar ook gaat volgen. Wat je wilt is een solide upgrade zodat je alle ouwe troep verwijdert, en dan weer vooruit kunt. Het probleem zit hem in de 8-9-stap want die is verreweg het grootst.

Het probleem zit em ook niet per se in Spring, maar in het direct aanroepen van interne classes (die dus niet meer bestaan in Java 9 en hoger), wat sowieso al een no-no was. Echter gebeurt het teveel, want handig. Even com.sun.internal.x509 gebruiken in plaats van een onderhouden library, want het is er toch? Ennnn krak!

[ari3]

Het probleem zit wel in Spring. De Spring autowiring magie doet echt hele foute dingen met reflectie waardoor ook migratie naar het Java Platform Module System (JPMS) nagenoeg onmogelijk is. Hoewel Spring JPMS ondersteuning in versie 3.3 beloofd was is dit niet van de grond gekomen. Sinds 3.4 heeft Spring een soort van eigen alternatief voor JPMS genaamd Modulith waarmee ze zich buiten het standaard Java ecosysteem plaatsen. Hierdoor kun je nog steeds geen images maken met een reduceerde JVM runtime en kun je onveilige reflectie van Spring niet beteugelen. Tenzij je voor legacy aan Spring Boot vastzit, adviseer ik klanten daarom nu om geen nieuwbouw meer te doen in Spring Boot.

[Remzi1993]

Nadeel is dat Java 11 al End of Life is, en Java 17 over 2 jaar ook gaat volgen. Wat je wilt is een solide upgrade zodat je alle ouwe troep verwijdert, en dan weer vooruit kunt. Het probleem zit hem in de 8-9-stap want die is verreweg het grootst.

Wat je wilt is dat een organisatie de LTS volgt, elke paar jaar of 3? Dat er een nieuwe LTS uitkomt. Dat mag volgens mij wel voldoende zijn om steeds te upgraden. Software moet onderhouden worden en dat moet men een keer inzien.

[aikebah]

Java 11 is nog niet end-of-life. Had dat origineel wel zullen zijn, maar als transitionele versie van 8 naar 11 en hoger is de support-periode van 11 verlengd tot voorbij de end-of-support van 17/21 (bij oracle momenteel januari 2032 respectievelijk september 2029/september 2031)

Juist vanwege de trage migratie in het bedrijfsleven van java 8 naar 11 en hoger voor bestaande applicaties (alleen 11 heeft de backward compatibility switches beschikbaar die java nog in een 'bijna gelijk aan java 8' stand kunnen krijgen waarbij veel van wat 'niet meer mag' (misbruik van internals) grotendeels nog weer aangezet kan worden.

[var_undefined]

Het gebeurt nog wel eens dat bedrijven afhankelijk raken van software dat niet meer (goed) onderhouden wordt. Bijvoorbeeld om machines aan te sturen. De vraag voor dit soort oplossingen komt dan van de securityafdeling.

[JBVisual]

Precies dit.
Ik ken veel software die gemaakt is in Java om hele specifieke industriële machines aan te sturen.
Deze machines hebben een afschrijving van maar liefst 20 jaar, maar de software wordt niet onderhouden.
Deze machines zijn vaak stand alone, en als ze deze al in het netwerk hangen, dan is dat een restricted vlan.
Security is dus inderdaad iets om rekening mee te houden, maar zolang deze verder nergens anders voor gebruikt worden is met een juiste inrichting het risico beperkt.

[_JGC_]

Vnml veel legacy meuk die het nog gebruikt. En wat een genot om in 2030 nog steeds Java8 support op Ubuntu 20.04 te hebben.

Unifi controller ondersteunt bijvoorbeeld pas sinds vorig jaar Java en MongoDB versies die niet end of life zijn.

[i-chat]

java is best wel een tijdje een taal geweest waarin je makkelijk een best degelijke multi-arch multi-os app kon bouwen met bovendien redelijk eenvoudige migratie-paden naar dingen als tomcat ... als jij een bedrijfs-aplicatie ontwikkeld kun je dus grote delen van je code hergebruiken tussen desktop server en cluster deployments...

dat is ook de reden dat cononical het alleen voor ubuntu pro uitbrengt zo binden ze bedrijven aan zich die mogelijk in het verleden ooit een bedrijfs-critische app hebben aangeschaft en nu tot de conclusie komen dat ze aan java vast zitten

[SPee]

If it ain't broken, don't fix it.

Dat is wat ik vaak merk. Of dat ze een java server gebruiken (zoals Tomcat, JBoss of Oracle Weblogic) die ze niet (genoeg) begrijpen en geen nieuwe release van durven doen. Of de technische upgrades zijn niet belangrijk genoeg om uit te laten voeren en alleen de functionele wijzigingen "mogen".

Dit speelt zelfs bij partijen die modern pretenderen te zijn.

De stap van Java 8 naar nieuwer is (in hun ogen) toch een behoorlijke stap verder. Maar als je de ontwikkelaars hebt, dan kan (en moet) je die stap maken. Op een gegeven moment loop je anders zoveel achter, dat alleen een complete vervanging mogelijk is. In een vorig project waar ik zat heeft men een volledige rewrite vanaf 0 gedaan, om van de oude code af te komen. Men durfte niet meer aan de huidige productiecode te komen (ookal had men die zelf geschreven).

[PROnline]

There is an update because the previous version was apparently broken to begin with. The new version will fix what was broken in the previous version.

Ik heb ooit een hoge manager gevraagd te tekenen voor t risico van niet patchen. Alle gevolgen niet voor de beheer afdeling en problemen voortkomend uit niet patchen SLA best effort.

Heeft nog even geduurd, maar patchen ging daarna wel door.

[daanb14]

In het MKB zijn veel bedrijven afhankelijk van ERP en CRM software met op maat gemaakte oplossingen die best vaak nog Java 8 gebruiken. Die software vervangen ga je niet voor elkaar krijgen, want een directie gaat je echt geen toestemming geven om actief ondersteunde software om deze reden te vervangen. Dus ja, het is super lelijk en waardeloos, maar in genoeg omgevingen heb je het er helaas mee te doen.

[closefuture]

De stap van java 8 naar java 9 is gigantisch.

Dat valt opzich wel weer mee, tenzij mensen onhandige dingen gedaan hebben in hun applicatie zoals zaken uit de "com.sun" namespace te gebruiken. Waar de compiler trouwens ook over klaagt met warnings als je dat doet.

Dan ook nog eens de stap van 11 naar 17 met de Javax naar Jakarta.

De overstap van javax naar jakarta namespace hangt niet perse direct samen met de overstap Java 11, 17 of 21. Het enige wat gebeurt op JDK vlak is dat sommige implementaties (met name javax.ws, i.e de webservice / SOAP implementatie) uit de JDK gehaald zijn. Die zitten nu dus in een losse library. De meeste projecten zoals Jetty hebben overigens voor javax naar jakarta een redelijk duidelijk migratie pad.

[Blorgg]

Nou vraag ik me af wat voor applicaties dit zijn.

Een voorbeeld is oudere Minecraft versies.

Minecraft versie 1.16 en ouder draaien op Java 8. Er zijn ontzettend veel mod packs die draaien op oudere versie van Minecraft. Met name Minecraft 1.12.2 uit 2017 is nog steeds erg populair.

Voor nog oudere versies zoals Minecraft 1.6.4 moet je in Java wel SHA-1 weer aanzetten zodat mods hun integrity checks weer kunnen doen. Dit doe je in de launcher als startup parameter van de gewenste Minecraft instance. Deze nog oudere Minecraft versies draaiden toen ze uitkwamen op Java 7 maar werken met dit truukje dus ook op Java 8.

[Remzi1993]

Ik vraag me echt af wie hier nou belang bij heeft. Of zijn dit weer van die swing desktopapplicaties die in de lucht moeten blijven?

Als het goed is niemand want als je een Java app maakt dan gebruik je jlink om een custom Java runtime te genereren voor je Java app en maakt je een installer of gebruik je jpackage om een MSI of setup exe te genereren.

Het is nu al sinds jaren dat Oracle Java developers adviseert om een zelf genereerde custom JRE mee te leveren in je Java applicatie. Een eigen JRE is altijd kleiner dan een JDK of wat de gebruiker dan ook installeert. Je kan doordat je een eigen JRE meelevert en verpakt in je app meer configs doen dan als je de gebruiker een JRE laat installeren (wat Oracle ook niet meer aanbied)

[uiltje]

Die zijn er vast, vooral als het gaat om management-applicaties die bij een web gebaseerd product geleverd worden. Wel zo logisch als je met een bak Java ontwikkelaars te maken hebt en dezelde libs wil gebruiken.

[Refalm]

Je kunt in plaats van Ubuntu Pro ook voor een third-party JDK gaan.

Amazon Corretto ondersteund Java 8 tot 2030.

Azul Zulu ondersteund Java 8 tot 2032.

[SPee]

Vaak wordt er specifieke aanroepen gedaan naar interne functies, waardoor dit niet mogelijk is.

Een collega ondersteund bijvoorbeeld een applicatie die gebonden zit aan de 32-bit versie. Daar laad de java code een 32-bit dll in, wat in de 64-bit jvm dus faalt. Alleen treed er soms een OutOfMemory error op. Leuk als je dus al op de max zit. Gelukkig is er veel budget, dat volledig naar een nieuwbouw project gaat, met als deadline 2 jaar geleden, en dus bijna 0 budget voor het huidige productiesysteem.

[Nozmordre]

Ik vind het zo zonde dat op deze manier bedrijven alleen maar ondersteund worden in deze oude meuk nog langer aan te houden.
Als het aan mij lag zou geen enkele versie van wat voor software dan ook meer dan 2 jaar ondersteund worden voordat het op de meest hardhandige manier de nek werd gedraaid.
Ja, ik weet dat dit "extreem" is, maar dit is vooral om tegengewicht te bieden aan een industrie die altijd maar wanhopig lijkt om oude shit DECENNIA te blijven ondersteunen om maar niet aan LCM te hoeven doen.

[farlane]

Toch prachtig om te zien dat er een keuze is, dit is volgens mij FOS op zn best: Iedereen die nieuwer wil en kan mag dat doen, iedereen die dat niet wil of kan wordt ook bediend.

[joerij]

Slimme strategie. Voor missiekritische systemen, die (redelijk) afgeschermd functioneren, wil je wel een modern OS hebben, bijvoorbeeld vanwege de moderne hardware waarop het systeem draait (die hardware moet je echt vervangen na verloop van tijd). Door wel oudere Java-versies te ondersteunen biedt je een gunstige propositie voor het hosten van verouderde maar verder prima functionerende software op moderne hardware met een modern OS. Daarmee onderscheidt Canonical zich echt van sommige andere distributies, waarbij je geen oude JRE kunt installeren en vervolgens bij het vervangen van de hardware en het OS ook nog eens een major LCM slag op de applicaties moet doen. Merk op dat het combineren van een hardware + OS + Java + libraries in één release helemaal een drama is, maar daar wordt je soms toe gedwongen als bv je JRE versie niet meer te installeren is op een nieuwer OS, dat je echt nodig hebt omdat je nieuwe hardware in het oude OS niet ondersteund wordt.

Het 'ga maar gewoon' LCM implementeren brengt soms echt heel veel kosten met zich mee, die zeker niet altijd te rechtvaardigen zijn tav het gebruik / de risico's / de resterende levensverwachting van de applicatie. Natuurlijk moet je LCM toepassen, tenzij. Dit geeft in ieder geval meer keuze vrijheid.