Sponsor Testimonial: Orange Eclipse OM2M contributors

Orange has contributed for several years to Eclipse projects in Smart Home and OM2M, and it’s a great pleasure to be part of the EclipseCon Europe meeting once again. This year is particularly special for Orange because we are officially joining the Eclipse Foundation. Smart home represents for us the natural extension of our core business, telecommunications, and Eclipse represents to us a wonderful community of both open source developers and partners working together to think and built the future of smart home.

The OSGi IoT Demo updated and extended for 2017

OSGi Robot

by Mike Francis

The OSGi IoT Demo for the OSGi Community Event and EclipseCon 2017 has been updated and extended to deliver another interesting and informative showcase of OSGi in action in IoT.

Taking the foundations from the last three years of demos we will be using products from multiple vendors, open source projects and Raspberry PI computers to operate and control LEGO® trains running around a track. For 2017, we add a new and exciting dimension: a robot that will interact with the trains.

The robot will be used to load and unload cargo from train carriages and will be fully integrated into the OSGi environment and pluggable train management and control systems. The cargo will be tracked using IoT sensors in each container.

Also new for 2017, we will be using the open.DASH open source dashboard project to bring a new level of visualisation to all of the IoT sensor data we are collecting and using to deliver the demo.

The demo control software has also been updated to take advantage of a number of the new OSGi R7 specifications, including configurator, converter and Push Streams. We will continue to make good use of Kura, MQTT, Bluetooth, Wifi, Infrared and lots of other protocols and technologies integrated together using the core OSGi based system for control and management.

Mike Francis

Looking forward to seeing you at our stand in the exhibition area.

Mike Francis



Jigsaw arriving - and now what?

by Stephan Hermann

Learn more about Stephan's talk JDT embraces Java™ 9 - An insiders' view in this co-published blog.

The debate is over. The result of fierce discussions has been declared. Jigsaw is knocking at the door. Now the fate of Jigsaw depends on the community. Will the community embrace Jigsaw? Will we be able to leverage the new concepts to our benefit? Will we struggle with new pitfalls?

Let’s step back a second: do we really know what is Jigsaw? Do we really understand the design, its subtleties and implications?

At EclipseCon Europe 2017 I will try to shed some light on some lesser known aspects of Jigsaw. A deep dive into things I learned as a JDT committer while implementing tool support for Java 9.

In search of the truth

To set the stage, we’ll first have to figure out, who or what defines Java 9 — or Jigsaw — or JPMS. This is both a question of specification vs. implementation as well as a matter of a specification spread over several documents and artifacts. Let’s try to grok Jigsaw from the legally binding sources, rather then from secondary writing and hearsay (if that is possible).

We will have to relearn some of the basic terms, like: what is a package in Java? Do packages form a hierarchy? (I will show, how both answers, yes and no, are equally right and wrong).

Jigsaw is said to do away with some “undesirable” stuff like split packages, and cyclic dependencies. Really? (Yes and no).


Of course, with Jigsaw all is about encapsulation – easy to agree on, but what is it that a Java 9 module encapsulates? Only a deep understanding of the flavor of encapsulation will tell us, what exact qualities we gain from following the new discipline (it’s not about security, e.g.), and also what pains will be incurred on the path of migrating to the new model. (Hint: I will be speaking both about compile time and runtime).

Interestingly, the magic potion Jigsaw also brings its own antidote: With tightening the rules of encapsulation, also the opposite becomes necessary: they call it breaking encapsulation, for which I once coined the term “decapsulation“. I should be flattered by how close Java 9 comes to what I call “gradual encapsulation“. So, the talk can not stop at presenting just the new language concepts, also the various extra-lingual means for tuning your architecture need to be inspected through the looking glass. This is also where tools come into focus: how can JDT empower its users to use the new options without the need to dig through the sometimes cryptic syntax of command line parameters?

Loose ends

At this point we shall agree that Jigsaw is a compromise, fulfilling many of its goals and promises, while also missing some opportunities.

I will also have to say a few words of long standing API of JDT, which makes guarantees that are no longer valid in Java 9. This raises the question: what is the migration path for tools that sit on top of JDT? (There is no free lunch).

Finally, it wouldn’t be Java, if overloading wouldn’t make things worse for the newly added concepts. But: haven’t you become fond of hating, when JDT says:

error_obj The type cannot be resolved. It is indirectly referenced from required .class files

We may be seeing light at the end of the tunnel: for Jigsaw we had to revamp the guts of our compiler in ways, that could possibly help to – finally – resolve that problem. Wish me luck …

