Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Software-update: Oracle Java 15

JavaOracle heeft versie 15 van Java Standard Edition uitgebracht. Oracle brengt sinds versie 11 alleen nog de Java SE Development Kit (JDK) uit, in zowel de Oracle JDK- als de OpenJDK-smaak, waarbij de laatste onder de gpl-licentie wordt aangeboden. Er worden geen Java Runtime Environment (JRE) en Server Java Runtime Environment (Server JRE) meer uitgebracht. Wel is het mogelijk om met jlink een kleinere runtime samen te stellen. De releasenotes van deze versie ziet er als volgt uit:

Introduction

These notes describe important changes, enhancements, removed APIs and features, deprecated APIs and features, and other information about JDK 15 and Java SE 15. In some cases, the descriptions provide links to additional detailed information about an issue or a change. This page does not duplicate the descriptions provided by the Java SE 15 ( JSR 390) Platform Specification, which provides informative background for all specification changes and might also include the identification of removed or deprecated APIs and features not described here. The Java SE 15 ( JSR 390) specification provides links to:

You should be aware of the content in that document as well as the items described in this page.

The descriptions on this Release Note page also identify potential compatibility issues that you might encounter when migrating to JDK 15. The Kinds of Compatibility page on the OpenJDK wiki identifies three types of potential compatibility issues for Java programs used in these descriptions:

  • Source: Source compatibility preserves the ability to compile existing source code without error.
  • Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link existing class files without error.
  • Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.

See CSRs Approved for JDK 15 for the list of CSRs closed in JDK 15 and the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for general information about compatibility.

IANA Data 2020a

JDK 15 contains IANA time zone data version 2020a. For more information, refer to Timezone Data Versions in the JRE Software.

Versienummer 15
Releasestatus Final
Besturingssystemen Windows 7, Java, Linux, BSD, macOS, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019
Website Oracle
Download https://www.oracle.com/java/technologies/javase-jdk15-downloads.html
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

15-09-2020 • 20:54

37 Linkedin

Submitter: xfj

Bron: Oracle

Reacties (37)

Wijzig sortering
Voor een beter overzicht van wat er nieuw is in Java 15: https://www.techgeeknext.com/java/java15-features

En verder, tja, allemaal leuk, maar in enterprise omgevingen zal het vaak gebeuren dat er pas bij een nieuwe LTS-release weer geupgradet gaat worden. Als dat al gebeurt. ;)
dat er pas bij een nieuwe LTS-release weer geupgradet gaat worden.
Heeft toch alleen zin als je daadwerkelijk een support contract heeft bij de vendor die een willekeurige java versie als LTS support?
Niet echt, als je software hebt draaien in productie blijf je graag bij met security patches, nieuwe root certificate store, timezonedata, etc. LTS releases krijgen dat zonder dat je language changes mee krijgt en tijd en geld in onderhoud/omschrijven van de applicatie moet steken. Dat kan ook prima zonder support contract zijn, zoals adoptopenjdk bijvoorbeeld doet.

En er lijkt gelukkig redelijk een lijn gekozen te zijn met wat betreft LTS versies ongeacht welke vendor je kiest, 1.8, 11, en hopelijk ook weer gezamelijk 17 in de toekomst. Ook niet meer dan logisch gezien ze eigenlijk allemaal wel voortbouwen op dezelfde source.
en hopelijk ook weer gezamelijk 17 in de toekomst
Als we allemaal zo hopen dat er een gezamenlijke LTS versie komt voor 17, zou het dan niet beter zijn als LTS "echt" bestond in Java zelf?

En een stapje verder, als we eigenlijk alleen maar LTS versies willen draaien (die eigenlijk voornamelijk zouden moeten draaien op support contracten, maar dat terzijde), waarom hebben we dan eigenlijk nog non-LTS versies?

