Achtung!

IntelliJ IDEA 2016.1 verbessert Code-Assists für Java 8

7. April 2016 Dominik Mohilo

Es ist ziemlich genau zwei Jahre her, seit Java 8 veröffentlicht wurde. Mittlerweile haben fast alle Frameworks und Plattformen ihre APIs vollständig auf die aktuellste Version der Programmiersprache eingestellt. IntelliJ IDEA und die gesamte Plattform dahinter sind mit Version 2016.1 auf Java 8 migriert, das hat auch die Programmierassistenz verbessert.

Java-Entwickler, die die Tools von JetBrains – insbesondere die IntelliJ IDEA 2016.1 – verwenden, können sich freuen. Mit Java 8 wurden einige neue Features veröffentlicht, die nun auch in der Entwicklungsumgebung von JetBrains uneingeschränkt nutzbar sind. Dies gilt natürlich auch für die Entwickler von Plug-ins für die IDE. Diese Umstellung haben die Macher der IntelliJ IDEA 2016.1 zum Anlass genommen, die Coding-Assistenz ihrer Entwicklungsumgebung zu verbessern.

Der falsche Gebrauch von java.util.Optional

Eine Reihe von Warnungen, die das Schreiben von unsicherem Code vermeiden sollen, wurde für die Verwendung von java.util.Optional eingebaut. Wird get() gecallt, ohne vorher mit isPresent() die Verfügbarkeit des Wertes zu prüfen, wird eine eine Warnung ausgesprochen.

Warnung bei der Verwendung von get() / Quelle: JetBrains Blog

Weitere Warnungen erscheinen, wenn man java.util.Optional<T>, java.util.OptionalDouble, java.util.OptionalLong oder com.google.common.base.Optional als Type für ein Feld oder einen Parameter nutzen möchte. Will man java.util.Optional– oder com.google.common.base.Optional–Types mit einem Array oder Collection–Type-Parameter verwenden, wird ebenfalls eine Warnung ausgesprochen. Diese Warnungen sind standardmäßig deaktiviert.

Funktionale Interfaces

Statt einer Method Reference empfiehlt IntelliJ IDEA nun einen Qualifier, wenn die Method Reference auf eine Method des eigenen Types des funktionalen Interfaces verweist. Es wird außerdem eine Warnung ausgegeben, wenn eine Method eines funktionalen Interfaces gecallt wird, die sich direkt auf eine Lambda-Definition, eine Method Reference oder eine anonyme Klasse bezieht.

Überladene Methods oder Constructors mit den gleichen Type-Parametern des funktionalen Interfaces werden nun ebenfalls gemeldet. Um die Mehrdeutigkeit dieser zu beheben, müssen für jede Call-Seite Parameter- oder Cast–Types in der Lambda Expression spezifiziert werden.

Eine Überladene Method / Quelle: JetBrains Blog

Guava

Wer seinen Guava-Code für APIs von Java 8 fit machen will, für den bringt das aktuelle Update von IntelliJ IDEA einige Quick-Fixes. Diese helfen dabei, FluentIterable, Function, Optional und Predicate durch die Entsprechungen in Java 8 zu ersetzen.

Mehr Beispielbilder finden sich im zugehörigen Blog-Eintrag von Andrey Cheptsov, Feedback kann entweder dort als Kommentar oder direkt im Tracker von JetBrains abgegeben werden.