Alle Beiträge von Christian Ullenboom

Über Christian Ullenboom

Ich bin Christian Ullenboom und Autor der Bücher ›Java ist auch eine Insel. Einführung, Ausbildung, Praxis‹ und ›Java SE 8 Standard-Bibliothek. Das Handbuch für Java-Entwickler‹. Seit 1997 berate ich Unternehmen im Einsatz von Java. Sun ernannte mich 2005 zum ›Java-Champion‹.

Hystrix wird nicht weiterentwickelt bleibt in „maintenance mode“

So schreibt es https://github.com/Netflix/Hystrix:

Hystrix is no longer in active development, and is currently in maintenance mode.

Hystrix (at version 1.5.18) is stable enough to meet the needs of Netflix for our existing applications. Meanwhile, our focus has shifted towards more adaptive implementations that react to an application’s real time performance rather than pre-configured settings (for example, through adaptive concurrency limits). For the cases where something like Hystrix makes sense, we intend to continue using Hystrix for existing applications, and to leverage open and active projects like resilience4j for new internal projects. We are beginning to recommend others do the same.

Netflix Hystrix is now officially in maintenance mode, with the following expectations to the greater community: Netflix will no longer actively review issues, merge pull-requests, and release new versions of Hystrix. We have made a final release of Hystrix (1.5.18) per issue 1891 so that the latest version in Maven Central is aligned with the last known stable version used internally at Netflix (1.5.11). If members of the community are interested in taking ownership of Hystrix and moving it back into active mode, please reach out to hystrixoss@googlegroups.com.

Java/Boot/JavaScript-Seminare für Q1/2019

tutego Schulungsraum


Java Grundlagen (›JAVA1‹)

7.–11. Januar 2019 (KW 2), 21.–25. Januar 2019 (KW 4), 28. Januar–1. Februar 2019 (KW 5), 18.–22. Februar 2019 (KW 8), 11.–15. März 2019 (KW 11), 25.–29. März 2019 (KW 13), 8.–12. April 2019 (KW 15)


Java für Fortgeschrittene (›JAVA2‹)

26.–30. November 2018 (KW 48), 7.–11. Januar 2019 (KW 2), 21.–25. Januar 2019 (KW 4), 28. Januar–1. Februar 2019 (KW 5), 18.–22. Februar 2019 (KW 8), 11.–15. März 2019 (KW 11), 25.–29. März 2019 (KW 13), 8.–12. April 2019 (KW 15)


Spring Boot (›SPRINGBOOT‹)

3.–5. Dezember 2018 (KW 49), 7.–9. Januar 2019 (KW 2), 21.–23. Januar 2019 (KW 4), 28.–30. Januar 2019 (KW 5), 18.–20. Februar 2019 (KW 8), 11.–13. März 2019 (KW 11), 25.–27. März 2019 (KW 13), 8.–10. April 2019 (KW 15), 24.–26. April 2019 (KW 17)


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

3.–5. Dezember 2018 (KW 49), 7.–11. Januar 2019 (KW 2), 21.–25. Januar 2019 (KW 4), 28. Januar–1. Februar 2019 (KW 5), 18.–22. Februar 2019 (KW 8), 11.–15. März 2019 (KW 11), 25.–29. März 2019 (KW 13), 8.–12. April 2019 (KW 15)

 

Diamant vs. var

Diamant und var haben vergleichbare Aufgaben, unterscheiden sich aber durch die Quelle der Informationen. Beim Diamanten ist es zum Beispiel bei einer Zuweisung die linke Seite, die dem Compiler die Information gibt, was auf der rechten Seite der Zuweisung für ein Typ gemeint ist. Bei var wiederum ist das anderes herum: die rechte Seite hat den Kontext und daher kann links der Variablentyp entfallen:

List<String> list1 = new ArrayList<>();  // List<String>

var list2 = new ArrayList<String>();     // ArrayList<String>

var list3 = new ArrayList<>();           // ArrayList<Object>

Im letzten Fall gibt es keinen Compilerfehler, nur ist eben nichts bekannt über das Typargument, und daher gilt Object.

Um Code abzukürzen haben wir damit zwei Möglichkeiten: var oder Diamond.

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)

Java 11 ist draußen

Download unter

  • https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html
  • http://jdk.java.net/11

Unter http://www.tutego.de/java/java-se-11-oracle-jdk-11-openjdk_11_java_18.9.html fasse ich die Neuerungen kompakt zusammen.

Hier im Blog gibt es die Kategorie http://www.tutego.de/blog/javainsel/category/java-11/ für alle Neuerungen in Java 11. Das geht in der Regel ins Buch.

