Autor: Christian Ullenboom

Get the latest version of a maven groupId:artifactId via Node.js script

~ Christian Ullenboom ~ Hinterlasse einen Kommentar 
// npm install node-fetch
import fetch from 'node-fetch';
const groupId = "org.apache.maven.plugins";
const artifactId = "maven-compiler-plugin";
const url = `http://search.maven.org/solrsearch/select?q=g:"${groupId}"+AND+a:"${artifactId}"`;
const response = await fetch(url);
const body = await response.json();
const version = body.response.docs[0].latestVersion;
console.log(version);

 

Code Snippets in Java API Doku geplant (JEP 413)

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Interessantes Feature, was die Javadoc doch dicker machen könnte. Geplant:

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet :
 * if (v.isPresent()) {
 *     System.out.println("v: " + v.get());
 * }
 * }
 */

Interessant wird das ganze durch Includes (wie bei Asciidoc):
/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet file="ShowOptional.java" region="example"}
 */
Dinge können zum Beispiel fett hervorgehoben werden:
/**
 * A simple program.
 * {@snippet :
 * class HelloWorld {
 *     public static void main(String... args) {
 *         System.out.println("Hello World!");      // @highlight substring="println"
 *     }
 * }
 * }
 */
Und Texte können ersetzt werden:
/**
 * A simple program.
 * {@snippet :
 * class HelloWorld {
 *     public static void main(String... args) {
 *         System.out.println("Hello World!");  // @replace regex='".*"' replacement="..."
 *     }
 * }
 * }
 */

Ziemlich wild, würdet ihr so was nutzen für eure Javadoc? Ich nutzte bisher immer Testfälle, um eine API zu zeigen und auch zu lernen.

Zum Weiterlesen: https://openjdk.java.net/jeps/413

Spring Boot 3 in 2022 + Neues Spring Buch entsteht

~ Christian Ullenboom ~ 2 Kommentare

Ankündigung unter https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6:

As announced at SpringOne yesterday, Spring Framework 6 and Spring Boot 3 are planned towards a high-end baseline for their general availability in Q4 2022:

  • Java 17+ (from Java 8-17 in the Spring Framework 5.3.x line)
  • Jakarta EE 9+ (from Java EE 7-8 in the Spring Framework 5.3.x line)

This forward-looking baseline will provide significant benefits in our API design and integration efforts, shining through to your application code and future-proofing the framework as well as your applications for many years to come. However, it comes at a cost, of course: Spring Framework 6 and Spring Boot 3 based applications will require a minimum of JDK 17 at runtime, as well as a minimum of Tomcat 10 / Jetty 11 (for Jakarta EE 9 compatibility). Even more importantly, there might be some changes required in your application source code: e.g. the javax to jakarta namespace change in Jakarta EE 9 wherever you’re touching the Servlet API, JPA, Bean Validation, etc.

While this may sound aggressive at first, keep in mind that we’re talking about a Q4 2022 release: By that time, not only will JDK 17 have superseded JDK 11 as the next Long-Term Support release for more than a year, it will itself have been superseded by JDK 18 and JDK 19 as then-available feature releases, with JDK 20 approaching its feature freeze already. Same for Jakarta EE 9: We expect Jakarta EE 10 to be out by then, and yet another generation of Tomcat, Jetty and co to be supported as runtime options. Keeping up the baseline above as a minimum, this allows for picking up further Java evolution in the Spring Framework 6.x generation, with Java 17 and Jakarta EE 9 only being the start.

Nächstes Jahr beginne ich mit einem neuen Buch; Thema: Spring Boot 3 und Spring Framework 6. Mit Rheinwerk haben wir uns überlegt, dass wir uns ein Spring Boot 2.x Buch sparen, daher wird es erst in rund 14 Monaten etwas.

Wer Probeleser*in sein möchte, bitte melden. Die ersten fertigen Kapitel gibt es vermutlich in ca. 1/2 Jahr.

QueryDSL 5.0.0 verfügbar

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Aus den Release-Notes: https://github.com/querydsl/querydsl/releases/tag/QUERYDSL_5_0_0:

This release of QueryDSL targets Java 8 minimally and comes with various improvements to make QueryDSL ready for the modern Java ecosystem.
This version also removes joda-time:joda-time, com.google.guava:guava and com.google.code.findbugs:jsr305 as required runtime dependencies for using QueryDSL.

