J2ME MIDlet is limited, why not Java applications on mobile?

[chen_lin99]

hi,

For a while I have been wandering about this, any comments or you point
out if I am wrong, it would be appreciated:

The J2ME platform (I am using Sun's J2ME Wireless Toolkit) looks
providing a very limited range of functionality. For example, MIDlet
cannot detect (or be triggered) when there is an incoming call on the
mobile phone, nor can it receive a regular SMS message sent from
another mobile phone (correct me if I am wrong).

With these limitations (or restrictions) in effect, I think it's very
hard to develop a powerful software on the J2ME platform, for example,
a powerful phone call management software, which can block certain
phone numbers from calling in, which can automatically redirect certain
incoming calls to another pre-configured phone number.

A war game on mobile phone, I believe J2ME is capable of; but more
powerful things, especially those interacting with IO's, I don't think
MIDlet is.

I understand for security reason, MIDlet can only execute within
"sandbox".

However, I wander, why there cannot be Java applications as well, just
like on the PC. If a user installs a Java application onto his mobile
phone, via bluetooth or data cable or whatever, that means he trusts
the application and he has the right to do it.

In addition, digital certificate can be used to sign the Java
application installation, and certain trusted digital certificates can
be pre-set on the mobile phone. So even with OTA, a Java application
(not only a MIDlet) can be downloaded and installed and started on the
mobile phone, as long as the software passes the certificate checking.

So, I would like to ask, why not Java applications on the mobile phone?
On PC, there are applets and applications; why not on mobile phones,
there are MIDlets and applications as well?

Somewhere I read about "Personal Java", maybe that's the Java
applications I meant here? But besides that, I did not hear much more
about "Personal Java".

Thank you,
Chen

 

[Darryl Pierce]

The J2ME platform (I am using Sun's J2ME Wireless Toolkit) looks
providing a very limited range of functionality.

That's because they're designed to run on devices with limited resources.

For example, MIDlet
cannot detect (or be triggered) when there is an incoming call on the
mobile phone, nor can it receive a regular SMS message sent from
another mobile phone (correct me if I am wrong).

It can receive and respond to SMS messages sent to specific ports on the
handset, but it is not allowed to intercept and process SMS messages on
ports for which the MIDlet's not registered. This was decided by the
handset manufacturers themselves who were on the expert group defining
the WMA.

 

[chen_lin99]

That's because they're designed to run on devices with limited

resources.

I think it's true that J2ME runtime hardware environment is pertty
resource limited. However, by looking at MIDlet design, like its
start(), pause(), APIs and alike, its security permissions, and other
technical details, I think fundamentally MIDlet was created with the
sandbox restrictions in mind, just like Applet.

It can receive and respond to SMS messages sent to specific ports on the
handset, but it is not allowed to intercept and process SMS messages on
ports for which the MIDlet's not registered. This was decided by the
handset manufacturers themselves who were on the expert group defining
the WMA.

Yes, it's true there is no problem for MIDlets to receive SMS messages
on specific ports; in other words, MIDlets can communicate with MIDlets
via specific and of course, pre-agreed port, but MIDlets can not
receive SMS messages which are not from a MIDlet it "knows".

I think, fundamentally, my question, i.e., why Java applications alike
cannot exist on mobile phones, was not answered. Limited resources
should not be the reason. Specific SMS message communication port is
only a technical detail.

Future comments are appreciated.

Abelard

 

[Darryl Pierce]

I think it's true that J2ME runtime hardware environment is pertty
resource limited. However, by looking at MIDlet design, like its
start(), pause(), APIs and alike, its security permissions, and other
technical details, I think fundamentally MIDlet was created with the
sandbox restrictions in mind, just like Applet.

Yes, it was. And it's stated very clearly in the specification and the
white papers that that's the intention behind the MIDP.

Yes, it's true there is no problem for MIDlets to receive SMS messages
on specific ports; in other words, MIDlets can communicate with MIDlets
via specific and of course, pre-agreed port, but MIDlets can not
receive SMS messages which are not from a MIDlet it "knows".

No, it can respond to any SMS message sent to the port on which it's
listening. It doesn't matter if the SMS message was sent by another
phone, a servlet, an email application, etc. All that matters is that
it's sent to the specific port on which the MIDlet is registered as a
listener.

I think, fundamentally, my question, i.e., why Java applications alike
cannot exist on mobile phones, was not answered.

Your question, as worded, makes no sense. What are you trying to find out?

 

[chen_lin99]

Here, I am not going to explain my topic any more. If interested in
this topic, one may go to Nokia discussion board:

http://discussion.forum.nokia.com/forum/

where this topic got good feedbacks and discussions.

Chen