Aehso’s Output

Frank Kieviet has two excellent posts that explain the dreaded “java.lang.OutOfMemoryError: PermGen space” error and more importantly how to use some new Java 6 tools to diagnose the source of the problem. The first post in particular highlights a very subtle issue with classloader/reference handling that anyone developing code for multiple-classloader environments needs to be aware of.

Alessandro Ribeiro also has an interesting three post piece where he shows how to use the JDK 1.5 ‘jps’ and ‘jstat’ tools to help diagnose the same problem (hint: “jstat -gcpermcapacity ” will give you a nice summary of the status of the VM with the target PID).

Users have been running into this when running Eclipse-based products on Sun’s JDK 1.5 for some time and Eclipse Bug 92250 has been quietly collating lots of feedback and suggestions from the Eclipse community along the way. A lot of people have been lurking/waiting/hoping that someone would identify the source(s) of the issue and produce a fix so it is good to see increased activity there. However, the recent debate about whether this is a Sun or Eclipse (where I found links to the above blog posts - thanks Karsten!) issue might be a little discouraging but it appears there is acknowledgement that some responsibility lies within the Eclipse community to help diagnose the problem.

I’d imagine many adapters would be willing to lend a hand in diagnosing this since it is a potential stability issue for all Eclipse based products when run on what is the de-facto Java VM. However, I suspect any such analysis effort would need to be done in coordination with some platform/WTP folks since they would need a good insight into the expected behaviour of all of the active bundles to be able to determine which are at fault (or if indeed the fault lies with the VM)

What intrigues me about this issue is that Eclipse/Equinox doesn’t normally destroy classloaders so classloaders not getting garbage collected can’t be the source of the problem. But with that assertion, how can any application be hitting a 512Mb permGen limit? It does smell of a VM bug but then why doesn’t it happen with other Java based applications? Clearly some feature common to many Eclipse applications is rubbing the Sun VM up the wrong way.

I guess the only way to find out is to do a very deep analysis but a pre-requisite for that is to find a simple use case that can reliably and repeatedly reproduce the problem. We don’t seem to have one with our product but perhaps someone else out there does.

I’ll not be at EclipseCon this year (it conflicts with polishing our next major product release this week) but if I was there I’d be going to any sessions related to the new Rich Ajax Platform (RAP) incubator project. Think the Eclipse UI running in your browser, with the Eclipse application, developed as plugins, running remotely on a web server.

The Yoxos Eclipse On Demand online Eclipse distribution builder is a good example of the types of applications this framework could support. In fact, given that Yoxos is run by Innopract, the folks who are driving the RAP project, it is probably the best example out there. It’d be interesting to find out how far along they are with their RWT API implementation - attempting to build a remote client framework based on a local client framework like SWT is perhaps a dangerous thing to attempt to do but we’ll see how they fare.

(Not to be confused with the WTP 2.0 AJAX Tooklit Framework (ATF) incubator project or the Google Web Toolkit (GWT) which are designed to also support development of AJAX applications, albeit using other frameworks and user interfaces…)

There used to be an age-old restriction in Eclipse whereby two projects couldn’t be imported into the same workspace if the project locations overlapped in the file system. So if you had a project hierarchy like

Then you couldn’t have a workspace that looked like this:

I say ‘age-old’, because (obviously) somewhere along the line this workspace restriction was removed, maybe at the behest of WTP - I’m not sure, I can’t find the related Bugzilla entry (UPDATED: John Arthorne has indirectly pointed me to it - Bugzilla 44967). I only noticed last night when I was just about to blog about how nice it would be to be able to do this. It would appear I am very stuck in my ways - until now I’ve always used separate workspaces to work on the my top level projects and that doesn’t sit too well with trying to use Mylar.

By top level projects I mean a simple project (with no builders/natures) that contain the Ant/PDE build scripts and multiple sub folders, each containing a set of projects (plugin or plain Java) that represent the modular components of our products. These projects are usually big, whole CVS modules in fact, but by synchronizing them with our CVS repository we can easily detect build script changes that might require us to do a little more than re-build each plugin project in our workspaces in order to pick up all of the latest changes.

There is one trick to using this arrangement. Always make sure that you put at least one non-project folder in between your top level project and the contained projects. That way you can check out the top level project, and then point the Eclipse Import “Existing Projects…” wizard at the intermediate folder and it can auto-import all projects found in sub-folders. If you point it at the top level project it will do nothing, thinking you already have that project in your workspace.

