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
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.
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.
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.
[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.
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