Linked by Thom Holwerda on Tue 1st May 2012 21:59 UTC
Thread beginning with comment 516595
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
It's a mistake to call a JIT an interpreter. Yes, it's possible to interpret bytecode, and that's what Sun's earliest implementations of Java did. But modern JITs will compile bytecode to native code before ever running it (or, in some cases, after it's run more than once). The only difference is that compilation is done when needed rather than ahead-of-time.
There are legitimate issues with JIT compilation strategies. The obvious one is startup time: there's a tradeoff between shorter compilation times and faster code, and so if you have to compile an application every time you run it, then you're going to do less optimization. But it's not interpretation.
At least then you bypass the interpretation layer and get a real executable to directly run applications.
Dunno, but (without having tried) it "seems" that only C/C++ are supported via NDK on Android. So maybe GCJ isn't supported there (and I'm honestly not sure it's still maintained upstream much, if at all, though I could be wrong).
RE[2]: Why not just use gcj
by moondevil on Thu 3rd May 2012 15:18
in reply to "RE: Why not just use gcj"




Member since:
2011-12-31
At least then you bypass the interpretation layer and get a real executable to directly run applications.