QueryDSL 5.0 is the long awaited major release after the QueryDSL project was left mostly unmaintained for over two years.

New features

  • #2672 – Various performance and code improvements possible by targeting Java 8 source level.
  • #2672 – Added Fetchable#stream() which returns a Stream<T>.
    Make sure that the returned stream is always closed to free up resources, for example using try-with-resources.
    It does not suffice to rely on a terminating operation on the stream for this (i.e. forEach, collect).
  • #2324 – Removal of Guava as dependency.
    Almost no required transitive dependencies to get started with QueryDSL.
    And no more conflicts with Guava versions required by your other tools or own application.
  • #2025 – joda-time:joda-time is no longer a required dependency for querydsl-sql.
    By default, the Java 8 date/time API is used for date/time operations.
    The joda-time:joda-time types will still be registered automatically if they are on the classpath.
  • #2215 – MongoDB 4 support through the Document API
  • #2697 – Allow com.querydsl.core.alias.Alias.* to be used on a JRE by relying on ECJ as compiler
  • #2479 – Swap out JSR305 for Jetbrains Annotations.
    Because the Jetbrains Annotations, contrary to the JSR305 annotations, use a Class retention level, Jetbrains Annotations
    does not have to be available at runtime and is not a transitive dependency.
  • #658 – Added JPAExpressions#treat which can be used to generate JPA 2.1 Treated path expressions.
  • #2666 – More descriptive error message when using unsupported query features in JPA.
  • #2106 – Support NullsLast ordering in querydsl-collections.
  • #2404 – Upgrade of JTS / Geolatte in querydsl-spatial
  • #2320 – Make Spatial support available to HibernateDomainExporter and JPADomainExporter.
  • #2612 – Support jakarta.* packages for new Jakarta EE releases (available through thejakarta classifiers for Maven)
  • #1376 – Return typed expression from nullif and coalesce methods.
  • #1828 – Kotlin Codegen support
  • #2798 – Java Record support

Wie ist denn der Einsatz bei euch von QueryDSL? Eine wichtiger Baustein in eurer Unternehmensanwendung?

Inselraus: parse*(…)- und print*()-Methoden in DatatypeConverter für Hex-Ausgaben

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Das javax.xml.bind-Paket bietet eine Klasse DatatypeConverter, die eigentlich für die Abbildung von XML-Typen auf Java-Typen gedacht ist, doch auch so einige nützliche Methoden bereitstellt. Wir finden in der Klasse statische parse*(String)-Methoden und print*(…)-Methoden: Die ersten konvertieren einen String in diverse Datentypen – etwa short parseShort(String) –, und die zweiten formatieren einen bestimmten Datentyp in einen String – etwa String printShort(short). Für die meisten Methoden gibt es mit String.valueOf(…) und den parse*(…)/toString(…)-Methoden in den Wrapper-Klassen bessere Alternativen, und die Umwandlung von Datumswerten und Fließkommazahlen ist nicht lokalisiert, doch hervorzuheben sind folgende zwei Methoden:

final class javax.xml.bind.DatatypeConverter

  • staticbyte[]parseHexBinary(StringlexicalXSDHexBinary)
  • staticStringprintHexBinary(byte[]val)

Mit diesen statischen Methoden können leicht Byte-Arrays in die String-Repräsentationen hexadezimal konvertiert werden. Das ist nötig, wenn etwa Bytes in einer Text-Konfigurationsdatei abgelegt werden sollen. DatatypeConverter bietet auch Methoden für eine Base64-Kodierung, allerdings sind die geschachtelten Klassen in java.util.Base64 üblicher.

Beispiel:

Konvertiere ein Byte-Array in eine String-Repräsentation, einmal im klassischen Hex-Format, einmal in Base64-Kodierung:

byte[] bytes = { 1, 2, 3, (byte) 254, (byte) 255 };
String s1 = DatatypeConverter.printHexBinary( bytes );
String s2 = DatatypeConverter.printBase64Binary( bytes );
System.out.println( s1 ); // 010203FEFF
System.out.println( s2 ); // AQID/v8=
// Arrays.equals( bytes, DatatypeConverter.parseHexBinary( s1 ) ) == true
// Arrays.equals( bytes, DatatypeConverter.parseBase64Binary( s2 ) ) == true

