Eclipse Yoxos Services Downloads Blogs About
Home > Blogs >

Archive for April, 2009

on Apr 17th, 2009Finding SWT Leaks with Sleak

In SWT, the mantra is “if you created it, you dispose it.”

The problem is, people forget to dispose which makes leaks a reality.

For example, ever come across this dreaded exception from SWT?

...
org.eclipse.swt.SWTError: No more handles
at org.eclipse.swt.SWT.error(SWT.java:2966)
at org.eclipse.swt.SWT.error(SWT.java:2863)
at org.eclipse.swt.SWT.error(SWT.java:2834)
at org.eclipse.swt.widgets.Widget.error(Widget.java:395)
at org.eclipse.swt.widgets.Control.createHandle(Control.java:482)
at org.eclipse.swt.widgets.Composite.createHandle(Composite.java:229)
at org.eclipse.swt.widgets.Control.createWidget(Control.java:497)
at org.eclipse.swt.widgets.Scrollable.createWidget(Scrollable.java:131)
at org.eclipse.swt.widgets.Control. (Control.java:97)
at org.eclipse.swt.widgets.Scrollable. (Scrollable.java:72)
at org.eclipse.swt.widgets.Composite. (Composite.java:87)
...

One of the most common causes of this type of exception is a resource leak. In SWT, you’re allocating operating system resources for widgets, images, fonts, and other graphical objects. Since there is a platform-specific limit on the amount of resources you can allocate, you must be careful to free any objects that you allocate. To see what resources your application has allocated, the SWT team has a tool called Sleak. To get an idea of how Sleak works, let’s modify the famous RCP Mail example. The first step will be to add the Sleak view to the RCP Mail perspective (Perspective.java):

layout.addStandaloneView(NavigationView.ID,  false, IPageLayout.LEFT, 0.25f, editorArea);
IFolderLayout folder = layout.createFolder("messages", IPageLayout.TOP, 0.5f, editorArea);
folder.addPlaceholder(View.ID + ":*");
folder.addView(View.ID);
folder.addView("org.eclipse.swt.sleak.views.SleakView"); // add sleak here!

The next step is to simulate a leak so we can show the benefit of using Sleak. We can simulate a resource leak by creating a bold font and never disposing of it in the RCP Mail view (View.java):

...
// setup bold font
// comment out the safe way of getting a bold font via the jface registry
// Font boldFont = JFaceResources.getFontRegistry().getBold(JFaceResources.DEFAULT_FONT);
FontData[] fontData = JFaceResources.getDialogFont().getFontData();
for (int i = 0; i < fontData.length; i++) {
	FontData data = fontData[i];
	data.setStyle(SWT.BOLD);
}
boldFont = new Font(parent.getDisplay(), fontData); // this should be disposed in dispose()
...

Ok, now that we have the code modifications out of the way, we need to launch our application. Note, in order to have Sleak function properly, you have to enable some options:

org.eclipse.ui/debug=true
org.eclipse.ui/trace/graphics=true

The easiest way to do this is in your Eclipse application launch configuration. There is a ‘Tracing’ tab that allows you to tweak options:
tracing 300x209 Finding SWT Leaks with Sleak

Once that is done, we can launch our application and find the ‘Sleak’ view:

sleak1 300x191 Finding SWT Leaks with Sleak

If you press the ‘Snap’ button in Sleak, it will take a snapshot of the current allocated resources. To demonstrate the leak, we need to open two more messages in the mail application, close both of them, and then go back to the Sleak view to press the ‘Diff’ button:

sleak3 300x155 Finding SWT Leaks with Sleak

Sleak now informs us that there are two more fonts allocated than before, we have found our leak! If you click the ‘Stack’ option, you can even get a stracktrace that tells you where the resource was allocated. A fix for this problem goes back to the SWT mantra of “if you created it, you dispose it.” In our view, we simply need to dispose of the bold font when we’re done using it (or use the font registry like before):

...
public void dispose() {
     super.dispose();
     boldFont.dispose(); // we need to dispose that font to prevent a leak!
}
...

Here’s a zip of mail example with the leak if you want to toy with Sleak.

Hope this helps!

on Apr 16th, 2009EclipseSource @ JAX 09

One of my favorite conferences of the year is next week, JAX 09.
jax09 EclipseSource @ JAX 09

There will be a few people from EclipseSource at the conference giving talks. Here’s what we have lined up:

Chris Aniszczyk
OSGi for Eclipse Developers
23.04.2009 | 16:45 – 17:45 Uhr | Watfordsaal II
What’s New in Plug-in Development?
22.04.2009 | 08:30 – 09:45 Uhr | Dijonsaal

Markus Knauer
Equinox above the Cloud – some call it heaven!
21.04.2009 | 16:45 – 17:45 Uhr | Zagrebsaal II

Jochen Krause
Eclipse RAP – New and Noteworthy
21.04.2009 | 18:00 – 18:25 Uhr | Watfordsaal II

