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

Discussion in 'Java' started by Simon Brooke, Nov 19, 2006.

  1. Simon Brooke

    Simon Brooke Guest

    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.

    --
    (Simon Brooke) http://www.jasmine.org.uk/~simon/

    ...but have you *seen* the size of the world wide spider?
    Simon Brooke, Nov 19, 2006
    #1
    1. Advertising

  2. Simon Brooke

    Rhino Guest

    "Simon Brooke" <> wrote in message
    news:...
    > 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.
    >
    > --
    > (Simon Brooke) http://www.jasmine.org.uk/~simon/
    >
    > ...but have you *seen* the size of the world wide spider?
    >


    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.

    --
    Rhino
    Rhino, Nov 20, 2006
    #2
    1. Advertising

  3. Simon Brooke

    Simon Brooke Guest

    in message <ejstar$s8b$>, Rhino
    ('') wrote:

    >
    > "Simon Brooke" <> wrote in message
    > news:...
    >> 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.
    >>
    >> --
    >> (Simon Brooke) http://www.jasmine.org.uk/~simon/
    >>
    >> ...but have you *seen* the size of the world wide spider?
    >>

    >
    > 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.

    --
    (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'
    Simon Brooke, Nov 21, 2006
    #3
  4. Simon Brooke

    Rhino Guest

    "Simon Brooke" <> wrote in message
    news:...
    > in message <ejstar$s8b$>, Rhino
    > ('') wrote:
    >
    >>
    >> "Simon Brooke" <> wrote in message
    >> news:...
    >>> 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.
    >>>
    >>> --
    >>> (Simon Brooke) http://www.jasmine.org.uk/~simon/
    >>>
    >>> ...but have you *seen* the size of the world wide spider?
    >>>

    >>
    >> 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.
    >

    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.

    --
    Rhino



    > --
    > (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, Nov 21, 2006
    #4
  5. Simon Brooke

    Simon Brooke Guest

    "Simon Brooke" <> wrote in message
    news:...
    > 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.

    --
    (Simon Brooke) http://www.jasmine.org.uk/~simon/
    Wannabe a Web designer?
    <URL:http://userfriendly.org/cartoons/archives/97dec/19971206.html>
    Simon Brooke, Nov 22, 2006
    #5
  6. Simon Brooke

    eliza81

    Joined:
    Feb 10, 2010
    Messages:
    12
    '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.
    eliza81, Jun 11, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. rbg
    Replies:
    0
    Views:
    424
  2. swy128
    Replies:
    2
    Views:
    813
    Simon Brooke
    Nov 8, 2006
  3. Replies:
    1
    Views:
    240
    Peter Zolja
    Jan 31, 2007
  4. Leo Pedeglorio

    Device emulator

    Leo Pedeglorio, Nov 23, 2004, in forum: ASP .Net Mobile
    Replies:
    2
    Views:
    118
    Leo Pedeglorio
    Nov 24, 2004
  5. ASMJ
    Replies:
    0
    Views:
    556
Loading...

Share This Page