How to use rapc from RIM… dirty details!

What’s really going on in rapc, Blackberry’s crazed compile tool? Let me begin by telling you that everything you’ve read until this point is not entirely accurate. There are those that will tell you that you have to run preverify.exe prior to running rapc. Then there are those who will tell you that the bb-ant-tools are sufficient. There are people that complain that the RIM compiler has bugs in it. (This may be true but I’ve so far been able to fix broken builds by using all of the advice I’m including here.) I’ve also found a blog that claims you can build from non-Windows operating systems. I’ve read in some places that either WTK or the JDE must be in the PATH so that rapc can find a preverifier. While some of these tips, tools, tutorials work they all have limits. Eventually you’ll find your application either throws random NPE’s, verification errors, or infinitely reboots the device! Now pay attention!

Now let me explain my project. I have a little bit of dependency injection going on via source generation. Then I also have some external jar dependencies. All of this creates a bit of a challenge for basic rapc invocation. In order to generate my midlet cod file I need to:

  • Run a source generator
  • Include the generated source in my list of things to compile
  • somehow include my external jar dependencies in the compile.
  • Include resources in my compiled output
  • Pick up my suit from the cleaners
  • Get the entire thing to run on my Mac?

While the last bullet is entirely optional and irrelevant, I include it because its the only way to get completely familiar with rapc. That is, if I can meet/greet/beat the challenge of cross platform compilation of Blackberry then I’ll really understand the intracacies of compiling with rapc. Now onto the juice.

How Rapc works… I think…
There are various approaches to compiling Blackberry applications that I know of.

  • Compile your app against the MIDP and CLDC APIs (include either WTK or MPowerplayer or someother party’s midp and CLDC jars on your bootstrap classpath for javac… making sure you use javac1.3 or below), preverify with JDE preverify.exe (found in %JDE_HOME%/bin), jar and finally compile with rapc.
  • Compile your application source files entirely with Rapc.

The first option has problems because there’s the possibility that javac will generate class files that will cause verification errors or (as my team discovered recently) the white screen of death when loaded onto the device. The second option has problems because it’s very tricky and prone to the same errors unless you are very dillegent. It took a lot of head banging and trial/error to come up with these details so read closely.

How do we use rapc? This is the question that still plagues me. There’s little documentation around the nuances you’ll encounter when invoking the rapc compiler from the command line. The rapc compiler is an executable (.exe) file in the JDE install directory living under the bin subfolder. First thing to note is the rapc.exe just delegates everything to rapc.jar. That means the same exact command line parameters you would use with rapc.exe will work with rapc.jar. (Call the jar with the “java -jar” command.) The most important thing to understand is that you cannot mix and match. That is you cannot use the output of javac/WTK preverify to fuel rapc. Furthermore you need to pay strict attention to the version of the JDE you use because it must be the same (or earlier) version of your target platform. For eg., if you intend to target Blackberry devices running a 4.2.2 OS you should use the compiler tools from the JDE version 4.2.2 or earlier. If you don’t pay attention to this step your product will work just fine until it’s time to ship… at which time you’ll experience weird, impossible to track/reproduce on a developer workstation, errors. There are other important tools in the JDE that you’ll need as well. The preverify tool is required (unless you’re using JDE 4.3.0 and targeting OS 4.3+) as well as the SignatureTool.jsr. Finally there is the net_rim_api.jar which lives under the lib folder in the JDE install directory. The next big thing to understand is the command line options.

Use the import= to specify the location of the net_rim_api.jar. This flag takes the relative or absolute path of not only the rim APIs but any other jar or cod dependencies your application has. (I haven’t tried cod dependencies but the docs say you can list cod files.) Be careful because this is only for resolving dependencies. Anything you list here will not be included in the final output cod. What this means is any jar files listed here must either be compiled as separate cod libraries or their source files somehow inlined in the final compiled. Dependencies listed here are scope as provided. In other words it is assumed they will be made available at runtime by either the RIM platform or by some pre-installed package.

(codname for 4.3.0+)
This parameter threw me for a minute when I attempted to roll back to an earlier version of the RIM compile toolchain. I believe (and I need to double check and update this fact later) that rapc version 4.3.0 and higher expect a codname flag while versions prior to 4.3.0 expect a codename flag. The value you specify here will be the value used in the output codfile name. Paths can be relative to the working directory (the folder rapc is called from) or possibly absolute paths. For instance if you give build/MyApp as the value then rapc will spit all of its output into the build folder relative to the working directory giving you a final MyApp.cod file there. (you’ll also have MyApp.jar, MyApp.csi, MyApp.debug and other files in this folder.)