Inselupdate: strictfp verschwindet in Java 17

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Zwischen Java 1.2 und Java 16 unterstützte der Java-Compiler das Schlüsselwort strictfp. Die Unterscheidung sollte es der Laufzeitumgebung erlauben, nicht strikt nach der IEEE-754-Spezifikation zu arbeiten und damit schneller auf der lokalen Hardware Java-Programme auszuführen. Doch seit 20 Jahren unterstützen alle Prozessoren IEEE-754, und die Unterscheidung ist irrelevant geworden – alle von der JVM ausgeführten mathematischen Operationen sind wie im IEEE-754-Standard beschrieben. Mit dem Abschied von strictfp wird auch die Klasse StrictMath irrelevant.

Details: https://openjdk.java.net/jeps/306

Inselraus: Vererbung und Überschattung von statischen Variablen in Schnittstellen

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Die Konstanten einer Schnittstelle können einer anderen Schnittstelle vererbt werden. Dabei gibt es einige kleine Einschränkungen. Wir wollen an einem Beispiel sehen, wie sich die Vererbung auswirkt, wenn gleiche Bezeichner in den Unterschnittstellen erneut verwendet werden. Die Basis unseres Beispiels ist die Schnittstelle BaseColors mit ein paar Deklarationen von Farben. Zwei Unterschnittstellen erweitern BaseColors, und zwar CarColors und PlaneColors, die für Farbdeklarationen für Autos und Flugzeuge stehen. Eine besondere Schnittstelle FlyingCarColors erweitert die beiden Schnittstellen CarColors und PlaneColors, denn es gibt auch fliegende Autos, die eine Farbe haben können.

interface BaseColors {
  int WHITE   = 0;
  int BLACK   = 1;
  int GREY    = 2;
}
interface CarColors extends BaseColors {
  int WHITE   = 1;
  int BLACK   = 0;
}
interface PlaneColors extends BaseColors {
  int WHITE   = 0;
  int GREY    = 2;
}
interface FlyingCarColors extends CarColors, PlaneColors { }
public class Colors {
  public static void main( String[] args ) {
    System.out.println( BaseColors.GREY );      // 2
    System.out.println( CarColors.GREY );       // 2
    System.out.println( BaseColors.BLACK );     // 1
    System.out.println( CarColors.BLACK );      // 0
    System.out.println( PlaneColors.BLACK );    // 1
    System.out.println( FlyingCarColors.WHITE );
       //  field FlyingCarColors.WHITE is ambiguous
    System.out.println( FlyingCarColors.GREY );
       //  field FlyingCarColors.GREY is ambiguous
  }
}

Die erste wichtige Tatsache ist, dass unsere drei Schnittstellen ohne Fehler übersetzt werden können, aber nicht die Klasse Colors. Das Programm und der Compiler zeigen folgendes Verhalten:

  • Schnittstellen vererben ihre Eigenschaften an die Unterschnittstellen. CarColors und auch PlaneColors erben die Farben WHITE, BLACK und GREY aus BaseColors.
  • Konstanten dürfen überdeckt werden. CarColors vertauscht die Farbdeklarationen von WHITE und BLACK und gibt ihnen neue Werte. Wird jetzt der Wert BLACK verlangt, liefert die Umgebung den Wert 0, während BaseColors.BLACK 1 ergibt. Auch PlaneColors überdeckt die Konstanten WHITE und GREY, obwohl die Farben mit dem gleichen Wert belegt sind.
  • Erbt eine Schnittstelle von mehreren Oberschnittstellen, so ist es zulässig, dass die Oberschnittstellen jeweils eine gleichlautende Objektvariable haben. So erbt etwa FlyingCarColors von CarColors und PlaneColors die Einträge WHITE, BLACK und GREY.
  • Unterschnittstellen können aus zwei Oberschnittstellen die Objektvariablen gleichen Namens übernehmen, auch wenn die Konstanten einen unterschiedlichen Wert haben. Das testet der Compiler nicht. FlyingCarColors bekommt aus CarColors ein WHITE mit 1, aber aus PlaneColors das WHITE mit 0. Daher ist in dem Beispiel Colors auch der Zugriff WHITE nicht möglich und führt zu einem Compilerfehler. Bei der Benutzung muss ein unmissverständlich qualifizierter Name verwendet werden, der deutlich macht, welche Objektvariable gemeint ist, also zum Beispiel CarColors.WHITE oder PlaneColors.WHITE. Ähnliches gilt für die Farbe GREY. Obwohl Grau durch die ursprüngliche Deklaration bei BaseColors und auch bei der Überschattung in PlaneColors immer 2 ist, ist die Nutzung durch FlyingCarColors.GREY nicht zulässig. Das ist ein guter Schutz gegen Fehler, denn wenn der Compiler dies durchließe, könnte sich im Nachhinein die Belegung von GREY in BaseColors oder PlaneColors ohne Neuübersetzung aller Klassen ändern und zu Schwierigkeiten führen. Diesen Fehler – die Oberschnittstellen haben für eine Konstante unterschiedliche Werte – müsste die Laufzeitumgebung erkennen. Doch das ist nicht möglich, und in der Regel setzt der Compiler die Werte auch direkt in die Aufrufstelle ein, und ein Zugriff auf die Konstantenwerte der Schnittstelle findet nicht mehr statt.