Hoeveel non-enterprise omgevingen (om in termen van @Upquark te spreken, draaien eigenlijk überhaupt Java?
Als we allemaal zo hopen dat er een gezamenlijke LTS versie komt voor 17, zou het dan niet beter zijn als LTS "echt" bestond in Java zelf?
Die bestaat ook wel "echt" alleen is de planning dat 17 in september 2021 uit komt, vandaar mijn hopelijk want het duurt gewoon nog een jaar. Uiteindelijk is bijna alles toch weer gebaseerd op de openjdk tegenwoordig, dus als die mensen beslissen dat 17 security patches krijgt dan zal de rest van de providers die die library pakken en support contracten er op bieden daar ook op mee gaan.
En een stapje verder, als we eigenlijk alleen maar LTS versies willen draaien (die eigenlijk voornamelijk zouden moeten draaien op support contracten, maar dat terzijde), waarom hebben we dan eigenlijk nog non-LTS versies?
De hobbyisten, cutting edge cowboys en mensen die nieuwe language features willen die upgraden natuurlijk zo snel mogelijk. Als je dat maar elke half jaar release netjes doet is daar ook niets aan de hand. Als wij intern niet al grotendeels over waren op Kotlin voor nieuwe projecten zouden een aantal dingen in java 14 ook heel aantrekkelijk zijn voor mij als programmeur zijnde. Nieuwe features moeten ergens getest en gereleased worden. 3-4 jaar wachten op nieuwe features is gewoon niet meer van deze tijd, om nog maar te spreken van de slakkensnelheid waarop sommige dingen uitgebracht werden in het verleden.
Hoeveel non-enterprise omgevingen (om in termen van @Upquark te spreken, draaien eigenlijk überhaupt Java?
Dat is een hele goeie vraag. Ik denk persoonlijk als je klein en hip genoeg bent om elk half jaar netjes je Java bij te houden java inderdaad al snel af valt als keuze. Het is inderdaad in veel enterprise omgevingen redelijk de preferred stack omdat het zo gegroeid is en ongetwijfeld ook voor de zeer redelijke support voor SOAP interfaces. Maar als je mag/kan kiezen, waarom niet iets hippers inderdaad.
Kotlin is een mooie middenweg als je binnen de JVM wilt blijven, deze kan java dependencies hergebruiken. Echter alle "nieuwe" language features die in java 15 zitten heeft Kotlin al lang en breed en in mijn mening zelfs ook nog wel beter.
Maar de JVM is zeker nog wel een van de lompere manieren om dingen te draaien. Genoeg alternatieven die veel lichtgewicht en sneller zijn en minstens net zo volwassen.
Die bestaat ook wel "echt" alleen is de planning dat 17 in september 2021 uit komt
Nee, het bestaat niet echt, in de zin dat het niet aan een Java versie zelf is gekoppeld. Niets in de Java specs (JLS or otherwise), of een JEP zegt dat een bepaalde Java release zelf LTS is.

Het is een afzonderlijke vendor die besluit om een bepaalde versie LTS te maken.
De hobbyisten, cutting edge cowboys en mensen die nieuwe language features willen die upgraden natuurlijk zo snel mogelijk.
Deze mensen hadden in het verleden toch ook al de beta en milestone releases kunnen gebruiken?

Het hele idee van de snellere cadence is juist dat je een volledig stabiele versie hebt elke 6 maanden die 100% geschikt is voor gebruik in productie. Het is jammer dat er een soort cargo cult ontstaan van mensen die denken dat het toch eigenlijk milestones zijn.

Alle JDK vendors kunnen zich dus net zo goed de moeite van het stabiliseren van elke Java release besparen. Voor de hobbyisten en cowboys is dat toch niet nodig?

> Genoeg alternatieven die veel lichtgewicht en sneller zijn en minstens net zo volwassen.

Er zijn niet heel veel VMs die sneller zijn hoor. Ook qua talen (met of zonder JVM) kom je eigenlijk zelden boven de snelheid van Java uit. Met hand optimised C of C++ zit je in de regel een factor of 2 sneller, maar b.v. Python code zelf kan al snel weer 50x langzamer zijn dan Java (en dus 100x langzamer dan C of C++).
Goeie vraag. Ik denk het niet. Aangezien LTS dus langer gesupport moet worden heb je minder kans dat er mogelijke grote breaking features in terecht komen. Ook kun je wat langer wachten tot je overstapt op een nieuwe LTS omdat daar (veel) meer bugs uit gehaald zullen worden door die grote enterprises en door die langere support lifecycle (of hun support contracten).
mogelijke grote breaking features in terecht komen
Vanaf Java 11, welke features zijn dan breaking geweest? En specifiek, van al die veronderstelde breaking features, welke waren groot?

Concreet, welke feature heeft iedereen tegengehouden om van 11 naar 12 te gaan?
Misschien was het niet zo bedoeld, maar je *hoeft* niet fel te reageren op een non-flame post.

Ik bedoel alleen te zeggen dat het common practice is om in een LTS release minder nieuwe features te proppen (de developers moeten dat immers langer onderhouden, zonder al te grote backports, bijv).

Ook al is dat niet het geval is zal een LTS op den duur stabieler zijn dan een non-LTS release. Enterprises blijven over het algemeen echt alleen op LTS hangen en vooral enterprises zullen support contracten hebben.

("Once a new feature release is made available, any previous non‑LTS release will be considered superseded. For example, Java SE 9 was a non‑LTS release and immediately superseded by Java SE 10 (also non‑LTS), Java SE 10 in turn is immediately superseded by Java SE 11." - uit de Oracle roadmap; dat is voor een gemiddelde enterprise een no-go en zijn daar dus minder gebruikers, testers en dus bug-reports voor)

Edit: flame stukje over Oracle weg gehaald, off topic :)

[Reactie gewijzigd door Loen op 16 september 2020 10:46]

Was niet als flame bedoeld hoor ;)

