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


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