Sun "takes back control" of J2ME [Sun's Java Website]
Those of us engaged in wireless services were beginning to wonder exactly where J2ME was headed, or more accurately MIDP, and why it didn't seem to be on the right track. Clearly MIDP 1.0 is woefully inadequate. It had many missing features just in terms of its basic capabilities, nevermind the higher system functions that a mobile environment must have - like a push mechanism, interactivity with the user's PIM functions and so on. Meanwhile, MMS and video phones have pushed the services capability of phones beyond what MIDP 1.0 is capable of. Hence we have ended up with a situation where Vodafone have released their own extensions (NOT open source) and the Java Community Process is hosting apparently unconnected efforts to usefully extend MIDP: such as the Wireless Messaging API (JSR 120) and Mobile Media API (JSR 135) that run on top of MIDP 1.0.
Clearly other extensions are needed, like location-based API capabilities, better authentication techniques, MMS handling and so on.
Thankfully, Sun has recently announced a new industry initiative and specification for the future of Java on the handheld devices. This is called JavaTM Technology for the Wireless Industry (JTWI) and is running within the Java Community Process, with good industry backing, as specification JSR-185.
In their roadmap, they seem spot on with considering the following questions:
-
Given the potential number of optional JSRs that might be associated with MIDP, how can we ensure that each is architecturally coherent with the other pieces in a handset?
-
How can content developers and operators know when new APIs will be available in real deployments, so they can take advantage of them?
-
When would a product manager be able to rely on those APIs to define them as features in new devices?
Any operators with a keen interest in generating revenue from MIDlets should probably be involved with this process.
3:52:34 PM 
|
