New features in Red Hat CodeReady Studio 12.15.0.GA and JBoss Tools 4.15.0.Final for Eclipse 2020-03

JBoss Tools 4.15.0 and Red Hat CodeReady Studio 12.15 for Eclipse 4.15 (2020-03) are now available. For this release, we focused on improving Quarkus and container-based development and fixing bugs. We also updated the Hibernate Tools runtime provider and Java Developer Tools (JDT) extensions, which are now compatible with Java 14. Additionally, we made many UI changes to platform views, dialogs, and toolbars.

Installation

First, let's look at how to install these updates. CodeReady Studio (previously Red Hat Developer Studio) comes with everything pre-bundled in its installer. Simply download the installer from the Red Hat CodeReady Studio product page and run it as follows:

$ java -jar codereadystudio-<installername>.jar

On the other hand, installing JBoss Tools 4.15.0—aka "bring-your-own Eclipse (BYOE) CodeReady Studio"—requires a bit more effort. This release requires at least Eclipse 4.15 (2020-03), but we recommend installing the latest Eclipse 4.15 2020-03 Java EE bundle. Installing the newest bundle ensures you get the most current Java dependencies.

Once you have Eclipse 4.15 (2020-03) or higher installed, you can open the Eclipse Marketplace tab and look for either JBoss Tools or Red Hat CodeReady Studio. Alternatively, you could download JBoss Tools 4.15.0 directly from our update site.

OpenShift Container Platform 4.4 support

With the new OpenShift Container Platform (OCP) 4.4 now available, JBoss Tools is compatible with this major release in a transparent way. Just define your connection to your OCP 4.4-based cluster as you did before for an OCP 3 cluster, and use the tooling.

Language support for Kubernetes, Openshift, S2i, and docker properties

There is now completion, hover, documentation, and validation for kubernetes.properties, openshift.properties, s2i.properties, docker.properties, as shown in Figures 1, 2, 3, and 4.

docker.properties completion, hover and documentation example — Figure 1: Hover and documentation example: `docker.properties` completion.

Enter kubernetes prefix:

kubernetes.properties completion, hover and documentation example — Figure 2: Hover and documentation example: `kubernetes.properties` completion.

Enter openshift prefix:

openshift.properties completion, hover and documentation example — Figure 3: Hover and documentation example: `openshift.properties` completion.

Enter s2i prefix:

s2i.properties completion, hover and documentation example — Figure 4: Hover and documentation example: `s2i.properties` completion.

Language support for MicroProfile Rest Client properties

Likewise, there is now completion, hover, documentation, and validation for the MicroProfile properties from the REST Client. Start by registering a REST client using @RegisterRestClient like so:

package org.acme;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

import org.eclipse.microprofile.rest.client.inject.RegisterRestClient;

@RegisterRestClient
public interface MyServiceClient {
	@GET
    @Path("/greet")
    Response greet();
}

The related MicroProfile Rest config properties will have language feature support (completion, hover, validation, etc.), as shown in Figure 5.

MicroProfile completion, hover and documentation example — Figure 5: Hover and documentation example: MicroProfile completion.

Change the Java code so that the configuration key is changed:

package org.acme;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

import org.eclipse.microprofile.rest.client.inject.RegisterRestClient;

@RegisterRestClient(configKey = "myclient")
public interface MyServiceClient {
	@GET
    @Path("/greet")
    Response greet();
}

and notice that the code assist is changed accordingly, as shown in Figure 6:

Figure 6: Code changes are reflected in the configuration.

Language support for MicroProfile Health

Likewise, there is now completion, hover, documentation, and validation for MicroProfile Health artifacts. So if you have the following Health class:

package org.acme;

import org.eclipse.microprofile.health.Health;

@Health
public class MyHealth {

}

you will get a validation error (as the class does not implement the HealthCheck interface), as shown in Figure 7:

Image showing MicroProfile Health support in the code — Figure 7: Language support for MicroProfile Health.

Similarly, if you have a class that implements HealthCheck but is not annotated with Health, some workflow applies:

package org.acme;

import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;

public class MyHealth implements HealthCheck {

	@Override
	public HealthCheckResponse call() {
		// TODO Auto-generated method stub
		return null;
	}

}

