[quote]China statistics are interresting too, this represent a lot of people… http://gs.statcounter.com/#browser-CN-monthly-201001-201101
[/quote]
55% still on IE6 wow…
So true. I’ve run into a more than a few of folks that can’t run my little 2D puzzle work-in-progress, thanks to my using Java 1.6. And they are unwilling (nervous/lack confidence) to navigate the existing Java upgrade process. If there is one thing that Flash has really done right, it is that it has made upgrading something just about ANY user both can do and is both comfortable and willing to do. That little pressure point is like a Spock-hold on Java’s client-side neck.
Still, JL235’s assertion is that browser tech is kept up-to-date much more than Java tech, and that’s cool, the proof of the pudding will be in the tasting and all that. Just not quite a risk I want to take just yet. I was an “early adopter” with Java and look where it got me.
Cas 
More companies are also pushing the browser for client-side apps then was/is the case with Java. That’s partly why I believe early adoption is going to be more successful.
Even Microsoft is now pushing JavaScript + HTML5 over it’s own Silverlight. That’s really something!
Google have also just added the canvas to GWT (announcement is here). So now it would be easier to build Java games with GWT and deploy to the browser.
This is pretty awesome stuff. I don’t have much experience with GWT, but I believe that it essentially translates your java code into javascript so that it can execute in the browser. What are the restrictions? I suppose it only implements a subset of the java libraries?
Here are some facts about the JRE simulation:
http://code.google.com/intl/sv-SE/webtoolkit/doc/latest/DevGuideCodingBasicsCompatibility.html
Quite a lot of useful classes are emulated but you can’t do multithreading and full reflection.
What is really cool though is that you can setup remote method invocation (so you can seemlessly call methods on the server from the client) and be able to pass across instances of stuff from one to the other and GWT will automatically work it all out. But you can get some very strange error messages when it goes wrong.
In a topic about how ‘Java doors are closing’ this is certainly one that helping to make the language more popular for the client (in some ways anyway).
Yes, this is really cool!
It is also very straightforward to develop the server and client in Eclipse if you want to deploy your application on the Google App Engine. The JRE on the server-side supports a lot more functionality than the client JS JRE simulation.
You can also test everything offline just as a regular Java application.
On my view, Java to JavaScript solution is a possible way, not the single one, I don’t see this as a replacement of the current JVM. There is already GWT, I’m not sure Oracle should provide its own solution except if it overcomes some limitations of GWT.
How about manipulating the DOM (including the canvas with or without WebGL) from a “headless” Java applet? Of course, it would not get around the need for the user to have a current JRE, but it may work around JavaScript’s performance, if that is the performance bottleneck at the client and not the DOM itself, as well as (possibly) the applet loading time. It is possible right now, but currently applets require AWT. Perhaps with the new AWT-free plugin scheduled for Java 7 this would be an interesting solution.
Manipulating the DOM using the Java language isn’t fun, but perhaps with a different JVM language, like Visage, it could be done as well as with JavaScript or even better.
We are dead busy with the x64 port right now, or, more precisely, with paying down the principal of the technical debt accrued for 10 years… But I can tell you that ARM is likely to be the next target, especially if Microsoft keeps its promise to make Windows available on that platform.
Full-fledged iOS port is a different story though.
Dmitry Leskov
Excelsior LLC
Not sure how profitable it’d be (compared to how much it’d cost to develop) but targeting apple platforms could be pretty cool, especially considering their recent anti-vm stance. Excelsior Jet could get a monopoly to becoming the only way to get java apps on iOS and the Mac App Store
Many developers would rather just write a game/app once (Android and iOS) and java looks like a perfect fit if the above worked.
You nailed it!
The problem is not the compiler, it is the standard library, specifically AWT native methods and L&F. Your app does not only have to be compiled down to native code, it must also look and feel native in order to get accepted in the iOS App Store.
For Windows and Linux, we just use the licensed reference implementation of the standard library. It costs us a hefty sum of money each year, but it is exactly the same code that Sun/Oracle ships alongside the HotSpot VM, so we get as close to 100% compatibility as possible. “Excelsior JET for Mac OS X” has been the #1 feature request ever since Apple’s switch to Intel CPUs, but the costs of porting AWT over to Cocoa and reproducing Apple’s L&F still looked prohibitive. Maybe something will change as a result of Apple contributing to OpenJDK, but we may face a license incompatibility then…
Aha!
…LWJGL based apps though are nice and easy for you to deal with though We’ll take care of the iOS interface bit. If you could just make JET spit out a .so we can call into from a stub…
Cas
Well, a headless port (that is, without screen/mouse/keyboard related parts of the library/runtime) is indeed permitted by the Java license, and we may start with just that on ARM/Linux anyway. An iOS port should not be that difficult then.
Field of use may be a problem though - Java SE is still not permitted on cellphones, and its usage on devices other than general purpose PCs and servers is subject to royalties… I expect the former to change at some point as the line between cellphones and everything else has been blurred by tablets and such.
LWJGL + a headless port should be more then enough for any type of game.
LWJGLJogAmp or LWJGL + a headless port should be more then enough for any type of game.
I thought JogAmp rather required AWT to work?
Cas :0
+1 for JET on ARM. Kev is currently looking into XMLVM which is of course far, far, FAR behind anything excelsior has to offer. However, with their upcoming C backend it seems feasible to at least create small GLES games.