Skip to main content

Mysterious Eclipse Collections APIs: forEachInBoth

by Donald Raab at June 26, 2019 01:31 PM

Sometimes APIs go undiscovered for a long time

What is Stonehenge?

Have you ever heard of forEachInBoth?

There is a method named forEachInBoth available in Eclipse Collections, but it can only be found on four utility classes. You can find the method on ArrayIterate, ListIterate, RandomAccessListIterate and ArrayListIterate.

The method forEachInBoth, takes two Lists or Arrays of the same size and iterates over both of them passing the elements from both lists at particular indexes into a two argument procedure.

The method has not been promoted to the ListIterable API in Eclipse Collections. This is probably because you can now zip two lists together and just use forEach or any of the other rich APIs from MutableList instead.

The Method Signatures

The method signatures for forEachInBoth on ListIterate, RandomAccessListIterate and ArrayListIterate are very similar so I will only show the signatures for ListIterate and ArrayIterate.


public static <T1, T2> void forEachInBoth(
List<T1> list1,
List<T2> list2,
Procedure2<? super T1, ? super T2> procedure)


public static <T1, T2> void forEachInBoth(
T1[] objectArray1,
T2[] objectArray2,
Procedure2<? super T1, ? super T2> procedure)

When is forEachInBoth useful?

One example that I discovered that forEachInBoth works well with is for converting two separate lists or arrays into a Map. Using forEachInBoth, I am able to use a method reference for calling put on the map instance. This was unexpectedly cool.

Putting two lists into a Map

The Source

public void forEachInBothList()
List<Integer> one =
Lists.mutable.with(1, 2, 3);
List<String> two =
Lists.mutable.with("One", "Two", "Three");
Map<Integer, String> map = Maps.mutable.empty();

ListIterate.forEachInBoth(one, two, map::put);

Maps.mutable.with(1, "One", 2, "Two", 3, "Three"),

This could easily work with two arrays of the same size using ArrayIterate instead.

What about zip?

If you use zip instead, you can use the fluent API to convert the zipped Lists into a Map using toMap. However, I could not take an existing Map and iterate using forEach or each and call Map.put since I would be iterating over Pair instances that would need to have the the two component parts of the pairs extracted and passed in as the key and value parameters.

Zipping two lists and putting them into a Map using toMap

The Source

public void zipList()
MutableList<Integer> one =
Lists.mutable.with(1, 2, 3);
MutableList<String> two =
Lists.mutable.with("One", "Two", "Three");

MutableMap<Integer, String> map =, Pair::getTwo);

Maps.mutable.with(1, "One", 2, "Two", 3, "Three"),

In the case of zip with this example, there is a temporary List created after zip is called, but it will be garbage collected after the call to toMap since the List is not referenced anywhere. This same code can be implemented lazily by calling asLazy before calling zip. This removes the temporary List creation.

MutableMap<Integer, String> map =
.toMap(Pair::getOne, Pair::getTwo);

When to use forEachInBoth or zip?

The primary benefit of forEachInBoth is that it is located in static utility and will work directly with Java arrays and any java.util.List. So if you need to convert two JDK Lists quickly into a Map, it might just be what the doctor ordered. However, because the method forEachInBoth returns void, you will not be able to make fluent methods calls like you can using zip. Most of the time, you may find zip more useful when dealing with two lists especially if you are performing multiple operations on the result.

If you discover a novel use case where forEachInBoth works well, please let us know by creating an issue on GitHub. We could move forEachInBoth up directly to the ListIterable API if there prove to be more good use cases that we just haven’t seen yet.

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

by Donald Raab at June 26, 2019 01:31 PM

EMF Forms and EMF Client Platform 1.21.0 released!

by Jonas Helming and Maximilian Koegel at June 25, 2019 08:40 PM

We are happy to announce that with the Eclipse Release 2019-06, we have also shipped  EMF Forms and EMF Client Platform...

The post EMF Forms and EMF Client Platform 1.21.0 released! appeared first on EclipseSource.

by Jonas Helming and Maximilian Koegel at June 25, 2019 08:40 PM

Graphical Editing Framework (GEF) 5.1.0 Release