Anyway, this is all great good news for anyone who wants to use Mylar with a project arrangement like this since it means that if you need to tweak build scripts as well as plugin source code (which I very frequently do), then you can do it all in one workspace and Mylar will keep track of everything you are doing . This is great for building change sets, especially so for committing changes back to CVS!

There is one caveat though, but only if you check your projects out into your workspace folder folder and I think a lot of people do this. If you try to subsequently use the New Project wizard to try create a “contained” project (like the ‘inner’ one illustrated above) then you will hit a problem. When you deselect the “Use default location” check box for the second (contained) project, the wizard will flag an error claiming that the “Project contents cannot be inside workspace directory”. I have no idea why it does this since this the suggested default is in the workspace folder but it’d be nice if the platform guys could fix this. It must be a trivial fix, I’m guessing it’s doing an indiscriminate “location.startsWith()” validation check on the string or something (see Bugzilla 165336. (UPDATE 2: it looks like the UI bug is fixed for 3.3 - see Bugzilla 147727)

A workaround is to create the project elsewhere, delete it from the workspace (but not it’s contents), move it on the filesystem and then re-import it into the workspace…

Happy New Year to your all and a belated Happy Christmas to those I didn’t get to share festive pints with! I should be back blogging a bit more frequently now - prior to the festive break I had my head down getting the Cape Clear 7 Studio Beta release (What’s New) out the door on time so it’s been a bit quiet around here. Kudos to our team for producing such a polished beta release in such a short period of time!

So now we are in sync with the Callisto train, that opens up more than a few possibilities, some of which we are already working on. Thanks are also due to the folks at Eclipse.org, they have been great at dealing with the bugs we logged while migrating from WTP 0.7 to WTP 1.5 and through our use Eclipse, PDEBuild, TPTP, BIRT and various other pieces in our build and test harnesses. In one instance I think I can remember a patch being committed within an hour of the original bug report being received!

Onward and upward, time to catch up on what has been happing in the technology world for the past month

On the AccuRev homepage they state:

AccuRev supports open standards and SOA-based development tool interoperability across Microsoft Windows, Linux, and UNIX platforms.

(emphasis mine)
I have to admit, this piqued my interest (actually my initial reaction was ‘wtf?’ but I digress).  Searching to figure out what SOA-based development tool interoperability is, I am now guessing that this is a reference to the Eclipse ALF (incubating) project.  ALF is a CruiseControl type framework that integrates various commercial SCM repositories, build management, testing and code scanning tools etc. via a BPEL-based orchestrations that control the overall “Application Lifecycle Framework”.

Unfortunately, ALF appears to be getting no love from the big players, which is a bit of a shame as we could all do with something a bit more sophisticated than CruiseControl+Ant for integrating and controlling large scale builds.  A Web Services API integration is, I think, a valid way to tie these types of systems together.  

After reviewing the ALF demos, I am actually a little surprised that the entire scope of what ALF is trying to achieve is managed under the Eclipse.org umbrella.  I can see a place for an ALF tools project in Eclipse.org certainly but I am surprised that the whole ALF server-side architecture appears to be being designed and developed in the same project.  I really don’t really see the connection between Eclipse.org and the design or implementation of service interfaces like the ALF Event Manager WSDL.  Projects like STP and WTP for example work to integrate with open standards like SCA and JEE but ALF does not seem to have that type of clear seperation between tools and target runtime implementation. 

Perhaps I am missing something but a recent interesting discussion on the eclipse.technology.alf newsgroup (Subject: Upcoming validation release review) raised these and other related concerns about the scope and deliverables of this project seems to re-enforce this observation.  It will be interesting to see how this all pans out.

Sun’s GPL’ing of Java SE, Java ME and Glassfish is definitely interesting - Tim Bray has some interesting commentary from the inside, no doubt slightly sanitized! Kudos to Sun for going GPL, thereby enabling it to be shipped with the GNU/Linux distributions. I am sure there are those in the OSS community who will remain suspicious.

Plenty of other questions yet to be answered, the governance model of the new OSS projects will be critical - it’ll be interesting to see that is set up (Eclipse.org style perhaps?). Interesting to note that Sun are retaining the TCK code (to retain control of Java brand compliance) and they are not changing the JCP. The latter decision is very interesting as if the specification process is still tightly controlled by Sun then that leaves limited latitude for the implementation project to go in other directions.

Once the dust settles, Java ISVs around the globe should be ready to re-validate their software platforms and distributions. Questions now exist about the viability of some GPL-licensed J2SE, ME and EE projects and their future viability. It is bound to impact Apache Harmony , a project largely driven by IBM (who predictably have reacted by suggesting that Sun should contribute their Java technologies to Apache.org - haha). And no doubt this will make GlassFish more competitive with JBoss. I’m sure this also impacts the ME space - interesting to note that the GPL nature of the license means any derivatives for other embedded platforms also have to be GPL’ed.

Interesting times…

To compliment the HTTP EFS plugin I created a while back I have created a simple “New Link” wizard extension that can be used to create link resources in projects. Manually adding linkedResources elements to the eclipse project descriptor (.project) file is no longer required!

The wizard page implementation class extends org.eclipse.ui.dialogs.WizardNewFileCreationPage (the standard New File wizard page) and just adds an extra control at the bottom to prompt the user for a target URI location. Thanks to the platform ui folks for designing thar page class in such an extensible way.

Plugin source and binary available at Cape Clear Developer.

At Cape Clear we use PDEBuild, controlled by CruiseControl driven Ant scripts to build our Eclipse features. As Oisín Hurley pointed out recently it has got a steep learning curve but once it is up and running it allows development teams to contribute to features by doing what is natural - using the Eclipse workbench tools to create and modify plugin projects.
Where PDEBuild wins big time is in eliminating redundant build metadata in your build system. The developers workbench is in sync with your build server because they both work off the same Eclipse project metadata. About the only pilot errors that trip up our builds occasionally are

• missing entries in the plugin/bundle build.properties files cause PDEBuild to leave resources out of the packaged jar (or folder). Unfortunately these missing resources don’t always get noticed until runtime. e.g. missing icons showing up as red boxes because the icons didn’t get packaged.
• missing entries in the PDEBuild map file cause PDEBuild to fail to resolve bundle dependencies. If it can’t find the source it can’t build the bundle!
• missing entries in the feature.xml (for a newly contributed plugin/bundle). PDEBuild will only build the plugins listed in the feature!

That’s all well and good for us Eclipse plugin developers. But what about building other types of projects? Headless builds of Java projects (not plugin projects) can be achieved by using the AntRunner application entry point in conjunction with an Ant build script. Unfortunately the Ant script needs to be pre-generated (or hand-written) so one end up back in the situation where the Ant build script can easily get out of sync with the project metadata. For large project sets (>10) this type of duplicate build metadata is difficult and frustrating to maintain.

The issue becomes larger when one considers that many Eclipse based products implement additional natures and builders that they add onto the projects they create. For example, a builder might need to generate some java code or verify spring configuration files). Theses projects need to be built inside Eclipse (since the builders are workspace/workbench dependent) but currently there doesn’t seem to be any facility to do so in a headless manner. I’m thinking along the lines of an application entry point that can perform the following tasks:

• Optionally import a set of projects into the target workspace
• Optionally clean all projects
• Build all projects in the order determined by the declared project dependencies (in the project descriptor), running all builders as it would if the Workbench UI running.
• For each project optionally execute an action (supplied by a plugin in the workbench) that packages the build output into some external format (e.g. generating a WAR file from a WTP Dynamic Web project, generating JavaDoc from a Java project etc).

The last one above is a ‘nice-to-have’ since the invoking script may well be capable of finding the build output and packaging it using pre-defined rules.

Does anyone know of such a beast? Or is any effort underway to produce such a beast? Bugzilla doesn’t seem to have anything relevant which is a surprise.  This seems like an awfully useful feature for the Eclipse platform to support…

A while back I mentioned I’d be creating a HTTP EFS plugin. I finally got around to uploading the source (licensed under EPL) and a binary build onto Cape Clear’s developer website.

Note this is only a first cut but feedback is more than welcome to john.oshea@capeclear.com

The spammers are getting deperate for Eclipse developers attention.

Date: Wed, 30 Aug 2006 02:10:10 -0700 (PDT)
From: wen fengli <wenfengli2007@yahoo.com>
Subject: No 1 in US and China?
Lawsuit maker wenfeng li used to declaim to be NO.1 business software vendor by 2006.Right now,he can declaim that BIRT to be NO.1 business intelligence software by whatever year he want to be. As long as he continue to grab big check from Actuate, he can declaim whatever he want to declaim.
Wenfeng li's business strategy is that let's do it. Let's hire more people and get rid of people I don't like quickly. Eventually, let's add version number and declare a success.
The trend is "Express". Let's call it BIRT Express next year.

Or that could be the most cunning and devious business plan I have ever seen (’excellent’, as Mr Burns would say). Watch out BIRT competitors!