Heise hat eine Java 11-Launch-Session aufgenommen: https://www.youtube.com/watch?v=CUuCVHWeO-Y

Klassenlader

Ein Klassenlader ist dafür verantwortlich, die Binärrepräsentation einer Klasse aus einem Hintergrundspeicher oder Hauptspeicher zu laden. Aus der Datenquelle (im Allgemeinen die .class-Datei) liefert der Klassenlader ein Byte-Array mit den Informationen, die im zweiten Schritt dazu verwendet werden, die Klasse ins Laufzeitsystem einzubringen; das ist Linking. Es gibt vordefinierte Klassenlader und die Möglichkeit, eigene Klassenlader zu schreiben, um etwa verschlüsselte vom Netzwerk zu beziehen oder komprimierte .class-Dateien aus Datenbanken zu laden.

Klassenladen auf Abruf

Nehmen wir zu Beginn ein einfaches Programm mit drei Klassen:

package com.tutego.insel.tool;

 

public class HambachForest {

public static void main( String[] args ) {

boolean rweWantsToCutTrees = true;

Forrest hambachForest = new Forrest();

if ( rweWantsToCutTrees ) {

Protest<Forrest> p1 = new Protest<>();

p1.believeIn = hambachForest;

}

}

}

 

class Forrest { }

 

class Protest<T> {

T believeIn;

java.time.LocalDate since;

}

Wenn die Laufzeitumgebung das Programm HambachForest startet, muss sie eine Reihe von Klassen laden. Das tut sie dynamisch zur Laufzeit. Sofort wird klar, dass es zumindest HambachForest sein muss. Und da die JVM die statische main(String[])-Methode aufruft und Optionen übergibt, muss auch String geladen sein. Unsichtbar stecken noch andere referenzierte Klassen dahinter, die nicht direkt sichtbar sind. So wird zum Beispiel Object geladen, da implizit in der Klassendeklaration von HambachForest steht: class HambachForest extends Object. Intern ziehen die Typen viele weitere Typen nach sich. String implementiert Serializable, CharSequence und Comparable, also müssen diese drei Schnittstellen auch geladen werden. Und so geht das weiter, je nachdem, welche Programmpfade abgelaufen werden. Wichtig ist aber, zu verstehen, dass diese Klassendateien so spät wie möglich geladen werden.

Klassenlader bei der Arbeit zusehen

Im Beispiel lädt die Laufzeitumgebung selbstständig die Klassen (implizites Klassenladen). Klassen lassen sich auch mit Class.forName(String) über ihren Namen laden (explizites Klassenladen).

Um zu sehen, welche Klassen überhaupt geladen werden, lässt sich der virtuellen Maschine beim Start der Laufzeitumgebung ein Schalter mitgeben: -verbose:class. Dann gibt die Maschine beim Lauf alle Typen aus, die sie lädt. Nehmen wir das Beispiel von eben, so ist die Ausgabe mit dem aktivierten Schalter unter Java 11 fast 500 Zeilen lang; ein Ausschnitt:

$ java -verbose:class com.tutego.insel.tool.HambachForest

[0.010s][info][class,load] opened: C:\Program Files\Java\jdk-11\lib\modules

[0.032s][info][class,load] java.lang.Object source: jrt:/java.base

[0.032s][info][class,load] java.io.Serializable source: jrt:/java.base

[0.033s][info][class,load] java.lang.Comparable source: jrt:/java.base

[0.036s][info][class,load] java.lang.CharSequence source: jrt:/java.base

[0.037s][info][class,load] java.lang.String source: jrt:/java.base

[0.684s][info][class,load] sun.security.util.Debug source: jrt:/java.base

[0.685s][info][class,load] com.tutego.insel.tool.HambachForest source: file:/C:/Inselprogramme/target/classes/

[0.687s][info][class,load] java.lang.PublicMethods$MethodList source: jrt:/java.base

[0.687s][info][class,load] java.lang.PublicMethods$Key source: jrt:/java.base

[0.689s][info][class,load] java.lang.Void source: jrt:/java.base

[0.690s][info][class,load] com.tutego.insel.tool.Forrest source: file:/C:/Inselprogramme/target/classes/

[0.691s][info][class,load] jdk.internal.misc.TerminatingThreadLocal$1 source: jrt:/java.base

[0.692s][info][class,load] java.lang.Shutdown source: jrt:/java.base

[0.692s][info][class,load] java.lang.Shutdown$Lock source: jrt:/java.base