by Tamas Miklossy ( at June 25, 2019 08:00 AM

The Eclipse GEF team is happy to announce that version 5.1.0 of the Eclipse Graphical Editing Framework is part of the Eclipse 2019-06 simultaneous release:




The project team has worked hard since the Eclipse GEF 5.0.0 release two years ago. The new release fixes issues on the GEF MVC, GEF Zest, and GEF DOT components.

We would like to thank all contributors who made this release possible:



Your feedback regarding the new release is highly appreciated. If you have any questions or suggestions, please let us know via the Eclipse GEF forum or create an issue on Eclipse Bugzilla.

For further information, we recommend to take a look at the Eclipse GEF blog articles, watch the Eclipse GEF session on the EclipseCon Europe 2018, and try out the Getting started with Eclipse GEF online tutorial.

by Tamas Miklossy ( at June 25, 2019 08:00 AM

Eclipse ioFog: Evolving Toward Native Kubernetes Orchestration at the Edge

June 24, 2019 06:00 PM

The Eclipse Foundation is excited to support today's announcement of the initial availability of Eclipse ioFog features that make any Kubernetes distribution edge-aware.

June 24, 2019 06:00 PM

Bringing IoT to Red Hat AMQ Online

by Jens Reimann at June 24, 2019 07:47 AM

Red Hat AMQ Online 1.1 was recently announced, and I am excited about it because it contains a tech preview of our Internet of Things (IoT) support. AMQ Online is the “messaging as service solution” from Red Hat AMQ. Leveraging the work we did on Eclipse Hono allows us to integrate a scalable, cloud-native IoT personality into this general-purpose messaging layer. And the whole reason why you need an IoT messaging layer is so you can focus on connecting your cloud-side application with the millions of devices that you have out there.

This post was originally published on Red Hat Developers, the community to learn, code, and share faster. To read the original post, click here.

What is Eclipse Hono™?

Eclipse Hono is an IoT abstraction layer. It defines APIs in order to build an IoT stack in the cloud, taking care of things like device credentials, protocols, and scalability. For some of those APIs, it comes with a ready-to-run implementation, such as the MQTT protocol adapter. For others, such as the device registry, it only defines the necessary API. The actual implementation must be provided to the system.

Eclipse Hono IoT architecture overviewEclipse Hono overview

A key feature of Hono is that it normalizes the different IoT-specific protocols on AMQP 1.0. This protocol is common on the data center side, and it is quite capable of handling the requirements on throughput and back-pressure. However, on the IoT devices side, other protocols might have more benefits for certain use cases. MQTT is a favorite for many people, as is plain HTTP due to its simplicity. LoRaWAN, CoAP, Sigfox, etc. all have their pros and cons. If you want to play in the world of IoT, you simply have to support them all. Even when it comes to custom protocols, Hono provides a software stack to easily implement your custom protocol.

AMQ Online

Hono requires an AMQP 1.0 messaging backend. It requires a broker and a component called “router” (which doesn’t own messages but only forwards them to the correct receiver). Of course, it expects the AMQP layer to be as scalable as Hono itself. AMQ Online is a “self-service,” messaging solution for the cloud. So it makes sense to allow Hono to run on top of it. We had this deployment model for a while in Hono, allowing the use of EnMasse (the upstream project of AMQ Online).

Self-service IoT

In a world of Kubernetes and operators, the thing that you are actually looking for is more like this:

kind: IoTProject
   name: iot
   namespace: myapp
         name: iot
         plan: standard-unlimited
           plan: standard-small-anycast
           plan: standard-small-queue
           plan: standard-small-anycast

You simply define your IoT project, by creating a new custom resource using kubectl create -f and you are done. If you have the IoT operator of AMQ Online 1.1 deployed, then it will create the necessary address space for you, and set up the required addresses.

The IoT project will also automatically act as a Hono tenant. In this example, the Hono tenant would be myapp.iot, and so the full authentication ID of e.g. sensor1 would be sensor1@myapp.iot. The IoT project also holds all the optional tenant configuration under the section .spec.configuration.

With the Hono admin tool, you can quickly register a new device with your installation (the documentation will also tell you how to achieve the same with curl):

# register the new context once with 'hat'
hat context create myapp1 --default-tenant myapp.iot https://$(oc -n messaging-infra get routes device-registry --template='{{ }}')

# register a new device and set credentials
hat reg create 4711
hat cred set-password sensor1 sha-512 hono-secret --device 4711

With that, you can simply use Hono as always. First, start the consumer:

# from the hono/cli directory
export MESSAGING_HOST=$(oc -n myapp get addressspace iot -o jsonpath={.status.endpointStatuses[?(\'messaging\')].externalHost})

mvn spring-boot:run$MESSAGING_HOST,--hono.client.port=$MESSAGING_PORT,--hono.client.username=consumer,--hono.client.password=foobar,,--hono.client.trustStorePath=target/config/hono-demo-certs-jar/tls.crt,--message.type=telemetry

And then publish some data to the telemetry channel:

curl -X POST -i -u sensor1@myapp.iot:hono-secret -H 'Content-Type: application/json' --data-binary '{"temp": 5}' https://$(oc -n enmasse-infra get routes iot-http-adapter --template='{{ }}')/telemetry

For more detailed instructions, see: Getting Started with Internet of Things (IoT) on AMQ Online.

IoT integration

As mentioned before, you don’t do IoT just for the fun of it (well, maybe at home, with a Raspberry Pi, Node.js, OpenHAB, and mosquitto). But when you want to connect millions of devices with your cloud backend, you want to start working with that data. Using Hono gives you a pretty simple start. Everything you need is an AMQP 1.0 connectivity. Assuming you use Apache Camel, pushing telemetry data towards a Kafka cluster is as easy as (also see ctron/hono-example-bridge):

<route id="store">
  <from uri="amqp:telemetry/myapp.iot" />

  <setHeader id="setKafkaKey" headerName="kafka.KEY">

  <to uri="kafka:telemetry?brokers={{kafka.brokers}}" />

Bringing together solutions like Red Hat Fuse, AMQ and Decision Manager makes it a lot easier to give your custom logic in the data center (your value add‑on) access to the Internet of Things.

What’s next?

AMQ Online 1.1 is the first version to feature IoT as a tech preview. So, give it a try, play with it, but also keep in mind that it is a tech preview.

In the upstream project EnMasse, we are currently working on creating a scalable, general purpose device registry based on Infinispan. Hono itself doesn’t bring a device registry, it only defines the APIs it requires. However, we think it makes sense to provide a scalable device registry, out of the box, to get you started. In AMQ Online, that would then be supported by using Red Hat Data Grid.

In the next months, we hope to also see the release of Eclipse Hono 1.0 and graduate the project from the incubation phase. This is a big step for a project at Eclipse but also the right thing to do. Eclipse Hono is ready, and graduating the project means that we will pay even closer attention to APIs and stability. Still, new features like LoRaWAN, maybe Sigfox, and a proper HTTP API definition for the device registry, are already under development.

So, there are lots of new features and enhancements that we hope to bring into AMQ Online 1.2.

The post Bringing IoT to Red Hat AMQ Online appeared first on ctron's blog.

by Jens Reimann at June 24, 2019 07:47 AM

Eclipse ioFog: Evolving Toward Native Kubernetes Orchestration at the Edge

by Mike Milinkovich at June 23, 2019 08:46 PM

With the proliferation of AI, autonomous vehicles, 5G, IoT, and other industrial use cases that require lightning-fast data processing, edge computing has emerged over the past few years as a way to address the limitations of existing cloud architectures to process information and deliver services at the “IoT edge”. Instead of backhauling data to the centralized cloud, edge computing brings computational power closer to data sources to support near real-time insights and local actions while reducing network bandwidth and storage requirements.

According to Gartner, 75% of enterprise-generated data will be created and processed outside a traditional centralized data center or cloud by 2025. While the problems at the IoT edge — connectivity, manageability, scalability, reliability, security — are being solved as point solutions by enterprises and ecosystem players, there is a need for a foundational industry-wide standard for managing distributed IoT workloads. Time and again, open source has been proven to be the best way to deliver complex platform software with industrial scale collaboration.

Enter Kubernetes, the de facto standard for orchestrating containers and the applications running inside them. Kubernetes has massive potential for handling IoT workloads on the edge by providing a common control plane across hybrid cloud and edge environments to simplify management and operations. Within the Kubernetes IoT Edge Working Group, members of the Kubernetes and Eclipse communities are collaborating with leading technology innovators to extend Kubernetes to support dynamically, securely, and remotely managing edge nodes.

A great example of this collaboration is Eclipse ioFog, a universal Edge Compute Platform which offers a standardized way to develop and remotely deploy secure microservices to edge computing devices. ioFog can be installed on any hardware running Linux and provides a universal runtime for microservices to dynamically run on the edge. Companies in different vertical markets such as retail, automotive, oil and gas, telco, and healthcare are using ioFog to turn any compute device into an edge software platform.

The Eclipse Foundation is excited to support today’s announcement of the initial availability of ioFog features that make any Kubernetes distribution edge-aware. With this latest release, developers are able to extend Kubernetes to easily deploy, secure, and manage edge computing networks supporting applications such as advanced AI and machine learning algorithms.

Farah Papaioannou, co-founder and president of Edgeworx, explains the significance of the release this way:

“ioFog is a proven platform at the edge. With this release, we build on native Kubernetes, seamlessly extending it to the edge…We do this based on things that actually matter at the edge, such as latency, location or resources. We are delivering today a full cloud-to-edge solution, that’s 100-percent open source and works with any Kubernetes flavors and distros.”

These native Kubernetes enhancements are in the process of being contributed to the Eclipse ioFog open source project. We are proud to support the collective efforts of the Eclipse community and the Kubernetes ecosystem to help developers deploy, manage, and orchestrate applications and microservices from cloud to edge in a simple and secure manner.

For more information about ioFog, get started by using this link to install and set up your production ioFog environment. If you have questions or want to connect with other people involved in this platform, join the ioFog community and the mailing list.

by Mike Milinkovich at June 23, 2019 08:46 PM

Become a Sponsor at EclipseCon Europe 2019!

June 21, 2019 04:00 PM

We're gearing up for EclipseCon Europe 2019, our biggest event of the year which brings together developers, architects, and open source business leaders.

June 21, 2019 04:00 PM

Update for Jakarta EE community: June 2019

June 20, 2019 05:05 PM

Get the latest monthly email update on the Jakarta EE community from news highlights to various meetings and events related to the platform!

June 20, 2019 05:05 PM

Update for Jakarta EE community: June 2019

by Tanja Obradovic at June 20, 2019 02:01 PM

Last month, we launched a monthly email update for the Jakarta EE community which seeks to highlight news from various committee meetings related to this platform. We have also decided to publish these updates as blogs and share the information that way as well. There are a few ways to get a grip on the work that has been invested in Jakarta EE so far, so if you’d like to learn more about Jakarta EE-related plans and get involved in shaping the future of cloud native Java, read on.

Without further ado, let’s have a look at what has happened in May:

Jakarta EE 8 release and progress

Jakarta EE 8 will be fully compatible with Java EE 8, including use of the javax namespace. The process of driving the Jakarta EE 8 specifications, as well as delivery of the Jakarta EE 8 TCKs, and Jakarta EE 8 compatible implementations will be transparent.

Mike Milinkovich recently published a FAQ about Jakarta EE 8, in which he offered answers to questions such as  

  • Will Jakarta EE 8 break existing Java EE applications that rely upon javax APIs?

  • What will Jakarta EE 8 consist of?

  • Will there be Jakarta EE 8 compatible implementations?

  • What is the process for delivery of Jakarta EE 8

  • When will Jakarta EE 8 be delivered?

Read Mike’s blog to find out what to expect from the Jakarta EE 8 release.

We need your help with the work on Jakarta EE 8 release. Project teams please get involved in the Eclipse EE4J projects and help out with  Jakarta Specification Project Names and Jakarta Specification Scope Statements.

If you’d like to get involved in the work for the Jakarta EE Platform, there are a few projects that require your attention, namely the Jakarta EE 8 Platform Specification, which is meant to keep track of the work involved with creating the platform specification for Jakarta EE 8, Jakarta EE 9 Platform Specification, intended to keep track of the work involved with creating the platform specification for Jakarta EE 9 and Jakarta EE.Next Roadmap Planning, which seeks to define a roadmap and plan for the Jakarta EE 9 release.

Right now, the fastest way to have a say in the planning and preparation for the Jakarta EE 9 release is by getting involved in the Jakarta EE.Next Roadmap Planning.

Election schedule for Jakarta EE working group committees

The various facets of the Jakarta EE Working Group are driven by three key committees for which there are elected positions to be filled: the Steering Committee, the Specification Committee, and the Marketing and Brand Committee. The elected positions are to represent each of the Enterprise Members, Participant Members, and Committer Members. Strategic Members each have a representative appointed to these committees.  

The Eclipse Foundation is holding elections on behalf of the Jakarta EE Working Group using the following proposed timetable:  

Nomination period:  May 24 - June 4 (self-nominations are welcome)

Election period:  June 11 - June 25

Winning candidates announced:  June 27

All members are encouraged to consider nominating someone for the positions, and self-nominations are welcome. The period for nominations runs through June 4th.  Nominations may be sent to

Once nominations are closed, all working group members will be informed about the candidates and ballots will be distributed via email to those eligible to vote.  The election process will follow the Eclipse “Single Transferable Vote” method, as defined in the Eclipse Bylaws.  

The winning candidates will be announced on this mailing list immediately after the elections are concluded.  

The following positions will be filled as part of this election:

Steering Committee

Two seats allocated for Enterprise Members

One seat allocated for Participant Members

One seat allocated for Committer Members

Specification Committee

Two seats allocated for Enterprise Members

One seat allocated for Participant Members

One seat allocated for Committer Members

Marketing and Brand Committee

Two seats allocated for Enterprise Members

One seat allocated for Participant Members

One seat allocated for Committer Members

Transitioning Jakarta EE to the jakarta namespace

The process of migrating Java EE to the Eclipse Foundation has been a collaborative effort between the Eclipse Foundation staff and the many contributors, committers, members, and stakeholders that are participating. Last month, it was revealed that the javax package namespace will not be evolved by the Jakarta EE community and that Java trademarks such as the existing specification names will not be used by Jakarta EE specifications. While these restrictions were not what was originally expected, it might be in Jakarta EE’s best interest as the modification of javax would always have involved long-term legal and trademark restrictions.

In order to evolve Jakarta EE, we must transition to a new namespace. In an effort to bootstrap the conversation, the Jakarta EE Specification Committee has prepared two proposals (Big-bang Jakarta EE 9, Jakarta EE 10 new features and incremental change in Jakarta EE 9 and beyond) on how to make the move into the new namespace smoother. These proposals represent a starting point, but the community is warmly invited to submit more proposals.

Community discussion on how to transition to the jakarta namespace concluded Sunday, June 9th, 2019.

We invite you to read a few blogs on this topic:

2019 Jakarta EE Developer Survey Results

The Eclipse Foundation recently released the results of the 2019 Jakarta EE developer survey that canvassed nearly 1,800 Java developers about trends in enterprise Java programming and their adoption of cloud native technologies. The aim of the survey, which was conducted by the Foundation in March of 2019 in cooperation with member companies and partners, including the London Java Community and Java User Groups, was to help Java ecosystem stakeholders better understand the requirements, priorities, and perceptions of enterprise Java developer communities.

A third of developers surveyed are currently building cloud native architectures and another 30 percent are planning to within the next year. Furthermore, the number of Java applications running in the cloud is expected to increase significantly over the next two years, with 32 percent of respondents hoping to run nearly two-thirds of their Java applications in the cloud in two years’ time. Also, over 40 percent of respondents are using the microservices architecture to implement Java in the cloud.

Access the full findings of the 2019 Java Community Developer Survey here.

Community engagement

The Jakarta EE community promises to be a very active one, especially given the various channels that can be used to stay up-to-date with all the latest and greatest. Tanja Obradovic’s blog offers a sneak peek at the community engagement plan, which includes

For more information about community engagement, read Tanja Obradovic’s blog.

Jakarta EE Wiki

Have you checked out the Jakarta EE Wiki yet? It includes important information such as process guidelines, documentation, Eclipse guides and mailing lists, Jakarta EE Working Group essentials and more.  

Keep in mind that this page is a work in progress and is expected to evolve in the upcoming weeks and months. The community’s input and suggestions are welcome and appreciated!

Jakarta EE Community Update: May video call

The most recent Jakarta EE Community Update meeting took place in May; the conversation included topics such as the Jakarta EE progress so far, Jakarta EE Rights to Java Trademarks, the transition from javax namespace to the jakarta namespace (mapping javax to jakarta, when repackaging is required and when migration to namespaces is not required) and how to maximize compatibility with Java EE 8 and Jakarta EE for future versions without stifling innovation, the Jakarta EE 8 release, PMC/ Projects update and more.

The minutes of the Jakarta EE community update meeting are available here and the recorded Zoom video conversation can be found here.  

Jakarta EE presence at conferences: May overview

Cloud native was the talk of the town in May. Conferences such as JAX 2019, Red Hat Summit 2019 and KubeCon + CloudNativeCon Europe 2019 were all about cloud native and how to tap into this key approach for IT modernization success and the Eclipse Foundation was there to take a pulse of the community to better understand the adoption of cloud native technologies.

Don’t forget to check out Tanja Obradovic’s video interview about the future of Jakarta EE at JAX 2019.  

EclipseCon Europe 2019: Call for Papers open until July 15

It’s that time of year again! You can now submit your proposals to be part of EclipseCon Europe 2019’s speaker lineup. The conference takes place in Ludwigsburg, Germany on October 21 - 24, 2019. Early bird submissions are due July 1, and the final deadline is July 15. Check out Jameka's blog and submit your talk today!

We are also working on JakartaOne Livestream conferencescheduled for September 10th. Call for Papers are open until July 1st

Thank you for your interest in Jakarta EE. Help steer Jakarta EE toward its exciting future by subscribing to the mailing list and by joining the Jakarta EE Working Group.

To learn more about the collaborative efforts to build tomorrow’s enterprise Java platform for the cloud, check out the Jakarta Blogs and participate in the monthly Jakarta Tech Talks. Don’t forget to subscribe to the Eclipse newsletter!  

by Tanja Obradovic at June 20, 2019 02:01 PM

Eclipse Handly 1.2 Released

by Vladimir Piskarev at June 19, 2019 06:50 PM

Eclipse Handly 1.2 has just been released. This release is focused on further enhancements to UI components. Particularly, it provides a framework for creating a full-featured Call Hierarchy view.

New and Noteworthy
Migration Guide

by Vladimir Piskarev at June 19, 2019 06:50 PM

WTP 3.14 Released!

June 19, 2019 03:14 PM

The Eclipse Web Tools Platform 3.14 has been released! Installation and updates can be performed using the Eclipse IDE 2019-06 Update Site or through the Eclipse Marketplace . Release 3.14 is included in the 2019-06 Eclipse IDE for Enterprise Java Developers , with selected portions also included in 9 other packages . Adopters can download the R3.14 update site itself directly and combine it with the necessary dependencies.

More news

June 19, 2019 03:14 PM

Xtext 2.18 – released!

by Sebastian Zarnekow ( at June 18, 2019 10:31 AM

The team around project lead Christian Dietrich has released version 2.18 of Xtext and Xtend. This version is also the one that enters the Eclipse release train number 2019-06, departing on time at June 19th.

More than 40 helping hands have made this Xtext release possible over the last quarter. A big shout-out especially to the first-time contributors! We are thankful for every reported issue, comment to a discussion, and proposed patch.

Even though the main focus was on stability and robustness, a couple of new features have been made available, too.


Playing catch-up with Java

Xtend eventually learned to understand the ternary expression and got support for try-with-resources. While the former is just expressing a matter of taste, being able to efficiently deal with closable resources is a big win. Forgetting to close a stream or a connection is just a little harder when you can benefit from the compiler auto-closing the thing. This is also available in legacy scenarios where code is still required to run on ancient Java versions.

Both features were implemented by Eva Poell, intern for 6 weeks at our Berlin office. We are thankful for her great work!

Improved “find references” view

When exploring a code base, software engineers navigate back and forth through the source, especially between references and declarations. If you want to take notes on the usage of a DSL concept, you can copy it directly from the “search results” page. Also, if you only want to deal with a subset of the results, it’s now possible to remove matches from the view.


Improved Find References View

New quick fixes for the Xtext grammar

The Xtext grammar editor received some love in this release cycle, too. The validation problems around invalid empty keywords can be automatically fixed from now on. Either a reasonable default is inserted, or the keyword is removed – it’s your call.

Xtext Grammar Editor

Rename refactoring

Long-running rename operations can now be cancelled by the user. Instead of waiting for the computation to finish and reverting the outcome, accidentally triggered renames are no longer a painful experience.

Rename class quick fix

Talking about renames: Even though Xtend allows to define as many public types per file as you want, it is a common usage pattern to have a single top-level class per file. If names get out of sync because of a change of mind, a quick fix is offered to align the two of them. If you decide to rename the type, a proper rename operation is triggered, and all the references are updated along with the declaration.

Language server fixes

The Xtext support for the Language Server Protocol has been improved in different areas. Extension implementations do now have access to the indexed resources, and the reporting of build results was fixed. Formerly, some notifications may have got lost such that the editors did not get any events about completed builds. The communication in the other direction was fixed, too. Sometimes the server did miss a couple of changed resources, thus its index information diverged from the code on disk.

Eclipse robustness

A few rarely-occurring issues around the startup of Eclipse and the processing of deleted projects have been fixed. It did not happen often, but if you were bitten by that bug, it was rather annoying. These issues have been resolved.

Your turn

The team is proud of the achievements in this release cycle. But we are also eager to know what your thoughts on this are. If you are missing a certain feature or do have suggestions how to improve Xtext or Xtend, just drop us a note and we are happy to discuss your ideas.

by Sebastian Zarnekow ( at June 18, 2019 10:31 AM

JCP Copyright Licensing request

by Tanja Obradovic at June 17, 2019 06:20 PM

The open source community has welcomed Oracle’s contribution of Java EE into Eclipse Foundation, under the new name Jakarta EE. As part of this huge effort and transfer, we want to ensure that we have the necessary rights so we can evolve the specifications under the new  Jakarta EE Specification Process. For this, we need your help!

We must request copyright licenses from all past contributors to Java EE specifications under the JCP. Hence, we are reaching out to all companies and individuals who made contributions to Java EE in the past to help out, execute the agreements and return them back to Eclipse Foundation. As the advancement of the specifications and the technology is in question, we would greatly appreciate your prompt response. Oracle, Red Hat, IBM, and many others in the community have already signed an agreement to license their contributions to Java EE specifications to the Eclipse Foundation. We are also counting on the JCP community to be supportive of this request.

The request is for JCP contributors to Java EE specifications, once you receive an email from the Eclipse Foundation regarding this, please get back to us as soon as you can!

Should you have any questions regarding the request for copyright licenses from all past contributors, please contact who is leading us all through this process.

Many thanks!

by Tanja Obradovic at June 17, 2019 06:20 PM

Eclipse Individual Committer Agreement 4.0 Update

June 17, 2019 02:05 PM

On June 13th, we retired all versions of the Eclipse Individual Committer Agreement (ICA) prior to version 4.0. Update yours today!

June 17, 2019 02:05 PM

Eclipse Introduces New IDE-Agnostic Tools for Building and Deploying Cloud-Native Applications

by Dustin Schultz at June 17, 2019 05:35 AM

Eclipse Codewind is a new developer-centric project from the Eclipse Foundation that aims to assist developers by providing ways to quickly and consistently accomplish tasks that are common to cloud-native application development.

By Dustin Schultz

by Dustin Schultz at June 17, 2019 05:35 AM

My new book on TDD, Build Automation and Continuous Integration

by Lorenzo Bettini at June 12, 2019 04:59 PM

I haven’t been blogging for some time now. I’m getting back to blogging by announcing my new book on TDD (Test-Driven Development), Build Automation and Continuous Integration.

The title is indeed, “Test-Driven Development, Build Automation, Continuous Integration
(with Java, Eclipse and friends)
” and can be bought from

The main goal of the book is to get you started with Test-Driven Development (write tests before the code), Build Automation (make the overall process of compilation and testing automatic with Maven) and Continuous Integration (commit changes and a server will perform the whole build of your code). Using Java, Eclipse and their ecosystems.

The main subject of this book is software testing. The main premise is that testing is a crucial part of software development. You need to make sure that the software you write behaves correctly. You can manually test your software. However, manual tests require lots of manual work and it is error prone.

On the contrary, this book focuses on automated tests, which can be done at several levels. In the book we will see a few types of tests, starting from those that test a single component in isolation to those that test the entire application. We will also deal with tests in the presence of a database and with tests that verify the correct behavior of the graphical user interface.

In particular, we will describe and apply the Test-Driven Development methodology, writing tests before the actual code.

Throughout the book we will use Java as the main programming language. We use Eclipse as the IDE. Both Java and Eclipse have a huge ecosystem of “friends”, that is, frameworks, tools and plugins. Many of them are related to automated tests and perfectly fit the goals of the book. We will use JUnit throughout the book as the main Java testing framework.

it is also important to be able to completely automate the build process. In fact, another relevant subject of the book is Build Automation. We will use one of the mainstream tools for build automation in the Java world, Maven.

We will use Git as the Version Control System and GitHub as the hosting service for our Git repositories. We will then connect our code hosted on GitHub with a cloud platform for Continuous Integration. In particular, we will use Travis CI. With the Continuous Integration process, we will implement a workflow where each time we commit a change in our Git repository, the CI server will automatically run the automated build process, compiling all the code, running all the tests and possibly create additional reports concerning the quality of our code and of our tests.

The code quality of tests can be measured in terms of a few metrics using code coverage and mutation testing. Other metrics are based on static analysis mechanisms, inspecting the code in search of bugs, code smells and vulnerabilities. For such a static analysis we will use SonarQube and its free cloud version SonarCloud.

When we need our application to connect to a service like a database, we will use Docker a virtualization program, based on containers, that is much more lightweight than standard virtual machines. Docker will allow us to

configure the needed services in advance, once and for all, so that the services running in the containers will take part in the reproducibility of the whole build infrastructure. The same configuration of the services will be used in our development environment, during build automation and in the CI server.

Most of the chapters have a “tutorial” nature. Besides a few general explanations of the main concepts, the chapters will show lots of code. It should be straightforward to follow the chapters and write the code to reproduce the examples. All the sources of the examples are available on GitHub.

The main goal of the book is to give the basic concepts of the techniques and tools for testing, build automation and continuous integration. Of course, the descriptions of these concepts you find in this book are far from being exhaustive. However, you should get enough information to get started with all the presented techniques and tools.

I hope you enjoy the book 🙂

by Lorenzo Bettini at June 12, 2019 04:59 PM

JBoss Tools 4.12.0.AM1 for Eclipse 2019-06

by jeffmaury at June 12, 2019 11:05 AM

Happy to announce 4.12.0.AM1 (Developer Milestone 1) build for Eclipse 2019-06.

Downloads available at JBoss Tools 4.12.0 AM1.

What is New?

Full info is at this page. Some highlights are below.

Server Tools

Wildfly 17 Server Adapter

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


Jeff Maury

by jeffmaury at June 12, 2019 11:05 AM

Eclipse Tycho: Disable p2 dependency resolution with tycho.mode=maven

by kthoms at June 12, 2019 01:31 AM

In Eclipse Tycho based builds the first step is always computation of the target platform and depedency resolution. This takes quite some time and in certain use cases it is not necessary. Typical use cases are updating versions with the tycho-versions-plugin, or displaying the effective pom with help:effective-pom.

The p2 target platform & dependency resolution can be skipped by setting the tycho-mode system property:

mvn -Dtycho.mode=maven <goals>

This useful feature is a bit hidden in just a few posts, e.g.

by kthoms at June 12, 2019 01:31 AM

2019 Annual Eclipse Foundation Community Report

June 11, 2019 06:05 PM

Read the eighth annual Eclipse Foundation Community Report! Comments and feedback on the style and content are welcome!

June 11, 2019 06:05 PM

Welcome Shabnam!

by Thabang Mashologu at June 05, 2019 09:13 AM

I am happy to announce that Shabnam Mayel has joined the Eclipse Foundation as a Senior Marketing Lead, Cloud Native Java. 

Shabnam brings with her several years of diverse marketing, business development, and technical sales experience. Most recently, she led marketing and brand management initiatives for tech startups in Southeast Asia. She holds an electronics engineering degree, an MBA and a Ph.D. in management. She is based in Toronto.

Shabnam will be responsible for developing and implementing global marketing programs to grow the awareness of and participation in Jakarta EE, Eclipse MicroProfile, and other Foundation projects in the cloud native application space.

Please join me in welcoming Shabnam to the Eclipse community!

by Thabang Mashologu at June 05, 2019 09:13 AM

Back to the top