Skip to main content

Measuring bundle startup time with JFR

February 22, 2020 10:20 PM

Several years ago, I gave a presentation at EclipseCon 2016 on “Optimising Eclipse Plug-ins” in which I talked about a few different ways of making Eclipse faster, at least from a start-up and memory usage perspective.

The presentation wasn’t recorded, but is available on SpeakerDeck as well as a narrated copy I recorded subsequently at Vimeo.

One of the techniques I discussed was using Java Flight Recorder as a means to record how long bundles take to start up, since the main cost of starting up Eclipse (or other OSGi applications) is how long it takes for the bundles to move into the STARTED state. Bundles that have a Bundle-Activator can slow this down, and since the majority of OSGi frameworks have a means to start up bundles sequentially, can lead to a lesser user experience.

At the original time of writing, JFR was still a commercial feature (requiring -XX:+UnlockCommercialFeatures setting and the wrath of licensing) in Java 8, and the API was evolving in Java 9 and onwards. However, now that Java 11 has been released, we have a free (both as in beer and in speech) implementation that we can code against in order to work as expected.

A number of API changes meant that the code needed some TLC, and so I recently uploaded a new version of the JFRBundleListener project to GitHub. The project can be downloaded and installed into an OSGi runtime (or Eclipse application) to find out where the start-up costs lie. At the present time, I have not published it anywhere for binary consumption.

The contains more information about how to use it, but the TL;DR is:

  • Build and install the bundle with a low start level (e.g. 1) so that it tracks all subsequent bundle activation
  • Start your OSGi framework or Eclipse application with the magic invocation to start JFR recording, e.g. -XX:StartFlightRecording=filename=/tmp/dump.jfr,dumponexit=true,disk=true
  • Load and inspect the recording into Java Mission Control, or use the embedded java -jar JFRBundleListener.jar < /tmp/dump.jfr > /tmp/stacks.txt to generate a stacks list that can be processed by
  • Use Brendan Gregg’s flamegraph tool to create an interactive SVG --hash --countname ms < /tmp/stacks.txt > /tmp/bundles.svg

The resulting SVG looks something like this:

Bundle startup

Custom JFR events

The API for interacting with JFR has improved significantly since its first inception in Java 8. I am looking forward to the backport of Java 11 to Java 8 to improve the experience significantly there.

To create a custom event, subclass the jdk.jfr.Event class. Provided that it has public fields of a known Java primitive or String, it will be written out when commanded. The JFRBundleEvent class is used to surface an OSGi BundleEvent, and so persists pertinent data to the JFRBundleEvent class upon creation.

These are created when receiving (synchronous) events with the SynchronousBundleListener implemented in the JFRBundleListener class. To mark a span, the event has begin() called at the start of a bundle coming on-line, and end() once it has finished. The commit() ensures that this bundle event is recorded; provided that the commit() occurs at some point later, and that the object is not reused in the meantime, it could be done at a later time.

The event information is recorded with specific key fields; they are identified using the field name in the class, or the one specified with the @Name annotation as defined in the event itself. For simplicity, I have chosen the OSGi bundle headers as the identifiers in the event, which may make post-processing it easier.

Processing JFR files

Similarly, the API for processing a JFR file has become significantly better. There is a helper method RecordingFile.readAllEvents() which translates a dump file at a given path into a list of RecordedEvent objects, or it can be used as an iterator to read through all events.

Events are identified by type; if not specified then the fully qualified name of the event class is used. This makes it easy to filter out specific events from the log, although it may be desirable that they are combined with other JFR events (e.g. thread sleeping, class loading, garbage collections etc.) in the log.

The JFRFlameGraph implementation provides a means to go through the log file, and generate a stack of bundle startup to allow for investigation as to why something is taken so long.

It prunes the list of events in the JFR recording to only include those JFRBundleEvent of interest, and then builds up a sorted data structure based on the earliest start-up time recorded. These are then interactively popped off to write out events before the end time, so that the resulting file contains a list of the bundles starting up:

Start-Level...;org.eclipse.ui.trace;org.eclipse.core.runtime;org.eclipse.equinox.preferences 28
Start-Level...;org.eclipse.ui.trace;org.eclipse.core.runtime;org.eclipse.core.contenttype;org.eclipse.equinox.registry 877
Start-Level...;org.eclipse.ui.trace;org.eclipse.core.runtime;org.eclipse.core.contenttype 6
Start-Level...;org.eclipse.ui.trace;org.eclipse.core.runtime; 28
Start-Level...;org.eclipse.ui.trace;org.eclipse.core.runtime 14
Start-Level...;org.eclipse.ui.trace 10
Start-Level...;org.eclipse.update.configurator 977

These can then be post-processed with to generate the interactive SVG above.

The code prepends the Java thread name to the stack shown; this allows some threads (such as background Worker-n threads) to be ignored, while focussing on specific threads (such as the main thread and the Start-Level... thread). Since the SVG is interactive, clicking on the thread name will focus the view on just those bundles, which may provide more detailed analysis.


Java Flight Recorder is available as open source in Java 11, and can be used to export timing information using a custom event format. With sufficient post-processing of the data, it can generate flame graphs that can be more expressive than just looking at numbers.

The API for programmatically interacting with JFR recordings has been significantly improved, and being able to log timely information in conjunction with other events can be a significant bonus in performance analysis.

February 22, 2020 10:20 PM

Postmortem - February 7 storage and authentication outage

by Denis Roy at February 20, 2020 04:12 PM

On Friday, February 7 2020, suffered a severe service disruption to many of its web properties when our primary authentication server and file server suffered a hardware failure.

For 90 minutes, our main website,, was mostly available, as was our Bugzilla bug tracking tool, but logging in was not possible. Wiki, Eclipse Marketplace and other web properties were degraded. Git and Gerrit were both completely offline for 2 hours and 18 minutes. Authenticated access to Jiro -- our Jenkins+Kubernetes-based CI system, was not possible, and builds that relied on Git access failed during that time.

There was no data loss, but there were data inconsistencies. A dozen Git repositories and Gerrit code changes were in an inconsistent state due to replication schedules, but thanks to the distributed nature of Git, the code commits were still in local developer Git repositories, as well as on the failed server, which we were eventually able to revive (in an offline environment). Data inconsistencies were more severe in our LDAP accounts database, where dozens of users were unable to log in, and in some isolated cases, users reported that their account was reverted back to old data from years prior.

In hindsight, we feel this outage could have, and should have been avoided. We’ve identified many measures we must enact to prevent such unplanned outages in the future. Furthermore, our communication and incident handling processes proved to be flawed, and will be scrutinized and improved, to ensure our community is better informed during unplanned incidents.

Lastly, we’ve identified aging hardware and Single Points of Failure (SPoF) that must be addressed.


File server & authentication setup

At the center of the Eclipse infra is a pair of servers that handle 2 specific tasks:

  • Network Attached Storage (NAS) via NFS

  • User Authentication via OpenLDAP

The server pair consists of a primary system, which handles all the traffic, and a hot spare. Both servers are configured identically for production service, but the spare server sits idly and receives data periodically from the primary. This specific architecture was originally implemented in 2005, with periodical hardware upgrades over time.


Timeline of events

Friday Feb 7 - 12:33pm EST: Fred Gurr (Eclipse Foundation IT/Releng team) reports on the Foundation’s internal Slack channel that something is happening to the Infra. Denis observes many “Flaky” status reports on but is in transit and cannot investigate further. Webmaster Matt Ward investigates.

12:43pm: Matt confirms that our primary nfs/ldap server is not responding, and activates “Plan A: assess and fix”.

12:59pm: Denis reaches a computer and activates “Plan B: prepare for Failover” while Matt works on Plan A. The “Sorry, we are down” page is served for all Flaky services except, which continues to be served successfully by our nginx cache.

1:18pm: The standby server is ready to assume the “primary” role.

1:29pm: Matt makes the call for failover, as the severity of the hardware failure is not known, and not easily recoverable.

1:49pm:, Bugzilla, Marketplace, Wiki return to stable service on the new primary.

2:18pm: Git and Gerrit return to stable service.

2:42pm: Our Kubernetes/OpenShift cluster is updated to the latest patchlevel and all CI services restarted.

4:47pm: All legacy JIPP servers are restarted, and all other remaining services report functional.  At this time, we are not aware of any issues.

During the weekend, Matt continues to monitor the infra. Authentication issues crop up over the weekend, which are caused by duplicated accounts and are fixed by Matt.

Monday, 4:49am EST: Mikaël Barbero (Eclipse Foundation IT/Releng team) reports that there are more duplicate users in LDAP that cannot log into our systems. This is now a substantial issue. They are fixed systematically with an LDAP duplicate finder, but the process is very slow.

10:37am: First Foundation broadcast on the cross-project mailing list that there is an issue with authentication.

Tuesday, 9:51am: Denis blogs about the incident and posts a message to the mailing list about the ongoing authentication issues. The message, however, is held for moderation and is not distributed until many hours later.

Later that day: Most duplicated accounts have been removed, and just about everything is stabilized. We do not yet understand the source of the duplicates.

Wednesday: duplicate removals continue, as well as investigation into the cause.

Thursday 9:52am: We file a dozen bugs against projects whose Git and Gerrit repos may be out of sync. Some projects had already re-pushed or rebased their missing code patches and resolved the issue as FIXED.

Friday, 2:58pm: All remaining duplicates are removed. Our LDAP database is fully cleaned. The failed server re-enters production as the hot standby - even though its hardware is not reliable. New hardware is sourced and ordered.


Hardware failure

The physical servers assuming our NAS/LDAP setup are server-class hardware, 2U chassis with redundant power supplies, ECC (error checking and correction) memory, RAID-5 disk arrays with a battery-backup RAID controller memory. Both primary and standby servers were put into production in 2011.

On February 7, the primary server experienced a kernel crash from the RAID controller module. The RAID controller detected an unrecoverable ECC memory error. The entire server became unresponsive.

As originally designed in 2005, periodical (batched) data updates from the primary to the hot spare were simple to set up and maintain. This method also had a distinct advantage over live replication: rapid recovery in case of erasure (accidental or malicious) or data tampering. Of course, this came at a cost of possible data loss. However, it was deemed that critical data (in our case, Source Code) susceptible to loss during the short time was also available on developer workstations.

Failover and return to stability

As the standby server was prepared for production service, the reasons for the crash on the primary server were investigated. We assessed the possibility of continuing service on the primary; that course of action would have provided the fastest recovery with the fewest surprises later on.

As the nature of the hardware failure remained unknown, failover was the only option. We confirmed that some data replication tasks had run less than one hour prior to failure, and all data replication was completed no later than 3 hours prior. IP addresses were updated, and one by one, services that depended on NFS and authentication were restarted to flush caches and minimize any potential for an inconsistent state.

At about 4:30pm, or four hours after the failure, both webmasters were confident that the failover was successful, and that very little dust would settle over the weekend.

Authentication issues

Throughout the weekend, we had a few reports of authentication issues -- which were expected, since we failed over to a standby authentication source that was at least 12 hours behind the primary. These issues were fixed as they were reported, and nothing seemed out of place.

On Monday morning, Feb 10th, the Foundation’s Releng team reported that several committers had authentication issues to the CI systems. We then suspected that something else was at play with our authentication database, but it was not clear to us what had happened, or what the magnitude was. The common issue was duplicate accounts -- some users had an account in two separate containers simultaneously, which prevented users from being able to authenticate. These duplicates were removed as rapidly as we could, and we wrote scripts to identify old duplicates and purge them -- but with >450,000 accounts, it was time-consuming.

At that time, we got so wrapped up in trying to understand and resolve the issue that we completely underestimated its impact on the community, and we were absolutely silent about it.


Problem solved

On Friday afternoon, February 14, we were able to finally clean up all the duplicate accounts and understand why they existed in the first place.

Prior to December, 2011, our LDAP database only contained committer accounts. In December 2011, we imported all the non-committer accounts from Bugzilla and Wiki into an LDAP container we named “Community”. This allowed us to centralize authentication around a single source of truth: LDAP.

All new accounts were, and are created in the Community container, and are moved into the Committer container if/when they became an Eclipse Committer.

Our primary->secondary LDAP sync mechanism was altered, at that time, to sync the Community container as well -- but it was purely additive. Once you had an account in Community, it was there for life on the standby server, even if you became a committer later on. Or if you’d ever change your email address. This was the source of the duplicate accounts on the standby server.

A new server pair has been ordered on February 14, 2020 . These servers will be put into production service as soon as possible, and the old hardware will be recommissioned to clustered service. With these new machines, we believe our existing architecture and configuration can continue to serve us well over the coming months and years.


Take-aways and proposed improvements

Although the outage didn’t last incredibly long (2 hours from failure to the beginning of restored service), we feel it shouldn’t have occurred in the first place. Furthermore, we’ve identified key areas where our processes can be improved - notably, in how we communicate with you.

Here are the action items we’re committed to implementing in the near term, to improve our handling of such incidents:

  • Communication: Improved Service Status page. gives a picture of what’s going on, but with an improved service, we can communicate the nature of outages, the impact, and estimated time until service is restored.

  • Communication: Internally, we will improve communication within our team and establish a maintenance log, whereby members of the team can discover the work that has been done.

  • Staffing: we will explore the possibility of an additional IT hire, thus enhancing our collective skillset, and enabling more overall time on the quality and reliability of the infra.

  • Aging Hardware: we will put top-priority on resolving aging SPoF, and be more strict about not running hardware devices past their reasonable life expectancy.

    • In the longer term, we will continue our investment in replacing SPoF with more robust technologies. This applies to authentication, storage, databases and networking.

  • Process and procedures: we will allocate more time to testing our disaster recovery and business continuity procedures. Such tests would likely have revealed the LDAP sync bug.

We believe that these steps will significantly reduce unplanned outages such as the one that occured on February 7. They will also help us ensure that, should a failure occur, we recover and return to a state of stability more rapidly. Finally, they will help you understand what is happening, and what the timelines to restore service are, so that you can plan your work tasks and remain productive.

by Denis Roy at February 20, 2020 04:12 PM

Git Contribution Activity Charts for Eclipse Projects

by waynebeaton at February 18, 2020 05:57 PM

Eclipse EGit: Git Integration for Eclipse

This post is brought to you today by the Eclipse EGitâ„¢ Project. Eclipse EGit is the Eclipse open source project that provides Git integration for the Eclipse Platform.

On Eclipse open source project pages (which we often refer to as the Project Management Interface or “PMI”), the “Who’s Involved” pages include some commit activity graphs.

The Contribution Activity chart shows the absolute number of commits made on project repositories over the last twelve months. Eclipse open source projects may have multiple Git repositories; this chart shows commit activity across all branches on all repositories owned by the project team.

The Individual Contribution Activity chart shows the commits attributed to individual developers over the last three months (across all repositories and branches). The identify of the individual committer comes directly from the author field in the Git commit. For project committers, we map author credentials to the information that committers provide in their Eclipse Foundation Account, so–for committers–the name shown here will match what’s in their account, not what’s on the commit record.

Note that any developer listed as an “Also-by” in the commit message will get credit for the commit (“Some Bodyelse”, from the example shown below, would share author credit for the commit). Because of the “Also-by” folks being counted as authors/contributors, some commits may be represented multiple times in the Individual Contribution Activity and Organization Contribution Activity charts (once each for each author).

If you click on a committer’s picture on the “Who’s Involved” page, you’ll see a chart of lifetime contributions to the project. If the chart is missing, that means that the person hasn’t authored any commits.

The Organization Contribution Activity chart shows relative contributions from Eclipse Foundation member companies. Commits made by all project committers affiliated with the company (across all project Git repositories and branches) are grouped together.

On this chart, “Other Committer” groups together contributions from committers who do not work for a member company, and “Contributor” refers to activity by contributors (i.e., developers who are not yet not committers).

Active Member Companies are those Eclipse Foundation member companies that have at least on committer that has made at least one commit on the project in the last three months (note that the order is random).

These charts take a very narrow view of “contribution”. There are many ways to contribute to an open source project. You can answer questions on forums or mailing lists, open and comment on issues, present at conferences, …

by waynebeaton at February 18, 2020 05:57 PM

Developer Surveys Survey: Including a Spotlight on Java Results

by Alex Blewitt at February 17, 2020 06:00 PM

JRebel and Snyk have recently published their Java/JVM technology reports, and Codingame and Tiobe have published reports into language usage and adoption. InfoQ looks at the state of play of these reports, and what is happening in the Java and wider ecosystems today.

By Alex Blewitt

by Alex Blewitt at February 17, 2020 06:00 PM

Eclipse Collections 10.2 Released

by Donald Raab at February 16, 2020 06:47 PM

Thank you to the contributors and our user community.

Eclipse Collections Website — Now published in Greek!

Release on Demand

It’s been about two and a half months since we released Eclipse Collections 10.1. We had a user request for a new release with a specific feature, so we decided to release another minor version. Version 10.2 is now released.

You can now download the release from Maven Central.



A new website translation is available

After the New Year we now have a contribution of a Greek translation of our Eclipse Collections website. This is an amazing addition to our growing number of website translations. Our website is now available in nine different languages. We have offers for two more language translations in the works. Thank you!

New Features

  • Exposed the allocateTable method as protected in Primitive Maps and Primitive Sets.

Bug Fixes

  • Fixed size edge case issues in Interval and IntInterval.

Tech Debt Reduction

  • Optimized removeIf on UnifiedMap.
  • Implemented removeIf as a default method on MutableMapIterable.
  • Replaced usages of Comparators.nullSafeEquals() with Objects.equals().

Thank you

From all the contributors and committers… thank you for using Eclipse Collections!

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 February 16, 2020 06:47 PM

Java Streams are great but it’s time for better Java Collections

by Donald Raab at February 13, 2020 01:47 AM

