Vikram Goyal's Blog

Frustrated with J2ME implementation differences

I am getting increasingly frustrated with the level of differences in MIDP, CLDC and optional API's implementations. Device manufacturers are increasingly making independent rules for their implementations, so much so, that it is almost impossible to port applications from one device to another.

Take the case of Mobile Media API (MMAPI) that enables MIDI, tones, audio and video in your MIDlets. The specification for this API is ambiguously written, in parts. You are guaranteed to have major headaches providing workarounds for different devices. Part of the blame lies with the device manufacturers as well, who provide arbitrary implementations with their own understanding of the specifications.

A specific case relates to the supports.mixing property. If true, the MMAPI implementation must provide the ability to play two sampled audio files simultaneously. But can you? No. Several implementations decide to interpret it as a combination of a MIDI file AND an audio file, rather than two pure sampled audio files. Others, decide to make available the mixing of two MIDI files, ignoring sampled audio completely. Still others give even worse results, by only allowing mixing of tones. The API is specific in this regard and mandates the support for mixing of two sampled audio files, if this property is true.

So, who suffers due to this? Content developers and consumers.

The solution, in my opinion, is for Sun (or any other regulatory body), to certify the implementations of MIDP, CLDC and ALL optional API's as conforming to the specifications. Developers will then know, which implementations they can confidently work against.

It is not such a difficult task. There is already a Java Verified program for certifying applications. Why can't we request the same level of momentum and commitment from device manufacturers and Sun?

I am even open to a third party being set up to provide this compliance against the specifications. There is an increasing number of optional API's coming out, all of which will lead to even more frustration and incompatibilities. Surely there is a market here for somebody to grab. Only if the device manufacturers would be willing to play ball.

Comments

• Doesn't NetBeans IDE Mobility Pack solve much of this issue with its solution to device fragmentation? Isn't this what you're talking about, device fragmentation? Take a look at http://www.netbeans.org/kb/articles/tutorial-j2mefragmentation-40.html Although this tutorial is based on NetBeans 4.0, I think you can follow the same instructions and use NetBeans 5.0 (which is in rc1 as of yesterday).

  Posted by: huntch on January 13, 2006 at 04:09 AM

• Hi huntch,

  In a way it is. But really, as far as optional API's are concerned, if they do not follow what is specified as mandatory in the specification, then they are breaking the spec.
  

  Posted by: gvix on January 13, 2006 at 04:23 AM

• The only real solution is to introduce "verifiable compatiblity" into the market: allowing anyone to verify the compatiblity claims of vendors by letting anyone run the compatiblity test suites without restriction.

  If a device has a bad implementation in some area of some spec, as a developer and user, I want to be able to find out about it, and do something about it, like recommend a different device to my customers. Currently, it is unfortunately legally impossible for anyone but the device vendor to verify if the compatiblity claims hold water.

  Unfortunately for users and developers, Sun is not intersted in letting them verify the compatibility claims of vendors, since Sun is selling the Java brand to the device vendors. Letting people independently verify the validity of the compatibility branding would endanger that business model, as far as I can tell.

  cheers,
  dalibor topic

  Posted by: robilad on January 13, 2006 at 07:59 AM

• I completely agree with you, because I have the same experience. J2ME implementations are not compatible. It is real state of things. :(

  Posted by: ahanys on January 14, 2006 at 05:03 PM

• I think that NetBeans' solution to device fragmentation is solving the issue at great length. If you know which device is causing problems, you can a) code a work-around, b) ommit certain functionality for that device, because a work-around is (nearly) impossible, c) provide a message stating that the device is not supported, d) do something else.

  The core of this problem, of course is the fact that we all want standard API's for mobile devices from a developer's point of view, but at the same time we all want the most hip and advanced technology in our mobile from a user's point of view. There's no way you can expect the standards to follow the technology in the same pace. And then there are the networks, some restrict the device to a certain point that a deviation from a standard is the only way to get certain functionality in the device. We all complain about the devices, but we never seem to complain about the networks.

  I agree that an official quality check on compliance with the spec would be of great benefit, but my question is: What would it really bring? Does it stop the vendors from implementing bad implementations? How much of a selling point is Java on the mobile phone? Is there already an application that is such a killer app that you have to support or else you wouldn't sell the device? The certification would only be for us, developers. Nokia, Sony-Ericsson and Motorola takes their developer's community rather serious and from experience I know that what I develop for Nokia runs on a Sony Ericsson (apart from screen resolution size dependent stuff). Motorola seems another issue, since I haven't been able to get my MIDlets to run in their emulator, but that's another story.
  The other vendors are already with their emulator deviating from the WTK (imho the standard for development) or have no real support at all. From a user's point of view, the certification wouldn't be a selling point, not at the moment, I think.

  Let's not forget, the vendors want to sell mobile devices, as much as possible and with as much profit as possible, this means that any shortcut possible in implementing a standard, or any deviation from it they get away with is ok for them. As long as there isn't really something in it for them to stick with the standard, they won't. And no 'not being certified' is not a big issue, since being Java certified is still not a big issue in consumer-country.

  If there would be some (semi) official database that would contain known issues, limitations etc for the various devices, something like J2ME Polish already has, it would be of great benefit to all of us. I had to optimize for a game the images I am using to a point that I moved away from PNG towards JPG because of the size-quality ratio. Then I tried to deploy to a Samsung E760 phone and found that it couldn't cope with the JPGs so I switch back to PNGs just for the Samsung (using Netbeans' device fragmentation this was a breeze).

  As a final thought; if your application would not run on 40% of the devices out there and part of your market would not support some functionality according to the specs, do you ignore them or do you create a work-around? As long as your application doesn't have the 'killer app features' that would make people switch to a device that does support the feature, you (and I and all of us developers) are at the loosing end of this discussion.

  Iwan

  Posted by: ieising on January 16, 2006 at 12:48 AM

• Some excellent points here Iwan. Thanks.

  Vikram

  Posted by: gvix on January 16, 2006 at 01:49 AM

• 盛大金属制造有限公司是以生产钢管、无缝钢管、无缝管以及销售为一体得大型文件柜更衣柜流通企业。我们提供论文发表和同声传译同声传译设备等Google排名服务，专注于企业的SEO优化培训！

  Posted by: jlj714 on October 21, 2007 at 08:04 PM

• 网站优化-搜索引擎优化-Google排名-Google左侧排名-SEO

  Posted by: jlj714 on October 21, 2007 at 08:08 PM

• 博澳流水线以丰富的经验和先进的计算机辅助设计生产线来满足客户的要求，设计出合理的工业流水线.
  

  Posted by: sunhuanjun on November 18, 2007 at 11:06 PM

This work is licensed under a Creative Commons License.