Maar er is wel duidelijk een soort van cult aan het ontstaan omtrent de term LTS, en een soort van fear of non-best practice voor het gebruik van een Java versie van een bepaalde vendor die niet dat mythische LTS labeltje heeft.

Ik kom dit in mijn dagelijkse werk overal tegen. Begin je een project en gebruik je gewoon de laatste Java versie, staat men met angst in je ogen je aan te kijken: "maar... maar... dat is geen LTS! Alleen Java 11 en 17 is LTS!"

Er gaan daar 2 dingen fout.

Ten eerste begrijpt (bijna) niemand dat LTS niet inherent is aan een Java versie, maar dat elke vendor haar distributie wel of niet als LTS kan bestempelen.

Ten tweede weet men ook vaak niet eens waarom men nou perse een LTS moet hebben. Het doel van de snellere release cadence was juist om de upgrade angst weg te nemen. Net zoals dat men ook niet meer gaat migreren van Chrome 84 naar Chrome 85, maar na een vluchtige test gewoon de nieuwste versie installeert voor het hele kantoor.

Er lijkt een soort angst cultuur te ontstaan nu dat alle niet LTS Java versies een soort alpha versies zijn, die je nooit en te nimmer in productie mag gebruiken. Dat is jammer. Als je Java 11 draait, kun je meestal gewoon naar Java 12 updaten voor de security fixes. Natuurlijk, testen is key, maar dat zou je ook voor een update die alleen uit security fixes bestaat moeten doen.
Geen probleem hoor, anders had ik het wel kunnen hebben ;)

Als de snellere release cadence dat voor ogen had is dat vrees ik inderdaad enigszins gefaald, in elk geval bij de omgevingen die ik tegen kom. Het label "LTS" lijkt inderdaad dat effect te hebben.
De meesten kennen LTS vooral van Ubuntu, daar blijft een groot deel zelfs nu nog bij 18.04 en gaan pas naar 20.04 als er een half jaartje overheen is. Ook Microsoft doet dat bijvoorbeeld voor hun hosted "azure devops agents"; de meest gebruikte "ubuntu-default" build agent gaat binnenkort ergens van 18.04 naar 20.04. Ubuntu heeft overigens ook wel eens nieuwe features geschrapt voor een LTS build, omdat het LTS was...

Op RHEL (waar ik zelf het meeste mee werk) levert Red Hat van de OpenJDK ook alleen de LTS versies. Daarnaast zijn de oracle rpm's ook geen upgrades van elkaar, wat *lijkt* te impliceren dat je niet zomaar kunt upgraden. (das enigszins best practice met RPM's; bij breaking changes neem je een major version mee in de package "name")