After 25 years, it’s time for Java to get a Collections to upgrade.

Java Streams and Collections Birds of a Feather Session from JavaOne 2014

25 Years of Java

This year will mark the 25th anniversary of the Java programming language. In March 2020, we will celebrate the 6th anniversary of the release of Java 8 which included Lambdas, Method References, Default Methods, and Java Streams.

Java 8 was and is still amazing. After 19 years without support for Lambdas, Java developers were suddenly enjoying amazing productivity gains with several great additions to the language and core libraries. Java Streams are extremely helpful and satisfy a large number of uses cases. They have also given Java content authors plenty to write about, and Java conference speakers plenty to talk about.

While the Java Collections framework has been greatly augmented with the new functionality in Java Streams, Java Streams are unfortunately hiding even greater productivity gains, increased type safety and improvements in performance.

Let’s explore why after 25 years, it is time for a better and more modern Java Collections framework. To see some of what we are still missing in Java, we can look to the past.

40 Years of Smalltalk

Forty years ago, Smalltalk-80 was released. Smalltalk has influenced so much that we use on a daily basis in modern programming languages and software development techniques like TDD and Refactoring.

Smalltalk is a dynamically typed object-oriented programming language. Smalltalk has a simple syntax that can fit on a post card, and a large feature rich class library. I programmed professionally in Smalltalk from 1994–2000 while employed by IBM Global Services working at Horizon Blue Cross Blue Shield of New Jersey. Smalltalk shaped the way I think about programming over the past 25 years, and has directly impacted how I design and program in Java.

I believe one of the most overlooked features of Smalltalk is its rich Collections framework. Smalltalk collections have an organized and easy to learn hierarchy.

Smalltalk Collection Hierarchy

The concrete collections in Smalltalk have simple factory methods for creating them (with:) and certain collection types like arrays and strings had literal syntax. In the screen shot below I create a Set, OrderedCollection (akaList), Bag, Array, String, Dictionary (aka Map) and Interval using Pharo Smalltalk. Smalltalk is a live programming environment. In Smalltalk, you can highlight code anywhere and execute it or inspect the results and view them in an inspector.

Factory methods and literal syntax for creating Smalltalk collections

The collection APIs in Smalltalk are very rich, and many of the common APIs are defined a the root of the hierarchy in the Collection class.

APIs including select:, reject:, collect:, detect:, inject:into: available on all Collection types

To understand how rich the Smalltalk Collection API is, I have captured a mindmap for the Pharo Smalltalk Collection class showing major method categories and individual APIs. I really miss method categories in Java, as it is a great way to organize larger APIs. Every subclass of Collection inherits all of these common behaviors.

Smalltalk Collection class API

Smalltalk has had lambdas and a feature rich collections framework now for over 40 years — 40 years! After 25 years the JDK still does not have the same level of functionality available directly on the collections.

There are options available in the Java open source community.

16 Years of better Collections in Java

I started developing a library named Caramel while working in Goldman Sachs in 2004. In 2012, the library was open sourced as GS Collections on GitHub. In 2015 it was migrated to the Eclipse Foundation and became Eclipse Collections.

Updated: I found a link to a talk I gave at the JVM Language Summit in July 2012 titled “A Java collections framework design”. In the talk I compared the collections frameworks in Java, Scala, Smalltalk and GS Collections.

The Eclipse Collections framework was inspired from the the Smalltalk Collections framework. Eclipse Collections has factory classes which provide a consistent way of creating collections.

Eclipse Collections also provides a rich API, with most methods defined in a parent interface named RichIterable. The methods available directly on the collections are eager by default. Methods which return collections such as select, reject and collect are co-variant in Eclipse Collections.

Compare this with the Smalltalk example above

There is a lazy API available in Eclipse Collections by calling asLazy.

The mutable types in Eclipse Collections extend the equivalent Collection types in Java.

  • MutableList extends java.util.List
  • MutableSet extends java.util.Set
  • MutableMap extends java.util.Map
  • MutableBag extends java.util.Collection

This means that methods like stream and parallelStream are also available on the Eclipse Collections types.

Eclipse Collections comes with a Collectors2 class with equivalent Collector implementations to those found in Collectors but that return Eclipse Collections types.

If you want to see visualizations of the Eclipse Collections library, there are many available in the following blog.

Visualizing Eclipse Collections

Comparing Collection base classes in Java

So what is the difference between Eclipse Collections and the JDK Collections framework? In the image below I have calculated the difference and intersection of the MutableCollection and java.util.Collection APIs using method names without parameters, so overloaded methods are excluded.

Eclipse Collection MutableCollection compared to java.util.Collection

Note: MutableCollection extends RichIterable, which is where a lot of the behaviors for the class are inherited from.

There are a lot more features available on MutableCollection. These features result directly in productivity gains for Java developers. The MutableCollection class extends java.util.Collection so the intersections above include all of the methods in java.util.Collection and from java.lang.Iterable.

What are Java Collections missing today?

  1. Functional and fluent APIs directly on the collections
  2. Memory Efficiency
  3. Optimized Eager APIs — Learn about eager vs. lazy here
  4. Primitive Collections for all primitive types
  5. Contractually Immutable Collections
  6. Lazy Iterable APIs for object and primitive collections
  7. A *distinct* Parallel Iterable Hierarchy
  8. Multimaps
  9. Bags
  10. BiMaps
  11. Mutable and Immutable Collection Factories
  12. 64-bit collections (size is long, arrays are 64-bit)

Past is present and future is now

We have a lot we can still learn in Java from Smalltalk. Smalltalk was (arguably still is) way ahead of its time. Adding additional syntax in newer versions of the Java language may be useful, but we need to build much better support in the base class libraries like the Collections framework. I hope to see many of these classic collections features added in a future version of Java. Java is a great development platform, and an updated Collections framework will make Java even better.

Let’s make Java even better for the next 25 years.

If you’re eager for these features today, there is no need to wait. You can increase your productivity and joy of programming by using Eclipse Collections right now. Eclipse Collections is available as a library in Maven Central, and has no dependencies. Eclipse Collections is an open source project at the Eclipse Foundation, which is where it gets the name prefix of Eclipse. Eclipse Collections is not related to or dependent on the Eclipse IDE and it works in any Java library, application or IDE that supports Java 8 or above.

Note: If you are still using Java 5,6 or 7, there is still hope. Eclipse Collections 7.x versions should work just fine for you. This version also works fine with Java 8. We’ve been enjoying the rich collections features of Smalltalk since JDK 1.4, which is what was available when I created the the first set of classes in the original Caramel library back in 2004.

Thank you to all of our users, contributors, committers, advocates and friends for supporting our journey in open source for the past 8 years! Your contributions, support and feedback fuels our motivation to make Eclipse Collections even better. We are working to help make the Java platform the best platform to program in for the next 25 years. Help wanted!

I am a Project Lead and Committer for the Eclipse Collections OSS project at the Eclipse Foundation. Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.

Other Useful Resources for learning Java you may like
10 Things Java Programmer Should Learn in 2020
10 Free Courses to Learn Java from Scratch
10 Books to Learn Java in Depth
10 Tools Every Java Developer Should Know
10 Reasons to Learn Java Programming languages
10 Frameworks Java and Web Developer should learn in 2020
10 Tips to become a better Java Developer in 2020
Top 5 Java Frameworks to Learn in 2020
10 Testing Libraries Every Java Developer Should Know

Mix the sources, but keep the right balance between research and practice. And good luck to you chasing your goals, of course :)

The 2020 Java Developer RoadMap

Java Streams are great but it’s time for better Java Collections was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Donald Raab at February 13, 2020 01:47 AM

Specification Project Committer Agreements

by waynebeaton at February 12, 2020 06:36 PM

We identified a hole in our committer agreement process that excluded individuals with a certain employment status from participating in Eclipse Foundation open source specification projects operating under the Eclipse Foundation Specification Process (EFSP).

I’ll start by saying that you don’t need to be a committer to contribute to an open source specification project (in fact, notwithstanding the initial bootstrapping of a new open source project team, you cannot become a committer without first demonstrating merit as a contributor). If you just want to make a contribution in the form (for example) of a chunk of text in a specification document or a new method in an API, you can sign the Eclipse Contributor Agreement, create a pull request (the column in grey below) for review by a committer (the pull request can only be merged by a committer), and you’re off to the races!

After making a habit of contributing high quality contributions, an existing project committer may (I might argue should or must) nominate you to be a committer via election.

Specification Project Agreement Selection Flow

Elections generally run for a full week (they will end immediately when all existing project committers vote in the affirmative). Following a successful election, you will be put into our committer agreement workflow: the Eclipse Foundation’s system will send you, the newly elected committer, an email with the instructions you need to provide us with agreements we need to instate you as a committer (we refer to this as the “committer paperwork” process).

If you work for an Eclipse Foundation member company that is a participant in the working group, then we already have all of the agreements that we need and you’re good-to-go.

If you’re self employed, unemployed, or a student, we need you to sign the individual working group participation agreement (IWGPA). This agreement embeds the Individual Committer Agreement and Membership Agreement that are required to participate in a specification project. Once you’ve signed the IWGPA and have provided it to the EMO Records team, they’ll set you up as a committer and you’re good-to-go.

If you work for an Eclipse Foundation member company but that company is not a participant in the working group, or you work for a company that is not a member of the Eclipse Foundation at all, then you need to sign the individual working group participation agreement (IWGPA), and your employer needs to sign the Employer Consent Agreement for Eclipse Foundation Specification Projects (which we shorten to “Employer Consent Agreement” or just “Consent Agreement). This is the part highlighted in red in the above Specification Project Agreement Selection Flow chart.

Our committer provisioning process is automated. As a new committer, you will—following your successful election—be contacted by the EMO Records team by email to engage in our agreement workflow which guides you through signing those agreements that you need. These agreements are all available for your review on our Legal Resources page. The working group-specific agreements are on our Explore our Working Groups page.

Note that in order to get committer rights on a project hosted on GitHub, you need to set your GitHub Id in your Eclipse Foundation account.

The Employer Consent Agreement is the new bit. Due to the differences in the way that intellectual property flows are managed in a specification project (vs. a software project), we need this employer agreement. This agreement must be signed on behalf of the company, so—if you need one of these—you have to identify somebody within your organization with the authority to sign on behalf of the organisation (your manager will likely be able to help you with this).


  • Step 1: Sign the ECA;
  • Step 2: Establish a pattern of contributing high-quality pull requests to an Eclipse open source specification project
  • Step 3: Get voted in to join the project by the existing committers;
  • Step 4: Complete the necessary working group participation agreements; and
  • Step 5: Take your place in history.

by waynebeaton at February 12, 2020 06:36 PM

Anatomy of a server failure

by Denis Roy at February 11, 2020 02:51 PM

Last Friday, Feb 7 at around 12:30pm (Ottawa time), I received a notification from Fred Gurr (part of our release engineering team) that something was going on with the infra. The multitude of colours on the Eclipse Service Status page confirmed it -- many of our services and tools were either slow, or unresponsive.

After some initial digging, we discovered that the primary backend file server (housing Git, Gerrit, web session data, and a lot of files for our various web properties) was not responding. It was also host to our accounts database -- the center for all user authentication.

Jumping into action

It's a well-rehearsed routine for colleage Matt Ward and I -- he worked on assessing the problem and identifying the fix, while I worked on Plan B - failover to our hot standby. At around 1:35pm, roughly 1 hour into the outage, Matt made the call -- failover is the only option, as a  hardware component has failed. 20 minutes later, most services had either recovered or were well on their way.

But the failover is not perfect. Data is sync'ed every 2 hours. Account and authentication info is replicated nightly. This was a by-design strategy decision, as it offers us a recovery window in case of data erasure, corruption or unauthenticated access.

Lessons learned

The failed server was put in service in 2011, celebrating its *gasp* ninth year of 24/7 service. That is a few years too many, and although it (and its standby counterpart) were slated for replacement in 2017, the effort was pushed back to make room for competing priorities. In a moment of bitter irony, the failed hardware was planned to be replaced in the second quarter of this year -- mere months away. We gambled with the house, we lost.

Cleaning up

Today, there is much dust to settle. Our authentication database has some gremlins that we need to fix, and there could be a few missing commits that were not replicated.

We also need to source replacement hardware for the failed component, so that we can re-enable our hot standby. At the same time, we need to immediately source replacement servers for those 2011 dinosaurs. They've served us well, but their retirement is long overdue.

by Denis Roy at February 11, 2020 02:51 PM

IOTA and the Eclipse Foundation Launch Working Group to Develop Commercial Applications on Distributed Ledger Technology

February 11, 2020 01:00 PM

New Tangle EE Working Group Brings Together Fifteen Diverse Organizations to Foster Data and Payment Innovation on Distributed Ledger Technology (DLT)

February 11, 2020 01:00 PM

Interfacing null-safe code with legacy code

by Stephan Herrmann at February 06, 2020 07:38 PM

When you adopt null annotations like these, your ultimate hope is that the compiler will tell you about every possible NullPointerException (NPE) in your program (except for tricks like reflection or bytecode weaving etc.). Hallelujah.

Unfortunately, most of us use libraries which don’t have the blessing of annotation based null analysis, simply because those are not annotated appropriately (neither in source nor using external annotations). Let’s for now call such code: “legacy”.

In this post I will walk through the options to warn you about the risks incurred by legacy code. The general theme will be:

Can we assert that no NPE will happen in null-checked code?

I.e., if your code consistently uses null annotations, and has passed analysis without warnings, can we be sure that NPEs can only ever be thrown in the legacy part of the code? (NPEs inside legacy code are still to be expected, there’s nothing we can change about that).

Using existing Eclipse versions, one category of problems would still go undetected whereby null-checked code could still throw NPE. This has been recently fixed bug.

Simple data flows

Let’s start with simple data flows, e.g., when your program obtains a value from legacy code, like this:


You shouldn’t be surprised, the javadoc even says: “The method returns null if the property is not found.” While the compiler doesn’t read javadoc, it can recognize that a value with unspecified nullness flows into a variable with a non-null type. Hence the warning:

Null type safety (type annotations): The expression of type ‘String’ needs unchecked conversion to conform to ‘@NonNull String’

As we can see, the compiler warned us, so we are urged to fix the problem in our code. Conversely, if we pass any value into a legacy API, all bad that can happen would happen inside legacy code, so nothing to be done for our mentioned goal.

The underlying rule is: legacy values can be safely assigned to nullable variables, but not to non-null variables (example Properties.getProperty()). On the other hand, any value can be assigned to a legacy variable (or method argument).

Put differently: values flowing from null-checked to legacy pose no problems, whereas values flowing the opposite direction must be assumed to be nullable, to avoid problems in null-checked code.

Enter generics

Here be dragons.

As a minimum requirement we now need null annotations with target TYPE_USE (“type annotations”), but we have this since 2014. Good.


Here we obtain a List<String> value from a Legacy class, where indeed the list names is non-null (as can be seen by successful output from names.size()). Still things are going south in our code, because the list contained an unexpected null element.

To protect us from this problem, I marked the entire class as @NonNullByDefault, which causes the type of the variable names to become List<@NonNull String>. Now the compiler can again warn us about an unsafe assignment:

Null type safety (type annotations): The expression of type ‘List<String>’ needs unchecked conversion to conform to ‘List<@NonNull String>’

This captures the situation, where a null value is passed from legacy to null-checked code, which is wrapped in a non-null container value (the list).

Here’s a tricky question:

Is it safe to pass a null-checked value of a parameterized type into legacy code?

In the case of simple values, we saw no problem, but the following example tells us otherwise once generics are involved:

Again we have a list of type List<@NonNull String>, so dereferencing values obtained from that list should never throw NPE. Unfortunately, the legacy method printNames() succeeded to break our contract by inserting null into the list, resulting in yet another NPE thrown in null-checked code.

To describe this situation it helps to draw boundaries not only between null-checked and legacy code, but also to draw a boundary around the null-checked value of parameterized type List<@NonNull String>. That boundary is breached when we pass this value into legacy code, because that code will only see List<String> and happily invoke add(null).

This is were I recently invented a new diagnostic message:

Unsafe null type conversion (type annotations): The value of type ‘List<@NonNull String>’ is made accessible using the less-annotated type ‘List<String>’

By passing names into legacy code, we enable a hidden data flow in the opposite direction. In the general case, this introduces the risk of NPE in otherwise null-checked code. Always?


Java would be a much simpler language without wildcards, but a closer look reveals that wildcards actually don’t only help for type safety but also for null-safety. How so?

If the legacy method were written using a wildcard, it would not be (easily) possible to sneak in a null value, here are two attempts:

The first attempt is an outright Java type error. The second triggers a warning from Eclipse, despite the lack of null annotations:

Null type mismatch (type annotations): ‘null’ is not compatible to the free type variable ‘?’

Of course, compiling the legacy class without null-checking would still bypass our detection, but chances are already better.

If we add an upper bound to the wildcard, like in List<? extends CharSequence>, not much is changed. A lower bound, however, is an invitation for the legacy code to insert null at whim: List<? super String> will cause names.add() to accept any String, including the null value. That’s why Eclipse will also complain against lower bounded wildcards:

Unsafe null type conversion (type annotations): The value of type ‘List<@NonNull String>’ is made accessible using the less-annotated type ‘List<? super String>’

Comparing to raw types

It has been suggested to treat legacy (not null-annotated) types like raw types. Both are types with a part of the contract ignored, thereby causing risks for parts of the program that still rely on the contract.

Interestingly, raw types are more permissive in the parameterized-to-raw conversion. We are generally not protected against legacy code inserting an Integer into a List<String> when passed as a raw List.

More interestingly, using a raw type as a type argument produces an outright Java type error, so my final attempt at hacking the type system failed:



