New RFPs under discussion at OSGi

by David Bosschaert ( at June 30, 2015 09:03 AM

While the Enterprise R6 release is currently in the process of being released, new topics are being worked on in the OSGi Alliance. These topics are currently discussed in RFP documents, which hold the requirements. The plan is to finalise these RFPs by the end of the summer, then we can start on the RFCs, the technical design that will ultimately be the basis for future spec texts. Below you

by David Bosschaert ( at June 30, 2015 09:03 AM

Eclipse Mars New and Noteworthy: Java 9 Beta

by waynebeaton at June 30, 2015 12:27 AM

Java™ 9 support has not yet landed in our standard download packages. But you can add an early access preview to your existing Eclipse Mars install.

The Eclipse Java™ 9 Support (BETA) contains the following:

  • ability to add JRE and JDK 9 as installed JRE;
  • support for JavaSE-1.9 execution environment; and
  • ability to create Java and Plug-in projects that use a JRE or JDK 9.

At the moment Eclipse must be run with Java™ 9 if you want to use Java™ 9 in your workspace. You can download from

This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP.

Install the Java 9 Beta via the Eclipse Marketplace:

Drag to your running Eclipse workspace to install Eclipse Java™ 9 Support (BETA) for Mars

by waynebeaton at June 30, 2015 12:27 AM

Android Developer Tools is dead….long live Andmore.

by kingargyle at June 29, 2015 01:03 PM

It is now official.   A posting from the official Android Developer’s blog has confirmed what many of us already knew, that the days of the original Android Developer Tools based on Eclipse was numbered.   Honestly, I think this is not  a bad thing.  It does free up the resources that Google has to fully concentrate on the Android Studio tooling, and continue to improve and advance their chosen strategy going forward.

However, all is not lost, as the Andmore project is here to continue to provide Android tooling for the Eclipse community.  However, progress right now is pretty slow, and that is because my own time has been limited.   With this said, we do have integrated support with Maven and the android-maven-plugin through the m2e-android project’s support.   The Buildship project can import an existing Android gradle project, and even run some tests, but it still has problems in setting up the project natures and make things work with Andmore.   There is a feature request opened to have some sort of project configuration extension so that Andmore can help configure such projects to better work with the tooling.

The state of Android development with Andmore and how well it keeps up with the yearly and quarterly updates coming from the Android Open Source Platform is going to greatly depend on contributions from the community.   We need your help, as one person definitely can not maintain the project alone.    So please do take a look at the bug/feature backlog, feel free to fork the project on GitHub, roll up your sleeves and get a bit dirty, submit pull requests and file new bugs.   Andmore is going to be what the community makes it.   We wished for years that ADT had been open more to contributions from the community, now is the time for us to follow through on that wish.

by kingargyle at June 29, 2015 01:03 PM

EMF Forms and EMF Client Platform 1.6.0 released!

by Maximilian Koegel and Jonas Helming at June 29, 2015 09:57 AM

We are happy to announce that together with Mars we have released  EMF Forms and EMF Client Platform 1.6.0! We want to thank all committers and all contributors for their work as well as the active ecosystem of users and adopters for the feedback and support!

EMF Forms is a framework focused on the creation of form-based UIs. EMF Client Platform is designed to support the development of applications based on an EMF data model. If you are not yet familiar with EMF Forms, please refer to this tutorial for a introduction of EMF Forms.

Both frameworks are part of Eclipse Modeling Tools Mars (version 1.6.0), however, we have already released a service release (1.6.1) fixing a Bug with the double control, so if you use EMF Forms or want to get started, we recommend to update to 1.6.1, available from our download page.:

Please have a look at our migration guide, e.g. if you have used the service provider interface in a previous version.

Since February 2015 and with the 1.6.x release, we have closed 111 Feature Requests and Bug Reports.

It is amazing to see, that the number of active contributors is still growing and how much effort was spent so far. OpenHub shows some impressive numbers:

We will describe the most notable new features in a small blog post series starting next week. We hope you enjoy the new release and provide us with feedback!




Leave a Comment. Tagged with eclipse, emf, emfforms, mars, eclipse, emf, emfforms, mars

by Maximilian Koegel and Jonas Helming at June 29, 2015 09:57 AM

Never ending fight on IDE related meta-files included in code source found an alternative: Eclipse Smart Importer rocks!

by aurelien.pupier at June 29, 2015 09:04 AM

Should the meta files related to an IDE be committed?

There is a never-ending fight over this question. I'm sure that most of the advanced Eclipse users will answer yes but unfortunately in a team you might get some Eclipse haters (and sometimes even IDE haters, who I also call last-century coders). This second and third categories will answer no.

When the answer is no, setting up your preferred IDE might become cumbersome. There is missing meta-information, for instance contained in .project files, which can lead a developer to import projects with the wrong nature into the IDE. Hopefully, here comes the Smart Importer! It enables Eclipse to guess the most appropriate nature when importing a project.

For instance, with the Bonita BPM engine project, you just have to specify the git clone repository that you want to import and all the correct natures for every projects are detected automagically.

screenshot list of imported project with nature

The project is not integrated in the Eclipse Mars Release train but is available from a dedicated update sites. It will enable you to test and contribute - ideas and code - for Neon, the next version.

by aurelien.pupier at June 29, 2015 09:04 AM

Eclipse 3x PDE/RCP Public Classroom in Bangalore

by Its_Me_Malai ( at June 27, 2015 12:34 PM

Too few developers for onsite courses? Try our public courses @ ANCIT on Eclipse based Technologies.

We at ANCIT are planning to organise a list of Eclipse based Public Training Courses. As part of that we are planning to organise a Public Classroom for Eclipse PDE & RCP. Course Content of the training is attached to the email.

Workshop Title : Eclipse 3x PDE/RCP - 2 Day Workshop
Trainer Profile : Annamalai Chockalingam
[Linked In Profile :]
Date of Workshop : 9th & 10th July 2015
Time of Workshop : 10.00am to 5.00pm
Venue : ANCIT Consulting Office [Apponix Technologies], Rajaji Nagar, Bangalore
Location on Google Map :

Cost of the Workshop : Rs.7500/participant + ST.

If you have more than 3 nominations you will get a discount of 10%.
If you register before 1st July 2015 you will get 20% discount on the above mentioned price.
For more information write to

by Its_Me_Malai ( at June 27, 2015 12:34 PM

Mars on Linux

by Andrey Loskutov at June 27, 2015 10:45 AM

Eclipse is landed on Mars, and now Platform UI team (as well as SWT and EGit teams) start to receive new bug reports from our end users. That's OK, business as usual after each release. Not OK is that we could get much less bug reports, especially from our Linux users. Why?

Eclipse Mars on Linux uses first time GTK3 toolkit by default (all versions before 4.5 were on GTK2), and that is the major driver for new bugs from Linux users. I'm writing this on Linux, and know what I'm talking about. Eclipse SWT team crafted the SWT GTK3 port with tremendous effort, but unfortunately GTK3 exists an a bunch of (partly incompatible) versions with different API behavior, and developing a widget toolkit on top of it is a pain, not a pleasure (IMHO).

The major issue with GTK3 is that if SWT is broken, it affects each and every Eclipse UI plugin, at most unexpected places! Anyway, now this is default toolkit and we must know how to work with it (or workaround it).

So if you are on Linux and see a new UI regression on Eclipse Mars, please be aware that if this a GTK3 issue, there is easy way to fix it - switch to back to the GTK2 version (which is still supported by Eclipse 4.5). But before switching the toolkit - try to help Eclipse and report the issue you observe, so that the next release has a bug fix for it!

1. Search for similar bugs

Before reporting, please search for bugs! All properly reported GTK related bugs contain [GTK], [GTK2] or [GTK3] keywords in the summary. If your bug is already reported, do not report another one, but just add extra details you want to mention.

2. Check if the GTK3 to blame? 

Try to check if your issue is GTK3 related: switch to GTK2. Either export SWT_GTK3=0 in the shell before starting Eclipse or add this two lines to your eclipse.ini:


which has exact the same effect. If this helps, we will know that the problem is most likely GTK3 related.

3. Check if the GTK+ theme to blame?

Not always the GTK itself is a problem, but the current GTK theme (widget style). 

GTK applications can be "styled" - they can look and feel differently on same GTK version due the currently selected "style" or "theme". There are various GTK themes available, and some are better for use with Eclipse as others.

Beware of oxygen-gtk theme on GTK3! This pair is known to be extremely buggy!

Unfortunately, many distributions set the default KDE GTK theme to oxygen-gtk. It worked well in the past with the old GTK2, but on GTK3 this can be a source of multiple issues. If you are using KDE desktop, the first thing you should do is to check if you are using oxygen-gtk. If so, switch to another theme (Adwaita or Clearlooks-Phenix). Later one is my favorite, and I even forked it to make it working on GTK2 in the way I like it :-).

Please note, that after switching GTK theme it is highly recommended to restart Eclipse to avoid unexpected side effects of half-zombied theme artifacts. If the problem do not disappear after restart we know it is independent from the theme.

4. Report the bug

If your bug is not on the list, prepare the information we need to triage it properly! First and foremost we want know exact Eclipse and GTK version used. Eclipse version is shown in the "About" dialog, GTK version is not that easy to retrieve. If you are on Eclipse 4.5, you can see GTK version used by SWT in the "Help -> About -> Installation Details -> Configuration" dialog - search for the "org.eclipse.swt.internal.gtk.version" property, it looks like:


But of course on Linux we want use command line tools :-) 

For the rpm - based distributions (Fedora, RHEL, CentOS) it's easy: just call 

rpm -q gtk2; rpm -q gtk3

and you will see something like:


For the debian based distributions (Ubuntu & Co) I know about two commands:

apt list | grep installed | grep libgtk2.; apt list | grep installed | grep libgtk-3.


dpkg -l | grep libgtk2.; dpkg -l | grep libgtk-3.

but both of them aren't that concise as rpm and print lot of unneeded information. Please also note inconsistent naming schema: libgtk2 but libgtk-3. Nice and makes lot of sense, isn't?

Now we know the installed GTK version we can go and submit bug report against Platform/SWT.

NB: please also add your operating system details, desktop environment (Unity/Gnome/KDE) and GTK+ theme used.


From my personal point of view SWT GTK3 port is still not on par with GTK2 and ideally shouldn't be made default for 4.5 - it wastes lot of space and introduces multiple regressions. But the decision was made and only way to fix it now is to contribute to Eclipse.

by Andrey Loskutov at June 27, 2015 10:45 AM

Google Ends Support for Android Eclipse Tools

by Abel Avram at June 27, 2015 08:15 AM

Google has announced the end of all Eclipse-based tooling for Android development by the end of the year.

By Abel Avram

by Abel Avram at June 27, 2015 08:15 AM

Presentation: Innovating in IoT Using Eclipse - Experience and Recommendations

by Max Domeika at June 27, 2015 02:30 AM

Max Domeika discusses the relative strengths and weaknesses of the current Eclipse IDE for IoT development, and tooling support for Sensor emulation, Power Analysis, and Cloud.

By Max Domeika

by Max Domeika at June 27, 2015 02:30 AM

Eclipse Code of Conduct

by Chris Aniszczyk at June 26, 2015 02:01 PM

At the recent Eclipse Foundation board meeting this week in Toulouse as part of EclipseCon France, the committer representatives helped move forward a code of conduct for the Eclipse community. As for a bit of background, the request for this initially came from bugzilla and also the LocationTech working group which was looking for a code of conduct for its community. The board opted for a simple code of conduct based on the Contributor Convenant, see this email from Mike Milinkovich:

I am very pleased to announce that the Eclipse Foundation Board of Directors approved a Community Code of Conduct[1] at their meeting earlier this week at EclipseCon France. This brings the Eclipse community in line with the best practices for open source communities around the world.

Our community already has a strong culture of respect and professionalism. Neither I nor the Board expect anyone’s behaviour to change as a result of this. This is simply codifying the high expectations we already meet in terms of professionalism, respect, and simply courtesy.

I agree with Mike and couldn’t have said it better, we have a great community and this simply codifies our high expectations.

by Chris Aniszczyk at June 26, 2015 02:01 PM

Eclipse Newsletter - Landed on Mars

June 26, 2015 02:00 PM

Read up on new and exciting things for the Mars release, the Oomph Insaller, Docker tooling, and Java 9 support.

June 26, 2015 02:00 PM

Sirius 3.0 “Harder, Better, Faster, Stronger”

by Melanie Bats at June 26, 2015 01:45 PM

Today is a great day: with the announcement of Eclipse Mars, many great projects are released, and Sirius 3.0 is part of this release train.

When I have a look at the status of the Sirius project today, one soundtrack immediately comes to mind: Harder, Better, Faster, Stronger

Work on it harder

One first fact, looking at the project’s statistics, is that the Sirius team worked hard on this release to deliver some new cool features and improve the existing ones:

Version Date Total Closed Feature Requests
1.0.0(Luna) June 14 100 2
1.0.1 Aug 14 20 -
2.0.0 Oct 14 113 27
2.0.1 Nov 14 2 -
2.0.2 Dec 14 15 -
2.0.3 Jan 15 16 -
2.0.4 Feb 15 8 -
2.0.5 Apr 15 8 -
3.0.0(Mars) Jun 15 213 35
426 64

This release is the first one on which the team worked at full speed, so for the future you can expect the same amount of work done.

Make it better

Their goal was to provide a better tooling for the end users by improving the diagram user experience. This work started with Sirius 2.0 and some of the following features are there since then.

Resizing a container

Positioning elements

Snap To Shape enabled by default for new diagrams
Snap To Grid now used when an element is created
Resize no longer change ports or children’s location
Actions to distribute shapes
Action to reset the diagram origin

Edges layouting

Beautiful editor

The editor was also improved to provide:

  • Anchor on borders: Now the edges are linked closely to the images, you just need to define images with an transparent background.

  • Underlined and strike through style for labels

  • Compartments: There are two new values available for a container mapping Vertical Stack and Horizontal Stack. This means that the defined container will show its children as a vertical/horizontal stack of compartments. Thanks to this new feature, you are able to define a dynamic number of compartments.

Compartments are just a specific setting of a full blown container mapping making it easy to create any artificial level of compartments independently from the metamodel structure.

Have a look at the Sirius compartments documentation for more details.

Do it faster

The goal was to get a runtime which react well with 1 million elements. Why one million? Because it is a beautiful number… but also because we noted that the modeling projects are fastly growing to 200K elements and 500K in case of in-depth analysis. Usually when you are over 500K, it means it’s time to re-think the process as you will likely need to decouple models with a clear and defined life-cycle. That is why we aim Sirius to work with 1 millions, then it will be really smoothly with the more usual 500K use case.

Sirius performances are in constant improvements, and this version comes with significant enhancements on heap consumption and time execution.

Time (sec) Heap (Mb) Time Variation Heap Variation
Open Huge Project 80 276 -31,00% -20,00%
Open Big Class Diagram 11 24 -54,00% +20,00%
Refresh Big Class Diagram 0,731 0 -18,00% 0,00%
Save After Diagram Change 26 0 -23,00% 0,00%
Close Diagram 0,1 -6 0,00% 0,00%
Close Project 55 294 0,00% 0,00%

On big operations, the model footprint is reduced by 20%. To do so, major work was done on:

  • using MinimalEObject
  • Transforming Colors from full-blown EObject into Immutable DataType
  • Detecting and fixing leaks
  • Reducing the usage of adapters.

Then the save strategy was reviewed as well as the diagram refresh and the image cache.

Another big task was to reduce the latency. First, on the UI runtime:

  • model element selection dialogs must be used for big models.
  • the right-click in the explorer was optimized.
  • and the property views made with EEF are better integrated.

And then to reduce the latency on tables, SWT refreshes are now done in batch and the team also improved the table model refresh.

Performance is also your matter! It really depends on your .odesign specification. You should focus on queries which will have a complexity depending on the size of the model: measure, improve and repeat! Think about using the Sirius embedded profiler:

Make us stronger

Definition tooling

The Sirius team also worked to polish the specifier editor. They improved many different small things which will really enhance the specifier work as it will guarantee a better odesign validation and an efficient navigation.

  • Workspace class loading is BACK: With Sirius 3 you can define Java services and then try them directly in your current development environment, you do not need anymore to launch another runtime just to test your services!
  • Image path validation and selection wizard: Now, there is a selection wizard to choose an image and then validation exists on image path. You will never get a not found image.

  • Quick Outline: An awesome improvement: it allows to quickly find any element in a odesign! Just call Ctrl+O and a wizard shows up to help you searching through the viewpoint specification.

  • Prioritized sub menus: Another great thing, the menus have been reordered and now the most used elements are available at the top.

Query languages

If you are used to work with Sirius, you already know that writing queries can turn to a severe headache due to the lack of detailed type information.

Actually, there are in Sirius 5 different interpreters to write your queries:

  • Feature: feature:
  • Service: service:
  • Var: var:
  • MTL: [/]
  • and the legacy one: <%%>

The .odesign specification is as flexible as possible, tools can be reused among mappings, mappings can be reused by other mappings, but that means one variable definition can actually have several types depending on the .odesign structure. If we have a look at the following query: What is the type of var:source?

Regarding our example, source can be a Man or a Woman but it could be Woman or Package. Then the source variable can be of multiple types and those types may have no common ancestor other than EObject.

Type analysis within the action language requires a stronger type information from interpreters. It is implemented in feature:, var:. We made some improvements in [/] and there is simply no support in legacy <%%> and ocl:. What we want is a good reference support.

The Acceleo Query Language also known as AQL comes to our rescue. The implementation of AQL is specifically tailored for the Sirius use case. We have many variables for a given expression and null values are common. The usage is really interactive and so the context is constantly changing. I can hear you “Hoooo no, not yet another language…”. Don’t be afraid! You know OCL ? Then you know AQL.

The most important things to know is that:

  • You will find the classic operations like filter, collect,
  • And some convenient ones as: eInverse(), eResource()
  • There is no implicit variable:
[name/] is invalid becomes 
[self.eContents()->select(name.startsWith('A'))/] is invalid and becomes self.eContents()->select(i |'A') 
self.referenceWithNoValue.someOtherAttribute has no evaluation error, returns "Nothing" 

AQL is not strictly compatible with MTL but a subset of MTL works for both.

We did some benchmarks with the different queries engines available in Sirius:

There is no good reason not to use it considering the overhead vs the flexibility and strong validation. In Sirius 3.0, it is delivered as an experimental feature but it will be available officially for the next 3.1 release.

So consider using it from now on if you are still using Acceleo 2 expressions (<%%>). Otherwise, if you are using MTL ([/]), you can prepare your queries to make the migration easier.

To get more details about what is arriving in Sirius 3.0, have a look at the release notes and to the slides or the video of Cédric Brun EclipseCon France talk.

Even if Sirius 3.0 is major version, don’t be afraid! The models are automatically migrated by Sirius, the API changes are well documented in the release notes and some projects such as EcoreTools or UML Designer could upgrade just by changing the version range in the plugin, no impact on the code.

The 3.1 version is planned for November and the next topics of work will be: more flexibility for diagram UX, compartments feature complete, bullet-proof AQL and again more performance and scalability improvements… and your priority is our priority for the future. So don’t be shy, report what you need and want on the bugzilla and remember you can sponsor us to get it done quickly!

Let’s have Daft Punk conclude this post:

More than ever
Hour after
Our work is
Never over

by Melanie Bats at June 26, 2015 01:45 PM

Eclipse for Docker has arrived on Mars

by maxandersen at June 26, 2015 12:07 PM

Eclipse Mars has arrived, and with it comes a brand new Docker tooling for it.

This blog is a cross-post from Eclipse Newsletter: Landed On MARS where you can read about more things included in recent released Eclipse Mars.


We wanted to have a way to easily start/stop and deploy Docker containers directly from Eclipse.

We wanted something that would run on all three major platforms: Windows, Linux and OS X.

We wanted something that would work together with existing Docker command line tools, but also utilized provide better overview and easier/faster access to common operations, from a visual perspective.

We wanted it to be released with Eclipse Mars.

…​and that is what we got now.

This article runs through how to get it installed, the main features and what the future plans are.

Where do I get it ?

With Eclipse Mars released, you can get it from the Eclipse Mars updatesite, the feature is named Docker Tooling.

If you want to try the latest greatest builds you can use Linux Tools project nightly builds update site at

To use the plugins, it is assumed that Docker is already installed. You can see Docker’s Installation guide on how to do this on various platforms.

Views and Perspectives

Once you have installed the Docker tooling, you will get access to three new views:

Docker Explorer

a tree view listing all connected Docker instances, with image and containers.

Docker Containers

a table view listing containers for selected Docker connection

Docker Images

a table view listing images available in the selected Docker connection

The easiest way to get to see these are by opening the Docker Tooling perspective.

Docker Tooling Perspective

In the screen above, the Docker tooling are connected to a locally running Docker deamon named boot2docker.


To configure this you click the Add Connection…​ button in the Docker Explorer view.

This will start a wizard that will try to detect your default Docker connection setup, dependent on your operating system.

Add Connection Wizard

In Linux it will use standard unix sockets and if on Windows or OSX, it will look for the following environment variables: DOCKER_HOST, DOCKER_TLS_VERIFY and DOCKER_CERT_PATH.

If neither of these are detectable, you can click Use custom connection settings and provide the connection info.

When you have the connection working you can get started using Docker images.

Pull individual images

To pull an image, you use the Pull Image in the Docker Image view.

Pull Image

Here, I’m simply pulling the jboss/wildfly image, a image amongst many available at


To run the image, the easiest way is to right-click on the image in the Docker Explorer.

Run Image from Docker Explorer

Here, I’ve initially filtered the list to just show images matching wildfly and then using right-click to choose the Run Image…​ action.

Docker Run

From within this dialog you can also search in Docker Hub for other images by clicking Search…​.

Docker search

In this example, I’m only going to focus on running using the defaults, but in the Run Image wizard you can also configure ports, links, volumes, environment variables etc.

By default, we enable interactive and tty mode to allow you to interact with the docker container in the console (i.e. if the image asks for input).

When you click Finish, the container will start and show output in a Console and the Docker Containers view will show which ports are used.


In here, the port at 8080 (the web server) is mapped to 32768 on the docker daemon.

To show this I just need to goto http://dockerhost:32768 to access it. dockerhost is the IP of the docker daemon.



If you have a Dockerfile you can build it via the hammer icon on the Image view. This will start the Build wizard.

docker build

Once built, the image will show up and be possible to use for running.


You can view properties for all the various parts: connection, image and container, including getting a tree view of what docker inspect would show.

docker properties


For Eclipse Mars we added all of the above base features and you can use it in your day-to-day work with Docker.

For Eclipse Mars SR1, we will work on getting some of the rough edges fixed, like &aposRun&apos and &aposBuild&apos should be available in the context menu and not only in the views menu.

Work also started in Eclipse CDT to support using Docker images to build binaries for an OS other than the one you are running on. The vision for this would allow running on Windows or Mac, but target native deployment on multiple various Linux architectures.

Furthermore in JBoss Tools we are working on better integrating Docker with Eclipse server adapters, to ease deployment of your web applications to a Docker container. You can see how server deployment works with the current Docker tooling by leveraging docker volumes and remote deployment support.

If you have suggestions or find bugs, please open these in the Linux Tools project under Docker.

Have fun!

Max Rydahl Andersen

by maxandersen at June 26, 2015 12:07 PM

RCPTT 2.0.0 (Mars) Released

June 26, 2015 12:00 AM

We are on Mars now!

On June, 24, we've released Mars-based version of RCP Testing Tool as participants of Simultaneous Mars Release.
So RCPTT IDE has migrated from Indigo to Mars to allow users to install it into their developer Eclipse installations.
The review information is available here and the latest version can be downloaded from Downloads page.

You can also install RCPTT as an eclipse plugin from an Update Site or from Eclipse Marketplace.

Test Runner is now free and Open Source.

This is the first release of Open Source RCPTT Runner.

Now RCPTT project consists of two tools providing the whole process of automated regression testing of Eclipse-based applications:

RCPTT Test Runner tests Eclipse-based applications by executing RCPTT tests unattended, on a regular basis.
It provides a command line interface and a Maven plugin and establishes seamless integration of your GUI tests with your favourite toolchain.

Runner is required to manage test bases greater than a dozen of tests for projects that care for development speed.

  • Completely automated testing
  • Command line interface
  • Maven plugin
  • Works with Jenkins, Hudson, Bamboo, etc.
  • Human readable HTML report
  • JUnit or custom reports
  • Every commit can be verified by functional tests before reaching development branch
  • Handles application hangups, logs errors, stores every test step and its result

RCPTT becoming mature

We are happy to celebrate RCPTT project graduation from incubation to mature!
P.S.: Will miss the egg. It was cute, though.

June 26, 2015 12:00 AM

OpenChrom 1.0.0 “Aston” Preview

by eselmeister at June 25, 2015 01:14 PM

I proudly announce the preview release of OpenChrom 1.0.0 “Aston”.
Some new data converters and a lot of improvements have been added. Stay tuned.

OpenChrom 1.0.0 Preview

by eselmeister at June 25, 2015 01:14 PM

RAP 3.0 Boosts Performance

by Ralf Sternberg at June 25, 2015 11:29 AM

This week, the third major version of RAP, the Eclipse Remote Application Platform, has been released. As a major release, RAP 3.0 cleaned up deprecated API, allowing us to change and to optimize internals. I’m happy to report that we achieved a significant performance boost compared to 2.3. Before I go into details, let’s look at some results.

Performance Tests

To evaluate the performance of RAP 3.0, we created a new load test setup. We deployed a test application with more than 300 widgets on an average cloud server (4 CPUs @2.80GHz and 8GB of memory). On another machine, we ramped up 1000 parallel user sessions, each issuing requests at a rate of one per second. The requests themselves are small, containing an event and some updated properties. Here’s the results of a test run with RAP 2.3.2:

RAP 2.3

Shortly before reaching 1000 requests per second the system started to degrade in response times, but stabilized at a level of ~60 ms. The server CPU utilization during this time was ~90%.

Running the exact same scenario with RAP 3.0, we saw an average server load of ~65% and the response times have dropped significantly:

RAP 3.0

With an average response time below 10 ms and 99% of all requests finishing in less than 100 ms, this is a result we are very happy with.

Response Times

Test Setup

We used Gatling, a powerful load test tool that creates nice and meaningful reports. I’ve aligned the scales of both graphs to make them easier to compare. The test application and test scenarios are all public, allowing you to reproduce and to adapt the tests to your needs.

The application ran on the latest Oracle Java 8 VM using the G1 garbage collector (-server -XX:+UseG1GC).

Background: Change Detection

Various changes contributed to the performance boost in RAP 3.0. For example, the synchronization in the RWT servlet has been reworked. Initial GET requests don’t create a separate UISession anymore. However, the biggest performance gain was achieved by a number of improvements to the change detection. This mechanism preserves the current UI state before processing a request and then compares it with the state afterwards in order to detect and render changes.

Due to the remote processing model of RAP, clients can send requests to the server at a high rate, for example, when typing in a text field with a server-side listener for validation or data binding. Many of these requests have only little effect on the UI. However, since the change detection has the same amount of work to do for every request, it contributes significantly to the server load in these cases.

To speed up this process, most standard Control properties such as bounds or font, are now preserved in dedicated fields in a new, optimized data structure instead of HashMap entries. For example, information about all attached listeners are now kept as a bitmask in a single long value. We also reduced the number of short living objects created during the change detection in order to reduce GC load.

During this work, some more ideas came up and I’m looking forward to further improving the performance of RAP. Big thanks go out to the nice guys at MIC, who contributed their insights and sponsored the performance work in RAP 3.0.


Leave a Comment. Tagged with eclipse, mars, new and noteworthy, performance, rap, eclipse, mars, new and noteworthy, performance, rap

by Ralf Sternberg at June 25, 2015 11:29 AM

Announcing Handly 0.3 Release

by Vladimir Piskarev at June 25, 2015 06:00 AM

It is with great pleasure that I announce the on-time availability of the Handly 0.3 release, symbolically coinciding with Eclipse Mars. This release includes major new features, such as an outline framework, integration with text editors (in addition to preexisting integration with Xtext editor), a real-world exemplary implementation (a simplified Java model), and a number of API enhacements. This release is primarily focused on bringing more value to early adopters while further evaluating the Handly core framework.


Handly is a relatively new project at Eclipse started with an initial contribution from 1C. In brief, it can be described as a framework for handle-based models — with an emphasis on code models that render Eclipse workspace from a programming language angle.

Because the rest of the IDE usually depends on the code model, the quality of the design and implementation of that model is of the utmost importance. Traditionally, such models were built either entirely from scratch or by forking and modifying preexisting models. The traditional process required much effort, was tedious and error-prone. The resulting models were effectively silos with a completely isolated API, which prevented a possibility of developing reusable IDE components, although the models did seem to have certain traits in common.

The Handly project begs to differ with the traditional approach. It provides a set of flexible building blocks that help developers create handle-based models similar in design principles to the JDT Java model. The framework imposes almost no restrictions on the shape of the models or on the languages modeled. The uniform API makes it possible to develop generic IDE components dealing with such models — some common UI components are already provided by Handly. The intent is to come up with a really nice design in this problem area through an open and transparent development process primarily driven by community feedback. For more information, please visit the project’s website.

Despite the “incubating technology” status of Handly, there already are three known major adopters (in chronological order): 1C:Enterprise Development Tools, erlide (in yet-to-be-released version 0.30), and Codasip Studio — two commercial products and an esteemed open-source IDE. We are very grateful for their vote of confidence to the project, active participation and valuable feedback. With this release, we hope to encourage further adoption and receive broader feedback.

Some design discussions with early adopters are already taking place on the project’s forum, but also (as it stands, chiefly) on the handly-dev mailing list, with potentially even more interesting discussions soon to follow.

So if you are interested in this project and would like to have a say in it, I encourage you to engage as early as possible by playing around with this release and giving feedback.

Thank you!

by Vladimir Piskarev at June 25, 2015 06:00 AM

ECF 3.10/Mars Released

by Scott Lewis ( at June 24, 2015 06:28 PM

ECF 3.10 has been released as part of Mars.   Some highlights:

Remote Services Tooling - A new Remote Services perspective with views to help design, test, discover, and debug Remote Services

OSGi R6 - Full support for OSGi R6 Remote Services/Remote Service Admin specifications.   Full spec compliance via the OSGi compatibility test suite

New Providers - Support added for websockets and MQTT-based distribution providers, and etcd-based discovery

Apache Karaf - ECF Remote Services can now be easily installed into Apache Karaf

New Tutorials, Examples, and Documentation

More on the New and Noteworthy.  Download here or via repository included in Eclipse Mars.

by Scott Lewis ( at June 24, 2015 06:28 PM

GEF4 - Mission to Mars Accomplished!

by Alexander Nyßen ( at June 24, 2015 03:32 PM

It's finally done. With today's Mars release we are able to celebrate the first release of the new GEF4 components, on which we have been intensively working for the last five years. A good opportunity for a small retrospective about our "Mission to Mars" and for some sightseeing "at the landing zone".

Countdown and Liftoff! - The Story behind GEF4

The renewal of the GEF API had already been a vision back in 2010, when development of Zest 2.x was started with the goal to revise the Zest 1.x API, which had been kept backwards compatible since 2007. Draw2d and JFace were still unquestioned as underlying rendering technologies, but several refactorings and additions were incorporated (e.g. some new layout algorithms), all in a separate repository and thus in parallel to the maintenance of Zest 1.x. Two completely new features were added in this context as well: support for rendering of tag clouds (Cloudio) as well as Graphviz DOT-support in terms of an Xtext-based editor and a Zest-based viewer (Dot4Zest).

Inspired by how Fabian Steeg, Zoltán Ujhelyi, and Stephan Schwiebert were bringing Zest 2.x forward, I initiated a comparable renewal of Draw2d and GEF (MVC) 3.x, whose API had been kept stable since 2004, in early 2011. As the GEF project team strictly separated between Draw2d/GEF (MVC) and Zest component responsibility at that time, Matthias Wienand and I started with developing a new double-based geometry API pretty much in parallel to the Zest 2.x efforts. Nevertheless, as we finalized the geometry API in 2012, it soon became clear that the next generation GEF API had to be developed in a unified effort. In accordance to the usage of "e4" to depict the 4th generation of the Eclipse platform, we chose the term "GEF4" to refer to that unified effort.

The major goal we identified for this unified approach was to have a self-contained GEF4 with no dependencies on Draw2d, GEF (MVC), or Zest, which could thus be developed in parallel to maintaining the old production components, not affecting any of our adopters directly. One of the first steps we performed conjointly in terms of GEF4 was the migration of the Zest 2.x codebase to the GEF4 namespace, the unification of the related Git repositories and Hudson build jobs, and the adoption of the just finalized GEF4 Geometry component by the migrated Zest 2.x code base.

Having finalized this initial Zest 2.x migration, we now initiated work on a replacement API for Draw2d and GEF (MVC) 3.x, using JavaFX instead of SWT as underlying rendering technology. This lead to two new GEF4 components: GEF4 FX and GEF4 MVC. To already decouple as much of the migrated Zest 2.x code base from Draw2d 3.x as possible, we extracted all newly introduced features, namely Cloudio and Dot4Zest, as well as all rendering-independent parts into new GEF4 components, namely GEF4 Cloudio, GEF4 DOT (the Zest-based DOT-viewer was not extracted at that time, because of dependencies to Zest), GEF4 Graph, and GEF4 Layout.

Mission to Mars: Accomplished!

The major goal for the Mars release timeframe - our Mission to Mars - was to finalize GEF4 FX and GEF4 MVC, so that a comparable functionality to that of Draw2d and GEF (MVC) is offered, and to completely rewrite the initially migrated Zest 2.x code base into a GEF4 Zest component that is internally based on GEF4 MVC, GEF4 Graph, and GEF4 Layout, and which uses JavaFX and GEF4 FX for rendering purposes. In other terms, we wanted to achieve that GEF4 is fully self-contained and provides at least the functionality offered by Draw2d, GEF (MVC), and Zest.

And while all GEF4 components are still provided with provisional API, and a little functional gap still remains compared to the current production components (on the other hand several new features are provided in exchange), a fully self-contained GEF4 has been initially released today as part of the GEF 3.10.0 (Mars) release. Mission accomplished!

Sightseeing Mars - What does the first release provide?

The spectrum of what is provided with Mars reaches from libraries that may also be used apart from graphical applications (GEF4 Common, GEF4 Geometry) via dedicated graphical application development frameworks (GEF4 FX, GEF4 MVC, GEF4 Graph, GEF4 Layout, GEF4 Zest) to graphical end-user tools (GEF4 DOT, GEF4 Cloudio) that as well include framework parts.

All components (features) are broken down into one or more modules (plug-ins), to clearly separate parts that are rendering-toolkit (i.e. JavaFX) dependent from independent ones, as well as parts that rely on SWT, JFace, or the Eclipse Workbench UI from others. We consistently use the suffix ".FX" to indicate that a module depends on JavaFX technology, and ".UI" to indicate that it depends on SWT, JFace, or the Eclipse Workbench UI. The following are provided with Mars (modules are given in brackets, where appropriate):


GEF4 Common provides core abstractions that can potentially be used by all other GEF4 components and other potential clients even outside the scope of graphical applications. This includes enhanced IAdaptable-pattern that properly supports parameterized types, allows to register and retrieve adapters by roles, and supports Guice-based dependency injection. GEF4 Common also provides utility classes to support working with String-based properties, observable collections, and more.

Geometry (Geometry, Geometry.Convert.SWT, Geometry.Convert.FX)

GEF4 Geometry provides different abstractions (euclidean, projective, planar) to perform geometric calculations in two-dimensional space. All calculations are performed with double-based precision, where inaccuracies are compensated by imprecise comparisons. Besides the "traditional" abstractions that can usually be found in the context of planar geometries, there is also direct support for Beziér curves of arbitrary degree, poly-Beziérs, and curved polygons. Furthermore conversion operations are provided to convert between planar geometries and respective representations in SWT and JavaFX.


Being the intended replacement for Draw2d 3.x, GEF4 FX provides additions to JavaFX that are useful in the context of graphical applications. Essentially, this comprises implementations of visual anchors, a connection abstraction, and related decorators. Furthermore, GEF4 FX delivers enhanced support for integrating JavaFX with SWT in terms of an own canvas implementation that augments the JavaFX provided FXCanvas with support for forwarding of gesture events (which is still missing in JavaFX 8). It also provides support to integrate SWT widgets (nested below an FXCanvas) into the embedded JavaFX scene graph, so that SWT widgets and JavaFX nodes can be layouted together.


GEF4 MVC is a generic model-view-controller framework that can be used to build up graphical editors and views. It is the intended replacement for GEF (MVC) 3.x and - compared to this - offers a couple of significant advantages. At first, there is a clear separation into core abstractions, JavaFX-dependent aspects, and Eclipse UI-integration related ones. Due to this, GEF4 MVC-based editors or views can be deployed as part of standalone Java applications, and may even be deployed in the web. Second, GEF4 MVC makes intensive use of the IAdaptable-patten provided by GEF4 Common and can be flexibly configured via Guice-based dependency injection. Third, from an end-users viewpoint, GEF4 MVC profits from much nicer visualization capabilities offered by JavaFX and GEF4 FX, and provides long requested features like an infinite canvas approach, direct support for application of rotations and other affine transforms, continuous zoom, and "live-feedback".


GEF4 Graph provides a simple model to represent directed graphs. It is used by GEF4 Zest as underlying data model for visualization as well as by GEF4 DOT as import/export data model. In the mid-term, GEF4 Graph could become the default notation model to be used for graphical editors and views that are based on GEF4 MVC. Currently, it is only used by GEF4 Zest in this role, where it is adapted to GEF4 Layout for automatic layouting.


GEF4 Layout provides general abstractions to integrate layout algorithms, as well as related  implementations (spring, grid, radial, sugiyama, tree, horizontal shift, space tree). It is used by GEF4 Zest for automatic layout of graphs, but can in principle be used by arbitrary graphical applications. Currently, there is no direct support for integrating GEF4 Layout algorithms into GEF4 MVC, but this is an intended extension for the mid-term. Furthermore, its intended to align the provided abstractions with the KIELER framework, so the layout algorithms provided there can also be easily integrated.

Zest (Zest.FX, Zest.FX.UI) 

GEF4 Zest is a framework for graph visualization and the intended replacement for Zest 1.x. Being written completely from scratch, GEF4 Graph-based data models are visualized using JavaFX and GEF4 FX and - through an integration of GEF4 Layout - also automatically layouted. GEF4 Zest provides a default visualization that can be adjusted through CSS styling. It is internally based on GEF4 MVC, and may thus be used in standalone Java applications or integrated within the Eclipse UI. As part of the Eclipse integration, GEF4 Zest furthermore provides a JFace-API, which allows to visualize a graph based on a dedicated viewer. From an end-users perspective GEF4 Zest supports additional features like hiding/unhiding of nodes as well as semantic zoom.


GEF4 DOT provides an Xtext-based editor for Graphviz .dot files, support for parsing and serializing DOT to/from GEF4 Graph representations, as well as 'DOT Graph' view to visualize .dot files via GEF4 Zest. The view also provides PDF export support based on the Graphviz native executable.

Cloudio (Cloudio.UI)

GEF4 Cloudio provides support for rendering tag clouds. This includes a dedicated SWT widget as well as a JFace-based viewer. In addition, GEF4 Cloudio offers a dedicated view, via which end-users can create and export tag clouds based on an input text file. In contrast to the other GEF4 components, GEF4 Cloudio does not support JavaFX-based rendering yet.

by Alexander Nyßen ( at June 24, 2015 03:32 PM

WTP 3.7 Released!

June 24, 2015 03:14 PM

The Eclipse Web Tools Platform 3.7 (Mars) has been released! Featured in the Eclipse IDE for Java EE Developers, you'll also find parts of WTP in many of the Mars packages. Of course you can still download the raw WTP 3.7 build manually--don't forget the dependencies if you do. Anyone with a working Eclipse 4.5, or Mars package, can install WTP by working with the Mars and corresponding WTP Update Sites.

More news

June 24, 2015 03:14 PM