Skip to main content

Why not get rid of the JVM and JIT for mobile device?

7 replies [Last post]
yt7589
Offline
Joined: 2008-05-06

Hi alll. I had a basic question about the design of java language.

At present java program first be compile to bytecode then executed by a JVM. Normally JVM is a little big for most of the mobile device. My question is that why not just convert the java bytecode to native executable before it run ( include the necessary JDK class ). Then it will run just as a native program. It will have smaller memory foot-print and run faster than the normal way. Now during the development phase we use the JVM to debug our program. When deploy the program we convert it to the native executable for the target device.

For how to achieve this taget we can convert the class file to for example C source file then compile it with GCC.

I want to know why we don't use this method to address the mobile application development. Does JVM provide so much advantage that we can't by pass it in any way?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
yt7589
Offline
Joined: 2008-05-06

When asking this question what is in my mind is Google's Android. It will convert the standard java bytecode to their own bytecode and run in their own VM. By doing so they can provide the java program the ability which can only be used by C/C++ before.
As you know that it is impossible to access the telephony function in the mobile phone via JavaME ( Except PlatformRequest ). So it is impossible to intercept the incoming call, to access the phone book, to management the SMS and so on. But by using Android you can access all these functions [b]via java[/b]. Although there has JSR about telephony in JavaME it will take several years to happen. Because the MSA is the next big thing for mobile phone vendor.
My question iis that why not JavaME follow Google's model or even forther we just convert the java bytecode to native code.

terrencebarr
Offline
Joined: 2004-03-04

You'll find that Google's approach is 100% non-portable. They have their own execution mechanism, own sets of entirely new APIs, and explicitly allow vendors to add proprietary extensions for differentiation.

I'm not saying Java ME in it's current state is perfect but from all I've seen so far Android's approach is not encouraging.

The reiterate: The real problem in the mobile space is the multitude of vendors, incompatible technologies, and conflicting business agendas. We developers like to think about functionality and neat execution tricks but whether Java is interpreted, JITed, or compiled to native ahead of time how it used native functionality is really secondary.

-- Terrence

linuxhippy
Offline
Joined: 2004-01-07

> At present java program first be compile to bytecode
> then executed by a JVM. Normally JVM is a little big
> for most of the mobile device. My question is that
> why not just convert the java bytecode to native
> executable before it run ( include the necessary JDK
> class ). Then it will run just as a native program.
Well, the java/jvm spec does not mention how the code has to be compiled.
Just because Sun's JVM does work this was, does not mean it has to be.

Some Sony-Ericcson phone for example compile the app as soon as you install it, some others don't have a JIT.

> It will have smaller memory foot-print and run faster
> than the normal way.
It won't run faster, you can't do many optimizations when you compile ahead-of-time.
Furthermore I know very little JME apps that spend most of their time in java-code.
Most of the JME apps are games, spending 90%+ of their some in native code.

> When deploy the
> program we convert it to the native executable for
> the target device.
> I want to know why we don't use this method to
> address the mobile application development. Does JVM
> provide so much advantage that we can't by pass it in
> any way?
Well, I've worked for a JME company, and we supported about 50+ mobile phones.
For us such a deployment model would have been a nightmare.

There are other toolkits like "breed" (or called something like this) or symbian or windows-ce-apps that work with pre-compiled code. The reason why you see only so little of them is that the deployment model is so expensive. I guess thats also the reason why Microsoft developed their .net-compact framework.

lg Clemens

hcucu
Offline
Joined: 2008-03-18

> Furthermore I know very little JME apps that spend most of their time in java-code.
> Most of the JME apps are games, spending 90%+ of their some in native code.

Was there a research done about how much of the time the apps are spending in native code or is this your empirical opinion?

I'm really interested about this as I've done some testing myself and, for example, on some Android applications the time spent in native methods did not exceed 30%, while a typical value was 10%-15%.

I haven't tested on J2ME and the percents could be a little higher that on Android (cause Android has only a few natives), but I doubt they are so high.

So, finally, the question is "are there any statistical studies that focus on these things?"

Regards,
Horia

terrencebarr
Offline
Joined: 2004-03-04

You have some good questions but consider that Java already runs on billions of mobile devices today so obviously the cornerstones of the Java VM runtime can't be all that wrong ;-)

First, a JVM isn't "too big" for mobile devices ... as witnessed by the fact that Java runs quite well even on lower-end phones today - modern VM technology is very smart about memory usage, dynamic compilation, and runtime optimizations. Also, what's "big" is typically not the VM but the libraries - and you have those in any language or runtime (including native).

Next, ahead-of-time compilation of Java or bytecode into native instructions of course *can* be done, but you loose many of the benefits of an intermediate representation that way, in particular the security aspects and the ability to do runtime optimizations. There are special cases where ahead-of-time compilation is useful (for example, for core libraries which are locked down into the device). But in many cases, dynamically compiled and optimized code is equal or better in performance compared to compiled C++ code. Java's supposed slowness has been disproven many times.

Finally, platform independence is a very valuable property. In today's market there are hundreds of different devices. Compiling Java to native platform-specific executables for each and every device is unmanagable and often not even possible as many devices have no native API and programming model. That's why Java covers hundreds and thousands of devices today and native platforms only cover a fraction of that.

Hope this helps,

-- Terrence

afishionado
Offline
Joined: 2004-05-26

> Finally, platform independence is a very valuable
> property.

Let me play the devil's advocate here for a second.

The mobile market today is very fragmented. Every other mobile device supports a different set of functionality (phones versus PDAs versus camera phones). Furthermore, the J2ME implementations today are extremely fragmented; I have heard the claim that there is no single API in the standard that is not seriously broken on at least one major device.

So, is processor-independent bytecode actually meaningful for portability in the ME environment?

- William

terrencebarr
Offline
Joined: 2004-03-04

Sure, Java ME fragmentation is a source of extra effort and frustration but one of the key reasons is because the underlying native platforms are so radically different (not really Java's fault). Deploying native apps not only requires developers to deal with the native differences but adds a new layer of complexity with different processors, executable formats, operating systems, libraries, security mechanisms, etc, etc. It grows the problem space by two or three dimensions.

And fragmentation in Java ME has a bad rap but if you plan ahead and choose the right design for your app it is actually quite manageable. For example, the LWUIT demo (https://lwuit.dev.java.net/), which is a pretty complex application in itself, runs absolutely unmodified (same jad/jar file) on a dozen *completely* different devices (Nokia S40, Nokia S60, SE W910i, SE K850i, Playstation Portable, Windows Mobile, etc) and even automatically supports device-specific features such as 3D accelleration and touch-screen support.

-- Terrence