We have seen several kinds of data flow with different risks:

  • Simple values flowing checked-to-legacy don’t cause any specific headache
  • Simple values flowing legacy-to-checked should be treated as nullable to avoid bad surprises. This is checked.
  • Values of parameterized type flowing legacy-to-checked must be handled with care at the receiving side. This is checked.
  • Values of parameterized type flowing checked-to-legacy add more risks, depending on:
    • nullness of the type argument (@Nullable type argument has no risk)
    • presence of wildcards, unbounded or lower-bounded.

Eclipse can detect all mentioned situations that would cause NPE to be thrown from null-checked code – the capstone to be released with Eclipse 2020-03, i.e., coming soon …

by Stephan Herrmann at February 06, 2020 07:38 PM

Sparkplug: Standardizing Industrial IoT Communications

February 06, 2020 06:40 PM

With the launch this week of the Sparkplug Working Group, we’re bringing together the industry leaders and technologies needed to drive...

February 06, 2020 06:40 PM

Eclipse and Handling Content Types on Linux

by Mat Booth at February 06, 2020 03:00 PM

Getting deep desktop integration on Linux.

by Mat Booth at February 06, 2020 03:00 PM

Sparkplug: Standardizing Industrial IoT Communications

by Mike Milinkovich at February 06, 2020 01:08 PM

With the launch this week of the Sparkplug Working Group, we’re bringing together the industry leaders and technologies needed to drive development and broad adoption of the Eclipse Sparkplug specification for open, interoperable, Industrial IoT (IIoT) solutions that use the MQTT protocol.

MQTT is an open and lightweight publish-subscribe messaging protocol that was first developed in the late 1990s for real-time message transport in Supervisory Control and Data Acquisition (SCADA) systems. Because it’s designed for low-bandwidth, low-power environments, it’s ideal for IIoT and industrial automation applications that rely on data from massive numbers of sensors.

Sparkplug Augments MQTT With IIoT Interoperability Essentials

Today, MQTT is the dominant messaging protocol for IIoT applications, but it doesn’t define the data format and it doesn’t address issues around device compatibility and interoperability — capabilities that are essential in IoT environments where all device and software services must share a common data format and support the same life cycle stages of device information.

The Sparkplug specification will resolve these issues. It will define an MQTT topic namespace, payload, and session state management approach that can be applied generically. The goal is to provide standardization for most MQTT devices out of the box so vendors, manufacturers, and industrial end users can develop an ecosystem of solutions and devices that can easily interoperate.

Broad Support Across Industries

With the Sparkplug Working Group’s focus on specifications and implementations that rationalize industrial data and improve the interoperability and scalability of IIoT solutions, companies in industries ranging from oil and gas to energy, manufacturing, and smart cities will have an overall framework to support their evolution to Industry 4.0.

The breadth and stature of the Sparkplug Working Group’s founding members confirm the huge need for industrial system interoperability and the value of the Sparkplug initiative across industries. Founding members include global leaders, such as Chevron, Canary Labs, Cirrus Link Solutions, HiveMQ, Inductive Automation, and ORing.

These companies, and others, are embracing Sparkplug to take IIoT applications to the next level with MQTT implementations that provide valuable, real-time information in a highly reliable, scalable, and secure way.

Get Involved With Sparkplug

I’m very excited about the huge potential and opportunities that will open up for everyone involved in IIoT and industrial automation as the Sparkplug Working Group pushes forward to standardize MQTT device communications. This is truly transformative technology, and I want to sincerely thank all of the corporations and individuals who have brought us to this point.

To get involved with the Eclipse Sparkplug Working Group and contribute to the project, please visit