You will get a validation message (as the class is not annotated with Health interface), as shown in Figure 8:

Image showing a prompt to install MicroProfile Health after using HealthCheck in the code. — Figure 8: Adding HealthCheck yields message to implement MicroProfile Health.

As there are several ways to fix the problem, several quick fixes are proposed.

Better extensions reporting in the Quarkus project wizard

With the Quarkus extensions ecosystem growing, we improved information about extensions in the Quarkus project wizard. When you select an extension in the wizard, you will see the extension's description on the lower side of the wizard, as shown in Figure 9. If the extension has a guide on the Quarkus web site, a link will also be displayed.

Image showing Quarkus extensions — Figure 9: Improved support for Quarkus extensions.

Clicking on that link will open the guide on your local web browser, as shown in Figure 10:

Image of Quarkus help for writing JSON REST services — Figure 10: Web-based help is available.

Hibernate runtime provider updates

A number of additions and updates have been performed on the available Hibernate runtime providers:

The Hibernate 5.4 runtime provider now incorporates both Hibernate Core version 5.4.14.Final and Hibernate Tools version 5.4.14.Final.
The Hibernate 5.3 runtime provider now incorporates both Hibernate Core version 5.3.16.Final and Hibernate Tools version 5.3.16.Final.

Platform

There are a variety of platform changes.

Hierarchical project layout by default in Project Explorer

To better handle multi-module, nested, and hierarchical projects, the default project layout in Project Explorer view has been changed from flat to hierarchical.

You can restore the layout to flat using the view menu (⋮).

Console view now interprets form feed and vertical tab characters

The interpretation of ASCII control characters in the Console view was extended to recognize the characters \f (form feed) and \v (vertical tab), in languages that support it. This feature is disabled by default. You can enable it on the Run/Debug -> Console preference page, as shown in Figure 11:

Example of form feed and vertical tab in code and result in browser — Figure 11: Form feed and vertical tab now supported.

Termination time in Console view

The Console view label will now show the termination time of a process in addition to the launch time.

Image showing process begin and end time. — Figure 12: Process timing information is readily available.

Preference to select resource rename mode

A preference has been added in the General preferences page that allows you to select the resource renaming mode in the Project Explorer: either open an inlined text field or a dialog, as shown in Figure 13. By default, the inline rename mode is selected.

The preference can also be specified via product customization:

org.eclipse.ui.workbench/RESOURCE_RENAME_MODE=inline
org.eclipse.ui.workbench/RESOURCE_RENAME_MODE=dialog

Note: A rename that would affect more than one resource is always performed with a dialog.

Image of two renaming options: Inline or Dialog-driven — Figure 13: Renaming a resource can be inline or dialog-driven.

The Welcome screen in the dark theme

When Eclipse is in the dark theme, the Welcome screen also appears dark on macOS and Linux, as shown in Figure 14.

Image of welcome screen shown in dark mode. — Figure 14: Welcome screen now available in dark mode.

Interactive performance

Interactive performance has been further improved in this release. To improve interactive performance, redraw is turned off by default during the collapse and expand operation of tree viewers. This behavior significantly improves these operations compared to drawing the updates synchronously.

Java Development Tools (JDT)

There are also a number of improvements around Java Development Tools.

Java 14 support

Java 14 is available and Eclipse JDT supports Java 14 for the Eclipse 4.15 release. This release notably includes the following Java 14 features:

JEP 361: Switch Expressions (Standard).
JEP 359: Records (Preview).
JEP 368: Text Blocks (Second Preview).
JEP 305: Pattern Matching for Instanceof (Preview).

Please note that the preview option should be on for language preview features. For an informal introduction of this support, please refer to the Java 14 Examples wiki.

Subword code completion

Content Assist now supports subword patterns, similar to Eclipse Code Recommenders and other IDEs. For example, completing on addmouselistener proposes results like addMouseMoveListener and addMouseWheelListener, as shown in Figure 15.

Image showing related methods as a method name is being entered — Figure 15: Related patterns suggestions now appear.

This feature can be enabled using the Show subword matches option on the Java -> Editor -> Content Assist preference page.

Subtype code completion

