Frequently Asked Questions
If the project is used as the source and output folder, trouble can occur with the verified and deployment directories. The Eclipse Java tooling assumes that the verified classes in the the verified directory should be included in the classpath, yet those classes aren't in the appropriate directory structure to match the package name for the class. When this occurs, you may see errors similar to the following snapshot.
If this occurs, it is necessary to define a set of Source Exclusion Patterns to remove the verified and deployed directories from further consideration. Those exclusions may be specified via the project's properties as the following snapshot shows.
These exclusions will be automatically added when creating a Java ME Project in which the source folder and project folder are the same.
This error can occur for numerous reasons, but the most likely reason is the fact that the Platform Components view functionality has migrated to the Mobiles Tools for Java preferences. This is a minor error that will only occur once per perspective.
It appears that the WTK Debugger is a combination of Sun's MIDP and K Debug Proxy tools, compiled together into a single executable. Normally, these are two separate tools that talk via a local socket connection. It appears that they still do this and that one half of the conversation is waiting for the other half. This warning appears in the console and does not appear to effect the operation of the debugger against the emulator.
If this occurs, MTJ will substitute in the "Unspecified Platform" for your project.
This project does not contain any libraries or other information, so it may also cause your project not to compile. To associate your project with a valid platform definition, use the Java ME Properties.
There are a number of possible reasons for this. The most likely is a problem with the project's platform definition. See the answer for Why does my midlet suite have an "Unspecified Platform"?
The process of obfuscated packaging requires that the jar file created by the obfuscation tool must be preverified again. The preverifier tool needs to be able to invoke the jar executable tool while preverifying the jar file from the PATH environment. MTJ searches for the jar executable within the "Installed Java Runtime Environments" in your Eclipse installation. MTJ must find at least one full Java Development Kit within the Installed JRE's (a subcategory of the Java category). By default, Eclipse will recognize a JRE rather than a full JDK on Windows. To solve this problem, make sure to point the location of the installed JRE instance to the root directory of the JDK directory. For instance on Windows, that might be something like c:\j2sdk1.4.2.
Verify that you made the required changes to the debug settings. For details, see the appropriate section of the installation instructions.
You did not define the MIDlet on the Midlets tab of the Application Descriptor. Use the JAD Editor to add an entry for the MIDlet.
This situation can happen when you create your MIDlet class manually, or if you do not have the Add to Application Descriptor option selected when you create the MIDlet as shown in Create a New Midlet
In an MTJ project, as part of the project build process, any Java files that are in your source folders are automatically compiled, while all non-Java files that are in your source folders are automatically copied into the build. This is standard Eclipse behavior.
In order to specify a new source folder:
Bring up the Project Properties dialog. This may be done either by right-clicking on the project and selecting Properties or by using the Project / Properties menu item.
Choose the
"Java Build Path" category from the left pane and the "Source" tab
from the tabs on the right side. Select the "Add Folder..." button.
Locate your resources directory in the list of project folders,
and place a check mark in the box to its left. Then press
OK to exit this dialog and the
Project Properties dialog.
When you do this, it is possible that you will get a dialog box that
looks like this:
Eclipse has two standard ways of creating new projects: using the base
project directory both as a source and output directory,
or with separate folders for source and output located under
the project directories. If used, these separate folders are usually named
src and bin,
respectively.
You will typically get this dialog
when your project was created with the base project directory as a
source directory. Eclipse does not support "nesting" source directories,
so if you try to designate a second source directory that is beneath
another source directory (i.e. the project directory) you will get this
error.
If you run into this situation and still want to separate your source and resources, the best thing to do is to reorganize your project. Create a new folder named "src", move all your Java files under this directory, and then designate this directory (and your resource directory) as source directories using the above procedure. As you do this, Eclipse will probably suggest shifting your output area to a "bin" folder, and will ask if you want to remove generated resources from the old location. Answering "Yes" to both questions will generally result in your project being properly reorganized.
Editorial note: It is the author's opinion that it is, in general, better to structure an Eclipse project with separate source and output folders, rather than using the base project folder as both source and output folder, even if you are not using a separate resource folder. Unfortunately, the Eclipse folks must disagree, because this is not the default setting.
Eclipse has a setting that controls whether a new project is created using
the project folder for source and output
or is created with separate source and output folders. To change
this setting, use the Windows / Preferences
menu to bring up the Eclipse Preferences dialog.
Expand the Java item in the left, and select
the Build Path item. Then select the
Folders radio button on the right, as shown below:
If you prefer names other than the default
src and bin
for the source and output folder, you can change them.
Remember that changing this setting only affects new projects that you create. If you want to reorganize an existing project, you just do it manually as described above.
With standard J2SE applications, we are used to the fact that a single application may be composed of multiple JAR files. With a Java ME project, however, that is not the case. All of the classes that are part of the MIDlet suite, with the exception of the Java ME platform classes, must be bundled together into the single JAR file that is then deployed to the mobile device.
That being said, this does not mean that you cannot share code across MTJ projects. MTJ is quite capable of handling situations in which you have multiple projects in your workspace and have dependencies between them. As part of the deployment operation, MTJ will pull classes from "child" projects into your MIDlet suite JAR file.
To make this work properly, however, you need to do the following:
Any project, dependent or otherwise, that uses Java ME classes should be converted to an MTJ project. You should not directly add Java ME libraries to the build path, even in a "utility" library - let MTJ do it. Any library that is part of a project's build path that is not part of a Java ME platform definition is assumed not to exist on the device. These libraries must then be preverified and packaged into the MIDlet JAR file. Clearly, you don't want the build process wasting time preverifying classes that are already on the device, and you definitely don't want those classes bundled into your JAR file.
"Child" projects (i.e. projects whose classes are to be included in "parent" MIDlet projects) should be checked to ensure that they export their own classes but not the classes associated with the the Java ME libraries. Thus, note that, in the following support library project, the project source and resources are exported, but the Java ME library classes are not:
MTJ adds the appropriate Java ME classes to each MTJ project, so exporting these classes across projects is not necessary. If the "child" project exports its Java ME library, then unexpected things could happen, for example, if the two projects got configured to use different toolkits or platforms. This could include:
The "resources directory" only affects a project as it is being created. Changing the setting afterwards has no effect on existing projects.
In addition, this feature only operates if you have set Eclipse to create your project with separate source and output folders. See Before You Begin in the installation instructions for how to configure Eclipse in this manner.
There are several reasons this might happen:
This list above is not exclusive, of course, but we find that these conditions cause the majority of the problems.
It is necessary to check the "export" box on the Order and Exports tab of the Java Build Path item in the project properties for an included JAR to be deployed. Similarly, the resources in a dependent project that are to be deployed must also be exported. See Adding JAR Files to a MIDlet Suite for more discussion on this.
If you have a midlet suite that seems to run fine when running but crashes under the debugger, you might have a problem with your debugger preference settings. Make sure that "Suspend execution on uncaught exceptions" option is disabled as described in the installation instructions.
If you are attempting to use the preprocessor feature and see the error "Preprocessor invoked, but hook is not installed. Consult the installation instructions for MTJ." in the Problems View for your Java file, you have not correctly completed all of the installation instructions for MTJ. Please refer to Configuring Preprocessor Support for more information.
After you have completed the preprocessor configuration, you will need to use Project -> Clean... to clean and rebuild your project. This will invoke the preprocessor and remove the errors.