Schon seit Java 1.0 gibt es den Quellcode der Standardbibliotheken (falls er beim JDK mitinstalliert wurde, befindet er sich im Wurzelverzeichnis unter dem Namen src.zip), und jeder Interessierte konnte einen Blick auf die Implementierung werfen. Zwar legte Sun damals also die Implementierungen offen, doch weder die Laufzeitumgebung noch der Compiler oder die Bibliotheken standen unter einer akzeptierten Open-Source-Lizenz. Zehn Jahre seit der ersten Freigabe von Java gab es Forderungen an Sun, die gesamte Java-Plattform unter eine bekanntere Lizenzform wie die GNU General Public License (GPL) oder die BSD-Lizenz zu stellen. Dabei deutete Jonathan Schwartz in San Francisco bei der JavaOne-Konferenz 2006 schon an: \u00bbIt\u2019s not a question of whether we\u2019ll open source Java, now the question is how.\u00ab War die Frage also statt des \u00bbOb\u00ab ein \u00bbWie\u00ab, k\u00fcndigte Rich Green bei der Er\u00f6ffnungsrede der JavaOne-Konferenz im Mai 2007 die endg\u00fcltige Freigabe von Java als OpenJDK (http:\/\/openjdk.java.net\/) unter der Open-Source-Lizenz GPL 2 an. Dem war Ende 2006 die Freigabe des Compilers und der virtuellen Maschine vorausgegangen.<\/p>\n\n\n\n
Obwohl OpenJDK unter der GPL stand, enthielt es doch Teile wie den Font-Renderer, Sound-Unterst\u00fctzung, Farbmanagement oder SNMP-Code, die als bin\u00e4re Pakete beigelegt wurden, weil etwa die Rechte zur Ver\u00f6ffentlichung fehlten. Sun nennt diese Teile, die etwa 4 % vom JDK 6 ausmachen, belasteten Code (engl. encumbered code). Das hinderte puristische Linux-Distributoren daran, OpenJDK auszuliefern. RedHat startete im Juni 2007 das Projekt IcedTea, um diese bin\u00e4ren Teile auf der Basis des OpenJDK durch GPL-Software zu ersetzen. So basiert der Font-Renderer zum Beispiel auf FreeType und das Farbmanagement auf little CMS. Mit diesen Ersetzungen erf\u00fcllte das OpenJDK mit IcedTea im Juni 2008 die Anforderungen des Technology Compatibility Kit (TCK) von Sun und ist in der \u00d6ffentlichkeit seither unter dem Namen OpenJDK 6 bekannt. Daraufhin floss das OpenJDK 6 plus der Ersetzungen unter der GPLv2 in Linux-Distributionen wie Fedora und Debian ein.<\/p>\n\n\n\n
Das OpenJDK bildet die Basis von Java 8, und jeder Entwickler kann sein eigenes Java zusammenstellen und beliebige Erweiterungen ver\u00f6ffentlichen. Damit ist der Schritt vollzogen, dass auch Java auf Linux-Distributionen Platz finden darf, die Java vorher aus Lizenzgr\u00fcnden nicht integrieren wollten.<\/p>\n\n\n\n
Auch wenn es sich so anh\u00f6rt, als ob das Oracle JDK bzw. OpenJDK das Gleiche sei, ist das nicht ganz richtig: Zwar basieren Oracle JDK und OpenJDK auf den gleichen Quellen (bei der Version 7 etwa zu 95 %), doch sind beim Oracle JDK immer noch propriet\u00e4re Dinge enthalten, und nicht alles ist hundertprozentig quelloffen und GPL. Das gilt f\u00fcr die Version 7 wie f\u00fcr die Version 6. Das Oracle JDK steht unter der Binary Code License; genau die muss jeder abnicken, der das JDK von der Webseite laden m\u00f6chte.<\/p>\n\n\n\n
Bei der 6er-Reihe kommt noch eine Besonderheit dazu, wie es die Versionsnummern ganz gut zeigen. W\u00e4hrend das Oracle JDK zum Beispiel im Juni 2011 bei Versionsnummer 1.6.0_26-b03 steht, ist das OpenJDK bei Version 6 b22. Die Versionsnummern sind deshalb v\u00f6llig unabh\u00e4ngig, weil beide Projekte auch unabh\u00e4ngig voneinander laufen. Das hat mit der Geschichte zu tun. Nach der Entwicklung des JDK 6, das nicht unter der GPL steht, ging es mit dem JDK 7 logisch weiter. Aus dem JDK 7 (Build 10) entstand dann OpenJDK, das heute mit der Versionsnummer OpenJDK 7 genannt wird. OpenJDK 7 und JDK 7 entwickeln sich Hand in Hand, und Code-\u00c4nderungen gehen mal in die eine Richtung und mal in die andere.<\/p>\n\n\n\n
Jetzt kommt die Besonderheit: Das OpenJDK 6 entstand nicht, wie vermutet werden k\u00f6nnte, aus dem Oracle JDK 1.6, sondern aus dem OpenJDK 7 (Build 20). Es wurden nur Java 7-Eigenschaften entfernt: Die meisten Patches am OpenJDK 6 sind Backports von OpenJDK 7. \u00c4nderungen am OpenJDK 7 stammen \u00fcberwiegend von Oracle, und h\u00e4ufig ist es die Firma Red Hat, die diese \u00c4nderungen in OpenJDK 6 portiert. Zwischen dem OpenJDK 6 und dem JDK 1.6 gibt es einen Quellcodeaustausch bei Bug-Fixes, doch die Codebasis ist unterschiedlich. Oracle JDK 6 ist im Wartungsmodus, und gro\u00dfartige Ver\u00e4nderungen passieren bis auf Fehlerbereinigungen nicht.<\/p>\n\n\n\n
Oracle JDK 8 ist die Version, die die Download-Seite von Oracle anbietet; das OpenJDK 8 liegt auf einem eigenen Server http:\/\/openjdk.java.net\/projects\/jdk8\/. Das OpenJDK bildet die Referenzimplementierung f\u00fcr Java SE, nicht das Oracle JDK.<\/p>\n\n\n\n
Das freie und unter der GPL stehende OpenJDK (http:\/\/openjdk.java.net\/) bildet nunmehr die Referenzimplementierung f\u00fcr Java SE. Alle Entwicklungen finden dort statt. Der Fortschritt ist live zu beobachten, regelm\u00e4\u00dfig fixen und erweitern Hunderte von Entwicklern die Codebasis. Die Quellen f\u00fcr das OpenJDK lassen sich im Mercurial-Repository unter http:\/\/hg.openjdk.java.net\/jdk\/jdk14 einsehen (ein Wechsel auf GitHub wird diskutiert). Viele Technologien, die Oracle vorher nur im Oracle JDK hatte, wurden in das OpenJDK \u00fcbertragen, etwa Java Flight Recorder, Java Mission Control, Application Class-Data Sharing und ZGC (Zero-Garbage-Collector).<\/p>\n\n\n\n
Oracle selbst compiliert das OpenJDK und bietet es an. Aktuelle Versionen sind \u00fcber http:\/\/jdk.java.net\/ verlinkt. Es gibt von Oracle OpenJDK-x64-Builds f\u00fcr Windows, Linux und macOS.<\/p>\n\n\n\n
Das Oracle OpenJDK steht unter der GNU General Public License v2 mit der Classpath Exception (GPLv2+CPE). Oracle selbst hat angek\u00fcndigt, bei neuen Versionen keine Updates mehr f\u00fcr die alten Versionen zu ver\u00f6ffentlichen.<\/p>\n\n\n\n
AdoptOpenJDK (https:\/\/adoptopenjdk.net\/) ist eine Stiftung und betreibt eine Serverfarm, die regelm\u00e4\u00dfig Builds vom OpenJDK baut und dazu weitere Software wie die JavaFX-Implementierung OpenJFX und alternative Laufzeitumgebungen wie Eclipse OpenJ9 einbindet. Es wird angek\u00fcndigt, auch \u00e4ltere Versionen mit Bugfixes zu versorgen. Zu den Unterst\u00fctzern z\u00e4hlen Amazon, IBM\/Red Hat, Microsoft, Pivotal und viele weitere.<\/p>\n\n\n\n
Von der Webseite l\u00e4sst sich f\u00fcr unterschiedliche Betriebssysteme eine Version herunterladen. Angeboten werden Builds u.a. f\u00fcr: Windows, Linux, macOS.<\/p>\n\n\n\n
AdoptOpenJDK z\u00e4hlt aktuell zu den popul\u00e4rsten OpenJDK-Distributionen.<\/p>\n\n\n\n
Das Unternehmen Azul bietet Builds unter dem Namen Zulu an, auch l\u00e4sst sich ein Support-Vertrag abschlie\u00dfen: http:\/\/www.azul.com\/downloads\/zulu\/. Neben den Plattformen Windows, Linux und macOS gibt es von Azul ebenfalls Docker-Images.<\/p>\n\n\n\n
Red Hat bietet neben Linux auch eine Windows-Version vom OpenJDK an: http:\/\/developers.redhat.com\/products\/openjdk\/overview\/. Die Integration in Linux ist sehr gut, und Red Hat pflegt auch noch Sicherheitsupdates in Java 6 und Java 7 ein.<\/p>\n\n\n\n
SAP bietet mit der SapMachine (http:\/\/sap.github.io\/SapMachine\/) Builds f\u00fcr diverse Betriebssysteme und auch ein Docker-Image.<\/p>\n\n\n\n
Amazon Corretto (http:\/\/aws.amazon.com\/de\/corretto\/) wird intern von Amazon in der Cloud eingesetzt und ist f\u00fcr die LTS-Versionen Java 8 und Java 11 kostenlos.<\/p>\n\n\n\n
Alibaba Dragonwell (http:\/\/github.com\/alibaba\/dragonwell8) ist eine vom OpenJDK 8 abgeleitete Implementierung von Alibaba.<\/p>\n\n\n\n
Von BellSoft gibt es das Liberica JDK (http:\/\/bell-sw.com\/) f\u00fcr die Plattformen Windows x86_64 und auch noch Windows x86, macOS x86_64, Linux x86_64, Linux ARMv8, Linux ARMv7 HardFloat, Solaris SPARC und Solaris x86_64.<\/p>\n\n\n\n
Apple pflegte lange Zeit eine komplett eigene JVM, bis Apple den Code an Oracle f\u00fcr das OpenJDK \u00fcbergab. Auch Google setzt bei Android neuerdings auf das OpenJDK.<\/p>\n\n\n\n
Oracle vermarktet auf der Basis des OpenJDK sein eigenes Projekt, Oracle JDK. Ab Java 11 sind das Oracle JDK und OpenJDK vom Code her (nahezu) identisch. Das Oracle JDK ist die \u00bboffizielle\u00ab Version, die die Java-Download-Seite von Oracle anbietet. Wenige kleine Unterschiede sind die Paketierung (das Oracle JDK hat einen Installer, das Oracle OpenJDK ist nur ein ZIP), die Versionskennung und ein paar weitere Module.[1]<\/p>\n\n\n\n
Die halbj\u00e4hrlichen Java-Releases haben zur Folge, dass Versionen immer dann veraltet sind, wenn eine neue Version erscheint. In dem Moment, in dem Java 10 kam, war Java 9 veraltet; das Gleiche gilt bei Java 14 \u2013 es machte sofort Java 13 zur alten Version. Das allein w\u00e4re kein Problem, wenn die \u00e4lteren Versionen mit Sicherheitsupdates versorgt w\u00fcrden. Aber Oracle investiert f\u00fcr die Allgemeinheit keine Zeit und M\u00fche mehr und pflegt die alten Versionen nicht.<\/p>\n\n\n\n
F\u00fcr Unternehmen ist das ein Problem, denn es erzeugt Stress, mit den \u00c4nderungen mitziehen zu m\u00fcssen. Aus diesem Grund bietet Oracle alle drei Jahre eine Java-Version mit Long Term Support (LTS) und versorgt sie mit Updates und Sicherheitspatches. Die LTS-Versionen nach Java 8 sind Java 11 (September 2018) und dann nach 3 Jahren Java 17 (September 2021). Das ist f\u00fcr weniger agile Unternehmen gut. Oracle will seine Java SE 8-Implementierung noch viele Jahre pflegen.<\/p>\n\n\n\n
Auf den ersten Blick sieht das gut aus: Es gibt regelm\u00e4\u00dfige Updates f\u00fcr agile Unternehmen, und die konservativen Unternehmen setzen auf eine LTS-Version. Das Problem ist allerdings, dass alle Oracle JDK-Versionen nicht kommerziell eingesetzt werden d\u00fcrfen; der Hersteller erlaubt die Nutzung nur f\u00fcr \u00bbdevelopment, testing, prototyping or demonstrating purposes\u00ab.<\/p>\n\n\n\n
F\u00fcr Java 8 endete die Schonfrist im Januar 2019. Das d\u00fcrfte vielen Entwicklern gar nicht bewusst sein, denn seit 20 Jahren sind Unternehmen daran gew\u00f6hnt, das Oracle JDK f\u00fcr alles einzusetzen. Und wir wissen alle, wie viele Menschen wirklich die Lizenzbedingungen lesen \u2026<\/p>\n\n\n\n
Wer also das Oracle JDK kommerziell einsetzen m\u00f6chte und nicht nur in einer Entwicklungs- oder Testumgebung, muss eine Lizenz von Oracle erwerben. Es wird monatlich abgerechnet, die Vertragslaufzeit betr\u00e4gt mindestens ein Jahr. Es stehen zwei Modelle zur Auswahl:<\/p>\n\n\n\n Oracle wendet bei der Java SE Subscription das gleiche Gesch\u00e4ftsmodell wie bei der Oracle-Datenbank an. Wie genau ein Rechner in der Cloud mit einer unbestimmten Anzahl der Prozessoren abgerechnet werden soll, ist noch unklar.[2] Interessenten sollten die \u00bbOracle Java SE Subscription FAQ\u00ab unter http:\/\/www.oracle.com\/technetwork\/java\/javaseproducts\/overview\/javasesubscriptionfaq-4891443.html studieren und Oracle-Berater hinzuziehen. Wer Client- und Serveranwendungen nutzt, muss zweimal bezahlen. Statt \u00bbwrite once, run anywhere\u00ab hei\u00dft es nun \u00bbwrite once, pay everywhere\u00ab.<\/p>\n\n\n\n Die Kosten k\u00f6nnen sich schnell summieren, doch bekommen Unternehmen damit Support und insbesondere f\u00fcr Java 8 immer noch f\u00fcr einige Jahre Unterst\u00fctzung. Der Nachteil ist, dass es das Subscription-Modell nur f\u00fcr die LTS-Versionen gibt, Unternehmen also gezwungen werden, gr\u00f6\u00dfere Versionsspr\u00fcnge zu machen. Nach Java 11 kommt erst im September 2021 die Version Java 17 mit dem n\u00e4chsten LTS.<\/p>\n","protected":false},"excerpt":{"rendered":" Schon seit Java 1.0 gibt es den Quellcode der Standardbibliotheken (falls er beim JDK mitinstalliert wurde, befindet er sich im Wurzelverzeichnis unter dem Namen src.zip), und jeder Interessierte konnte einen Blick auf die Implementierung werfen. Zwar legte Sun damals also die Implementierungen offen, doch weder die Laufzeitumgebung noch der Compiler oder die Bibliotheken standen unter […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","_links_to":"","_links_to_target":""},"categories":[1],"tags":[],"class_list":["post-4514","post","type-post","status-publish","format-standard","hentry","category-allgemein"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/4514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/comments?post=4514"}],"version-history":[{"count":1,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/4514\/revisions"}],"predecessor-version":[{"id":4515,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/4514\/revisions\/4515"}],"wp:attachment":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/media?parent=4514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/categories?post=4514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/tags?post=4514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Java SE Subscription<\/strong><\/td> Java SE Desktop Subscription<\/strong><\/td><\/tr> F\u00fcr Serveranwendungen<\/td> F\u00fcr Client-Anwendungen<\/td><\/tr> Abrechnung pro Prozessor<\/td> Abrechnung pro Benutzer<\/td><\/tr> Bis 25 USD\/Monat, f\u00fcr 1\u201399 Benutzer<\/td> Bis 2,50 USD\/Monat f\u00fcr 1\u2013999 Benutzer\/Clients<\/td><\/tr><\/tbody><\/table>