Also, the Eclipse Foundation and our member companies will be showcasing the Sparkplug Working Group at the ARC Advisory Group’s 24th Annual Industry Forum, February 3-6 in Orlando. If you’re at the Forum, be sure to drop by Inductive Automation’s booth (booth #25) to learn more.

by Mike Milinkovich at February 06, 2020 01:08 PM

Jakarta EE Community Update February 2020

by Tanja Obradovic at February 05, 2020 07:21 PM

With the Jan 16 announcement that we’re targeting a mid-2020 release for Jakarta EE9, the year is off to a great start for the entire Jakarta EE community. But, the Jakarta EE 9 release announcement certainly wasn’t our only achievement in the first month of 2020.

Here’s a look at the great progress the Jakarta EE community made in January, along with some important reminders and details about events you won’t want to miss.


The Java EE Guardians Are Now the Jakarta EE Ambassadors

The rebranding is complete and the website has been updated to reflect the evolution. Also note that the group’s:

·  Twitter handle has been renamed to @jee_ambassadors

·  Google Group has been renamed to!forum/jakartaee-ambassadors

Everyone at the Eclipse Foundation and in the Jakarta EE community is thrilled the Java EE Guardians took the time and effort to rebrand themselves for Jakarta EE. I’d like to take this opportunity to thank everyone involved with the Jakarta EE Ambassadors for their contributions to the advancement of Jakarta EE. As Eclipse Foundation Executive Director, Mike Milinkovich, noted, “The new Jakarta EE Ambassadors are an important part of our community, and we very much appreciate their support and trust.”

I look forward to collaborating with the Jakarta EE Ambassadors to drive the success and growth of the Jakarta EE community. I’d also like to encourage all Jakarta EE Ambassadors to start using the new logo to associate themselves with the group.


Java User Groups Will Be Able to Adopt a Jakarta EE Specification

We’re working to enable Java User Groups (JUGs) to become actively involved in evolving the Jakarta EE Specification through our adopt-a-spec program.

In addition to being Jakarta EE contributors and committers, JUG members that adopt-a-spec will be able to:

·  Blog about the Specification

·  Tweet about the Specification

·  Write an end-to-end test web application, such as Pet Store for Jakarta EE

·  Review the specification and comment on unclear content

·  Write additional tests to supplement those we already have

We’ll share more information and ideas for JUG groups, organizers, and individuals to get involved as we finalize the adopt-a-spec program details and sign up process.


We’re Improving Opportunities for Individuals in the Jakarta EE Working Group

Let me start by saying we welcome everyone who wants to get involved with Jakarta EE! We’re fully aware there’s always room for improvement, and that there are issues we don’t yet know about. If you come across a problem, please get in touch and we’ll be happy to help.

We recently realized we’ve made it very difficult (read impossible) for individuals employed by companies that are neither Jakarta EE Working Group participants nor Eclipse Foundation Members to become committers in Jakarta EE Specification projects.

We’re working to address the problem for these committers and are aiming to have a solution in place in the coming weeks. In the meantime, these individuals can become contributors.

We’ve provided the information below to help people understand the paperwork that must be completed to become a Jakarta EE contributor or a committer. Please look for announcements in the next week or so about the.


It’s Time to Start Working on Jakarta EE 9               

Now that the Jakarta EE 9 Release Plan is approved, it’s time for everyone in the Jakarta EE community to come together and start working on the release.

Here’re link that can help you get informed and motivate you to get involved!

·  Start with the Jakarta EE Platform specification page.

·  Access the files you need on the Jakarta EE Platform GitHub page.

·  Monitor release progress here.


All Oracle Contributed Specifications Are Now Available for Jakartification

We now have the copyright for all of the Java EE specifications that Oracle contributed so we need the community’s help with Jakartification more than ever. This is the only way the Java EE specifications can be contributed to Jakarta EE. 

To help you get started:

·      The Specification Committee has created a document that explains how to convert Java EE specifications to Jakarta EE.

·      Ivar Grimstad provided a demo during the community call in October. You can view it here.


Upcoming Events

Here’s a brief look at two upcoming Jakarta EE events to mark on your calendar.

·      JakartaOne Livestream – Japan, February 26

This event builds on the success of the JakartaOne Livestream event in September 2019. Registration for JakartaOne Livestream – Japan is open and can be accessed here. Please keep in mind this entire event will be presented in Japanese. For all the details, be sure to follow the event on Twitter @JakartaOneJPN.

·  Cloud Native for Java Day at KubeCon + CloudNativeCon Amsterdam, March 30

Cloud Native for Java (CN4J) Day will be the first time the best and brightest minds from the Java ecosystem and the Kubernetes ecosystem come together at one event to collaborate and share their expertise. And, momentum is quickly building.

To learn more about this ground-breaking event, get a sense of the excitement surrounding it, and access the registration page, check out these links:

o   Eclipse Foundation’s official announcement

o   Mike Milinkovich’s blog

o   Reza Rahman’s blog

In addition to CN4J day at KubeCon, the Eclipse Foundation will have a booth #S73 featuring innovations from our Jakarta EE and Eclipse MicroProfile communities. Be sure to drop by to meet community experts in person and check out the demos.


Join Community Update Calls

Every month, the Jakarta EE community holds a community call for everyone in the Jakarta EE community. For upcoming dates and connection details, see the Jakarta EE Community Calendar.

Our next call is Wednesday, February 12, at 11:00 a.m. EST using this meeting ID.

We know it’s not always possible to join calls in real time, so here are links to the recordings and presentations from previous calls:

·      The complete playlist

·      January 15 call and presentation, featuring:

o   Updates on the Jakarta EE 9 release from Steve Millage

o   A call for action to help with Jakartifying specifications from Ivar Grimstad

o   A review of the Jakarta EE 2020 Marketing Plan and budget from Neil Paterson

o   A retrospective on Jakarta EE 8 from Ed Bratt

o   A heads up for the CN4J and JakartaOne Livestream events from Tanja Obradovic


Stay Connected With the Jakarta EE Community

The Jakarta EE community is very active and there are a number of channels to help you stay up to date with all of the latest and greatest news and information. Tanja Obradovic’s blog summarizes the community engagement plan, which includes:

• Social media: Twitter, Facebook, LinkedIn Group

• Mailing lists: and

• Newsletters, blogs, and emails: Eclipse newsletter, Jakarta EE blogs, monthly update emails to, and community blogs on “how are you involved with Jakarta EE”

• Meetings: Jakarta Tech Talks, Jakarta EE Update, Jakarta Town Hall, and Eclipse Foundation events and conferences

Subscribe to your preferred channels today. And, get involved in the Jakarta EE Working Group to help shape the future of open source, cloud native Java.

To learn more about Jakarta EE-related plans and check the date for the next Jakarta Tech Talk, be sure to bookmark the Jakarta EE Community Calendar.


by Tanja Obradovic at February 05, 2020 07:21 PM

CN4J Day Is an Important Industry First

by Thabang Mashologu at January 29, 2020 02:44 AM

Mark Cloud Native for Java (CN4J) Day on March 30 on your calendars. This all-day event at KubeCon + CloudNativeCon Europe will be the first time the best and brightest minds from the Java and the Kubernetes communities join forces at a single event to collaborate and share their expertise.
CN4J Day attendees will benefit from expert talks, demos, and thought-provoking sessions focused on building cloud native enterprise applications using Jakarta EE-based microservices on Kubernetes.

CN4J Day is a major milestone in open source software development. It’s also a significant day for everyone involved with the Eclipse Foundation because it confirms the Jakarta EE and MicroProfile communities are at the forefront of open source innovation, delivering on the promise of cloud native Java. Given that the Eclipse Foundation is Europe’s largest open source organization, it makes perfect sense to hold this first-of-its-kind event in Amsterdam.

The timing of CN4J Day could not be better. As our Executive Director, Mike Milinkovich, noted in his blog, momentum toward Jakarta EE 9 is building. This event gives all of us an important and truly unique opportunity to:

  • Learn more about the future of cloud native Java development from industry and community leaders
  • Gain deeper insight into key aspects of Jakarta EE, MicroProfile, and Kubernetes technologies
  • Meet and share ideas with global Java and Kubernetes ecosystem innovators 

Leading minds from the global Java ecosystem will be on hand at CN4J Day to share their expertise. Along with keynote talks from our own Mike Milinkovich and IBM Java CTO, Tim Ellison, CN4J Day offers technical insights from well-known Java experts and Eclipse Foundation community members, including:

  • Adam Bien, an internationally recognized Java architect, developer, workshop leader, and author
  • Sebastian Daschner, lead java developer advocate at IBM
  • Clement Escoffier, principal software engineer at Red Hat
  • Ken Finnegan, senior principal engineer at Red Hat
  • Emily Jiang, liberty architect for MicroProfile and CDI at IBM
  • Dmitry Kornilov, Jakarta EE and Helidon Team Leader at Oracle
  • Tomas Langer, Helidon Architect & Developer at Oracle

Leading players in the Java ecosystem have signed on to sponsor CN4J activities and show their support for the initiative. Our sponsors include the Cloud Native Computing Foundation (CNCF), IBM, Oracle, and Red Hat.

Since we have limited capacity, this is a first-come, first-served event. To register today, just include CN4J Day when you’re registering for KubeCon + CloudNativeCon Europe. Thanks to the generous support of our sponsors, a limited amount of discounted CN4J Day add-on registrations will be made available to Jakarta EE and MicroProfile community members. For more information about CN4J Day and a link to the registration page, click here.
For additional questions regarding this event, please reach out to We’ll let you know when we add speakers and sponsors for CN4J Day. Watch our blogs and newsletters for updates.


by Thabang Mashologu at January 29, 2020 02:44 AM

Setting up e(fx)clipse RCP development for Java11+ and PDE

by Tom Schindl at January 28, 2020 03:00 PM

As I’m currently converting a Java-8 project to AdoptJDK-11 and JavaFX-11+ I thought it would be a good idea document the steps involved.


I assume you have installed:

Configure your Eclipse

Java Settings

Make AdoptJDK-11 the default JRE unless it is already the default.

Make sure AdoptJDK-11 is used for the Java-SE-11 EE

e(fx)clipse Settings

Open the JavaFX-Preference Page and point it to your JavaFX-11-SDK

This step is required because JavaFX is not part of AdoptJDK-11 and hence Eclipse won’t find the libraries and your code won’t compile inside the IDE (we’ll revisit this topic below once more)

Setup a target platform

Create your project

Bootstrap your project

Check your project setup

Check if Eclipse correctly recognized the javafx-library and magically added them to your plug-in dependendencies

Implement the UI

Add javax.annotation to your MANIFEST.MF

Before you can write the Java-Code for your UI you need to add javax.annotation-package to your bundle (this used to ship with Java-8 has been removed since then)

Create a Java-Class


import javax.annotation.PostConstruct;

import javafx.scene.control.Label;
import javafx.scene.layout.BorderPane;

public class SamplePart {
  void init(BorderPane root) {
      new Label(System.getProperty("javafx.version"))

Adapt your e4xmi

Running your application

While everything happily compiles running the application would fail because in the initial steps we only satisfied the Eclipse compiler by magically injecting the JavaFX-Libraries in your Plug-in-Dependency (see above).

To run the application we need to decide how we’d like to ship JavaFX:

  • next to your application in a folder
  • as part of your eclipse application inside the the plugins-directory
  • you jlink yourself a JDK

We’ll not take a look at the 3rd solution as part of this blog post!

Running with an external folder

Open the generated launch configuration and append in the VM arguments-field

Running with bundled javafx-modules

We provide OSGi-Bundles who contain the original and unmodified JavaFX-Modules (note you can NOT use them are OSGi-Dependencies!) you can use them by adding

Add them to your launch configuration

Exporting your application

The project wizard already generated the basic infrastructure for you but we need to make some small changes. We assume you’ve chosen to option to ship the JavaFX-modules as part of the plugins-directory to keep it simple.

The wizard already added the JavaFX-Standard-Feature into your product-File

It also added the parts to satisfy the compiler in your releng/pom.xml

While most of the stuff is already in place we need to make 2 small modifications:

  • Update the tycho-version property to 1.5.0
  • Change the export environment to match the operation-system(s) you want to target
    • Windows: os=win32, ws=win32, arch=x86_64
    • Linux: os=linux, ws=gtk, arch=x86_64
    • OS-X: os=macosx, ws=cocoa, arch=x86_64

Producing a native launcher

As we anyway have to produce a platform-dependent we can also add the creation of a native launcher. For that open your .product-File:

  • Tick the “The product includes native launcher artifacts”
  • Change the application to main-thread-application

by Tom Schindl at January 28, 2020 03:00 PM

Cloud Native for Java Day @ KubeCon EU

by Mike Milinkovich at January 28, 2020 12:00 PM

Cloud Native for Java (CN4J) Day at KubeCon + CloudNativeCon Europe will be the first time the best and brightest minds from the Java ecosystem and the Kubernetes ecosystem come together at one event to collaborate and share their expertise.

The all-day event on March 30 includes expert talks, demos, and thought-provoking sessions focused on building cloud native enterprise applications using Jakarta EE-based microservices on Kubernetes. CN4J Day is a proud moment for all of us at the Eclipse Foundation as it confirms the Jakarta EE and MicroProfile communities are at the forefront of fulfilling the promise of cloud native Java. We’re excited to be working with our friends at the CNCF to offer this event co-located with KubeCon Europe.

A Unique Opportunity to Engage With Global Experts

The timing of CN4J Day could not be better. With momentum toward the Jakarta EE 9 release building, this event gives all of us an important and truly unique opportunity to:

  •     Learn more about the future of cloud native Java development from industry and community leaders
  •     Gain deeper insight into key aspects of Jakarta EE, MicroProfile, and Kubernetes technologies
  •     Meet and share ideas with global Java and Kubernetes ecosystem innovators

The global Java ecosystem has embraced CN4J day and several of its leading minds will be on-hand to share their insights. Along with keynote addresses from my colleague Tanja Obradovic and IBM Java CTO, Tim Ellison, CN4J Day features informative technical talks from Java experts and Eclipse Foundation community members, such as:

  •     Adam Bien, an internationally recognized Java architect, developer, workshop leader, and author
  •     Sebastian Daschner, lead java developer advocate at IBM
  •     Clement Escoffier, principal software engineer at Red Hat
  •     Ken Finnegan, senior principal engineer at Red Hat
  •     Emily Jiang, liberty architect for MicroProfile and CDI at IBM
  •     Dmitry Kornilov, Jakarta EE and Helidon Team Leader at Oracle
  •     Tomas Langer, Helidon Architect & Developer at Oracle

Major Industry and Ecosystem Endorsement

Leading industry players in the Java ecosystem are also showing their support for CN4J Day through sponsorship. Our sponsors include:

  •     Cloud Native Computing Foundation (CNCF)
  •     IBM
  •     Oracle
  •     Red Hat

The event is being coordinated by an independent program committee composed of Arun Gupta, principal technologist at Amazon Web Services, Reza Rahman, principal program manager for Java on Azure at Microsoft, and Tanja Obradovic, program manager for Jakarta EE at the Eclipse Foundation.

Register Today

To register today, simply add the event to your KubeCon + CloudNativeCon Europe registration. Thanks to the generous support of our sponsors, a limited amount of discounted CN4J Day add-on registrations will be made available to Jakarta EE and MicroProfile community members on a first-come, first-served basis.

For more details about CN4J Day and a link to the registration page, click here. For additional questions regarding this event, please reach out to

As additional speakers and sponsors come onboard, we’ll keep you posted, so watch for updates in our blogs and newsletters.

by Mike Milinkovich at January 28, 2020 12:00 PM

Introduction to Eclipse JKube: Java tooling for Kubernetes and Red Hat OpenShift

by Rohan Kumar at January 28, 2020 08:00 AM

We as Java developers are often busy working on our applications by optimizing application memory, speed, etc. In recent years, encapsulating our applications into lightweight, independent units called containers has become quite a trend, and almost every enterprise is trying to shift its infrastructure onto container technologies like Docker and Kubernetes.

Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications, but it has a steep learning curve, and an application developer with no background in DevOps can find this system a bit overwhelming. In this article, I will talk about tools that can help when deploying your Maven applications to Kubernetes/Red Hat OpenShift.

Background: Eclipse JKube

This project was not built from scratch. It’s just a refactored and rebranded version of the Fabric8 Maven plugin, which was a Maven plugin used in the Fabric8 ecosystem. Although the Fabric8 project was liked and appreciated by many people in the open source community, due to unfortunate reasons it could not become successful, and the idea of Fabric8 as an integrated development platform on top of Kubernetes died. Although the main project is archived, there are still active repositories used by the community, such as the Fabric8 Docker Maven plugin, the Fabric8 Kubernetes client, and of course the Fabric8 Maven plugin.

As maintainers of the Fabric8 Maven plugin, we started decoupling the Fabric8 ecosystem related pieces from the plugin to make a general-purpose Kubernetes/OpenShift plugin. We also felt there was a need for rebranding because most people were confused about whether this plugin had something to do with Fabric8. Hence, we decided to rebrand it, and fortunately, someone from the Eclipse foundation approached us to take in our project. Now, the project is being renamed to Eclipse JKube and can be found in the Eclipse Foundation repos on GitHub.

Eclipse JKube can be seen as a reincarnation of the Fabric8 Maven plugin. It contains the good parts of this plugin and offers a clean and smooth workflow with the tooling it provides. We refactored this plugin into three components:

  • The JKube Kit
  • The Kubernetes Maven plugin
  • The OpenShift Maven plugin

The JKube Kit contains the core logic for building Docker images, generating Kubernetes/OpenShift manifests, and applying them onto Kubernetes/OpenShift clusters. Plugins consume this library for their operations. In the future, we also plan to add support for Gradle plugins.


Now, let’s have a look at Eclipse JKube in action. For the demo, I will deploy a simple Spring Boot project onto Kubernetes using the Eclipse Kubernetes Maven plugin. Let’s walk through this process:

  1. Add the Kubernetes Maven plugin as a dependency in your pom.xml file, as shown in Figure 1:
The Kubernetes Maven plugin added as a dependency in pom.xml.

Figure 1: The Kubernetes Maven plugin added as a dependency in pom.xml.

  1. Build your Docker images. The Eclipse JKube Kubernetes Maven plugin offers a zero-config mode, in which it builds your Docker image with opinionated defaults. However, you can customize it by providing an image configuration in the plugin configuration. In order to build a Docker image, you just need to run the following (the results are shown in Figure 2):
mvn k8s:build
The results of the Docker image build command.

Figure 2: Building the Docker image.

  1. Generate your Kubernetes resource manifests. Eclipse JKube plugins have a powerful and configurable resource generation mechanism in which they can generate Kubernetes resources in zero-config mode. This feature can also be configured using XML configuration or by placing customized resource fragments in the src/main/jkube directory. The results are merged with the finally generated resource fragments. In order to generate resources, run the following (the results are shown in Figure 3):
mvn k8s:resource
The results of the resource manifest creation command.

Figure 3: Creating the Kubernetes resource manifests.

  1. Apply generated Kubernetes resources onto the Kubernetes cluster. In order to apply resources onto this cluster, you just need to run one of the following (the results are shown in Figure 4):
mvn k8s:apply


mvn k8s:deploy
The results of the command to apply the generated Kubernetes resources onto the Kubernetes cluster.

Figure 4: Applying the generated Kubernetes resources onto the Kubernetes cluster.

  1. Undeploy your Maven application from Kubernetes. We have a cleanup goal, too, which just deletes all resources created during the deploy phase. To use this feature, run the following (the results are shown in Figure 5):
mvn k8s:undeploy
The results of undeploying your Maven application from Kubernetes.

Figure 5: Undeploying your Maven application from Kubernetes.

  1. Debug your Java application inside Kubernetes. Apart from these goals, we also have a goal for remote debugging. Suppose that you see a bug inside your application that’s running inside Kubernetes and you want to debug its behavior. You can simply run our debug goal, which does port forwarding for debugging:
mvn k8s:debug
  1. Configure your IDE in order to connect to this open port for debugging, as shown in Figure 6:
A configuration window open in the IDE.

Figure 6: Configuring your IDE to debug your Java application inside Kubernetes via Maven.

  1. Set a breakpoint in the application code and hit the application endpoint. We can see the breakpoint being hit in IDE as shown in Figure 7:
The IDE hitting the application's breakpoint.

Figure 7: The application’s breakpoint in your IDE.

With this result, I wrap up this article. We do have more in our pipeline, so stay tuned for new updates. If you want to get involved, please reach out to us via our mailing list at, or our Gitter channel at


The post Introduction to Eclipse JKube: Java tooling for Kubernetes and Red Hat OpenShift appeared first on Red Hat Developer.

by Rohan Kumar at January 28, 2020 08:00 AM

Eclipse Vert.x 3.8.5

by vietj at January 24, 2020 12:00 AM

We have just released Vert.x 3.8.5, a bug fix release of Vert.x 3.8.x.

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

Vert.x 3.8.5 deprecations and breaking changes

Vert.x 3.8.5 release notes

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

You can bootstrap a Vert.x 3.8.5 project using

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.

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

by vietj at January 24, 2020 12:00 AM

Eclipse 2019-12 Now Available From Flathub

by Mat Booth at January 20, 2020 04:00 PM

How to get the latest release of Eclipse from Flathub.

by Mat Booth at January 20, 2020 04:00 PM

JDT without Eclipse

January 16, 2020 11:00 PM

The JDT (Java Development Tools) is an important part of Eclipse IDE but it can also be used without Eclipse.

For example the Spring Tools 4, which is nowadays a cross-platform tool (Visual Studio Code, Eclipse IDE, …), is highly using the JDT behind the scene. If you would like to know more, I recommend you this podcast episode: Spring Tools lead Martin Lippert

A second known example is the Java Formatter that is also part of the JDT. Since a long time there are maven and gradle plugins that performs the same formatting as Eclipse IDE but as part of the build (often with the possibly to break the build when the code is wrongly formatted).

Reusing the JDT has been made easier since 2017 when it was decided to publish each release and its dependencies on maven central (with following groupId: org.eclipse.jdt, org.eclipse.platform). Stephan Herrmann did a lot of work to achieve this goal. I blogged about this: Use the Eclipse Java Development Tools in a Java SE application and I have pushed a simple example the Java Formatter is used in a simple main(String[]) method built by a classic minimal Maven project: java-formatter.

Workspace or not?

When using the JDT in an headless application, two cases needs to be distinguished:

  1. Some features (the parser, the formatter…) can be used in a simple Java main method.

  2. Other features (search index, AST rewriter…) require a workspace. This imply that the code run inside an OSGi runtime.

To illustrate this aspect, I took some of the examples provided by the site in the blog post series Eclipse JDT Tutorials and I adapted them so that each code snippet can be executed inside a JUnit test. This is the Programcreek examples project.

I have split the unit-tests into two projects:

  • programcreek-standalone for the one that do not require OSGi. The maven project is really simple (using the default convention everywhere)

  • programcreek-osgi for the one that must run inside an OSGi runtime. The bnd maven plugins are configured in the pom.xml to take care of the OSGi stuff.

If you run the test with Maven, it will work out-of-the box.

If you would like to run them inside an IDE, you should use one that starts OSGi when executing the tests (in the same way the maven build is doing it). To get a bnd aware IDE, you can use Eclipse IDE for Java Developers with the additional plugin Bndtools installed, but there are other possibilities.

Source code can be found on GitHub: programcreek-examples

January 16, 2020 11:00 PM

Oracle made me a Stackoverflow Guru

by Stephan Herrmann at January 16, 2020 06:40 PM

Just today Oracle helped me to become a “Guru” on Stackoverflow! How did they do it? By doing nothing.

In former times, I was periodically enraged, when Oracle didn’t pay attention to the feedback I was giving them during my work on ecj (the Eclipse Compiler for Java) – at least not the attention that I had hoped for (to be fair: there was a lot of good communication, too). At those times I had still hoped I could help make Java a language that is completely and unambiguously defined by specifications. Meanwhile I recognized that Java is at least three languages: the language defined by JLS etc., the language implemented by javac, and the language implemented by ecj (and no chance to make ecj to conform to both others). I realized that we were not done with Java 8 even 3 years after its release. Three more years later it’s still much the same.

So let’s move on, haven’t things improved in subsequent versions of Java? One of the key new rules in Java 9 is, that

“If [a qualified package name] does not name a package that is uniquely visible to the current module (§7.4.3), then a compile-time error occurs”.

Simple and unambiguous. That’s what compilers have to check.

Except: javac doesn’t check for uniqueness if one of the modules involved is the “unnamed module”.

In 2018 there was some confusion about this, and during discussion on stackoverflow I raised this issue to the jigsaw-dev mailing list. A bug was raised against javac, confirmed to be a bug by spec lead Alex Buckley. I summarized the situation in my answer on stackoverflow.

This bug could have been easily fixed in javac version 12, but wasn’t. Meanwhile upvotes on my answer on stackoverflow started coming in. The same for Java 13. The same for Java 14. And yet no visible activity on the javac bug. You need ecj to find if your program violates this rule of JLS.

Today the 40th upvote earned me the “Guru” tag on stackoverflow.

So, please Oracle, keep that bug unresolved, it will earn me a lot of reputation for a bright future – by doing: nothing 🙂

by Stephan Herrmann at January 16, 2020 06:40 PM

Release 4.2

January 14, 2020 12:00 AM

New version 4.2 has been released.

Release is of Type B


  • OData artefact for declarative service exposure (*.odata)
  • Pretty names parameter for tables and columns names


  • Dependencies fixes
  • Minor fixes


  • 64K+ Sessions
  • 45K+ Users
  • 180 Countries
  • 356 Repositories in DirigibleLabs



January 14, 2020 12:00 AM

Building and running Equinox with maven without Tycho

January 12, 2020 11:00 PM

Eclipse Tycho is a great way to let maven build PDE based projects. But the Plug-in Development Environment (PDE) model is not the only way to work with OSGi.

In particular, since 2 or 3 years the Eclipse Platform jars (including the Equinox jars) are regularly published on Maven Central (check the artifacts having org.eclipse.platform as groupId).

I was looking for an alternative to P2 and to the target-platform mechanism.

bnd and bndtools logo

Bnd and Bndtools are always mentioned as potential alternative to PDE (I attended several talks discussing this at EclipseCon 2018: Migrating from PDE to Bndtools in Practice, From Zero to a Professional OSGi Project in Minutes). So I decided to explore this path.

This StackOverflow question catches my attention: How to start with OSGi. I had a close look at the answer provided by Peter Kriens (the founder of the Bnd and Bndtools projects), where he discusses the different possible setup:

  • Maven Only

  • Gradle Only

  • Eclipse, M2E, Maven, and Bndtools

  • Eclipse, Bndtools, Gradle

Even in the "Maven Only" or "Gradle Only" setups, the proposed solution relies on plugins using bnd under the hood.

How to start?

My project is quite simple, the dependencies are already on maven central. I will not have a complex use-case with multiple versions of the same library or with platform dependent artifacts. So fetching the dependencies with maven is sufficient.

I decided to try the "Maven Only" model.

How to start?

I was not sure to understand how to use the different bnd maven plugins: bnd-maven-plugin, bnd-indexer-maven-plugin, bnd-testing-maven-plugin, bnd-export-maven-plugin

Luckily I found the slides of the Bndtools and Maven: A Brave New World workshop (given at EclipseCon 2017) and the corresponding git repository: osgi-community-event2017.

The corresponding effective-osgi maven archetypes used during the workshop are still working well. I could follow the step-by-step guide (in the readme of the maven archetypes project). I got everything working as described and I could find enough explanations about the generated projects. I think I understood what I did and this is very important when you start.

After some cleanup and a switch from Apache Felix to Eclipse Equinox, I got my running setup and I answered my question: "How to start with OSGi without PDE and Tycho".

The corresponding code is in this folder: effectiveosgi-example.

January 12, 2020 11:00 PM

Jakarta EE Community Update January 2020

by Tanja Obradovic at January 09, 2020 02:26 PM

Welcome to our first update of 2020. As we start the new year, I want to wish you all the best. We have a lot to look forward to in 2020 as it will be the first year with multiple Jakarta EE releases. What a bright and optimistic way to start a new year!

As we ramp up our 2020 activities, here’s a look back at Jakarta EE highlights from the last few weeks in November and December of 2019. 

The Jakarta EE 8 Retrospective Is Complete

As we mentioned in our last update, the Jakarta EE Steering Committee asked the community to provide feedback on the Jakarta EE 8 release so we can make improvements in Jakarta EE 9 and future releases.

We’re happy to tell you that feedback has now been collected, analyzed, and summarized. 

To learn more about the results of the retrospective, keep an eye out for a blog post on the topic, but also, please join us for the January 15 at 11:00 a.m. EST using this meeting ID where this topic will be on the Agenda.

 The Jakarta EE 9 Release Plan Is Ready for Specification Committee Review

The Jakarta EE Platform Project team, led by Kevin Sutter and Steve Millidge, has been working very hard to create the detailed Jakarta EE 9 release plan. As promised, the plan has been created, presented, and endorsed by the Jakarta EE Steering Committee. The next step is for the Specification Committee to review it and vote on it early this year.

You can read the minutes of the Jakarta EE Platform Project team meetings here.

For the latest updates on Jakarta EE 9 release planning, listen to the recording of the December Jakarta EE update call here.

Reminder: We Need Your Help to Jakartify Specifications

Just a reminder that we now have the copyright for quite a number of Java EE specifications and we need the community to Jakartify them so they can be contributed to Jakarta EE.

To help you get started:

·      The Specification Committee has created a document that explains how to convert Java EE specifications to Jakarta EE.

·      Ivar Grimstad provided a demo during the community call in October. You can view it here.

And, here’s the list of specifications that are ready for the community to Jakartify.

• Jakarta Annotations

• Jakarta Enterprise Beans

• Jakarta Expression Language

• Jakarta Security

• Jakarta Server Faces

• Jakarta Interceptors

• Jakarta Authorization

• Jakarta Activation

• Jakarta Managed Beans


• Jakarta Deployment

• Jakarta XML RPC

• Jakarta Authentication

• Jakarta Mail

• Jakarta XML Binding

• Jakarta RESTful Web Services

• Jakarta Web Services Metadata

• Jakarta XML Web Services

• Jakarta Connectors


• Jakarta Persistence

• Jakarta JSON Binding

• Jakarta JSON Processing

• Jakarta Debugging Support for Other Languages

• Jakarta Server Pages

• Jakarta Transactions

• Jakarta WebSocket


Jakarta EE 2020 Marketing Plan Finalized

The Jakarta EE Marketing Operations Report for Q3 2019 was presented during the December Marketing Committee call. The report includes market activities and metrics for planned versus actual activities in Q3 and was generally well received by the committee.

You can read the meeting minutes here

Upcoming Events

Here’s a brief look at two upcoming Jakarta EE events to mark on your calendar:

·      JakartaOne Livestream – Japan, February 26

With the success of the JakartaOne Livestream event in September 2019, we’re expanding the initiative with more virtual conferences in more languages. Our next event is JakartaOne Livestream - Japan scheduled for February 26. Please follow the event on Twitter @JakartaOneJPN for all the details. Registration will open shortly. Keep in mind this entire event will be presented in Japanese.

·      Cloud Native for Java (CN4J) Day at KubeCon Amsterdam, March 30

CN4J day on March 30 is a full day (9:00 a.m.-5:00 p.m.) of expert talks, demos, and thought-provoking sessions focused on enterprise applications implemented using Jakarta EE and Eclipse MicroProfile on Kubernetes. This event is a great opportunity to meet with industry and community leaders, to better understand key aspects of Jakarta EE and MicroProfile technologies, and to share your ideas with ecosystem innovators. Learn more about the event here.

Join Community Update Calls

Every month, the Jakarta EE community holds a community call for everyone in the Jakarta EE community. For upcoming dates and connection details, see the Jakarta EE Community Calendar.

 Our next call is Wednesday, January 15 at 11:00 a.m. EST using this meeting ID.

We know it’s not always possible to join calls in real time, so here are links to the recordings and presentations:

·      The complete playlist.

·      December 11 call and presentation, featuring Steve Millage discussing Jakarta EE 9 release planning, an update on Jakartifying specifications from Ivar Grimstad, and a call for action to help with the Jakarta EE 2020 Program Plan and budget from Jakarta EE Steering Committee chair, Will Lyons.

November and December Event Summary

We ended a very exciting year for Jakarta EE by participating in three major events:  

·      Devoxx BE

·      KubeCon NA

·      Java2Days

We had members presenting at all three events and we’d like to sincerely thank them for their time and effort. A special shout-out to our Jakarta EE Developer Advocate, Ivar Grimstad, who presented multiple times and participated in a panel discussion at Java2Days.

Our members were also on hand at our booths at Devoxx BE and KubeCon NA to share their expertise, provide demos, and engage with attendees. Again, a huge thank you to everyone involved for their enthusiastic participation. Your engagement helps drive the success of the entire Jakarta EE community.

Stay Connected With the Jakarta EE Community

The Jakarta EE community is very active and there are a number of channels to help you stay up to date with all of the latest and greatest news and information. Tanja Obradovic’s blog summarizes the community engagement plan, which includes:

•  Social media: Twitter, Facebook, LinkedIn Group

•  Mailing lists: and

•  Newsletters, blogs, and emails: Eclipse newsletter, Jakarta EE blogs, monthly update emails to, and community blogs on “how are you involved with Jakarta EE”

•  Meetings: Jakarta Tech Talks, Jakarta EE Update, Jakarta Town Hall, and Eclipse Foundation events and conferences

Subscribe to your preferred channels today. And, get involved in the Jakarta EE Working Group to help shape the future of open source, cloud native Java.

To learn more about Jakarta EE-related plans and check the date for the next Jakarta Tech Talk, be sure to bookmark the Jakarta EE Community Calendar.



by Tanja Obradovic at January 09, 2020 02:26 PM

4 Years at The Linux Foundation

by Chris Aniszczyk at January 03, 2020 09:54 AM

Late last year marked the 4th year anniversary of the formation of the CNCF and me joining The Linux Foundation:

As we enter 2020, it’s amusing for me to reflect on my decision to join The Linux Foundation a little over 4 years ago when I was looking for something new to focus on. I spent about 5 years at Twitter which felt like an eternity (the average tenure for a silicon valley employee is under 2 years), focused on open source and enjoyed the startup life of going from a hundred or so engineers to a couple of thousand. I truly enjoyed the ride, it was a high impact experience where we were able to open source projects that changed the industry for the better: Bootstrap (changed front end development for the better), Twemoji (made emojis more open source friendly and embeddable), Mesos (pushed the state of art for open source infrastructure), co-founded TODO Group (pushed the state of corporate open source programs forward) and more!

When I was looking for change, I wanted to find an opportunity that could impact more than I could just do at one company. I had some offers from FAANG companies and amazing startups but eventually settled on the nonprofit Linux Foundation because I wanted to build an open source foundation from scratch, teach other companies about open source best practices and assumed non profit life would be a bit more relaxing than diving into a new company (I was wrong). Also, I was throughly convinced that an openly governed foundation pushing Kubernetes, container specifications and adjacent independent cloud native technologies would be the right model to move open infrastructure forward.

As we enter 2020, I realize that I’ve been with one organization for a long time and that puts me on edge as I enjoy challenges, chaos and dread anything that makes me comfortable or complacent. Also, I have a strong desire to focus on efforts that involve improving the state of security and privacy in a connected world, participatory democracy, climate change; also anything that pushes open source to new industries and geographies.

While I’m always happy to entertain opportunities that align to my goals, the one thing that I do enjoy at the LF is that I’ve had the ability to build a variety of new open source foundations improving industries and communities: CDF, GraphQL Foundation, Open Container Initiative (OCI), Presto Foundation, TODO Group, Urban Computing Foundation and more.

Anyways, thanks for reading and I look forward to another year of bringing open source practices to new industries and places, the world is better when we are collaborating openly.

by Chris Aniszczyk at January 03, 2020 09:54 AM

Release 4.1

December 27, 2019 12:00 AM

New version 4.1 released.

Release of Type B


  • Enchanced persistence models for references
  • Embedded mode and executable jar removed from distributions
  • Update to JDK 11
  • OData persistence layer
  • Ephemeral distibution for SAP Cloud Platform
  • Case sensitive parameter for tables and columns names


  • Database API fixes
  • HTTP Client fixes
  • Custom datasources fixes
  • Quartz integrated with datasources management layer
  • Minor fixes


  • 64K+ Sessions
  • 45K+ Users
  • 180 Countries
  • 356 Repositories in DirigibleLabs



December 27, 2019 12:00 AM

Eclipse Theia IDE – FAQ

by Jonas Helming and Maximilian Koegel at December 24, 2019 12:00 AM

In this article we´ll answer the most frequently asked questions about the Eclipse Theia IDE, the open source platform for building...

The post Eclipse Theia IDE – FAQ appeared first on EclipseSource.

by Jonas Helming and Maximilian Koegel at December 24, 2019 12:00 AM

An update on Eclipse IoT Packages

by Jens Reimann at December 19, 2019 12:17 PM

A lot has happened, since I wrote last about the Eclipse IoT Packages project. We had some great discussions at EclipseCon Europe, and started to work together online, having new ideas in the progress. Right before the end of the year, I think it is a good time to give an update, and peek a bit into the future.


One of the first things we wanted to get started, was a home for the content we plan on creating. An important piece of the puzzle is to explain to people, what we have in mind. Not only for people that want to try out the various Eclipse IoT projects, but also to possible contributors. And in the end, an important goal of the project is to attract interested parties. For consuming our ideas, or growing them even further.

Eclipse IoT Packages logo

So we now have a logo, a homepage, built using using templates in a continuous build system. We are in a position to start focusing on the actual content, and on the more tricky tasks and questions ahead. And should you want to create a PR for the homepage, you are more than welcome. There is also already some content, explaining the main goals, the way we want to move forward, and demo of a first package: “Package Zero”.


While the homepage is a good entry point for people to learn about Eclipse IoT and packages, our GitHub repository is the home for the community. And having some great discussions on GitHub, quickly brought up the need for a community call and a more direct communication channel.

If you are interested in the project, come and join our bi-weekly community call. It is a quick, 30 minutes call at 16:00 CET, and open to everyone. Repeating every two weeks, starting 2019-12-02.

The URL to the call is: You can also subscribe to the community calendar to get a reminder.

In between calls, we have a chat room eclipse/packages on Gitter.

Eclipse IoT Helm Chart Repository

One of the earliest discussion we had, was around the question of how and were we want to host the Helm charts. We would prefer not to author them ourselves, but let the projects contribute them. After all, the IoT packages project has the goal of enabling you to install a whole set of Eclipse IoT projects, with only a few commands. So the focus is on the integration, and the expert knowledge required for creating project Helm chart, is in the actual projects.

On the other side, having a one-stop shop, for getting your Eclipse IoT Helm charts, sounds pretty convenient. So why not host our own Helm chart repository?

Thanks to a company called Kiwigrid, who contributed a CI pipeline for validating charts, we could easily extend our existing homepage publishing job, to also publish Helm charts. As a first chart, we published the Eclipse Ditto chart. And, as expected with Helm, installing it is as easy as:

Of course having a single chart is only the first step. Publishing a single Helm charts isn’t that impressive. But getting an agreement on the community, getting the validation and publishing pipeline set up, attracting new contributors, that is definitely a big step in the right direction.


I think that we now have a good foundation, for moving forward. We have a place called “home”, for documentation, code and community. And it looks like we have also been able to attract more people to the project.

While our first package, “Package Zero”, still isn’t complete, it should be pretty close. Creating a first, joint deployment of Hono and Ditto is our immediate focus. And we will continue to work towards a first release of “Package Zero”. Finding a better name is still an item on the list.

Having this foundation in place also means, that the time is right, for you to think about contributing your own Eclipse IoT Package. Contributions are always welcome.

The post An update on Eclipse IoT Packages appeared first on ctron's blog.

by Jens Reimann at December 19, 2019 12:17 PM

WTP 3.16 Released!

December 18, 2019 10:42 PM

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

More news

December 18, 2019 10:42 PM

EMF Forms and EMF Client Platform 1.23.0 released!

by Jonas Helming and Maximilian Koegel at December 18, 2019 08:36 AM

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

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

by Jonas Helming and Maximilian Koegel at December 18, 2019 08:36 AM

Eclipse Vert.x 4 milestone 4 released!

by vietj at December 13, 2019 12:00 AM

We are extremely pleased to announce the fourth 4.0 milestone release of Eclipse Vert.x .

Vert.x 4 is the evolution of the Vert.x 3.x series that will bring key features to Vert.x.

This release aims to provide a reliable distribution of the current development of Vert.x 4 for people that want to try it and provide feedback.


Vert.x 4 extends the 3.x callback asynchronous model to a future/callback hybrid model.

public interface NetClient {

  // Since 3.0
  void connect(int port, String host, Handler> handler);

  // New in 4.0
  Future connect(int port, String host);

This third milestone makes progress and fully covers with the following stack modules:

  • Vert.x Shell
  • Vert.x Mail Client
  • Vert.x Consul Client
  • Vert.x RabbitMQ Client
  • Vert.x Stomp
  • Vert.x Mongo Client

Mail client improvements

Our mail clients had nice contribution with the ability to use streaming payload for attachements and the support for DKIM signatures.

General client improvements

Some Vert.x client are designed to be used within the verticle that created it while some can be shared between verticles. This is a technical limitation that stems from the fact that client are implemented using Vert.x or Netty (such as HttpClient) and are bound to the underlying event-loop that powers them.

In Vert.x 4 we decided to get away of this limitation to simplify the usage and the configuration of the clients. Of course it is possible to continue confining clients within a verticle (for best performance) but clients can be now shared between verticles when desired with a neglectible impact on performance (requiring message passing).

Security improvements

Finally here are a few improvements done in our security layer:

  • Vertx Auth is now decoupled to handle authn/authz as 2 independent functions thanks to @sbastiandev
  • Auth Shiro is deprecated in favour of the new “auth properties” module and “auth ldap”
  • Web CSRF tokens are session aware to allow multiple requests from the same user
  • Initial support for webauthn

Ramping up to Vert.x 4

Instead of developing all new features exclusively in Vert.x 4, we introduce some of these features in the 3.x branch so the community can benefit from them. The Vert.x 4 development focus on more fundamental changes that cannot be done in the 3.x series.


This is the forth milestone of Vert.x 4, you can of course expect more milestones to outline the progress of the effort.

You can also read the previous milestone announces:


The deprecations and breaking changes can be found on the wiki.

For this release there are no Docker images.,

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

You can bootstrap a Vert.x 4.0.0-milestone4 project using

The documentation has been deployed on this preview web-site

That’s it! Happy coding and see you soon on our user or dev channels.

by vietj at December 13, 2019 12:00 AM

Announcing Eclipse Ditto Release 1.0.0

December 12, 2019 12:00 AM

Today the Eclipse Ditto is thrilled to announce the availability of Eclipse Ditto’s first major release 1.0.0.


The initial code contribution was done in October 2017, 2 years later and 2 releases (0.8.0 and 0.9.0) later, we think its time to graduate from the Eclipse “incubation” phase and officially declare the project as mature.

Recent adoptions and contributions from our community show us that Eclipse Ditto solves problems which also other companies have. Adopters add Eclipse Ditto as a central part of their own IoT platforms.

API stability

Having reached 1.0.0, some additional promises towards “API stability” do apply:

HTTP API stability

Ditto uses schema versioning (currently schema version 1 and 2) at the HTTP API level in order to being able to evolve APIs. It is backward compatible to the prior versions 0.8.0 and 0.9.0.

JSON API stability

Ditto kept its main JSON APIs (regarding things, policies and search) backwards compatible to 0.8.0 and 0.9.0 releases. The JSON format of “connections” was changed since 0.9.0 and will from 1.0.0 on be kept backwards compatible as well.

Java API stability

The Java APIs will for the 1.x release be kept backwards compatible, so only non-breaking additions to the APIs will be done. This is enforced by a Maven tooling.

The following Java modules are treated as API for which compatibility is enforced:

  • ditto-json
  • ditto-model-*
  • ditto-signals-*
  • ditto-protocol-adapter
  • ditto-utils
  • ditto-client


The focus on the 0.9.0 and 1.0.0 releases regarding non-functionals were laid on horizontal scalability.

With Eclipse Ditto 1.0.0 we are confident to face production grade scalability requirements being capable of handling millions of managed things.


The main changes compared to the last release, 0.9.0, are:

  • addition of a Java and a JavaScript client SDK in separate GitHub repo
  • configurable OpenID Connect authorization servers
  • support for OpenID Connect / OAuth2.0 based authentication in Ditto Java Client
  • invoking custom foreign HTTP endpoints as a result of events/messages
  • ability to reflect Eclipse Hono’s device connection state in Ditto’s things
  • configurable throttling of max. consumed WebSocket commands / time interval
  • Addition of “definition” field in thing at model level containing the model ID a thing may follow
  • Improved connection response handling/mapping

Please have a look at the 1.0.0 release notes for a more detailed information on the release.


The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central.

The Docker images have been pushed to Docker Hub:


The Eclipse Ditto team

December 12, 2019 12:00 AM

Xtext 2.20 Release

by Karsten Thoms ( at December 03, 2019 02:38 PM

Right on time for the Eclipse 2019-12 Simultaneous Release, we have shipped Xtext 2.20. This time we focussed more on maintenance work than on features. As with each release, the world around us is spinning fast, and keeping the whole technology stack up-to-date and testing against it is quite time consuming.

Let’s talk about Xtend

For a long time, the Java language missed some features that could make a developer’s life easier. This was one of the reasons that a broad range of languages running on the Java Virtual Machine (JVM) became popular, Xtend being one of them. With its powerful lambda expressions, extension methods, and template support, Xtend had some sweet spots back in 2013, which Java did not have. And even with the availability of lambdas with Java 8, it took some years for projects to catch up with that. Xtend provided this for years, while still being able to produce Java 1.6-compliant code.

Now the (Java) world has changed, and some nice language features have been added to Java, making the gap to Xtend smaller. Back in 2013, we claimed Xtend to be the “Java 10 of today”. We are realistic enough to state that Xtend is not and will not be the “Java 17 of today”. However, there are still areas where we see Xtend as beneficial over other Java and other JVM languages. To be more specific, we still think that Xtend is the most powerful language supporting template expressions. The most common use case for this are code generators. Besides that, writing unit tests with Xtend feels much cleaner than with Java.

However, we decided to encourage to use Xtend only for these areas, and not as the primary general-purpose language. And we start doing this with the “New Project” wizard. The configuration that this wizard creates for a new Xtext project, will now use Java as the language for generated skeleton classes, so that newly-created projects (and especially new users) are using Java by default. This is just a changed default for the generated MWE2 workflow, and users, who still prefer to use Xtend for the generated artifacts, can simply modify the workflow file. We expect that those users are advanced anyway. Xtend will stay the default language for the code generator and unit test fragments.

Additionally, we have started to clean up the code base and to refactor some of the Xtend code to Java. As Xtend already is compiled into Java, this basically means that we take those sources and clean them up. This will be an ongoing maintenance work. If you like to contribute to Xtext, this would be a good starting point for refactoring contributions.

New Xtend features

After that being said, there is some good news about some features that have been added to Xtend’s Eclipse integration. We are very happy about some useful contributions from Vivien Jovet in this area.

A new refactoring has been implemented that allows the user to refactor a call to a static method either as static import or as a static extension. This allows the user to produce more readable and fluent code.




The testing support for Xtend has been improved:

  • An Xtend unit test can now be triggered within the Eclipse IDE when the cursor is located around the test class definition.
  • As known from JDT’s JUnit integration, Xtend now also provides quickfixes if the JUnit library is missing on the classpath. By using the quickfix, the library can be added for either JUnit 4 or 5.

It’s time to get rid off old generator workflows

Already back in 2015, we changed to new Xtend-based generator fragments and deprecated the old Xpand-based language generator. If you still use an old generator workflow based on the org.eclipse.xtext.generator bundle (the new bundle is org.eclipse.xtext.xtext.generator, please note the duplicated .xtext segment), then it is time for you to finally take action!

The old generator is based on the Xpand language, which is dormant for a while. We are refactoring Xtext to avoid any dependency on Xpand, except for the deprecated generator bundle. Also, we do not change the old generator templates anymore, so we strongly recommend to use the maintained new generator infrastructure. Although it is not scheduled yet, dropping the whole old generator completely is just a matter of time. So, please, if you still have any anciently-structured Xtext projects, migrate them to the recommended infrastructure! If you need help on this, get in contact with us. We have enough experience to help you quickly on that.

Create new projects and files from the toolbar

If you want to allow creation of projects and files for your DSL from the toolbar, then this is good news for you: The fragments for generating the infrastructure for wizards have been extended by an option called generateToolbarButton. As the name already suggests, the generator fragments will generate the button to the toolbar, if this option is enabled in the fragment’s configuration in your generator workflow.

Making our maintenance work easier

With 4 releases per year and 3 milestone releases towards any release, it is quite some effort to make these releases. As we finished our hopefully last build infrastructure change to Eclipse JIRO with the previous release, we were able to invest a bit of time into enhancing our build pipelines again.

As a result, initiating a milestone or final release is mostly triggering a parameterized build job now and then waiting several hours until everything has been build. Actually, while I’m writing this article, the final Xtext release is being build for you, which has been triggered 3.5 hours before. Yes, it still builds that long. And it is still painful to orchestrate the build over all Xtext repositories. There are still some steps that require manual action (releasing to Maven Central, updating Eclipse Marketplace, sending notifications to the communication channels), but we slowly add all automatable tasks to the pipelines.

Also, we interacted with the Eclipse infrastructure staff to get us in the position that our technical build user is able to raise pull requests on GitHub automatically. This enabled us to create a bot update pipeline that lets us automate some frequently occurring update changes. This is, for example, updating the version, versions to use (like Tycho), the Orbit URL, etc. The job raises pull requests for us, so we can safely verify that nothing is missing and that everything is properly built. It is very much like these dependency update bots like Dependabot that are coming up more and more, but tightly tailored to the very specific needs of the Xtext project. We are still at the beginning here. Some first pull requests merged for 2.20 have been created by the bot job. We expect that the bot will be triggered automatically in the future and that the bot user will become one of the most active Xtext contributors then.


Xtext 2.20 is a maintenance release. For users of a recent Xtext version it will be a drop-in replacement. Users of old versions and project structures are recommended to upgrade their projects, in order to keep their projects compatible.

The Xtext project started to discourage the usage of Xtend where the latter’s language features do not have a significant benefit over Java. And internally, the project started to refactor the codebase to follow this recommendation.

For build and release engineering, the project improved towards more automated tasks and benefits from reduced manual maintenance tasks.

The project team is happy about receiving contributions. We are especially grateful about new feature ideas that are actively developed by contributors.

Do you want to know more? Have a look at the release notes for Xtext & Xtend.

by Karsten Thoms ( at December 03, 2019 02:38 PM

Obeo Cloud Platform

December 02, 2019 10:00 AM

TLDR; This is almost the story of my first CTO pregnancy experience, organizational stuff inside.

It’s been almost 2 years since I started operating as Obeo’s CTO, 2 years since I accepted the challenge to take the lead of our R&D. As part of this, almost 1 year ago I started to organize the development of our new generation modeling tool solution. And for the past 9 months my team has been busy working full time on this new product.

When you become pregnant a product manager, you are basically a story trigger for everyone around you: people love to tell their failure-project and their stupid-leader story. It is scary to be at the place where you are the one who decides. It is even more frightening when you are at the point where you redesign your products with a completely different technological layer. This is where I was one year ago. At Obeo, we have been developing for years modeling workbenches based on the Eclipse Platform. Today our customers want more and asked us to modernize the modeling stack by making it cloud compliant. So how do we go from this statement to a first software release?

If you’re a product manager or affiliate, you’re probably aware that the first nine months of a new software product are always a big adventure. CTOs-to-be may have a lot of questions about what they can expect and the changes they’ll go through. Do you know when to expect to feel your product move? When to look for a UI/UX designer or a continuous deployment pipeline? Customer interest on what you are developing? Is that the signs of preterm labor?

1st month - Your imagination has no limit

The beginning of a new product is not easy. Where should we start? Should we rely on the prototypes we already have? Should we built a completely new project? How will you build your team? Who will be in? When? What will be the first scenario that will be supported in your software? How should you be organized? These are all the first questions you will come across.

What I will remember from that first month is that at some point you have to take decision: that is why you are here, that’s your job, and that will remind you why there is a C in CTO. You have the power of choice. There is not a unique good solution for everything. When every other person has a piece of advice for you, you start to understand that not everything works for everyone. I found what I believe works best for me. Of course, what works for me may not work for you: it depends on your company technological background but also on how you want to get your collaborators engaged as well. Each project, team and context is different.

Take the time to discuss this with others in your company, take the time to find what they need but also what are they dreaming about this new product. I developed my product vision for example by asking people to fill in a survey with questions such as in 1, 2, 5 years what is the final goal, the business needs, the users expectations, the success factor, etc. See the product vision template available on my github for details.

Product Vision Template

Write a summary of all this. And in the end, find your own voice in the ocean of opinions. Build your team, define your first scenario, share with everyone what you decided and do not hesitate to fail! Your first organisation might not be the best one: try, learn, update, reorganize, try something else… You are not alone in this task, this is a collective effort. The entire team cares about its organization and discusses it regularly by making retrospectives, having a dedicated moment during regular meetings, defining process to improve their collaboration, selecting tools…

The questional period you just went through, your team will go through the same. Which technical bricks will they rely on? Which part of our existing code will integrate this new project? Should we start by building the simplest scenario, this without taking into account the whole complexity of the end product you are trying to build? What should in the end be the software architecture?

Important point, give some time to your team to discuss all those things. But ask them to produce something even during that period. In our case, we wrote documents (AsciiDoc rocks!) and decided to keep a trace of all our decisions. For that, we used ADR - Architectural Decision Record: it is like reading the pocket reference of your project. After several months of use, it has turned out to be really useful. It helps people who are working part time on the project to get what we decided and why and help remember why we took a given decision. It forces us to discuss and validate all the important decisions together. You also need to stop this questioning period by just pushing your team to contribute code and not just loosing them in the limbs of the imaginative product.

Mid months - Scared! Believe! Realize!

Pregnancy, giving software birth and the first 3 months is such an emotional roller coaster with so many changes. As you move forward on your development journey, it is amazing to discover all the things your sweety-software can do before he’s born. We went through different themes during these months: Persistence, CRUD, Diagram, Properties views, Edition, Concurrence, Authentication… Then everything is on track, you are organized as a team, code is being produced, your scenarios are more and more rich. And at some point, we realized we were actually growing life within us. It did not come right when we started the project.

I felt it in 3 specific moments —

  • When we chose the name - Obeo Cloud Platform,
  • When I had a first ultrasound scan preview of the UI - fortunately we have a Design team to work with,
  • And when he kicked for the first time - I mean his first public live demo.

We will also never forget our baby shower celebration at EclipseCon Europe! This was an amazing moment for us. We were so happy to present our new work to the Sirius community. That day I was feeling the kicks in my belly. As Steve Jobs puts it, “A lot of times, people don’t know what they want until you show it to them.” That’s why we decided to give a preview of our new product even before it is polished, and why we launched a beta testing team. The idea is to give them a preview access and organize live remote testing sessions to grow the feedback river with real end-users. Join us now and share your needs!

8-9th months - You are (almost) releasing!

Today, I do not even realise it is already the last months of pregnancy: we are getting closer and closer to our due date. I have this mixed feeling of excitement and nervousness and want our software product to come as soon as possible.

Our product is getting ready for birth, and the whole Obeo family is preparing to welcome a new member. You are also invited to join us, stay tuned for the upcoming SiriusCon Live Q1 2020.

At the end of this year, on his first days, our software product will be tiny and little. It will know only a few things but will do them well. Next we will continue to feed him: baby bottles first and then we will go through the diversification phase introducing new kind of food. My team will help him to grow, you, our users, our customers will be part of its education. We have many projects and plans, but we need you to turn true customers problems into product features.

Sometimes it’s important to stop and look back. It really made me appreciate and comprehend what an amazing experience I and my company went through ❤ and still are.

Hope you had a good read.

December 02, 2019 10:00 AM

Eclipse m2e: How to use a WORKSPACE Maven installation

by kthoms at November 27, 2019 09:39 AM

Today a colleague of me asked me about the Maven Installations preference page in Eclipse. There is an entry WORKSPACE there, which is disabled and shows NOT AVAILABLE. He wanted to know how to enable a workspace installation of Maven.

Since we both did not find the documentation of the feature I digged into the m2e sources and found class MavenWorkspaceRuntime. The relevant snippets are the method getMavenDistribution() and the MAVEN_DISTRIBUTION constant:

private static final ArtifactKey MAVEN_DISTRIBUTION = new ArtifactKey(
      "org.apache.maven", "apache-maven", "[3.0,)", null); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$


protected IMavenProjectFacade getMavenDistribution() {
  try {
    VersionRange range = VersionRange.createFromVersionSpec(getDistributionArtifactKey().getVersion());
    for(IMavenProjectFacade facade : projectManager.getProjects()) {
      ArtifactKey artifactKey = facade.getArtifactKey();
      if(getDistributionArtifactKey().getGroupId().equals(artifactKey.getGroupId()) //
          && getDistributionArtifactKey().getArtifactId().equals(artifactKey.getArtifactId())//
          && range.containsVersion(new DefaultArtifactVersion(artifactKey.getVersion()))) {
        return facade;
  } catch(InvalidVersionSpecificationException e) {
    // can't happen
  return null;

From here you can see that m2e tries to look for workspace (Maven) projects and to find one the has the coordinates org.apache.maven:apache-maven:[3.0,).

So the answer how to enable a WORKSPACE Maven installation is: Import the project apache-maven into the workspace. And here is how to do it:

  1. Clone Apache Maven from
  2. Optionally: check out a release tag
    git checkout maven-3.6.3
  3. Perform File / Import / Existing Maven Projects
  4. As Root Directory select the apache-maven subfolder in your Maven clone location

Now you will have the project that m2e searches for in your workspace:

And the Maven Installations preference page lets you now select this distribution:

by kthoms at November 27, 2019 09:39 AM

Modernizing our GitHub Sync Toolset

November 19, 2019 08:10 PM

I am happy to announce that my team is ready to deploy a new version of our GitHub Sync Toolset on November 26, 2019 from 10:00 to 11:00 am EST.

We are not expecting any disruption of service but it’s possible that some committers may lose write access to their Eclipse project GitHub repositories during this 1 hour maintenance window.

This toolset is responsible for syncronizing Eclipse committers accross all our GitHub repositories and on top of that, this new release will start syncronizing contributors.

In this context, a contributor is a GitHub user with read access to the project GitHub repositories. This new feature will allow committers to assign issues to contributors who currently don’t have write access to the repository. This feature was requested in 2015 via Bug 483563 - Allow assignment of GitHub issues to contributors.

Eclipse Committers are reponsible for maintaining a list of GitHub contributors from their project page on the Eclipse Project Management Infrastructure (PMI).

To become an Eclipse contributor on a GitHub for a project, please make sure to tell us your GitHub Username in your Eclipse account.

November 19, 2019 08:10 PM

Jakarta Microprofile REST Client in Eclipse

by Christian Pontesegger ( at November 18, 2019 11:19 AM

Today we are going to implement a simple REST client for an Eclipse RCP application. Now with Jakarta @ Eclipse and all these nice Microprofile implementations this should be a piece of cake, right? Now lets see...

Source code for this tutorial is available on github as a single zip archive, as a Team Project Set or you can browse the files online.

Step 1: Dependencies

The Eclipse Microprofile REST Client repository is a good place to get started. It points to several implementations (at the bottom of the readme). Unfortunately these implementations do not host any kind of p2 sites which we could use directly. So our next stop is Eclipse Orbit, but same situation there. This means we need to collect our dependencies manually.

For my example I used RESTEasy, simply as it was the only one I could get working within reasonable time. To fetch dependencies, download the latest version of RESTEasy. As the RESTEasy download package does not contain the REST client API, we need to fetch that from another source. I found it in the Apache CXF project, so download the latest version too. If you know a better source, please let me know in the comments.

Now create a new Plug-in from Existing JAR Archives. Click on Add External... and add all jars from resteasy-jaxrs-x.y.z.Final/lib/*.jar. Further add apache-cxf-x.y.z/lib/
This plug-in now contains all dependencies we need for our client. Unfortunately also a lot of other stuff we probably do not need, but we leave the cleanup for later.

Step 2: Define the REST service

For our example we will build a client for the Petstore Service, which can be used for testing purposes. Further it provides a swagger interface to test the REST calls online. I recommend to check out the API and play with some commands online and with curl.

Lets write a simple client for the store with its 4 commands. The simplest seems to be the inventory command, so we will start there. Create a new Java interface:
package com.codeandme.restclient.resteasy;


public interface IStoreService {

Response getInventory();
Everything necessary for RESTEasy is provided via annotations:

  • @Path defines the path for the command of the REST service
  • @GET defines that we have to use a GET command (there exist annotations for POST, DELETE, PUT)
  • @Produces finally defines the type of data we do get in response from the server.
Step 3: Create an instance of the service

Create a new class StoreServiceFactory:
package com.codeandme.restclient.resteasy;


import org.jboss.resteasy.client.jaxrs.ResteasyClient;
import org.jboss.resteasy.client.jaxrs.ResteasyWebTarget;
import org.jboss.resteasy.client.jaxrs.internal.ResteasyClientBuilderImpl;

public class StoreServiceFactory {

public static IStoreService createStoreService() throws URISyntaxException {
ResteasyClient client = new ResteasyClientBuilderImpl().build();
ResteasyWebTarget target = URI(""));
return target.proxy(IStoreService.class);

This is the programmatic way to create a client instance. There also exists another method called CDI, which I did not try out in Eclipse.

The service is ready and usable, so give it a try. The result object returned does contain some valuable information:

  • getStatus() provides the HTTP response status. 200 is expected for a successful getInventory()
  • getEntity() provides an InputStream which contains the JSON encoded response data from the server
Step 4: Response decoding

Our response is encoded as JSON collection of properties. In Java terms this basically reflects to a Map<String, String>. Instead of decoding the data manually, we let the framework do it for us:

Change the IStoreService to:

 Map<String, String> getInventory();
Anything else is done by the framework. Now how easy was that?

Step 5: POST request

To place an order we need order parameters. Best we encapsulate them in a dedicated Order class. From the definition of the order REST call we can see that we need following class properties: id, petId, quantity, shipDate, status, complete. Add these parameters as fields to the Order class and create getters/setters for them.

Now we can extend our IStoreService with the fileOrder() call:

public interface IStoreService {

Map<String, String> getInventory();

void fileOrder(Order order);

The Order automatically gets encoded as JSON object. No need for us to do the coding manually!

As parts of the path are the same for both calls, I moved the common component to the class level.

Step 6: Path parameters

To fetch an order we need to put the orderId in the request path. Coding of such parameters is put in curly braces. The parameter on the java call then gets annotated so the framework knows which parameter value to put into the path:

Order getOrder(@PathParam("orderId") int orderId);

Again the framework takes care of the decoding of the JSON data.

Step 7: DELETE an Order

Deleting needs the orderId as before:

void deleteOrder(@PathParam("orderId") int orderId);

The REST API does not provide a useful JSON response to the delete call. One option is to leave the response type to void. In case the command fails, an exception will be thrown (eg when the orderId is not found and the server returns 404).

Another option is to set the return type to Now we do get everything the server sends back and no execption is thrown anymore. Sometimes we might only be interested in the status code. This can be fetched when setting the return type to Response.Status. Again, no exception will be thrown on a 404.

Optional: Only have required RESTEasy dependencies

Looking at all these jars I could not figure out a good way to get rid of the ones unused by the REST client. So I provided unit tests for all my calls and then removed dependencies step by step until I found the minimal set of required jars.

by Christian Pontesegger ( at November 18, 2019 11:19 AM

Show Your Support for Open Source IoT at the Eclipse Foundation

November 14, 2019 04:35 PM

The Eclipse IoT working group is launching a campaign to identify the adopters of Eclipse IoT open source projects. Companies — whether or not they are working group members — can be listed as adopters.

Adopters are organizations that voluntarily show their support for the Eclipse IoT projects they have adopted (i.e. shipping commercial products based on the projects and/or using the projects for non-commercial or internal reasons).

You can add your organization logo to our list of adopters by submitting a pull request or by creating an issue. You can attach files to an issue by dragging and dropping them in the text editor of the form.

If you plan on submitting a pull request, you will need to make the following changes to the website codebase:

  1. Add a colored and a white organization logo to static/assets/images/adoptors. We expect that all submitted logos to be transparent svg.
  2. Update the adopter data file: data/adopters.yml If your organization wishes to express support for multiple projects, you will need to add your organization’s YAML definition to the adopters list of each of the relevant project nodes.

Your participation in this initiative will publicly show your support for open source innovation.

List Eclipse IoT adopters on an Eclipse project website

Eclipse projects can showcase the logos of their adopters on their project websites. We built a JavaScript plugin to make this process easier. If you are a project committer, here are quick instructions on how to use the eclipsefdn-adopters.js on your Eclipse project website:


Include the plugin’s JS in the section of the page:

<script src="//"></script>

Load the plugin:

project_id: "[project_id]"

Create an HTML element containing the chosen selector:

<div class="eclipsefdn-adopters"></div>
  • By default, the selector’s value is eclipsefdn-adopters.


project_id: "[project_id]",
selector: ".eclipsefdn-adopters",
ul_classes: "list-inline",
logo_white: false
Attribute Type Default Description
project_id String Required: Select adopters from a specific project ID.
selector String .eclipsefdn-adopters Define the selector that the plugin will insert adopters into.
ul_classes String Define classes that will be assigned to the ul element.
logo_white Boolean false Whether or not we use the white version of the logo.

November 14, 2019 04:35 PM

New features in Red Hat CodeReady Studio 12.13.0.GA and JBoss Tools 4.13.0.Final for Eclipse 2019-09

by Jeff Maury at November 11, 2019 07:30 AM

JBoss Tools 4.13.0 and Red Hat CodeReady Studio 12.13 for Eclipse 2019-09 are here and waiting for you. In this article, I’ll cover the highlights of the new releases and show how to get started.


Red Hat CodeReady Studio (previously known as Red Hat Developer Studio) comes with everything pre-bundled in its installer. Simply download it from our Red Hat CodeReady Studio product page and run it like this:

java -jar codereadystudio-<installername>.jar

JBoss Tools or Bring-Your-Own-Eclipse (BYOE) CodeReady Studio requires a bit more.

This release requires at least Eclipse 4.13 (2019-09), but we recommend using the latest Eclipse 4.13 2019-09 JEE Bundle because then you get most of the dependencies pre-installed.

Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under “JBoss Tools” or “Red Hat CodeReady Studio.”

For JBoss Tools, you can also use our update site directly:

What’s new?

Our main focus for this release was improvements for container-based development and bug fixing. Eclipse 2019-06 itself has a lot of new cool stuff, but I’ll highlight just a few updates in both Eclipse 2019-06 and JBoss Tools plugins that I think are worth mentioning.

Red Hat OpenShift

OpenShift Container Platform 4.2 support

With the new OpenShift Container Platform (OCP) 4.2 now available (see the announcement), even if this is a major shift compared to OCP 3, Red Hat CodeReady Studio and JBoss Tools are compatible with this major release in a transparent way. Just define your connection to your OCP 4.2 based cluster as you did before for an OCP 3 cluster, and use the tooling!

CodeReady Containers 1.0 Server Adapter

A new server adapter has been added to support the next generation of CodeReady Containers 1.0. Although the server adapter itself has limited functionality, it is able to start and stop the CodeReady Containers virtual machine via its crc binary. Simply hit Ctrl+3 (Cmd+3 on OSX) and type new server, which will bring up a command to set up a new server.

crc server adapter

Enter crc in the filter textbox.

You should see the Red Hat CodeReady Containers 1.0 server adapter.

Select Red Hat CodeReady Containers 1.0 and click Next.

All you have to do is set the location of the CodeReady Containers crc binary file and the pull secret file location, which can be downloaded from

Once you’re finished, a new CodeReady Containers server adapter will then be created and visible in the Servers view.

Once the server is started, a new OpenShift connection should appear in the OpenShift Explorer view, allowing the user to quickly create a new Openshift application and begin developing their AwesomeApp in a highly replicatable environment.

Server tools

Wildfly 18 Server Adapter

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

EAP 7.3 Beta Server Adapter

A server adapter has been added to work with EAP 7.3 Beta.

Hibernate Tools

Hibernate Runtime Provider Updates

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

The Hibernate 5.4 runtime provider now incorporates Hibernate Core version 5.4.7.Final and Hibernate Tools version 5.4.7.Final.

The Hibernate 5.3 runtime provider now incorporates Hibernate Core version 5.3.13.Final and Hibernate Tools version 5.3.13.Final.


Views, Dialogs and Toolbar

The new Quick Search dialog provides a convenient, simple and fast way to run a textual search across your workspace and jump to matches in your code. The dialog provides a quick overview showing matching lines of text at a glance. It updates as quickly as you can type and allows for quick navigation using only the keyboard. A typical workflow starts by pressing the keyboard shortcut Ctrl+Alt+Shift+L (or Cmd+Alt+Shift+L on Mac). Typing a few letters updates the search result as you type. Use Up-Down arrow keys to select a match, then hit Enter to open it in an editor.

Save editor when Project Explorer has focus

You can now save the active editor even when the Project Explorer has focus. In cases where an extension contributes Saveables to the Project Explorer, the extension is honored and the save action on the Project Explorer will save the provided saveable item instead of the active editor.

“Show In” context menu available for normal resources

The Show In context menu is now available for an element inside a resource project on the Project Explorer.

Show colors for additions and deletions in Compare viewer

In simple cases such as a two-way comparison or a three-way comparison with no merges and conflicts, the Compare viewer now shows different colors, depending on whether text has been added, removed, or modified. The default colors are green, red, and black, respectively.

The colors can be customized through usual theme customization approaches, including using related entries in the Colors and Fonts preference page.

Editor status line shows more selection details

The status line for Text Editors now shows the cursor position, and when the editor has something selected, it shows the number of characters in the selection as well. This also works in the block selection mode.

These two new additions to the status line can be disabled via the General > Editors > Text Editors preference page.

Shorter dialog text

Several dialog texts have been shortened. This allows you to capture important information faster.



Close project via middle-click

In the Project Explorer, you can now close a project using middle-click.


Improved usability of Environment tab in Launch Configurations

In the Environment tab of the Launch Configuration dialog, you can now double-click on an environment variable name or value and start editing it directly from the table.

Right-clicking on the environment variable table now opens a context menu, allowing for quick addition, removal, copying, and pasting of environment variables.

Show Command Line for external program launch

The External Tools Configuration dialog for launching an external program now supports the Show Command Line button.


Close editors automatically when reaching 99 open editors

The preference to close editors automatically is now enabled by default. It will be triggered when you have opened 99 files. If you continue to open editors, old editors will be closed to protect you from performance problems. You can modify this setting in the Preferences dialog via the General > Editors > Close editors automatically preference.

In-table color previews for Text Editor appearance color options

You can now see all the colors currently being used in Text Editors from the Appearance color options table, located in the Preferences > General > Editors > Text Editor page.

Automatic detection of UI freezes in the Eclipse SDK

The Eclipse SDK has been configured to show stack traces for UI freezes in the Error Log view by default for new workspaces. You can use this information to identify and report slow parts of the Eclipse IDE.

You can disable the monitoring or tweak its settings via the options in the General > UI Responsiveness Monitoring preference page as shown below.

Themes and Styling

Start automatically in dark theme based on OS theme

On Linux and Mac, Eclipse can now start automatically in dark theme when the OS theme is dark. This works by default, that is on a new workspace or when the user has not explicitly set or changed the theme in Eclipse.

Display of Help content respects OS theme

More and more operating systems provide a system-wide dark theme. Eclipse now respects this system-wide theme setting when the Eclipse help content is displayed in an external browser. A prerequisite for this is a browser that supports the prefers-color-scheme CSS media query.

As of the time of writing, the following browser versions support it:

  • Firefox version 67
  • Chrome version 76
  • Safari version 12.1

Help content uses high-resolution icons.

The Help System, as well as the help content of the Eclipse Platform, the Java Development Tooling, and the Plug-in Development Environment, now uses high-resolution icons. They are now crisp on high-resolution displays and also look much better in the dark theme.

Improved dark theme on Windows

Labels, Sections, Checkboxes, Radio Buttons, FormTexts, and Sashes on forms now use the correct background color in the dark mode on windows.

General Updates

Interactive performance

Interactive performance has been further improved in this release and several UI freezes have been fixed.

Show key bindings when command is invoked

For presentations, screencasts, and learning purposes, it is very helpful to show the corresponding key binding when a command is invoked. When the command is invoked (via a key binding or menu interaction) the key binding, the command’s name and description are shown on the screen.

You can activate this in the Preferences dialog via the Show key binding when command is invoked checkbox on the General > Keys preference page. To toggle this setting quickly, you can use the Toggle Whether to Show Key Binding command (e.g., via the quick access).

Java Developement Tools (JDT)

Java 13 Support

Java 13 is out, and Eclipse JDT supports Java 13 for 4.13 via Marketplace.

The release notably includes the following Java 13 features:

  • JEP 354: Switch Expressions (Preview).
  • JEP 355: Text Blocks (Preview).

Please note that these are preview language features; hence, the enable preview option should be on. For an informal introduction of the support, please refer to Java 13 Examples wiki.

Java Views and Dialogs

Synchronize standard and error output in console

The Eclipse Console view currently can not ensure that mixed standard and error output is shown in the same order as it is produced by the running process. For Java applications, the launch configuration Common tab now provides an option to merge standard and error output. This ensures that standard and error output is shown in the same order it was produced but also disables the individual coloring of error output.

Java Editor

Convert to enhanced ‘for’ loop using Collections

The Java quickfix/cleanup Convert to enhanced ‘for’ loop is now offered on for loops that are iterating through Collections. The loop must reference the size method as part of the condition and if accessing elements in the body, must use the get method. All other Collection methods other than isEmpty invalidate the quickfix being offered.

Initialize ‘final’ fields

A Java quickfix is now offered to initialize an uninitialized final field in the class constructor. The fix will initialize a String to the empty string, a numeric base type to 0, and, for class fields, it initializes them using their default constructor if available or null if no default constructor exists.

Autoboxing and Unboxing

Use Autoboxing and Unboxing when possible. These features are enabled only for Java 5 and higher.

Improved redundant modifier removal

The Remove redundant modifier now also removes useless abstract modifier on the interfaces.

For the given code:

You get this:

Javadoc comment generation for module

Adding a Javadoc comment to a Java module ( will result in automatic annotations being added per the new module comment preferences.

The $(tags) directive will add @uses and @provides tags for all uses and provides module statements.

Chain Completion Code Assist

Code assist for “Chain Template Proposals” will be available. These will traverse reachable local variables, fields, and methods, to produce a chain whose return type is compatible with the expected type in a particular context.

The preference to enable the feature can be found in the Advanced sub-menu of the Content Assist menu group (Preferences > Java > Editor > Content Assist > Advanced).

Java Formatter

Remove excess blank lines

All the settings in the Blank lines section can now be configured to remove excess blank lines, effectively taking precedence over the Number of empty lines to preserve setting. Each setting has its own button to turn the feature on, right next to its number control. The button is enabled only if the selected number of lines is smaller than the Number of empty lines to preserve; otherwise, any excess lines are removed anyway.

Changes in blank lines settings

There’s quite a lot of changes in the Blank lines section of the formatter profile.

Some of the existing subsections and settings are now phrased differently to better express their function:

  • The Blank lines within class declarations subsection is now Blank lines within type declaration.
  • Before first declaration is now Before first member declaration.
  • Before declarations of the same kind is now Between member declarations of different kind.
  • Before member class declarations is now Between member type declarations.
  • Before field declarations is now Between field declarations.
  • Before method declarations is now Between method/constructor declarations.

More importantly, a few new settings have been added to support more places where the number of empty lines can be controlled:

  • After last member declaration in a type (to complement previously existing Before first member declaration setting).
  • Between abstract method declarations in a type (these cases were previously handled by Between method/constructor declarations).
  • At end of method/constructor body (to complement previously existing At beginning of method/constructor body setting).
  • At beginning of code block and At end of code block.
  • Before statement with code block and After statement with code block.
  • Between statement groups in ‘switch.’

Most of the new settings have been put in a new subsection Blank lines within method/constructor declarations.


JUnit 5.5.1

JUnit 5.5.1 is here and Eclipse JDT has been updated to use this version.


Enhanced support for –patch-module during launch

The Java Launch Configuration now supports patching of different modules by different sources during the launch. This can be verified in the Override Dependencies…​ dialog in the Dependencies tab in a Java Launch Configuration.

Java Build

Full build on JDT core preferences change

Manually changing the settings file .settings/org.eclipse.jdt.core.prefs of a project will result in a full project build, if the workspace auto-build is on. For example, pulling different settings from a git repository or generating the settings with a tool will now trigger a build. Note that this includes timestamp changes, even if actual settings file contents were not changed.

For the 4.13 release, it is possible to disable this new behavior with the VM property: -Dorg.eclipse.disableAutoBuildOnSettingsChange=true. It is planned to remove this VM property in a future release.

And more…​

You can find more noteworthy updates in on this page.

What is next?

Having JBoss Tools 4.13.0 and Red Hat CodeReady Studio 12.13 out we are already working on the next release for Eclipse 2019-12.


The post New features in Red Hat CodeReady Studio 12.13.0.GA and JBoss Tools 4.13.0.Final for Eclipse 2019-09 appeared first on Red Hat Developer.

by Jeff Maury at November 11, 2019 07:30 AM

Getting to the Source

by Ed Merks ( at November 08, 2019 09:04 AM

As a Java developer using JDT, no doubt you are intimately familiar with Ctrl-Shift-T to launch the Open Type dialog.  You might not even realize this is a shortcut accessible via the Navigate menu.  So you probably will not have noticed that this menu also contains Open Discovered Type:

Eclipse has a huge variety of open source projects maintained in a bewildering collection of Git repositories.  Many are hosted at Eclipse:
Others are hosted at Github:

Finding the Git repository that contains a particular Java class is like finding a needle in a haystack.  This is where Open Discovered Type comes to the rescue.  Once a week, Oomph indexes every *.java file in every Git repository hosted by and  The Open Discovered Type dialog loads this information to populate a tree view of all these packages and classes.

Please read the help information the first time you use it.  It was written to help you get the most out of this dialog.  Also be patient the first time you launch the dialog; there's a lot of information to download.

Suffice to say, you can use the dialog much like you do Open Type.  So here we search for JavaCore and discover all the classes with that name:

We can select any one of them and discover all the Git repositories containing that class and we can use the context menu for each link for each repository or for the specific file in that repository to open the link where we want it opened.  From that link, you can of course see the full history of the repository or specific file.

As a bonus, if this repository provides an Oomph setup, you can easily use that Oomph setup to import the sources for this project into your workspace. If there is no Oomph setup, you'll have to do that manually.

In any case, contributing to Eclipse open source projects has never been easier.

by Ed Merks ( at November 08, 2019 09:04 AM

Eclipse startup up time improved

November 05, 2019 12:00 AM

I’m happy to report that the Eclipse SDK integration builds starts in less than 5 seconds (~4900 ms) on my machine into an empty workspace. IIRC this used to be around 9 seconds 2 years ago. 4.13 (which was already quite a bit improved used around 5800ms (6887ms with EGit and Marketplace). For recent improvements in this release see Thanks to everyone who contributed.

November 05, 2019 12:00 AM

Announcing Ditto Milestone 1.0.0-M2

November 04, 2019 12:00 AM

The second and last milestone of the upcoming release 1.0.0 was released today.

Have a look at the Milestone 1.0.0-M2 release notes for what changed in detail.

The main changes and new features since the last release 1.0.0-M1a release notes are

  • invoking custom foreign HTTP endpoints as a result of events/messages
  • ability to reflect Eclipse Hono’s device connection state in Ditto’s things
  • support for OpenID Connect / OAuth2.0 based authentication in Ditto Java Client
  • configurbale throttling of max. consumed WebSocket commands / time interval


The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central.

The Docker images have been pushed to Docker Hub:


The Eclipse Ditto team

November 04, 2019 12:00 AM

Setup a Github Triggered Build Machine for an Eclipse Project

by Jens v.P. ( at October 29, 2019 12:55 PM

Disclaimer 1: This blog post literally is a "web log", i.e., it is my log about setting up a Jenkins machine with a job that is triggered on a Github pull request. A lot of parts have been described elsewhere, and I link to the sources I used here. I also know that nowadays (e.g., new Eclipse build infrastructure) you usually do that via docker -- but then you need to configure docker, in which

by Jens v.P. ( at October 29, 2019 12:55 PM

LiClipse 6.0.0 released

by Fabio Zadrozny ( at October 25, 2019 06:59 PM

LiClipse 6.0.0 is now out.

The main changes is that many dependencies have been updated:

- it's now based on Eclipse 4.13 (2019-09), which is a pretty nice upgrade (in my day-to-day use I find it appears smoother than previous versions, although I know this sounds pretty subjective).

- PyDev was updated to 7.4.0, so, Python 3.8 (which was just released) is now already supported.


by Fabio Zadrozny ( at October 25, 2019 06:59 PM

Qt World Summit 2019 Berlin – Secrets of Successful Mobile Business Apps

by ekkescorner at October 22, 2019 12:39 PM

Qt World Summit 2019

Meet me at Qt World Summit 2019 in Berlin


I’ll speak about development of mobile business apps with

  • Qt 5.13.1+ (Qt Quick Controls 2)
    • Android
    • iOS
    • Windows 10


Qt World Summit 2019 Conference App

As a little appetizer I developed a conference app. HowTo download from Google Play Store or Apple and some more screenshots see here.


sources at GitHub

cu in Berlin

by ekkescorner at October 22, 2019 12:39 PM

A nicer icon for Quick Access / Find Actions

October 20, 2019 12:00 AM

Finally we use a decent icon for Quick Access / Find Actions. This is now a button in the toolbar which allows you to trigger arbitrary commands in the Eclipse IDE.

October 20, 2019 12:00 AM

A Tool for Jakarta EE Package Renaming in Binaries

by BJ Hargrave ( at October 17, 2019 09:26 PM

In a previous post, I laid out my thinking on how to approach the package renaming problem which the Jakarta EE community now faces. Regardless of whether the community chooses big bang or incremental, there are still existing artifacts in the world using the Java EE package names that the community will need to use together with the new Jakarta EE package names.

Tools are always important to take the drudgery away from developers. So I have put together a tool prototype which can be used to transform binaries such as individual class files and complete JARs and WARs to rename uses of the Java EE package names to their new Jakarta EE package names.

The tools is rule driven which is nice since the Jakarta EE community still needs to define the actual package renames for Jakarta EE 9. The rules also allow the users to control which class files in a JAR/WAR are transformed. Different users may want different rules depending upon their specific needs. And the tool can be used for any package renaming challenge, not just the specific Jakarta EE package renames.

The tools provides an API allowing it to be embedded in a runtime to dynamically transform class files during the class loader definition process. The API also supports transforming JAR files. A CLI is also provided to allow use from the command line. Ultimately, the tool can be packaged as Gradle and Maven plugins to incorporate in a broader tool chain.

Given that the tool is prototype, and there is much work to be done in the Jakarta EE community regarding the package renames, I have started a list of TODOs in the project' issues for known work items.

Please try out the tool and let me know what you think. I am hoping that tooling such as this will ease the community cost of dealing with the package renames in Jakarta EE.

PS. Package renaming in source code is also something the community will need to deal with. But most IDEs are pretty good at this sort of thing, so I think there is probably sufficient tooling in existence for handling the package renames in source code.

by BJ Hargrave ( at October 17, 2019 09:26 PM

I’ll never forget that first EclipseCon meeting with you guys and Disney characters all around and…

by Doug Schaefer at October 16, 2019 01:18 AM

I’ll never forget that first EclipseCon meeting with you guys and Disney characters all around and the music. And all the late nights in the Santa Clara bar and summits and meetings talking until no one else was left. Great times indeed. Until we meet again Michael!

by Doug Schaefer at October 16, 2019 01:18 AM

Missing ECE already? Bring back a little of it - take the survey!

by Anonymous at October 15, 2019 09:22 PM

We hope you enjoyed the 2019 version of EclipseCon Europe and OSGi Community Event as much as we did.

Please share your thoughts and feedback by completing the short attendee survey. We read all responses, and we will use them to improve next year's event.

Speakers, please upload your slides to your session page. Attendees really appreciate this!

by Anonymous at October 15, 2019 09:22 PM

A Committer’s View of Our New ECD Tools Working Group

by Thabang Mashologu at October 10, 2019 01:48 PM

When you look at the very impressive list of founding members for our new Eclipse Cloud Development (ECD) Tools Working Group, it’s clear that world-leading technology companies strongly believe that open source, cloud native development tools are needed. Our Eclipse Foundation developer community has also enthusiastically embraced the initiative.

To get an insider’s view of why the ECD Tools Working Group initiative is so important, I recently talked to Carlos Andres De La Rosa, an active Eclipse Foundation committer, about why he is getting involved in the Working Group. Here’s an edited version of our conversation.


Q. How did you first become involved in the open source communities at the Eclipse Foundation?

 A. I was looking for something interesting from which I could learn something new related to cloud technologies. I found the Eclipse MicroProfile project about two years ago. That was a very interesting topic for me, especially the fault tolerance spec. I added my email address to the mailing list and started joining weekly calls. After a while, I started to contribute to the spec with different things, like improving the spec testing, adding and modifying documentation, and also debating about how to evolve the spec. I became a committer and an entire technological world opened up for me. Jakarta EE was another interesting project that got my attention, so then I became involved with the Jakarta EE community.

I like the fact that Eclipse projects are from the people, for the people, so anyone can learn and contribute to solve problems that can help a lot of developers around the world. It’s shared knowledge and that’s the most important thing for me.


Q. Why did you expand your involvement to include the ECD Tools Working Group?

 A. When you’re part of the community, you have access to beta versions of the specifications and projects. I was looking around and I learned about this new project for cloud development tools. I saw the charter and what people were trying to achieve and I knew I wanted to be part of it. It was that simple.

I think cloud technologies will be the biggest and most important topic for the next 10 years. Everything is moving to the cloud, so every day we have more applications, from banking to AI medical analysis services. And, people have easy access to all this thanks to the cloud. I want to be there at the forefront and be working for the community when cloud really starts to grow.


Q. What benefits do you expect to gain from your participation in the ECD Tools Working Group?

A. It’s a huge opportunity to learn from the best engineers in the world because there are a lot of great professionals at the Eclipse Foundation and they have a lot of experience driving technology forward. If you’re new to this field and you’re trying to learn new things, this is a big chance to do it. Also, I’m currently working as a cloud consultant and this project is very related to my day-to-day job, so I can use what I learn in this project to improve my consultancy services.


Q. What impact do you think the ECD Tools Working Group will have on open source, cloud native development?

A. I think the impact will be huge because this group will deliver all of the tools that will be used every day in cloud development. From deploy, scale, debug, and manage, to Cloud Foundry applications, everything is integrated with the Eclipse IDE making the job of developers more productive.


Q. How does your participation in the ECD Tools Working Group fit with the other cloud-related projects you’re involved with at the Eclipse Foundation?

A. Everything is related. MicroProfile provides implementations and specs for capabilities such as fault tolerance that are needed in a microservices architecture to make it easier for developers to create microservices. And the Jakarta EE specs are basically the foundation for the MicroProfile framework because MicroProfile depends on the Java enterprise specs. The Eclipse Cloud Development Tools is a complementary project that helps to complete the framework for cloud native applications. So, they are all part of the cloud ecosystem. 

I really think that MicroProfile, Jakarta EE, and now the Eclipse Cloud Development Tools Working Group are the three most important projects at the Eclipse Foundation right now. They will drive the future of cloud technologies and everything that is handled and developed by the community.


Q. What would you say to people who are considering joining the ECD Tools Working Group?

A. I would say “join now!” The most important thing I can tell people is get involved if you want to learn about a cutting-edge technology that will be driving peoples’ lives for a long time. And contribute to help create something meaningful. It’s a community, so it’s for everyone.

by Thabang Mashologu at October 10, 2019 01:48 PM

Open Source Gerrymandering

by Chris Aniszczyk at October 08, 2019 06:20 PM

Over the years, I have spent a lot of time thinking about and working on open source communities… from bootstrapping projects out of corporations (or broken communities), to starting brand new open source foundations.

I was recently having a conversation with an old colleague about bringing an open source project out of a company into the wild and how to setup the project for success. A key part of that discussion involved setting up the governance for the project and what that means. There was also discussion how neutral and open governance under a nonprofit foundation can be good for certain projects as research has shown that neutral foundations can promote growth and community better than other approaches. Also the conversation led to a funny side discussion on the concept of gerrymandering and open source.

For those who aren’t familiar with the term, it’s become popular in the US political lexicon as a “practice intended to establish a political advantage for a particular party or group by manipulating district boundaries.� A practical example of this is from my town of Austin TX which is in district 35 which snakes all the way from Austin to San Antonio for some reason.

The same concept of gerrymandering can apply to open source communities as open source projects can act like mini political institutions (or bigger ones in the case of Kubernetes). I shared some of my favorite examples with my friend so I figured I’d write this down for future reference and share it with folks as you really need to read the “fine print� to find these at times.

Apache Cassandra

The Apache Software Foundation (ASF) is a fantastic open source organization that has been around for a long time (they celebrated their 20th anniversary) and has had a lot of impact across the world. The way projects are governed in the ASF are through the Apache Way, which places a lot of emphasis on “community over code� amongst some other principles which are great practices for open source projects to follow.

There have been some interesting governance issues and lessons learned over the years in the ASF, in particular it can be challenging when you have a strong single vendor associated with a project as was with the case with Cassandra awhile ago:

As the ASF board noted in the minutes from its meeting with DataStax representatives, “The Board expressed continuing concern that the PMC was not acting independently and that one company had undue influence over the project.” There was some interesting press around the time this happened:

“Jagielski told me in an interview, echoing what he’d said on the Cassandra mailing list, that undue influence conflicts with project leadership obligations established by the ASF. As he suggested, the ASF tried many times to get a DataStax-heavy Project Management Committee (PMC) to pay attention to alleged trademark and other violations, to no avail. Whatever DataStax’s positive influence on the development of the project—in other words—it failed to exercise equivalent influence on governing the project in ASF fashion.â€�

The ASF basically forced a reorganization of the Cassandra PMC to be in more in lines with its values and then caused the primary vendor behind the project to pull engineers off the open source project.


The containerd project is an industry-standard container runtime with an emphasis on simplicity, robustness and portability. The history of the project comes from being born at Docker where their open source projects had a governance policy essentially aligned with the BDFL philosophy with one of their project founders.

In CNCF, (which containered is a project of), project governance documents aren’t considered static and evolve over time to meet the needs of their community. For example, when containerd joined the CNCF their governance was geared towards a BDFL approach but over time evolved to a more neutral approach that spread authority across maintainers.

Cloud Foundry

Cloud Foundry is an open source community that has a large and mature ecosystem of PaaS focused projects. In the Cloud Foundry Foundation (CFF), they have a unique governance clauses in regards to how affiliates are treated and voting.

Pivotal Platinum Director Voting Power. The Platinum Director appointed by Pivotal (“Pivotal Director�) shall have five (5) votes on any matter submitted to a vote of the Board. (i) On a date one (1) year after the incorporation date set forth in the Certificate, the number of Pivotal Director’s votes will be reduced to three (3). (ii) On a date two (2) years after the incorporation date set forth in the Certificate, the number of Pivotal Director’s votes will be reduced to one (1)

To bootstrap the foundation, the originating company wanted a little bit of control for a couple of years, which can make sense in some situations as the beginning of a foundation can be a tumultuous time. In my opinion, it’s great to see the extra vote clause expire after 2 years, however, it’s still very unfair to the early potential members of the organization.

Another example of open source gerrymandering can be how votes are represented by member companies that are owned by a single entity:

At no time may a Member and its Affiliates have more than one Director who is an employee, officer, director, or consultant of that Member, except that Pivotal, EMC, and VMware, though Affiliates, shall each have one (1) Director on the Board).

This is an interesting tidbit given that Dell owns Pivotal, EMC and VMWare. In some organizations, usually there is legal language that collapses owned entities into one vote.

I personally I’m not the biggest fan of this approach as it makes things unfair from the beginning and can be an impediment to wide adoption across the industry. There can definitely be reasons of why you need to do this in the formation phase but it should be done with caution. If you saw the recent news that Pivotal was being spun back into VMWare and their woes with adoption, it shouldn’t come as a surprise in my opinion as one company was bearing too much of the burden in my opinion and not building a diverse community of contributors.

Cloud Native Computing Foundation (CNCF)

If you remember the early days of the container and orchestration wars, there was a lot different technologies, approaches and corporate politics. When CNCF was founded, the original charter included a clause that upgraded certain startup members from Silver to Platinum that were important in the ever evolving cloud native ecosystem.

“The Governing Board may extend a Platinum membership at the Silver Membership Scale rates on a year-by-year basis for up to 5 years to startup companies with revenues less than $50 million that are deemed strategic technology contributors by the Governing Board.�

In my opinion, that particular piece in the charter was important in bringing together all the relevant startups to the table along with the big established companies at the time.

In terms of projects, the CNCF Technical Oversight Committee (TOC) defines a set of principles to steward the technical community. The most important principle is around a minimum viable governance that enables projects to be self-governing. TOC members are available to provide guidance to the projects but do not control them.

Unlike Apache and the Apache Way, CNCF does not require its hosted projects to follow any specific governance model. Instead, CNCF specifies that graduated projects need to “explicitly define a project governance and committer process.� So in reality, CNCF operates under the principle of subsidiarity, encouraging decisions to be made at the lowest project level consistent with their resolution.


GitLab is a fantastic open source project AND company that I admire deeply for their transparency. The way the GitLab project is structured is that it’s wholly owned by the GitLab company (they also own the trademark). To the credit of GitLab, they make this clear via their stewardship principles online and discuss what they consider enterprise product work versus project work.

I’d love for them in the future to separate the branding from the company, project and the product as I believe it’s confusing and dilutes the messaging, but that’s just my opinion 🙂


Istio is a popular service mesh project originated at Google. It has documented its governance model publicly:

However, as you can see, it’s heavily tilted towards Google and there seems to be no limits on the number of spots on the steering committee from one company which is a common tactic in open governance approaches to keep things fair. On top of that, Google owns the trademark, domains and other project assets so I’d consider Istio to be heavily gerrymandered in Google’s versus the community’s interest.


I had the pleasure of serving on the Java Community Process (JCP) Executive Committee for a few years while I was at Twitter. It’s a great organization that drives standardization across the Java ecosystem, some of the fine print is interesting though:

“The EC is composed of 25 Java Community Process Members whose seats are allocated as follows: 16 Ratified Seats, 6 Elected Seats, and 2 Associate Seats, plus one permanent seat held by Oracle. (Oracle’s representative must not be a member of the PMO.) The EC is led by a non-voting Chair from the PMO.â€�

This essentially gives Oracle a permanent seat on the Executive Committee.

Here’s another fun clause:

Ballots to approve Umbrella JSRs that define the initial version of a new Platform Edition Specification or JSRs that propose changes to the Java language are approved if (a) at least a two-thirds majority of the votes cast are “yes” votes, (b) a minimum of 5 “yes” votes are cast, and (c) Oracle casts one of the “yes” votes. Ballots are otherwise rejected.

This essentially gives Oracle a veto vote on any JSR.

Note: The coolest thing the JCP has done is contribute the EE specification work to the Eclipse Foundation and form the Jakarta project over there to steward things in an open way.


Knative, like Istio mentioned above, is an open source project that was born at Google and controlled by Google. There have been a lot of discussion lately about this as Google recently decided to not openly govern the project and move it to a neutral foundation:


Kubernetes operates under the auspices of the CNCF and openly governed by the Kubernetes Steering Committee (KSC). The Kubernetes project has grown significantly over time, but has done a great job of keeping things openly governed and inclusive in my opinion, especially compared to its project size these days. The KSC governs the project along with a variety of sub working groups. Also, the Kubernetes trademark is neutrally owned by the CNCF and openly governed via the Conformance Working Group which decides how certification works for the community, which there are nearly 100 certified solutions out there!


The Spinnaker project was originally born at Netflix and recently spun out into the Continuous Delivery Foundation (CDF) as an openly governed project. The project assets, from domains to github to trademarks are all neutrally owned by the community through the CDF.


Vault is a fantastic and widely used secrets management tool from Hashicorp. It’s a single vendor controlled open source project that has an open core model with an open source and enterprise versions (see matrix). What this essentially means is that the buck stops at the single vendor on what features/fixes end up in the open source version, most likely that won’t include things that they sell in their enterprise offering.


I hope you learned something new about open source projects, foundations and communities as these things can be a little bit more complicated as you dig into the details. It’s really important to note that there is a difference between open source and open governance and you should always be skeptical of a project that claims it’s truly open if only one for profit company owns all the assets and control. While there’s nothing wrong with this approach at all, most organizations don’t set expectations up front which can lead to frustrations down the road. Note, there’s nothing wrong with single vendor controlled open source projects, I think they are great but I think they need to be upfront, similar to what GitLab stewardship principles on what they will put in open source versus their enterprise version.

In conclusion, as with anything in life, you should always read the fine print of an open source communities charter or legal paperwork to understand how it works. The lesson here is that every organization or project has its own rules and governance and it’s important that you understand how decisions are made and who has ownership of project assets like trademarks.

by Chris Aniszczyk at October 08, 2019 06:20 PM

JShell in Eclipse

by Jens v.P. ( at October 08, 2019 12:16 PM

Java 9 introduced a new command line tool: JShell. This is a read–eval–print loop (REPL) for Java with some really nice features. For programmers I would assume writing a test is the preferred choice, but for demonstrating something (in a class room for example) this is a perfect tool if you are not using a special IDE such as BlueJ (which comes with its own REPL). The interesting thing about

by Jens v.P. ( at October 08, 2019 12:16 PM

Removing “Contact Us

by tevirselrahc at October 07, 2019 02:17 PM

Unfortunately, because of the larger amount of spam, I now have to remove off the “Contact Us” page.

If you want to contact us, I would recommend you go through our twitter account.

by tevirselrahc at October 07, 2019 02:17 PM

Instanceof Type Guards in N4JS

by n4js dev ( at September 30, 2019 08:06 AM

Statically typed languages like Java use instanceof checks to determine the type of an object at runtime. After a successful check, a type cast needs to be done explicitly in most of those languages. In this post we present how N4JS introduced type guards to perform these type casts implicitly. 

No error due to implicit cast in successful instanceof type guard

The example above shows that strict type rules on the any instance a causes errors to show up when accessing the unknown property pX. However, after asserting that a is an instance of X, the property pX can be accessed without errors. A separate type cast is unnecessary, since type inference now also considers instanceof type guard information.

Hover information on variable access of a shows the inferred type

The resulting type is the intersection type of the original type (which is here any) and of all type guards that must hold on a specific variable access (which is here only type X). Keeping the original types any or Object is not necessary and could be optimised later. In case the original type is different, it is necessary to include it in the resulting intersection type. The reason is that the type guard could check for an interface only. If so, property accesses to properties of the original types would cause errors.

Re-definition of a type guarded variable

Two distinct differences between type guards and type declarations are (1) their data flow nature and (2) their read-only effects. Firstly, when redefining (in the sense of the data flow) a variable, the type guard information gets lost. Consequently, subsequent accesses to the variable will no longer benefit from the type guard, since the type guard was invalidated by the re-definition. Secondly, only the original type information is considered for a redefinition. That means that the type guard does not change the expected type and, hence, does not limit the set of types that can be assigned to a type guarded variable.

Further examples for instanceof type guards in N4JS

Data flow analysis is essential for type guards and has been presented in a previous post. Based upon this information, type information for each variable access is computed. Since also complicated data flows are handled correctly, such as in for loops or short circuit evaluation, type guard information is already available in composed condition expressions (see function f3 and f5 above). Aside from being able to nest instanceof type guards (see function f4 above), they also can be used as a filter at the beginning of a function (see function f6 above) or inside a loop: Negating a type guard and then exiting the function or block leaves helpful valid type guard information on all the remaining control flow paths.

by Marcus Mews

by n4js dev ( at September 30, 2019 08:06 AM

Team Sports for Developers! Edge Computing Mini-Hackathon

by Anonymous at September 26, 2019 09:21 PM

Do you like to build gadgets and/or hack? Then get a team together for the Edge Computing Mini-Hackathon, organized by Edgeworx.

Teams will be challenged to integrate at least one other Eclipse IoT project with Eclipse ioFog and showcase what they were able to accomplish. Representatives from all Eclipse projects are welcome to come help guide, coach, and influence participants to make use of their projects. There will be prizes for the standouts, plus giveaways (and fun) for all!

The event is part of Community Night on Tuesday, October 22, from 19:30 - 22:00 in the Theater Stage room at the Forum.

by Anonymous at September 26, 2019 09:21 PM

Blocked by an Eclipse Wizard?

by Wim at September 24, 2019 08:53 AM

Tuesday, September 24, 2019
There is a small but very useful patch in Eclipse 4.12 for people that do not want the UI to be blocked by wizards. There are many cases where it is desired that the underlying window can be reached WHILE the user is finishing the wizard. That's why it's strange that the Eclipse Wizard demands from us to always have full and utter attention.

Read more

by Wim at September 24, 2019 08:53 AM

Back to the top