Ik snap de angst cultuur dus wel, ook al is dat wellicht echt niet nodig :)
Volgens mij zijn de niet-LTS releases vooral gericht op Agile omgevingen waar vaak gereleased wordt, dus ook ontwikkelcapaciteit beschikbaar is als er iets breekt, en waar ze (kunnen) vertrouwen op hoge unittest coverage. Dan zijn de potentiele breaking changes lang niet zo spannend meer en is de versnelde toegang tot nieuwe features soms wel interessant.

In mijn omgeving, waar met veel moeite een tester moet worden gevonden, die dan handmatig door de hele applicatie heen klikt, en waar men liever een upgrade tegenhoudt dan er een dev op te zetten als er iets niet werkt, gebruiken we toch liever een LTS.
OpenJDK LTS heeft niks met support contracten te maken. Elke 3 jaar wordt een release branch als LTS bestempeld en wordt deze door de OpenJDK developers ondersteund. Verschillende OpenJDK distributies zullen deze versies dan ook distribueren.

OpenJDK developers is niet alleen Oracle, maar ook RedHat/IBM, Azul, SAP, Amazon. Welke ook allemaal OpenJDK releases uitbrengen. De meeste staan ook achter Eclipse Adoptium (voormalig AdoptOpenJDK).

TLDR, LTS releases voor OpenJDK zijn voor iedereen, en gratis. Bij Oracle kan je alleen commerciele versies krijgen. (Net zoals bij sommige andere vendors).
Elke 3 jaar wordt een release branch als LTS bestempeld en wordt deze door de OpenJDK developers ondersteund.
Door wie wordt deze dan als LTS bestempeld?

Overigens, hoe past de MTS dan in het verhaal?
De OpenJDK developers, voor de OpenJDK implementatie. De meeste andere implementors van Java zullen waarschijnlijk dezelfde LTS releases aanhouden (zowel voor de OpenJDK forks als de alternatieve implementaties). Duur van LTS kan natuurlijk wel verschillen, en eventueel afhankelijk zijn van commerciële afspraken.
Veel OpenJDK bases releases zullen niet of weinig aan MTS doen, maar dat is afhankelijk van het bedrijf er achter. Adoptium doet niet aan MTS maar wel aan LTS.
Azul heeft voor Zulu (een OpenJDK fork) wel MTS die om elke release gaat, zie: https://www.azul.com/products/azul-support-roadmap/
Dus als je voor langer dan 6 maanden een non-LTS release wilt gebruiken kan je misschien beter Azul Zulu gebruiken, dan krijg je gratis 1.5 jaar ondersteuning op de elke andere non-LTS Java versie.
Precies, en dat was dus ook in de andere comments een beetje mijn punt.

De LTS en MTS labels zijn niet inherent aan een Java versie zelf, maar afhankelijk van de vendor.
Zodra de stap van Java 8 naar Java 11 gezet is gaat het upgraden van majors een stuk makkelijker.
Voor wie liever geen Oracle distributie gebruikt, https://adoptopenjdk.net/ komt waarschijnlijk binnen een paar dagen met versie 15.

Ik heb meteen mijn overzicht geüpdatet over wat er nieuw, deprecated en verwijderd is in de API (dus geen nieuwe language features).
Bedankt voor de link voor OpenJDK, dat scheelt weer googlen op moment dat ik weer eens op zoek ben naar een niet-Oracle versie.

HotSpot is ook van Oracle toch? Vind ik niet echt duidelijk worden op die pagina.
Nee, HotSpot is gewoon OpenJDK. Het is de standaard JVM van OpenJDK. OpenJ9 is een alternatieve JVM. Er staat ook een linkje naast "help me choose".

De Oracle versies download je van de Oracle website. Elke andere website waar je Java kan downloaden is dus per definitie niet de Oracle versie. java.net is btw ook een Oracle website.

[Reactie gewijzigd door elmuerte op 16 september 2020 07:51]

Je overzicht is vast heel handig, maar het leest voor geen meter. Waarom al die uitklap dingen? Waarom niet gewoon een makkelijke lijst. Het is ook lastig te zien wat een externe link is, en wat weer een uitklapper.
ZGC is nu production ready, klaar voor JDK17. Ze zijn nog steeds bezig GC pauses te verminderen naar sub-milliseconden zover ik weet, maar het blijft interessant. Trouwens kon ik laatst nog steeds niet ZGC gebruiken in combinatie met UseJVMCICompiler.

