why java does not compile to native code?

[masijade]

Do you (couling) think it would be "generally" better to compile to native code? If so, why do you wish to restrict yourself and/or make loads of more work for yourself? Sure, you may have a "target" audience, but who's to say that others won't want what you're producing? And if you're producing native code you either can't give it to them or you have to redo everything again and again (and keep track of those versions, of course). And since the Jit/Hotspot is as effective as it is, I find it, more than, a bit pedantic to so concentrate on a possible native compiler "solution" (considering all of those questions above) when, at most it would acheive a negligible performance improvement, and would, just as likely, as things evolve, result in a performance reduction.

[couling]

I'm not in favor of native compiled code. I like java, I like the way it works, that's why I'm on this forum. I stated several benefits of java byte code earlier in this thread.

My point was to disagree with a statement (somewhere earlier in this post) that using JIT rather than static (the subject of this thread) produced better native code. I see no evidence for this and little reason why it should.

I'm a massive fan of Java's Object code and the benefits it brings. But I'm not a "fan-boy" and remain objective about why I like it. I always like my views to be challenged, hence taking part in this discussion.

[Fubarable]

I have seen objective data (although I can't find it!) where there are times when JIT works better than static compilation, usually with highly repetitive tasks, but that the converse is also (more often) true.

[Tolls]

Do the people producing these tests show their methodology?
Things like compilation flags set for the code, number of times run, the code that's run, the platform run on...that sort of thing.

Because without any of that then the stats are meaningless.

Can the JVM recompile code based ont he underlying hardware by the way?