So stellt es der Artikel https://www.infoworld.com/article/3407781/a-plan-to-bring-java-to-ios.html vor.

Kerngedanke: Das Projekt OpenJDK Mobile wieder aktivieren, GraalVM ahead-of-time Compiler nutzen.

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

Details siehe https://spring.io/blog/2019/07/04/explore-the-project-on-start-spring-io

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

Amazon Corretto 8 Now Generally Available
byu/small_ticket injava

https://github.com/ullenboom/ppt2asciidocslides

Java Grundlagen (›JAVA1‹)

Java für Fortgeschrittene (›JAVA2‹)

Spring Boot (›SPRINGBOOT‹)

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

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.

Kurz nach Eclipse Photon basiert nun auch die STS auf der aktuellsten Eclipse-Version:

• https://spring.io/blog/2018/07/05/spring-tool-suite-3-9-5-released
• https://docs.spring.io/sts/nan/v395/NewAndNoteworthy.html

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)

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 );
 }
}

Details unter https://docs.gradle.org/4.6/release-notes.html

Infos unter http://wildfly.org/news/2018/02/28/WildFly12-Final-Released/. Wie auch Java 10 gibt es zeitbasierte Releasese: http://lists.jboss.org/pipermail/wildfly-dev/2017-December/006250.html.

Infos darüber unter https://netbeans.apache.org/download/nb90/index.html.

Allerdings frage ich mich, wer NB noch verwendet, ihr? Ich halte den NB-Zug für abgefahren. In den Insel kommen die Anmerkungen zu NB raus und IntelliJ stattdessen rein.

Die 9er Version kann kein Java 10, und die Entwickler freuen sich über Java 9-Support, wow, 1/2 Jahr nach dem Java 9 Release. In 2 Wochen kommt Java 10.

Präsentation und Code verlinkt unter https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database

Sehr spannend!

Siehe https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Release-Notes und https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide.

Es knarrzt an einigen Stellen, ich musste zum Beispiel meine CRUD-Implementierungen anpassen, die Methodennamen haben sich geändert. Wie sind eure Erfahrungen?

Das bedeutet, es gibt Syntaxerweiterungen, aber die sind erst mal zum Testen.

http://openjdk.java.net/jeps/12

An incubating language or VM feature is a new feature of the Java SE Platform that is fully specified, fully implemented, and yet impermanent. It is available in a JDK feature release to provoke developer feedback based on real world use; this may lead to it becoming permanent in a future Java SE Platform.

In der Mailliste fragen die Eclipse-Bauer schon nach, ob das verpflichtend ist … es wäre blöd, wenn man sich bei den JDT viel Mühe gibt, und dann wird das doch nicht übernommen: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000642.html

JEP-12 ist allerdings noch nicht bestätigt.