JPhone and JOS: It could work

Hi all,

Since iOS and Android came out as two big waves flooding the entire mobile world, leveraged by Apple and Google (and its partners) and their incredible devices, developers have wondered what is going to be the future of other mobile platforms. In our case, Java ME.

There are a lot of discussions in the internet about this topic. Actually, I have already exposed my point of view on this matter. However, I am not here today to extend this discussion. In fact, I would like to demonstrate how Java ME could be at a better place.

In my opinion, one of the greatest advantage of iOS and Android platforms have compared to Java ME is a rich and uniform base. Who develops for either one knows that there is a bunch of APIs that allow us to build very compelling apps. In addition, those APIs will always be there. So developers do not have to worry about fragmentation.

In any event, we know that Java ME has a different concept, which is to provide a base platform aimed to run on low, mid and high-end devices. Because this difference of hardware, not all JSRs specified by JCP are available on any Java ME-enabled device.

Since the existent set of specified JSRs, I believe that Java ME could be at a better place. Java ME has a very rich set of JSRs at JCP that could also provide a very rich and uniform base for Java ME devices. If we had a manufacturer interested on implementing all of them in a single device, I believe Java ME developers would not be so afraid. Sony Ericsson and Nokia have done a good work on providing devices with a very good set of APIs. However, it is not enough to compete with the other players.

So, let's imagine such device. Let's call it JPhone, running JOS. Now, let's outline some JSRs that could be present on it.

• JSR 139: Connected Limited Device Configuration 1.1
• JSR 271: Mobile Information Device Profile 3.0
• JSR 75: PDA Optional Packages (PIM and File System)
• JSR 80: Java USB API
• JSR 82: Java APIs for Bluetooth
• JSR 113: Java Speech API
• JSR 205: Wireless Messaging API 2.0
• JSR 135: Mobile Media API
• JSR 172: Web Services Specification
• JSR 177: Security and Trust Services API
• JSR 293: Location API 2.0
• JSR 180: SIP API
• JSR 184: Mobile 3D Graphics API
• JSR 190: Event Tracking API
• JSR 211: Content Handler API
• JSR 287: Scalable 2D Vector Graphics API 2.0
• JSR 229: Payment API
• JSR 234: Advanced Multimedia Supplements
• JSR 238: Mobile Internationalization API
• JSR 239: Binding for the OpenGL ES API
• JSR 253: Mobile Telephone API
• JSR 256: Mobile Sensor API
• JSR 257: Contactless Communication API
• JSR 258: Mobile User Interface Customization API
• JSR 272: Mobile Broadcast Service API for Handheld Terminals
• JSR 280: XML API
• JSR 281: IMS Services API
• JSR 300: DRM API

A lot of stuff, huh? And here I am just considering JSRs that at least are compatible with CLDC and at final release stage. There are a bunch of other ones in JCP, but they are either CDC compliant, rejected or stuck. I am assuming that once a JSR reaches final release stage, it is feasible to be implemented. So it would be ready to go on JPhone.

I would also add LWUIT to this list. I believe that all efforts put on LWUIT, since ORACLE (that time Sun) embraced it, have come this project to a higher level of maturity and capabilities. Today, we have seen great things being developed with it. At Java One, there were many presentations regarding LWUIT being capable to build very compelling smartphone apps.

This my list is close to what is proposed by MSA. However, I would like to see no optionality, i.e., MSA subset or even hardware dependency.

We can't forget about the Java language itself. Today we are stuck in Java 1.3 language. On the other hand, there are some great new features, e.g., generics, enumerations, auto boxing, etc, in Java 5, which most developers can no longer live without.

Java has many more things to offer and that could be present on JPhone, e.g., collections, network, I/O, etc. Considering the hardware that runs iOS and Android, full Java SE 6 could run properly on it too.

Another leak of Java ME is related to an application model. iOS and Android have theirs, which are based on Model-View-Controller pattern. On the other hand, Java ME let this task on developers' hands. Java ME needs to provide more references for them.

Java ME also leaks providing a better solution for data storage. Record Store is not enough at all. On the other hand, iOS and Android provide their SQLite implementations. It is time for ORACLE to start thinking of using its huge background on it to help Java ME.

I know that my proposal is kind of surreal, but it seams to be a receipt for success of iOS and Android. Windows Phone 7 tends to follow it letter by letter.

See you in the next post...

Is MSA 2 already coming?

Hi all,

We are still getting used with Mobile Service Architecture (MSA), but the Java Community Process can't stop. They are already working on a new version of MSA, MSA 2, which comes to comprise more JSR's; some of them are new ones and others just newer versions. For example, the JSR 256 - Mobile Sensor, JSR 257 - Contactless Communication API and JSR 271 - MIDP 3.0.

In additional, the MSA is now divided into three groups: Limited, Subset and Full. Previously, we had just the Subset and Full. Each one cromprising a different set number of JSR's supported. For example, the Limited version will be aligned with JSR 185 - Java Technology for the Wireless Industry (JTWI).

The ratification of MSA 2 is expected to be done along with MIDP 3.0, about fourth quarter of 2008. However, MSA 2's ratification, problably, will be done before the first quarter of 2009.

For further information on MSA 2, see the link below:
http://java.sun.com/developer/technicalArticles/javame/msa2-intro/

See you in the next post...