MIDlet works on emulator, fails on device: how to debug?

[Simon Brooke]

I've got to the point with my MIDlet development where it does everything I
want perfectly... under Sun's j2me_wt2.2 emulator. Or at least, to be
perfectly honest and exact, it works perfectly with the emulator's
QwertyDevice, DefaultGrayPhone and MediaControlSkin. It crashes the
DefaultColorPhone horribly, but not until the user is well into using the
application - it starts all right under the DefaultColorPhone.

But when I port it onto the device - an HP IPAQ 6515 using IBM's j9 MIDP2.0
implementation, it will not start at all. It appears to fail immediately,
with no diagnostics.

And, of course, I'm up against deadlines and have to deliver - this
application is wanted in the field on Tuesday, which is why I'm working on
Sunday.

Can anyone give me any advice as to how to get a handle on what's going on?

By MIDlet standards this is probably quite a big and sophisticated
application - the jar file is 84Kb and contains 24 classes, a few of which
are redundant and could be trimmed out - but this shouldn't be a problem
on a device which has 57Mb of RAM.

 

[Rhino]

I've got to the point with my MIDlet development where it does everything
I
want perfectly... under Sun's j2me_wt2.2 emulator. Or at least, to be
perfectly honest and exact, it works perfectly with the emulator's
QwertyDevice, DefaultGrayPhone and MediaControlSkin. It crashes the
DefaultColorPhone horribly, but not until the user is well into using the
application - it starts all right under the DefaultColorPhone.

But when I port it onto the device - an HP IPAQ 6515 using IBM's j9
MIDP2.0
implementation, it will not start at all. It appears to fail immediately,
with no diagnostics.

And, of course, I'm up against deadlines and have to deliver - this
application is wanted in the field on Tuesday, which is why I'm working on
Sunday.

Can anyone give me any advice as to how to get a handle on what's going
on?

By MIDlet standards this is probably quite a big and sophisticated
application - the jar file is 84Kb and contains 24 classes, a few of which
are redundant and could be trimmed out - but this shouldn't be a problem
on a device which has 57Mb of RAM.

I think you've bumped into the same problem that messed me up badly a couple
of years ago. I was using WTK2.2 beta and a Palm Tungsten E with the J9 JVM.
My midlet worked fine in the emulator and crashed on the actual Palm.

I'm pretty sure that the problem is that WTK2.2 (at least the beta) uses the
K9 JVM and that this is why the midlet behaves differently on the real
device than on the emulator: K9 <> J9.

Unfortunately, I never figured out how to get a J9 emulator. This was just a
"spare time" project, not something I was doing for work, and I got into
other things. I never made a serious attempt to find a proper J9 emulator so
I'm not sure where to find one. Or maybe the better answer is to find a K9
JVM that I can install on a Palm. I never found that either.

But I think that's where your answer lies.

If you find out where to lay your hands on either one, or if anyone reading
this thread knows, please post it here. I don't have the time to write
midlets right now but I'd still be interested in knowing the answer.

 

[Simon Brooke]

I think you've bumped into the same problem that messed me up badly a
couple of years ago. I was using WTK2.2 beta and a Palm Tungsten E with
the J9 JVM. My midlet worked fine in the emulator and crashed on the
actual Palm.

I'm pretty sure that the problem is that WTK2.2 (at least the beta) uses
the K9 JVM and that this is why the midlet behaves differently on the
real device than on the emulator: K9 <> J9.

Unfortunately, I never figured out how to get a J9 emulator. This was
just a "spare time" project, not something I was doing for work, and I
got into other things. I never made a serious attempt to find a proper J9
emulator so I'm not sure where to find one. Or maybe the better answer is
to find a K9 JVM that I can install on a Palm. I never found that either.

But I think that's where your answer lies.

If you find out where to lay your hands on either one, or if anyone
reading this thread knows, please post it here. I don't have the time to
write midlets right now but I'd still be interested in knowing the
answer.

From my reading of the IBM website, J9 /only/ runs on StrongARM/xScale
processors, so you can't get it to run on an x86 (or anything else)
machine unless you have an emulator for the xScale processor.

--
(e-mail address removed) (Simon Brooke) http://www.jasmine.org.uk/~simon/
Ye hypocrites! are these your pranks? To murder men and give God thanks?
Desist, for shame! Proceed no further: God won't accept your thanks for
murther
-- Robert Burns, 'Thanksgiving For a National Victory'

 

