EclipseCon2011: Day one and I’m done

Yeah. Day one is over (at least all my presentations are done) and I’m ready to enjoy EclipseCon in the next 3 days because I’ve no more talks this week. I think the talks I’ve delivered today have been received quite well.

  • Eclipse 4.x RCP Tutorial: Kai will upload our slides later on his blog. We had around 100 attendees and I think most of them liked our tutorial
  • Single Sourceing for Eclipse 4.x and 3.x: I think I got the message around. The slides can be looked at once more following the link

Equinox, Hibernate and Concurrency

I’ve been hunting a deadlock in an application of a customer we support with our RCP, EMF and OSGi know-how and turned out be a class-loader problem because Hibernate uses Class.forName().

The application is a pure OSGi-Application acting as an Application Server which is used to process database informations in an asynchronous fashion and heavily uses OSGi-DS to wire up the complete application. The problems we’ve been facing only happened at start up where many threads are accessing database informations in a highly concurrent fashion.

The deadlock information from the JVM looked like this:

Found one Java-level deadlock:
=============================
"Thread-23":
  waiting to lock monitor 0x18b30eac (object 0x09c93230, a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader),
  which is held by "Thread-17"
"Thread-17":
  waiting to lock monitor 0x1977f16c (object 0x09c92fd0, a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader),
  which is held by "Thread-12"
"Thread-12":
  waiting to lock monitor 0x18b30eac (object 0x09c93230, a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader),
  which is held by "Thread-17"

where the threads where calling the following methods:

“Thread-23”:

        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:169)
        at org.hibernate.util.ReflectHelper.classForName(ReflectHelper.java:192)
        at org.hibernate.impl.SessionFactoryImpl.getImplementors(SessionFactoryImpl.java:825)
        at org.hibernate.hql.QuerySplitter.concreteQueries(QuerySplitter.java:123)
        at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:92)
        at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
        at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:124)
        at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156)
        at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135)
        at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1770)

“Thread-17”:

        at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:468)
        - waiting to lock <0x09c92fd0> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader)
        at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449)
        at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
        at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
        at org.eclipse.osgi.internal.loader.buddy.DependentPolicy.loadClass(DependentPolicy.java:54)
        at org.eclipse.osgi.internal.loader.buddy.PolicyHandler.doBuddyClassLoading(PolicyHandler.java:135)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
        at org.eclipse.osgi.internal.loader.buddy.DependentPolicy.loadClass(DependentPolicy.java:54)
        at org.eclipse.osgi.internal.loader.buddy.PolicyHandler.doBuddyClassLoading(PolicyHandler.java:135)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
        at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:169)
        at org.hibernate.util.ReflectHelper.classForName(ReflectHelper.java:192)
        at org.hibernate.impl.SessionFactoryImpl.getImplementors(SessionFactoryImpl.java:825)
        at org.hibernate.hql.QuerySplitter.concreteQueries(QuerySplitter.java:123)
        at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:92)
        at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
        at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:124)
        at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156)
        at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135)

“Thread-12”:

        at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:468)
        - waiting to lock <0x09c93230> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader)
        at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449)
        at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
        at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393)
        at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:466)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
        at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        at com.bizerba.basic.resource.teneo.TeneoHbDataStoreProvider$ChangeInformationInterceptor.afterTransactionBegin(TeneoHbDataStoreProvider.java:148)
        at org.hibernate.impl.SessionImpl.afterTransactionBegin(SessionImpl.java:1479)
        at org.hibernate.jdbc.JDBCContext.afterTransactionBegin(JDBCContext.java:259)
        at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:107)
        at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1473)

So what did we do to fix the problem once we managed to get to the bottom of it? We asked at the equinox IRC-Channel for help and Tom Watson pointed me to a bug 212262 describing more or less the problem we are seeing. As described in the bug we’ve added jvm options:

-XX:+UnlockDiagnosticVMOptions
-XX:+UnsyncloadClass

and ran our test-suite the whole night and could not reproduce the locks since then.

So if you happen to run Hibernate (other libraries who use Class.forName() might have the same problem) inside the Equinox-OSGi-Container (I have no idea if other OSGi-Implementation might face the same problem) and your system is doing many things in a concurrent way you should consider setting those 2 options to avoid deadlocks.

e4 – Fundamental Overview on the Eclipse 4 Application Platform