Jeff McAffer
Equinox p2: provisioning your world
23.04.2009 | 16:45 – 17:45 Uhr | Zagrebsaal II
Runtime(R)evolution at Eclipse
23.04.2009 | 15:30 – 16:30 Uhr | Dijonsaal

Feel free to catch us for some frosty beverages while we’re there. If you want to set a meeting beforehand, email me!

See you at JAX!

on Apr 15th, 2009Equinox Update Interview

EclipseCon was a blast this year.  Lots of great talks and fun people to talk to.  One of my favorite folks to chat with is Michael Cote from RedMonk.  He’s got lots of great ideas and feedback on things. He’s also very interested in Equinox and this whole runtime thing at Eclipse.  EclipseCon afforded us an opportunity to sit (well, stand) together and chat.  Cote just released the video interview on RedMonk TV.

jeffcote Equinox Update Interview

Check it out and see what you think.  Stay tuned as I believe there is a demo session coming up as well.

on Apr 14th, 2009OSGi Training

I’ve been recently approached by people interested in OSGi training. This is quite serendipitous because the Eclipse Training Series is happening right now and offers OSGi training from places like sunny Austin to historic Berlin!

traininggraphic 125x125 OSGi Training

If you’re looking for hands-on training, I highly recommend looking at the Eclipse Training Series. If you like books, here are some books related to OSGi:

Good luck getting up to speed with OSGi!

on Apr 13th, 2009Visualizing OSGi Systems

At the recent OSGi Tool Summit, one of the biggest discussion items that came up was visualization. This makes perfect sense to me as visualizations can be a powerful tool, whether it’s for reviewing your architecture or sharing information with colleagues. In the OSGi world, I only know of two projects starting to scratch the surface of visualizing OSGi systems: PDE and Knopflerfish. Since I co-lead PDE, let me speak about what I know best. In PDE, I recently published a new build of the PDE Visualization project:

pdeviz 300x191 Visualizing OSGi Systems

To install, point Eclipse (Help->Install New Software…) to this repository (make sure you have the Galileo or Ganymede repository in your list of repositories so p2 can reason about the dependencies). I recommend using Eclipse 3.4 or later too.

A couple days ago, I spent some time polishing the visualization code and pondering about what functionality is missing. First and foremost, the biggest thing missing is the ability to visualize packages and services. Currently, it’s only possible to visualize bundle-level dependencies and the only reason this is the case is because noone has spent time to add support! Another cool feature that’s missing in my opinion is to measure dependency extent. Imagine for a second if the screenshot above included information on the weight of a dependency… for example the lines could be thicker to signify how “strong” of a dependency org.eclipse.jdt.core has on certain bundles. This type of information would allow us to potentially prune bundles that we didn’t really need or catch mistakes where we bring in one bundle that depends on the “rest of the world.” There’s so many possibilities when you start thinking about it!

What do people out there want to see in their OSGi visualization tools? Any crazy ideas?

If you’re interested in helping the PDE Visualization project move forward, let me know and I’d love to help you contribute. In my opinion, it would be a great opportunity to get invovled with PDE and potentially the Zest project (which powers the visualizations). Don’t be shy and feel free to shoot me an email.

on Apr 10th, 2009OSGi on AppEngine?

As many people know, Google recently announced support for Java on its AppEngine platform. As a connoisseur of OSGi, the first natural thing that came across my mind was quickly I could get OSGi running on it. Well, I’m happy to announce that we are part way there. I have OSGi running locally on the AppEngine SDK using the Equinox servlet bridge. I’ve managed to get a basic environment running with Equinox (and some bits of p2) and the Knoplerfish console:

appengineosgi 300x188 OSGi on AppEngine?

This wasn’t easy and was full of problems. If you read the AppEngine documentation, the sandbox is quite restrictive. First, there were a few places we were setting the context classloader and AppEngine doesn’t like that. I managed to hack the Equinox servlet bridge and the Equinox http service to not do that (it’s only needed in certain cases). Second, there’s a JRE “whitelist” of classes you can access that can cause trouble. I think this isn’t much of a problem if we define a custom OSGi execution environment for AppEngine. I attempted to do this since in Eclipse 3.5, we support the definition of custom execution environments. However, I found that the current whitelist doesn’t seem to be complete (maybe someone from Google can help). If you solve those problems, you can get Equinox working locally within the AppEngine SDK (as seen in the screenshot above). Here’s a zipped project if you’re interested (see the Equinox OSGi shared launch configuration and just go to localhost:8080/console).

In reality, this is only half of the battle. If we actually try to deploy what we have created above, things will fail. The most complicated problem I came across with running OSGi on AppEngine was you can’t write anywhere to the file system. Equinox and other OSGi frameworks need a place to write its state.  I think we can get around this if we write a custom storage adaptor hook in Equinox that uses the AppEngine storage facilities, however, that’s going to take some effort.

That’s it for now. I plan on making some more progress next week… are there any other people that want to see OSGi running on AppEngine? Have any other people out there been experimenting with OSGi and AppEngine? Did you hit the same roadblocks? Do you want to collaborate?

on Apr 8th, 2009ECF kisses REST

