Frequently Asked Questions

• Verified and Deployed Directories Causing Errors
• Unable to Restore Workbench State
• "KVM Not Ready" when debugging
• Why does my midlet suite have an "Unspecified Platform"?
• Why does Eclipse say my "build path is incomplete"?
• Couldn't get ClassFile object for signature cmd
• "Could not find jar tool executable" When Packaging
• When I try to debug my MIDlet, nothing happens
• When I try to debug my MIDlet in OTA mode, I get an error "No midlets defined in JAD File."
• How do I include images or other resources in the generated JAR file?
• How can I share classes across several Eclipse projects?
• Why doesn't the "resource directory" feature work?
• Why does my device complain that my app is invalid?
• Why are classes from a JAR file or dependent project not being included in my deployed application?
• Why does the emulator crash when debugging?
• Why do I see preprocessor errors?

Verified and Deployed Directories Causing Errors

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.

As of version 0.4.0 of EclipseME, these exclusions will be automatically added when creating a J2ME Midlet Suite in which the source folder and project folder are the same.

Unable to Restore Workbench State

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 J2ME preferences. This is a minor error that will only occur once per perspective. See migration information for more details.

"KVM Not Ready" when debugging

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.

Why does my midlet suite have an "Unspecified Platform"?

In previous versions of EclipseME, it was very easy to lose the platform definition information associated with a Midlet Suite project. This could cause any number of problems. If this occurs, EclipseME 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 J2ME Properties.

Why does Eclipse say my "build path is incomplete"?

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"?

Couldn't get ClassFile object for signature cmd

This error occurs because Eclipse doesn't currently request class prepare events for all classes. See EclipseME bug 904266 and Eclipse Bug 50531 for further information.

"Could not find jar tool executable" When Packaging

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. EclipseME searches for the jar executable within the "Installed Java Runtime Environments" in your Eclipse installation. EclipseME 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.

When I try to debug my MIDlet, nothing happens

Verify that you made the required changes to the debug settings. For details, see the appropriate section of the installation instructions.

When I try to debug my MIDlet in OTA mode, I get an error "No midlets defined in JAD File."

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

How do I include images or other resources in the generated JAR file?

In an EclipseME 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:

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

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

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

How can I share classes across several Eclipse projects?

With standard J2SE applications, we are used to the fact that a single application may be composed of multiple JAR files. With a J2ME project, however, that is not the case. All of the classes that are part of the MIDlet suite, with the exception of the J2ME 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 EclipseME projects. EclipseME 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, EclipseME will pull classes from "child" projects into your MIDlet suite JAR file.

To make this work properly, however, you need to do the following:

1. Any project, dependent or otherwise, that uses J2ME classes should be converted to an EclipseME project. You should not directly add J2ME libraries to the build path, even in a "utility" library - let EclipseME do it. Any library that is part of a project's build path that is not part of a J2ME 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.

2. "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 J2ME libraries. Thus, note that, in the following support library project, the project source and resources are exported, but the J2ME library classes are not:

   

   EclipseME adds the appropriate J2ME classes to each EclipseME project, so exporting these classes across projects is not necessary. If the "child" project exports its J2ME library, then unexpected things could happen, for example, if the two projects got configured to use different toolkits or platforms. This could include:

   • The "parent" project binding to the wrong version of classes (the exported "child" ones instead of its own.
   • EclipseME wasting time preverifying classes in the "child's" J2ME libraries that don't need preverifying.
   • EclipseME bundling specialized classes from the "child's" J2ME library into your MIDlet suite.

Why doesn't the "resource directory" feature work?

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.

Why does my device complain that my app is invalid?

There are several reasons this might happen:

• You may have designed your application to require MIDP-2.0 or CLDC-1.1, while the device in question only supports MIDP-1.0 or CLDC-1.0. Make sure that the settings in the JAD file are correct, and that you have selected the appropriate platform definition in your project's properties.
• You may have compiled your application using external (device-supplied) JAR files that are not present on this particular device. See Adding JAR Files to a MIDlet Suite for more discussion on this.
• You may have compiled your Java classes using a class file format that is not supported by your device. See Best Practices for more discussion on this.

This list above is not exclusive, of course, but we find that these conditions cause the majority of the problems.

Why are classes from a JAR file or dependent project not being included in my deployed application?

Beginning in release 0.9.4 of EclipseME, 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.

Why does the emulator crash when debugging?

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.

Why do I see preprocessor errors?

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 EclipseME." in the Problems View for your Java file, you have not correctly completed all of the installation instructions for EclipseME. 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.