The Main Issue with MSA for CLDC (JSR 248)

Updated on 9.27.05

As you may know, MSA for CLDC is in public review as we speak. If you care about the short-term future of Java ME in handsets, you should review the spec and provide feedback.

MSA for CLDC is trying to do what JTWI has done so far — define a consistent runtime environment. But while JTWI defined that a compliant handset shall consist of 5 JSRs (CLDC, MIDP2.0, WMA 1.1, etc), MSA for CLDC is defining 23!

I can see the writing on the wall, and the runtime and compatibility issues that such a complex runtime will bring with it… not to mention the cost of the handset.

Because the public review is NOW, now is the time bring up issues and concerns — you should consider doing the same.

ceo

Recently the Mobile Service Architecture (MSA) for CLDC or JSR 248 entered the Java Community Process public review phase. Now is the time to provide feedback. And I have a concern with MSA that I want to bring up. If you haven't looked at this JSR yet, you should… You will quickly realize that it is a pretty massive and complex spec.

The MSA JSR is an umbrella JSR. It's goal is to define the set of JSRs and related clarifications that a compliant handset must include — similarly to what Java Technology for the Wireless Industry (JTWI) JSR has done. The purpose is to have a consistent Java runtime environment across all compliant handsets. We all want consistency, that is not the issue. The issue is that MSA for CLDC is so massive, trying to satisfy such a large and diverse target audience with just one set (combination) of JSRs, that I don't think it is practical… The list of JSRs is next, but first, some definitions on JSR optionality:

Mandatory JSR: A JSR 248 compliant implementation must implement all mandatory JSRs and their optional packages and comply with the requirements and clarifications.

Conditionally Mandatory JSR: A JSR 248 compliant implementation must implement JSRs marked as conditional mandatory and comply with the requirements and clarifications, if the particular functionality in included on the device. For example, if support for smart card is present on a handset, the SATSA-APDU optional package MUST be supported.

The Mandatory JSRs:

1.	JSR 75 PDA File API 1.0
2.	JSR 75 PIM API 1.0
3.	JSR 82 Bluetooth (Core) API 1.1
4.	JSR 82 Bluetooth OBEX API 1.1
5.	JSR 118 - Mobile Information Device Profile 2.0
6.	JSR 135 - Mobile Media API Version 1.1
7.	JSR 139 - Connected Limited Device Configuration 1.1
8.	JSR 172 - J2ME Web Services Specification 1.0 (XML Parsing)
9.	JSR 172 - J2ME Web Services Specification 1.0 (JAX-RPC)
10.	JSR 177 - Security and Trust Services API for J2ME Version 1.0 (SATSA-CRYPTO)
11.	JSR 180 - SIP API for J2ME Version 1.0.1
12.	JSR 184 - Mobile 3D Graphics API for J2ME Version 1.1
13.	JSR 185 - Java Technology for the Wireless Industry Version 1.0
14.	JSR 205 - Wireless Messaging API 2.0 Version 2.0
15.	JSR 211 - Content Handler API Version 1.0
16.	JSR 226 - Scalable 2D Vector Graphics API for J2ME Version 1.0
17.	JSR 229 - Payment API Version 1.0
18.	JSR 234 - Advanced Multimedia Supplements Version 1.0
19.	JSR 238 - Mobile Internationalization API Version 1.0

The Conditionally Mandatory JSRs:

1.	JSR 177 - Security and Trust Services API for J2ME Version 1.0 (SATSA-APDU)
2.	JSR 177 - Security and Trust Services API for J2ME Version 1.0 (SATSA-PKI)
3.	JSR 179 - Location API for J2ME Version 1.0.1

Not part of JSR 248:

1.	JSR 177 - Security and Trust Services API for J2ME Version 1.0 (SATSA-JCRMI)

But developing and testing a handset that supports all those specs, I have to guess, is complex and costly! Don't you think? If buying a nice handset today cost around $400+, how much would a MSA-compliant handset cost? $1,000+? What good is to have such a nice handset specification, if just very few people can afford it? Of course, having all the APIs and features available on all compliant-handsets would be terrific, if 1) someone subsidies the cost (i.e. it is not passed 100% to the consumer), and 2) it is trully consistent across all handsets.

What the MSA expert group needs to do is re-target MSA; this is, target sets of JSRs to specific types or classes of consumers… Similarly to how developers address a particular consumer space such as gaming, business, messaging, music, multimedia, etc when creating applications and services. The idea is to be able to bound development cost, while maximizing what customers really want. The idea is to better address the customers. As a starting point, let's propose the following consumer classes:

low-end: Not everyone cares about gadgets; voice is the main feature these customers want. Those customers don't care about things such as advanced multimedia supplements 3D graphics API, PIM, or giving away their location! They are not gamers. They may not even care about Bluetooth, and so on. They just want to talk on the phone. And there are lots and lots of people who only care about low-end handsets. This type of customer may care about text messaging though (short messaging is the most predominant use of handsets, only 2nd to voice). But because we know better, in addition to MIDP2 we may include JSRs such as WMA 2.0, payment, basic ringtones, and internationalization APIs, a browser and so on.

mid-end: These people are more sophisticated. They like to take and share pictures, maybe even listen to music on their handsets. They like to play games as well. To keep cost down, this handset doesn't include hardware assisted graphics. They use short messaging, and IM, and maybe even Bluetooth, but they don't care about PIM APIs, or SATSA.

high-end: People who spend money on such a high-end device wants all, all the bells and whistles — with all the JSRs described above. I want one of these handsets. This type of customer wants GPS, all kinds of network connectivity, PIM and data synchronization, high-performance graphics and great display resolution, camera, great sound, and so on.

gaming: This is a handset that is VERY good with graphics, sound and networking. It even has hardware assisted graphical co-processors! Things like networking and Bluetooth are important for downloading game levels, and playing with other people (in the vicinity). You get the idea.

business: This may be the same as the high-end device described above, or maybe not. Maybe the difference is in the software or included JSRs but hardware-wise is almost the same. PIM and data synchronization is very important. Some business people want cameras, other can't because they are not allowed at work, security and handset management are extremely important, as well as integrating with IT back-end web services. Business types probably want all the bells and whistles — all the JSRs.

The ultimate list may combine some of the above classes together, or have different names for them, or define new ones. The number of “classes or types” should not exceed 5 and actually 3 classes max. would be ideal. The classes definition above is not complete or perfect, but are a good start.

That said, the MSA EG should adopt the idea of targeting MSA for CLDC to specific consumer classes. Doing this will help to better address compliance, and better address what the consumers want. Again, the idea is to be able to bound the "problem", what is compliant and what is not, the development cost and the cost of the handset (by just including what is needed), while maximizing what customers really want. Note that once support for downloadable shared libraries (coming in MIDP3) is available, just in time download of JSRs and their packages will be possible — making, in theory, the MSA for CLDC issue described here a short-term issue, but even then, the concept of “classes of devices and types of consumers” will exist (last sentence is “strike-out” since there is more to JSRs, such as native implementations).

The MSA for CLDC public review closes on October 20th, 2005. Send your comments to jsr-248-comments@jcp.org.