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)

Spring Retry

Das Spring Retry Projekt

Spring Retry ist ein Zusatzprojekt (https://github.com/spring-projects/spring-retry), um Codeblöcke wiederholt auszuführen, wenn sie zu einem Fehler führen.

  • Das ist nützlich beim Ansprechen von Remote-Diensten, die temporär nicht verfügbar sein können.

Als erstes müssen zwei Dependencies in unsere POM:

<dependency>
	<groupId>org.springframework.retry</groupId>
	<artifactId>spring-retry</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-aspects</artifactId>
</dependency>

@Retryable

Schreiben wir eine Bean, die zwei Anläufe braucht, eine Operation durchzuführen.

@Component
class Achiever {

  int tries = 1;

  @Retryable   
  public int tryIt() {   

    System.out.println( "Runde " + tries );
    tries++;

    if ( tries != 3 )
      throw new IllegalStateException( "Runde nicht 3" );

    return tries;
  }
}
Retryable drückt aus, das eine Operation bei Ausnahmen automatisch neu aufgerufen werden soll.
Die Methoden können eine Rückgabe haben, oder auch keine.

@EnableRetry

Damit Spring für die annotierten Methoden einen Proxy baut, müssen wir eine @Configuration mit @EnableRetry annotieren.

Wir können nun den Achiever injizieren:

@Autowired Achiever archiever;

Und die Methode ausführen:

System.out.println( "Vor dem Aufruf" );
int i = archiever.tryIt();
System.out.println( "Nach dem Aufruf ist i=" + i );

Auf der Konsole erscheint keine Exception. Nur:

Vor dem Aufruf
Runde 1
Runde 2
Nach dem Aufruf

Der Annotationsty Retryable

@Target({ ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Retryable {
	String interceptor() default "";
	Class<? extends Throwable>[] value() default {};
	Class<? extends Throwable>[] include() default {};
	Class<? extends Throwable>[] exclude() default {};
	String label() default "";
	boolean stateful() default false;
	int maxAttempts() default 3;              
	String maxAttemptsExpression() default "";
	Backoff backoff() default @Backoff();
	String exceptionExpression() default "";
}
Die Anzahl der Wiederholungen ist nicht unendlich, Spring stoppt standardmäßig bei 3.

Ausblick

Die Dokumentation unter https://github.com/spring-projects/spring-retry zeit weitere Möglichkeiten auf. Ein zusätzliches Beispiel:

@Retryable
public void tryIO() throws IOException {
  throw new IOException( LocalTime.now().toString() );
}

@Recover  
public void recover( IOException e ) {
  System.err.println( "Aarrrrg: " + e );
}
Die mit @Recover annotierte Methode wird am Ende einer nicht erfolgreichen Aufrufkette aufgerufen.

Caching in Spring Boot nutzen

Optimierung durch Caching

Bei Methoden, die idempotent sind, also zu einem Parameter immer den gleichen Wert liefern, kann Spring einen Cache zur Optimierung einsetzen.

  • Im Grunde ist der Cache ein Assoziativspeicher, der die Methodenparameter als Schlüssel nutzt.

Beispiele:

  • Berechnen einer Prüfsumme
  • Dateiinhalt
  • DNS-Cache

Achtung: Gewisse Cache-Inhalte können nach einer Zeit ungültig werden.

Caching in Spring

Um das Caching zu aktivieren annotiert man

  1. eine @Configuration mit @EnableCaching
  2. eine public (!!!) Methode mit @Cacheable und vergibt einen Cache-Namen.

@Cacheable-Beispiel (1/2)

@Component
class Hash {

  @Cacheable( "md5" )
  public byte[] md5( String text ) {

    System.out.println( "hash: " + text );
    try {
      MessageDigest md = MessageDigest.getInstance( "MD5" );
      return md.digest( text.getBytes( StandardCharsets.UTF_8 ) );
    }
    catch ( NoSuchAlgorithmException e ) {
      throw new IllegalStateException( e );
    }
  }
}

@Cacheable-Beispiel (2/2)

Wir können Hash injizieren

@Autowired
Hash hash;

und nutzen

byte[] md5_1 = hash.md5( "tutego" );
byte[] md5_2 = hash.md5( "tutego" );
System.out.println( Arrays.equals( md5_1, md5_2 ) ); // true

System.out.println( hash.getClass() ); // com.tutego.boot.basic.Hash$$EnhancerBySpringCGLIB$$4548965

Ausblick (1/2)

  • Spring generiert den Schlüssel zum Cache aus den Argumente. Man kann kann eigene KeyGenerator en verwenden.
  • Mit der SpEL lassen sich von Anfrageobejkte zum Beispiel die Schlüssel erfragen, etwa so @Cacheable(cacheNames="books", key="#isbn.rawNumber") .
  • Unter Umständen sollen große Objekte nicht in den Cache, hier kann man eine Bedingung angeben: @Cacheable(cacheNames="book", condition="#name.length() < 32")
  • Ist eine Methode mit @CachePut annotiert, kann man den Cache selbst füllen, bzw. Werte überschreiben.
  • Ist eine Methode mit @CacheEvict annotiert, etwa @CacheEvict(cacheNames="books", allEntries=true) public void clear() wird der Cache gelöscht.

Ausblick (2/2)

Das Spring Framework kann automatisch diverse Caching-Implementierung nutzen.

  • Standardmäßig ist es eine ConcurrentHashMap.
  • Unterstützt werden u.a.: EhCache 2.x, Hazelcast, Infinispan, Couchbase, Redis, Caffeine.
  • Spring erkennt anhand des Eintrags im Klassenpfad, was gewünscht ist.

In der application.[properties|yml] lassen sich dann Dinge wie Lebensdauer, Größe, etc. extern konfigurieren.

JMX in Spring Boot nutzen

Die Java Management Extensions (JMX)

  • Die Java Management Extensions (JMX) ist eine Spezifikation zur Verwaltung und Überwachung von Java-Anwendungen.
  • Teile der JMX Spezifikation sind ab Java 5 in der Java SE integriert.
  • Es gibt einen JMX Agent, an dem Managed Beans angemeldet werden.
  • Von außen lassen sich diese Managed Beans erfragen.
  • JConsole ist ein GUI-Programm im JDK, das zur Verwaltung von MBeans verwendet werden kann.

JMX in Spring Boot

Spring nutzt drei Annotationen, um Managed Beans mit ihren Zuständen und Operationen beim JMX Agent zu registrieren:

@ManagedResource
Definiert mit der Typ-Annotation die Managed Bean
@ManagedAttribute
Definiert ein Attribut (Setter/Getter)
@ManagedOperation
Definiert eine Operation

Beispiel-Managed-Bean

package com.tutego.boot.actuator;

import java.util.HashMap;
import java.util.Map;
import org.springframework.jmx.export.annotation.ManagedAttribute;
import org.springframework.jmx.export.annotation.ManagedOperation;
import org.springframework.jmx.export.annotation.ManagedResource;
import org.springframework.stereotype.Component;

@Component
@ManagedResource
public class StringMapManagedBean {
  private final Map<String, String> map = new HashMap<>();

  @ManagedAttribute
  public int getSize() {
    return map.size();
  }

  @ManagedOperation
  public String get( String key ) {
    return map.get( key );
  }


  @ManagedOperation
  public String put( String key, String value ) {
    return map.put( key, value );
  }

  public void remove( String key ) {
    map.remove( key );
  }
}

Annotationstyp @ManagedResource

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface ManagedResource {

	@AliasFor("objectName")
	String value() default "";

	@AliasFor("value")
	String objectName() default "";

	String description() default "";

	int currencyTimeLimit() default -1;
	boolean log() default false;
	String logFile() default "";
	String persistPolicy() default "";
	int persistPeriod() default -1;
	String persistName() default "";
	String persistLocation() default "";
}

Springs eigene Managed Beans

Spring Boot veröffentlicht selbst diverse Managed Beans unter der Domäne org.springframework.boot.

  • org.springframework.boot:type=Endpoint,name=Health zum Beispiel für die Gesundheitsinformationen

Sie lassen sich abschalten mit management.endpoints.jmx.exposure.exclude=*.

Falls mehrere ApplicationContext exisistieren kommt es zum Namenskonflikt; der lässt sich mit management.endpoints.jmx.unique-names=true vermeiden.

Der Domain-Name lässt sich anpassen mit management.endpoints.jmx.domain.

JavaFX fliegt aus dem JDK

So schreibt es Oracle unter https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

Starting with JDK 11, Oracle is making JavaFX easier to adopt by making the technology available as a separate download, decoupled from the JDK. These changes clear the way for new contributors to engage in the open source OpenJFX community. Meanwhile, Oracle customers can benefit from continued commercial support for JavaFX in the Oracle JDK 8 through at least 2022.

With the Java Platform Module System in place since Java SE 9, it now more viable to decouple JavaFX from the JDK, in order to make it available as a separate download.  This will make it easier for developers using JavaFX to have more freedom and flexibility with the framework.  Moreover, with our focus on increasing the release cadence of OpenJDK, JavaFX needs to be able to move forward at a pace driven by the contributions from Oracle and others in the OpenJFX community. Oracle plans to implement this decoupling starting with Java 11 (18.9 LTS).

Warum ein Lambda-Ausdruck keine lokale Variablen/Parametervariablen beschreiben kann

Lambda-Ausdrücke können lokale Variablen nur lesen und nicht beschreiben. Der Grund hat etwas mit der Art und Weise zu tun, wo Variablen gespeichert werden: Objekt- und statische Variablen „leben“ auf dem Heap lokale Variablen und Parameter „leben“ auf dem Stack. Wenn nun Threads ins Spiel kommen ist es nicht unüblich, dass unterschiedliche Threads die Variablen vom Heap nutzen; dafür gibt es Synchronisationsmöglichkeiten. Allerdings kann ein Thread nicht auf lokale Variablen eines anderen Threads zugreifen, denn ein Thread hat erst einmal keinen Zugriff auf den Stack-Speicher eines anderen Threads. Grundsätzlich wäre das möglich, allerdings wollten die Oracle-Entwickler diesen Pfad nicht gehen. Beim Lesezugriff wird tatsächlich eine Kopie angelegt, sodass sie für einen anderen Thread sichtbar ist.

Die Einschränkung, dass äußere lokale Variablen von Lambda-Ausdrücken nur gelesen werden können, ist an sich etwas Gutes, denn die Beschränkung minimiert Fehler bei nebenläufiger Ausführung von Lambda-Ausdrücken: arbeiten mehrere Threads Lambda-Ausdrücke ab, und beschreiben diese eine lokale Variable, müsste andernfalls eine Thread-Synchronisation her.

Grundsätzlich verbietet das Schreiben von lokalen Variablen aus Lambda-Ausdrücken heraus aber nicht jede Programmiersprache. In C# kann ein Lambda-Ausdruck lokale Variablen beschreiben, sie leben dann nicht mehr auf dem Stack.

CompletionService und ExecutorCompletionService

Die invokeAll(…)-Methoden aus dem ExecutorService sind praktisch, wenn es darum geht, mehrere Aufgaben nebenläufig abzusenden, und später die Ergebnisse einzusammeln. Allerdings ist die Rückgabe vom Typ List<Future<T>> und wir werden nicht informiert, wenn ein Ergebnis vorliegt. Wir können zwar die Liste immer wieder ablaufen und jedes Future-Objekte mit isDone() fragen ob es fertig ist, aber das ist keine ideale Lösung.

Mit java.util.concurrent.CompletionService gibt es eine weitere Java-Schnittstelle – die keinen Basistyp erweitert – mit der wir ein Callable oder Runnable arbeiteten lassen können und später nacheinander die Ergebnisse einsammeln können, die fertig sind. Die Java-Bibliothek bringt mit ExecutorCompletionService eine Implementierung der Schnittstelle mit, die intern die fertigen Ergebnisse in einer Queue sammelt, und wir können die Queue abfragen. Schauen wir uns das in einem Beispiel an.

ExecutorService executor = Executors.newCachedThreadPool();

CompletionService<Integer> completionService =

  new ExecutorCompletionService<>( executor );

List.of( 4, 3, 2, 1 ).forEach( duration -> completionService.submit( () -> {

  TimeUnit.SECONDS.sleep( duration );

  return duration;

} ) );



for ( int i = 0; i < 4; i++ ) {

  try {

    System.out.println( completionService.take().get() );

  }

  catch ( InterruptedException | ExecutionException e ) {

    e.printStackTrace();

  }

}

executor.shutdown();

Der Typ ExecutorCompletionService erwartet im Konstruktor einen Executor, der den Code ausführen soll; wir setzen einen Thread-Pool ein. CompletionService hat zwei submit(…)-Methoden:

  • Future<V> submit​(Runnable task, V result)
  • Future<V> submit​(Callable<V> task)

Abgesendet werden vier Callable-Exemplare, die 4, 3, 2, 1 Sekunden warten und ihre Wartezeit am Ende zurückgeben. Natürlich wird als erstes das Callable mit der Rückgabe 1 fertig, dann 2, usw.

Für die Rückgaben interessiert sich unser Programm nicht, denn es nutzt die take()-Methode. Insgesamt hat CompletionService drei Entnahme-Methoden:

  • Future<V> take()
    Liefert das Ergebnis von der ersten abgeschlossenen Aufgabe und entfernt es von der internen Queue. Liegt kein Ergebnis an, wartet die Methode.
  • Future<V> poll()
    Liefert das Ergebnis von der ersten abgeschlossenen Aufgabe und entfernt es von der internen Queue. Liegt kein Ergebnis ist, wartet poll() nicht, sondern liefert null.
  • Future<V> poll​(long timeout, TimeUnit unit)
    Wartet wir take() auf ein Ergebnis, doch kommt es nach dem Ablauf von timeout nicht, liefert die Methode wie poll() als Rückgabe null.

Was der Schnittstelle fehlt ist eine Methode, die die verblendende Anzahl liefert. Wir müssen in unserem Code daher einen Zähler als extra Variable einführen.

Warum Properties extends Hashtable<Object, Object> und nicht Hashtable<String, String>?

Von der Intuition her ist von der Vererbung class Properties extends Hashtable<String, String> naheliegend, doch hat Sun nicht gewollt. Der Grund hat gar nicht so sehr mit Properties selbst zu tun, sondern mit der Basisklasse Hashtable und gewählten Umsetzung der Generics und der gewünschten Kompatibilität. Von Java 1.0 bis Java 1.4 hat die Klasse Hashtable eine Methode put(Object, Object). Ab Java 5 wird Object durch generische Typparameter ersetzt, sodass es in Hashtable heißt: put(K, V). Wenn nun Properties extends Hashtable<String,String> ist, dann wird die Hinzufügemethode zu put(String, Sting). Das wäre nicht mehr kompatibel zu put(Object, Object) vor Java 5. Also haben die Sun-Entwickler Properties extends Hashtable<Object, Object> geschrieben, auch wenn die put(…)-Methode überhaupt nicht verwendet werden soll, sondern setProperty(…). Da Generics nur ein „Trick“ des Compilers sind, lässt sich über den Raw-Typ tricksen:

Properties props = new Properties();

@SuppressWarnings( {"rawtypes", "unchecked"} )

Map<String, String> map = (Map) props;

Iterator vom Stream besorgen

Sich einen Iterator von einem Stream geben zu lassen ist nützlich, weil dann der Zeitpunkt des Konsumierens vom Zeitpunkt des Stream-Aufbaus getrennt werden kann. Es ist nicht einfach mehrere Streams gleichzeitig abzulaufen, doch mit Iteratoren funktioniert das. Zudem lässt sich in Stream mit einer Generator-Funktion einfach aufbauen, in Iterator aber nicht.

Beispiel: Aus zwei Streams sollen jeweils alterrnierend das nächste Element konsumiert und ausgegeben werden.

Iterator<Integer> iterator1 = Stream.of( 1, 3, 5 ).iterator();

Iterator<Integer> iterator2 = Stream.of( 2, 4, 6, 7, 8 ).iterator();




while ( iterator1.hasNext() || iterator2.hasNext() ) {

  if ( iterator1.hasNext() )

    System.out.println( iterator1.next() );

  if ( iterator2.hasNext() )

    System.out.println( iterator2.next() );

}

Iterator ist ein Datentyp, der häufig in der Rückgabe verwendet wird, seltener als Parametertyp. Mit stream.iterator() ist es aber möglich, die Daten vom Stream genau an solchen Stellen zu übergeben. Einen Stream in einen Iterator zu konvertieren, um diesen dann mit hasNext()/next() abzulaufen, ist wenig sinnvoll, hierfür bietet sich genauso gut forEach(…) auf dem Stream an.

Stream ist nicht Iterable

Der Typ Stream bietet eine Methode iterator(), erweitert jedoch die Schnittstelle Iterable nicht. In der Javadoc ist bei iterator() die Bemerkung „terminale Operation“ vermerkt, denn der Iterator saugt den Stream leer, sodass ein zweiter iterator()-Aufruf auf einem Stream nicht möglich ist. Bei Klassen, die Iterable implementieren, muss ein Aufruf von iterator() beliebig oft möglich sein. Bei Streams ist das nicht gegeben, da die Streams selbst nicht für die Daten stehen wie eine Collection, die daher Iterable ist.

Iterator in Stream umwandeln

Ist auf der anderen Seite ein Iterator gegeben, lässt sich dieser nicht direkt in einen Stream bringen. Iteratoren können wie Streams unendlich sein, und es gibt keinen Weg, die Daten eines Iterators als Quelle zu benutzen. Natürlich ist es möglich, den Iterator abzulaufen und daraus einen neuen Stream aufzubauen, dann muss der Iterator aber endlich sein.

Beispiel: Die Methode ImageIO.getImageReadersBySuffix(String) liefert einen Iterator von ImageReader-Objekten – sie sollen über einen Strom zugänglich sein:

Builder<ImageReader> builder = Stream.builder();
 for ( Iterator<ImageReader> iter = ImageIO.getImageReadersBySuffix( "jpg" );
       iter.hasNext(); )
   builder.add( iter.next() );
 Stream<ImageReader> stream = builder.build();
 System.out.println( stream.count() );    // 1

Einen anderen Weg geht StreamSupport.

Ist eine alte Enumeration gegeben, hilft Collections.list(enumeration).stream(), denn list(…) liefert eine ArrayList mit allen Einträgen; list(Iterator) gibt es da hingegen nicht.

iterator() von BaseStream und PrimitiveIterator.OfXXX

Die Schnittstelle Stream deklariert keine abstrakte iterator()-Methode, sondern bekommt die Methode vom Obertyp BaseStream vererbt. BaseStream ist insgesamt Basistyp von:

  • Stream<T>, DoubleStream, IntStream, LongStream

Alle diese drei Typen haben damit iterator()-Methdoden, doch die Rückgaben sind unterschiedlich:

Typ iterator()-Methdoden und Rückgabe
Stream<T> Iterator<T> iterator()
DoubleStream PrimitiveIterator.OfDouble iterator()
IntStream PrimitiveIterator.OfInt iterator()
LongStream PrimitiveIterator.OfInt iterator()

Unterschiedliche Rückgaben der Iteratoren

PrimitiveIterator ist eine Schnittstelle aus dem Paket java.util mit eben drei inneren statischen Schnittstellen: OfDouble, OfInt und OfLong, die PrimitiveIterator erweiten. Jeder dieser drei inneren Typen hat eigene, aber symmetrische Methoden:

  • default void forEachRemaining(Consumer<? super WrapperTyp> action)
  • default void forEachRemaining(WrapperTypConsumer action)
  • default WrapperTyp next()
  • PrimitiverTyp nextPrimitiverTyp()

Statt WrapperTyp und PrimitiverTyp ist dann Double, Integer, Long und double, int, double einzusetzen.

Beispiel: Ein vom Stream abgeleiter Iterator besorgt Zahlen. Diese werden in einem anderen Stream eingesetzt.

PrimitiveIterator.OfInt counter =

  IntStream.iterate( 1, Math::incrementExact ).iterator();

Stream.of( "Telegram", "WhatsApp", "Facebook Messenger", "Insta" )

      .map( s -> counter.nextInt() + ". " + s )

      .forEach( System.out::println );

jdk-11-ea+2 freigegeben

Die größte Änderung ist, was angekündigt wurde:

These builds include JEP 320 (Remove the Java EE and CORBA Modules) [1],
so they're significantly smaller (nine fewer modules, 22 fewer megabytes
on Linux/x64).

- Mark

Weitere Infos und Download unter http://jdk.java.net/11/. Folgende Änderungen gibt es:

Changeset Bug ID Synopsis
d9fce53461a1 8197812 (ref) Data race in Finalizer
c38163717870 8198227 Fix COMPARE_BUILD after forest consolidation
329428e095b6 8198306 Add post custom extension hooks to two launchers
67cdc215ed70 8198228 Spec clarification: j.u.Locale.getDisplayName()
edaa989b4e67 8058965 Remove IPv6 support from TwoStacksPlainSocketImpl [win]
01237b276b8b 8198318 Make build comparisons clean again
7f9c3cd11e97 8170120 jimage throws IOException when the given file is not a jimage file
0a185d6fafa1 8198379 tools/jimage/JImageListTest.java failing
b417304c811b 8198380 tools/jimage/JImageExtractTest.java failing
42cec55157fa 8198417 Exclude tools/jimage/JImageExtractTest.java and tools/jimage/JImageListTest.java on Windows
37beaca49e63 8194922 jlink –exclude-resources should never exclude module-info.class
18debf414948 8198425 make/Main.gmk Add extra extension/override points to the make file
c7e84c0a51c3 8198328 Create devkit for Solaris with developer studio 12.6 and Solaris11.3
916690b5edc9 8194892 add compiler support for local-variable syntax for lambda parameters
576e024f10b6 8198418 Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker
906025796009 8198441 Replace native Runtime::runFinalization0 method with shared secrets
b75c9e2e3b1f 8198450 Make jdk.internal.vm.compiler/module-info.java.extra reproducable
1913e7fc6be9 8198301 jdk11+1 was built as ‚fcs‘ instead of ‚ea‘
b2bba53b079d 8198303 jdk11+1 was build with incorrect GA date as 2018-03-20
02404e27d356 8198479 JDK build is broken by 8194892
847a988152b8 8194154 System property user.dir should not be changed
cc30928a834e 8198385 Remove property sun.locale.formatasdefault
28d8fc8cd3cd 8190904 Incorrect currency instance returned by java.util.Currency.getInstance()
b1a5b4ad7427 8198523 Refactor BootstrapMethodInvoker to further avoid runtime type checks
b25eb74ec283 8197439 Crash with -XDfind=lambda for anonymous class in anonymous class.
9e3f2ec326ba 8198502 Exception at runtime due to lambda analyzer reattributes live AST
20358c9f72c1 8198563 Test langtools/tools/javac/analyzer/AnonymousInAnonymous.java failing after JDK-8198502
03ae177c26b0 8198512 compiler support for local-variable syntax for lambda parameters

Release Notes Since build 1  Integrations

core-libs/java.util.concurrent

 ThreadPoolExecutor should not specify a dependency on finalizationPrevious versions of ThreadPoolExecutor had a finalize method that shut down the thread pool, but in this version the finalize method does nothing. This should have no visible effect unless a subclass explicitly invokes the finalize method and relies on the executor being shutdown.

security-libs/java.security

 jarsigner should print when a timestamp will expireThe jarsigner tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year.