Why KeyCodeNumber exception after signing Blackberry app? - blackberry

Question

We've signed a 4.7 Blackberry application with the 4.6 code-signing tool. But when starting the application a second time it throws a 'KeyCodeNumber exception'.
Anybody some clues to why we get this exception?
Thanks!

Answer 1

KeyCodeNumber exceptions have todo with the verification process.
Blackberry published an article describing how to prevent verification errors:
When developing Java applications for
the BlackBerry smartphone, you may
encounter any of the following
verification errors or errors similar
to the following:
Verification Error 3141 Module
'MyMIDlet' has verification error
(<###>) at offset <###>. Error
starting MyMIDlet: Module 'MyMIDlet'
has verification error (<####>) at
offset <###>." These errors often
occur when creating MIDlets. They are
inherently hard to debug because the
same error message can apply to a
number of problems.
The following is a list of possible solutions to prevent or correct verification errors:
If you started by building a Java
Archive (JAR) file and then used the
RIM Application Program Compiler
(RAPC) to create .cod files, make
sure you turn obfuscation off when
building the JAR file. The RAPC
compiler performs its own
obfuscation and issues may occur if
the code is already obfuscated.
Remove any System.out.* calls. These
generally do nothing on the
BlackBerry smartphone, but they
might cause verification errors.
Remove unused import statements.
Explicitly specify the access for
each function or variable. For
example, make sure each one is
specified as public, private, or
protected.
If you are working with a MIDlet,
make sure the MIDlet class is
declared as public.
Verification errors may occur if the
COD file is corrupted or if it was
not signed correctly. Make sure that
you perform a clean rebuild and that
you re-sign your application.
Reinstall the application on the
BlackBerry smartphone.
Comment out any non-executable code.
Verification errors might be related
to the size of the main code file
and the library files. If you
comment out non-executable code, the
file sizes change, which may correct
the problem.
If you have created any classes that
inherit from RIM classes, change the
name of any custom methods and
members that you created in those
classes. This makes sure that you
have not named any methods or
members of the same name in the
internal RIM classes.
If your application is using
BlackBerry® Device Software 3.8 or
later, verification errors occur
when an application that implements
the
javax.microedition.rms.RecordStore
class is compiled using BlackBerry®
Java® Development Environment
(BlackBerry JDE) earlier than
version 4.0. This occurs if the
application uses either the
addRecordListener or
removeRecordListener methods of the
RecordStore class. To resolve this
issue, recompile the application
using BlackBerry JDE 4.0 or later.
There is a problem with how the
BlackBerry® Java® Virtual Machine
(BlackBerry JVM) handles the
referencing of a class directly
within the constructor of another
class. The following is an example:
Class1 class1= new
Class1(Class2.class.getName());
To work around this issue, do not make the class call within a constructor as shown in the following example:
Class1 class1;
String className = Class2.class.getName();
Class1 = new Class1(className);
Remove references to a static instance variable from an inner class. For example, the following code example could cause an error:
public class MyOuterClass {
static int var;
class MyInnerClass {
public void doSomething() {
var = 7;
}
}
}
There are a few ways you can remove these references, such as creating get/set methods for var in the outer class or modifying the logic to pull MyInnerClass out of MyOuterClass.
The build procedure normally
compiles from the java source file
with the javac command, and then
runs preverify.exe file and then
RAPC. Add the following command line
arguments to javac to help avoid
issues in earlier versions of the
RAPC:
javac.exe -source 1.3 -target 1.1
Some methods that are very long can
cause verification errors. By
breaking these methods into helper
methods, you can reduce the
likelihood of verification errors.
Although not as likely, some very
long method definitions (with 10 or
more parameters), and some very long
constant definitions (long package
structure and/or long names) can
also cause verification errors.