Posts tagged with 'devstudio'

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 Launcher application link and the following wizard will appear:

Switch the Mission field to rest-http as we want to generate a simple REST application and switch the Runtime field to spring-boot current-community as we want to generate a Spring Boot based application.

Then set the Project name field to myfirstrestapp and leave other fields as-is.

Click the Finish 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.

When the project is build and if you expand the myfirstrestapp in the Project explorer window, you should see this:

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 myfirstrestapp under your GitHub account.

We will first create a local Git repository for our application code then push it to GitHub.

Select the myfirstrestapp project and right click the Team → Share project…​ menu item:

Then select the Git repository type and click the Next button:

Select the Use or create repository in parent folder of project checkbox then select the myfirstrestapp project:

Click on the Create repository button and the on the Finish button.

The Project explorer view is updated:

Select the myfirstrestapp project and right click the Team → Show in Repositories View menu item. A new view called Git Repositories will be added to the perspective:

Inside this view, select the Remotes node and right click the Create Remote…​ menu item. The following dialog will be displayed:

Click on the OK button, the following dialog will be displayed:

Click on the Change…​ button and enter git@github.com:GITHUB_USER/myfirstrestapp in the URI field, replacing GITHUB_USER by your real GitHub user name.

Then click the Finish button and then on the Save button.

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 myfirstrestapp project, create a new JSON file called springboot.json and set the content of this file to:

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 New → Resource…​ menu item and the following dialog will be displayed:

You can select the OpenShift project you want to work with and then click on the Browse Workspace…​ button and select the springboot.json file in the myfirstrestapp project:

Click the OK and Finish buttons. The new ImageStream will be created and a status dialog will be displayed:

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 OpenShift explorer, right click the Server Adapter…​ menu item, the following dialog will be displayed:

Click the OK button, the initial synchronization will be started and the Servers view will be displayed:

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 src/main/java/io/openshift/booster/service/Greeting.java in the myfirstrestapp project and change the FORMAT string value from Hello, %s! to Hello, Mr %s! and save the file.

The file should be now:

Then, in the ÒpenShift explorer` view, select the myfirstrestapp deployment and select the `Show In → Web Browser menu item and once the web browser is displayed, ckick the Invoke button, you should see the following view:

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 ?

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.

The existing quick fix to create missing methods has been improved to create abstract method declarations. The option only appears when the target class is an abstract class.

A new quick fix has been implemented that allows the user to convert static field accesses and static methods to use a static import. It’s also possible to replace all occurrences at the same time.

A new option in the Source > Generate hashCode() and equals()…​ tool allows you to create implementations using the Java 7 Objects.equals and Objects.hash methods.

The above setup generates the following code:

Additionally, arrays are handled more cleverly. The generation prefers the Arrays.deepHashCode and Arrays.deepEquals methods when dealing with Object[], Serializable[] and Cloneable[] or any type variables extending these types.

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.

The Open Type dialog now always shows the full path of all the matching items.

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').

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.

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).

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.

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.

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

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.

See the BPMN2 1.5.0.Final Known Issues Section of the Integration Stack 12.0.0.GA release notes.

See the Drools 7.8.0.Final Known Issues Section of the Integration Stack 12.0.0.GA release notes.

See the Teiid Designer 11.2.0.Final Resolved Issues Section of the Integration Stack 12.0.0.GA release notes.

Thanks to Eclipse Photon, there are new two different classpathes, the main and the test classpath. The main classes will now no longer see the test classes and dependencies

The embedded Maven runtime is now based on Apache Maven 3.5.3.

It is now possible to disable an archetype catalog.

Support for Java 9/10 has been improved: bugs fixes, better handling of module path.

A quick fix Change project compliance and JRE to 10 is provided to quickly change the current project to be compatible with Java 10.

A new quick fix is offered to fix issues that are reported when the Missing '@NonNullByDefault' annotation on package warning is enabled. If the package already has a package-info.java, the quick fix can be invoked from the editor:

Otherwise, the quick fix must be invoked from the problems view, and will create a package-info.java with the required annotation:

When invoked from the problems view, both variations of the quick fix can fix the problem for multiple packages simultaneously.

You can now Ctrl+click or use Open Declaration (F3) on case or default keywords to quickly navigate to the beginning of the switch statement.

