Oct 22, 2010

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

    3 comments:

    Nitz said...

    Hi, long time developer first time caller :)

    I've been with J2ME since its early childhood, in the begining of the 2000s, and witnessed its process of maturing into the wierd, cranky and hard to work with grownup which J2ME is today. Over those years I've had countless talks about the subject with all around me. From bizdev officers to software engineers, from managers to subordinatesm from CEOs to customers.

    One thing that everyone seems to agree upon is that the general Sun approach about handling J2ME is "never talk about the elephant". Sadly, reading your post proves to me that Oracle is not happy about dropping bad old habbits.

    Sentences such as "In addition, those APIs will always be there. So developers do not have to worry about fragmentation" are exactly this. Talking about everything besides the huge elephant in the room.

    API fragmentation might be a cause for discomfort, but its far from being the cause for the "porting hell" that drives J2ME production costs so high and drives all of its developers to search so desperately for alternatives.

    Device fragmentation drives firsly, and utmost, from lack of Sun backup for J2ME. And I say "backup" and not "support" to emphasize that the problem is not technical. Its mainly political.

    The main, most painful and most costly device fragmentation issues have ALWAYS been manufucturers not living up to specs. The elphant that noone in Sun or Oracle seems to want to talk about lies with thousands of devices bearing the Java logo, but not living up to the promise.

    J2ME real life implementation are notoriously buggy, they almost never fullfill the specs completely and tend to present their own little variations. Evrything, from displaying a string to the user, to opening a connection or a multimedia player is painfull, and needs to be tested on each specific target device. Its "code once, debug seperately on every-fricking-firmware-version-out-there".

    Why do I blame Sun for it? Because has there been a "responsible adult", using his weight and influence on enforcing the specs and the quality of the implementations, we wouldn't have been in that "porting hell" situation. But there have never been such and adult. I've never heard about a device being rejected from bearing the Java logo, and I suspect that Sun never troubled itself with the issue. So, like every neglected child, J2ME grew up to become very hard to work with.

    It's not the technology which drives us, enetrpenuers, investors and developers alike, as far away from J2ME as possible. Its not the technology that makes us prefer platforms which are 31 times less popular than J2ME (according to your own JavaOne figures). We're able to overlook and overcome technological challenges. That's our job. But we will not tolerate being left alone at th field. Sun has left us, and Oracle seems to continue on the same path. The rest of the world prefers to go where there are no elephants in the room.

    Ernandes Mourão Júnior said...

    Hi, Nitz

    Your point is right and I really agreed with that. I have witnessed many situations like that.

    Besides a buggy implementation, Java ME specification also have many breaches. Many features are optional so developers have also to handle with that. For instance, last week I was implementing a feature to put an app on background. That easy, just set null to Display.setCurrent(). Unfortunately, it does not work on any device. The specification allows you not to implement it.

    I know that things like that are due Java ME's concept, which I mentioned in the post. However, embrace the whole world by providing a very flexible specification just leads to problems, sometimes.

    Thanks for you comment,

    Regards,
    Ernandes

    p.s: I removed you duplicated comment. :)

    Eric Simmons said...

    Great and Useful Article.

    Online Java Course

    Java Online Training

    Java Course Online

    Best Recommended books for Spring framework

    Java Interview Questions












    Java Training Institutes in Chennai

    Java Training in Chennai

    J2EE Training in Chennai

    java j2ee training institutes in chennai

    Java Course in Chennai