Why Should My Company Get Involved with MTJ?
Craig Setera — November 30, 2008 @ 1:58 pm — Miscellaneous
I find myself in an interesting position with the Eclipse Mobile Tools for Java project. Despite the fact that I am the original author of much of the current MTJ code as part of the EclipseME project, I have no corporate interest in MTJ. My goal has always been to build a solid set of tools for use by developers like myself for developing for JavaME. I wanted to allow a developer to target as many different devices as possible without ever leaving the Eclipse-based tooling. Let’s face it, JavaME is hard enough to deal with and having good tools really does help.
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.
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.
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 .
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.
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.
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.
December 1st, 2008 at 5:34 pm
Huzzah! I could not agree more. I would add one other point, on-device debugging would be a HUGE advantage if it could also be done in a common way. I don’t know how emulators work, but if a real device could provide the same interface as an emulator then on device debugging may also be possible. Alternatively, the ability to use profilers on the “real” device would also be a HUGE advantage. Apple has really nailed this one, using XCode and Instruments I can work with a very accurate emulator but also debug on device easily. Now if only the J2ME world could function the same way we may actually see more compelling content for those devices. As it stands now, it is just too expensive to create software for a broad range of devices.
December 1st, 2008 at 5:42 pm
At least some of the JavaME vendors do support on-device debugging. Nokia, SonyEricsson and Motorola all have at least some devices that allow for this using the standard JDWP protocols. As you say, it is great. Given the addition of Android to the on-device debugging picture, I expect this will only grow as a “requirement” for developers.
December 2nd, 2008 at 6:45 am
Excellent post Craig! Productive developers produce more valuable applications more quickly and without those applications, the hardware is useless. It seems a simple and obvious motivation to provide good tools, but sometimes it’s very important to point out what might seem obvious to you because it’s not always obvious to everyone.