Skip to main content

How to build your own midp stack to debug midlets?

3 replies [Last post]
Joined: 2007-01-03


I have a debugging question and I would appreciate if some of the experts could help me out.
Sorry for the long post, but I am trying to give you as much information as I can from the start.

I have been trying to build a phoneme feature vm for linux/x86 and wince/arm with which I could
debug midlets, but I am having trouble getting it to work. Here is what I have been up to (I will
just mention my attempts for linux/x86 as my experiences with wince/arm are similar):


I have been using WTK 2.5.2 and jdb on linux and that works as expected. With the information
at, I could step through my test midlet
just fine. The goal is to have a similar phoneme VM with which I can do the same. I followed the
instructions on the following links:

I followed the instructions on the forum (last link) to build a recent snapshot from the svn
repository. The build of the vm was successful, and kdp.jar seems to connect to runmidlet_g, but
when I start jdb, I do not get a prompt to enter commands.

I noticed the midlet is not suspended when the debugging session starts, but runs as it normally
would. I added some printf debug code in cldc/src/vm/share/debugger/JavaDebugger.cpp and
in midp/src/ams/ams_base_cldc/reference/native/midp_run.c, and I can confirm that the right
flags are set (e.g. suspend is set) upon initialization.

I have the same problem with stable releases mr3 and mr4. When I build mr2, I can connect both
kdp and jdb, but if I want to step through the midlet, I get the same IllegalThreadStateException
as mentioned in one of the posts in the forum thread at the above link. I don't know if it ever
worked, but something must have changed.

I built cldc with the following flags:

and I built midp with the following flags:

Am I doing something wrong, or is debugging with kdp/jdb broken or deprecated?


I also downloaded the Java ME SDK 3.0 for windows, followed the manual and installed the Sun
Java CLDC Emu on my Windows Mobile PDA to see if debugging that way would work. This
version of the VM cannot be used standalone, and I was hoping the build a VM with similar
features that can be used standalone and for debugging purposes. I ran the Sun Java CLDC Emu
on my PDA, ran Java ME SDK 3.0 (device manager) on my desktop, opened a sample project
(UIDemo), looked up the IP address of my PDA, and added its address with the device-address
tool (device-address add ip x.x.x.x), and after a few seconds I get to see the CldcWinceEmu1
entry in the device selector list.

Deploying and running the program on the Sun Java CLDC Emu fails, but that is probably
because the midlet is installed OTA from my desktop to the PDA. The PDA initiates the http
download request, but cannot connect directly to my desktop (in a private class B 172.16.x.x

Jad URL for OTA execution: http://localhost:8083/servlet/org.netbeans.modules.mobility.project.jam....
Starting emulator in execution mode
Installing suite from:
Exception during install (1)com.sun.midp.installer.InvalidJadException: Reason = 1
com.sun.midp.installer.InvalidJadException: Reason = 1
- com.sun.midp.installer.Installer.downloadResource(), bci=873
- com.sun.midp.installer.Installer.downloadJAD(), bci=214
- com.sun.midp.installer.Installer.installStep1(), bci=31
- com.sun.midp.installer.Installer.performInstall(), bci=113
- com.sun.midp.installer.Installer.installJad(), bci=75
- com.sun.midp.odd.ODTEngineBase.installApplication(), bci=103
- com.sun.midp.odd.ODTEngineBase.executeMIDletSuite(), bci=23
-, bci=269
- com.sun.jme.remoting.RemotingHandlerImpl.executeCommand(), bci=37
-, bci=83
-, bci=5
*** Error ***
A problem occured during deploying application from

Debugging with Sun Java CLDC Emu running in the Windows Mobile device emulator is not an
option as I cannot use VirtualPC to set up the virtual network connection, and connecting the
WM emulator through the cradle does not work with Java ME SDK 3.0 (Note that I can browse
the internet within the emulator when using the cradle connection) .


I then tried to enable the "on device debugging" feature and followed some online documentation:
* On-Device Debug of JavaME Applications
* Develop MSA Applications on real device
* phoneME Feature Software (MR4)
* PhoneME Feature MR4 plugin

I got the odd.jar from the precompiled mr4 windows build (I also tried the jmesdk-odt.jar
implementation of the phoneme feature mr4 plugin for Java ME SDK 3.0 but I had similar

I added the following flags to the midp settings:

I then started the ODT agent as follows from the command line (and started the server):
runMidlet_g -1 com.sun.midp.odd.ODTAgentMIDlet

I checked that the socket is opened, just by telneting to the port 55123. This appears to be
the same port that the Sun Java CLDC Emu VM of the Java ME 3.0 SDK is using. I assume
the latter is just a simple VM that launches the ODT Agent behind the screen so that you
can deploy and run midlets from within the Java ME 3.0 SDK. Unfortunately, I could not get
my builds to work.

So basically, I would like to know how I can either use kdp/jdb with a "recent" phoneme feature
snapshot, or how to use my own odd-enabled phoneme feature build for debugging midlets on
a real device. I have looked around quite a lot for online documentation, so any help is much

Kind regards,

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2007-09-24

Hi Davy,
regarding to the problem no. (1), it seems that KDP does not connect properly to the VM (in that case KDP is running but doesn't pass JDB's commands, which would explain hanging JDB). You should see handshake results in KDP output. You can also try to increase KDP verbosity by -v argument (value up to 9) to see whether the commands are passed on.

Just an idea: please check the VM debugging port you are connecting to, the default port was changed in the past from 2808 to 2800 for some builds and I'm not sure whether setting custom port works in all builds. You can try these two port numbers if KDP has problem to communicate with VM.

Please note that the "suspend when debugging session starts" behavior is not implemented. You can try passing -suspend argument to the VM which activates initial suspend.

Hope this helps,

Joined: 2007-01-03

Thank you both Lubomir and Pavel for your answers.

In the meantime, I was able to use Java ME SDK 3.0 to debug midlets on my PDA. Like I initially presumed, the problem occurred due to the fact that my desktop system was connected on a different subnet unreachable by my PDA. So (2) is fixed.

Before I posted, I did a port scan on my PDA to know which ports were opened by Sun Java CLDC Emu VM and my own VM. I am pretty sure that I connected to the right port. KDP prints messages when it cannot connect anyway. This is what I get with verbose logging on.

Path array length is :2
KVMListener: attempting connection
KVMListener: got connection Socket[addr=/,port=2808,localport=39499]
Waiting for debugger on port 2810
Debugger connection received. Socket[addr=/,port=37825,localport=2810]
DebuggerListener: start: 37825: Sending through: Virtual Machine(1)/IDSizes(7)


With "suspend when debugging session starts", I actually mean that when I start a midlet with the -debug option, I noticed a difference between phoneme feature mr2 on the one hand and mr3 (and following) on the other hand. With mr3, the midlet runs as it would without the debug option. With mr2, the midlet is loaded but not executed. With a debugger I can then step through the program.

I will try out the ODD debug hints to see if they help.


Joined: 2006-10-19

Hi Davy,

I'll try to aswer some of your questions:


Check your firewall settings. It seems that it blocks the incomming tcp connections from the device.


It is not enough to start the ODT agent, the JAMS needs to be running as well. Try to run the "com.sun.midp.appmanager.MVMManager" MIDlet with "-runodtagent:autoStart=true,pinRequired=false,signedOnly=false,startInBackground=true" as an argument.

Best regards,