Project Loom klinkt interessant, maar onderhand is het ongeveer een jaar sinds ik met Java heb gewerkt in mijn eigen tijd en is eigenlijk alles wat ik voor mijzelf doe in go.
Vraagje van iemand die geen developer is. Moet je echt de hele JDK installeren als je simpel een applicatie die in Java geschreven is, wil uitvoeren? Is er geen JRE meer?
De JRE is er al een hele tijd uit. Tegenwoordig heb je slechts de JDK nog. Voor de opslagruimte hoef je het tegenwoordig niet meer te doen, dus ik lig er persoonlijk niet wakker van.
Ok duidelijk. Het was ook een hele tijd geleden dat ik een java applicatie wilde draaien op de desktop. :)
Op adoptopenjdk.net wordt nog wel een jre aangeboden.
Waarom is dat eigenlijk? Ik gebruik Java eigenlijk alleen af en toe op servers maar onlangs had ik het op een desktop nodig en toen viel me op dat je van Oracle alleen de hele SDK kon downloaden.

Ik heb het uiteindelijk opgelost door de JRE van AdoptOpenJDK te installeren maar vond het wel vreemd.
De verschuivingen in de java omgevingen hebben naar mijn idee vooral een oorsprong in de licentie wijzigingen die Oracle er de laatste jaren op heeft uitgevoerd. Ga er voor het gemak van uit dat prive en consumenten gebruik van java voorlopig nog gratis is.

Zakelijk gebruik en software ontwikkeling met de door Oracle gedistribueerde java omgevingen is aan steeds striktere licentie voorwaarden gebonden en zou ook zomaar veel geld kunnen gaan kosten.

[Zeur mode aan]
Volgens mij heeft Oracle een bedrijfsmodel gevonden in het oppakken van vrij bruikbare software en pakketten en zo om daar dan de licentie vorm van aan te passen om er direct en veel geld aan te verdienen. Zie hierbij bijvoorbeeld MySQL, OpenOffice en Java.
De ontwikkelaar het kan met JLink een kleinere runtime samenstellen en dit bundelen met de applicatie. Er is dan geen aparte JDK installatie nodig.
Ik dacht dat iedereen (Oracle/Sun) Java probeert te vermoorden (niet meer te gebruiken)???
Zelf ben ik meer een quick en dirty python guy, maar het laatste java project was leuk om te doen en behoorlijk performant tov de python mockup die ik eerst aan het bouwen was
Wat mist, en dat geldt niet alleen voor java, is een tutorial hoe je alle toeters en bellen rondom een programmeertaal gebruikt om efficient te werken. De meeste tutorials draaien alleen om code maar vergeten de environment
[Zeur mode aan]
Volgens mij heeft Oracle een bedrijfsmodel gevonden in het oppakken van vrij bruikbare software en pakketten en zo om daar dan de licentie vorm van aan te passen om er direct en veel geld aan te verdienen. Zie hierbij bijvoorbeeld MySQL, OpenOffice en Java.
Mooie release weer. Eigenlijk hoop ik iedere keer dat ze eens iets doen aan die 64K limiet op de static class initializers. Voor gegenereerde code is dat een behoorlijke beperking. Ik weet dat daar workarounds voor te bedenken zijn, maar die hebben allemaal als nadeel dat code completion dan niet meer mogelijk is wegens het ontbreken van static final constants of enums.

Best bizar dat men die 64K limiet er in houdt. Dat je handmatig beter geen 64K aan static final vars of enums maakt begrijp ik, maar voor gegenereerde code vind ik het wel een legitieme use-case.
Wellicht wat onbekend voor t grote publiek, maar ook SAP heeft inmiddels een openJDK 'SAPMachine' https://sap.github.io/SapMachine
http://openjdk.java.net/jeps/381
En alle Solaris en SPARC support is nu definitief verwijderd. Ook voor Solaris/x86 helaas.
Let op met commercieel gebruikt van Oracle's java releases. Beter is het dan om openjdk te gebruiken, om een bezoek van Oracle's legal en licentie afdeling te vermijden.
Bestaat Java nog? Beetje obsolete dacht ik.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True