Troubleshooting
Yes, sometimes things are broken. If MTJ does not appear to be working properly, We are happy to have you report it here. You can help us enormously, however, if you do a little legwork before entering a bug report.
Please collect the following basic configuration information:
This helps tremendously in attempting to recreate the bug.
The more detail you provide, particular step-by-step detail, the better. In particular, provide as many of the Preference settings as you can, along with a step-by-step description of what you did, what you expected, and what happened. If there's a bug in the code, I have to be able to isolate the part that's faulty, which means I have to be able to do what you did. It sounds elementary, but many times it's the exact sequence you did things, or some non-obvious interaction between settings that trigger a problem.
As you know, Eclipse stores settings and other state information in your workspace. By default, your workspace is stored in the directory named workspace within your Eclipse installation directory. You also can specify a particular non-default workspace directory using the -data command line option when invoking Eclipse.
Within the workspace directory, there is a subdirectory named .metadata. This, in turn, may contain a file named .log. Unix users, remember that files that being with the character "." are hidden by default. You will need to use the "-a" option to ls in order to see them.
The .log file contains valuable debugging information, particularly exception traces. One way to help me isolate a problem is to close Eclipse, delete this file, then run Eclipse, cause your problem to happen, and then close Eclipse again. Now look to see if a .log file has been created. If it has, include this file as part of your report.
If you have the Plugin Development Environment loaded, this same information can be more easily obtained by opening the "Error Log" view. If you don't have the PDE loaded, this view is not available.
Sometimes it is necessary to know exactly what command line MTJ generated for a particular WTK invocation. When you run Eclipse, add the arguments
to your Eclipse command line. This will cause extra debugging information to be placed into your .metadata log file. Then include the log information as described above. If you have more than one system property to be set, you only need to specify -vmargs once before them all.
If you are having trouble importing a UEI-based toolkit, add the arguments
to your Eclipse command line. This will cause extra debugging information to be placed into your .metadata log file. Then include the log information as described above. If you have more than one system property to be set, you only need to specify -vmargs once before them all.
There are a number of parts that make up your mtj development environment. Eclipse is the IDE, mtj is a set of plugins that provides a bridge between that IDE and a Wireless Toolkit (WTK), and a WTK is a development environment provided by a vendor to allow you to develop for a Java ME device. mtj's goal is simply to allow you to use the Eclipse IDE in a convenient way while developing your MIDlet, instead of having to use the WTK directly.
mtj itself doesn't have much logic specific to the implementation of the various devices being emulated or the features that they provide. All of that function is implemented in the WTK. In many cases, you may find that by eliminating Eclipse and mtj you may find further information that can be used to solve your problem. Simply load up and run your MIDlet directly using the WTK without Eclipse or mtj.
mtj doesn't provide direct support for loading your MIDlet onto any device whatsoever - it's completely device agnostic, merely allowing you to use the Eclipse IDE to "operate" the compile-and-debug features of your WTK. mtj doesn't really "know" about devices - all it "knows" about are toolkits.
A good example of this is the OTA launch feature of mtj which is simply a link to the capabilities of the WTK to allow a MIDlet to be loaded "Over The Air", in much the same way that a real device normally would. OTA debugging vs. direct debugging doesn"t really make that much difference in most situations when you're debugging your MIDlet. It is useful, however, to make sure that your JAD settings are all correct, and to allow you to simulate a few special conditions that arise once in a while.
While the new internal preverifier is a step in the right direction, it is still a work in progress. If you encounter errors while using the new preverifier, we would appreciate any information that you can provide to help improve the functionality. If you encounter errors, the more of these troubleshooting steps you can try and questions you can answer the more help your information will be. Until the preverifier has had a bit more time to mature, we would ask that you bring these discussions to the developper's mailing list so that all users may benefit from the discussions.
While any developer would rather that a bug be reported multiple times than not be reported at all, before entering a bug report, please check the current list at MTJ Bugzilla to see if somebody has already reported your problem or a similar problem. I try to keep the number of outstanding bugs fairly short, so it won't take too long for you to look through, and if somebody has already reported something similar, there may be a work-around.