Spring Boot Update 2.4.1

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Details siehe https://github.com/spring-projects/spring-boot/releases/tag/v2.4.1

Dependency Upgrades:

  • Upgrade to Caffeine 2.8.8 #24443
  • Upgrade to DB2 JDBC 11.5.5.0 #24383
  • Upgrade to Dropwizard Metrics 4.1.16 #24384
  • Upgrade to Groovy 2.5.14 #24385
  • Upgrade to Hibernate 5.4.25.Final #24386
  • Upgrade to HttpCore 4.4.14 #24387
  • Upgrade to Infinispan 11.0.8.Final #24388
  • Upgrade to Jetty 9.4.35.v20201120 #24389
  • Upgrade to jOOQ 3.14.4 #24390
  • Upgrade to Kotlin 1.4.21 #24391
  • Upgrade to Kotlin Coroutines 1.4.2 #24392
  • Upgrade to MariaDB 2.7.1 #24393
  • Upgrade to Micrometer 1.6.2 #24281
  • Upgrade to Mockito 3.6.28 #24394
  • Upgrade to Netty 4.1.55.Final #24444
  • Upgrade to Netty tcNative 2.0.35.Final #24445
  • Upgrade to Nimbus JOSE JWT 9.1.3 #24395
  • Upgrade to Reactor 2020.0.2 #24275
  • Upgrade to Spring AMQP 2.3.2 #24288
  • Upgrade to Spring Batch 4.3.1 #24291
  • Upgrade to Spring Data 2020.0.2 #24284
  • Upgrade to Spring Framework 5.3.2 #24278
  • Upgrade to Spring HATEOAS 1.2.2 #24285
  • Upgrade to Spring Integration 5.4.2 #24442
  • Upgrade to Spring Kafka 2.6.4 #24294
  • Upgrade to Spring Security 5.4.2 #24297
  • Upgrade to SQLite JDBC 3.32.3.3 #24446
  • Upgrade to Tomcat 9.0.41 #24447
  • Upgrade to Undertow 2.2.3.Final #24397

Oracle JDK vs. OpenJDK und Migration zu Azul für den kommerziellen Betrieb

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Veränderungen in der Verfügbarkeit des Java Development Kit seit dem Release des JDK 11 im September 2018 erschweren den sicheren Betrieb von Java-Anwendungen für viele Endnutzer. Die Nutzung des Oracle JDK ist im kommerziellen IT Betrieb nun nur noch mit Lizenz möglich.
Azul Systems tritt an, mit der Zulu OpenJDK Laufzeitumgebung eine wirtschaftlich attraktive Java-Distribution mit zuverlässigen Updates und Bug Fixes anzubieten.

