Download the Conference App!

by Anonymous at October 17, 2018 08:18 PM

Thanks to EclipseSource and their Tabris framework, the EclipseCon Europe conference app is ready for download. Browse the schedule, save your favorite talks to your personal list, read the talk descriptions, and see the speaker bios. If you're looking for a room, follow the maps and you won't get lost!

  • Download the Android version
  • Download the iOS version

by Anonymous at October 17, 2018 08:18 PM

Download the Conference App!

by Anonymous at October 17, 2018 07:34 PM

Thanks to EclipseSource and their Tabris framework, the EclipseCon Europe conference app is ready for download.

by Anonymous at October 17, 2018 07:34 PM

Xtext Editors within Sirius Diagrams – the Best of both Worlds!

by Niko Stotz at October 17, 2018 01:55 PM

tl;dr: Altran’s Xtext / Sirius Integration provides the full Xtext experience for Sirius direct editors (a.k.a. pressing F2 in diagram) and properties editors. It’s highly configurable, well-documented, and released under EPL 2. I’ll present it at EclipseCon 2018 next week in Ludwigsburg. We intend to contribute this to the Sirius project.

Example of Xtext’s error checking and auto-completion support within Sirius diagram figure

Both textual and graphical modeling have their well-known strengths and weaknesses – obviously, we want the best of both worlds!

Xtext and Sirius are among the most-used Eclipse Modeling Framework technologies, covering textual and graphical modeling, respectively. Previous   EclipseCon talks discussed the different usage scenarios and difficulties of integrating these technologies. We focused on the “Xtext editors within Sirius diagrams and properties view” scenario and could solve most of the integration difficulties. The result is called Xtext / Sirius Integration.

Our main goals were to be a good Sirius citizen, i.e. configuring all details in the Odesign model, and to support as much of Xtext’s features as possible without requiring changes to the Xtext language.

We would like to contribute the code to the Sirius project. Initial discussions already started, so stay tuned.

I’m very happy to discuss any questions or ideas at the EclipseCon 2018 next week in Ludwigsburg – please approach me! I’ll present Xtext / Sirius Integration at Wednesday, Oct. 24th, 10:25 am on Theater Stage. See you there!

Main Features

Use Cases

  • Use Xtext as direct editor for Sirius diagram figures and connections
  • Use Xtext in Sirius property editors
  • Edit parts of the Sirius editor’s model with Xtext
  • Edit text stored in the model with Xtext

Configuration Options

  • Single-line or multi-line Xtext editor
  • Limit the editable features
  • Configure pre-selected features
  • Prepend or append text to model contents in order to provide a valid Xtext document
  • Ignore selected nested features
  • Use a different Xtext grammar for persisting and editing a model


The source code of all examples is available at github.

The github readme provides more details on the examples.

Smart UML Class Attributes

Assume a model and diagram akin to UML class diagrams.

Each attribute has a visibility, a name, a type, a multiplicity with lower and upper bounds, and a (possibly long) description text. We can edit these features in one line with full Xtext support.

Xtext reports invalid visibility

Xtext provides auto-completion for referenced constants

Xtext / Sirius Integration allows to edit all the visible features of the attribute just as we see them, without fiddling around in property editors. It automatically checks for valid input (i.e. does not accept ~ as visibility) and provides auto-completion for references to declared constants.

Pre-selecting the most edited part

We hide the description feature from the Xtext editor, as it makes no sense to edit it in-line. Also, we pre-select only the attribute’s name. This way, we changed only the name without touching the other features, if the user pressed F2, typed something, and pressed enter.

We can still edit all of the features separately in the properties view.

Markup Language for Descriptions

Assume a model where every element can have a description. Formally, the description is just a string feature of the element. However, the user may use HTML-like tags in the description. A build server task collects the descriptions of all elements of one model and combines them into one HTML page. We’d have an Xtext grammar for HTML.

HTML-like documentation language with Xtext support in Properties View

As HTML goes, we need to start with a <html> tag, followed by a <head> section, and only in the <body> the user may add their description text. Also, we need to finish the text by closing both <body> and <html>. We don’t want the user to add this boilerplate to every description, as it’s cumbersome, error-prone, and we’d need to remove it in the build step. Still, we’d like to use our Xtext grammar.

With Xtext / Sirius Integration, we define a prefix (<html><head><title>dummy</title></head><body>) and suffix (</body></html>). This way, the model contains only the actual description, and the user still benefits from all the goodies of our Xtext HTML language, like using only valid tags, or closing them in the correct order.

We can provide such an editor to the user within the diagram and/or in the properties view.

Smart UML Class Associations

Assume a model and diagram akin to UML class diagrams. Each class is represented by a rectangle, associations between classes are shown as connections.

The model is persisted with Xtext. Example:

constant MAX_ROOMS = 23
constant MAX_PEOPLE = 42

