JBoss Tools 4.9.0 and Red Hat Developer Studio 12.9 for Eclipse 2018-09 are here waiting for you. Check it out!
Installation
Red Hat Developer Studio comes with everything pre-bundled in its installer. Simply download it from our Red Hat Developer product page and run it like this:
java -jar devstudio-<installername>.jar
JBoss Tools or Bring-Your-Own-Eclipse (BYOE) Developer Studio require a bit more:
This release requires at least Eclipse 4.9 (2018-09) but we recommend using the latest Eclipse 4.9 2018-09 JEE Bundle since then you get most of the dependencies preinstalled.
Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under "JBoss Tools" or "Red Hat Developer Studio".
For JBoss Tools, you can also use our update site directly.
http://download.jboss.org/jbosstools/photon/stable/updates/
What is new?
Our main focus for this release was on adoption of Java11, improvements for container based development and bug fixing. Eclipse 2018-09 itself has a lot of new cool stuff but let me highlight just a few updates in both Eclipse 2018-09 and JBoss Tools plugins that I think are worth mentioning.
OpenShift 3
Inner loop for Spring Boot applications
Although Spring Boot applications were already supported by the OpenShift server adapter, the global developer experience has been enhanced. Let’s complete the full workflow.
Bootstrapping your Spring Boot applications
A new generator (wizard) has been added to JBoss Tools. It’s called the Launcher application as it’s based on the fabric8-launcher project. When you launch JBoss Tools, you should see this in Red Hat Central:
Click on the
link and the following wizard will appear:Launcher application
Switch the
field to Mission
as we want to generate a simple
REST application and switch the rest-http
field to Runtime
as we want to generate a Spring Boot based application.spring-boot current-community
Then set the
field to Project name
and leave other fields as-is.myfirstrestapp
Click the
button. A new project will be added to your local workspace.
It may takes some times as Maven will resolve all the Spring Boot dependencies and
thus need to download them from the Internet.Finish
When the project is build and if you expand the
in the myfirstrestapp
window, you should see this:Project explorer
Storing your source code on GitHub
As OpenShift builder images retrieves code on a Git repository, we first need to push
the just generated application code to GitHub. The following section assumes that you
created a repository called
under your GitHub account.myfirstrestapp
We will first create a local Git repository for our application code then push it to GitHub.
Select the
project and right click the myfirstrestapp
menu item:Team → Share project…
Then select the
repository type and click the Git
button:Next
Select the
checkbox
then select the Use or create repository in parent folder of project
project:myfirstrestapp
Click on the
button and the on the Create repository
button.Finish
The
view is updated:Project explorer
Select the
project and right click
the myfirstrestapp
menu item. A new view
called Team → Show in Repositories View
will be added to the perspective:Git Repositories
Inside this view, select the
node and right click
the Remotes
menu item. The following dialog will be displayed:Create Remote…
Click on the
button, the following dialog will be displayed:OK
Click on the
button and enter Change…
in the git@github.com:GITHUB_USER/myfirstrestapp
field, replacing URI
by your real GitHub user name.GITHUB_USER
Then click the
button and then on the Finish
button.Save
Pushing code to GitHub
We are now ready to push our application code to GitHub. Select the
project
in the myfirstrestapp
view, right click the Project explorer
menu item. A new view
call Team → Commit
will open:Git Staging
Double click on the view title to maximize it:
Select all the files listed in the
list and click the '+' button. The
files will then move to the Unstaged changes
list:Staged Changes
Enter a commit message (ex 'Initial version') and click the
button.
the following dialog will be displayed:Commit and Push…
Click on the
button:Next
Click on the
button to start the push operation.Finish
A dialog with the result of the push operation will be displayed. Click the
to
dismiss it.OK
Add Spring Boot Devtools to the packaged application
In order to support live update on an OpenShift cluster, we must add Spring Boot DevTools to our Spring Boot application.
Open the
in the pom.xml
. Locate the myfirstrestapp
and add the following section:spring-boot-maven-plugin
<configuration>
<excludeDevtools>false</excludeDevtools>
</configuration>
The whole
section is given below:spring-boot-maven-plugin
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<excludeDevtools>false</excludeDevtools>
</configuration>
</execution>
</executions>
</plugin>
Close and save the
file.pom.xml
Push the change to GitHub: select the
with a new commit
message (ex 'With DevTools')Team → Commit…
Deploy the application on OpenShift
Before we can deploy the application on OpenShift, we must first create an ImageStream on our OpenShift cluster. The reason is that the Spring Boot support relies on S2I builds that will explode the Spring Boot uber JAR when Spring Boot DevTools is present. As this is not supported by all Java based S2I images, we will use one that supports it, ie fabric8/s2i-java:2.2
First, in the
project, create a new JSON file called myfirstrestapp
and set the content of this file to:springboot.json
{
"apiVersion": "image.openshift.io/v1",
"kind": "ImageStream",
"metadata": {
"name": "springboot"
},
"spec": {
"lookupPolicy": {
"local": false
},
"tags": [
{
"annotations": {
"tags": "builder,java"
},
"from": {
"kind": "DockerImage",
"name": "registry.access.redhat.com/fuse7/fuse-java-openshift:1.1"
},
"importPolicy": {},
"name": "1.1",
"referencePolicy": {
"type": "Source"
}
}
]
}
}
Then, from the OpenShift explorer view, select the OpenShift connection for your cluster (if you don’t have
one already defined, you must define it), right click on the
menu item and the
following dialog will be displayed:New → Resource…
You can select the OpenShift project you want to work with and then click on
the
button and select the Browse Workspace…
file
in the springboot.json
project:myfirstrestapp
Click the
and OK
buttons. The new ImageStream will be created and a status
dialog will be displayed:Finish
Create the application on OpenShift
We’re now ready to create the application on the OpenShift cluster. Select the OpenShift
connection, right click the
menu item. If you scroll down the
list, you should see the New → Application…
ImageStream we just created:springboot
Select this ImageStream and click the
button:Next
Enter
in the `myfirstrestapp
`Name
field,
`https://github.com/GITHUB_USER/myfirstrestapp in the
Git Repository URL
field, replacing
GITHUB_USER
by your real GitHub user name and click
the
Next``
button.
On the
dialog, click the Deployment Configuration & Scalability
button.`Next
On the
, select the Service & Routing Settings
port and click
the 8778-tcp
button, change the 8787 value to 8080:Edit
Click the
button then the OK
button.Finish
The list of OpenShift resources created will be displayed by a dialog:
Click the
button to dismiss it and when asked to import the application
code, click the OK
button as we already have the source code.Cancel
After the build is run (this may takes several minutes as the Maven build will download lots of dependencies), you should see a running pod:
Inner loop setup
We are going to synchronize the local Eclipse project with the remote OpenShift pod. Each time a file will be modified locally, then the pod will be updated accordingly.
Select the running pod in the
, right click the OpenShift explorer
menu
item, the following dialog will be displayed:Server Adapter…
Click the
button, the initial synchronization will be started and
the OK
view will be displayed:Servers
We’ve not setup the synchronization between our local Eclipse project and the remote OpenShift project. Each modification done locally will be reported on the remote OpenShift cluster.
Let’s modify our local application code and see the changes applied almost instantly:
Edit the file
in the src/main/java/io/openshift/booster/service/Greeting.java
project and change the myfirstrestapp
string
value from FORMAT
to Hello, %s!
and save the file.Hello, Mr %s!
The file should be now:
/*
* Copyright 2016-2017 Red Hat, Inc, and individual contributors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package io.openshift.booster.service;
// tag::snippet-greeting[]
public class Greeting {
public static final String FORMAT = "Hello, Mr %s!";
private final String content;
public Greeting() {
this.content = null;
}
public Greeting(String content) {
this.content = content;
}
public String getContent() {
return content;
}
}
// end::snippet-greeting[]
Then, in the ÒpenShift explorer
` view, select the
deployment
and select the myfirstrestapp
menu item and once the web browser is
displayed, ckick the `Show In → Web Browser
button, you should see the following view:Invoke
You’ve just experienced the inner loop on your Spring Boot application: any change done locally is reported and testable almost immedialtely on your OpenShift cluster.
You can restart the deployment in debug mode and you’ll be able to remote debug your Spring Boot application. Amazing, no ?
Hibernate Tools
Runtime Provider Updates
The Hibernate 5.3 runtime provider now incorporates Hibernate Core version 5.3.6.Final and Hibernate Tools version 5.3.6.Final.
The Hibernate 5.2 runtime provider now incorporates Hibernate Core version 5.2.17.Final and Hibernate Tools version 5.2.11.Final.
The Hibernate 5.1 runtime provider now incorporates Hibernate Core version 5.1.16.Final and Hibernate Tools version 5.1.10.Final.
Fuse Tooling
REST Viewer becoming an editor
Previously, there was a REST editor which was read-only. It is useful to have a great overview of already defined Camel REST DSL definitions. Now the editor and its related properties tab are also providing editing capabilities allowing to develop faster.
You can now:
-
Create and delete REST Configurations
-
Create and delete new REST Elements
-
Create and delete new REST Operations
-
Edit properties for a selected REST Element in the Properties view
-
Edit properties for a selected REST Operation in the Properties view
In addition, we’ve improved the look and feel by fixing the scrolling capabilities of the REST Element and REST Operations lists.
Java Developement Tools (JDT)
Java Editor
Improved Breadcrumb for Dark theme
The Breadcrumb in the Java Editor now uses a dark background in the Dark theme.
In the Light theme, the Breadcrumb uses a flat look style instead of a gradient.
Java Code Generation
Improved hashCode() and equals() generation
A new option in the Source > Generate hashCode() and equals()… tool allows you to create
implementations using the Java 7
and Objects.equals
methods.Objects.hash
The above setup generates the following code:
Additionally, arrays are handled more cleverly. The generation prefers the
and Arrays.deepHashCode
methods when dealing with Arrays.deepEquals
, Object[]
and Serializable[]
or any type variables extending these types.Cloneable[]
Java Views and Dialogs
Quick Fix for JRE Compiler Compliance Problem Marker
A new quick fix is provided on the JRE Compiler Compilance problem marker which is created when the compiler compliance does not match the JRE being used. This quick fix provides the option of opening the Compiler Compliance page of the project to fix the issue.
Selecting this option opens the Compiler Compliance property page for the specified project as shown below.
Java Formatter
Keep simple loops in one line
New formatter settings have been added that make it possible to keep the bodies of simple loops (without braces) in the same line as their headers, similar to previously existing setting for simple 'if' statements. Different kind of loops ('for', 'while', 'do while') can be controlled independently.
The settings can be found in the profile editor under New Lines > In control statements > Simple Loops.
There’s also a new setting to control how these loops should be handled if they exceed the maximum line width. It’s located under Line Wrapping > Wrapping settings > Statements > Compact loops ('for', 'while', 'do while').
Align items in columns
A feature previously known as align fields in columns has been expanded and can now be used for variable declarations and assignment statements as well.
An option has also been added to always align with spaces, even if tabs are used for general indentation. This is very similar to the Use spaces to indent wrapped lines option and is useful to make the code look good in editors with differing tab width.
All the settings related to aligning are now in the new preferences subsection: Indentation > Align items in columns.
Debug
Timeout for result of step operation
Observing the result of step operations may slow down execution, which may be unusable if the step takes long already. Therefore a timeout (default: 7000 ms) has been introduced after which the observation mechanism is disabled until the end of the step operation.
The timeout can be configured in Preferences > Java > Debug > Don’t show if step operation takes longer than (ms).
Option to hide running threads in Debug view
A new option has been introduced in the Debug view to show or hide running threads.
Hiding running threads can be useful when debugging heavily multithreaded application, when it is difficult to find threads stopped at breakpoints among hundreds or thousands of running threads.
Show Command Line button in Launch Configuration
A new button Show Command Line has been added in the Java Launch Configuration dialog.
Clicking the button will open a dialog to show the command line used for launching the application.
Option to disable thread name changes in Debug View
Thread name changes in the debuggee JVM are reflected in the Debug View. A VM option can now be used to disable this behavior, in case the JVM communication necessary for the name updates is not desired.
The functionality can be disabled by specifying the following VM option
-Dorg.eclipse.jdt.internal.debug.core.model.ThreadNameChangeListener.disable=true
Support for long classpath/modulepath
Classpath and/or modulepath are now shortened if they are longer than current operating system limits.
If a temporary jar is needed to shorten the classpath (Java 8 and previous versions), a dialog is shown asking for confirmation.
The option Use temporary jar to specify classpath (to avoid classpath length limitations) is available in the Classpath tab of the Run/Debug Configuration dialog.
And more…
You can find more noteworthy updates in on this page.