Ändern wir die Variable rweWantsToCutTrees auf true, so wird unsere Klasse Protest geladen, und in der Ausgabe kommt nur eine Zeile hinzu! Das wundert auf den ersten Blick, denn die Klasse referenziert LocalDate. Doch ein LocalDate wird nicht benötigt, also auch nicht geladen. Der Klassenlader bezieht nur Klassen, wenn die für den Programmablauf benötigt werden, nicht aber durch die reine Deklaration als Attribut. Wenn wir LocalDate mit zum Beispiel LocalDate.now() initialisieren kommen stattliche 200 Klassendateien hinzu.

Eclipse 4.9 (2018-09) ist fertig, Spring Tool Suite 3.9.6 setzt sofort drauf auf

Heise schreibt recht gut darüber: https://www.heise.de/developer/meldung/Entwicklungsumgebung-Eclipse-Auf-Photon-folgt-2018-09-4168224.html. Leider ist noch ein Java 11-Plugin nötig, so muss ich das im kommenden Java 11-Buch auch extra mit einführen.

Zur STS-Ankündigung: https://spring.io/blog/2018/09/20/spring-tool-suite-3-9-6-released, https://docs.spring.io/sts/nan/v396/NewAndNoteworthy.html

 

Weißraum entfernen

In einer Benutzereingabe oder Konfigurationsdatei steht nicht selten vor oder hinter dem wichtigen Teil eines Textes Weißraum wie Leerzeichen oder Tabulatoren. Vor der Bearbeitung sollten sie entfernt werden. Die String-Klasse bietet dazu trim() und seit Java 11 strip(), stripLeading() und stripTrailing() an. Der Unterschied:

Methode Entfernt …
trim() … am Anfang und am Ende des Strings alle Codepoints kleiner oder gleich dem Leerzeichen ‚U+0020‘
strip() … alle Zeichen am Anfang und am Ende des Strings, die nach der Definition von Character.isWhitespace(int) Leerzeichen sind
stripLeading() … wie strip(), allerdings nur am Anfang des Strings
stripTrailing() … wie strip(), allerdings nur am Ende des Strings

Unterschiede von trim() und stripXXX()

Alle vier Methoden entfernen keinen Weißraum inmitten des Strings.

Beispiel: Entferne Leer- und ähnliche Füllzeichen am Anfang und Ende eines Strings:

String s = “ \tSprich zu der Hand.\n  \t „;
System.out.println( „‚“ + s.trim() + „‚“ ); // ‚Sprich zu der Hand.‘

 

Beispiel: Teste, ob ein String mit Abzug allen Weißraums leer ist:

boolean isBlank = „“.equals( s.trim() );

Alternativ:

boolean isBlank = s.trim().isEmpty();

Strings aus Wiederholungen generieren

In Java 11 ist eine Objektmethode repeat(int count) eingezogen, die einen gegeben String vervielfacht.

Beispiel: Wiederhole den String s dreimal:

String s = „tu“;

System.out.println( s.repeat( 3 ) );    // tututu

Bevor es die Methode in Java 11 gab, sah eine alternative Lösung etwa so aus:

int    n = 3;
String t = new String( new char[ n ] ).replace( „\0“, s );
System.out.println( t );                // tututu

String-Länge und Test auf Leer-String

String-Objekte verwalten intern die Zeichenreihe, die sie repräsentieren, und bieten eine Vielzahl von Methoden, um die Eigenschaften des Objekts preiszugeben. Eine Methode haben wir schon benutzt: length(). Für String-Objekte ist sie so implementiert, dass sie die Anzahl der Zeichen im String (die Länge des Strings) zurückgibt. Um herauszufinden, ob der String keine Zeichen hat, lässt sich neben length() == 0 auch die Methode isEmpty() nutzen. In Java 11 ist die Methode isBlank() hinzugekommen, die testet, ob der String leer ist, oder nur aus Weißraum besteht; Weißraum ist jedes Zeichen, bei dem Character.isWhitespace(int) wahr anzeigt.

Anweisung Ergebnis
„“.length() 0
„“.isEmpty() true
“ „.length() 1
“ „.isEmpty() false
“ „.isBlank() true
String s = null; s.length(); NullPointerException

Tabelle 1.1: Ergebnisse der Methoden length(), isEmpty() und isBlank()

Vom Zeichen zum String

Um ein Unicode-Zeichen ein einen String zu konvertieren können wir die statische überladene String-Methode valueOf(char) nutzen. Eine vergleichbare Methode gibt es auch in Character, und zwar die statische Methode toString(char). Beide Methoden haben die Einschränkung, dass das Unicode-Zeichen nur 2 Byte lang sein kann. String deklariert dafür auch valueOfCodePoint(int). So eine Methode fehlte bisher in Character; erst in Java 11 ist toString(int) eingezogen; intern delegiert sie an valueOfCodePoint(int).