Sorry. This turned into a long one and I think it comes across more negatively that it's meant to. Perhaps I've been holding all this in too long ;-)
My personal take on the history is as follows:
The current state of J2ME (MIDP-1.0 and MIDP-2.0) seems to show that Sun - with it's wonderful idea of cross-platform compatibility - has been trodden heavily underfoot by the manufacturers and network operators.
In order to get these powerful entities to adopt Java widely, compromises needed to be made to secure agreements. This meant that the specifications were too loose and contained too many mays and optionals, instead of shalls and musts.
This let implementors off the hook and allowed the fragmentation to really take hold and proprietary APIs proliferated, along with interpretations of the specifications.
It was quite evident that this was a known problem before MIDP-2.0 was released and Sun (or at least, the JCP), to it's credit, did seem to try to tie down that specification more tightly.
Personally, I really enjoy developing J2ME applications. I have a background of embedded software development and I understand the concepts of devices that are restricted in both memory and speed (for those who think it's too restricted, go and look at JavaCard!). I think that there is very little actually wrong with the J2ME concept. It's mainly about the implementation.
For any J2ME developer, number 1 on the list of real horror stories is device fragmentation. I have been to seminars by manufacturers and network operators and they are all happy to admit that this is a problem and they are all keen to resolve it. Unfortunately, they only seem to be keen on resolutions that go their way :-(
Section 2 of JSR-271: MIDP-3 appears to be addressing the fragmentation issue, particularly with statements like "Tighten spec in all areas to improve cross-device interoperability".
Perhaps second on the list, but also very high up are the attitudes of many (but not all) network operators. Walled gardens, expensive contracts, complex contracts and difficulty with device settings are just some of the common and very valid complaints from developers who want to access the potential markets without unfair restrictions.
I wouldn't think that Sun is in any position to do anything about that. Let's face it, the device manufacturers are somewhat at the mercy of the network operators.
Java Verified. Hmm. How many others have questioned this? If I have (as I do) an application written in pure MIDP-1.0, that adapts itself to screen size, colour depth, font support and keypad (and/or joystick) capabilities. An application that works perfectly on the J2MEWTK emulator and on the most restricted handset (Nokia 6310i). Why does this need to be approved on more than one device in order to become Java Verified? Surely that's Handset Verified.
This same application was accepted by a network operator for publication on their site for several platforms. However, it was not accepted on other for reasons that I found very disagreeable. One example was that one particular handset, deliberately does not display Command.EXIT options. I'm sure other J2ME developers know which devices I'm talking about. None of the native applications on this device display an exit option. Users of these devices understand that the special button either takes them back one step or exits an application. I asked them repeatedly to reconsider, even with support (though a bit half-hearted) from one of the manufacturers support engineers.
Another reason the application was rejected on that handset was that their test handsets had bugs! On my device (same make and model, but presumeably a different firmware version), my application could read the application properties (eg. version). Their devices were returning nulls. Is it reasonable to reject an application because the test hardware is faulty?
If you wish to have an application published my many manufacturers or operators, they require that it be verified (either by them or the Java Verified process), usually involving significant cost (both time and financial). This seems astonishingly unfair when you look at the state of some of the handsets. How can a manufacturer be allowed to declare a device compliant when it has bugs? Input fields should work properly, application properties should be readable, Exit options should not be added to screens by the JVM (and preferably not ignored either), the JVM should not crash when requests are made to the browser, threads should work correctly, including a MIDlet Icon should not cause an installation error to be reported, font metrics should be reported correctly, etc. etc. etc. If devices are allowed into the market with faults like these, cross-platform application behaviour cannot be achieved or relied upon.
This leads nicely to the next major issue. Upgrades to devices in the field. At the moment, I don't know of any devices that can be updated this way. It's possible, (if you know who to talk to and you're prepared to pay for it) to get device firmware upgraded, but it is not an easy process.
JSR-233 J2EE Mobile Device Management and Monitoring Specification would appear to be addressing this, but I have concerns about what else it proposes, mainly regarding privacy.
The JCP is at the heart of any improvements. It needs to be tight on the manufacturers and the specifications need to be rigidly imposed. Without rigorous testing and approval of devices for compliance to the standards, there is no point having the standards. Let's hope it all falls into place for MIDP-3.0 because it's too late for MIDP-1.0 and 2.0. We just have to live with their legacy.
One final thing worth pointing out. As a member of the JCP, I recently needed to vote to ratify three positions on the JCP Micro Edition executive committee. IBM, Nokia and Philips. I took the opportunity of asking them how they intended to reduce the fragmentation problems, so prevalent in the industry. You are allowed to ask questions because the "C" in JCP stands for "Community".
Only Philips responded. Conclusion: Watch out. Keep a close eye on the direction that the Micro Edition JSRs take and if you have the chance, comment on them to help guide the process.
Posted by: jimmack on November 07, 2005 at 09:43 AM
del.icio.us 
Digg 
DZone 
Furl 
Reddit
java.net RSS Feeds
