After 13 years, the Eclipse framework gets it second make-over. The new work is termed e4 and will be included in Eclipse 4.0.
In the first make-over the run-time was replaced in Eclipse 3.0 with OSGi to get a better and more stable foundation for plug-ins. This time the user interface and contributions are modernized for use in Eclipse 4.0.
In this session, we will see some of the insides of the new paradigms in e4.
#StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
javagruppen.dk - e4, the next generation Eclipse platform
1. PR0017 - 2009-09-29
Redistribution and other use of this material requires written permission from The RCP Company.
e4, the Next Generation Eclipse Platform
After 13 years, the Eclipse framework gets it second make-over. The new
work is termed e4 and will be included in Eclipse 4.0.
In the first make-over the run-time was replaced in Eclipse 3.0 with OSGi to
get a better and more stable foundation for plug-ins. This time the user
interface and contributions are modernized for use in Eclipse 4.0.
In this session, we will see some of the insides of the new paradigms in e4.
2. PR0017 - 2009-09-29
2
Agenda
Introduction
Eclipse is… what exactly?
A little about the general Eclipse architecture
The goals and history of e4
The guts of e4
The timeline for Eclipse 4.0
3. PR0017 - 2009-09-29
3
Who Are You?
Who uses with Eclipse?
Who have developed plug-ins for Eclipse?
Who have al ready looked into e4?
Who knows about Dependency Injection?
4. PR0017 - 2009-09-29
4
About Me
Tonny Madsen, Founder and Owner of The RCP Company
20 years of experience in system development in major
companies
Regnecentralen (now ICL)
Digital (now HP)
Anritsu (previously NetTest)
9 years experience as the Systems Architect of an 20+ MLoC
project
8 years of experience with Eclipse and Eclipse RCP
Solutions Member of the Eclipse Foundation
Chairman of Eclipse.dk
Extern Lecturer at IT-University on Model Driven Development
and Domain Specific Languages
Regular speaker at EclipseCon, Eclipse Summit, etc
11. PR0017 - 2009-09-29
11
Basically…
We need an architecture that supports
distributed development over a large number
of autonomous development groups
We need a component concept where
components are loosely coupled and can be
started (and stopped) independently
We need a way to describe external
interfaces of components and dependencies
between components
We need a way to only start the components
as they are needed – also known as late
activation
We need all this to work over multiple
generations of components
14. PR0017 - 2009-09-29
14
Organizing the Platform
The software of an Eclipse system is based on the following terms:
Plug-ins – a plug-in is the basic unit of software
Fragments – a fragment is an add-on to an existing plug-in with
additional functionality
Features – a feature is a number of plug-ins that is distributed and
updated as a whole
Applications – an application is a Java class that implements a specific
interface and is declared as such in the plug-in
Products – a product is a set of features or plug-ins along with the
appropriate branding
15. PR0017 - 2009-09-29
15
The Short Story
1994: IBM develops VisualAge for Smalltalk – programmed in Smalltalk
1995: Java is released to a select group
1996: IBM develops VisualAge for Java – still programmed in Smalltalk
November 1998: OTI (Object Technology International – part of IBM)
commissioned to develop new development platform for Java
7. November 2001: Eclipse 2.0 made Open Source
25. June 2004: Eclipse 3.0 released introducing Eclipse RCP
Framework make-over introducing OSGi
2009: Eclipse 3.5 released – known as Galileo
27. June 2010: Eclipse 3.6 will be released
Also known as Helios
June 2011: Eclipse 3.7 will be released
June 2012: Eclipse 4.0 will be released
17. PR0017 - 2009-09-29
17
Why A New Eclipse Framework
Simplify the Eclipse programming model
This will reduce development and maintenance costs and enable a larger
developer community to leverage the platform in their own Eclipse-
based applications
Enable the platform for use on emerging web-based runtime technologies
This will ensure the platform remains a compelling and viable
application framework in a rapidly changing web technology landscape,
and it will allow e4-based applications to leverage web technologies,
while remaining insulated from specific technology choices that may
quickly become obsolete
Broaden participation in development of the platform
This reduces the risks associated with building on a platform largely
funded from a single source. Having a large and diverse group of
commercial backers, will ensure the platform remains vibrant and viable
over the long term
18. PR0017 - 2009-09-29
18
Main Technical Differences between Eclipse 3.x and e4
Application Model in EMF
Complete live model for the application – changes are reflected
immediately in the application
Rendering the Application
Maps the model to the UI
Allows for a completely new look and feel without touching the internals
Allows support for different widget sets – even Adobe Flash or Microsoft
Silverlight
Context
Contains the context/environment for all contributions
Brokers interaction with the framework: service lookup, service
registration
Dependency Injection
Allows for POJOs for all contributions
19. PR0017 - 2009-09-29
19
Basic e4 Workbench Model
Application
Command
Handler Binding
Window
Part
Menu
Part Description
Toolbar
20. L0036 - 2008-11-23
20
Basic Eclipse 3.x Workbench Model
Workbench Window
Workbench Page
Editors Views
PerspectiveTop-level menu
Top-level toolbar
Status line
Perspective switcher
Drop-down menuLocal toolbar
Workbench
0..n
1..n
0..n0..n
22. PR0017 - 2009-09-29
22
Rendering the Application
Provides the mapping of the model to a specific UI Widget Set
SWT
xWT
GWT
Adobe Flash
Macrosoft Silverlight
For some of the mappings, the concrete look can be customized using CSS
A render
Creates the needed widgets for the model element
Binds the widget and model element
23. PR0017 - 2009-09-29
23
The Current Context - IEclipseContext
Contains the current context for contributions
Name/Value pairs
Value can be POJO or IComputedValue objects
Created in a hierarchy
Children inherits all values from parent
Child contexts are used to override values locally
Used for all contributions
Views
Handlers
Wizards
Dialogs
etc
Supports
IClipseContext.runAndTrack – allows you to track changes in the values you
use
IComputedValue – allows for late creation of objects and common behavior
Used as the base data store for Dependency Injection
24. PR0017 - 2009-09-29
24
Dependency Injection
Popular solution to the singleton problem:
PicoContainer
Spring
Google Guice
OSGi declarative services
Injection supported for all class members:
Fields, Constructors and Methods
Need not be public or protected
Marked with @Inject
Possibly @Optional
Value based on type of argument or field
Finds matching value from IEclipseContext
Possibly marked @Named(“name”)
Used with static methods on ContextInjectionFactory:
Object inject(Object object, IEclipseContext context)
Object make(Class clazz, IEclipseContext context)
Object invoke(Object object, String methodName, IEclipseContext context,
Object defaultValue)
25. PR0017 - 2009-09-29
25
Code for Parts
The code that provides the “parts” of the application is ordinary POJO
No special inheritance – e.g. IViewPart or IWizardPage
public class Preview {
public Preview(Composite parent, Realm workspace) {
// Create UI ...
}
@Inject
private MUILabel uiItem;
@Inject
public void setSelection(@Optional @Named(IServiceConstants.SELECTION) IFile input) {
// React on Selection Changes
}
}
27. PR0017 - 2009-09-29
27
Open Social Gadgets
What are OpenSocialGadgets
Gadgets are web-based software components based on HTML, CSS, and
JavaScript.
Open Eclipse for a new set of developers
Examples
Remember the Milk http://www.rememberthemilk.com
Twitter Gadget
…
28. PR0017 - 2009-09-29
28
The e4 Story
First presented at EclipseCon ’08
20. May 2008: Mail to e4-dev „A radical approach to explore new paths for
e4“
Platform designed from Scratch
Based upon an EMF-Application-Model
No statics, no singletons, usage of Dependency Injection
Based on OSGi-Services
14. January 2010: 1.0M3 released
27. June 2010: 1.0 will be released
29. PR0017 - 2009-09-29
29
If You Want to Know More about Eclipse
The foundation:
http://eclipse.org
The Danish User Group:
http://eclipse.dk
The training:
http://www.eclipse.org/community/training/classes.php
Resources on Eclipse:
http://www.eclipse.org/resources/
Consolidated Blog:
http://planeteclipse.org/
30. PR0017 - 2009-09-29
30
If You Want to Know More about e4
The Project:
http://www.eclipse.org/e4/
Downloading e4:
http://download.eclipse.org/e4/downloads/
The Wiki:
http://wiki.eclipse.org/E4
The training:
Not yet, but coming after the Summer
Tutorials on e4:
http://www.vogella.de/articles/EclipseE4/article.html
A “create an application” tutorial from Lars Vogel
32. PR0017 - 2009-09-29
32
Eclipse.dk – The Danish Eclipse Society
Eclipse.dk was created in Marts 2007 as a meeting place for everyone
interested in the Eclipse (www.eclipse.org) platform.
The purpose of Eclipse.dk is as follows:
To promote the knowledge of Eclipse in Denmark.
To create networks amongst danish Eclipse-users and developers.
To build knowledge on Eclipse in Denmark, especially
In danish institutes of higher education.
Between danish companies developing applications based on Eclipse.
Create and maintain a web site on Eclipse for danish users – eclipse.dk.
Strengthen the relations between danish and international Eclipse-users and
organizations.
The eclipse.dk society has members representing not only vendors of
Eclipse-based products and services, but also users of the platform and
representatives from institutions of higher education.
Editor's Notes
Just to make everybody aware that they actually know about Eclipse already. It is known technology – not new technology. ESB, web services and BPM are all considered new technology…
The current view of Eclipse according to the Eclipse Foundation. Really, the same view as when Eclipse was first conceived.
This is the prototype of the banking desktop. It looks and feels like an Eclipse application. Just see the L&F. No serious presentation branding has been performed… yet…
One area where e4 would have helped – the look could be Nordea look instead of Eclipse look.
Is this Eclipse RCP?
The perspective switcher is different!
Views in the “same position” of the perspective – a so-called folder – are shown differently.
The “Launch” button
Based on Eclipse RCP!
Early demo based on Eclipse RCP 3.1
Look of some native widgets has been changed!
UI is a mix of SWT and Native Notes® windows
The workbench is recognizable yet different
Domino, IBM, Lotus, Notes and Workplace Client Technology are trademarks or registered trademark of International Business Machines Corp. in the United States, other countries, or both.
IBM Lotus Notes look&feel was designed by Mary Beth Raven.
Would have been easier with e4, as this would have eased the structural changes as well.
What are the main drivers for the Eclipse architecture?
Eclipse products are built in layers.
At the bottom there are Eclipse RCP with the bare necessities. The RCP subsystems typically add visible features to the platform and provide APIs for extending their functionality. Some of these components supply additional class libraries that do not directly relate to an extension point, but can be used to implement extensions. For example, the workbench UI supplies the JFace UI framework and the SWT widget toolkit.
The platform layer adds the generic features needed for an Integrated Development Environment (IDE).
The different language support sits on top of the platform. The basic IDE features (known under the misleading name Eclipse SDK) includes two major tools that are useful for plug-in development. The Java development tooling (JDT) implements a full featured Java development environment. The Plug-in Developer Environment (PDE) adds specialized tools that streamline the development of plug-ins and extensions.
Likewise for the many features of Calisto, Europa and now Ganymede. They are also layered to provide a set of basic features that are used by other features to provide better and more specialized tools.
The Resources, Workspace and Update components shown above is not really part of the very basic RCP component set. They are used very often in RCP applications.
Using Eclipse RCP in an application is typically done the very same way as when used in Eclipse IDE.
At the bottom there are Eclipse RCP with the bare necessities.
The platform layer adds the generic features needed for any application in the specific environment.
The application itself is then placed at the top.
The terms listed above are central to an Eclipse system and it is rather important to understand them in order to implement a big Eclipse application.
Also an outline of the history of Eclipse
Tooling yet a little rough
We all know a new framework is expensive, so why do this?
Simplify the Eclipse programming model
We want more models in Eclipse – e.g. the workbench itself – as this will
Ease the support for alternative UI – a new look for Eclipse
Separate appearance from content
The Eclipse API is 13 years old (!) and is beginning to show its age
Too many singletons
Accumulated garbage
Complicated class hierarchy
Enable the platform for use on emerging web-based runtime technologies
Communication getting faster and faster
Web Browsers have a fast JavaScript engine
RAP on steroids
Broaden participation in development of the platform
There are vastly more people programming for the web than for Eclipse – what if we could simplify the model for Eclipse to tap into these resources
Support for
JavaScript for Plug-ins
Skinnable UI
OpenSocial gadgets
Scripting
The 20 things
From the official whitepaper for e4
Context
Also eases the testing of application code – you “just” need to fake the environment
Commands are global, but the implementations (Handlers) can be local – also so with bindings
The information model of the Eclipse workbench consists of a number of entities. These all have a UI representation expect for Workbench and Perspective.
The information model is relative simple:
A workbench consists of one or more workbench windows.
Each workbench window has a top-level menu, a tool bar, a status line and a perspective switcher.
Each workbench window has exactly workbench page.
Each workbench page has one or more perspectives.
Each workbench page handles any number of editors and views.
Each perspective provides a specific view of the editors and views of the page.
Each view also has a view-local menu and tool bar.
Most applications only have one window.
Most UI resources in the application is handled on a per-window basis, which can be very important if the windows are shown on different monitors, in which case the low-level resources such as fonts and images must be handled specially.
Please note that the Resource API provides a view of the workspace of the user and this view is common to all workbench windows.
All editors and views are shared between all perspectives of a workbench window.