Eclipse Che looks promising, the cheese’s moved around

A very quick look at Eclipse Che shows a promising concept. I thought let’s have a look. When I’m serious about a technology I take the time to read the documentation before diving in. In this case I wanted to follow the typical journey that most folks take, just dive in, never bother with documentation, upon the first hurdle start complaining like a bewitched mad dog with an exaggerated sense of entitlement – ok, minus the last bit of attitude.

I installed Eclipse Che, easy peasy. Then I fired it up. Oops! I can’t connect to it. The first time ever I couldn’t just use an Eclipse release after installing it. It was time to look under the bonnet. So I did. I saw it’s deployed on Docker… What!? Why!? Ahem, ok, move on. I stopped it, also stopped Docker Machine. Then I manually started Docker Machine, readied the environment, then started Che again. This time I tried http://localhost:8080 and I got in. Cool. Everything looks familiar, except it’s all now in one web browser window.

Time to look back and reflect on what I’ve learned here. The fact I couldn’t connect the first time might have to do with RTFM that I didn’t. Anyway, not a big deal, it took me a couple of minutes.

Nothing much to it, just an IDE inside a web browser. It’s the same old thing, in a new cloak. The most obvious/visible differences I spotted can be depicted in a simple diagram, BEFORE and AFTER.


With Eclipse Che,


I’m oversimplifying, but highlighting the most visible changes. It seems that when we get to modernising our software stack, adding Docker and JavaScript are passage-obligé. So, somehow people think that deploying a Java app on Docker is a better architectural choice than only targeting the JVM? In my case, since I’m using a Mac, which runs OSX, hence requires an extra VM (VirtualBox in my case) in order to run Docker containers, I actually end up with a more complicated stack for just an IDE. I don’t know where this is going. Now trying the IDE.



I haven’t gone further than this. The concept of Developer WorkStation Server can be interesting for pair programming. The Server option is perhaps more appealing. I just wonder why this couldn’t be just a Java App and why Docker was actually necessary.


  1. Hi – I am the project lead for Eclipse Che. You wondered why Docker was being used. The simple idea behind Che is that the workspace needs to include all of its dependencies so that if you wanted, a developer could move the workspace around from one location to another and then pick up development where you left off. The runtime in this case is the tools like compilers. So Che workspaces have embedded environments. Our default environment implementation is Docker containers, but you could implement this with MacMini or zOS for instance.

    Unfortunately, Docker requires a VM on Mac and Windows, but this is a temporary issue.

    1. That was a super fast reaction! Thanks for taking the time to clarify. You and team clearly are on he ball.

      I certainly am not underestimating the challenge of reinventing a platform that’s been so successful. The containerisation pattern is definitely promising. I did wonder about potential fragmentation. For example, whether the plugin system would be moving in that direction too. If not, wouldn’t that keep some complexity around? And if it did, then the granularity (as opposed to OSGI or Project Jigsaw) could also come to question.

      This is such an undertaking that I also want to take the time to applaud the achievement so far.

  2. Che has its own type of plugin system that is similar to that of the Eclipse RCP, but notedly different. In Che, the workspaces are distributed, so there are three types of extensions: those that run within the IDE, those that run within the Che server, and those that run within the workspace (which has its own runtime). Workspace extensions are essentially RESTful APIs that are deployed that can do magical things in the workspace & projects. IDE extensions modify the browser behavior, and can connect back to the extensions that are RESTfully exposed from within the workspace.

    Eclipse extensions can move over – but it’s easiest to move the server and data logic extensions into the workspace. Eclipse GUI extensions have to be rewritten from SWT into GWT, which is what we used to generate the JavaScript IDE.

    1. Interesting. I need to dive into the details. As the IDE becomes distributed, it also inherits the challenges inherent with that architecture. I’m curious how this is being addressed, so I’ve got to look at the source code. Rewriting the UI is going to give plugin developers quite a bit migration work to do. Most of the IDE reinvention endeavours I am aware of have really just focused on replicating the Eclipse model around a text editor, not much reinvention in my view. The ones that took the playground approach, like Xcode, have offered more. Che’s a hybrid WorkStation/Server model is innovative from the deployment perspective, but I think it could be ambitious beyond Docker though. The IDE of 2016 could benefit by being a streaming hub for a network of components, would you see Che going in that direction or would you rather it only focuses on the microservice idea and not much else?

  3. Pingback: Eclipse Che | Blog

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.