×

Discussion Board

Results 1 to 12 of 12
  1. #1
    Registered User
    Join Date
    Jan 2005
    Posts
    3

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

    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

  2. #2
    Regular Contributor
    Join Date
    Aug 2003
    Location
    uk
    Posts
    232
    You have overlooked the most obvious reason.

    j2me is a subset of java because java is huge.

    To understand that statement fully you have to remember that your phone has to hold 2 things, it has to hold you application, but it also has to hold the java (in this case j2me) virtual machine to run it on.

    While this is becoming less important as phones ship with more and more memory, the first phones and indeed the majority now still have a tiny amount of heap memory (250k average ?) compared to any machine/pc running a full java virtual machine.

  3. #3
    Super Contributor
    Join Date
    Mar 2003
    Location
    Finland
    Posts
    9,553
    Right. The reasons why a full J2SE implementation does not exist can be summarized as:

    - too little memory (mainly RAM, often also storage memory) -> expensive

    - too little processing power -> also adds to the device cost, power consumption and heat dissipation -> one would have to add fans, bigger batteries, etc.

    - limited battery capacity (power efficiency) -> you don't want to carry around a 100 gram phone and 500g to 1KG battery

    - sometimes also too limited underlying operating system (not a problem with, e.g., Symbian, but can be when it is a small real-time OS)

    In-part these will be solved by technology advancements, but not today in any economic fashion (or at least you end up with an expensive, big and heavy phone).

  4. #4
    Registered User
    Join Date
    Jan 2005
    Posts
    3
    No, I haven't.

    My point was not why we cannot run big Java software on mobile phone.

    Instead, my point was, why Java software running on mobile phones has to be restricted within the security sandbox?

    Due to the original limited hardware resources on mobile phones, and due to the time needed to develop Java libraries, the current API packages available on J2ME platform are relatively limited. This is understandable.

    What is not understandable, at least to me, is, Why Java software, in order to run on J2ME platform, has to be in the format of MIDlet? To me, MIDlet poses many restrictions to the runtime functionality. Those restrictions are there not because of shortness of available APIs, nor because of the targeted hardware/network accessories not popular, but are there by intention, for security considerations.

    I have mentioned, security is important, especially for dynamically downloaded Java software (applet-alike MIDlet); but there is also the reason for the existence of Java applications on mobile phones. Just like on the PC platform.

    Having Java applications alike on mobile phones does not necessarily increase the size of JVM or the Java software (applications vs. MIDlets). It only means removing the security sandbox, so as the result, the size could even be smaller -- I think this is true.

    Again, I am not talking about having (or porting) all the API packages from the PC to the mobile phones. I am talking about letting Java software running on mobile phones just like Java software running on PC's. The Java applications running on mobile phones can use whatever API pakcages available on mobile phones.

    In one word, I am not complaining about the API limitation on mobile phones, I am compalining about the security restriction.

    By the way, I am currently using a Nokia 6670. It gives me over seventy Megabytes memory free of use (a 64M MMC card included). I can view Microsoft Office documents, chat on msn, yahoo messengers, surfing the web, running RealPlayer, all these things on the phone. I charge the battery every two to three days.

    I am not one in a million owning a Nokia 6670; taking a look at the recent new mobile phones from Nokia, Motorola, etc., talking a detailed look at the specifications including weight, battery time, etc., will help know what's going on.

  5. #5
    Super Contributor
    Join Date
    Mar 2003
    Location
    Finland
    Posts
    9,553
    6670: 70MB of storage memory (or more, with a bigger memory card) yes, but not much run-time memory (dynamic RAM). That's only about 10MB after the phone is up and running.

    In any case, there are examples of phones with more Java capabilities (e.g., the Sony Ericsson P800/P900/P910 that allows from PersonalJava apps, via JNI, access to C++ DLLs that are not limited by Java security).

    Also, the Java PersonalProfile is less restricted than MIDP.

    And, I'm pretty sure time will bring also devices to the market with CDC Java as opposed to CLDC, etc.

    On the other hand, many network operators and device manufacturers do prefer that there are security restrictions/limitations (and probably phone users, too, if without those malicious software messes up their data, or makes expensive phone calls that they have to pay).

    The way to influence what is and isn't allowed is through the JCP (Java Community Process). What you see in today's phones is due to the JSR's related to "mobile Java" including MIDP/JTWI and others that have been defined by organizations and individuals active in the workgroups defining the specifications: http://www.jcp.org/

    In any case, if you want more complete access today (immediately), use a Symbian OS based phone (like your 6670) and write the apps in C++.

  6. #6
    Super Contributor
    Join Date
    Mar 2003
    Location
    Israel
    Posts
    2,280
    But the security of the sandbox is very important.

    Just imagine that I'm a malicious developer, and I make a game that I give away for free. But in this game I also implement my own nasty phone call management that blocks calls from certain numbers or something like that. The user thought he was just getting a small game, when he finds out that the game is responsible for him missing a very important business call. A few cases like this and the reputation of J2ME will be gone forever. Noone will want to risk downloading applications that can mess up the phone's regular functionality.

    shmoove

  7. #7
    Registered User
    Join Date
    Jan 2005
    Posts
    3
    Thanks for the replies. petrib's is very informative.

    Chen

  8. #8
    Registered User
    Join Date
    May 2003
    Location
    Tropical Paradise Penang
    Posts
    43

    Security and sandbox

    Although the security is an important issue, but i think J2ME implemented a very tight and limited API. I think it should do away with constraint security and let the user decide whether to allow application to be install with premission from user end, and not from the manufacturer end. Some Nokia devices do have this feature where user are allow to either let the device to connect to web without prompting(Always, This time etc). I think SMS API(as well as MMAPI etc etc) should also implement this feature. User should be given the right to decide whether to allow the midlet to have access to the security feature, instead of being define by the manufacturer.

    Since in the JAD, the midlet manufacturer is a prequisites attributes, the user know where/who he/she downloaded the midlet from, so I think the issues lie more on user than manufacturer.

  9. #9
    Regular Contributor
    Join Date
    Mar 2005
    Posts
    60

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

    personally i think the decision to allow whether dis & dat particulars applications 2 b installed shud b the responsibility of the manufacturers,simply bcos majority of handphone users are just any ordinary human beings who does not really know the technicals of handphones,applications,consequence of installing malicious content,whether Application A is gud or bad,so better leave the decision to the manufacturers,simply bcos the manufacturers are experts/professional in dis field.

  10. #10
    Regular Contributor
    Join Date
    Mar 2005
    Posts
    60

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

    in a way the manufacturers are js helping the users to protect his/her mobile apps ( handphones,pdas,etc )

  11. #11
    Registered User
    Join Date
    Dec 2005
    Location
    Brazil
    Posts
    1,884

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

    i chen_lin99,

    I liked your comments but i think you've not taken some things into consideration. Below are my comments:

    Undoubtedly JME is limited if compared to Symbian C++, but it's also easier to learn and develop.

    "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)."


    The call issue is going to be addressed by MTA and yes, you can send regular SMS from one phone to another. Take a look at WMA - Wireless Messaging API).

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

    Well, the sandbox is for MIDP 1.0 MIDlets, for MIDP 2.0 ones there's the "MIDP 2.0-trusted model". It can seem the same but there are differences but permissions are required anyway.

    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?

    Well, as you may know Java is not just applets and applications. I agree with you that a standalone Java application is simple and straightforward to develop and run.

    But a lot of Java APIs (and specially components) use the managed environment concept (a.k.a containers), applets are an example. Applets can run in sandbox or signed, the embedded browser JVM being their container.

    But remember of J2EE: We have servlets, jsps (web container), ejb (ejb container), SIP servlets (modified sip container) etc. None of these run like a general standalone Java application.

    The containers are very important to ease things for a developer, the container services are leveraged to reduce complexity and each component that runs within a container must honor the contract with this managed environment. The benefits are so many that's hard to say...

    For MIDlets, the AMS is also a container (i regard it as one) and sets a very simple contract. Compare MIDlets and EJB entity beans (CMP) and you'll see how simple yet powerful MIDlets are.

    petrib commented about technology advancements. I do believe that today it's possible to build a very powerful device, in fact there are very good ones.
    But battery is the real challenge, the battery technology is not as advanced as CPU, memories, etc. This is the real problem i guess.

    "The Java applications running on mobile phones can use whatever API pakcages available on mobile phones."

    The main problem here are the associated costs when you're using network access, for example. I think the security permissions are well-thought and JCP considers a lot of issues when defining them, absolutely. shmoove gave a good example, depending on the situation/contry some cases can result in a legal battle.

    At last, thank you very much. I've found this thread very interesting, i'll be watching it for comments.

    BR

  12. #12
    Registered User
    Join Date
    Dec 2007
    Posts
    1

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

    Hmm, strange thread. I think most of the posters talking about batterly life, storage capacity and security missed the point entirely.

    JIT compiled Java is not a lot less efficient than C++ to begin with, and with the ability to use native methods in demanding parts of an application there really is no difference at all performance wise.

    Regarding storage capacity, the OP obviously was interested in the ability of a java application to be treated as a first class citizen by the OS. He was not asking for an implementation of the standard edition of Java, so this point is pretty moot as well.

    Regarding security, the differentiation between application and applet in normal Java can be used to add native functionality in a way that isn't accessible to sandboxed java apps. What is needed is adding JNI interfaces to the Native APIs and install a classloader for MIDlets that isn't allowed to load the native classes - just like it is done for applets. Symbian already has the security issues that C++ applications bring to the table. Java applications can't possibly raise any more if they are treated the same way.

    In conclusion, given that the Java VM already exists the ability to install and run java applications as native apps is essentially free and does not create additional security or power issues. The only work that would need to be done is create the JNI wrappers for all native APIs that aren't fully exposed through existing java APIS.
    This would give you the ability to abandon C++ as an application language(apart from small scale optimization) and enjoy the garbage collection, memory integrity and type integrity of a real programming language. =)

    Sorry for the long post, but I just spent two days figuring out that java is limited to toy apps on the symbian platform in its current state and I'm a bit frustrated. I hate C++, but it looks like it's the only way to get OS integration.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×