News

Why you and your manager should say yes! to EclipseCon Europe

 

Five good reasons to bring the team to Ludwigsburg

1. Learn from the experts.

EclipseCon Europe is about the technology creators and developers working with you in workshops and telling their technology stories in talks and demos. You will discover ways to work smarter.

2. Innovate with the community.

Breaks, events, hallway conversations, Q&As all lead to new ideas and new paths to explore in solving your coding challenges.

3. Spread the word about your technology.

Everyone is interested in technology at EclipseCon Europe and everyone has the opportunity to share projects, ideas, and problems with one another.

4. Get answers to complex issues.

You can move forward quickly on complex issues when specialists from various areas are on hand. Create a BoF to present your challenge.

5. Extend your network.

With participants from a wide range of disciplines from all over the world, EclipseCon Europe's open atmosphere encourages making new acquaintances and renewing acquaintances with old friends.

 

Here's what people are saying about EclipseCon Europe

 

 

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.

The itemis EclipseCon Team

EclipseCon Europe is and has always been a great place to meet up with the community, to exchange with experts, and talk about trends, innovations, and new ideas. At EclipseCon everyone works together for a common goal: to keep the IDE competitive and to create new potential for growth to benefit everyone.

- Frederic Ebelshäuser, Yatta Solutions

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.

Jan Köhnlein, TypeFox

 

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

Encapsulation

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 org.foo.Bar 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.

Stephan

 

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!"

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.

 

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 (http://eclipsesource.com/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 (http://eclipsesource.com/munich/). He has many years of experience with Eclipse RCP, EMF and EMFForms and is the project lead of EMFStore (http://emfstore.org). Edgar likes to work on various open source projects such as JSONForms (http://jsonforms.io) or Play JSON Schema Validator (https://github.com/eclipsesource/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.

Benoit

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

Project Quality Day 2017

Join us on Wednesday 25th October for the Project Quality Day at Eclipse Con Europe! Over the course of the day, we’ll hear from 7 different speakers about a great balance of topics relating to different aspects of testing. This year, we have talks about testing in Eclipse contexts, good practices for quality in fast-paced delivery contexts, and examples of tooling and methods for functional software testing.

As Program Chair, I’m obviously looking forward to all the talks – and I’m incredibly pleased with the program as a whole. Nevertheless, I always like to pick out a couple of personal highlights that I’m particularly interested in hearing. This time round, our early bird pick is one of the talks that I’m especially looking forward to: Mutate and Test your Tests. For me, it will be the first chance to hear about mutation testing and I hope to learn what it can help teams achieve and how / when / where it can be meaningfully used. I’m a great advocate for ensuring that our automated tests are actually delivering us worthwhile information and mutation testing sounds like an interesting way of checking this.

PQD Logo

My other highlight(s) are the two talks on the continuous aspects of testing and delivery: Tools and Methodology of Continuous Testing and Pipelining Quality. It is critical to get fast and useful feedback about quality in any process – even more so when we start thinking about continuous delivery. I’m interested to hear what techniques, processes and tools the two speakers are using to achieve this.

Of course, I’m excited to hear from the other speakers too! We have talks on RedDeer and on Jubula, tips and tricks for Testing Eclipse Plugins, and we’ll close out the day with a talk called Software is made out of people.

Register

You can register for the full EclipseCon Europe Conference or just the Project Quality Day.

The Project Quality Day (only) ticket lets you participate in all Quality Day talks as well as the main keynote – and the breaks, lunch and party in the evening.

Sponsors

The Project Quality Day is made possible thanks to our sponsors and supporters. This year, we are pleased to have BREDEX GmbH, SQS and Bachmann as Exhibitors. Baloise are joining us as Sponsors, and Testbirds, SauceLabs and Verit are Supporters of the day. Women Testers and ASQF are once again media partners.

Alex

Alexandra Schladebeck

 

Our Sponsors

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

Elite Dual ECE/OSGi CE

Premium

Basic

IoT Theme Day

Project Quality Day

Smart Home Day

Media

EclipseCon Support Other Events

Our Other Events

Eclipse events are hosted all over the world!

  • Eclipsecon Europe 2017