Quiz: Listen in Arrays konvertieren und toArrays(…) beherrschen

Während Array.asList(...) nur ein Dektorator ist, der ein Array so aussehen lässt, als wäre es eine List, übertragen drei überladene Methoden toArray(...) aus Collection alle Elemente einer Sammlung auf eine Liste:

  • Object[] toArray()
  • <T> T[] toArray(T[] a)
  • default <T> T[] toArray​(IntFunction<T[]> generator) (Java 11)

Was ist das Ergebnis der Ausgabe?

List<String> list = new ArrayList<>( Arrays.asList( "a", "b" ) );
System.out.println( list.toArray()[ 0 ] );
System.out.println( list.toArray( new String[ 0 ] )[ 0 ] );
System.out.println( list.toArray( new String[ 0 ] ).length );
System.out.println( list.toArray( new String[ 1 ] )[ 0 ] );
System.out.println( list.toArray( new String[ 1 ] ).length );
System.out.println( list.toArray( value -> new String[ 1 ] )[ 0 ] );
System.out.println( list.toArray( value -> new String[ 1 ] ).length );
System.out.println( list.toArray().getClass() );
System.out.println( list.toArray( new String[ 0 ] ).getClass() );

Lösung .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

List<String> list = new ArrayList<>( Arrays.asList( "a", "b" ) );
System.out.println( list.toArray()[ 0 ] ); // a
System.out.println( list.toArray( new String[ 0 ] )[ 0 ] ); // a
System.out.println( list.toArray( new String[ 0 ] ).length ); // 2
System.out.println( list.toArray( new String[ 1 ] )[ 0 ] ); // a
System.out.println( list.toArray( new String[ 1 ] ).length ); // 2
System.out.println( list.toArray( value -> new String[ 1 ] )[ 0 ] ); // a
System.out.println( list.toArray( value -> new String[ 1 ] ).length ); // 2
System.out.println( list.toArray().getClass() ); // class [Ljava.lang.Object;
System.out.println( list.toArray( new String[ 0 ] ).getClass() ); // class [Ljava.lang.String;

Es hilft beim Verständnis sich den Code aus dem OpenJDK anzuschauen:

Aus der OpenJDK-Implementierung von java.util.ArrayList:

public Object[] toArray() {
return Arrays.copyOf( elementData, size );
}

Aus der OpenJDK-Implementierung von java.util.ArrayList:

public T[] toArray( T[] a ) {
if ( a.length < size ) // Make a new array of a’s runtime type, but my contents: return (T[]) Arrays.copyOf( elementData, size, a.getClass() ); System.arraycopy( elementData, 0, a, 0, size ); if ( a.length > size )
a[ size ] = null;
return a;
}

Aus der OpenJDK-Implementierung von java.util.Collection:

default T[] toArray( IntFunction generator) {
return toArray(generator.apply(0));
}

 

Geschichte hinter OpenJDK

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: »It’s not a question of whether we’ll open source Java, now the question is how.« War die Frage also statt des »Ob« ein »Wie«, kündigte Rich Green bei der Eröffnungsrede der JavaOne-Konferenz im Mai 2007 die endgültige 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.

Obwohl OpenJDK unter der GPL stand, enthielt es doch Teile wie den Font-Renderer, Sound-Unterstützung, Farbmanagement oder SNMP-Code, die als binäre Pakete beigelegt wurden, weil etwa die Rechte zur Veröffentlichung 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ären 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üllte das OpenJDK mit IcedTea im Juni 2008 die Anforderungen des Technology Compatibility Kit (TCK) von Sun und ist in der Öffentlichkeit 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.

Das OpenJDK bildet die Basis von Java 8, und jeder Entwickler kann sein eigenes Java zusammenstellen und beliebige Erweiterungen veröffentlichen. Damit ist der Schritt vollzogen, dass auch Java auf Linux-Distributionen Platz finden darf, die Java vorher aus Lizenzgründen nicht integrieren wollten.

Auch wenn es sich so anhört, 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äre Dinge enthalten, und nicht alles ist hundertprozentig quelloffen und GPL. Das gilt für die Version 7 wie für 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öchte.

