Editor's Daily Blog

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 captainfreedom asking:

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 terrencebarr's reply:

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."

Felipe Gaúcho is looking for the best way to copy SOAP <-> ORM. "Few days evaluating my options about binding my SOAP message objects to my JPA entities... Options I am considering right now: 1) Brute force, copying one by one the fields and properties from one side to another. Simple, fast and the most reliable solution, but with a lot of identical code for all entities... The number of line codes required to copy is linearly coupled with the number of entities and its attributes (can be thousands of lines to code and maintain)..."

In Java Today, Project WebSynergy Stable Build 2 [download] is now available. "This build represents a significant milestone for the team and establishes a lot of the groundwork for the future features. In addition, summer vacations and name searches have delayed us somewhat, but we are very close to getting the external community site established (see James Falkner's detailed blog post for details)."

Jasper Potts continues a series on customizing the Nimbus look-and-feel in Nimbus UIManager UIDefaults. "Nimbus is completely configured by properties in the UIManager defaults table. In my last blog I showed a simple example of how to skin a single component. This gave you a sneak peek into the power of these properties. Lots of people have asked for a complete list of properties that can be set. Well, it's simple: just grab UIManager.getLookAndFeelDefaults() and iterate over the contents of the map and print the keys and values and there you go. Well, I am not that cruel so I did the work for you and will include a link to a complete table of them at the end. But before I get to that let me explain how they work..."

In the SDN interview Meet Sanjeeb Kumar Sahoo, GlassFish Engineer at Sun Microsystems, Sun GlassFish engineer and java.net blogger Sahoo provides an update on GlassFish, discusses the Java EE portability checking tool he's writing, and offers insight into the benefits of working in an open-source community.

Today's Weblogs begin with a tutorial by Evan Summers on Automatic Binding. "We illustrate automatic binding of typical Swing input components (eg. JTextField, JComboBox) using convention-over-configuration, assuming that the names of the components in the view, match property names in presentation model."

Eamonn McManus announces JMX Event Service now available in JDK 7 snapshots. "The new Event Service that is part of version 2.0 of the JMX API is available in the latest snapshot of the JDK 7 platform."

Finally, Tom Ball provides a little perspective in It's All Just Bits. "Developers often get so involved with design abstractions that those concepts can block understanding of what's really happening during execution. Reminding yourself that "it's just bits" regularly can keep you on top of whatever problem you are investigating."

Current and upcoming Java Events :

• September 1-24 - O&B's Enterprise Architect's Boot Camp - September 2008
• September 4-6 - JSF One
• September 12-14 - New England Software Symposium 2008: Fall Edition
• September 15-19 - Java Training Philippines
• September 19-21 - Pacific Northwest Software Symposium 2008: Fall Edition
• September 22-24 - O&B's Agile Training - September 2008
• September 22-24 - O&B's Test Driven Development Training - September 2008
• September 23-26 - Java Power Tools Bootcamp in Melbourne
• September 29-October 1 - The Ajax Experience
• September 29-October 2 - Java Power Tools Bootcamp in Sydney
• September 29-October 3 - JavaEE Training Philippines

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

Comments

This work is licensed under a Creative Commons License.