Quote:
Originally Posted by lfmorrison 
Well, you may not need a virtual machine per se, since the vanilla version of the CPU used in the iPhone is supposed to be able to directly interpret Java byte code. You *would* however need a way to encapsulate the CPU's Java interpreter to reside within inside an ARM-native OSX process (much like the THUMB and ARM instruction sets can currently be interchanged in other hybrid ARM-based operating systems), and you would need a set of class libraries (APIs) capable of communicating with the outside world through that encapsulation.
But that would probably require specific extensions to OSX on Apple's part, whereas a completely software-based virtual machine would likely be doable by a 3rd party using only a full-featured SDK.

Well, you may not need a virtual machine per se, since the vanilla version of the CPU used in the iPhone is supposed to be able to directly interpret Java byte code. You *would* however need a way to encapsulate the CPU's Java interpreter to reside within inside an ARM-native OSX process (much like the THUMB and ARM instruction sets can currently be interchanged in other hybrid ARM-based operating systems), and you would need a set of class libraries (APIs) capable of communicating with the outside world through that encapsulation.
But that would probably require specific extensions to OSX on Apple's part, whereas a completely software-based virtual machine would likely be doable by a 3rd party using only a full-featured SDK.
Right, I was just pointing out that it appears doable. Abstractly, I would still call either of those approaches a "virtual machine", as even if you execute the code bytecode in hardware, you still would likely have to encapsulate that action within a virtual machine-type block (to OS X). Android requires each application to run in a separate virtual machine.