Content Assist will prioritize displaying constructor completions whose declaring type inherits from the expected return type within the completion context. For example, completing on:

Queue<String> queue = new L

prioritizes constructors for LinkedBlockingQueue, LinkedBlockingDeQueue and LinkedList, as shown in Figure 16.

Image showing code completion suggestions based on return type — Figure 16: Suggestions based on return type are prioritized.

Option for non-blocking Java completion

Code completion in the Java editor can now be run in a separate non-UI thread to prevent UI freezes in the case of long computations. To enable this non-blocking computation, go to Preferences -> Java -> Editor -> Content Assist -> Advanced and check the Do not block UI Thread while computing completion proposals preference. This option is currently disabled by default.

Non-blocking completion is useful when completion proposals are long to compute, as it allows you to type or use other parts of the IDE in the meantime. Some completion participants may prevent this option from being effective (typically if the Java completion extension doesn’t declare requiresUIThread="false"), so the UI thread may still be used even if this option is set.

Quick fix to wrap Optional statements

A quick fix has been added to wrap an Optional statement. The options for a primitive statement are: Optional.empty() and Optional.of(). Type statements also have Optional.ofNullable().

Figure 17 shows an example for type objects.

Image showing support for Optional statement — Figure 17: Improved support for Optional statement.

Selecting Wrap with nullable Optional for a type object results in what is shown in Figure 18.

Figure 19 shows an example for the primitive.

Primitive without wrap with optional — Figure 19: Without Wrap with Optional.

Selecting Wrap with Optional for primitive results in what's shown in Figure 20.

Primitive with wrap with optional — Figure 20: Using Wrap with Optional.

Simplify functional interface instances

A new cleanup has been added that simplifies the lambda expression and the method reference syntax and is enabled only for Java 8 and higher. The cleanup removes parenthesis for a single untyped parameter, return statement for a single expression, and brackets for a single statement. It replaces a lambda expression by a creation or a method reference when possible.

To select the cleanup, invoke Source -> Clean Up…, use a custom profile, and on the Configure… dialog select Simplify lambda expression and method reference syntax on the Code Style tab, as shown in Figure 21.

Dialog box allowing user to enable lambda cleanup — Figure 21: Enabling Lambda cleanup.

Consider the code shown in Figure 22.

Example of code before lambda cleanup — Figure 22: Before Lambda cleanup.

You get what you see in Figure 23 after the cleanup.

Example of code after lambda cleanup has been enabled — Figure 23: After Lambda cleanup.

Directly use Map method

Some map manipulations are unnecessarily verbose. The new cleanup option Operate on Maps directly, shown in Figure 24, calls methods on a map instead of calling the same methods on the key set or the values. Beware, though. If you create Map implementations that don’t follow the Map specification, this cleanup may break the behavior (a size() method that changes the values, an iterator that destroys the items, etc.)

Figure showing how to toggle the Operate on Maps directly feature — Figure 24: You can enable easier Map manipulation.

Consider the code shown in Figure 25.

Code sample without Operate on Maps directly enabled — Figure 25: Before Map cleanup.

You get what you see in Figure 26 after the cleanup.

Example of code with Operate on Maps directly enabled — Figure 26: After Map cleanup enabled.

Uppercase for long literal suffix

A new cleanup option, Use uppercase for long literal suffix, has been added, as shown in Figure 27. It will rewrite long literals like 101l with an uppercase L like 101L to avoid ambiguity.

Option to toggle long literals to automatic uppercase — Figure 27: Automatically convert long literal suffixes to UPPERCASE.

Surround with "try-with-resources" block

Corresponding to the quick fix which will surround a selection with a "try-with-resources" block, a new action has been added to the Surround With menu. For example, you might select the lines shown in Figure 28.

Three lines of source code selected in editor — Figure 28: Select lines to be surrounded by Try-with-resources.

Then, you might right-click and select Surround With -> Try-with-resources Block, as shown in Figure 29.

Dialog selecting Surround with Try-with-resources for the selected code block — Figure 29: Applying Try-with-resources to a code block.

Figure 30 shows the results.

Selected code block with try-with-resources automatically added to the code — Figure 30: Try-with-resources automatically added to code.

