My wishlist for open source Java ME
Motorola has recently announced that it will develop an open source Java ME implementation (MIDP 3) under the Apache license. This is the second open source Java ME announcement since Sun announced that it will open source Java ME with the rest of the Java platform!
Now, the big question is which hardware / OS platforms will those open source Java ME implementation run on. In theory, they could release an implementation that only runs in a software emulator on desktop Windows or Linux OSes — pretty much like what Sun did with Java ME CDC reference implementation before. IMO, that was part of the reason why CDC failed to take hold in the PDA market. Without a variety of real devices to run those open source Java ME implementations, they would be utterly useless for most users and developers. I hope the Motorola implementation will run on the new Motorola Linux-based smartphones, and the Sun implementation will run on Windows Mobile 5.0 devices!
The next question is whether Motorola / Sun will provide implementations for important Java ME optional packages. As we all know, MIDP by itself is not very useful. The open source implementation needs at least the MMAPI and the PIM API to be useful. The Bluetooth API, the Mobile 3D API, the Web Services API, and even the Location API are also much needed. It would be ideal if the open source implementation is structured so that the user can decide what optional APIs to install on his/her own Linux/Windows Smartphone.
Well, we can hope …
November 8th, 2006 at 6:24 pm
Yes…
Oh, and WMA as well…
enrique
November 9th, 2006 at 2:25 am
I really agree about that!
Perhaps also Java support for devices like Apple’s Ipod?
It would be great if it aslo was possible to upgrade Symbian phones with
support for JavaME/CDC1.1/PP1.1 (today mostly Symbian phones support JavaME/CLDC.1.1/MIDP2.0)
Now when it look like SavaJe is out of buisness (http://ovenordstrom.blogspot.com/2006/11/savaje-bye-bye.html), it would be great if it aslo was possible in the future to upgrade my SavaJe phone (Jasper) with a new Sun Java implementation!
-ove
November 9th, 2006 at 5:03 pm
I disagree about on thing; MIDP 2.0 itself is very useful. IMO API:s with security restrictions is not very useful anyway. Try to use JSR 75 with an usigned midlet and you´ll see.
My biggest problem is heap, open source or not….
Speaking about MIDP 3.0. How can you “Tighten spec in all areas” and at the same time promise “backward compatibility with MIDP2.0″. What will happen to the MMAPI?
/Tomas
November 9th, 2006 at 5:08 pm
Yeah, I think it is important to make application signing easier — perhaps the OSS implementation should be able to accept self-generated certificates by default? I mean, if someone installs the OSS Java ME on his Linux phone, he probably knows what he’s doing and should be permitted to run any app without the need for the root certificate from the carrier or the device manufacturer.
November 9th, 2006 at 5:10 pm
Strongly agree with the SavaJe comment! A lot of people bought SavaJe in JavaOne believeing it is “the future”. It would be terrible if the device is discontinued with no chance to upgrade the SW.
November 10th, 2006 at 1:37 am
Like the idea about self-generated certificates by default. Signed midlets is just something that the “walled-garden-telecom-people” invented…:)
December 2nd, 2006 at 5:19 am
As the Sun’s ME java got the GPL licence I think we’ll have to kiss goodbye the implementation for Windows Mobile 5 unless individual vendors buy Sun’s commercial license (and they probably won’t as they already have semi-working vm’s from third party companies that don’t cut it in the enterprise - read this as “they can’t run things like eclipse ercp”). Plus, as these devices differ and each model is a story for itself, even if one vendor gets a VM from Sun it’ll be exclusive for it’s devices only.
Of course if Windows Mobile got GPL’ed our problems are history, but pigs will fly if that ever happens. (even though MS open sourced Windows CE recently it’s still not GPL,thus incompatible)