In my last blog post I talked very short about the relation of XWT and the Eclipse 4 Application platform. It looks like many people are mixing things up. In this post I’ll try to give a deeper look into the Eclipse 4 Application Platform which might make even clearer why XWT is not necessarily part of a Eclipse 4 application.

I can only reiterate that the Eclipse 4.0 Application Platform (EAP) is not forcing you in a direction or technology (it even not force you to use SWT though for many applications this might be the natural choice). Let’s look at the big picture at first.

The center of an EAP-Application is the Application Model   is defined using Ecore and holds the complete application state at runtime. One of those runtime informations is the core UI-Structure your custom UI-Code is plugged in at runtime but there are many other none ui types found in like handlers and commands. You can think of the Application Model as the central registry of an EAP Application and because things come and go in a running application the model is dynamic and changes while your application is running (e.g. when switching Perspectives, moving UI-Elements around e.g. detaching an editor)

An interesting fact though is that you also use this very same Application Model at design time which is in complete contrast to Eclipse 3.x where you use the plugin.xml-Model to describe your application. The default format we use to persist the model at design time is XMI which is supported by EMF but in the end the EAP does not really care in which format the Application Model is persisted all it needs when starting up is an in memory instance of the model.

This means the Application Model has 2 different states in can be in:

  • Designtime state: Used to describe how the running application should look like when started which gets persisted e.g. to an XMI-File
  • Runtime state: An in memory model loaded e.g. from the designtime state stored which gets processed by EAP and once finished the Eclipse 4 Application UI is presented to the user and after this point a bidirectional relationships between the in memory model and UI-Controls is established

The 2 different states the Application Model can be in is also reflected by the tooling:

  • Model Editor: Is an filesystem based editor similar to the plugin.xml-Editor and stores the model as an XMI-File
  • Live Model Viewer/Editor: Is operating on the in memory model of an running EAP Application and because the model is a live model you can not only view informations but also modify them
    State 1: State 2:

Now let’s go on to see what the EAP does with the model and how it creates the UI out of this abstract information.

As outlined already the Application Model holds UI-Information but what you find in the model are abstract UI-Concepts like Window, Perspective and PartStack but does not talk about concrete widgets to used to implement such a concept in the UI presented to the user. The transformation (we call it rendering) of the model elements into concrete widgets is the responsibility of the Rendering Engine  .

From a very highlevel the process is like this:

The last small thing I’d like to show in this post how the Java-Class referenced in the MPart named my.bundle.a.View looks like:

package my.bundle.a;

public class View {
  @Inject
  public View(Composite parent) {
    // Make up the content displayed in the part
  }
}

There are a lot of talks at EclipseCon 2011 and I’m giving a tutorial together with Kai Tödter and Eric Moffatt where you can learn how to write applications using the Eclipse Application Platform.

e4 – Relation between Eclipse 4.1 and XWT

Today someone approach me and his introduction statement was that he’s interested in XWT and was told that Eclipse 4.1 is built upon XWT. I’ll restate the same I’ve stated in all of my talks: XWT is a technology developed in the e4-Incubator side by side with the Eclipse 4 Application Platform.

The important thing here is SIDE BY SIDE which means XWT nor the Eclipse 4 Application Platform have a dependency on each other! The Eclipse 4 Application platform makes no assumption on the technology you use to write/describe your UI – the system is extremely open which I highlighted in another blog where I used Swing to render the UI.

So once more the important message: Eclipse 4.1 does not depend on XWT nor does XWT depend on Eclipse 4.1

e4 – More News from ModelTooling

Some weeks ago I’ve blogged about some new features I’ve added to the e4-ModelTooling. The soon declared 4.1M6 release will hold some more features I’d like to present to you in this blog entry.

Control Finder

If you are interested into which widget the rendering engine turned a specific model element into and where it is rendered on the screen there’s now support to find this out.

Widget Tree Browser

The widget browser allows you to completely inspect the widget tree of the running applications. Together with the introduced Control-Finder those 2 utilities will help developer to inspect, debug and ultimately better understand and control applications built upon the Eclipse 4.0 Application Platform.

Scripting Support

In contrast to the 2 features above who allow developers to inspect the applications this feature give developers the power to interact with the running application using a scripting language like JavaScript, Groovy, … .

Europe rules at the Eclipse Individual Awards

