I love Google because Google loves Java ME technology

Google loves Java ME (technology) yes I know, For Tom's Guide tells me so.
I'm making this up as I go along, Android is weak but Java ME is strong.

See:

New GMail Mobile 2.0 on Java ME phones

Here's a quote:

 The third and possible biggest 
 update this week for Gmail is the 
 release of the newest version of 
 Gmail for Mobile.  Users can now 
 enjoy a faster, smoother service 
 from Gmail for Mobile.  Gmail Mobile 
 2.0 comes with J2ME and Blackberry 
 support for nearly all models, so 
 Nokia N95 and Bold users users can 
 now enjoy Gmail on their phone.
So, let's review: a) Java ME technology is awesome b) Google uses it for their GMail Mobile to reach billions of cell phones c) You can't run this announced GMail Mobile 2.0 version meant for the masses on Android. Got it now. It's simple as A-B-C. :-)

Comments:

A quick correction: the version of Gmail on Android has pretty much the same functionalities except that it supports Push email, which was not possible with J2ME.

Posted by Derek on October 24, 2008 at 05:08 PM PDT #

Thanks, Derek.

Good information to have. Java ME technology does provide Push Technology in MIDP, however.

See:
http://www.javaworld.com/javaworld/jw-04-2006/jw-0417-push.html

Quote:
---
The latest version of MIDP, 2.0, has introduced many new features for helping developers build robust enterprise applications, with one of the more important being the push registry. In Java ME applications, sometimes we need to push data from the server and launch a mobile application automatically in the device...

Posted by Hinkmond Wong on October 25, 2008 at 03:43 AM PDT #

Hardly any phone supports this and the sandboxed model of J2ME makes this pretty much impossible to use in practice. We're not going to see Push applications on J2ME any time soon. Pity.

Android uses XMPP to channel Push updates, which is a much cleaner model and works great with Gmail, Calendar and Contacts.

Posted by Derek on October 25, 2008 at 04:58 AM PDT #

Hi Derek,

I'm not sure you are totally correct or you have been affected by perceived truth-bending anti-Java ME bias by some developers out there. Funambol has had Java ME push e-mail as an application on Java ME technology for quite some time now.

http://www.funambol.com/news/pressrelease_2007.05.22.php

---

. It includes a new portal that automates over-the-air provisioning of mobile devices, a new open source Java ME push email client for commodity handsets, and capabilities to ease mass deployments.

“Carriers see a huge opportunity to offer push email for the mass market but they have not had a viable solution,” said Fabrizio Capobianco, Funambol CEO. “With Funambol v6, carriers have an easy-to-use push email solution that works on consumer devices with the features and price point that the mass market wants.”

Posted by Hinkmond Wong on October 25, 2008 at 05:15 AM PDT #

Have you actually used Funambol? Apparently not. The sandboxed model of J2ME is an uphill battle that will discourage all but the most resilient users. It's not Funambol's fault, by the way, they did what they could, but the sandbox is the death of any J2ME application that wants to do anything non trivial.

Look at it this way: the Push specification for MIDP has been around for 2+ years, why do you think Google didn't include it in their latest Gmail on J2ME? I have been developing with J2ME for 4+ years now, it's a real pain and it's getting worse instead of getting better.

And with Android supplying this out of the box over cheap 3G contracts, I don't think we'll ever see any credible Push solution or application on J2ME.

Posted by Derek on October 25, 2008 at 09:31 AM PDT #

Hi Derek,

Your original statement was this:

"...Android has pretty much the same functionalities except that it supports Push email, which was not possible with J2ME."

I'm just pointing out you are spreading misinformation because Push E-mail is indeed possible with Java ME technology.

See:
http://www.funambol.com/documents/Funambol_datasheet.pdf

It's a matter of opinion whether it is a good quality solution or bad quality solution, but Push E-mail is indeed possible with Java ME technology.

