I’m not a big fan of this method of restricting APIs either but it sure is very effective so far in preventing bad stuff from happening while at the same time succeeding in getting plenty of third party software signed and out there ready for you to install.

I can’t speak for AT&T of course. The ability to disable or restrict access to certain features is important for operators, that’s just the way it is. In some places operators use this ability more than in others. The US is probably one of the worst places in that sense. Part of Nokia’s success (outside US mostly) is due to the ability to cater to operator requirements like this. The whole symbian signed deal is part of this game. I fully expect Google to do something similar; or Apple; or anyone for that matter.

Your decision to pay up is of course up to you. It’s my understanding that barring use of restricted APIs, your cost is going to be limited to paying up to Verisign for a certificate (200$) + additional cost for testing, if you wish to distribute your binaries to others. For testing on your own device, the cost is free, check here: http://developer.symbian.com/main/signed/ for more details on how to fix that. I’m actually quite sympathetic here and I think it is very regrettable & understandable if people like you decide not to support our devices for reasons of cost. But that’s just my opinion.

BTW. For J2ME applications there is no Symbian signed at all unless you need access to specific restricted APIs. I don’t know about JSR 135 and why some operators limit it and other JSRs. I imagine AT&T is protecting or trying to protect their own business.

The real question is why should I pay money $500 to get my application be signed. I developed my application and want to test it on my Nokia 6085 phone (which I paied money already), why should I pay 3rd party big money???

Nokia is the manufacture for my phone. AT&T, as the operator, provide to access to their wireless network. As long as the application doesn’t access your AT&T network, AT&T must provide a way for US to access our phone’s property! For example, to take a picture using my phone since getSnapshot is purely to access my phone’s camera, it is nothing to do with your network security. If I want test it on my phone, I know the security risk for my phone.

I know for the same phone Nokia 6085, in different country, different operator are allow to access the JSR135 API. But Why AT&T disable it?

Other problems arise from differences in formfactors and hardware capabilities. That is a hard problem to work around at the API level. J2ME does a reasonable job but it remains to be seen how Android handles this.

Regardless of this, there is more than a billion J2ME phones out there with reasonable compatibility for MIDP 1.0 and MIDP 2.0 (for the subset that supports this) across platforms. Android doesn’t offer an alternative cross platform API. Instead it requires replacing the entire platform.

Implementing J2ME on top of Android should indeed not be that difficult. Consequently, not making it part of Android is motivated by non technical reasons. I’m pretty sure license issues are not it.

BTW. forget about operators and vendors not locking down the platform. The user granted privilege model is hopelessly broken since most users will just select “OK” or “YES” when confronted with a game that won’t run until you do so. This leaves the door wide open to all sorts of malware so operators will insist on proper locks so that they can control what goes on the phone. Android provides the regular Java security hooks so it should be easy to lock down access to e.g. phone or SMS APIs.

1, I think main reason for this is licensing..it won’t be possible under AL.
2, J2ME is too limited/optional and implementations are too buggy so the whole platform is fragmented/screwed beyond repair. I think they made a good choice.
3, it is possible to implement J2ME API on top of Android. Thus you get the best of both worlds : new, consistent platform that will simplify that ridiculous process of testing/tweaking/certifying the application on zillions of devices and you still can transform the “legacy” applications for Android quite easily as they are all Java.

I only hope the actual devices will be same as the SDK emulator and it won’t be possible for operator to “lock” it in any way. I want to be able to install on MY device whatever I want with privilegies I decide, since it is MY device, not operator’s.

I too was sadly disappointed to learn that Google was re-inventing the wheel and putting out yet another type of Java development environment. It will make my work harder now since I have to port my J2ME code to Android over the next few months.

However, as a J2ME developer in the US, my experience has been that the best minds, companies and standards bodies (Sun, IBM, Motorola, Nokia, Samsung, RIM, Palm, AT&T, Verizon Wireless, Microsoft, Apple, OSGI and the JCP and of course Google itself ) to date (after many many years of effort) have yet to put out a mobile platform that provides for freedom of choice, open development and easy and open deployment, cross-platform compatibility with great security and privacy of course.

I say let’s give someone else a chance now!

There is a good chance that Google might be able to pull something off now if they could get carrier backing. Sun and the JCP were getting nowhere!

Now, I only hope that Google exercises common sense and gradually rolls in all the great technical (but not managerial) work Sun and the JCP has been doing. So maybe we could end up with the best of both worlds.

I look forward to reading some more of your excellent writing.

In general most operators will insist on controlling software on their network for a number of reasons that include security and desire to control end user experience. Especially security is increasingly important as devices are getting hooked up to the internet and people start downloading all sorts of stuff with them. It only takes one buffer overflow in C++ for a hacker to take over the device even if the application itself was harmless. Most mobile platforms have no concept of root or a user so that makes any native application a risk.

Anyone wanting to release a phone platform will have to deal with this in order for operators to deploy/allow phones with the platform on their networks. That’s true for everybody in the business currently. Most platforms don’t allow for native application installation at all (e.g. many of the current linux phone platforms are completely locked down). The ones that do tend to be tightly controlled by operators and vendors.

J2ME was designed specifically to allow developers access to more sensitive parts of the functionality using a permissions system based on Java security APIs. However, J2ME was designed for really limited devices initially which means there is all sorts of technical limitations. Google seems to plan to make a fresh start but still, Google is using a similar security mechanism in their API now. Android applications need to ask permission to do stuff like making phone calls. This permission can be granted by the user but it might also be denied by the Operator … I fully expect similar mechanisms to be used by Apple when they release their SDK in a few months.

Nokia and Symbian also provide protection for native applications. Using certificates, you can get access to parts of the API that are protected. Certification involves a process that ensures that Nokia verifies the application is not malicious and that the associated developer can be trusted. For example to programmatically send an SMS you would need the right certificate. This has proven to be an acceptable solution to operators and now that the S60 v3.x platform is stabilizing and getting on more and more phones, we’re seeing lots of interesting development happening on the platform inside and outside Nokia. Symbian was rather dismissive about Android last week. I don’t really agree with that position but clearly Google has some catching up to do with us. Nokia has large developer communities around Java, Symbian and Maemo.

Especially the maemo development is really open. I’d say it is the only commercially backed open mobile linux platform currently with products in the shop today. Maemo as you note does not have a cellular stack currently; nor does it currently have a way to restrict access to APIs (which makes it the ideal mobile linux device for hackers since you can do anything you want on it). As announced a few weeks ago there will be wimax variant of N810 but still without call functionality (other than the various VOIP software packages). This is a similar use case as equipping a laptop with a wimax card so operators are pretty OK with this. I can’t comment on what the future will bring though.