Hope to see you in Ludwigsburg, there’s much to be discussed over coffee and beer.



The League of Extraordinary Antipattern

by Dirk Fauth

Read more about Dirk's talk co-presented with Stefan Schlott, The League of Extraordinary Antipattern.

With our background of being consultants for several years, having seen a lot of projects, some years ago we started collecting what is called "bloomers" in literature. Those were the kind of programming misconceptions that made us laugh and cry at the same time.

A few years later, while refactoring an application to make it ready for the future, I came across several places in code that made it very hard to refactor. And I realised that these kinds of issues are quite common for beginners in object oriented programming. At a certain point in time while refactoring I started to give these anti-patterns the names of superheroes for several reasons:

1. I really like comic books and superheroes

2. I realized that the code that was produced looks like a very good idea in first place, so the one who produced it surely felt very good when he solved his problem this way

3. I wanted a name that is easy to remember to help others to avoid the same mistakes in the future.

One of these places in code was the misuse of statics, and this was the birth of "Captain Static". Whenever I needed to refactor static code to make it match object oriented principles I shouted out "Hey, I found another place where Captain Static tried to help!" or even simpler "Look, another Captain Static!". After a while I realized that people started thinking about whether to mark variables and methods static or not. And when they were unsure, they asked me if they are producing "another Captain Static" or if it would be correct in that scenario. The learning process started.

Talking to several people and remembering the "bloomer" from the past, the idea of the "League of Extraordinary Anti-Patterns" was born. We collected anti-patterns that are typically made by people starting with object oriented programming, enriched them with some anti-patterns that are made by accident (probably because they are hard to understand) and added those very uncommon but ugly "bloomers" to help people not to make the same mistakes.

We were asked why they are superheroes and not villains. Well, we like our job and what we are doing. We love to laugh and we know that it is easier to remember something when you laughed about it rather than someone simply saying "this is bad, don't do it!". And someone thought it would be a good idea to use this anti-pattern without knowing that it is one. So that person thought he found the superhero to solve his issue, but in the end it turned out that he was not that super at all.

As I like comics and superheroes, I started sketching our superheroes to also have a visualization. The digitalizing of theses sketches was done by Stefan´s sister, and I really like the professional result. To give you an example, have a look at the previously mentioned Captain Static.

If you like to laugh at a conference, about the speakers, the slides, the content or maybe even about yourself because you realize you did the same things in the past, you should come and attend our talk.

Hopefully you also learn something new that you didn't know or realize yet. And even if there is nothing new for you (lucky you!) you will enjoy an entertaining talk.

We had a lot of fun in preparing the talk and hope you will like to listen to it as much as we like to present it.

Captain Static


Dirk Fauth

Dirk Fauth is a Software Architect for Rich Client Systems working for the Robert Bosch GmbH in Stuttgart and a lecturer in Java basics for the Baden-Wuerttemberg Cooperative State University (DHBW). He is active in developing, teaching and talking about Eclipse RCP applications and Eclipse related technologies. He is project lead of the Nebula NatTable project, Eclipse Platform committer and also a committer and contributor to several other Eclipse projects.

Stefan Schlott

Dr. Stefan Schlott, Advisory Consultant is developer, architect, and trainer at BeOne Stuttgart GmbH and a lecturer for parallel programming for the Baden-Wuerttemberg Cooperative State University (DHBW). His specialties are security, privacy, scalable architectures, and the broad field of web technologies. He is a functional programming enthusiast, a fan of the Scala programming language and a friend of open source.


Sponsor Testimonial: Milen Dyankov, Liferay

As Strategic Members of the OSGi Alliance, Liferay is proud to sponsor the OSGi Community Event again and to be among the Eclipse community. ...Join us for three sessions given by Carlos Sierra, "OSGi Meets Lambdas", Milen Dyankov, "Fantastic Java Contracts and Where To Define Them?", and Ray Augé, "CDI and OSGi: So Happy Together!"

Tutorial: What every Eclipse developer should know about Angular

by Maximilian Koegel and Edgar Mueller

Interested in Angular? Maximilian Koegel and Edgar Mueller tell us more about their tutorial.

Many business applications nowadays have at least some web UI parts using server-side rendered, static HTML. With the latest dynamic HTML Javascript frameworks like React, Vue.js, or Ember.js, there is a continuous trend to implement these web front-ends as “single page” applications. While there is a lot of diversity in the JavaScript world, one framework that has become especially popular for business applications, is Angular. It allows you to extend HTML through dynamic behaviour and provides essential concepts for developing single page web applications.