Now, the issue of the wireless carrier requirements for gaining permission from a cell phone to access data networking is a different problem altogether, and I agree is a pain to deal with.

But, that's a carrier sandbox requirement, not a Java ME requirement. Make sure you don't confuse the two, since many people love to blame Java ME technology for the failures of the wireless carriers in how sandboxing is implemented.

Also, as Google Android developers will quickly learn, that while a restrictive sandbox model does have bad points, it also has good points (it keeps things safe):

Hacker finds a security hole in the Google Android software on the T-Mobile G1
---
http://venturebeat.com/2008/10/25/hacker-finds-a-security-hole-in-the-google-phone/

I've been working on EmbeddedJava/PersonalJava and Java ME technology for 10 years. And, I see Java ME technology getting better with better security and more functionality versus other less mature technologies out there and still up and coming. The younger technologies will go through the same exact process to gain the same level of robustness that Java ME technology already has.

Hinkmond

Posted by Hinkmond Wong on October 25, 2008 at 01:45 PM PDT #

Hi Hinkmond.

I have a question regarding push feature in Java ME. In this document "The Recommended Security Policy for GSM/UMTS Compliant Devices"
(http://jcp.org/aboutJava/communityprocess/maintenance/jsr118/MIDP_2.0.1_MR_addendum.pdf) we can read:

"Additionally, the Blanket setting for Application Auto Invocation and the Blanket setting for Net Access are mutually exclusive. This constraint is to prevent a MIDlet suite from auto-invoking itself, then accessing a chargeable network without the user being aware. If the user attempts to set either the Application Auto Invocation or the Network Function group to "Blanket" when the other Function group is already in "Blanket" mode, the user MUST be prompted as to which of the two Function groups shall be granted "Blanket" and which Function group shall be granted "Session"."

Also check this thread at Forum Nokia:
http://discussion.forum.nokia.com/forum/showthread.php?t=106285

So according to the specification I can't make a Java ME application which will be automatically started by SMS message and then will connect to some server on the internet -- and will do ALL of that WITHOUT any prompts to the user.

Am I right?

I check that on my Nokia phone and this seems to be true. When I want to set "Application auto-start" to "Always allowed" I can't set "Network access" to "Always allowed" and conversely (I checked this on Opera Mini which is installed as "Trusted third-party" application).

Posted by Pawel Marchewka on October 28, 2008 at 09:33 AM PDT #

Hi Pawel,

Your question was:

---
So according to the specification I can't make a Java ME application which will be automatically started by SMS message and then will connect to some server on the internet -- and will do ALL of that WITHOUT any prompts to the user.
---

The answer is dependent on the carrier (not dependent on Java ME technology itself). This is what confuses most people. Java ME technology by itself does allow a Java ME app to automatically start via a SMS message and connect to some server on the Internet (via the MIDP Push Registry).

However, most carriers don't want this to happen on their phones on their wireless networks, so they clamp down on it and create a carrier-specific sandboxing requirement that prevents it from happening.

So, it is up to the carriers, not the Java ME platform to either allow it or not allow it.

See from the Nokia forum thread:
http://discussion.forum.nokia.com/forum/showpost.php?p=305688&postcount=6

Quote from above:
"The answer to your question is "No." It is not possible to remove the questions altogether with your VeriSign Certificate. Your VeriSign Code Signing Certificate makes you a "Trusted Third Party" developer. To remove the questions completely, you would need an Operator or Manufacturer Certificate. Requires agreement with Carrier."

The key statement is: "Requires agreement with [the] Carrier".

Getting that agreement from the Carrier is outside the scope of what Java ME technology.

Maybe Google Android is a way around that. Maybe not. We'll see who still has the control on networks as Android evolves. Does AT&T, Verizon, T-Mobile, Vodafone, Orange, etc. control what happens on their own networks and how they dictate the sandbox for Internet access, or will Google force the carriers to loosen their current restrictions a bit?

Good question.

Hinkmond

Posted by Hinkmond Wong on October 28, 2008 at 09:57 AM PDT #

Hi Hinkmond.

Thanks for your answer but I'm still a bit confused.

Lets concentrate on that "The Recommended Security Policy for GSM/UMTS Compliant Devices".

I am reading it and for me this specification == MIDP 2.0 == JCP == Java ME technology.
I was convinced that this document is mostly intended for device manufacturers.
So device manufacturer takes that specification and it says: If you want your device to be MIDP 2.0 compliant it MUST work in such way that it will not let the user to set "Application auto-start" and "Network access" to "Always allowed" simultaneously for "Trusted third-party" applications. (I really don't see any carrier to be involved in) True/False?

So for me it still looks like it doesn't matter how open the carrier is (and in Europe they seems to be more open than in the U.S.) because device manufacturer has no option - it has to make the device exactly as the specification says.

Back to my original question. I'm not asking if it is possible in Java ME technology from some technical point of view. I'm asking if it is possible for me as a third-party developer with third-party certificate on the device compliant with the mentioned above MIDP security recommendations. When I am reading this specification literally the answer is just "No". Am I missing something?

Posted by Pawel Marchewka on October 28, 2008 at 11:33 AM PDT #

Hi Pawel,

You wrote:
---
I am reading it and for me this specification == MIDP 2.0 == JCP == Java ME technology.
I was convinced that this document is mostly intended for device manufacturers.
So device manufacturer takes that specification and it says: If you want your device to be MIDP 2.0 compliant it MUST work in such way that it will not let the user to set "Application auto-start" and "Network access" to "Always allowed" simultaneously for "Trusted third-party" applications. (I really don't see any carrier to be involved in) True/False?
---

I agree it's confusing, but you might be missing a key point. The rule is that you can either set an app to run "Blanket Auto Invoke" or "Blanket Network Access" (the two are mutually exclusive by definition) without prompting the user as long __as the other setting was not previously set__.

So, the key point is that you can still access the network when setting "Blanket Auto Invoke" for a MIDlet to access a server, without prompting the user as long as "Blanket Network Access" was never set before "Blanket Auto Invoke" was set.

The translation is that these 4 rules are all true:

1. Trying to set Blanket Auto Invoke when Blanket Network Access has already been set requires that the user is prompted to make sure it's OK with him/her.

2. Trying to set Blanket Network Access when Blanket Auto Invoke has already been set requires that the user is prompted to make sure it's OK with him/her.

3. Trying to set Blanket Network Access when Blanket Auto Invoke has not been set yet, does _not_ require any user prompting.

4. Trying to set Blanket Auto Invoke when Blanket Network Access has not been set yet, does _not_ require any user prompting.

So, the answer is "Yes", according to the spec. you can write a MIDlet that is auto launched that can access the network without user prompting as long as the device was set by the user to Blanket Auto Invoke and Session Network Access, or Blanket Network Access and Session Auto Invoke.

(It's really tough to try to explain this via blog comment! I wish I had a whiteboard... :-) )

Hinkmond

Posted by Hinkmond Wong on October 28, 2008 at 12:19 PM PDT #

As for Android, the answer is: it's very easy to write applications that work in the background and do whatever they want, including pulling data, retrieving GPS information or anything else.

The difference in security with Java ME is that you are told at download time what features the application is requesting and you say yes or no. If you say no, the installation is cancelled. If you say yes, the application will not bother you any more and you have a very clear idea of what it will be doing.

I find this a big relief from Java ME applications that keep asking you if it's okay for it to access the network and such things (admittedly, it's only partially Java ME's fault, but the bottom line is that all Java ME applications have this problem and none of Android's do).

Posted by Andy on October 29, 2008 at 02:50 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Hinkmond Wong's blog on making Machine to Machine (M2M) and the Incredible Internet of Things (IoT) smarter with Java Embedded Technologies

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
3
4
5
6
7
8
9
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today