I’m on the road to prepare my example for the E4 talk I’m delivering on the Eclipse-Developers-Day in Karlsruhe and I have to say that in my eyes E4 is going to open up a new world for Eclipse-RCP-Developers.
Though RCP-Applications written in 3.x might not look too bad no one can deny that the UI-Design is coming from an IDE background and compared to modern Web-UIs it looks boring (which is not a bad thing per se for business applications). The problem in 3.x is that it is very hard to impossible to change the L&F of your application.
E4 provides different multiple solutions to fix the L&F:
- Declarative-Styleing through CSS
- The possibility to define your own renderes to exchange Widget A through Widget B if CSS is not enough to theme your application
To demostrate what you can achieve when you combine the 1st and 2nd possibility I create a small screencast
where you see the famous E4-Photo-Application revamped
A second example application is our E4-Contacts-Demo created and maintained by Kai Tödter which shows advanced css-styles like radial gradients.
I use this application to show you another nice thing you can do with E4’s declarative styling support. You can adjust the styling of your application while it is running so that you can experiment with various font and color settings WITHOUT shutting down your application.
If all this would not be enough you can run the unmodified code (please take this literally) from the example application above in your browser using the RAP-Framework.
If you are interested in E4 and what’s going on behind the scenes of the next major Eclipse-Release I hope to see you in Karlsruhe on Tuesday July 7th.
Tomsondev Blog 
The most interesting question for me in regards to e4 is: Will I have to add the EMF bundles to my RCP app and by that adding more bloat just for some CSS styling?
EMF has nothing todo with CSS but yes you will definately need to have a flavor of EMF installed because the whole workbench uses it as the underlying modeling technology. You are talking about bloat to add because of EMF but you forget that we stripped down the whole code tremendously and the Runtime-Part of EMF is smaller than you think (I’d have to look up the concrete numbers). I also said a flavor of EMF because we could probably split up EMF-Core a bit more to move out things not needed like XML-Serialization.
But you are pointing your finger on to the right thing (though on the wrong library) because today the CSS-Engine is quite an heavy thing because parsing the CSS-Stuff needs Batik if I remember correct and this is where the bloat is happening. We need to see if we can change this and how.
Yes, a simple RCP app quickly reach 30Mo, let’s not run to 50. But who cares if it’s all server-side now 🙂
I just exported the Contacts-Demo and here are the figures. The total size of the exported 16 MB (14 MB zipped) where 5.5 MB is taken by com.ibm.icu and can be replaced by com.ibm.icu.base, the css stuff all in all needs batik (243+145+90KB) + css implementation (169+13+103KB) =~ 800 KB and emf (199K+64K+213K+1MB) =~ 1,3 MB (in the current packaging structure which could be changed a bit). So in reality the application has a minimum size of 10.5 MB.
The complete list:
5,5M – com.ibm.icu_4.0.1.v20090415.jar
1,8M – org.eclipse.swt.cocoa.macosx.x86_64_3.5.0.v3550b.jar
1,1M – org.eclipse.osgi_3.5.0.v20090520.jar
1,0M – org.eclipse.jface_3.5.0.I20090525-2000.jar
1,0M – org.eclipse.emf.ecore_2.5.0.v200906151043.jar
689K – org.eclipse.core.resources_3.5.0.v20090512.jar
277K – org.eclipse.core.databinding.observable_1.2.0.I20090604-2000.jar
252K – org.eclipse.jface.databinding_1.3.0.I20090525-2000.jar
243K – org.apache.batik.css_1.6.0.200907030925.jar
213K – org.eclipse.emf.ecore.xmi_2.5.0.v200906151043.jar
211K – javax.xml_1.3.4.200907030925.jar
199K – org.eclipse.emf.common_2.5.0.v200906151043.jar
192K – org.eclipse.core.databinding_1.2.0.I20090604-2000.jar
188K – org.apache.commons.beanutils_1.7.0.200907030925.jar
169K – org.eclipse.equinox.registry_3.4.100.v20090520-1800.jar
169K – org.eclipse.e4.ui.css.core_0.9.0.200907030925.jar
153K – org.eclipse.core.databinding.property_1.2.0.I20090526-2000.jar
145K – org.apache.batik.util.gui_1.6.0.200907030925.jar
119K – org.eclipse.core.resources.compatibility_3.4.0.v20090505.jar
113K – org.eclipse.e4.ui.model.workbench_0.9.0.200907030925.jar
103K – org.eclipse.core.commands_3.5.0.I20090525-2000.jar
103K – org.eclipse.e4.ui.css.swt_0.9.0.200907030925.jar
103K – org.eclipse.equinox.preferences_3.2.300.v20090520-1800.jar
97K – org.eclipse.equinox.common_3.5.0.v20090520-1800.jar
90K – org.apache.batik.util_1.6.0.200907030925.jar
88K – org.eclipse.nebula.widgets.gallery_1.0.0.200907030925.jar
85K – org.eclipse.core.contenttype_3.4.0.v20090429-1800.jar
84K – org.eclipse.core.expressions_3.4.100.v20090429-1800.jar
80K – org.eclipse.core.jobs_3.4.100.v20090429-1800.jar
80K – org.eclipse.equinox.app_1.2.0.v20090520-1800.jar
72K – org.w3c.dom.svg_1.1.0.200907030925.jar
71K – org.eclipse.core.databinding.beans_1.2.0.I20090525-2000.jar
68K – org.eclipse.core.runtime_3.5.0.v20090525.jar
64K – org.eclipse.emf.databinding_1.1.0.v200906151043.jar
56K – org.eclipse.e4.ui.workbench.renderers.swt_0.9.0.200907030925.jar
55K – org.eclipse.e4.core.services_0.9.0.200907030925.jar
52K – org.eclipse.e4.demo.contacts_0.9.0.200907030925.jar
49K – org.eclipse.e4.ui.workbench_0.9.0.200907030925.jar
44K – org.eclipse.equinox.launcher_1.0.200.v20090520.jar
43K – org.eclipse.core.filesystem_1.2.0.v20090507.jar
43K – org.apache.commons.logging_1.0.4.v200904062259.jar
24K – org.w3c.css.sac_1.3.0.200907030925.jar
21K – org.eclipse.e4.ui.workbench.swt_0.9.0.200907030925.jar
18K – org.eclipse.equinox.concurrent_1.0.0.v20090520-1800.jar
16K – org.eclipse.swt_3.5.0.v3550b.jar
13K – org.eclipse.e4.ui.css.nebula_0.9.0.200907030925.jar
11K – org.eclipse.e4.ui.services_0.9.0.200907030925.jar
11K – org.w3c.dom.smil_1.0.0.200907030925.jar
11K – org.eclipse.core.filesystem.macosx_1.1.0.v20090112.jar
3,8K – org.eclipse.e4.core.services.annotations_0.9.0.200907030925.jar
238B 3 Jul 09:26 org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800
204B 3 Jul 09:26 org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.0.0.v20090519
The EMF core runtime library itself is quite tiny – just about 2MB, so I would argue that adding EMF itself does not add any bloat to anything.
Plus of course – as others have already pointed out, the CSS rendering has nothing to do with EMF and everything to do with “bloat” (depending on your definition of “bloat”)…
Pretty cool ! Do you think e4 apps will be RAP based ?
They can be based upon RAP and the work for the RAP team to provide you with a runtime should much less work than it is today because they don’t need to patch the whole underlying workbench code.
Thanks, Tom. 10 MB sounds fair enough! I think I will give it a try. Is there any document how to transform a 3.x app to E4? Will my views all still work? Or do I first have to learn EMF?
I wonder why com.ibm.icu is not split up into fragement bundles for each language. Its just bloat to carry all this waste around when you never ever going to use all the languages it covers.
Do I read your list correctly that the ui.workbench bundle is missing (~4MB in 3.5)?
Please note that E4 is a complete rewrite of the core and so you won’t see things you know from 3.x! We provide a compat layer so that you can run your 3.x plugins but that naturally adds bloat to your system you don’t want to have.
Without the compat layer your ViewPart/EditorParts won’t work out of the box but I hope to have time soon to show how you can structure your 3.x code in a way already today that it can run on E4 without compat layer with minimal changes. Please also note that the 3.x is going to be maintained some more years so that you are not forced to switch.