class House {
  public inhabitants: string[1..MAX_PEOPLE]
class Room {
  public size: integer[2..2]

association rooms House --> Room[1..MAX_ROOMS]

The Xtext grammar might be:

grammar com.example.classes with org.eclipse.xtext.common.Terminals

generate classes ""


	| Class
	| Association

	'=' initial=Value

// omitting Class, Value, ...

	source=[Class] '-->' target=[Class]
	'[' lowerBound=Value '..' upperBound=Value ']' 

We want to display and edit the name and multiplicity of the association as connection label. We want to get full Xtext support (e.g. auto-completion for referenced constants in multiplicity).

However, for technical reasons, we can only hide features at the beginning and/or end of the element’s text. To solve this issue, we create another Xtext language and use this one in our diagrams:

grammar com.example.classes.edit with com.example.classes

import ""

EditClassModel returns ClassModel:

	'[' lowerBound=Value '..' upperBound=Value ']' 
	source=[Class] '-->' target=[Class]

We extend the original grammar and override the Association grammar rule. All other grammar rules remain untouched. We move the source and target features to the end of the element’s text. This way, we can hide them from the user: They should edit the source and target by dragging the connection.

Model in original grammar. Note the association’s source and target are in-between its name and multiplicity.

Xtext editor using the alternative grammar, hiding the association’s source and target features.


We spent more than six months on this development, and had to overcome quite a few hurdles. Please read about some of them below.

Deep Technology Stack

Deep technology stack

Both Xtext and Sirius are very mature, flexible, and complex frameworks. It’s not surprising they both stand on the shoulder of giants, i.e. re-use lots of other technologies. Xtext / Sirius Integration balances on top of these behemoths standing on other giants. In this height, the air is thin and we feel the Law of Leaky Abstractions.

To achieve our goal of best possible integration, we have to weave together both technology stacks on various levels, leading to lots of gory gut work.

Sirius follows a very rigorous “separation of concerns” approach (partially because it seems to be required by underlying technologies). As a result, for each “thing” in Sirius (e.g. a node, connection, or tool), there is one class in each concern. As soon as we required even the slightest adjustment on any aspect, we had to duplicate this whole thread of classes throughout all concerns.

Graphical / Event Integration

I was most scared about the graphical and event integration, as my previous experience in this field suggested. Luckily, there is another Open Source project called Yakindu Statecharts. It provides, among lots of other features, graphical state machine modeling. It’s not based on Sirius, but shares the same base (Graphical Editing Framework GEF, to be precise). Yakindu Statecharts also provides Xtext editors within the diagram – jackpot! We could re-use most of the drawing, sizing, and event integration.

As a sidenote, I think this is a prime example of Open Source’s power: Xtext is Open Source, Sirius is Open Source, and so is Yakindu Statecharts. This whole integration would never have been possible without access to the source code! Statecharts happily accepted a pull request to improve re-usability of their code. Thanks again!

Model Integration

Both Xtext and Sirius edit a model, but in very different ways. Integrating them was the biggest technical challenge – as we knew from previous EclipseCon talks.

Note: The following discussion touches quite intricate issues; explaining them with text only is tough. If you’re lost, visit my talk at EclipseCon or view it’s video recording (I’ll link to it once it’s online).

Xtext / Sirius Integration can work on two different bases:

  1. Storing the Xtext-edited model as text in the Sirius model
  2. Editing the same model with Xtext and Sirius

Base 1) is not that hard: When the user presses F2, we open an Xtext editor, read the text attribute from the Sirius model, Xtext parses it and creates its own, independent model. The user edits the Xtext model, and when the editor is closed, we ask Xtext for the changed text and write it back to the text attribute in the Sirius model.

Base 2) is much more challenging. To understand why, we have to look at some details.

(We assume the Sirius model is persisted via Xtext. At Altran, this is the most common use-case, as this allows sensible diff/merge on models without taming EMFCompare. Anyways, most of the discussion applies equally to other persistence formats.)

Let’s have a look at the lifecycle of a Sirius diagram persisted via Xtext:

Lifecycle of a Sirius diagram

  1. The user opens a Sirius diagram.
  2. Sirius figures out the diagram is based on a model that’s persisted via Xtext. Sirius asks Xtext to read the model.
  3. Xtext reads the model text file.
  4. Xtext parses the file contents and creates an read-only Abstract Syntax Tree (AST).
  5. Xtext converts the AST into a model instance.
  6. The model instance is ready to use. Sirius uses the model instance to display the diagram.
  7. The user changes the diagram, e.g. they add some connections or remove some elements.
  8. Sirius changes the underlying model without saving it. At this point, the contents of the file and the model instance differ.
  9. The user saves the diagram.
  10. Sirius asks Xtext to persist the current state of the model instance.
  11. Xtext serializes the model into text. Xtext does not change the AST.
  12. Xtext writes the text into the text file.

So what changes if the user didn’t use Sirius to change the model, but the Xtext / Sirius Integration?

Lifecycle of Xtext edit within Sirius diagram