The Java > Editor > Typing > Escape text when pasting into a string literal preference option now has a suboption Use Unicode escape syntax for non-ASCII characters:

When enabled, characters outside the visible ASCII range will be replaced by unicode escape sequences when pasted into a string:

To improve readability in the dark theme, bold style usage has been reduced and some colors that were too close to each other have been altered.

The colors of links in code element information control now takes the color settings of the Hyperlink text color and the Active hyperlink text color from the Colors & Fonts preference page into account. The readability in the dark theme has been improved a lot by this.

Before:

After:

The Eclipse default dark theme now includes styling of inherited members in JDT’s Quick Outline. This improves readability in the dark theme a lot. The color can be configured via the Java > Inherited Members color definition on the Colors and Fonts preference page.

Before:

After:

In the Java Build Path project settings, there is now an attribute Contains test sources to configure that a source folder contains test sources. (Note: test sources must have their own output folder). Similarly, for projects and libraries there is an attribute Visible only for test sources. This setting also exists for classpath containers, and if it is set to Yes for one of these, this value will be used for all contained libraries and projects.

Test source folders and dependencies are shown with a darker icon in the build path settings, the package explorer and other locations. This can be disabled in Preferences > Java > Appearance:

Referenced projects can contain test sources and have test dependencies themselves. Usually, when test sources are compiled, the test code in projects on the build path will be visible. As this is not always desirable, it can be changed by setting the new build path attribute Without test code, that is available for projects, to Yes.

Build path entries configured like this have a decoration [without test code] after the project name, which can be disabled in Preferences > General > Appearance > Label Decorations:

For each project, compilation is now done in two phases: First all main sources (which cannot see any test-code on the build-path) and then all test sources.

As a consequence, if the project is a modular Java 9 project, test dependencies like JUnit can not be referenced in the module-info.java, as they will not be visible while compiling it. The solution used to handle this is the same, that Maven uses: When test dependencies are put on the classpath, the module being compiled will automatically be configured to read the unnamed module during the compilation of the test sources, so the test dependencies will be visible.

Of course, code completion will not suggest test code in main sources:

There are now two dynamic Java working sets Java Main Sources and Java Test Sources containing the source folders grouped according to value of the Contains test sources attribute. This can for example be used to remove warnings in test sources from the problems view:

To achieve this, create a new filter that shows warnings for the Java Main Sources working set and select it with the All Errors on Workspace filter:

There are also dedicated filters to quickly remove hits in main code or test code from Java search results:

Similar, there is a filter to remove test code from Call hierarchies:

Another filter to remove test code exists for Quick type hierarchies:

Test source folders will be preselected in the New JUnit Test Case wizard

In Run and Debug configurations, the Classpath tab (or Dependencies tab when launching with Java 9) contains a new option Exclude Test Code, that is automatically preselected when launching a Java Application from a source folder that is not marked to contain test sources:

When launching with Java 9 and this option is not selected, command line options will automatically be added so modules that have a non-empty classpath read the unnamed module. These command line options are part of what can be overridden using the new Override Dependencies button.

The content of libraries are displayed in the order of the classpath. This makes it difficult to find specific libraries by their name, especially when projects have many dependencies. The library entries can now be sorted alphabetically when setting the preference Sort library entries alphabetically in Package Explorer on the Java > Appearance preference page:

The default for this preference is OFF.

The Generate…​ dialogs of the Java tools have been adapted to use verbs instead of OK.

This is an experimental support provided to allow the regular expression usage in search field while searching for module declaration. This can be considered as a wrapper of the API change.

To invoke the regular expression search from the search field under Java Search, start the expression with "/r " i.e, a slash '/', the letter 'r' and a blank ' ' (not tab) followed by a regex, an example of which is shown below:

In the above example, all the characters trailing "/r " form a Java regular expression to denote a module name which starts with zero or more 'n’s followed by the string ".ver" and followed again by zero or more number of arbitrary characters.

Another example would be to search for all modules that start with java.x followed by zero or more characters which is given by the regular expression /r java\.x.* - note the backslash for . to consider this as a "normal" character instead of the special regex].

Yet another example would be search for all module names that start with j followed by zero or more characters and ending with .xml which in regex language translates to /r j.*\.xml. Please note that here the first '.' is the special regex character while the second '.' is escaped to denote that this is a normal character.