2006 hat Sun Microsystems, zu diesem Zeitpunkt der Inhaber der Marke Java, angekündigt das JDK in ein Open-Source Projekt zu überführen. Zu diesem Zweck wurde das OpenJDK Projekt in Leben gerufen, das ein Zuhause auf http://openjdk.java.net fand. Beginnend mit dem JVM Source Code wurden bis Anfang 2007 auch die Kernbibliotheken veröffentlicht. Einige Teile des OpenJDK blieben bis April 2009 proprietär, bis mit build 53 des OpenJDK 7 eine vollständig auf Open Source basierende Distribution verfügbar war. Seit Java 7 SE ist das OpenJDK die Referenzimplementierung des Java SE-Standards, der durch die entsprechenden Java Specification Requests (JSR) festgelegt wird. Ein Projekt mit dem Ziel einer Open Source Umsetzung von Java SE 6 wurde ebenfalls gestartet, geleitet von Andrew Brygin von Azul Systems. Das OpenJDK steht unter der GNU Public License (GPL) version 2 with classpath exception (CPE). Die Lizenzierung unter der CPE verhindert das die „copyleft“ Natur der GPL sich auf die Anwendungen auswirkt die das OpenJDK als Laufzeitumgebung nutzen. Im September 2007 hat Oracle zahlreiche Veränderungen bei der Art und Weise wie das JDK entwickelt, verbreitet und aktualisiert wird. Diese lassen sich wie folgt zusammenfassen:

  • Der Releasezyklus des JDK ist kalendergetrieben mit zwei Releases pro Jahr im März und September.
  • Oracle hat liefert nun eine zweite Binärdistribution des JDK aus, die ausschließlich auf OpenJDK Source Code basiert. Diese wird unter der GPLv2 with classpath exception license verbreitet, die weniger restriktiv als die Oracle Binary Code License (BCL) for Java SE ist, welche für Oracle Binaries verwendet wird.
  • Ab JDK 11 gibt es keine funktionalen Unterschiede mehr zwischen den Oracle JDK Binaries und eine reinen Open Source OpenJDK. Um dies zu ermöglichen, hat Oracle einige zuvor proprietäre Features zum OpenJDK hinzugefügt (z.B. Mission Control und Flight Recorder). Einige andere Features, wie Web Start und JavaFX, wurden entfernt.
  • Ab JDK 11 nutzt Oracle das Oracle Technology Network License Agreement (OTNLA) welches keine völlig freie Nutzung mehr erlaubt. Unter dieser Lizenz kann das Oracle JDK frei für Entwicklung und Test verwendet werden, benötigt aber eine kommerzielle Lizenz für die produktive Nutzung.
  • Oracle OpenJDK-Binaries werden nur maximal 6 Monate bis zum nächsten JDK gepflegt. Longterm Support ist von Oracle nur unter einem Lizenzvertrag verfügbar sein.
  • Freie Updates für das JDK 8 enden im Januar 2019 mit Update 202. Anwender können dies Version frei weiter nutzen, da sie noch unter der Oracle BCL steht. Ab April 2019 stehen die Updates auf java.oracle.com unter der OTNLA und bedürfen zur produktiven Nutzung eine Lizenzvereinbarung mit Oracle.

Das OpenJDK ist ein reines Source Code Projekt. Um es als Java Laufzeitumgebung nutzen zu können ist es nötig, das Projekt in eine Binärdistribution zu kompilieren. Die von Azul erstellte Distribution trägt den Namen Zulu. Zulu wird, mit dem vom OpenJDK vorgegebenen Standard
Build Prozess erstellt und alle Binaries mit dem Technology Compatibility Kit (TCK) validiert, um Kompatibilität und Konformität mit der Java SE-Spezifikation sicherzustellen. Um die den stabilen und sicheren Betrieb bei den Kunden zu ermöglichen werden regelmäßige Updates für
das OpenJDK erstellt, die Bug Fixes und Security Patches enthalten. Bis zu Version 9 des JDK wurden diese Updates jeweils für die aktuelle Version und die vorhergehende Version bereitgestellt. Die Überlappung der Supportzeiträume seit JDK 6 betrug zwischen 13 und 37 Monate. Unter der neuen Release Policy sind jedoch bereits OpenJDK 6, 7, 8 und 11 aus dem öffentlichen und freien Support herausgefallen. Azul liefert auf weiterhin Updates für all diese JDK-Versionen. Dies erlaubt es den Kunden auch ältere Java-Versionen sicher im produktiven Betrieb zu nutzen.

Unterschiede zwischen OpenJDK und Oracle JDK