Bei der 6er-Reihe kommt noch eine Besonderheit dazu, wie es die Versionsnummern ganz gut zeigen. Während 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öllig unabhängig, weil beide Projekte auch unabhängig 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-Änderungen gehen mal in die eine Richtung und mal in die andere.

Jetzt kommt die Besonderheit: Das OpenJDK 6 entstand nicht, wie vermutet werden könnte, 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. Änderungen am OpenJDK 7 stammen überwiegend von Oracle, und häufig ist es die Firma Red Hat, die diese Änderungen 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ßartige Veränderungen passieren bis auf Fehlerbereinigungen nicht.

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ür Java SE, nicht das Oracle JDK.

OpenJDK

Das freie und unter der GPL stehende OpenJDK (http://openjdk.java.net/) bildet nunmehr die Referenzimplementierung für Java SE. Alle Entwicklungen finden dort statt. Der Fortschritt ist live zu beobachten, regelmäßig fixen und erweitern Hunderte von Entwicklern die Codebasis. Die Quellen für 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 übertragen, etwa Java Flight Recorder, Java Mission Control, Application Class-Data Sharing und ZGC (Zero-Garbage-Collector).

OpenJDK-Builds von Oracle

Oracle selbst compiliert das OpenJDK und bietet es an. Aktuelle Versionen sind über http://jdk.java.net/ verlinkt. Es gibt von Oracle OpenJDK-x64-Builds für Windows, Linux und macOS.

Das Oracle OpenJDK steht unter der GNU General Public License v2 mit der Classpath Exception (GPLv2+CPE). Oracle selbst hat angekündigt, bei neuen Versionen keine Updates mehr für die alten Versionen zu veröffentlichen.

OpenJDK-Builds von AdoptOpenJDK

AdoptOpenJDK (https://adoptopenjdk.net/) ist eine Stiftung und betreibt eine Serverfarm, die regelmäßig Builds vom OpenJDK baut und dazu weitere Software wie die JavaFX-Implementierung OpenJFX und alternative Laufzeitumgebungen wie Eclipse OpenJ9 einbindet. Es wird angekündigt, auch ältere Versionen mit Bugfixes zu versorgen. Zu den Unterstützern zählen Amazon, IBM/Red Hat, Microsoft, Pivotal und viele weitere.

Von der Webseite lässt sich für unterschiedliche Betriebssysteme eine Version herunterladen. Angeboten werden Builds u.a. für: Windows, Linux, macOS.

AdoptOpenJDK zählt aktuell zu den populärsten OpenJDK-Distributionen.

Weitere OpenJDK-Builds

Das Unternehmen Azul bietet Builds unter dem Namen Zulu an, auch lässt sich ein Support-Vertrag abschließen: http://www.azul.com/downloads/zulu/. Neben den Plattformen Windows, Linux und macOS gibt es von Azul ebenfalls Docker-Images.

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.

SAP bietet mit der SapMachine (http://sap.github.io/SapMachine/) Builds für diverse Betriebssysteme und auch ein Docker-Image.

Amazon Corretto (http://aws.amazon.com/de/corretto/) wird intern von Amazon in der Cloud eingesetzt und ist für die LTS-Versionen Java 8 und Java 11 kostenlos.

Alibaba Dragonwell (http://github.com/alibaba/dragonwell8) ist eine vom OpenJDK 8 abgeleitete Implementierung von Alibaba.

Von BellSoft gibt es das Liberica JDK (http://bell-sw.com/) für 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.

Apple pflegte lange Zeit eine komplett eigene JVM, bis Apple den Code an Oracle für das OpenJDK übergab. Auch Google setzt bei Android neuerdings auf das OpenJDK.

Oracle JDK

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 »offizielle« 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]

Long Term Support (LTS)

Die halbjährlichen 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 – es machte sofort Java 13 zur alten Version. Das allein wäre kein Problem, wenn die älteren Versionen mit Sicherheitsupdates versorgt würden. Aber Oracle investiert für die Allgemeinheit keine Zeit und Mühe mehr und pflegt die alten Versionen nicht.

Für Unternehmen ist das ein Problem, denn es erzeugt Stress, mit den Änderungen mitziehen zu müssen. 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ür weniger agile Unternehmen gut. Oracle will seine Java SE 8-Implementierung noch viele Jahre pflegen.

Kommerzialisierung des Oracle JDK

Auf den ersten Blick sieht das gut aus: Es gibt regelmäßige Updates für 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ürfen; der Hersteller erlaubt die Nutzung nur für »development, testing, prototyping or demonstrating purposes«.

Für Java 8 endete die Schonfrist im Januar 2019. Das dürfte vielen Entwicklern gar nicht bewusst sein, denn seit 20 Jahren sind Unternehmen daran gewöhnt, das Oracle JDK für alles einzusetzen. Und wir wissen alle, wie viele Menschen wirklich die Lizenzbedingungen lesen …

Wer also das Oracle JDK kommerziell einsetzen möchte und nicht nur in einer Entwicklungs- oder Testumgebung, muss eine Lizenz von Oracle erwerben. Es wird monatlich abgerechnet, die Vertragslaufzeit beträgt mindestens ein Jahr. Es stehen zwei Modelle zur Auswahl:

Java SE SubscriptionJava SE Desktop Subscription
Für ServeranwendungenFür Client-Anwendungen
Abrechnung pro ProzessorAbrechnung pro Benutzer
Bis 25 USD/Monat, für 1–99 BenutzerBis 2,50 USD/Monat für 1–999 Benutzer/Clients
Zwei Lizenzmodelle für Oracle Java SE

Oracle wendet bei der Java SE Subscription das gleiche Geschäftsmodell 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 »Oracle Java SE Subscription FAQ« 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 »write once, run anywhere« heißt es nun »write once, pay everywhere«.

Die Kosten können sich schnell summieren, doch bekommen Unternehmen damit Support und insbesondere für Java 8 immer noch für einige Jahre Unterstützung. Der Nachteil ist, dass es das Subscription-Modell nur für die LTS-Versionen gibt, Unternehmen also gezwungen werden, größere Versionssprünge zu machen. Nach Java 11 kommt erst im September 2021 die Version Java 17 mit dem nächsten LTS.

Quarkus 1.0.0 erschienen

Das „Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.“ ist in der ersten Version erschienen und positioniert sich gegen Spring Boot und Jakarata EE.

Zum Weiterlesen und schauen:

Microsoft arbeitet am OpenJDK mit

https://mail.openjdk.java.net/pipermail/discuss/2019-October/005173.html:

Subject: Microsoft’s Ready do Contribute to OpenJDK

Hi OpenJDK Community,

In the past week Microsoft formally signed the Oracle Contributor Agreement, in which Oracle Inc. promptly acknowledged and welcomed us to the project. On behalf of the Microsoft Java Engineering Team, I’d like to say that we are thrilled to officially join the OpenJDK project and be ready to work with you.

As many of you may know, Microsoft and its subsidiaries are heavily dependent on Java in many aspects, and also offers Java runtimes in its Microsoft Azure cloud to its customers. Microsoft recognizes the immense value that Oracle’s successful and effective stewardship of the OpenJDK project has bought Java and the wider software ecosystem and we look forward to playing our part in contributing back!

The team will initially be working on smaller bug fixes and backports so that we can learn how to be good citizens within OpenJDK. For example, we already understand that discussing changes first before posting patches is preferred and I'm sure there's more for us to learn as well.

The Java engineering team led by Martijn Verburg [1] is already engaged with other Microsoft groups and its subsidiaries who are using Java, as well as its partners in the Java ecosystem such as Azul Systems, Oracle, Pivotal, Red Hat, Intel, SAP and others, and the overall team will be joining the many OpenJDK mailing lists to start conversations and participating.

We look forward to participating in the future of Java.

[1] martijn.verburg at microsoft.com<mailto:martijn.verburg at microsoft.com>

Best regards
Bruno Borges
Product Management for Java,
Microsoft Developer Division

Mehr zu der Geschichte unter

  • https://jaxenter.com/microsoft-ready-contribute-openjdk-163550.html

JDK 13 ist in Release Candidate Phase

Laut https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html:

Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
The stabilization repository, jdk/jdk13, is open for P1 bug fixes per
the JDK Release Process (JEP 3) [2].  All changes require approval via
the Fix-Request Process [3].

If you’re responsible for any of the bugs on the RC candidate-bug list
[4] then please see JEP 3 for guidance on how to handle them.

We’ll tag the first Release Candidate build shortly.

- Mark


[1] https://openjdk.java.net/projects/jdk/13/#Schedule
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] https://j.mp/jdk-rc

Weiteres unter http://www.tutego.de/java/jdk-13-java-13-openjdk13.html.

Google Guava 28.0 erschienen

Änderungen laut https://github.com/google/guava/releases/tag/v28.0:

  • collect: Added Duration-based overloads to some Queues methods. (21d06cf)
  • net: Added MediaType for „application/geo+json“. (36cd5cf)
  • net: Added a number of constants to HttpHeaders.
  • concurrent: Removed deprecated CheckedFuture and related utilities. (3dd22fe)
  • concurrent: Added Duration-based overloads to many methods.
  • concurrent: Removed @Beta from setFuture. (5ec1360)
  • concurrent: Added deprecated FluentFuture.from(FluentFuture) to point out redundant code. (f9f2807)
  • graph: Added GraphBuilder.immutable(),ValueGraphBuilder.immutable() and NetworkBuilder.immutable() for building immutable graphs in a fluent way.
  • J2ObjC: Fixed crashes from use of ImmutableMap.entrySet(). (74fc49f)

JBoss EAP 7.2 mit Java EE 8-Untertützung freigegeben

Details bei Red Hat unter https://www.redhat.com/en/blog/announcing-general-availability-red-hat-jboss-enterprise-application-platform-72

Stichwörter:

  • greater compliance with Java Enterprise Edition (EE) 8
  • JBoss EAP 7.2 is Java EE 8 certified
  • Java EE 8 certification introduces new capabilities designed to improve portability and security of applications and the manipulation of JSON documents
  • enhancements related to the support of HTTP/2
  • JBoss EAP 7.2 also supports OpenJDK 11, Oracle JDK 11, Java SE 11
  • Red Hat offers supportfor OpenJDK 8 until 2023 and OpenJDK 11 until 2024.
  • Eclipse MicroProfile Config, a microservices library to manage application configurable parameters across environments
  • Eclipse MicroProfile REST Client, a microservices library designed to more easily invoke microservices in a type-safe manner
  • Eclipse MicroProfile OpenTracing, a microservices library to trace microservices-based applications
  • Eclipse MicroProfile Health, a microservices library to check the state of microservices-based applications
  • tighter integration with Red Hat OpenShift for clustered applications

 

Offene Java/JavaScript-Seminare in 2018

tutego Schulungsraum


Java Grundlagen (›JAVA1‹)

22.–26. Oktober 2018 (KW 43), 12.–16. November 2018 (KW 46)



Java für Fortgeschrittene (›JAVA2‹)

8.–12. Oktober 2018 (KW 41), 26.–30. November 2018 (KW 48)



Spring Boot (›SPRINGBOOT‹)

15.–17. Oktober 2018 (KW 42), 5.–7. November 2018 (KW 45), 3.–5. Dezember 2018 (KW 49)



JavaScript für Web-Entwickler (›JAVASCRIPT‹)

15.–17. Oktober 2018 (KW 42), 5.–7. November 2018 (KW 45), 3.–5. Dezember 2018 (KW 49)

Eigene Doclets programmatisch ausführen – was ist neu in Java 10?

Das javadoc-Tool hat die Aufgabe, den Java-Quellcode auszulesen und die Javadoc-Kommentare zu extrahieren. Was dann mit den Daten passiert, ist die Aufgabe eines Doclets. Das Standard-Doclet von Oracle erzeugt die bekannte Struktur auf verlinkten HTML-Dateien, aber es lassen sich auch eigene Doclets schreiben, um etwa in Javadoc-Kommentaren enthaltene Links auf Erreichbarkeit zu prüfen oder UML-Diagramme aus den Typbeziehungen zu erzeugen. Hervorzuheben ist JDiff (http://javadiff.sourceforge.net/), was Differenzen in unterschiedlichen Versionen der Java-Dokumentation – wie neu hinzugefügte Methoden – erkennt und meldet.

Die Doclet-API ist Teil vom JDK, und deklariert Typen und Methoden, mit denen sich Module, Pakete, Klassen, Methoden usw. und deren Javadoc-Texte erfragen lassen. Allerdings gibt es zwei Doclet-APIs:

  • Im Paket javadoc.doclet (Modul jdk.javadoc) ist die aktuelle API.
  • Im Paket sun.javadoc ist die mittlerweile deprecated API, allerdings einfacher zu nutzen.

Beispiel

Im folgenden Beispiel wollen wir ein kleines Doclet schreiben, das Klassen, Attribute, Methoden und Konstruktoren ausgibt, die das Javadoc-Tag @since 10 tragen. So lässt sich leicht ermitteln, was in der Version Java 10 alles hinzugekommen ist. Doclets werden normalerweise von der Kommandozeile aufgerufen und dem javadoc-Tool übergeben, doch da es mit der Tool-Schnittstelle auch selbst geht, können wir ein Programm mit main(…)-Methode schreiben, das die Neuerungen auf der Konsole ausgibt.

package com.tutego.insel.tools;




import java.io.IOException;

import java.nio.file.*;

import java.util.Arrays;

import java.util.List;

import java.util.function.Predicate;

import java.util.stream.Collectors;

import javax.tools.*;

import com.sun.javadoc.*;




@SuppressWarnings( "deprecation" )

public class FindSinceTagsInJavadoc {




  public static class TestDoclet {




    public static boolean start( RootDoc root ) {

      Arrays.stream( root.classes() ).forEach( TestDoclet::processClass );

      return true;

    }




    private static void processClass( ClassDoc clazz ) {




      Predicate<Doc> hasSinceTag = doc -> Arrays.stream( doc.tags( "since" ) )

                                            .map( Tag::text ).anyMatch( "10"::equals );




      if ( hasSinceTag.test( clazz ) )

        System.out.printf( "%s -- Neuer Typ%n", clazz );




      Arrays.stream( clazz.fields() ).filter( hasSinceTag )

            .forEach( f -> System.out.printf( "%s -- Neues Attribut%n", f ) );




      Arrays.stream( clazz.methods() ).filter( hasSinceTag )

            .forEach( m -> System.out.printf( "%s -- Neue Methode%n", m ) );




      Arrays.stream( clazz.constructors() ).filter( hasSinceTag )

            .forEach( c -> System.out.printf( "%s -- Neuer Konstruktor%n", c ) );

    }

  }




  public static void main( String[] args ) throws IOException {




    Path zipfile = Paths.get( System.getProperty( "java.home" ), "lib/src.zip" );

    try ( FileSystem srcFs = FileSystems.newFileSystem( zipfile, null ) ) {

      Predicate<Path> filesToIgnore = p ->  p.toString().endsWith( ".java" ) &&

                                          ! p.toString().startsWith( "/javafx" ) &&

                                          ! p.toString().startsWith( "/jdk" ) &&

                                          ! p.toString().endsWith( "module-info.java" ) &&

                                          ! p.toString().endsWith( "package-info.java" );




      List<Path> paths = Files.walk( srcFs.getPath( "/" ) )

                              .filter( filesToIgnore ).collect( Collectors.toList() );




      DocumentationTool tool = ToolProvider.getSystemDocumentationTool();

      try ( StandardJavaFileManager fm = tool.getStandardFileManager( null, null, null ) ) {

        Iterable<? extends JavaFileObject> files = fm.getJavaFileObjectsFromPaths( paths );

        tool.getTask( null, fm, null, TestDoclet.class, List.of( "-quiet" ), files ).call();

      }

    }

  }

}

Unsere main(…)-Methode bindet zunächst das ZIP-Archiv vom JDK mit den Quellen als Dateisystem ein. Im nächsten Schritt durchsuchen wir das Dateisystem nach den passenden Quellcodedateien und sammeln sie in eine Liste von Pfaden. Jetzt kann das DocumentationTool mit unserem Doclet konfiguriert und aufgerufen werden. call() startet das Parsen aller Quellen und führt anschließend zum Aufruf von start(RootDoc) unseres Doclets.

In unserer start(…)-Methode laufen wir über alle ermittelten Typen und rufen dann processClass(ClassDoc) auf. Dort passiert der eigentliche Test. Die Metadaten kommen dabei über diverse XXXDoc-Typen. Ein Predicate zieht den Tag-Test heraus.

Autor für MySQL-Administrationshandbuch gesucht

Der www.rheinwerk-verlag.de ist auf der Suche nach einem Überarbeiter für das Administrationshandbuch zu MySQL (https://www.rheinwerk-verlag.de/mysql_3843/). Das Autorenteam des bestehenden Buchs findet für die anstehende Aktualisierung auf MySQL 8
nicht mehr die Zeit. Interessierte Autoren mögen sich bitte unter melden bei:

Christoph Meister, Lektor Computing
Rheinwerk Verlag GmbH | Rheinwerkallee 4 | 53227 Bonn
Telefon +49 228 42150-45
christoph . meister @ rheinwerk – verlag . de (Space entfernen)

Nacktes Thymeleaf

Oftmals nutzen die Beispiele im Internet Spring, oder — noch spezieller — Thymeleaf wird als Template-Engine in Spring MVC eingesetzt, daher jetzt nackt, so einfach es geht.

In unsere POM kommt:

<!-- https://mvnrepository.com/artifact/org.thymeleaf/thymeleaf -->
<dependency>
 <groupId>org.thymeleaf</groupId>
 <artifactId>thymeleaf</artifactId>
 <version>3.0.9.RELEASE</version>
</dependency>

Wir schreiben das Template demo.html:

<!DOCTYPE html>
<html>
<body>
<p>Hey <span data-th-text="${name}">CHRISTIAN</span></p>
</body>
</html>

Und dann kann ein Java-Programm name füllen:

import org.thymeleaf.TemplateEngine;
import org.thymeleaf.context.Context;
import org.thymeleaf.templateresolver.FileTemplateResolver;

public class ThymeleafDemo {

 public static void main( String[] args ) {

  FileTemplateResolver resolver = new FileTemplateResolver();
  resolver.setCharacterEncoding( "UTF-8" );

  TemplateEngine templateEngine = new TemplateEngine();
  templateEngine.setTemplateResolver( resolver );

  Context ctx = new Context();
  ctx.setVariable( "name", "tutego" );
 
  String result = templateEngine.process( "demo.html", ctx );
  System.out.println( result );
 }
}

 

Aktuelle offene Java-Seminare Q2/Q3 2018

Spring Boot (›SPRINGBOOT‹)

22.–24. Mai 2018 (KW 21), 11.–13. Juni 2018 (KW 24), 16.–18. Juli (KW 29)

Java Grundlagen (›JAVA1‹)

14.–18. Mai 2018 (KW 20), 25.–29. Juni 2018 (KW 26), 6.–10. August 2018 (KW 32), 17.–21. September 2018 (KW 38), 5.–9. November 2018 (KW 45)

Java für Fortgeschrittene (›JAVA2‹)

28. Mai bis 1. Juni 2018 (KW 22), 9.–13. Juni 2018 (KW 28), 20.–24. August 2018 (KW 34), 8.–12. Oktober 2018 (KW 41), 26.–30. November 2018 (KW 48)

Java für C++/C#-Programmierer

23.–27. April 2018 (KW 17), 11.–15. Juni 2018 (KW 24), 23.–27. Juli 2018 (KW 30), 3.–7. September 2018 (KW 36), 22.–26. Oktober 2018 (KW 43)

Nebenläufige Programmierung mit Threads (›JAVACON‹)

7.–8. Mai (KW 19), 14.–15. Juni (KW 24), 19.–20. Juli (KW 29)