[Rhino]

From my reading of the IBM website, J9 /only/ runs on StrongARM/xScale
processors, so you can't get it to run on an x86 (or anything else)
machine unless you have an emulator for the xScale processor.

Wonderful :-((( So, it's probably not possible to test and execute in the
same JVM.... That's just great. That's like trying to test code on a
Macintosh and then implement it on a Windows machine directly. Back in the
days before you could run Intel code on Macs and vice versa.

You'd think there'd be some way to test on the same JVM on which you're
going to implement..... In my case, it might be worth asking the best way to
handle this dilemna on the java newsgroup for Palm developers but the
traffic on it was so sparse when I was developing a couple of years ago - a
couple of posts a week - that it was not very useful. But it might be worth
going this way for this issue since it's such a big and important issue.
Perhaps you can do something equivalent for your IPAQ? After all, if the
manufacturers want code developed for their platforms it would seem highly
advisable for them to create emulators that those developers can use and for
those emulators to be the same as the JVMs they're putting on their PDAs.

 

[Simon Brooke]

I've got to the point with my MIDlet development where it does
everything I
want perfectly... under Sun's j2me_wt2.2 emulator. Or at least, to be
perfectly honest and exact, it works perfectly with the emulator's
QwertyDevice, DefaultGrayPhone and MediaControlSkin. It crashes the
DefaultColorPhone horribly, but not until the user is well into using
the application - it starts all right under the DefaultColorPhone.

But when I port it onto the device - an HP IPAQ 6515 using IBM's j9
MIDP2.0 implementation, it will not start at all. It appears to fail
immediately, with no diagnostics.

For reference, the problem was as follows:

Images were stored in the MIDlet suite JAR file in the directory /images/;
I have verified they were indeed there. They were loaded using

try
{
zoneDisplay =
new ImageItem( "Zone",
Image.createImage( "/images/closed.png" ),
Item.LAYOUT_BOTTOM, "Closed" );
statusDisplay =
new ImageItem( "Status",
Image.createImage( "/images/confirm.png" ),
Item.LAYOUT_BOTTOM, "OK" );

form.append( zoneDisplay );
form.append( statusDisplay );
}
catch ( IOException e )
{
// ignore
}

in the MIDlet constructor.

On the Sun Wireless Toolkit emulators, both versions 2.2 and version 2.5,
this worked fine. On the device, the MIDlet failed, with no error message
or other diagnostics.

However, when I removed the images from the directory, leaving the code
unchanged, the MIDlet ran successfully on the device (although without
images, of course).

Images /do/ work on the j9 MIDP installation, because the following method
works:

/**
* Shamelessly cribbed from
* http://java.sun.com/developer/J2METechTips/2001/tt0820.html
*
* @param d the diaplay on which to display thie
* @param next the screen to show next after this
*/
protected void showSplashScreen( Display d, Displayable next )
{
Image logo = null;

try
{
logo = Image.createImage( "/images/splash.png" );
}
catch ( IOException e )
{
}

Alert a =
new Alert( "Field Inspection Pack",
"Fisherman field inspection pack $Revision: 1.4 $ of $Date: 2006/11/21
14:58:35 $ " +
"(c) 2006 Simon Brooke\n\n" +
"http://www.weft.co.uk/products/fisherman", logo,
AlertType.INFO );
a.setTimeout( 6000 );
d.setCurrent( a, next );
}

I'm left with the possibilities that

(i) Images cannot be loaded during startup, while the constructor is being
executed, possibly because required structures have not yet been
initialised; or

(ii) There's a bug in the ImageItem constructor.

 

[eliza81]

'Debug' works fine, but not in 'Release' and vice-versa.

t times it is possible that some operations work fine in Debug mode but not in Release mode and vice-versa.

Here are the some of the common errors that lead us to the above problem.

1. In general, the default value of an uninitialzed variable is garbage in Debug and zero in Release .

So, the following code works fine in Debug and not in Release .

int enabled;
if( enabled )
DoSomeThing();

So, Please initialise when a variable is declared.
2. One of the main difference in Debug and Release is Optimization.

We can set this from Properties -> C/C++ -> Optimization.