Da das OpenJDK die Referenzimplementierung des Java SE-Standards darstellt, nutzen Oracle und andere es als Basis ihrer Binärdistributionen. Vor JDK 11 enthielt das Oracle JDK eine Reihe von
zusätzlichen Features, von denen einige nun Open Source sind, andere bleiben proprietär.

  • Die Kryptographie-Module von Oracle JDK und OpenJDK unterstützten die gleichen kryptographischen Funktionen auf der Basis des gleichen Source-Codes. Ab Januar 2018 (JDK 8 Update 161) haben alle OpenJDK-basierten Distributionen (Zulu und Oracle) Einschränkungen zur Schlüssellänge und Stärke der Verfahren entfernt. Zuvor war die Schlüssellänge auf 128 Bit beschränkt, und es war nötig, ein ergänzendes Modul zu installieren, um starke Kryptographie zu aktivieren. Für Oracle JDK war dieses Module das Java Cryptographic Extensions (JCE) package, und für Zulu, das Cryptographic Extension Kit (CEK). Zulu und Oracle JDK folgen im Allgemeinen der gleichen Kryptographie-Roadmap. Details siehe Link https://www.java.com/en/jre-jdk-cryptoroadmap.html.
  • JavaFX ist ein optionales GUI Framework, welches Oracle mit dem JDK ausgeliefert hat. Die Quellen wurden in das OpenJFX-Projekt überführt. Azul unterstützt OpenJFX im ZuluFX Bundle. Download verfügbar unter: http://openjdk.java.net/projects/openjfx
  • Browser-Plugin: Das Browser Applet Plugin ist mit dem Oracle JDK, aber nicht mit Zulu JDK verfügbar.
  • Applet-Support im Browser wurde mit JDK 9 deprecated und mit JDK 11 von Oracle entfernt.
  • Java Web Start: Im Oracle JDK enthalten, aber nicht im Zulu JDK. Azul bietet mit IcedTea-Web eine Open Source Alternative. Java WebStart wurde wie Applets mit JDK deprecated und in JDK 11 entfernt. IcedTea-Web ist auch für Zulu 11 verfügbar. Für IcedTea-Web ist ein sorgfältiger
    Migrationstest notwendig.
  • Mission Control: Bis Oracle JDK 9 ist Mission Control ein kostenpflichtiges Add-on für den produktiven Betrieb. Mission Control ist seit JDK 10 Open Source und Teil des OpenJDK. Azul stellt Mission Control als separates Paket bereit. Es ist mit jeder JVM mit Flight Recorder Unterstützung kompatibel.
  • Flight Recorder: Wie Mission Control war der Flight Recorder bis JDK 10 kostenpflichtig, ab JDK 11 Open Source. Azul hat einen Backport auf Zulu 8 erstellt, so dass Azul-Kunden ab Zulu 8 (update 202) von Mission Control Unterstützung profitieren können.
  • – VisualVM: Bis JDK 8 Teil des Oracle JDK, aber nicht Teil von Zulu. VisualVM wurde ab JDK 9 entfernt , ist aber weiterhin als separates Open-Source-Projekt verfügbar: https://visualvm.github.io/.
  • Java DB: Binärdistribution der Apache Derby Datenbank, die im Oracle JDK bis JDK 8 enthalten war, aber nicht mit Zulu ausgeliefert wurde. Ab JDK 9 entfernt, aber weiterhin als Open Source Projekt verfügbar: https://db.apache.org/derby/.

Nicht im OpenJDK enthaltene Features

  • Fonts: Sowohl Oracle als auch Zulu JDKs werden mit dem gleichen Satz an kommerziell lizenzierten Fonts ausgeliefert.
  • SNMP: Das Oracle JDK enthält ein proprietäres Modul. Diese wurde mit JDK 11 aus dem Oracle JDK entfernt. Die Open Source Lösung SNMP4J  http://snmp4j.com/ kann ggf. als Alternative dienen.
  • Sound-Treiber: Nur für ältere Windows Versionen benötigt und nicht im OpenJDK enthalten.

Abweichungen zwischen OpenJDK und Oracle JDK

  • Color Matching: Das Oracle JDK verwendet eine proprietäre Lösung. Zulu JDK nutzt die Lösung des OpenJDK, die vergleichbare, aber nicht identische Ergebnisse liefert.
  • Font Rendering: Das Oracle JDK verwendet einen proprietären Font-Renderer (T2K). Zulu (und OpenJDK) nutzen den FreeType Open Source Renderer https://www.freetype.org/.
  • Java 2D Graphics Rasterizer: Vor JDK 9 nutzte OpenJDK den Pisces Open Source Renderer, während Oracle JDK ein proprietäres Modul, Ductus, verwendete. Ab JDK 9 wurde Pisces durch den Marlin Renderer ersetzt, dessen Performance mit Ductus vergleichbar ist. Zulu JDK nutzt Marlin seit JDK 8.

JDK Deployment

