Thanks to the help from Motorola and the other members of the Eclipse Mobile Tools for Java project, the EclipseME code has grown and matured far beyond what I could have done in my own free time. There are many more support options now available and users should find a much smoother environment. If you need any proof of the commitment from members of the MTJ development team, take a look at the developers mailing list request to begin work on the first service release beyond MTJ 1.0.

I’m looking forward to continuing my involvement with the MTJ project going forward both as a code committer and as a voice for the average mobile developer. I want to thank all of the users of EclipseME over the years for their continued support and urge you to make the jump to MTJ if you have not already. The final Galileo release is scheduled to be available on June 24th, but the versions available right now are pretty close to what you can expect at that time. The differences between this first MTJ version and the last EclipseME release make it a very worthwhile upgrade to your development environment.

Note that I’m in the process of moving all of my Eclipse, MTJ and EclipseME blogging over to my new site. Please update your bookmarks accordingly.

For more information and to register, see the Eclipse Live announcement.

Release 0.9.1 of the MTJ project is available to download from the MTJ website. You can access the release from:

Download site: http://download.eclipse.org/dsdp/mtj/downloads/drops/R-0.9.1-200812231340/index.html
Via update manager: http://download.eclipse.org/dsdp/mtj/updates/0.9/stable/

Below is a list of the main new features that are available in the new release:

• Multidevice support: each MTJ project can now have several devices associated to it
• Preprocessor enhancements: there is code assist on the preprocessor tags
• MIDlet Unit Test Support: it is possible to create unit tests cases/suite to MIDlet classes. The tests can be packed with the MIDlet suite
• MIDlet localization: There is now one option on the MIDlet suite to localize all Strings that are used on the MIDlet Suite
• MIDlet suite libraries: There is a new extension point that can be used by content developers to provider libraries that can be packed with the MIDlet suite
• Import Symbol Set definitions: Besides creating symbols and symbols set, MTJ users are now able to import predefined symbol sets based on Antenna format
• Content assist on the JAD Editor

In this release, besides the valuable community contributions during conference calls, email discussions and bug reports, there were code contributions from the following companies:

• Craig Setera (individual)
• Inlogic Software ltd
• Motorola
• Nokia
• Sybase

Thanks for the hard work of everyone that contributed to this release.  The project will be scheduling a call in early January to talk about MTJ 1.0 scope.

setera@ubuntu-laptop:~/software/wtk252/bin$ ./emulator
./emulator: 26: /usr/lib/jvm/java-1.5.0-sun/bin/java: not found

Ah Ha! My emulator installation is broken. What’s going on?

setera@ubuntu-laptop:~/software/wtk252/bin$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)

Sure enough, I remember recently updating my Java installation on this machine and deleting the older Java 5 installation. Of course, I had forgotten that the Sun WTK writes these files during installation. Edit the emulator file with a text editor and sure enough you can see that the installation path is hardcoded within the shell script file.

#!/bin/sh
javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/

In fact, all of the shell scripts in the WTK bin folder have the incorrect Java installation folder.

setera@ubuntu-laptop:~/software/wtk252/bin$ grep "/usr/lib/jvm/java-1.5.0-sun/bin/" *
defaultdevice:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/
emulator:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/
i18ntool:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/
ktoolbar:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/
mekeytool:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/
prefs:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/
siptool:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/
utils:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/
wscompile:javapathtowtk=/usr/lib/jvm/java-1.5.0-sun/bin/

A bit of searching on my machine tells me that Java is linked into /usr/bin.

setera@ubuntu-laptop:~/software/wtk252/bin$ which java
/usr/bin/java

The safest configuration is to point to the actual installation folder. Following a few links yields the installation path of /usr/lib/jvm/java-6-sun/jre/bin

setera@ubuntu-laptop:~/software/wtk252/bin$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 2008-11-02 07:18 /usr/bin/java -> /etc/alternatives/java
setera@ubuntu-laptop:~/software/wtk252/bin$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 36 2008-11-02 07:18 /etc/alternatives/java -> /usr/lib/jvm/java-6-sun/jre/bin/java

Editing the shell scripts and replacing the incorrect Java installation path with the correct path corrects the WTK installation and allows it to be used within MTJ again.

