09-20-2009 08:28 PM
Currently developing an app for the 8310 an using the 4.5 JDE. Until this Friday everything was going great and then..... Started to receive this COD verification error. In my initial post, someone mentioned that these can usually be attributed to trying to access something from the API that is not available on the device.
My question though is, how dos one go about fining out what it is that you are using that is not compatible with the target device and hance JE version?
Solved! Go to Solution.
09-21-2009 04:14 AM
See this KB article:
What Is - Appropriate version of the BlackBerry JDE
Article Number: DB-00537
So you should develop using a level that matches or precedes the earliest OS you wish to support. While in some cases it is possible to use a later level and not use any of the features that are introduced at that level on earlier devices, this is not supported.
Regarding the differences release to release, you will find the Release guide explinas these. For example, here is the 4.6 Release Guide.
09-21-2009 09:19 AM - edited 09-21-2009 09:21 AM
How does one go about finding out what it is that you are using that is not compatible with the target device and hance JDE version? Usually there are two obvious steps:
1. Compile with the JDE version corresponding to the lowest handheld software version you're targetting. The first three numbers in the handheld software version and JDE version are the important ones. For example, JDE 4.5.0 is fine for any devices with v4.5.0.x handheld software; JDE 4.6.1 is not necessarily OK for v4.6.0 devices, whereas JDE 4.6.0 is.
2. If you want to be really really certain, install your module(s) on devices covering major handheld software versions (again, first three numbers of the version are the important ones). For example, v4.0, v4.0.2, v4.1.0, v4.2.0, 4.2.1, v4.2.2, v4.3, v4.5.0, v4.6.0, v4.6.1, v4.7.0, v4.7.1, v5.0.0.Verification errors happen and install/system startup time and these are link-time errors, so you don't need to actually test the various features of your app -- it either fails the verification or does not. If a module fails the verification, it cannot be used, and the applications contained in the module cannot be started.
P.S. In principle you shouldn't even be allowing the user/BES admin to install a COD file compiled by a higher version (first three numbers only) of JDE, as otherwise, in the worst case scenario, the device may get semi-bricked due to the verifier crashing or entering an infinite loop (lots of trickery will be required to make it usable again). Last time I've seen this it was on a v4.1 handheld software, so, may be, this has been fixed. The typical case nowadays is that your module gets a verification error and cannot be used
Note that there are certain corner cases where, even if you're using an API that is available in lower JDE version, your module will still get verification errors on handheld software corresponding to that lower JDE version. For example, if you're using SocketConnectionEnhanced and build your module using JDE 4.6+, you'll still get a verification error on handheld software v4.5. If you build the same source code with JDE 4.5 (provided you don't use any 4.6-specific APIs), your module will load fine on both v4.5 and v4.6+ handheld software.
09-22-2009 01:09 AM
Thank you for your insightful answer. In the end we found that it was not a question of using an API call or class that was the problem but, using the .forName() on a class that was not supported on the 8310/JDE 4.5
09-22-2009 05:30 AM
I find it really hard to believe that Class.forName() was the root cause of the verification error. Class.forName() is a runtime operation and the link-time verifier can't know (because of the undecidability of the Halting Problem) what classes your module will be requesting via Class.forName(). I suspect your link-time verification error may have been caused by a dependency on a class having been compiled into your module by the Java compiler and/or rapc and the verifier finding out that it could not satisfy the dependency.
If you used Class.forName(), may be you used it like this: (MissingClass) Class.forName(...).newInstance(), which would have given your module a compile/link-time dependency on the class MissingClass.
04-23-2010 08:26 AM
Hello, I am trying to find the 4.6 runtime for my eclipse plugin but the only one available is the 5.0.0
My device is an 8350i and runs on a 4.6 platform
I've tested on the simulator and it seems fine, but wanted to ensure here with you guys.
Thanks for any kind of assistance.