We should only show to the user the interesting part of the underlying model. If they pressed F2 on one UML Class Attribute (as an example), they should only edit this Attribute, not the whole model.
We cannot use the existing AST, as it might be outdated. Also, for fundamental technical reasons, Xtext cannot parse/serialize parts of a model file.
Thus, we ask Xtext to serialize the complete model instance into a memory buffer. We create a dummy Xtext file and copy the text there. Xtext does its usual work of parsing and creating the dummy model instance (which, at this point, is identical to Sirius’ model instance).
We hide all text from the user they should not edit. Again for technical reasons, we can only hide text before or after the visible text, not somewhere in between. This allows also to hide some features of the edited attribute: If the UML Class Attribute’s description was the first feature in the model text, we can hide it – and the user cannot edit it any more.

The user changed the text to their wishes. As Xtext flags any issues directly, we assume the user did not introduce any errors. But all these changes happened in the dummy Xtext file; we have to get them back into the Sirius model instance.

We could try to merge the changed text from Xtext into the model’s text. But we all know text merge is not reliable on big changes, so we prefer to merge on a model basis. Given the known restrictions, model merge works mostly ok. It gets complicated if the user changed names or similar attributes that are part of an element’s URI.

Even more complicated are cross-references. Assume our model instance contains Constants and Classes with Attributes. The Attributes’ initial values can refer to the Constants. If the user pressed F2 on the Attribute, we create a complete copy into a dummy model instance. The user asks auto-complete for available Constants, and auto-complete proposes the Constants from the dummy model instance.
Once the user is finished, we merge their changes back into the Sirius model instance. But we only merge the edited Attribute and throw away the rest of the model – including the referenced Constant!

Luckily, both Xtext and Sirius are based on EMF, and EMF knows a concept called proxies. If EMF loads a model and finds a reference to an element outside of this model, it only creates a placeholder, a.k.a. proxy, for the external element. This placeholder stores the URI of the external element. Once required, EMF loads the external resource and replaces the proxy with the real thing.
We abuse this mechanism a bit to solve our dangling reference problem: Before merging the Attribute back into the Sirius model instance, we check the Attribute for any references to the dummy model. If we find one, we convert the target into a proxy. After finishing the merge we ask EMF to resolve all proxies in the Sirius model instance. As the target was there in the copied dummy model instance, and we didn’t change anything outside the merged part, we can be sure these proxies will be resolved.

We can follow a similar approach for references from the Sirius model instance to element merged back from the dummy model instance.

odesign Integration

The developer defines all aspects of a Sirius diagram in a odesign file. We wanted to keep this approach. Thankfully, Sirius provides all the necessary hooks – but they are hard to find. Interestingly, the hooks work very different for seemingly similar aspects: Adding context menu entries to the Properties part of the odesign file requires a completely different approach than adding context menu entries to the Diagram part of the odesign file.

I’m quite satisfied with the result: Only the most advanced use cases require coding outside the odesign file.

Further Reading

Please refer to the extensive user guide (also available as PDF) for more details and known issues.

The github readme provides more details on the examples and information about required dependencies.

Xtext / Sirius integration is released under EPL 2 at github.

We provide an update site.

by Niko Stotz at October 17, 2018 01:55 PM

Short-Circuit Evaluation in N4JS

