I am trying to preverify "signpost-commonshttp4-1.2.1.1.jar" file to use it in BlackBerry project
Here is the command im trying. Since it also needs "signpost-core-1.2.1.1.jar" to classpath which is already preverified.
C:\Eclipse_bb\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.25\components\bin>
preverify.exe -classpath
"C:\Eclipse_bb\plugins\net.rim.ejde.componentpack5.0.0_5.
0.0.25\components\lib\net_rim_api.jar;C:\Program Files\Java\jdk1.6.0_25\jre\lib\
rt.jar;C:\Eclipse_bb\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.25\components
\bin\output\signpost-core-1.2.1.1.jar"
signpost-commonshttp4-1.2.1.1.jar
Here i have added classpath of net_rim_api.jar, rt.jar & signpost-core-1.2.1.1.jar
It throws below Error
Error preverifying class
oauth.signpost.commonshttp.CommonsHttpOAuthConsumer
VERIFIER ERROR oauth/signpost/commonshttp/CommonsHttpOAuthConsumer.wrap(Ljava/lang/Object;)Loauth/signpost/http/HttpRequest;:
Illegal type in constant pool
If you mean signpost, with source code hosted on github by kaeppler, then it appears to be a Java-SE library. BlackBerry is a Java-ME device, so you will need to find a Java-ME compliant library. The preverifier errors you are seeing are the first indication that the Java-SE code won't work on BlackBerry.
Related
I'm trying to port one of my iOS apps from the Mono versions of the
ServiceStack.Text libraries to the PCL versions for JSON
serialization/deserialization.
I have the libraries working in a regular Windows console application. When trying to port this into the iOS application, I'm getting an "Object reference not set to an instance of an object" exception from on the ServiceStack extension method classes. The error message is a red herring; the true error is getting swollowed by a try/catch.
The static constructor in ServiceStack.Text.PCL.PclExport is doing late binding for a
platform specific DLL and can't find that DLL. The build log bears out that the
Client, Interface, and Pcl libraries aren't being packaged with the .app file even though the reference are included at the project level.
I've been able to reproduce this in a basic iOS Hello World application. If I
add a line of code that references a method in the Pcl DLL, the three missing
libraries are copied. However, I'm still getting the same "Object reference not
set to an instance of an object" error.
I suspect that this is caused by the fact the Xamarin compiler doesn't translate the DLLs into iOS binaries unless they are actually used, and since they're late bound, it doesn't know they're used and so ignores them.
I didn't think late binding was legal under the licensing on at actual iPhone? doesn't the link merge everything into one exe?
See the Xamarin Linker Docs try the -nolinkaway option.
im using code::blocks IDE and mingw 4.7.2 compiler. resently i installed open cv 2.4.5 when i build the following program it build without errors. but when starting the progrm it terminates giving the error
the application failed to initilize propely (0x0000005). click ok to terminate the program
all the librarys are linked properly, and all the nessory directoris are added to the path variable. the program is a very simple program that just reads a image and displays it. eny ideas how to avoid this error. thanks for eny help....
here when i tested the exe in dependency walker
it says dwmpi.dll is missing. what may be gone wrong...
Try the depends utility to be sure your program is not missing any .dll files.
I have also asked this question on the BlackBerry support forums, under the thread "NoClassDefFoundError while preverify the jar files in BlackBerry"
I am adding a library files(jar files) in my BlackBerry Project and and try to run it. But it is giving me the below error : Error!: Missing stack map at label 77. So i try to find out the issue and find this link: Preverify Link
So i tried to fix this issue using preverifier. As i am using BlackBerry eclipse plugin, i have tried in this way:
Copy the jar file in the bin folder of my eclipse 6.0 plugins (eclipse-SDK-3.5.2-win32\eclipse\plugins\net.rim.ejde.componentpack6.0.0_6.0.0.29\components\bin)
Execute the following command in the command line:
preverify -classpath "<path to 6.0.0.29 SDK>\net_rim_api.jar" "ArcotOTP-Lib-Java-Test-2.0.0.jar"
But after running this line, i am getting the below error:
Error preverifying class Mypackage.API$1
java/lang/NoClassDefFoundError: Mypackage/Test
BlackBerry devices are running on the Java-ME platform, so you can't use modern java features. Typical Java jar files these days use newer features that are not backward compatible with the Java-ME platform. Some projects do go out of the way to be backward compatible, like Bouncy Castle. But that is rare.
This question, duplicated on the BlackBerry forums, was also answered on the BlackBerry forums, which I will capture here:
simon_hain:
and is it a j2me library?
Arindam Mukherjee:
No it is java library..all classes are basically java classes. The same library i am using for android also and it is working fine fro me..
simon_hain:
BlackBerry uses J2ME as a base, Android uses J2SE.
You cannot use an Android library on BlackBerry unless you re-compile it (and resolve all the errors due to missing reflection, lists etc)
I've implemented a blackberry application using JRE5.0, it's running well on any device with OS5.0 and OS6.0
When I try to open the same application on 9900 which has OS 7.0, I got the following error:
Error Starting myAppName: Module 'MyAppName-4' has verification error
3337. (Codfile version 78)
where myAppName is the application name (name of the cod file)
as in the following image:
I checked the event logger, here what it contains (older to newer):
a System - VM:LINK MyAppName
a System - VM:VECPs=my.Package.Name.Containing.Screens
a System - VM:VECCs=oneOfMyScreenClassNames
a System - VM:VECMm=functionInOneOfMyClasses()
Module 'MyAppName-4' has verification error 3337 (codfile version 78)
Linker error: 'VerifyError' for MyAppName
Error starting myAppName: Module 'MyAppName-4' has verification error 3337 (codfile version 78)
Here is the content:
E System - JVM:INFOp=2100000a,a='7.0.0.296',o='4.0.0.127',h=7001204
For those who are interested, I found the solution.
In the logs there were:
a System - VM:VECCs=oneOfMyScreenClassNames
a System - VM:VECMm=functionInOneOfMyClasses()
I did the next steps in the whole class "oneOfMyScreenClassNames" indicated in logs
Here are the steps:
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
Remove references to a static instance variable from an inner class. 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.
Source: http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/832062/Support_-_Preventing_verification_errors.html?nodeid=1499031&vernum=0
PS, I also removed "instanceOf" usage in code
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!
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.