This is the application type. Use this flag if you plan to develop a J2ME spec compliant midlet. Blackberry support another application type, cldc, which provides RIM specific features (more on that in possibly another post) and is specified by the mutually exclusive -cldc flag. A You have to -midlet or -cldc to specify which kind of application you are building.

Use this flag if your are building a CLDC application that adheres to RIM’s proprietary launching interfaces. CLDC apps offer abilities to run in the background and be started at device boot time. There are other hidden gems here that I’d have to get into with another post.

Use this parameter if you have a JAD file that includes your application’s meta data. This parameter is optional as you may substitue a .rapc file to include the meta data. Application meta data includes things like the icon to display on the desktop, the midlets contained in your aplication bundle, runtime properties, etc. Referr to the J2ME midlet spec for more detail.

rapc file
This would be the path to a “.rapc” file that includes meta data about your application. I’ll probably follow up with another post to explain the details behind this proprietary RIM spec. While a JAD file also includes meta data there are certain properties that can be included in this file that cannot be included in the JAD file and vice-versa.

class or java files
The last parameter should specify either a jar file containing the compiled classes or be a list of the .java files you intend to compile. Here’s where rapc gets really interesting. If you precompile your “.java” files you had better be certain you run the RIM preverify tool against these class files prior to invoking the compiler. Also I will repeat that you must use the same (or earlier) version preverify as your target platform. For eg., if you intend to target Blackberry devices running a 4.2.2 OS you should use both RIM’s rapc and preverify tools from the JDE version 4.2.2 or earlier. If you don’t pay attention to this step your product will work just fine until it’s time to ship… at which time you’ll experience weird, impossible to track/reproduce on a developer workstation, errors. (I said this before didn’t I?) Rapc is very picky here and the behavior varies between versions. It first calls out to javac assuming that the Java compiler is in the PATH. It then passes the output from javac to preverify. Note that in JDE 4.3.0 both “.java” source compiling and preverification is done from within the rapc.jar while earlier versions of rapc call out to the command line using the command “preverify” (not “preverify.exe”… this is an important distinction) and passing standard preverify parameters. Finally it creates the final “.cod” that will run on the device. What is included in the cod file depends on what is passed on the command line and what’s available from the working directory. For instance, your application icon (and I found this through trial and error) must be locatable from the working directory unless you specify an absolute path in the jad file. If you compile a jar file (not recommended for rapc prior to 4.3.0) then everything in that jar file (images, multimedia files, application resources, etc.) will be included in the final cod file. If you compile “.java” files directly from rapc then no application resources will make it into the final output cod file, only the compiled .class files will be there (along with the application icon specified in the jad if it can be found from the working directory). It took a lot of banging my head to figure this out. Finally instead of a jar file or space delimited list of “.java” files, you can specify a text file that lists (new line delimited style) all of the “.java” files you wish to pass to the compiler. This is a potential work-around to command line size restrictions that may be present on some versions of Windows. This file should be given with an @ prefix. For eg. if your have a MyApp.txt file then the last parameter for rapc will be @MyApp.txt. This is the preferred method of giving files to rapc because as your application grows so will the list of files.

One last got’cha I found was with trying to use rapc.jar directly instead of rapc.exe. If you are running a JDE earlier than 4.3.0 then you’ll get into trouble here because there is a secret parameter passed from rapc.exe that RIM won’t tell me about. Because the command line syntax for the jar is identical to the command line syntax for the “.exe” you can almost get away with it but because of a secret exchange happening between the Jar and exe you’ll get undefined behavior and weird errors in certain circumstances. This last gotcha is what makes it impossible to compile on an OS other than Windows while targeting a RIM OS earlier than 4.3.0.

In the end I’ve determined that it is not possible to accurately build a blackberry application on an operating system other than Windows. Also while there may be some truth to the myth of bugs in rapc I believe it all boils down to a bunch of nasty assumptions the RIM developers made during the design. (they assumed everyone would be so thrilled with their Swing based IDE that they would throw away Eclipse/Idea/Netbeans and burn their Macintosh laptops in celbration of the obviously superior RIM tool chain.) I do believe that if you pay close attention to the details outlined above you can diagnose most preverification and random erros you may be suffering from. I plan to revist this topic in the future as I’ve taken a break from mobile and begun work on some other things. However I do not plan to let rapc defeat me entirely. Keep an eye out because I’ll likely be updating this very same post with more details.