While EclipseCon is primarily about Eclipse Technology, this tutorial is a chance to enhance your skills in addition to Eclipse. And, even though this tutorial is not directly about Eclipse technology, it is specifically geared towards Eclipse developers. Based on an example application, we explain basic concepts such as components and dependency injection - using terms and concepts from the Eclipse/Java ecosystem and relying on Eclipse-based tooling.

In the tutorial, we introduce Angular from scratch for Eclipse/Java developers. Iteratively, we apply our learning to hands-on exercises developing a web frontend to view and edit artists and their albums (see screenshot right).

Our target audience is explicitly Java and Eclipse developers with no or very limited previous experience with JavaScript, TypeScript, and Angular. While 3 hours is certainly not enough to become an expert on Angular, our goal is rather to provide a decent overview and basic understanding of Angular.

Angular example

If you would like to join us, when you register for EclipseCon Europe sign up for the tutorial What every Eclipse developer should know about Angular. See you in Ludwigsburg!

Maximilian and Edgar



Maximilian Koegel

Maximilian Koegel is deeply involved with the Eclipse community. He is a project lead (EMFStore, EMF Client Platform, Edapt) and a committer on several projects, and serves on the Eclipse Architecture Council. Maximilian is general manager of EclipseSource Munich (, where he is focused on pragmatic modeling and web applications. He has a strong research background, with a PhD on the topic of model versioning, and teaches Eclipse and open-source technology to university students.

Edgar Mueller

Edgar Mueller is a Software Engineer at EclipseSource Munich ( He has many years of experience with Eclipse RCP, EMF and EMFForms and is the project lead of EMFStore ( Edgar likes to work on various open source projects such as JSONForms ( or Play JSON Schema Validator ( where he is involved with technologies such as Javascript, Angular, JSON, JSON Schema, Play and Scala.


Sponsor Testimonial: The Itemis EclipseCon Team

...For more than a decade we haven’t missed a single conference. The networking opportunities are just outstanding and it’s always a great chance to get an early view on the new and upcoming trends in the Eclipse ecosystem... Also this year, itemis presents a wide range of Eclipse related, deep technical content. Amongst others, our topics cover Eclipse Modelling technology, Systems Engineering in the Automotive Industry and Machine Learning, ..

Mutate and Test Your Tests

by Benoit Baudry

I am extremely proud and happy that my talk on mutation testing was accepted as an early bird for EclipseCon Europe 2017.

We will talk a lot about software testing at the Project Quality Day. In this talk, I will focus on qualitative evaluation of a unit test suite. Statement coverage is commonly used to quantify the quality of a test suite: it measures the ratio of source code statements that are executed at least once when running the test suite. However, statement coverage is known to be a rather weak quality indicator. For example, a test suite that covers 100% of the statements and that has absolutely no assertion is a very bad test suite, yet is considered of excellent quality according to statement coverage.


Mutation testing is another way of evaluating the quality of a test suite, according to the following intuition: a test suite is good to test a specific program if it is able to detect bugs in this program; so, let's inject bugs into this program and see how much the test suite is able to detect. Mutation testing was proposed back at the end of the 1970's by Richard A. DeMillo, Richard J. Lipton, and Fred G. Sayward, and their idea was quite simple: create multiple mutants of the program under test, i.e., versions of the program with one seeded bug (for example, an off-by-one error), run the test suite against each mutant, and see how many are detected. Since then, many tools were built for mutation testing, including PIT, a state-of-the-art tool for Java mutation testing.

In the example below, PIT will generate one mutant in which the == operand at line 2 is replaced by !=, a mutant in which the return value.hashcode() at line 11 is replaced by return 0, and so on.

public int hashCode() {
    if (value == null) {return 31;}
    if (isIntegral(this)) {
        long value = getAsNumber().longValue();
        return (int) (value ^ (value >>> 32));
    if (value instanceof Number) {
        long value = Double.doubleToLongBits(getAsNumber().doubleValue());
        return (int) (value ^ (value >>> 32));
    return value.hashCode();

Mutation testing tools generate large quantities of mutants, and, consequently, the analysis takes a long time to run. In this talk, I will present Descartes: a mutation testing tool that adapts PIT for extreme mutation. Descartes follows the principle of mutation testing, but generates mutants by removing completely the body of a method, instead of injecting multiple small bugs. For example, Descartes generates only two mutants for the hashCode() above:

public int hashCode() {
    return 0;

public int hashCode() {
    return 1;

In this talk, I will summarize the principles of mutation testing, the current state of the art and then will illustrate how it can work with PIT and Descartes. I will conclude with some of the lessons we have learned when running Descartes on open source projects.


About the author

Benoit Baudry is a Professor at the KTH Royal Institute of Technology in Stockholm, Sweden. He currently investigates novel techniques for automatic test amplification in DevOps. His research focuses on program analysis, transformation, testing and diversification. Until August 2017 he was a research scientist at INRIA, France, where he led the DiverSE research group (EPI) since 2013.

On Language Servers: Interview with Martin Lippert


Martin Lippert's talk, Implementing Language Servers - the Good, the Bad, the Ugly is an early pick. Martin gives us his thoughts on why language servers are important, what the challenges are and what the future might look like for the technology.

Martin Lippert



Q: Language servers have been called a conceptual breakthrough. What in your opinion has come together to make it possible now?

A: The architecture behind language servers, mostly the language server protocol, hits a sweet spot. Language and framework providers can now, for the first time, focus on their language or their framework, instead of dealing with the numerous proprietary extension APIs of all the various IDEs and editors out there in the world. They can implement language tooling in the language of their choice, using libraries of their choice, and re-using the compiler technology of their choice - and all that in an editor- or IDE-agnostic way. They can do the job once instead of re-Implementing everything for each IDE they want to provide language tooling for. That is a huge step forward.

On the other side of the equation, people working on IDEs and code editors don’t need to think about individual languages anymore. They can focus on the user experience while editing code and let other people do the work for individual languages and frameworks.

In the end this makes up a powerful matrix of IDEs/editors and language servers which can all be combined independently of each other. It's a very powerful approach, especially since developers use a larger variety of languages and tools than ever before.


Q: What have been some of the challenges working with this innovative technology?

A: The devil is in the details - as always. The language server protocol defines the basic structure and semantics of the messages that the client (the IDE or the code editor) exchanges with the server (the language server). And both sides need to have the same understanding about those messages and need to deal with them in the same way. Otherwise the advantage of implementing a language server that can be used out of the box with various clients is gone. At the moment the client implementations (as well as existing language servers) vary greatly in those details. It is hard to implement a language server that provides the same awesome user experience across all the various clients.

This might be a problem of the early days of this new architecture because most of the client implementations aren’t mature yet. That might improve in the future. But at the moment you really need to test your language server against each IDE/editor individually to make sure everything works as expected. And sometimes you need to deal with differences in the clients via feature flags or behavior flags in the language server. That is somewhat annoying from time to time.


Q: What would you like to see in the medium term that would take the technology to the next level?

A: I think having a broad set of high-quality client implementations that are all on the same level would be a great step forward.

And maybe a unified mechanism to add those language servers to an existing client would be great. At the moment you have to implement the client-side extension manually and for each client individually. This isn’t a lot of code, but you still have to deal with different extension mechanisms.

And it will be interesting to see how people exchange information along different languages servers or whether they will remain totally isolated from each other. I can see meaningful arguments for both sides.


Q: How do you think Language Servers and the Language Server market will look in 3 years?

A: I expect that all major IDEs and editors will support the language server protocol out-of-the-box. I also expect that most language providers will provide language server implementations for their languages out-of-the-box.


Q: What message do you think is most important here for EclipseCon attendees? 

A: One of the most important messages for attendees at EclipseCon with regards to language servers is: if you want to support a language or a framework, a language server IS THE WAY TO GO. The days of hacking your parser, builder, content-assist, and refactoring directly into Eclipse are over.

Sponsor Testimonial: Jan Köhnlein, TypeFox

EclipseCon Europe connects the Eclipse community in the best possible way. You will hear great talks on a wide range of topics, talk to smart and friendly people, enjoy great food and just have a very good time. ...This year’s EclipseCon gives us a great opportunity to share our knowledge how to integrate Xtext with Sirius. We will also present three new frameworks: Xpect, which makes testing Xtext languages easy, Theia, that allows you to build tools that run both in a browser or as a rich-client, and sprotty, a graphical framework for web-based apps which extends the ideas of the LSP to graphics....

Our Sponsors

For information about becoming a sponsor, please visit the EclipseCon Europe 2017 sponsor prospectus page.

Elite Dual ECE/OSGi CE



Club ECE Sponsor

IoT Theme Day

Project Quality Day

Smart Home Day


EclipseCon Support Other Events

Our Other Events

Eclipse events are hosted all over the world!

  • EclipseCon Europe 2018