BlackBerry JDE Plug-In for Eclipse 1.1 Beta - Part 1

The BlackBerry Developer Conference (Nov 9-12 in San Francisco) contained a lot of new announcements - among the bigger ones (Payment Services, Advertising Services, etc) one of the most exciting - from my point of view - may have been overlooked a bit. A new version of the BlackBery JDE Plug-In for Eclipse - v1.1 - as of this writing in Beta.

Being a huge fan of Eclipse for BlackBerry development - despite numerous problems - I was eager to try out this version. I discovered a few interesting quirks, but overall a much more solid development experience.

Installation

Installation is significantly easier with this version, mainly because the Eclipse Update Site for BlackBerry now seems to be working properly (some people were able to use it fine with v1.0 of the plugin, but I never did get it to work). The Plug-in ships with v5.0 of the JDE by default, but you can easily add 4.2.1-4.7.1.

The installer is available on the developer zone (http://www.blackberry.com/developers) - newly redesigned (and in a way which does make things easier). Click on development beta software on the left hand nav bar, the download is right there.

This version of the plug-in runs on Eclipse 3.5 Ganymede (1.0 ran on Eclipse 3.4) available free from eclipse.org/downloads. Not much difference between 3.5 and 3.4 in my experience (I’m sure the Eclipse team would beg to differ) aside from a few things in different places, including the software updates feature, which we can use to get older JDE versions installed with the plug-in.

The basic installation process itself is self explanatory - just run the wizard and follow the prompts - I won’t go into details.

Installing older JDE versions

JDE 5.0 is great, but is only shipping on a few devices right now, so you’ll likely need to get at least one of the older versions. You can do this by going to Install New Software from the Eclipse Help menu. Click the Add button and enter http://www.blackberry.com/go/eclipseUpdate/3.5/java in the Location field for the Add dialog. Then name the site something meaningful (RIM suggests BlackBerry Java Plug-in Update Site, I just used BlackBerry Updates):

Adding the BlackBerry Update Site

Once this is done and you’ve clicked OK, you’ll see a list of the JDE versions available from the site. I just selected all - figuring that I might as well get everything over with at once:

Selecting the earlier JDE versions

Click Next and then Next again, accept the license agreement and let the downloading commence. A warning - this is not a fire-and-forget installation: You will be asked for your developer zone login (email and password) and not right away, so at least make sure your computer is in sight so you’ll see the dialogs (yes, one for each JDE version) when they pop-up. You’ll also be asked to restart Eclipse when finished. It only takes a few seconds, so definitely a good idea.

Ch-ch-ch changes

If you’re familiar with the earlier JDE Plug-in, a lot of things have changed - pretty much all for the better, and all much more in keeping with the Eclipse way of doing things. I’ll go through the list that I’ve seen so far. I was tripped up on some of these - maybe I just don’t read documentation well - but hopefully I’ll save someone else the trouble.

Difference 1: Project-specific JRE versions

You now specify a different version of the JRE (Java Runtime Environment - basically the JDE) for each project in your workspace. This is a cleaner implementation in many ways, and probably more in keeping with Eclipse, but can be a bit annoying - after all, if you have more than one project in one workspace, don’t you often want to have them all running on a simulator at once? Ah well. There are a couple of places where you can specify this. First is in the new project dialog box:

Create a new BlackBerry project by clicking File->New->Project... and selecting BlackBerry Project. You’ll notice a field called JRE Version which is pre-populated with BlackBerry JRE 5.0.0. All of the JRE’s we selected from the BlackBerry Update site are available here:

Selecting the JRE version for a new project

What about changing the version for an existing project? I had a little trouble finding this (anyone else?). It’s available in a couple of spots, but the easiest one that I’ve found is right clicking the JRE System Library item under your project and selecting Properties:

Right Click JRE System Library and select Properties

The properties dialog box will allow you to select a different JRE/JDE version:

The JRE System Library Properties dialog

Difference 2: Location of resources in a compiled application

A huge fix in this version of the Plug-in is that folders besides src now work correctly all the time for source & resource files! In fact by default there’s a res folder in every new project for your resources. So to emphasize, I’m much happier dealing with the following quirk than the way things existed before - and great job RIM for fixing this.

The problem is that stuff placed in these folders ends up at the root level of your COD file. That is, if you have a setup like the following, with an image under res:

An image under the res folder

The following code (which may have worked under the older plugin):

		Bitmap bmp = Bitmap.getBitmapResource("res/icon.png");

		// bmp is null, so the following will throw an Exception
		int height = bmp.getHeight();

Will now cause problems, because res/icon.png will not be found. Instead you have to load the image from the root:

		Bitmap bmp = Bitmap.getBitmapResource("icon.png");

		// this works now
		int height = bmp.getHeight();

Just something to get used to - and you may want to update your build scripts according to the new reality.

Difference 3: Verification Errors

This one really tripped me up - there are some differences in the way things are compiled and/or run on the simulator with this version, which can cause obscure verification errors. While I’m sure several things can cause this, the problems with my applications had to do with using the Java class keyword in certain ways in static contexts. Specifically as a parameter to another constructor seemed to cause problems. I’ll illustrate:

One of our apps, Super Baby GO, uses a pattern similar to the following (admittedly rather contrived) example:

public class HelloWorldMainScreen extends MainScreen {

	static String className;

	static {
		className = new String(HelloWorldMainScreen.class.getName());
	}

This did work in previous versions, and causes no problems on device (when built using Ant for example). When deployed and run in the simulator from the 1.1 Plug-in, you get a RuntimeException with the message Verification Error 1756 at some offset (the offset changes depending on your program):

RuntimeException Verification Error 1756 with the BlackBerry Eclipse 1.1 Plug-in

Some hint to what causes this can be found in the simulator Event Log (hold the CTRL key on your keyboard and type L G L G). Look at those VM:VECMm, VM:VECCs etc. lines. They tell you where the error happened (in this case I’ve already given it away, it’s in the static class initializer - represented by clinit below):

The Event Logs around the Verification Error 1756

The problem is that using the class keyword as a constructor parameter in a static (class initialization) context causes problems with this version of the Plug-in. Fortunately this is easily resolved by using a temporary variable:

public class HelloWorldMainScreen extends MainScreen {

	static String className;

	static {
		String strClass = HelloWorldMainScreen.class.getName();
		className = new String(strClass);
	}

No significant problems doing this, the real time-waster for me was figuring out what caused this in the first place!

There are still a few things to talk about, including differences to debug configuration setup, and signing key management, but I’ll leave that for another post on another day.