I've just spent a remarkable amount of time on some verification errors on the BlackBerry platform. Its just amazing how much misinformation exists on the subject on the internet and is being repeated constantly by blogs, I don't want to link to that misinformation since it would just promote it up in the search results...
As an example one of the often repeated "advice" options is to remove redundant import statements... Since the class file format doesn't have a notion for import and all is translated to fully qualified class names in the binary this change would do absolutely nothing, yet the advice is repeated just like any religion.
On getting a verification error you should do the following:
1. 9 our of 10 cases means you used an API that isn't available in the current device. If you are compiling on your own just make sure that you are compiling against the jars of the proper JDE version.
To check on your device go to the options -> about option to check the OS version compare it to the JDE version and make sure you are compiling against the proper version.
2. Check that you are using the preverifier from RIM, I'm not sure about this one though.
3. Make sure that you are using -target 1.1 in your compliation step! This was mentioned nowhere but that was the difference between success and failure for my build (failed on devices but worked in the simulator).
Notice that NetBeans doesn't let you configure that through GUI in mobility projects!
4. If all else fails use rapc for the compilation, this usually solves the verification issues mostly by getting the first 3 options right.
Eventually I went with the excellent BB ant tasks rather than use the approach suggested by NetBeans. The main reasons are the signing and JAD generation which works really smoothly and its much easier to use than copying the whole project into the JDE...
Does this mean we're getting closer to seeing the Blackberry drop you've talked about? :)
ReplyDeleteI solved this problem only obfuscating the code using proguard. I thought the problem is dued to the jar size
ReplyDeleteYou're right, the web, and the forums in particular, are full of questionable speculation about this topic. I've seen the import-nonsense on a j2mepolish page which should be considered quite professional otherwise.
ReplyDeleteI think RIM is strongly at fault here for several reasons:
- first, they don't publish anywhere what these error code mean. If you get a verification 1704 then you can speculate anything, like starting the compilation with the wrong hand. 1704 doesn't mean anything (nor do the other numbers).
- indeed their class verifier works really strange. I'm not sure how many of the things listed on the above mentioned j2me polish page is true, there are pretty weir things that may or may not be true and thus I'd rather not reiterate, but their VM is either java or not. If it is java then the things listed there should work, just as the standard j2me WTK preverifier. (Unless the latter has bugs, of course.) If those or the standard preverifier produce code that the BB VM does not accept then it's not java.
I've just finished tackling with an application and making it work again on a real device. To me removing a SomeClass.class statement and replacing it with a painful Class.forName call solved the problem. At least for now. I just checked the netbeans generated build-impl.xml file and indeed it does set the javac traget to 1.1.
ardf69: you won't have a problem with COD (that's we're talking about) size because rapc takes care of that and if the result is too large then it will package it into several cod files. (But to make it more confusing in the end it will ZIP all the CODs together into a file named as you originally wanted. Yes, even the extension will be cod. So if you create a large X.cod file then it will be a ZIP with X.cod, X-1.cod, X-2.cod, etc inside.)
The obfuscation probably solves the problem by chance, mangling byte code somehow makes it pass the verifier. (That to me indicates that the problem is with the BB verifier.) Proguard is also able to do preverification.
How do you open and read the .bug file? Mine looks like the following:
ReplyDeleteÿ õÄM³Ô ÿ ¶Ô( ( Z Àabsadmin Nov 21 2008 19:38 yÃg {Ãgfledge.exe {Ãg/app=Jvm.dll {Ãg/h
When i tried to navigate to other form on BlackBerry 6.0 this error appeared
ReplyDeleteAn internal application error occurred: java.lang.IllegalStateException: UI engine
accessed without holding the event lock
How to fix this problem?