Note: You should use this only for Declarations search for modules as it is not implemented for module references. Selecting All occurrences in conjunction with regex will default to finding only the Declarations matching the regex ignoring the references.

When using annotation-based null analysis, there are now more ways to define which unannotated locations are implicitly assumed to be annotated as @NonNull:

Version 2.2.0 of bundle org.eclipse.jdt.annotation contains an annotation type NonNullByDefault that can be applied to parameter and module declarations (in addition to the previously allowed targets).

There is now support for running Java annotation processors on test sources. The output folder for files generated for these can be configured in the project properties in Java Compiler > Annotation Processing as Generated test source directory.

A new preference Compiler Compliance does not match used JRE is added to Compiler Preference Building Page.

This preference indicates the severity of the problem reported when project’s used JRE does not match the compiler compliance level selected. (e.g. a project using JRE 1.8 as JRE System Library, and the compiler compliance is set to 1.7).

The value of this preference is by default WARNING.

If the JRE being used is 9 or above and the --release option is selected and even if the compiler compliance does not match the JRE being used, this option will be ignored.

This preference can be set as shown below:

The formatter profile preference page (Java > Code Style > Formatter > Edit…​) has a new look which makes it much easier to set preferences for formatting Java code. Instead of multiple tabs, all preferences are presented in an expandable tree.

You can use filtering to display only the settings with names matching a specific phrase. Filtering by values is also possible (prefix a value filter with a tilde).

Most sections have a Modify all button in their header that lets you set all their preferences to the same value with one click.

Some preferences have more convenient controls. For example, number values can be easily modified with arrow buttons. Wrap policy settings are controlled by simple toolbars so that you can see and compare multiple policies at once.

In the preview panel you can now use your own code to immediately see how it will be affected by the modified settings. You can also see the raw form of standard preview samples and make temporary modifications to them.

The formatter can now align names and/or descriptions in Javadoc tags in new ways. The formatter profile editor is available for selection, under Comments > Javadoc.

For example, the Align descriptions, grouped by type setting is now used in the built-in Eclipse profile.

The setting previously known as Indent Javadoc tags is now called Align descriptions to tag width. The two settings related to @param tags also had their labels changed to better describe what they do.

The formatter preferences tree styling has been fixed to work properly in the dark theme.

The new cleanup action "Remove redundant modifiers" removes unnecessary modifiers on types, methods and fields. The following modifiers are removed:

The cleanup action can be configured as save action on the Unnecessary Code page.

A Java Launch Configuration can now be based on a prototype.

A prototype seeds attributes in its associated Java Launch Configurations with the settings specified in the Prototype tab.

Once a Java Launch Configuration has been created, you can override any initial settings from the prototype. You can also reset the settings of a Java Launch Configuration with the ones from its prototype. A Java Launch Configuration maintains a link to its prototype, but is a complete stand-alone launch configuration that can be launched, exported, shared, etc.

More precise advanced source lookup implementation, particularly useful when debugging applications that load classes dynamically at runtime.

New org.eclipse.jdt.launching.workspaceProjectDescribers extension point can be used to enable advanced source lookup for projects with non-default layout, like PDE Plug-In projects.

New org.eclipse.jdt.launching.sourceContainerResolvers can be used to download sources jar files from remote artifact repositories, like Maven Central or Eclipse P2.

Advanced source lookup affects debug launches only and can be enabled or disabled with Java > Debug > Use advanced source lookup (JRE 1.5 and higher) preference option:

Debug view now automatically updates thread names if they are changed in the debuggee JVM. This shows live information for worker instances, as described above.

Technically speaking, Java debugger automatically adds a new (user invisible) breakpoint in the JVM and notifies clients (like Debug view) on a breakpoint hit. If this behavior is undesired for some reason, product owners can disable it via product customization.

The property value is: org.eclipse.jdt.debug.ui/org.eclipse.jdt.debug.ui.javaDebug.ListenOnThreadNameChanges=false

When a method exit breakpoint is hit, the value being returned is now shown in the variables view.

Similarly, when an exception breakpoint is hit, the exception being thrown is shown.

The Display view has been renamed to Debug Shell to better match the features and purpose of this view. Also, a java comment is shown in the Debug Shell on fresh open that explains when and how to use it.

JAX-RS 2.1 brought support for server side events. The Sse and SseEventSink resources can now be injected into method arguments thanks to the @Context annotation.

Enjoy!

Jeff Maury