Quick fixes for module-info Javadoc

Quick fixes have been added to fix the missing and duplicate @provides and @uses Javadoc tags in a module-info file, as shown in Figure 31.

Error showing duplicate @provides annotations in Javadoc — Figure 31: Duplicate Javadoc @provides detected.

No more spurious semicolon from import completion

Almost 18 years ago, it was reported that completion for imports adds an unnecessary semicolon if one already exists (like when changing an existing import). Now, this extra semicolon is no longer inserted.

Java compiler

There are also a number of improvements to the Java compiler.

Warn when legacy code can taint null-checked values

When using null-annotations for advanced null analysis, it is inherently tricky to combine your code with legacy code that has no null annotations and has not been blessed by such analysis. Previously, Eclipse would only warn you when you obtain a dubious value from a legacy API, but it would keep silent in the opposite case: Passing a value of an annotated type into a legacy API.

Still, in specific situations, this behavior can cause a NullPointerException to be thrown in your null-checked code, as shown in Figure 32.

Code showing potential NullPointerException error — Figure 32: Potential NullPointerException errors are detected.

The console shows an exception thrown from within your checked main method (see the class level @NonNullByDefault). It also shows the new warning, which Eclipse raises to alert you of this danger.

Note: The shown code assumes that the list names has the type List<@NonNull String>, but the legacy method Legacy.printNames() succeeds in tainting this list by inserting a null element. This result goes unnoticed because that method views the list as having the type List<String>, with no nullness constraint on the type argument.

By default this problem is raised at level info, but the severity can be configured in the compiler settings, as shown in Figure 33.

Dialog showing toggle to enable or disable NullPointerException as a compile-time error — Figure 33: You can force compile errors for potential NullPointerException errors.

Improved Resource leak analysis

Resource leak analysis has been improved in several ways. Most importantly, the analysis now consistently considers resources (=values of type AutoCloseable) that are acquired using a method call, where previously under some circumstances resource allocation went unnoticed if it was wrapped in a factory method, like in the following example:

makePrintWriter("/tmp/log.txt").printf("%d", 42);
// a PrintWriter is never closed!

Second, resource leak analysis now leverages knowledge about well-known resource classes that support fluent programming, i.e., instance methods which return this to enable chains of method calls. Where a naive analysis could consider the method result as a new resource coming into scope, special knowledge about these classes informs the analysis that it is one and the same resource.

This issue concerns the following system classes:

from java.io

CharArrayWriter, Console, PrintStream, PrintWriter, StringWriter, Writer

from java.nio.channels

AsynchronousFileChannel, AsynchronousServerSocketChannel, FileChannel, NetworkChannel, SeekableByteChannel, SelectableChannel, Selector, ServerSocketChannel

from java.util

Formatter

The following example is now understood to be safe because analysis understands that the resource returned by append() is the same as the initial pw:

PrintWriter pw = new PrintWriter("/tmp/log.txt");
pw.printf("%d", 42).append(" is the answer").close();

Generally, resource leak analysis was made more precise regarding several specific situations.

Java formatter application requires a workspace

The Java formatter application will provide a sensible error message if a workspace is required but not provided (with the -data command-line option). This behavior also enables the -help option to be run on the formatter without a workspace specified.

A new bundle services the org.eclipse.jdt.core.JavaCodeFormatter application. This new bundle is part of the JDT feature. Users who are not using the JDT feature to define their set of bundles will need to add org.eclipse.jdt.core.formatterapp to their set of bundles.

Functional debug expressions

Lambda expressions and method references are now supported in debug expressions, such as in the Expressions view and in breakpoint condition expressions, as shown in Figure 34.

Debug window with Lambda function shown — Figure 34: Using a Lambda function in the debug window.

New bundle org.eclipse.jdt.core.formatterapp

The entry point of the org.eclipse.jdt.core.JavaCodeFormatter application has been moved to a new bundle, org.eclipse.jdt.core.formatterapp.

Conclusion

As you can see, there are a wide range of additions and improvements in JBoss Tools 4.15.0 and Red Hat CodeReady Studio 12.15 for Eclipse 4.15 (2020-03). There should be a bit of something for everyone.

Last updated: September 25, 2024