Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

It would bring thousands of apps to the N900 and motivate Maemo devs to make apps compatible with the N900/Android phones.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

Nokia doesn't support Java and Android supports some kind of perverted version of Java, so unlikely same applications could work in both Android and Meego/Maemo devices.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

There is no way to run that version of java on the N900?

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

Most Android apps run over a customized Java virtual machine called Dalvik. Why on Earth someone decided that an already resource-limited device would need a VM to run apps is beyond me, but that means that Dalvik would need to be ported to MeeGo.

MeeGo apps could run on Android through Qt?

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

It is a modern (compiler science) way to have interpreted code in applications instead of fully compiled one.
Theoretically (and I believe in practise also in the future) interpreted code can be faster, more power efficient and less buggy than fully compiled one. There needs to be only one VM in RSS memory and all applications can use its codebase.
Device drivers and kernel is a different thing, but for applications it makes sense.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

It's unlikely that you would see Dalvik in Maemo (though I don't know why besides business interests.. for example is it owned by Google?). Though I remember reading something about people trying to bring QT to Android.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

Theoretically: Canonical developers aim to make Android apps run on Ubuntu

This has been previously discussed in the thread, "Android on Maemo and/or Mer".

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

Very nice answer. I have been waiting ages to read an explanation like this.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

Also, search this forum for NITDroid for info on an alternative OS method (as opposed to what the OP asked for, which is Dalvik running within Maemo).

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

on the topic of java, ARM cores have had a java accelerator for ages, thanks to j2me being "popular" on featurephones (with opera mini being the best known example).

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

They do, and the chip in the N900 includes it, IIRC. However, the output of the Android compiler targets Dalvik, which isn't compatible with the standard Java runtimes or most hardware Java accelleration.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

oh, nuts. More crazy from andy rubin i guess.
http://en.wikipedia.org/wiki/Andy_Rubin

the guy seems to run the android division as some kind of mini-apple, with himself as jobs, but the looks of it.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

Speed, power efficiency and bugs have nothing to do with the way Java was designed. The reason why Java code is not fully compiled and uses a VM instead to run the bytecode is portability alone, or in other words: write the code once and use it everywhere no matter the hardware architecture that is under the hood (which is what the VM is for).

Cheers.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

I am sorry, I have to correct this.

A virtual machine simply emulates another machine architecture in software.

It's a computer science way of implementing an abstract hardware platform that insulates us from physical hardware issues. The VM machine code, called "bytecode", is also compiled and we call it "interpreted" because it's not run by a real processor but a software emulator which may be higher level.

Theoretically, and therefore also in practice, interpreted code by its very definition can never be faster than native code. There are other advantages to using a VM but this ain't it.

As a VM emulates another architecture in software, the best it can ever hope to achieve is speed just below the native code. A machine that executes code that executes code is slower than a machine that just executes code, period. The fastest VMs aren't really VMs per se, they don't interpret the bytecode but convert it to native code (JIT) and run it on the real CPU.

It cannot be more power efficient either, for emulation overhead means extra power usage.

It won't be less "buggy" as far as functionality goes. It usually does have much fewer security holes, because the VM is an effective sandbox and I suspect this is one of the reasons it was chosen here (other being hardware abstraction).

Remember, there needs be nothing extra in memory to run native code, the CPU and hardware are already there.

A VM is easier to work on because, at least theoretically, you develop for a fixed generic platform and don't have to deal with hardware variations. In practice this write-once, run anywhere concept has failed miserably IMHO (witness all the bastardized mobile Java implementations and how we can't run Android apps on a standard, fully implemented JRE).

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

have you seen this article: http://www.saurik.com/id/10

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

That's only half of the truth.

In fact the running of a program depends sometimes heavily of the data given on runtime.
Passing these parameters to procedures can be a heavy load. On the other hand code can be optimized for special cases, determined by circumstances given at runtime.
(For example: In some cases you know that one test is useless or that one procedure will abort without result.)
Also branches can be predicted.

A classical compiler doesn't know the circumstances at runtime. It has to compile a general program open to all possible circumstances.
That isn't efficient.

The JIT (Just in time compiler) compiles code just before execution and knows much more about the special runtime conditions. The code can be optimized much more on special conditions.

The result is that the code compiled just in time can (depending on the circumstances) be much faster than a classical compiled program.


AFAIK the bottlenek of speed is the throughput to the CPU.
It can be heavily optimizedd if some conditions or parameters are known and heaven't to be examined in the CPU again.
If there is a loop this can create very efficient code.

Modern processors (like ours) are able to process bytecode as a kind of "virtual machine language". You can formulate inside the CPU with a special language your own "virtual machine language" (e.g. Java Bytecode, DEX, .net-Bytecode). Thumbee and thumb2 are a very advanced architectures (but actually not used with n900).


Ergo: It is even possible that Java is in some cases faster than compiled code.

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

the biggest win for meego would be to have QT support apps written for android or iOS. i.e. if QT can use the code wirtten for iOS or Android to create apps that can run in meego. if nokia can get this done there is no stopping meego..

Re: Could Maemo/MeeGo ever be compatible with Android apps and vice-versa?
 

No, the Cortex A8 does not have Jazelle DBX. It only has Jazelle RCT which is language independent as long as it is JITed (because it defines its own machine code, which they say it's broken on the OMAP3, btw).

On the other side, the A9 brings Jazelle DBX support back, and I have to wonder why..