43 thoughts on “How to use rapc from RIM… dirty details!

  1. This is great stuff, Cliff – thanks a million for posting it!

    One (further) point of clarification, CLDC itself is actually a “super-spec” implemented on both RIM and MIDP devices. It contains interfaces to the various connection, exception, object, and stream interfaces. Why on earth it’s called the “cldc” flag is beyond me… though I guess having a “rapc” flag within an executable named “rapc” woulda been pretty confusing too.

    In the next JDE release, I vote they rename it “Steve”.

  2. Good one cliff,

    Also note (and I saw on RIM’s forums many ppl have this unanswered problem) that when you specify -midlet, your original jad does not get populated with the COD links like RIM-COD-SHA1, RIM-COD-Size, etc

    You MUST specifiy -cldc to get this. If you want to deploy the app OTA, then this is important!

    Lick my RIM

  3. That’s a new one on me! We use “-midlet” all the time (never even tried -cldc) and the links are always set. There must be something else going on. We deploy OTA without issue… that is, until the verify errors start reminding us that we have an incorrect version of something somewhere in our toolchain!

    Here’s another trick that I learned from building my Blackberry Maven plugin…
    RAPC creates a jar containing everything from the cod in the same folder. You can run pack this jar with additional resources and run it back through rapc only after removing the generated files that rapc sticks in the root of the jar. These are the *.csi, *.cso files.

    I swear one day after I perfect the art of cloning, I’m going to sit one of me down and finish then release the plugin… then sit another one of me down and finally nail down how to test drive a mobile app from start to finsh. I’ll need one more “me” to write the blog post about it.

  4. Hello Cliff, good advice about the problem with the application icon.
    We are developing an application for the Blackberry and using Eclipse and Blackberry Ant Tools. We have the problem how to include images for the application (both application icon and other images as for ImageItem). Could you please post some sample build.xml files (or mail) to show an example and note how the structure has to look like? It seems to us that the images are not included in the .cod file. Thank You very much, we appreciate your help, as we don`t find the solution by ourselfs.


  5. Yes Barry, images are a big problem. I’ll probably follow with a post of my Blackberry GMaven plugin source that wold illustrate how I address the problem. The secret is a two pass compile. As I hinted in the post just above yours, rapc creates a jar mirroring the cod in the same folder. Take this jar and update it with the images, then remove the .csi, and .cso files from te root of the jar. Finally pass the jar back to rapc to create the final code with images in place.

  6. Hello Cliff, we found another problem today, maybe you know about this issue as you have much more experience.
    As mentioned earlier we like to develop an Blackberry application, and we use Eclipse as IDE. We will not use the RIM API but J2ME (MIDlet).
    When we start the application with a simple form and some items (CustomItem) in the Blackberry Simulator you can’t see what item is currently selected. If we take the same application and use Eclipse ME and start it in the WTK Emulator it works, the selected items have a border to indicate that an item is selected. Is this only a Simulator problem? Thank You!


  7. Well I had another read (this time very very slowly) through this article and came to this command:

    “c:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\bin\rapc.exe” -import=”c:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\lib\net_rim_api.jar” -codename build/helloworld.cod -midlet jad hello.jad jar hello.jar

    but got this error:
    I/O Error: C:\test\build\helloworld.cod (The system cannot find the file specified)

    I even tried “-codname build/helloworld.cod”, but got the same error.

    This article is excellent but how about some examples? or pictures?

  8. this works however (not tested on phone)

    “c:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\bin\rapc.exe” -import=”c:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\lib\net_rim_api.jar” -midlet hello.jad hello.jar

    the result is hello.cod, cso, debug

  9. this command builds also fine AND your orginaljad is now populated.

    “c:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\bin\rapc.exe” -import=”c:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\lib\net_rim_api.jar” -cldc hello.jad hello.jar

    jad now has these extra:

    RIM-COD-Module-Dependencies: net_rim_cldc,net_rim_xml_org
    RIM-COD-SHA1-2: ec 2d 51 99 5b 13 90 f4 6d 7c 46 e3 73 0f fd 7d cd 2e fd 4a
    RIM-COD-URL-1: hello-1.cod
    RIM-COD-SHA1-1: a3 83 d6 fd 10 3e 27 d2 76 0a 24 26 47 2a 9f 96 b5 93 ed bb
    RIM-COD-Size-2: 69492
    RIM-COD-Size-1: 64804
    RIM-COD-Module-Name: hello
    RIM-COD-Size: 83236

  10. Got it!!!!!

    “c:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\bin\rapc.exe” -import=”c:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\lib\net_rim_api.jar” codename=build/helloworld.cod -midlet hello.jad hello.jar

    Note that it is “codename=” and not “-codename=” so the rapc documentation is wrong when refering to page 263 of the “development guide for BB 4.3”

    the above command will build for -midlet AND populate your jad with the COD links goodies. Note this is 4.3 I’m going to frame this on my wall.

  11. Yes, that’s right. There were some minor differences between versions of rapc and I kinda remember the optional dash in front of the flag thing. I didn’t know it would cause errors in certain cases. I was going to suggest making sure the build folder was created because sometimes these commands aren’t smart enough to create them on the fly. Thanx for the comments. I promise when I get a second to breath I’m going to revisit the topic and update my article with actual command examples. I’ve been bouncing between projects lately and finding hidden secrets in other things like JQuery, and Ruby-Cocoa. (This morning I was playing with Selenium and finding my way.) I gotta get my focus back.

  12. I have used the rapc in the way you describe above to create a midlet. However, the JAD files doesn’t contain the RIM-COD… meta data which is mentioned above when a CLDC Cod file is produce. Is the JAD file needed for midlets? My midlet works fine in the simulator – How would I do OTA without a JAD – just download the COD (assuming that I have to break the COD up first into sibbling COD files)?

  13. Hi,

    I am not using ant task, just .bat file to automation the build. How can i generate .alx and .rapc files on command line?

    Thanks. A.

  14. The whole BB toolchain is a disaster. It’s both low quality and undocumented. One just has to look at all the misinformation, strange believes and unsupported myths around the net. For example a document on the j2mepolish web site, even though they must really know a lot about java, suggest removing unused imports from java files if you encounter a verification error. Which is of course 100% wrong, unused imports don’t show up in the compiled code.

    I think you’ve also got something wrong: compiling java files and class files shouldn’t make a difference since rapc will call javac anyway to first create a class file. It uses tools.jar and the class . The compiled class files will be placed under a temp directory in C:\TEMP (or wherever your %TEMP% points to, I guess). This claim is quite easy to verify: just rename your tools.jar in your JDK installation and rapc will fail with a NoClassDefFoundError complaining about the above mentioned class.

    Having said that, I’m also fighting with getting a large project compiled for Blackberry. I thought I got the essence of this problems and that my ant build file will just work :). It does work for all of my projects, however I got this one to fix and it results in a verification error. The problem might be that I’m not using the RIM provided preverifier, however if that thing inside the BB is java then it should work with the j2me one and of course the java compiler itself shouldn’t make a difference). My guess is that despite they use the java logo they are not compatible, and what’s worse, their tools just won’t catch the problems during compile time and the on device verification will give unusable error messages.

    Anyway, my experience is that the most common problem is that the code is referencing a class that does not exist on the device. The BB seems to do an install time linking and it will definitely fail in this case, even if the ‘offending’ class would be loaded dynamically. So if you have class A that may try to load class B at runtime using Class.forName(“B”) and B referes class C (a vendor specific API, say then it won’t install on the BB…

    Another issue that I remember having found earlier was the use of class literals (SomeClass.class), but I’ve just made a test again, and it seems to work with a trivial example. However I do remember that in one of my earlier porjects I was able to consistently break and fix the COD file by adding and removing a single class literal. It may be a bug in rapc that only manifests itself in more complicated cases.

  15. I only skimmed your reply since I’m on a tight lunch break but you’re absolutely right regarding the source vs. class compilation. I meant to update this post for a while but I’ve been soo busy with iPhone related stuff that it’s kinda hard to dual focus. Having fought the verification error and eventually come out on top I can understand completely where all of the false info comes from. People may tweak one of these other things (inlining a method or removing a constant) and effectively changed the compiled result which moves the point of the verification error. Then they’ll go to market with “I found/fixed that nasty verification error!” I believe the truth is that the error is caused/remedied only by the things present in your build/compilation chain. If you make sure you use the correct version of all the Blackberry tools (pre-processor, rapc, javac 1.3, etc.) for your target platform (upwards, not backwards compatible… use the tool version that matches the earliest version of your target audience) then you’ll be safe.

    That said I’d also like to point out that prior to 4.3.x the multimedia API was horribly broken not allowing you to connect to an inputstream. Also the 4.2.1 version of rapc is a horrible mess requiring the Windows .exe and preprocessor files to be in either the current directory or the path. I got close to getting it running on my Mac but was thwarted by the dumb path issue.

  16. I’ve just fixed the above mentioned build and the key was using the RIM preverifier. I mean I checked each step systematically, and didn’t go the “just be sure to use all the RIM tools while holding your keyboard in the right angle” way. Javac version doesn’t matter as long as it’s told to output v1.1 class files. At least rapc would have been using 1.6 anyway, since that’s the one it can find on my machine. So my build is still based on ant and the original sun javac, I just use the RIM preverifier instead of the Sun WTK one (or letting proguard do the task for that matter…)

    The preverifier in JDE 4.2.1 is either one taken from an old sun wtk or at least it’s based on it. The help screen that you get when running it without any parameters is very similar to the one found in j2mewtk 1.0.2. The only difference is that the RIM version mentions CLDC1.0 explicitly while the wtk just refers to CLDC in the description of one of the options. (That’s why I think that the RIM version is based on a wtk version that’s a bit newer than 1.0.2)

  17. Yes, using the correct preverifier is critical. I suggested using all RIM tools that less than or equal to your target platform version because it’s the safest bet. Experience shows that when you plug a Toyota part into a Honda engine, though it may fit and though it may run, will not yield the stability/longevity of using the Honda part. Because I (and my buddies in Denver) have been down this path soo many times I feel it’s just not worth it to experiment.

    So I caution you (and anyone else who thinks they can get away with the same approach). Check the version numbers of your RAPC tools, Javac output, and target platform before claiming victory. Javac should output 1.1 binaries (I think it stamps the class version 45 or 46 or something but that’s low level detail… I’m counting backwards from javac6 output of 49 is it…?) Use RIM’s preverify and RAPC equal or earlier than your target, and the RIM SignatureTool can be a later version. DO NOT mix different preverifiers with RAPC. Do Not get clever and guess the versions of the tools under RAPC/Preverify unless you want to spend weeks/months chasing random dancing verification errors and bouncing white screens just to prove you could be a RIM engineer.

  18. Thanks for this post.

    I was able to successfully compile and use a simple app I made using the command line compiler, however I am also having an issue regarding the images.

    Is there a tutorial on how to add the images to the project?

    1. Harry,

      Be careful with RAPC. you may get your application to compile. You may even manage to get it to run on the device. However, your next hurdle will definitely be either verification errors or the white screen of death. The only way to avoid these problems is to use ONLY the RIM preverifier and also use the correct version of the preverifier/rapc compiler for your target audience. If you target older 8800’s and 8830s that run OS 4.1 then you’ll have another set of hurdles as the older rapc compiler works differently than the newer compiler. You should definitely use the older compiler unless you’re developing for internal company use only as it increases your audience. Most people on Blackberry don’t know how/ain’t got time/lack the patience to upgrade their OS and will likely have the older version installed.

  19. Great stuff, really useful dude. All your articles are very informative, please dont stop churning them out and giving back. Good info is so sparse!

  20. Hi Cliff,
    I am new to maven. I would want to port my application to black berry. Could u please help me out as to how i go about building the pom.xml file to build the cod file for black berry using maven.

  21. Hi
    I just discovered this site and it’s great 😉
    I wonder if you could maybe help me with my problem, maybe you’ve encountered it already.
    I posted my question on BB developers site but I didn’t get any satisfactioning answers… I will just copy post from there, to be sure I describe it right:
    “The problem is I can’t load java program to simulator.

    I’m porting game with many graphics to BB and recently after adding new ones generated .cod file size is over 7,5mb and it won’t install – after loading java program it doesn’t show in downloaded folder, as it used to.

    After running simulator with attached debugger I found above message showing while loading file:

    Jvm: errors in game.cod
    CMM: add game-1(5301)
    CMM: add game-2(5434)
    CMM: add game-3(5437)

    and so on (about 150 of them).

    I checked on debugger loading smaller file (5,5mb) and “Jvm: errors..” doesn’t show. Only diffrence beetwen those two versions is size of one included resource file (so far not used in code)

    What could those errors be? Is there maybe some limit on individual resource file size? Or maybe limit on .cod file (but from what I read there’s no such limit) ?”

    It would be great if you got something on this one, I’m sitting on it for too damn long already..

  22. Hey Kog,

    I’ve seen this soo many times in the past. It’s sad but true that things start to go silly when you load big cod files. I never really found any definitive root cause when I started experiencing this problem. I believe it finally boiled down to our using the wrong version of rapc and other tools. At one point we were using the Sun WTK preverifier version 4.2.2 of RAPC and deploying to version 4.2.1 OS. once we got all of the tools lined up, (version 4.2.1 of RAPC with RAPC preverify for OS 4.2.1 and higher) the problems all melted away. If you’re running RAPC 4.7 and installing on 4.5 then you’ll probably see radically different behavior by making sure your target OS is of an equal or higher version than that of the RAP build tools. In Eclipse you can install different versions of RAPC using the update site. If you’re using the JDE then download the correct version of the JDE (JDE 4.5 or lower for OS 4.5). If you’re installing Jad/Jar files switch to the JDE or the Blackberry Eclipse plugin and you’ll get a far better experience. If none of these is your problem try removing the images/graphics files from the package and downloading them from an HTTP server on 1st run. Also try removing class files that you may not be using. RAPC should do this but I’ve had limited success using the Ant tag to prune out unused class files from my jar before pointing RAPC at the jar.

  23. Hi, Cliff,

    This article is really good, I just want to make a comment on how to pass the multiple java files to rapc,

    I make an ant script like this:

    The above script is equivalent to the following command:

    rapc.exe -quiet import=net_rim_api.jar codename=MIDletDemo -midlet jad=MIDletDemo.jad resource.jar …

    Here I use Ant apply task,

    Apply task allow us to pass a fileset, and it will pass each file one by one to the rapc.exe. Please note that here we choose parallel=”true” attribute, it means the command execute only once, which is just what we want rapc.exe do that for us.

    For details please refer my blog:

  24. Sorry, last time the ant script was not posted correctly:

    <target name=”build” >
    <apply executable=”${rim.blackberry.home}/bin/rapc.exe” parallel=”true”>
    <arg value=”-quiet”/>
    <arg value=”import=${rim.blackberry.home}/lib/net_rim_api.jar” />
    <arg value=”codename=${}” />
    <arg value=”-midlet”/>
    <arg value=”jad=${}.jad”/>
    <fileset file=”${}.jad”/>
    <fileset file=”resources.jar” />
    <fileset dir=”${src.dir}” />

  25. Steve,

    I just want to point out that there are limitations to your approach. There is a hard limit on the size of the cmd line which is what you depend on when you pass the files individually. Using the @files.txt as I eluded to in my post works around this limitation. It can be used in conjunction with an Ant fileset assuming you echo the fileset to an output file prior to running the command. I’d suggest any custom ant task or tool take this into consideration as there’s nothing more frustrating than picking up an Ant build that was working until you added a few more files. Diagnosing such a problem could be impossible for someone unfamiliar with Ant and RAPC.

  26. Cliff –
    Thanks for the info. I came across this while looking for a way to get rapc to include all the resource (/res) files (mostly images).
    I noticed that the rapc command combined with eclipse generates a jar that includes the app’s COD files and the resources. Using bb-ant-tools rapc binding results in a jar/COD that doesn’t have any resources – despite my attempts to include them.
    Precompiling to a jar with the resources doesn’t seem to change the behavior.

    I’m pretty sure you must have solved this problem. Any thoughts would be great!


  27. Hello Cliff,

    I am working under strict time line for my project which can not use any IDE. I googled a lot and placed my query in BB support forum too, but nothing comes as help. I hope you can help me to learn how to build application through command line/ant build for JDE5.0 and prior version.

    I tried with different options but don’t know how to create .jad for my command
    I tried following command for JDE5.0
    rapc codename=build\HelloBB -import c:\BlackBerry\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.25\components\
    lib\net_rim_api.jar -d c:\BlackBerry\workspace\HelloBB\src

    Error Message: I/O Error: Import file not found: 1

    rapc codename=build\HelloBB -import c:\BlackBerry\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.25\components\
    lib\net_rim_api.jar -jad=HelloBB.jad -d c:\BlackBerry\workspace\HelloBB\src

    Error Message : I/O Error: HelloBB.jad (The system cannot find the file specified)

    I am new to Black Berry platform. Your help will be highly appreciated.

    Thanks in advance,

    1. It looks like you are specifying a relative path to the jad file which would assume the jad file is in the current directory. You need to specify the correct path to the jad file using either relative or absolute semantics. If you don’t have a jad file you should create one, either by hand or using a tool.

  28. Hello Cliff,
    I can able to get .cod/.cso/.jar/.jad/.debug file with following commands

    bin\rapc -quite import=c:\BlackBerry\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.25\components\lib\net_rim_a
    pi.jar codename=HelloBB -cldc C:\Personal\work\BlackBerry\HelloBB\src\com\qz\HelloBB\ C:\Personal\

    where C:\Personal\work\BlackBerry\HelloBB is my project directory.

    When I tried to run newly created .cod files on emulator by copy/paste to C:\BlackBerry\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.25\components\simulator
    nothing happens. can you help me figure out what is issue.


    1. You can use the “Load Java Program” option from the simulator’s File pull down menu. Alternatively (and likely a faster approach) you can use the JavaLoader program found in the JDE’s INSTALL_PATH\bin folder. add this to your %Path% using:
      Path=”C:\Program Files\Research In Motion\BlackBerry JDE 4.5.0\bin”;%Path%
      This assumes you’ve installed JDE 4.5.0. I believe there is a copy of Java loader distributed with the plugin as well and you might be able to add:
      to your path but I’m not sure. (I’ve since removed most of the Blackberry stuff from most of my machines.)

      The cmd line syntax for this tool is:
      javaloader -u load C:\path\to\program.cod

      You have to simulate the USB connection from the simulator using the file menu for this to work. Also depending on which simulator you’re running it may be tricky to find the loaded program. I remember on the Storm you had to look under the Downloads folder. Try loading with the Javaloader program and post back if you still have issues.

      1. Hello Cliff,

        I would like to update my last article with full details

        BB SDK installation path : C:\BlackBerry

        My working directory : c:\Temp

        My Project name : DummyApp

        Successfully working Command line rapc command

        c:\BlackBerry\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.25\components\bin\rapc.exe -convertpng -quite import=c:\BlackBerry\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.25\components\lib\net_rim_api.jar codename=DummyApp c:\Temp\DummyApp\src\com\qz\DummyApp\ -cldc DummyApp.jad

        Content of DummyApp.jad

        Manifest-Version: 1.0
        MIDlet-Version: 1.0.0
        MIDlet-Jar-Size: 7380
        MicroEdition-Configuration: CLDC-1.1
        MIDlet-Jar-URL: DummyApp.jar
        RIM-COD-Module-Dependencies: net_rim_cldc
        RIM-MIDlet-Flags-1: 0
        RIM-COD-Module-Name: DummyApp
        MIDlet-Name: DummyApp
        RIM-COD-Size: 5324
        RIM-TouchCompatibilityMode-UserChangeable: true
        RIM-COD-Creation-Time: 1281451739
        MIDlet-1: DummyApp,res/img/qz_logo.png,
        RIM-COD-URL: DummyApp.cod
        RIM-TouchCompatibilityMode: false
        RIM-COD-SHA1: 6e 57 1f dc 61 fc cd 12 71 21 43 92 a6 9c 8e b6 eb 6f 31 57
        MicroEdition-Profile: MIDP-2.0
        MIDlet-Vendor: BlackBerry Developer

        imporatnt line in .jad file for app icon

        MIDlet-1: DummyApp,res/img/qz_logo.png,

        contain Application name and app icon file name. Remember app icon file size must be of small size.

        Thanks for you suggestion.

  29. Your welcome. And best of luck to you as I still have nightmares from mis-typing “-codname” and using RAPC version 4.3.0 for a 4.2.1 device.

  30. Hello Cliff,
    Thanks for the nice article.
    We are making a Blackberry application which is significantly big. 3 teams are working together to make this. So we have three different projects – two of them are library & one is application.
    We are facing some issue with the build – as we are trying to make a single .cod file after the build.
    Is there any way to make a single .cod file with 2 libraries and one application?
    We are using blackberry JDE 5.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s