The last major change to Eclipse was with the 3.0 release when it migrated to OSGi. The Eclipse 4 model provides a significant departure from the Eclipse 3.x line, with the user interface being represented as a dynamic EMF model. In addition, both the model and views can be represented as simple POJOs with services provided by dependency injection. There is also a separate rendering mechanism which allows an E4 application to be hosted by different UIs, although we'll look at the SWT renderer specifically. In this chapter, we'll take a look at the differences and how you can evolve Eclipse plug-ins forward.
In this chapter we shall:
- Set up an Eclipse 4 instance for development
- Create an E4 application with parts
- Style UI with CSS
- Send and receive events
- Create commands, handlers, and menus
- Integrate with preferences
- Inject custom POJOs
Since Eclipse was first released in November 2001, its user interface has remained mostly static. Each window has a perspective, which contains zero or one editor area, and zero or more view parts. In early releases, every perspective had exactly one editor area, and it was not until the release of Eclipse RCP with Eclipse 3.0 in 2004 that it was possible to disable the editor, and have a custom application suitable for a non-IDE use.
However, the presentation of the perspective always proved difficult to customize, such as changing the background color or arrangement of the windows or toolbars.
The Eclipse 4 model provides a way to model an application both at design time, and also interpret and modify it at runtime. An application has a top-level model, but may also have additional model fragments contributed by different bundles. Additionally, the separate rendering framework allows the UI to be represented with different tools such as JavaFX and HTML. In this book, the default SWT rendering tool will be used, since that closely matches the existing Eclipse 3.x UI.
The other significant change is that it is no longer necessary to create subclasses of specific classes to contribute to the Eclipse infrastructure. Instead, classes are created with dependency injection (similar to how Spring components are configured) and may consume platform-level services separately to the user interface. Instead of referring to global singletons through accessor methods, these are now available through injection. This allows components to be built as simple POJOs (Plain Old Java Objects) which allows them to be tested headlessly and provides a looser binding to the services that they consume.