by Project N4JS ( at October 17, 2018 09:28 AM

Short-circuit evaluation is a popular feature of many programming languages and also part of N4JS. In this post, we show how the control-flow analysis of the N4JS-IDE deals with short-circuit evaluation, since it can have a substantial effect on the data flow and execution of a program.

Short circuit evaluation is a means to improve runtime performance when evaluating boolean expressions. This improvement is a result of skipping code execution. The example above shows an if-statement whose condition consists of two boolean expressions that combine the values of 1, 2 and 3, and its control flow graph. Note that the number literals are placeholders for more meaningful subexpressions.

First the logical and, then the logical or gets evaluated: (1 && 2) || 3. In case the expression 1 && 2 evaluates to true, the evaluation of the subclause 3 will be skipped and the evaluation of the entire condition results to true. This skipping of nested boolean expressions is called short circuit evaluation.

However, instead of skipping expression 3, expression 2 might be skipped. In case condition 1 does not hold, the control flow will continue with condition 3 right away. This control flow completely takes places within the if-condition, whereas the former short circuit targets the then block.

The reasoning behind short circuit evaluation is that the skipped code does not affect the result of the whole boolean expression. If the left hand side of the logical or expression evaluates to true, the whole or expression also does. Only if the left hand side is false, the right hand side will be evaluated. Complementary, the right hand side of a logical and expression is skipped in case the left hand side evaluates to false.

Side Effects

Risks of short circuit evaluation might arise in case a subexpression has side effects: These side effects will not occur if the subexpression is skipped. However, a program that relies on side effects of expressions inside an if-condition can be called fragile (or adventurous). In any case it is recommended to write side-effect free conditions.

Have a look at the example above. In case variable i has a value of zero, the right hand side expression i++ is executed, otherwise, it is skipped. The side effect here is the post-increment the value of i. If the value of i is other than zero, this value will be printed out. Otherwise, the value will be incremented but not printed. The control flow shows this behavior with the edge starting at i and targeting the symbol console.


Loop conditions also benefit from short circuit evaluation. This is important to know when reasoning about the all possible control flow paths through the loop: Each short circuit will introduce another path. Combining all of them makes data flow in loops difficult to understand in case of side effects in the subconditions.

Creative use of short circuit evaluation

Misusing short circuit evaluation can mimic if-statements by using expressions but without using the language feature of conditional expressions (i.e. condition() ? then() : else()). This could be used when if-statements should be executed e.g. when passing arguments to method calls, or when computing the update part of for-loops.

The picture above shows the two versions: the first uses an if-statement and the second uses an  expression statement. These two statements call the functions condition, then and end. Depending on the return value of condition, the function then is executed or not. Consequently, the printouts are either "condition then end" or "condition end", depending on the control flow.

The corresponding control flows are depicted on the right: The upper three lines refer to the if-statement, and the lower three lines to the expression statement. They reveal that the expression statement behaves similar to the if-statement. Note that the control flow edge in the last line that skips the nodes end and end() is never traversed since the logical or expression always evaluates to true.

by Marcus Mews

by Project N4JS ( at October 17, 2018 09:28 AM

Introducing the Jakarta EE Specification Process

by Mike Milinkovich at October 16, 2018 07:18 PM

I am very happy to announce that we are publishing a draft of the Eclipse Foundation Specification Process for community review and feedback. This specification process will be used by Jakarta EE as the new open specification process, replacing the JCP process previously used for Java EE. It is also expected that this new process will be of interest to other Eclipse working groups.

We are really looking forward to your feedback, which you can do via the Jakarta EE Community mailing list (preferred), or on the document comments.  The feedback provided will be used as input to finalizing a first version of the specification process and its adoption by Jakarta EE and other working groups at the Eclipse Foundation.  

As you are reviewing this draft specification process, please keep in mind the following key points about the approach that was taken by the Specification Committee.

  1. We want to design a specification process to replace the JCP. While there are many differences with the JCP, the key objective was to make the whole process as lightweight as possible.
  2. We want the specification process to be as close to open source development as possible. This is actually not a trivial exercise, as by its very nature drafting specifications is a somewhat different process.
  3. This is the Eclipse Spec Process, so we want to reuse the Eclipse Development Process wherever possible, and we want to ensure that the general flow and tone of the EDP is followed.
  4. We want to create a process that allows code-first development. Specifically, we want to enable a culture where experimentation can happen in open source and then have specifications be based on those experiences.
  5. We want the specifications that result from this process to be as high quality as possible. In particular, this means that we need to take care of the intellectual property flows, and to protect the community’s work from bad actors. This requirement manifests as two fundamentally important differences from the EDP:
    • Specification Committee approval is required for releases from Spec Projects, in addition to the normal PMC approval; and
    • We introduce the notion of “Participants” who are committers who represent specific member companies on a Spec Project. This is necessary to ensure that the IP contributions (particularly patents) from companies are properly captured by the process.

All of us at the Eclipse Foundation would like to recognize the tireless efforts of the members of the Specification Committee. A lot of hard work has gone into this document, and it’s very much appreciated. We are certain that Jakarta EE, and many other Eclipse technologies, benefit from the thoughtful efforts of this Committee.  In particular, we would like to thank the following Specification Committee members and alternates:

Fujitsu: Kenji Kazumura​, Mikel DeNicola
IBM: Dan Bandera​, Kevin Sutter
Oracle: Bill Shannon​, Ed Bratt​, Dmitry Kornilov
Payara: Steve Millidge​, Arjan Tijms
Red Hat: Scott Stark, Mark Little
Tomitribe: David Blevins​, Richard Monson-Haefel
PMC Representative: Ivar Grimstad
Elected Members: Alex Theedom, Werner Keil​

I also wish to recognize Tanja Obradovic and Wayne Beaton from the Eclipse Foundation team who have driven the process throughout – many thanks to you both!

by Mike Milinkovich at October 16, 2018 07:18 PM

Example demonstrating connectivity to an MQTT broker

October 16, 2018 04:00 AM

Eclipse Ditto can now connect to MQTT 3.1.1 brokers.

Perfect timing to happily welcome a new colleague to our team behind Eclipse Ditto: David.

In order to get familiar with Ditto and the development with digital twins, David was assigned with one of his first tasks to get his hands on one of our newest features, MQTT connectivity which was released recently with milestone 0.8.0-M2.

On his journey into digital twin land he made a great example with an ESP8266 powered board connected via an MQTT broker to Ditto and published it to the Eclipse Ditto examples repository:

This example is about how to communicate between device and solution in a two way pattern through Ditto using MQTT. This means we will add a policy, a thing and a MQTT connection to Ditto. When Ditto ist set up and working, we will create real world device (“octopus board”) and connect it to it’s digital twin via MQTT.

At the end, we will create a basic frontend webapp. The webapp will automatically connect to Ditto when you type in your credentials, automatically pull your things and show them in a list.
You can create, modify and delete devices in the webapp and if there is a real world device connected to the thing in the list, you can send it a command message to control any feature on it. The list of things will always be up-to-date when you listen to server-sent-events, which you can activate easily with pressing a button.

Eclipse Ditto bidirectional MQTT diagramSource:

We will use an Octopus-board with an ESP8266 on it. It has several sensors built in, but for simplicity we will just use it’s temperature and altitude sensor.
To show the functionality of Eclipse Ditto messages, we will switch on/off a LED on the Octopus-board through it.

If you have any wishes, improvements, are missing something or just want to get in touch with us, you can use one of our feedback channels.


The Eclipse Ditto team

October 16, 2018 04:00 AM

Smart Home Day

by Anonymous at October 13, 2018 04:30 PM

Join us for the second installment of Smart Home Day on 21 October, the Sunday before EclipseCon Europe.

The Smart Home Day focuses specifically on Eclipse SmartHome-based solutions such as openHAB and QIVICON. It is an awesome opportunity for all community members to meet and exchange ideas.

There will be great talks from core project maintainers, solution providers, and other community members. The agenda has been carefully compiled to addresses developers, tech-savvy users, and other smart home enthusiasts alike.

by Anonymous at October 13, 2018 04:30 PM

Ten reasons to use Eclipse Collections

by Donald Raab at October 12, 2018 02:37 AM

You may only need one.

It’s a sign

Top Ten Reasons to use Eclipse collections

  1. Rich, fluent, and functional APIs with good symmetry (productivity)
  2. Memory Efficiency (performance)
  3. Optimized Eager APIs (performance)
  4. Primitive Collections (productivity & performance)
  5. Immutable Collections (predictability and performance)
  6. Lazy APIs (performance)
  7. Parallel APIs (performance)
  8. Multimaps (productivity and type safety)
  9. Bags (productivity and type safety)
  10. Mutable and Immutable Collection Factories (productivity)

If the collection framework(s) you are using today is (are) missing one or more of these features, and you need them, then it would really be worth your time to check out and try Eclipse Collections.

Additional Reasons to try Eclipse Collections

  1. It’s open source and managed at the Eclipse Foundation and you can contribute to the library if there is something you need
  2. Eclipse Collections 9.0, 9.1 and 9.2 were released with a lot useful features that were contributed by 30 members of the open source community
  3. There are fun code katas to get you started
  4. Easy to understand and refactor to if you already know lambdas/ streams
  5. The Eclipse Collections website is available in seven different languages

Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.

Ten reasons to use Eclipse Collections was originally published in Oracle Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Donald Raab at October 12, 2018 02:37 AM

Presentation: "Yo... Ask Me Anything" - Panel of NY Senior Java Developers

by Justin Lee, Don Raab, Chandra Guntur, Sai Sharan Donthi, Jeanne Boyarsky at October 11, 2018 03:28 AM

The panelists discuss thoughts on the latest trends in Java, the new release model, modules, modern garbage collectors, Kotlin for the enterprise, Eclipse stewardship of JEE and the rising complexity of the Java source language.

By Justin Lee, Don Raab, Chandra Guntur, Sai Sharan Donthi, Jeanne Boyarsky

by Justin Lee, Don Raab, Chandra Guntur, Sai Sharan Donthi, Jeanne Boyarsky at October 11, 2018 03:28 AM

JBoss Tools and Red Hat Developer Studio for Eclipse 2018-09

by jeffmaury at October 09, 2018 09:17 AM

JBoss Tools 4.9.0 and Red Hat Developer Studio 12.9 for Eclipse 2018-09 are here waiting for you. Check it out!



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.

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:

spring boot inner loop

Click on the Launcher application link and the following wizard will appear:

spring boot inner loop1

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.

spring boot inner loop2

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:

spring boot inner loop3
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 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:

spring boot inner loop4

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

spring boot inner loop5

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

spring boot inner loop6

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

The Project explorer view is updated:

spring boot inner loop7

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:

spring boot inner loop8

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

spring boot inner loop9

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

spring boot inner loop10

Click on the Change…​ button and enter in the URI field, replacing GITHUB_USER by your real GitHub user name.

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

Pushing code to GitHub

We are now ready to push our application code to GitHub. Select the myfirstrestapp project in the Project explorer view, right click the Team → Commit menu item. A new view call Git Staging will open:

spring boot inner loop11

Double click on the view title to maximize it:

spring boot inner loop12

Select all the files listed in the Unstaged changes list and click the &apos+&apos button. The files will then move to the Staged Changes list:

spring boot inner loop13

Enter a commit message (ex &aposInitial version&apos) and click the Commit and Push…​ button. the following dialog will be displayed:

spring boot inner loop14

Click on the Next button:

spring boot inner loop15

Click on the Finish button to start the push operation.

A dialog with the result of the push operation will be displayed. Click the OK to dismiss it.

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 pom.xml in the myfirstrestapp. Locate the spring-boot-maven-plugin and add the following section:


The whole spring-boot-maven-plugin section is given below:


Close and save the pom.xml file.

Push the change to GitHub: select the Team → Commit…​ with a new commit message (ex &aposWith DevTools&apos)

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

          "apiVersion": "",
          "kind": "ImageStream",
      	"metadata": {
      		"name": "springboot"
          "spec": {
              "lookupPolicy": {
                  "local": false
              "tags": [
                      "annotations": {
      					"tags": "builder,java"
                      "from": {
                          "kind": "DockerImage",
                          "name": ""
                      "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 New → Resource…​ menu item and the following dialog will be displayed:

spring boot inner loop16

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:

spring boot inner loop17

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

spring boot inner loop18
Create the application on OpenShift

We’re now ready to create the application on the OpenShift cluster. Select the OpenShift connection, right click the New → Application…​ menu item. If you scroll down the list, you should see the springboot ImageStream we just created:

spring boot inner loop19

Select this ImageStream and click the Next button:

spring boot inner loop20

Enter `myfirstrestapp in the `Name field, ` in the Git Repository URL field, replacing GITHUB_USER by your real GitHub user name and click the Next`` button.

On the Deployment Configuration & Scalability dialog, click the `Next button.

On the Service & Routing Settings, select the 8778-tcp port and click the Edit button, change the 8787 value to 8080:

spring boot inner loop21

Click the OK button then the Finish button.

The list of OpenShift resources created will be displayed by a dialog:

spring boot inner loop22

Click the OK button to dismiss it and when asked to import the application code, click the Cancel button as we already have the source code.

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:

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

spring boot inner loop24

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

spring boot inner loop25

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/ 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:

       * 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
       * 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 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:

spring boot inner loop26

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 ?

Server tools

Wildfly 14 Server Adapter

A server adapter has been added to work with Wildfly 14. It adds support for Java EE 8.

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.

Fully Editable REST Editor

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.

breadcrumb dark and light

In the Light theme, the Breadcrumb uses a flat look style instead of a gradient.

Quick fix to create abstract methods

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.

quickfix create abstract method 1
Quick fix to convert to static import

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.

quickfix convert to static import

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 Objects.equals and Objects.hash methods.

hashcode equals dialog

The above setup generates the following code:

hashcode equals generation

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.

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.

quickfix open cc page

Selecting this option opens the Compiler Compliance property page for the specified project as shown below.

quickfix cc page
Open Type dialog now always shows the full path

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

open type full path

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 &aposif&apos statements. Different kind of loops (&aposfor&apos, &aposwhile&apos, &aposdo while&apos) can be controlled independently.

The settings can be found in the profile editor under New Lines > In control statements > Simple Loops.

formatter compact 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 (&aposfor&apos, &aposwhile&apos, &aposdo while&apos).

formatter compact loops wrap
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.

formatter align in columns


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.

result timeout 537142

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.

hide running threads
Show Command Line button in Launch Configuration

A new button Show Command Line has been added in the Java Launch Configuration dialog.

show command line

Clicking the button will open a dialog to show the command line used for launching the application.

show command line detail
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

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.

enable classpathonly dialog

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.

enable classpathonly option

And more…​

You can find more noteworthy updates in on this page.

What is next?

Having JBoss Tools 4.9.0 and Red Hat Developer Studio 12.9 out we are already working on the next release for Eclipse 2018-12.


Jeff Maury

by jeffmaury at October 09, 2018 09:17 AM

EclipseSource Oomph Profile – updated to 2018-09

by Jonas Helming and Maximilian Koegel at October 09, 2018 08:10 AM

In September, Eclipse 2018-09 has been released, a new version of the Eclipse IDE and platform. It contains many useful improvements, so it is worth to update. It is the first release following the new release cycle with four equal releases per year. One of many noteworthy extensions is the new minimap view, which provides a complete overview of opened documents. It allows to browser files more efficiently and due to showing the selection, also identifying occurrences of certain expressions, e.g. usages of fields.

EclipseSource Oomph Profile - updated to 2018-09

Further general improvements of the Eclipse 2018-09 IDE are summarized in the following video, Git and Platform improvements in a separate video below.  Both are provided by Holger Voormann, whom we want to thank you once again for this great work!

As always, in case you use our EclipseSource Oomph profile (see here for more details), you should get a notification and Oomph will apply the update automatically. If you do not get the notification, just navigate to the menu entry “Help” => “Perform Set-Up Task”.

This will automatically update all plugins to Photon, but keep all existing settings untouched.

Have fun with Eclipse 2018-09!

by Jonas Helming and Maximilian Koegel at October 09, 2018 08:10 AM

Welcome Jameka

by Thabang Mashologu at October 05, 2018 06:29 PM

I am thrilled to announce that Jameka Woodberry has joined the Eclipse Foundation as a Marketing Specialist based in Europe.

Jameka comes to us from SAP, where she managed marketing programs for the EMEA region. Jameka has an MA in Business Psychology and an MBA in International Business with a focus on Marketing and Communications. Her wonderful personality and ample experience will be great assets to the Eclipse community.

Jameka is originally from California and is currently based in Wiesloch, Germany.  

Please join me in welcoming Jameka to the Eclipse Foundation marketing team.

by Thabang Mashologu at October 05, 2018 06:29 PM

Jakarta EE @EclipseFdn: Getting it done

by waynebeaton at October 03, 2018 06:31 PM

To say that bringing Jakarta EE to life at the Eclipse Foundation was a massive undertaking is a gross understatement.

We started this effort in early 2018. Today, we have 39 open source projects (as part of the EE4J Top Level Project) representing 14% of our overall project space. These projects collectively have 99 Git repositories (most of which are hosted in the eclipse-ee4j GitHub organization; a small number are hosted on Eclipse Foundation infrastructure) representing 8% of the repositories created and managed by the Eclipse Foundation’s IT team. We have 162 committers working on these projects, representing 10% of our total active committer community. These projects have made a combined 440 requests to the Eclipse Foundation’s IP Team to review intellectual property, representing 17% of the work done by the team. The Jakarta EE projects have 53 distinct CI instances running (or in the planning stages to run) on Eclipse Foundation build infrastructure, representing 30% of our work there (on the topic of build, if you have some spare cycles and want to contribute, we can use your help).

Added to the all of the project-related work, we’ve also been doing a lot of other work to  stand up the new Jakarta EE Working Group, bootstrap the new EE4J PMC, manage related trademarks and various legal agreements, recruit participants, build websites, improve infrastructure, hire and train new staff, and more.

By way of comparison, the work that we do with Eclipse IoT is at about the same scale, but grew more organically (one open source project at a time) over six years. Jakarta EE happened all at once.

While we engaged in this enormous chunk of work, we still did everything that we’ve always done. In just the first nine months of 2018, for example, the Eclipse Intellectual Property Team has already received and processed 30% more requests for reviews than they did in all of 2017! And the number of new project proposals, committers, and contributions (not including those that are related to Jakarta EE) that we’ve added in 2018 are on an upward trend compared with past years.

This has been an all-hands-on-deck sort of effort for the Eclipse Foundation staff. Even those of us who have not been directly involved in the work, have helped by taking on extra burdens so that those of use who were directly involved could stay focused.

This is not to say that we’ve done this alone: this has been a ginormous shared effort. We’ve had a lot of help from the Eclipse Foundation member companies that have contributed many talented people to the migration effort, and—of course—the members of our community who have stepped up.

I really want to name names, but the probability of me missing somebody is so high that I dare not. If you want to meet some of the key players, join us at EclipseCon Europe!


by waynebeaton at October 03, 2018 06:31 PM

My first 100 days at the Eclipse Foundation

by Tanja Obradovic at October 03, 2018 01:22 PM

I made it to my first 100 days at the Eclipse Foundation! New beginnings are always exciting. It has been a blast and a challenge at the same time. Many twists and turns, but steady progress nevertheless for both Jakarta EE and me!

My experience at the Eclipse Foundation started with EclipseCon France 2018 in the amazing Toulouse. Clearly, I was always a strong believer in open source as a movement, but meeting people from different companies, and witnessing their enthusiasm in person is something different. As the Eclipse Foundation hosts over 350 different open source projects, the conference attracted not only technology developers, but different industries using them as well. Their presence and interest demonstrated the importance of open source in software development. Jakarta EE, naturally, was one of the highlights of the conference, clearly indicating huge interest of the community in evolving Java EE technology and making it ready for cloud-native Java application development.

At the time, mid-June 2018, it was still very early days for us both. So early that it was hard to contemplate the concrete first steps for Jakarta EE. We hadn’t yet completed migrating the necessary Java EE contributions from Oracle to the Eclipse Foundation, and still struggling with all the legal aspects required in the process. We had initial conversations on the new Specification Process that will fill the role of the Java Community Process, and started looking into the new world with open source TCKs and requirements for the Jakarta EE implementations. And for me, getting familiar with the working group members and its committees, the community members, the existing Eclipse Foundation processes already in use, the processes that need to be defined, and figuring out what to focus on first was a challenge for sure!

Jumping to the fall, not everything is ready, but steady progress has been made. The majority of the Java EE code, including TCKs and GlassFish, found a new home at the Eclipse Foundation. New processes are being developed and the first drafts are ready for internal review. Name spaces are being discussed and even some specifications are being suggested as possible first components under the Jakarta EE specification umbrella. And yes, another Eclipse Foundation conference is just around the corner. EclipseCon Europe 2018 is being actively planned. If you haven’t already, please register! Jakarta EE and MicroProfile Community Day is taking shape and we need your presence and participation.

I am looking forward to finding out what the next 100 days will bring!

by Tanja Obradovic at October 03, 2018 01:22 PM

Eclipse Vert.x 3.5.4

by vietj at October 03, 2018 12:00 AM

We have just released Vert.x 3.5.4, a bug fix release of Vert.x 3.5.x.

Since the release of Vert.x 3.5.3, quite a few bugs have been reported. We would like to thank you all for reporting these issues.

Three CVE have also been reported and fixed in this release:

Vert.x 3.5.4 release notes:

The event bus client using the SockJS bridge are available from NPM, Bower and as a WebJar:

Docker images are also available on the Docker Hub. The Vert.x distribution is also available from SDKMan and HomeBrew.

The artifacts have been deployed to Maven Central and you can get the distribution on Bintray.

Happy coding and see you soon on our user or dev channels.

by vietj at October 03, 2018 12:00 AM

Thorntail - A Micro implementation of Eclipse MicroProfile

by Anonymous at October 02, 2018 02:38 PM

by Ken Finnigan

In this article we introduce some of the topics Michal Szynkiewicz, from the Thorntail team, will be presenting during his EclipseCon session Thorntail - A Micro Implementation of Eclipse MicroProfile. Be sure to come by his session to learn all the details on Eclipse MicroProfile and how to use it in Thorntail!

by Anonymous at October 02, 2018 02:38 PM

Case Study: How Bosch Is Succeeding with Open Source at Eclipse IoT

October 02, 2018 02:00 PM

How is it that a 150-year-old, 400,000 employee industrial conglomerate is competing and winning in the rapidly involving IoT software industry?

October 02, 2018 02:00 PM

Case Study: How Bosch Is Succeeding with Open Source at Eclipse IoT

by Mike Milinkovich at October 02, 2018 12:04 PM

How is it that a 150-year-old, 400,000 employee industrial conglomerate is competing and winning in the rapidly involving IoT software industry? We’ve just published a case study in which Bosch shares how open collaboration at the Eclipse Foundation factors into that success. This case study is required reading for any organization considering pursuing an open source strategy.

This case study is yet another proof point that open source has won. No single company can deliver innovation at the pace and scale of open source. For industrial companies in particular, broadly adopted open technologies and standards are critical for success in the digital economy. It’s a case of disrupt or be disrupted — and open source holds the key for rapid and sustainable innovation in the digital age. The team at Bosch recognized all of this several years ago. When the time came for creating an IoT platform for themselves and their customers, Bosch chose open source to compete with proprietary vendors.

At the Eclipse Foundation, Bosch is successfully executing a long-term strategy to create a widely adopted open source platform for IoT. Having previously been a long-term Solutions member of the Eclipse Foundation, Bosch increased its membership level in the Eclipse Foundation to become a Strategic member and joined the Eclipse IoT Working Group in 2015. Beyond IoT, Bosch is an active participant in the Eclipse Foundation’s Automotive Industry community.

Some of the highlights from the case study (html) (pdf):

  • Bosch’s leadership in the Eclipse IoT community has helped position the company as a leader in the IoT industry.
  • Bosch has created six different IoT open source projects since joining the Eclipse IoT community. In addition, Bosch contributes to many other Eclipse IoT projects.
  • Bosch has contributed around 1.5 million lines of code to Eclipse projects. At present, over 60 Bosch developers work on Eclipse IoT projects.
  • Many of the Bosch IoT Suite commercial products are now based on Eclipse IoT projects. The open development process used by the Eclipse projects has been adopted by Bosch Software Innovations’ product development teams. The open source development model helps Bosch provide more transparency for their customers, and aids in recruiting new developers keen to work on open source.
  • The Eclipse Foundation’s clear, vendor-neutral rules for intellectual property sharing and decision-making make it easy to collaborate with other organizations on driving rapid innovation. The Foundation’s legal processes provide Bosch with the legal assurance that they can successfully embed open source technology into their commercial products.

We are thrilled that Bosch is seeing the benefits of their open source strategy and participation in the Eclipse community. Thanks to the contributions of Bosch engineers and many other developers within the Eclipse community, all can benefit from runtimes and frameworks creating a open, vendor-neutral platform for IoT.

To learn more about the Eclipse IoT community, head over to the Eclipse IoT Working Group website.

by Mike Milinkovich at October 02, 2018 12:04 PM

Eclipse CBI - Common Build Infrastructure changes

September 28, 2018 08:00 PM

The Eclipse CBI, which traces its roots back to 2006, has undergone some important changes recently, including a new Kubernetes+Docker-powered environment at that re announced previously.

September 28, 2018 08:00 PM