Looking at finalists of the individual awards finalists it looks like Europe rules (9 finalists, 7 from europe, 2 canada – I counted Boris for Canada).

I’m delighted to be part of the final nominies once more [see 2009 1,2] and thank anyone who voted for me. It is really a big honor to be part of the final nominees given that I’m a sparetime committer (well if I’d really count the hours I spend e.g. on e4 it could be compared to a half-day job).

BTW if there are people arriving already Friday for EclipseCon 2011 and search for a taxi share to get to Santa Clara there’s a wiki page to coordinate the arrivals.

Anyways if you happen to be at EclipseCon I’d like to invite you to the sessions I’m going to present together with great people:

I think both of those session will provide interesting topics to you and even if you’ve not considered the Eclipse 4.0 development relevant to your daily work I’d like to invite you to my talk Singlesourcing for Eclipse 4.x and Eclipse 3.x who might change your mind.

e4 – Use Eclipse 4.1 Application Platform but not SWT

So the title already says what this Blog-Post is about. It will talk about the possibility to use the Eclipse 4.1 Application Platform without using SWT to develop your UI-Components.

Already the initial designs of Eclipse 4.x splitted the codebase not only into Core and UI-Components but futher broke up the UI-Components in stuff into a toolkit independent and toolkit dependent part. The concept we are using here is often referred in our talks as the “RenderingEngine” which is responsible of turning our Application Model into an UI.

In the 4.0 we violated our own design by dragging in unwanted SWT-Dependency through referenced bundles but we got rid (or better said will get because of bug 338559) of them in 4.1 and so the Eclipse 4 Application Platform we’ll be able to be used without using SWT but use the UI-Toolkit of your choice (e.g. Swing, Qt, …).

To make it possible to write e.g. Swing-Applications using the Eclipse 4 Application the only requirement is that someone wrote a replacement for the default rendering engine provided by default by the e4-Team. To find out how much effort it would be to write such a thing I’ve experimented a bit yesterday and have to admit it’s doable using the SWT-Implementation and translating into Swing calls. Hacking for about 5 hours I had a minimal Swing-Application running on.

Here’s a screenshot of my model editor which is used to connect the pieces so that we get a running application:

So what does this first experiment tell us? The Eclipse 4 Application Platform is a flexible UI Framework to build component based UI application no matter if you use SWT or not and the effort to provide a rendering engine for another UI-Toolkit is not a task of man years.

The educated reader might ask why one would want to write applications without using SWT given that Eclipse 4.1 allows you to style widgets using CSS.

There are multiple:

  • SWT and Styling pixelperfect: For many types of applications I have no problems with the limitation SWT has when it comes to styling the native widgets (when e.g. writing Database-Forms) but when it want to write a stylish UI which looks as slick as applications created with other RIA technologies. Don’t believe me? Ever tried to change the background-color of a Button?
  • JavaFX on the horizon: The first test reports from JavaFX 2.0 are promising and my bet is that integration into a Swing-Application is going to be easier than in SWT. I think using JavaFX will be quite nice if you’d like to include multimedia content and use animations which is something SWT has not made any progress since the early days of the Eclipse 4.0 effort
  • Legacy-Swing codebase: If you have a lot of Swing knowledge and probably even source code it might be easier to stay with Swing
  • Learn only one RCP-Framework: If you have to write application using different Toolkits (SWT,Swing, …) it is easier to learn only one framework currently you’ll have to keep the knowledge about Nebeans and Eclipse RCP
  • You simple like Swing/Qt and want to make use of the new DI-Programming model, OSGi-Services and the new idea of the central application model

Finally what did i use to make the small application in the screen shot:

  • Java 1.6 SE (swing is part of it🙂
  • Eclipse Databinding: Only the core part and Pojo-stuff
  • org.eclipse.ufacekit.ui.viewers: Base implementation for JFace-Viewer like components but defined in a widget toolkit independet fashion (plus support for Generics)
  • org.eclipse.ufacekit.ui.swing.jface: JFace-Viewer like components for Swing-Controls
  • org.eclipse.ufacekit.ui.swing.databinding: Observable implementation of the Eclipse Databinding API for Swing controls
  • org.eclipse.ufacekit.ui.viewers.databinding: Observable implementation working on top of the generic JFace-Viewer API provided by org.eclipse.ufacekit.ui.viewers