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
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:
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.
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. :)
Hey, would you mind if I share your blog with my twitter group? There’s a lot of folks that I think would enjoy your content. Please let me know. Thank you.
apple service center chennai | ipod service center in chennai | Apple laptop service center in chennai | apple iphone service center in chennai | apple iphone service center in chennai
Post a Comment