Eclipse SmartHome 0.9.0 Release Review

End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.




This release includes improvements and new features on many levels, ranging from new framework features to more mature APIs for extensions and a long list of new available extensions.

The binding APIs are pretty stable and in wide use by now and also the new rule engine has matured and can be used productively.

Code wise, the release now uses Java 8 language features and hence dropped support for Java 7.

Major work went into the Paper UI as the reference administration user interface. It supports GUI driven system configuration of the majority of features.

With respect to configuration, a fully new approach is now in place for textual configuration: The RCP-based "Eclipse SmartHome Designer" has been deprecated and is no longer a project deliverable in favor for the new Language Server Protocol (LSP) support that this built into the runtime and which enables external editors to provide similar features as it has been done by the Designer.

With this release, the project switched to EPLv2.

API Certification

The project leadership certifies that the APIs in this release are "Eclipse Quality".

Architectural Issues

Existing APIs have matured, new ones have been introduced to allow new kinds of extensions being added.

The framework's architecture is continuously evolved with the mindset to make it easy for extension developers and keep the heavy lifting hidden within the framework itself.

The main issue with the existing APIs is the heavy use of abstract classes that developers are expected to extend - this makes it difficult to extract a single API bundle against which can be developed.

To better decouple framework implementation and its API and thus more easily guarantee source as well as binary compatibility in the future, we might be forced to do some API breaking changes when moving towards an 1.0 release.

Security Issues

No vulnerabilities were reported.

The project team added a link on how to report vulnerabilities to the project home page as well as to the contribution page.

Non-Code Aspects

The project team continuously tracks and improves the infrastructure that is provided to developers - this starts with the Oomph-based IDE setup, includes Maven archetypes for code skeleton generation and p2 sites with latest builds as well as its dependencies to build against.

A lot of effort has been put into code quality checks: We have a customized static code analysis tooling in place, which combines project specific checkstyle, PMD and SpotBugs rules with specific checks wrt OSGi and our coding guidelines. This tool automatically checks any contribution on Travis before it can be merged.

Furthermore, the team has introduced the use of null annotations, which helps developers to better understand the expected method signatures and which help identifying potential null pointer exceptions.


Conforms To UI/UX Guidelines
Not verified
Usability Details

As the project is a framework, there is no direct impact on the user - it all depends on how solutions make use of the framework in detail.


Overall, the readiness can be seen from the fact that more than four solutions already use the software productively.

End of Life

The Eclipse SmartHome Designer has been removed from the project's deliverables in favor of the new LSP support.


The project heavily relies on the OSGi specification version 4.2 and also exposes this to extension developers. Regular testing on different OSGi framework implementations is done to ensure that there is no dependency on a specific implementation.

A couple of features also use communication standards, such as UPnP, mDNS, HTTP and CoAP. For all of them, the project seeks to use a standard-compliant Java implementation (implementing those protocols is not in scope of the project).


The community is continuously growing. The number of contributors has almost doubled from 69 to 126.

There is an increasing activity on issue reporting as well as pull requests - by now the project team processes an average of 30 PRs every week.