Last time I talked to Dmitri Leskov of Excelsior, JET was basically Windows or Linux, and there wasn’t the money to do a Mac port or XBox or Playstation, which is a massive shame. I’m wondering if Oracle might help out here.
Cas 
The basic idea behind zero is to kill all CPU specific code in the JVM tree (means zero assembler) to make the source more portable and easier to maintain. Add Shark (the LLVM portion) to generate native code. LLVM is designed for lifetime & whole program compiling and ‘should’ be vastly superior to tracing JITs. LLVM is starting to spread: Apple’s GCC & OpenGL and pretty much all OpenCL vendors. I don’t see a strong linux focus (other than redhat is pick-up the bill) on Shark/Zero and likewise for Apple & LLVM.
WRT Dalvik - register based VMs require 20% less instructions on average, so it helps with the memory footprint.
I understand your original point, I’ve always found it easy to write portable C. But as a devil’s advocate, the stuff that’s portable iffy in Java is likewise in C, no?
GCJ is considerbly better now. Pretty usable. Though still gonna give you cross platform issues.
IPhone-wise the XMLVM team have been working really really hard. It’s performance and capabilities are progressing very quickly. As to not being able to get any Java games on the Apple AppStore - I have 3 currently.
Kev
I’m still pretty miffed at their approach though. Their website makes all kinds of bold claims about transforming between language but the only transformation path that actually works is Java -> iPhone. They’d get a lot more respect if they were up front about it and said that was their actual focus rather than pretending that the other backends (ie. C#) were fully functioning when they’re flat out broken.
IMO, the major problem with Java is that there was bad choice of merging too much API and JVM into something called JRE…
If you write Java pure code it will run fine and the same (nearly) everywhere (thats also why I am affraid when they claim to add “closure” and such while Java is not yet stabilized…), but as soon as you start using JRE-API you get into trouble of versioning and bugs of the JRE.
Without all those very target-specific JRE-API, building a JVM for a new device (as building a C compiler) should not be that hard (because it is basically the same to do).
C is just Everywhere, back years ago… I had to built and program a DSP box using TMS320XXX, and guess what was the possible languages with the provided constructor tools ? ASM & C … “after the Assembly” C is probably the first compiler made for a new device.
EDIT : in contradiction with what I said above about JVM :P… it is probably related to the simplicity and its machine similarity for the whole language : implements while/for/if/switch/expression => C compiler is nearly finished.
Orange has just chosen GameTree tv for its ADSL boxes, it relies on C++ :’( Java has lost the fight once more. Oracle, please do something!!!
What we need is something like what Lua has - just a crossplatform shared library (with various other files for runtime classes etc) that you can call into from C. And an absolutely 100% liberal license.
Cas
Isn’t all the Swing and AWT stuff still missing? Plus Wikipedia says the project is practically dead now.
At the risk of bumping an old topic i wanted to add my 2cents.
Sure with an ANSI compiler you can write C that will compile on lots of things. But you better not do anything other than std out and read/write to files. Hell even then you better hope you use “file name” conventions that work across platforms (I just learned that OSX command line is case insensitive!). But if you want to write a GUI, then you need the right libs on every platform you deploy too, and someone has to maintain them etc… Before even getting to the gate, the situation is as bad as java or worse (generally worse).
Yes it would be nice if it really ran on everything, but the hardware market is diverse, and supporting even the 3 core platforms is hard enough and you don’t really have anything usefull unless you have some libs (well nothing that really an improvment over C/C++).
Its like wanting DX support for java, whats the point? Why not just use C# since the code can’t run on anything but windows anyway. 
Frankly having work with cross platform projects before, java is far easier than most languages. God i hate #IF …
As for GCJ, its quite a lot slower than just a plain old sun jvm. In fact all the AOT compilers i tested where slower than jvm with my code.
The point is, I don’t want to write in C
And I’d quite like to port my stuff easily to iPhone and XBox, where by “port” I mean, “not have to re-write everything in another language”.
Cas
As someone who has shipped games on Windows, let me say: this portability of which you speak is a myth. Just targeting multiple versions of Windows is a testing and maintenance nightmare. Java delivers WAY more out of the box than alternative technologies.
I hear what you’re saying about consoles - that’s a pain in the ass. Requires someone with cash to produce a JVM for consoles OR a cross compiler (probably an easier option).
Re: iPhone, iPad - that’s restricted due to Apple being protectionist assess. There’s no technical issues. I would think that similar issues hold for consoles (i.e.: it’s political, not techical issues at play here)
I know a bunch of guys who don’t have any problems with xplat C/C++.
I can run Lua on iPhone. It’s just a library. I want the same for Java. I just want a library I can call. It doesn’t need AWT, or anything much fancy. I’ll link it statically with my stub app.
Cas
that library work cross platform with keyboards/opengl/widgets and everything else? Last i checked, it didn’t.
Well, a Java interpreter isn’t too much hassle. Especially AOT bytecode compilation into something else (like Dalvik) and it’s even quite fast, like 10% (interpreter) or even 25% (compiled) of native speed LUA isn’t that fast either.
Could anybody point out (the obvious?) why a bytecode to C source converter wouldn’t work nicely? The C compiler would take care of fancy optimisations and (near) native performance. We could even sacrifice ‘advanced’ stuff like synchronized or multithreading, garbage collection, and obviously reflection. Once it works people will fill the gaps.
Edit:
Like http://lejos.sourceforge.net/
Like I say - I’m not bothered about the fancy stuff - I just want the bare minimum JVM that executes bytecode and manages memory, not the whole JRE. I can make my own libraries to interface to other platforms. Just as we have done with LWJGL.
@Riven - interpreters are way too slow for general purpose usage.
I believe the naive bytecode->C approach may have been tried but is barely faster than an interpreter and adds an inconvenient step that will probably involve GCC, may it die horribly. Besides, the memory allocation / garbage collection stuff is also required, along with a few other bits.
Ya knows what I want really. I just want to be able to use Java as a true general purpose language that I can run anywhere because it’s a portable C library.
Cas
lejos - interesting stuff…
Cas
I think this boils down to either a AOT compiler (the binaries would run natively) which is simply too much work for a community project, or a severely restricted subset of Java sourcecode to C source compiler. That’s actually doable. As time progresses, and people join in, the Java subset would grow.
Probably much easier and more productive to do a bytecode->C compiler, but with some bytecode based optimisations.
Cas
Well sure, but…