sabinati's article wrote:ARM processors traditionally support two instruction sets; ARM state, with 32-bit instructions and Thumb state which compresses the most commonly used instructions into 16-bit format. The Jazelle technology extends this concept by adding a third instruction set, Java bytecode, to the capability of the processor, together with a new Java state.
How... interesting. I would, naively, think that a bad idea. Since Java bytecode is normally intended to be optimized by the JIT compiler, javac itself seldomly does any optimizations from what I've seen. When I've looked at decompiled class files, the bytecode looks more-or-less like a straight collapse of the source parse tree. I would imagine, therefore, that a "hardware accelerated" JVM running the bytecode as-is would actually run (potentially much) slower than a JIT JVM. Of course, it is true that the lack of a JIT compiler makes the JVM more lightweight (especially memory-wise) which may be worth more for embedded platforms, but it's hard for me to believe that the presence of a JIT compiler would matter a lot on a platform like the iPhone. I would love to see some benchmarks on that.
DatOneGuy wrote:[...]the touch-screen seems to be heatbased (can't use a stylus).
It's actually capacitive, so I think the main reason a stylus doesn't work is because most styli aren't conductive. I haven't tried a conductive one, but even then I might imagine that its small contact area causes a significant enough difference in response to confuse the controller.
That said, though, it may be conceivable that a slightly different UI for Haven would solve the problem by trying to prioritize between the various objects you're touching (a different UI would obviously be necessary anyway to compensate for the screen resolution). Doing such a thing might even be ever so slightly interesting for being a UI thing.