Anwender können bei der Planung des OpenJDK-Rollout folgenge Option in Betracht ziehen:

  • Weiternutzung der bereits installierten Java-Laufzeitumgebungen, wie z. B. JDK 8, ohne Updates und Security-Patches. Dies ist die Option mit dem höchsten betrieblichen Risiko, da im Laufe der Zeit vermehrt Sicherheitslücken aufgedeckt werden. Für Anwendungen die regulatorischen Anforderungen entsprechen müssen ist dies ein erhebliches Problem.
  • Migration der Anwendungen auf die neueste freie OpenJDK-Version mit Update auf die Folgeversion alle 6 Monate. Dies ist mit einem Kompatibilitätsrisiko verbunden, da Oracle angekündigt hat, das Kompatibilität nicht mehr 100% garantiert wird (bis JDK 9 war Rückwärtskompatibilität stehts ein Designziel). Der Test und Migrationsaufwand kann für nicht aktiv weiterentwickelte Anwendungen erheblich sein.
  • Weiterverwendung von Oracle JDK als kostenpflichtige Subskription. Dies eliminiert die Risiken der vorgenannten Optionen ist aber meist die teuerste Lösung. Die neue Oracle Java Subskription wird auf der Basis von „Oracle Processors“ kalkuliert. Die Ermittlung der zu lizensierenden Mengen kann komplex sein, da neben der genauen Zahl von physischen Cores ein CPU Typ spezifischer „Core factor“ herangezogen werden muss. In virtualisierten Umgebungen (z. B. VMware) muss das gesamte vCenter lizensiert werden, da Applikationen zwischen Servern migrieren können. Ein typischer Server hat zwei Intel Xeon Hexa-core CPUs und wird als sechs „Oracle Processors“ gezählt. Bei Java SE-Subskriptionskosten von $25 pro Oracle Processor pro Monat sind dies $1800 pro Jahr für diesen Beispielserver. In Umgebungen mit über 1000 Servern können die Kosten über einer Million USD pro Jahr liegen.
  • Support für eine alternativen OpenJDK Variante mit niedrigeren Gesamtkosten. Azul kann mit der Zulu Enterprise Distribution eine attraktives Angebot machen, da nur die Zahl der physischen Server in Betracht gezogen werden, und es bei über 1000 Servern zu weniger als einem Zehntel des Oracle Subskription Listenpreises kommt. Für größere Umgebungen ist daher Zulu Enterprise immer die kostengünstigere Lösung.

Migration zu Zulu Enterprise

Das Zulu OpenJDK wird unter der GPLv2 with CPE Lizenz veröffentlicht. Zulu Binaries stehen für Windows, Linux, Solaris und MacOS X auf https://www.azul.com/downloads/zulu-community/ zum Download bereit. Auch Release Notes mit Installationsanleitung finden sich auf dieser Seite. Diese decken alle bereitgestellten Paketformate, Abhängigkeiten sowie Anleitungen für die Installation in gängigen Cloud Umgebungen wie Microsoft Azure und Amazon Web Services bereit. Enthalten sind auch Post-Installationsschritte und eine Anleitung wie die Standard Java Runtime auf einem Server/Desktop aus festgelegt werden kann.

Das Zulu Commercial Compatibility Kit

Die proprietären Lucida Font aus dem Oracle JDK sind nicht Teil des Standard OpenJDK. Falls erforderlich stellt das Zulu Commercial Compatibility Kit (CCK)diese Fonts bereit, um in GUIs und PDF Generatoren ein identisches Layout und Schriftbild zu erhalten.

Zum Download des Zulu CCK müssen die Nutzungsbedingungen akzeptiert werden. Der Installer überprüft, ob eine passende Zulu-Version installiert ist. Beim Download ist auf die korrekte Version zu achten! Details und Download gibt es unter https://www.azul.com/products/zulu-and-zulu-enterprise/cck-downloads/. Dies ermöglicht in der Regel eine Migration ohne zusätzlich betriebliche Aufwände.

Zusammenfassung

Zulu ist eine OpenJDK Distribution die vollumfänglich der Java SE-Spezifikation entspricht. Jede Anwendung, die auf Standard Java-Komponenten und APIs setzt, kann durch einen einfachen Austausch des JDK Pfads migriert werden. Ein engagiertes Entwicklerteam nimmt komplexe Anpassungen, wie Backporting und Integration von Updates in ältere OpenJDK-Versionen vor; daher können sich Azul-Kunden der aktuellsten Security-Patches und Bug-Fixes auch auf älteren Java-Versionen erfreuen.

Die Zulu OpenJDK-Distribution bietet eine kostengünstige Alternative, um Applikationen auf aktuelle Java Versionen zu migrieren und sicher zu betreiben.