09-16-2008 05:21 PM - last edited on 10-07-2008 06:38 AM by Andy
I am developing on the BB JDE 4.5.0
Using the BlackBerry Smartphone Simulator 18.104.22.168
I am developing a simple application, which requires an import of a .jar file. I am able to build correctly. Below are the build details which show that the .jar file (socialdeck-client.jar) is correctly imported:
"C:\Program Files\Research In Motion\BlackBerry JDE 4.5.0\bin\rapc.exe -quiet import=..\..\bin\socialdeck\socialdeck-client.jar;
Below are the additional imports that i used, followed by the Main class where I instantiate a class contained in the .jar file, followed by the runtime error way below.
From what I read i need to also copy a .cod file that associates to the .jar file? Is this correct, and if so how do I generate a .cod file from a .jar file? Furthermore, if I want to package this as one executeable .alx file, how do I include the imported .jar/.cod files into one executeable?
Moderator EDIT: Code from this part of the post has been removed at the original posters request
On runtime, I get the following in the
09-17-2008 10:03 AM
Please see the following link.
How To - Compile a jar file into a BlackBerry Library
Article Number: DB-00042
You can add the reference to the cod file of your library within the JAD and ALX file so that both are loaded at the same time.
09-17-2008 10:53 AM
09-18-2008 01:57 AM
Thanks msohm and Simon!
I read the article and it makes sense now. However I don't have a .jad file... all i was given was a .jar file wich has compiled classes.
Before I am able to get to that point I have a duplicate definition error when I try to build:
"Error!: Duplicate definition for 'xxx.yyy.zzz.FeedWSProxy' found in: xxx.yyy.zzz.FeedWSProxy"
And so I can't build the newly created project that contains the .jar file. What boggles me is wouldn't the compiler that created the .jar file complain about this before it was built?
Please, let me know if I need the .jar file checked out as I don't have any visibility to into the already compiled classes.
09-18-2008 01:04 PM
09-18-2008 08:23 PM
The file is meant to be used with the blackberry platform. I un-jarred the file in question, and I don't see a duplicate definition of any class, there is only one version of it.
Can you suggest what I should have the owner of the .jar file do?
09-19-2008 09:24 AM
Do you have this defined in one of the files you are trying to compile?
For that matter, does the jar contain source that the compiler could be picking up?
It wouldn't be crazy for someone to archive the source too.
I just converted a standalone app into a library and a small launcher and built both with command line
utilities and everything went fine- it even ran on my target device but I never tried it in the emulator.
If there was a problem with your jar file you would expect something like a missing classdef.
The -import option seems to be like -classpath.
09-22-2008 02:29 AM
I am not trying to define the class that the compiler is complaining about. I asked the owner of the .jar file to compile all of his code using the BB Compiler to make sure everything was up to BB conventions. However, when I import the .jar file and try to build it as a library I get the duplicate definition for "aaa.bbb.ccc.XYZ".
So i can't seem to figure out why it is complaining about a duplicate definition!!
I'm a little frustrated right now
09-22-2008 05:59 AM - edited 09-22-2008 06:03 AM
Well, I guess the obvious question is, "does that class appear twice in things the compiler can find?"
Can you get a directory of that jar and sort it or just grep for the name and have it show up twice?
Is the compiler referencing the jar twice in some odd way? Does the name appear in some other
jar or source file the compiler knows about?
It seems the places for conflicts are limited to things on the command line and there shouldn't be too many of these
as you could grep or otherwise find all references to the offender.
[ added notes ]
IIRC, glancing at the jar, it looked like it does contain a lot of extra "stuff" that Sun doesn't put in there. I have verified that building
with the "-library " options does generate a jar file that works fine with -import. If you don't build this way maybe it does something to
generate a larger archive. If there is a cod file in the jar, the compiler may be finding this, it may be worth manually removing and see
if that is what it complains about as I'm not sure that normal tools work easily in extracting the class defs from a cod.
09-22-2008 08:21 AM
I haven't checked the jar I geneated with the -libarary option but the normal jar does contain a cod file and browsing
through that with a strings utility it could likely contain duplicate class definitions that the compiler may find.
Id' be curious to know if there is a cod in your jar and if removing it helps. I did check the jar that I generated, IIRC,
with the library flag and it does seem to contain a cod but not sure if the compiler reads the RIM-library-flag
in the manifest or something else.
Anyway, in my limited experience compiling with the -library flag seemed to allow later -import of the jar
file. I guess in some cases if you don't include a flag like -library the compiler may link in extra stuff. Is you duplicate
one of your classes, a java class, or a RIM class?