[peterhansen]

Greetings everyone,

I'm having this serious problem for some time and still haven't figured out how to solve it. I've developed 2 J2ME applications that works fine on BlackBerry devices with JDE 4.5 or higher (tested on two 8310 and one 8100 devices). I'm using Netbeans 6.5 to compile the project and I'm manually generating COD files with rapc.

The problem happens when I try to run the apps in devices with software versions older than 4.5:

* if I try to convert jar->cod with rapc 4.6 and net_rim_api 4.6, I get Veryfication Error at offset xxxx.yyyy (the number changes). This is actually expected, since the compiler JDE is newer than device's. This code runs fine on 4.5+ phones though;
* using rapc 4.6 and net_rim_api 4.2 : as odd as it may seems, this is so far the only way I managed to make the apps run on a 8310 4.2.2 . Trying to install on a 8100 4.2.0 or on a 8700 4.1.0 generates errors such as "invalid cod file" and "Error: file is not a valid Java code file", depending on the install method (tried OTA, javaloader and DesktopManager);
* using rapc 4.2 and net_rim_api 4.2 / rapc 4.1 and net_rim_api 4.1: this should be the correct way to do it, but even though there are no compilation errors, the apps don't work on ANY device. I receive a "Uncaught Exception: noclassdeffounderror"at runtime, with no more specific messages.

I'm not using any restricted APIs and the code is not signed. All my jar files are not obfuscated. Just a bare minimum of BlackBerry's API is used, mostly for event handling: net.rim.device.api.system.Application, net.rim.device.api.ui.Keypad and net.rim.device.api.ui.UiApplication .

The closest I've got to make this work was doing the following:

* wrote a "hello world" app. It worked even on 4.2 phones, so there must be something in my code that generates the "noclassdeffounderror"
* began with a very simple app, with just a few screens containing text, that wasn't working on < 4.2 devices, and began commenting chunks of code, until it could work on all phones;
* uncomment back small pieces of code and make tests, until the problem was back again, to find where the problem was specifically located.


Among other things, this is what I concluded from my (bad) experience:
* noclassdeffounderror is thrown if I declare a variable (can be either local or static) of the type GameMIDlet (the name of my MIDlet class). This happens if I call Display.getDisplay( instance ).vibrate( 200 ), for example, and instance is the instance of my MIDlet.
* someone also doesn't like when I declare internal classes in the MIDlet (moving them outside solved temporarily the error)
* declaring static arrays like private static SomeObject[ ] myObjects in my classes is also disliked (looks like it only happens with my app classes; static String[ ] or static byte[ ] [ ] is fine, for example)
* I have a compiled library, used all along the application, to encapsulate J2ME methods, such as drawing to the screen, rendering texts, forms, etc. Looks like the problem happens also if I extend one of this classes and the child class references a static object of the parent's class. Tried also to compile the library as a COD and adding it to the rapc import path, without success.


It seemed that I was making some progress, but since I began to have problems again after making simple method calls (even if it was a static method with a fully commented body), I decided to stop and ask for help. This was looking much more a matter of faith than logic, and certainly it isn't supposed to be like this.

Sorry if I didn't go further or skipped some details, but it's hard to give all details at once.

I would be REALLY grateful if anyone can give me any help to solve this!


best regards,
Peter

[Dougsg38p]

I think you need to get the component pack for 4.2.1. Use the RAPC from this distro, rather than the 4.6 version.

If nothing else, this will tell you what class is causing the issue. You basic problem is that you are referencing an API that is present in 4.6, but not in 4.2.

[peterhansen]

Hi,

I've downloaded and repeated the build steps, but got the same noclassdeffounderror...

Debugging with BlackBerry JDE i've discovered that this exception is thrown in class.forName( "screens.GameMIDlet" ) (which points correctly to my MIDlet class) at the application startup process.

I thought that this probably has something to do with the fact that this class extends a class named AppMIDlet, which in turn extends javax.microedition.midlet.MIDlet . Looks like rapc searchs for a class that extends a MIDlet, and then it will find AppMIDlet, when is not my application entry point. It then obfuscates GameMIDlet, changing its name and methods signatures, and then there "screens.GameMIDlet" doesn't exists when the application is running (please someone correct me if this is not the actual way rapc does its thing).

I had another shot: copied all my library classes to my project, and then compiled it all together. It was not enough: again the same noclassdeffounderror, no matter if I compile it against JDE 4.1, 4.2.0 or 4.2.1 .

Another test: I removed my mid-level MIDlet class, letting my app entry point extends javax.microedition.midlet.MIDlet directly. The code (finally) ran fine on a 8100 4.2.2 and on a 8700g 4.1.0!

But when I made some changes to the library so I won't need to copy all its files to each new project (after all, this is not what libraries are made for, right?), the problem was back, but I hope (at this point, faith is becoming more important than logic) that I'm just bypassing some basic library compilation step.

If I can manage this to work I'll let you know. If it doesn't, I'd like to anticipate a question: is there any unsupported J2ME class/resource in JDE 4.1 and 4.2 versions? Even if I comment ALL BlackBerry API imports, method calls, variables, etc I have in the code, this problem persists. Looks like some kind of limitation, such as number of classes, code size, method call depth that makes rapc generate a bad code.

I say this because a LOT of times I thought I had the solution, but it comes back from the dead to haunt me after some simple code insertions. I desperately need to go away from the trial-and-error path to a more solid, reliable and caffein-free path


Peter