Monthly Archives: January 2016

2 posts

Eclipse Mattermost – What’s the state?!

A few weeks ago we started to test Mattermost as a communication channel for Eclipse Foundation projects. So, how is it going?

First of all Cédric Brun wrote a bunch of Java tasks which create Mattermost events based on various other Eclipse systems (like Gerrit, Bugzilla, Twitter, Forum, …) which integrate nicely with the Mattermost channels and allow each project to aggregate all these events in a single location. So you actually can get a notification about a new Forum entry for your Eclipse project in Mattermost now. Cool stuff! Many thanks!

From the usage side we are currently approaching the 100 user mark. At the moment of writing there are 94 registered users, 24 public and 8 private channels. About 150 posts per day and between 10 to 20 active users. You can have a look at the statistics below.

So is it a success? Well I goes into the right direction. Please don’t forget that this is just a test, but on the other hand there are people which are using it on a day by day basis for their Eclipse process. The usage of one big team with many channels (even multiple per project) seem to work fine. Single-sign-on will be a topic, right now Mattermost does have its user management. Also is the setup for projects still a manual process, which could be automated somehow. So there are a few topic left to solve.

But for me it is really amazing to see how quickly a new communication platform was established if all people work together. And it seems that people accept the new system quite well. I really hope we can establish this as a permanent solution.

Mattermost Statistics 2016-01-29

Java 8 magic with method references

When you start learning a new programming language you often encounter snippets of code which you have no idea why they work. The more you learn about that programming language to more you understand and these moments become rare.

Today, after programming many years in Java, I ran into such a situation with Java 8 and was really fascinated about it.

It all started with the problem of having a Stream<T> and wanting to “for-each” iterate over its content. The for-each construct in Java requires to have an array or Iterable<T>. However Stream<T> does only provide an Iterator<T>, which is not the same.

Now there are many solutions (good and bad) out there for this problem. However one solution really fascinated me:

[code language=”java”]
Stream<String> s = …;

for (String v : (Iterable<String>) s::iterator) {


Now wait … Stream<T> does have a method iterator which returns an Iterator<T>. But Iterator<T> cannot be cast to Iterable<T>! And also is “s::iterator” not calling the method, but referencing the method.

Screenshot of Eclipse Quick Fix for Lambda expressions

Pasting this code fragment into the Eclipse IDE helps to understand what actually happens. Pressing Ctrl+1 on a code fragment allows to convert method references to lambda expressions and lambda expressions to anonymous classes. Quite fantastic ;-)

So, lets see how this code fragment get expanded to a lambda expression:

[code language=”java”]
for ( final String v : (Iterable<String>)() -> s.iterator () ) {


And this lambda expression is equivalent to:

[code language=”java”]
for ( final String v : new Iterable<String> () {
public Iterator<String> iterator () {
return s.iterator ();
}} ) {


The last snippet is rather bloated, as inner classes have always been in Java.

The magic which is happening is done by Java 8 new features “method references” and the “functional interfaces”. A functional interface is a java interface which only has one method to implement. “default” methods don’t count. Looking at Iterable<T> this is the case. So an Iterable<T> can be implemented with a lambda expression and or method reference. But for the for-each loop, Java does not “know” what you have mind. This is where the cast comes into play. By casting the method reference to Iterable<T>, Java infers that an Iterable<T> is requires, which can be provided by the method reference to Iterator<T>.

But looking at Iterable<T> there is no @FunctionalInterface present?!

That is right. But @FunctionalInterface is not a requirement for actually being a functional interface. It only tells the compiler to fail if the interface is not. So the downside of this example is, that there is no guarantee that Iterable<T> will always stay a functional interface, since the authors have not committed to that using @FunctionalInterface.

In the end, I am not sure if this is a good solution for my original problem. But is still is a fascinating piece of code and a great idea indeed.