Inconistent or missing stackmap at target?

Java on Mobile Devices J2ME
#1

Hi

I have written a very simple helper class for a j2me app. It only contains a few integer fields, a constructor and two methods. I also have import java.lang.Math;

It compiles fine but when I run my application I get something like:
Error verifying method BoundBox.moveBy(II)V
approximate bytecode offset 18.
Inconsistent or missing stackmap at target
ALERT: java/lang/verifyError BoundBox

I am using Sun Wireless Studio built on Netbeans. I have not come accross this issue before, the few searches I have done on the net have resulted in me thinking that there is something wrong with the preverification process.

I only get this problem when I exclude the two methods from my class. Including them throws this error. They are fairly simple and only do some integer math.

Has anyone come accross this before and what is the workaround to it? Why am I getting this issue, isit because I am using the Math class?

Thank You

#2

I would have to see the code to make a better estimate. Maybe try the netbeans preferences/platform tab and set the Device Configuration to CLDC-1.1 and the Device Platform to MIDP-2.0. Just a wild guess from very little information you’ve given us.

Wood

#3

Have you preverified the class?

#4

Hi

According to Sun’s documentation, the build process automatically preverifies the class file. I have no compilation errors, this is only thrown up during runtime.

I will have to try Wood’s suggestion later as I am at work… the code is on my home pc so will post it sometime soon.

If I wanted to preverify manually, I would obviously use preverify.exe located in {$WirelessToolkit2.2 Base}\bin… only problem is I cant get it to see the file, I do something like:
preverify F:\MOBILE\PROTO1\boundbox.java
Am I typing in the parameter incorrectly, do I need to include “\” for a backslash? Also what file format does preverification produce?

Thank you guys

#5

preverify is for class files, not source (.java) files. I don’t ever use it directly, but looking up the options, I think it would be more like this:

preverify c:\wtk21\lib\cldcapi10.jar;c:\wtk21\lib\midpapi20.jar -d f:\mobile\proto1\output F:\MOBILE\PROTO1\boundbox.class

That said, I keep all of my source under the wtk21 directory. I’m not using 2.2 yet. It just makes life easier and the wtk doesn’t seem to want to use any other directories. Or I’m to lazy to go digging. All of my projects are under c:\wtk21\apps. When I start a new project I first create the project with wtk, then create the same project with NetBeans in the same directory. Source files are under c:\wtk21\apps<appname>\src. I dev with NetBeans (I used to use codewarrior), and I create my final releases with wtk.

Wood

#6

Thanks Wood. I don’t think WTK has anyway of checking other dirs, or even mounting them - then again maybe im being lazy to!

I have my code seperated from my install dir for basic reasons:
If windows plays up and C needs formatting then I will loose all my work! Ok we can use command line tools, etc to all the necessary work but its unnecessary extra effort! I personally think its best to keep dev kit dirs seperate from code dirs, especially if you decide to uninstall the product.

Also having your own dirs makes locating and backing up files much easier. Just a thought!¬

p.s. I like my root dirs in capitals, its just the way I do things, some day I may go back to lower!

#7

I have the same problem as ameano has:

JK_VMEVENT_VMSTARTED

Error verifying method sergo/MidletTest$1 commandAction(Ljavax/microedition/lcdu
i/Command;Ljavax/microedition/lcdui/Displayable;)V
Approximate bytecode offset 23: Inconsistent or missing stackmap at target
ALERT: Error verifying class sergo/MidletTest$1

JK_VMEVENT_VMSTOPPED

AMstartMidpApplication return code = -127

And here is problematic code:

public void commandAction(Command c, Displayable d) {
String label = c.getLabel();
if(label.equals(“Exit”))
destroyApp(true);
}

It’s just commandAction method of CommandListener interface. Problem or mistake is in the “if” statement, because then I comment this string everything works without any problem. But in that case I’ve lose functionality - I can’t check what command causes an Event.

#8

Make sure you are preverifying against the correct midp classes.

i.e. if you are preverifying against the midp2 class library, you may encounter problems if you are then executing them against the midp1 library.

#9

Its maybe a silly question but anyway… Is preverifier supposed to use after compiling ??
I have folder structure in Eclipse (using EclipseME) like src, bin, res, verified, deployed.

I get the same error : ALERT: java/lang/VerifyError:

So if i use preverifier from command line is it supposed to put it to the folder verified or deployed ?

Thanx

#10

Is the verifier so important?
I thought compiler does same things such as checking errors etc.

#11

[quote]Is the verifier so important?
I thought compiler does same things such as checking errors etc.
[/quote]
Preverification is an absolutely critical part of the compilation process for any CLDC application.

J2SE verifies class file integrity at runtime, however the verification process was deemed too slow to perform on the kind of devices targetted by CLDC.

Therefor, part of the verification process was moved from runtime, to compile time, to speed up the runtime verification - hence the preverifier was born.

#12

Thanks Abuse
I understand, I must learn more about these pocesses