I Want To Want You
Is MIDP evolving too slowly?
There's been a pretty interesting thread about the progress and future of MIDP going on in the forums. It started with
Just curious. What's the current status of midp3 (aka jsr 271).
It's been 4 years in the running. Why is it taking so long? When will it be finished?
Some of the replies pointed out that MIDP 2.1 phones have barely hit the market, and that the MIDP 3 spec is due in the first half of 2009, with compatible devices out in Q1 2010. If that seems too long... maybe it is. On yesterday's front page, we featured
Yeah, MIDP 3 has been in the works too long. I think part of the problem is that it grew in requirements substantially over time and there were quite a few technical challenges. It defines much improved application management and concurrency, shared libraries, new security model aligned with CDC, the basics of a service framework, inter-midlet communication, and a bunch of other things. Still, it took too long IMO (release early, release often ...).
Daniel Rocha, who has been particularly active in this conversation sees this as a problem with the entire JCP process:
Having to accommodate multiple interests from multiple stakeholders who are donating their time to the expert groups while holding real world jobs seems to be slowing down the process for defining more complex specifications.
My basic argument is that proprietary technologies are progressing much faster than Java ME, which makes them suitable for innovative applications. Java ME these days looks mostly a platform for simple games and enterprise (forms) applications. One of the main reasons for this IMO is the overall slowness in releasing new specs.
Evidence: even Nokia, known for having a pretty standard implementation of Java ME, is starting to adopt proprietary extensions and APIs as a way to ensure requirements from developers and operators are met without having to wait for new JSRs.
I think we know who he's talking about in terms of proprietary technologies in the mobile space (no, not Android, that's largely open-source). But is that an appropriate comparison? The smartphone APIs are running on more desktop-like stacks -- the iPhone's roots trace back to Mac OS X on the desktop, not to other small devices. And not every phone can or should be a smartphone. Maybe MIDP's role is to be the API for the everyday device, not the luxury device. Or maybe not... doesn't the luxury usually become commonplace in our industry? After all, that was James Gosling's much-misunderstood point that "over time, it's pretty clear that JavaME and JavaSE will converge and become largely indistinguishable." But, then again, if Java SE and ME are converging, then why do we need MIDP at all?
Or maybe the problem is that we've got so many levels of capability that the reality is hard to make out. After all, embedded Java might mean CLDC, CDC, or even JavaFX Mobile. Maybe it makes sense for each to follow its own evolutionary course and find appropriate markets... so long as we're clear on which is which.
We're in an era where "ME" doesn't automatically mean CLDC/MIDP. If MIDP is indeed small, limited, and evolving slowly, that may be ideal for its target class of products, while other stacks provide more capability to pricier devices.
Also in today's Forums, Jagadish Prasath Ramu provides a concise answer in the thread
Re: how to look up a resource adapter. "You (RAR developer) will provide implementations of ManagedConnectionFacotry, ConnectionFactory, Connection etc., App. developer/administrator will create a connector-resource (and connector-connection-pool). This resource will be bound to jndi, application will do a lookup and get the connection-factory (provided by your RAR) to create connections (provided by your RAR) to the EIS."