Once upon a time a guy named Roy Fielding made his disertation about a design aproach called REST. From this point REST is getting very popular. Many service provider using REST to offer developers access to their services i.e. Twitter, Facebook and so on.

But what is this REST thing? It’s a way to publish web services without any overloaded technology like SOAP for example. Every REST service is available under a unique URL and can accessed by everybody. Mostly it sends a response using XML but this is different from service to service. To get the idea of REST let’s take a look at an example. There is a realy huge REST example out there. Probably you using it every day – it’s called the World Wide Web icon wink ECF kisses REST

Yes, the web is nothing else as an landscape full of REST web services. Mostly the services response are HTML but as I said before the response can vary from service to service.

The special thing about REST is that it uses a very well known technology called HTTP. Fielding was involved in the design of HTTP1.1. So REST is nothing else as a way to use HTTP the right way. The HTTP methods (GET, PUT, DELETE, UPDATE) are used for the interaction. The benefit for us developers is, that we can use any programming language to access such a REST service.

And why does ECF want to kiss REST? As I said before, many providers already provide RESTful interfaces. So if ECF has a common API to access a REST based web service it would be much easier to implement providers for these services. On this point GSoC enters the field.

soc ECF kisses REST

There is a GSoC project called “REST abstraction for ECF” which is my project for this year. You can read more about this project in my proposal and edit or update ideas. Please feel free to get involved.

The overall goal for this project is to make the Eclipse IDE more social. Sounds terrifying isn’t it? But imagine, you open your workspace and activate a mylyn task which is probably a bug. On the same time the bug id and your name is tweeted on Twitter. So everybody who’s interested in your project can see that you working on a new feature or bug. I think this would be really awesome to improve collaboration. There are many other use cases, if you have any ideas please feel free to add comments. Maybe we can realize it if the project has finished. There is only one hurdle left.

The project has to be nominated. So if you are a mentor for GSoC2009, please vote for this project and on the same time for me. Every vote counts icon wink ECF kisses REST

Thank you all for your interest.

on Apr 7th, 2009The Logic of Collective Action

In the last few days, there have been a number of provocative and interesting posts around the issue of how to maintain Eclipse’s innovation, as well as commercial growth, and project contributions

Bjorn’s – It’s a New World

Doug’s – On the Future of Eclipse

and Michael’s – Eclipse Freeloader Award

There is some long-standing social science/economics work that is relevant.  For example, see The Logic of Collective Action.  Some thoughts from what I’ve read from Olson’s book:

1) Small groups differ from large groups in their incentives for participation

2) Selective incentives/disincentives for participation are sometimes necessary (i.e. different incentives for different group members)

3) Large groups are less able to act in their common interest than small ones

Some of the thinking that’s going on around how to get the EF membership to all act/contribute…in order that all can continue to benefit…and maintain a healthy community…could be informed by this work.

on Apr 2nd, 2009Eclipse Menu Contribution URIs

Since Eclipse 3.3, placing contributions in a menu (via the org.eclipse.ui.menus extension point) has been a bit challenging given the new locationURI attribute:

locationuri 300x97 Eclipse Menu Contribution URIs

While at EclipseCon 2009, I had time to sit down with Paul Webster and hack the menu spy functionality of the Plug-in Spy to spit out location URIs. For example, if you selected the JDT open project wizard, you would get this popup:

spy11 300x131 Eclipse Menu Contribution URIs

Another example is if you selected the Import wizard from the File menu, you’d get this popup:

spy21 300x240 Eclipse Menu Contribution URIs

That URI should be good enough to use for your personal menu contributions. Look for this functionality to appear in Eclipse 3.5 M7 and if you have anymore ideas, please file a bug.

In the end, I hope people find this useful as I continue my quest of introspecting the workbench and making life easier for RCP developers.

on Apr 2nd, 2009OSGi Execution Environment Validation

Execution Environments (EE) are a neat concept within OSGi, however, things can become complicated when developing against multiple EEs. For a real world example of what I mean, this weeks integration build in Eclipse was delayed due to an EE issue. A new bundle (org.eclipse.equinox.p2.repository) was added to the Eclipse SDK that declared an execution environment of J2SE-1.4 but used methods from J2SE-1.5 environment. This is really easy to do when you’re using a 6.0 JRE but developing bundles that should run on a 1.4 JRE. I mean, it isn’t that hard to use a new method from java.lang.String or java.lang.Double that you didn’t know about it.

Well, I’m happy to report that these types of problems should never happen again if you use PDE API Tools. In Eclipse 3.5, the PDE team added support for execution environment (system library) validation. To enable the validation support, simply go to the Plug-in Development->API Compilers Errors/Warnings preference page:

apitoolspref 300x243 OSGi Execution Environment Validation

Now that you have system library validation enabled, you should see cool warnings like this in your workspace:

apitools 300x62 OSGi Execution Environment Validation

All I can say is that I highly recommend you use PDE API Tools if you’re developing OSGi-based applications with Eclipse. If you find any issues or have suggestions, please let the team know by filing a bug.

© EclipseSource 2008 - 2011