IntelliJ IDEA 2019.1 hits Beta

The upcoming IntelliJ IDEA 2019.1 goes Beta! To install IntelliJ IDEA 2019.1 Beta, download it from the website, update from our Toolbox App, or use a patch update.

The Beta builds are sufficiently stable compared to the EAP builds, but some issues may still occur. If they do for you, please report them to our issue tracker.

Since the opening of IntelliJ IDEA 2019.1 EAP, we’ve teased you with previews of the most notable changes to expect and this Beta stage seems to be a good time for an overview of some of the Java improvements that are coming your way in this next major version. Watch now.

Let’s take a more detailed look at a few of the big changes that are in this build.

Support for Java-style Lambda syntax of Groovy 3.0

Earlier in IntelliJ IDEA 2018.2, we added initial Groovy 3.0 support. With the upcoming IntelliJ IDEA 2019.1, we are taking it even further by supporting the experimental Groovy 3.0 feature highly anticipated by the Groovy developers – Java-style Lambda syntax.

IntelliJ IDEA now provides editing support including code completion, highlighting, and type inference.

Groovy intentions and inspections work properly inside the lambda body.

Now formatting is also available for Java-style lambdas. We’ve added a couple of specific new Java-style lambda options that can be found in Preferences Settings | Editor | Code Style | Groovy. On the ‘Wrapping and Braces’ tab, look for Braces placement | In lambda declaration and Keep when reformatting | Simple lambdas in one line. On the Spaces tab, we’ve added Around Operators | Lambda arrow.

That you can now debug Java-style lambdas should be useful, too.

So far we’re only getting started with supporting the Groovy 3.0 Java-style lambda syntax. We plan to extend this functionality in future releases of IntelliJ IDEA and add support for various refactorings.

Fixes linked with JetBrains Runtime 8

Last but not least, JetBrains Runtime 8 was updated to 1.8.0_202-release-1483-b31 and with this version we’ve fixed a few things like:

DPI detection which was broken on KDE in 8u202 was repaired: JBR-1200.

Windows native file dialogs with the new Common Item Dialog API was implemented: JBR-1216.

No, unfortunately we cannot position the caret to NullPointerException (NPE) cause, mostly because there’s no additional information and single line may have several NPE causes. On the other hand adding detailed message to NPE report is actively considered in OpenJDK now (see https://bugs.openjdk.java.net/browse/JDK-8218628 ). Thus it’s quite possible that additional information will be added in Java 13 or 14. If this happens we will use this information for precise caret position.

Gradle composite builds are _still_ totally broken. They have been since early in the EAP. I opened an issue and it was closed quite quickly with the information that the problem was caused by the Kotlin plugin.

When can we expect to see this fixed? Hopefully before final release? Surely gradle composite builds is a feature many people depend on, it can’t be that esoteric.