setera@ubuntu-laptop:~/software/wtk252/bin$ ./emulator
Syntax:

emulator [arguments] <Application>

If you end up having trouble importing or otherwise running a Sun WTK emulator on Linux, you may want to try looking at your installation to see if you have a similar problem.

I’m still working out the details of my travel arrangements.  With any luck I will have some extra time to talk to those that may be interested in more details of MTJ.  If you have any interest in using or consuming MTJ, take some time to stop by these presentations.

As part of my day job at mFoundry (http://www.mfoundry.com), we deal with more than 100 different devices.  Many of those devices have their own requirements and quirks that need to be dealt with in order to get a working product.  Some of the issues we deal with from day to day include:

• Different available memory space - Always very constrained
• Different screen size
• Variety of bugs and quirks
• Different tools and emulators

The last bullet item is one of the most frustrating, since it is really not necessary.  Being forced to switch from one set of tools to a different set in order to work with one manufacturer’s devices really should not be necessary. 

Getting Involved

There are quite a few different ways that a corporation can get involved with a project like the Eclipse Mobile Tools for Java.  Each involves different amounts of commitment and investment.

• Accurate Emulator Support
  Developing for hundreds of different devices does not scale very well if each developer needs to have each device in-hand in order to do their job.  Proper emulator support is extremely important for developer productivity.  Emulators need to be as accurate as possible.  It is not just about screen size, but also includes things like accurate fonts, concurrency behavior and networking behavior.

  Excellent emulator support matters whether or not your company plans to be supported on platforms like Eclipse Mobile Tools for Java or Netbeans.  By adding proper Universal Emulator Interface (UEI) support to an emulator, it can then be imported into MTJ and used alongside all of the other mobile device emulators.  Emulators that may be consumed by MTJ are a huge step for developer productivity.

• Provide a Branded Solution
  The Eclipse Public License makes it easy for companies to consume the Eclipse Mobile Tools for Java and brand them to meet their needs.  There is no requirement to be directly involved in the MTJ project in order to repackage MTJ as a branded solution.
• Participate in the Development Conversation
  The Eclipse Mobile Tools for Java project is a truly transparent project in which anybody can participate.  The first step to getting involved with the development of MTJ is to join the developer’s mailing list.  This is the place where discussions take place about the development of MTJ, including schedules, features and bug fixes.  For more information see this page.
• Provide Patches for Bugs and Features
  If you choose to consume MTJ, you will inevitably find a bug or new feature that you would like to see taken care of.  This is where you can take advantage of the transparent process for the Mobile Tools for Java and provide a patch that resolves your issue.  You don’t need to be heavily involved in the overall project to be able to contribute.  All contributions are welcomed.  Given enough good contributions, developers may become committers on the project and have more freedom in their checkins.

Why Get Involved?

There are a number of options mentioned that really don’t require significant involvement in the Mobile Tools for Java project.  While I’m obviously biased, let me throw out a couple of reasons that I believe getting more involved in MTJ makes sense.

• Software Development Leads to Hardware Sales
  At the end of the day, device manufacturers want to sell devices.  The ability to find good software for devices is increasingly driving device sales, as evidenced by the Apple iPhone and Android Market stores.  Having excellent tools for software development does not compete with hardware sales and instead increases the interest in those devices.  Using MTJ as the base for your company’s tooling improves developer usability at a much lower cost to your company.

• Influence Over Project Direction
  Many of the opportunities for consumption of the Mobile Tools for Java require little or no involvement in the development of the project.  If your company does not get involved in the project, you will need to take the output of the MTJ project as-is.  On the other hand, getting involved with the MTJ project allows for more influence over the direction of the project.
• Easy Developer Consumption
  Development tools in any form are always a good thing.  With that said, development tools that are integrated and easily accessible from an integrated suite such as Eclipse Mobile Tools for Java make it much easier for developers to use those tools.  This does not need to imply a lowest-common-denominator solution for developers.  For instance, if you provide a great set of media management tools, there is no reason that those can’t be hosted within Eclipse as well.  This allows developers to use the basic software development functionality in a consistent way using MTJ while still having easy access to your value-add tools as well.

New readers may find these recent posts on the transition to MTJ from EclipseME of particular interest.

• Converting From EclipseME to Mobile Tools for Java
• Why Switch to Eclipse Mobile Tools for Java?

These articles are primarily focused on use of the Mobile Tools for Java. I’ve recently had some interesting conversations with people in the mobile industry that lead me to believe it is time to address the question “How and why should my company get involved with the MTJ project?” I will attempt to provide my perspective on those questions in an upcoming post.

There have been a number of questions about why someone might want to switch from EclipseME to the Eclipse Mobile Tools for Java project. While I can understand why someone might ask that question if things are “just working” for them with EclipseME, there are a number of good reasons to make the switch.

It is important to note that there are no plans or reasons to create new releases of EclipseME. Everything that EclipseME had made available is now available in MTJ. Any time that I choose to apply to this hobby will be made to the MTJ project rather than making new changes to EclipseME.

Read on to see some of the reasons for transitioning to Eclipse Mobile Tools for Java.

• New Features
  • Device Management
  • Create MIDlet Suite
  • Debug Settings Warning
  • Preverification
  • JAD Editor
• Bug Fixes
• More Support

New Features

There are a number of new features in the 0.9 release of MTJ compared to EclipseME 0.7.9. These new features add a new level of polish versus EclipseME.

Device Management

Device management has been improved in a number of ways within MTJ.

When importing devices, it is now possible to have preprocessing symbol sets automatically created by MTJ. The Symbol Set preferences dialog can then be used to manipulate the symbols.

The Device Management dialog now allows for filtering the displayed devices via the drop-down at the top of the page.

Create MIDlet Suite

The Create MIDlet Suite dialog has been enhanced to bring it in line with the current Java project creation dialog.

Debug Settings Warning

Debug settings have been difficult to get set correctly for debugging Java ME emulators. MTJ now warns of incompatible debug settings and will even update debug settings to make them work for the emulators.

Note: In this snapshot you can see that both EclipseME and MTJ are loaded. The easiest way to distinguish the two plugins is the use of J2ME and Java ME. MTJ has been updated to use “Java ME” throughout.

When incompatible debug settings are found during launching, this dialog will be shown. If Yes is chosen, MTJ will alter your debug settings to allow for correct debugging of Java ME emulators.

Preverification

The “embedded” preverifier has been removed in this release. Instead, it is now possible to specify a default preverifier executable to be used for SDK’s that do not contain an preverifier such as Microemulator and MPowerplayer.

JAD Editor

The JAD Editor has received a large number of improvements in MTJ. The Overview page has been cleaned up and allows for more interaction with the project.

Motorola Specific Properties

A new page has been added to edit Motorola-specific JAD properties.

Nokia Specific Properties

A new page has been added to edit Nokia-specific JAD properties.

Push Properties

A new page has been added to edit Push JAD properties.

JAD Source

A new page has been added to directly edit the source of the JAD properties.

Bug Fixes

There have been a ton of bug fixes and polish work in MTJ 0.9 relative to EclipseME 0.7.9.

More Support

The EclipseME project has always had strong support via the user’s mailing list. There have been some great users on the list that have jumped in to help with support whenever they possibly could. That is something I’ve always been very proud to see. Despite that, support is always difficult and hard to find time for. By moving to MTJ, users will be able to take advantage of a larger support group.

Some of the options for support are listed here.

• Eclipse Mobile Tools for Java Web Site
  The root of the Eclipse MTJ web space.
• User’s Newsgroup
  Eclipse projects use Usenet Newsgroups for user interaction. This is the place that EclipseME users should go for help with MTJ.
• Developer’s Mailing List
  Eclipse projects use mailing lists for project development discussions. User’s should not use the mailing list for questions about use of MTJ. For those questions, please use the newsgroups.

EclipseME Users Mailing List

While I will keep the EclipseME user’s mailing list open for a while, it will eventually be phased out to pure MTJ support options. This is due in large part to the fact that as MTJ continues to grow, it will be difficult for me to keep track of the details and really provide useful support. The sooner that everyone makes the transition to MTJ support, the better it will be.

UPDATED: It turns out that the original steps I documented for doing the conversion were incorrect. This post has been updated to specify the use of the Eclipse Import wizard to import EclipseME projects as MTJ projects.

UPDATE 2: Added instructions for upgrading preprocessor hooks configuration.

Now that EclipseME forms the base for the new Mobile Tools for Java project, it is now time for EclipseME users to convert to using MTJ. The conversion from EclipseME to the Eclipse Mobile Tools for Java project could not be any easier. Given that Eclipse MTJ is based on the last release of EclipseME, it should be very comfortable for all EclipseME users. The primary thing that may trip up EclipseME users are minor text changes throughout the tools.

There have been a number of questions about why people might want to make the switch over to MTJ. My next post will cover some of the cool new features in MTJ versus the last release of EclipseME. (Not to mention the many bug fixes that were made.)

Making the switch to MTJ involves three primary steps:

1. Install the Mobile Tools for Java Support
2. Convert EclipseME projects to Mobile Tools for Java projects
3. Configure Preprocessor Hooks
4. Uninstall the EclipseME Support

Install MTJ

It is possible to install MTJ using an Eclipse Update Site or by downloading an installable archive file. MTJ requires at least version 3.3 of Eclipse. I would suggest that you move to Eclipse 3.4 for the best experience. This examples shows the installation of MTJ into Eclipse 3.4 using the update site.

1. Open the installation dialog via the Software Updates… menu item in the Help menu.
2. Switch to the Available Software tab of the dialog.
3. Press the Add Site… button
4. Enter the MTJ Update site URL: http://download.eclipse.org/dsdp/mtj/updates/0.9/stable and press OK

1. Expand the update site
2. Select the MTJ features of interest

Follow the prompts through to complete the installation of the Eclipse Mobile Tools for Java
project plugins.

Import Devices into MTJ

The devices in EclipseME will not be brought over automatically. Import your devices into MTJ so that they are available when importing your your project into MTJ.

Convert EclipseME projects to Mobile Tools for Java projects

The MTJ project provides the ability to convert an EclipseME project over to a Mobile Tools for Java project. This functionality is implemented in the as an Import wizard, requiring a number of steps. There are likely other ways to handle this import operation, but the following steps are relatively straightforward.

Delete the EclipseME Project

In order to import the project as an MTJ project, it is necessary to delete the project from the current workspace. The delete operation must be done carefully to avoid deleting the project from the file system.

When prompted, make sure that the Delete project contents on disk radio box is not selected to avoid accidentally deleting the actual project contents. When this is done, the project is deleted from Eclipse, but not from the file system.

Move the EclipseME Project

In order for the import wizard to find the EclipseME project for the conversion, it must not be located in the workspace folder on the file system. Find the project in your local file system and move it to another location.

Import As EclipseME Project

Launch the Import wizard from the File menu. When the wizard dialog is displayed, choose EclipseME Project from the Java ME category.

When prompted, specify the folder holding your EclipseME project file in the location that it was placed when moved. The import wizard should find the EclipseME project and allow you to do the import. Once finished, the project will be in your Eclipse workspace as an MTJ project.

IMPORTANT NOTE: The way in which keystore passwords are stored has changed in MTJ versus in EclipseME. If your your project stores the keystore password within the project or workspace, you will need to re-enter your keystore password after the conversion has been completed.

Configure Preprocessor Hooks

If you are using the preprocessing support in EclipseME, you will need to update your installation to point to the MTJ preprocessor hooks library. Full information on installing the preprocessor hooks for EclipseME can be found here.. To update your installation for MTJ, change from:

osgi.framework.extensions=eclipseme.core.hooks

to:

osgi.framework.extensions=org.eclipse.mtj.core.hooks

Uninstall EclipseME

EclipseME and Mobile Tools for Java functionality overlap. If both toolsets are installed, many menus will be replicated and there will be two two Java ME categories in the preferences dialog. While not a requirement, removing EclipseME will make it easier to deal with the Mobile Tools for Java.

http://www.eclipse.org/org/press-release/20081015_mtj.php

I will follow up soon with more details about what is to come from the EclipseME project, including information about making the transition from EclipseME to MTJ. I would like to urge all EclipseME users to download the MTJ release and use the import wizard to begin the transition. EclipseME users should find MTJ familiar and comfortable. Even better, the first MTJ release even includes some new features and a lot of new bug fixes.

More coming soon…