A while ago, I wrote a post about setting up the JDE Eclipse Plugin, which extolled the virtues of the JDE Plugin for Eclipse. As I said then, I’d been using Eclipse for BlackBerry development for years (using custom Ant scripts, etc) but the official RIM Plugin for Eclipse was relatively new. I’ve now used the plugin for a few more months, and, while I still believe it’s the best way to develop BlackBerry applications, I’m also less in love with it than I was. Basically, the JDE’s built-in editor is still pretty hopeless, lacking what should be considered rudimentary features at this point, and so even with its quirks, it’s better to work in Eclipse.
But - there are some pretty significant quirks.
Big ones that I haven’t found good workarounds for include:
- src is the only ‘officially’ recognized source folder. I don’t know why or how RIM overrode this, but the bug is: You can set any folder to a source folder (as with any Eclipse project) and things will work, until you shut down and restart Eclipse, at which point only src will still be a source folder. The workaround is to manually re-add your source folders to the build path each time you restart Eclipse (which may not be that often) which works, but is obviously not great (read: very, very annoying)
- you can’t add 3rd party .jar files to a BlackBerry project in Eclipse (mentioned here). The only way around this is to use source files (for KXML/KXML-RPC, the most common one I’ve seen, source is thankfully available, though you have to dig)
- importing from a .jdw (BlackBerry JDE Workspace) file is broken - you get a bunch of symbolic links to your files in your Eclipse project. Just means you have to rebuild your project, making the Import feature pretty useless.
There are others, but you get the idea
Don’t let these scare you away (unless one really is a showstopper) - Eclipse is still the best way to go.
Now, here’s my suggestion for fixing things:
Open source the BlackBerry JDE Plugin for Eclipse!
That’s right, open source it. Please. Listen, RIM, if your’e reading: There’s a big and growing community of BlackBerry developers yearning for a better way to build BlackBerry apps. And you have very strong competition in the form of iPhone and Android, both of which have stunning development environments. They both came to the game late, and they’ve leapfrogged you, and you’re falling further behind.
You don’t have to make it GPL or even LGPL. Something less idealistic would be fine. You don’t even have to open-source parts of the Plugin that we know work (like RAPC). Just as much as you can, as soon as you can, so some enterprising BlackBerry developer out there with good knowledge of the Eclipse platform (and believe me, there are enough) can figure out what’s wrong and FIX IT.
Thank you!
12 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
Thanks for that post - I includes many things I always wanted to say about the Eclipse JDE plugin!
I have to say that the latest Beta is better than the first one but it still has many problems. One of the biggest for me is that it is not possible to use OS 4.2 libraries with the latest plugin.
Ah yes, I’d almost forgotten about that - still hits you even when you’re trying to target just all existing trackball devices (Pearl and better).
I have to say, i have been using eclipse for about a month and a half now, i had some issues including resources, and honestly, i’ve been debugging in the JDE, thought that might change in time.
Not sure when this happened but there is now a 4.2.1 component package for the eclipse plugin!
http://na.blackberry.com/eng/developers/javaappdev/javaeclipseplug.jsp
Installing it now!
Anthony,
You should post a sticky blogpost to accept article suggestions.
I’m a beginner to Blackberry APIs and I’ve learnt so much from your website. Keep it up.
Article idea: investigate the intricacies of making connections (Socket/HTTP) answering questions like what is this deviceside=true/false business, properties of a good network app (to support the myriad connectivity options) etc..
thanks @Tony - I did not see that 4.2.1 component pack, downloading it now
Ok, so here’s a funny Eclipse quirk, though I’m somewhat new to BB dev so could easily just be me!
I’ve been having trouble when using the Eclipse 4.5 component pack where sometimes the simulator always seems to run an old version of my code. Even something as drastic as commenting out entire methods does not affect my app when launched on the simulator, as if those blocks of code were never commented out. Frustrating!
I’ve verified no compile errors, and I’ve tried simply deleting the (project)/bin folder then rebuilding - no change. I ran the “clean.bat” program in the plug-in’s folder, but now my app icon is never added to the simulator when running or debugging. Twice as frustrating.
So now I have two issues:
1) I’m currently blocked from further development until I can get my app’s icon back on the home screen of the simulators.
2) Once the above is fixed, how can I ensure that my latest code is correctly compiled and loaded into the simulator?
I’ve had significantly less challenges designing mobile web pages within Visual Studio 2008, but I need to get just as comfortable with the BlackBerry JDE plug-in for Eclipse! Thanks for the help!
Update! I resolved my issues by checking out my .jad file from source control. Apparently, the IDE does not automatically check that out when building/debugging, and the read-only bit was causing the .cod file to never be generated.
Hope this helps somebody else!
I have the same problems as Grant, just that I am not checking out the code from SVN but developing the app in the Eclipse plug-in. And after running the clean.bat, rebuilding my app number of times, I still can’t generate the cod file (and not get my app on the simulator!) Help! :s
Thanks for this article…and God I hope they listen to you because Im having a really hard time to add 3rd library jar files to my app and its a required issue. If anyone knows how to do this without having to make another .cod or a way to specify another cod in the jad file I will apreciate it (I did this but still I was asked for the library project).
What RIM needs to do is discontinue their clunky JDE IDE and direct all of their efforts in making the JDE plugin for Eclipse flawless. I have wasted too much time trying to find the best work around for the issues you mentioned above, and I truly hate having to perform these hacks. I truly feel that RIM will have a hard-time winning back developers once Android trumps their position in sales.
Continuing the Discussion