Lots of doors are being closed for Java

[zammbi]

China statistics are interresting too, this represent a lot of people.... http://gs.statcounter.com/#browser-CN-monthly-201001-201101

55% still on IE6 wow...

[philfrei]

Ah you must live in a world of early adopters and risk taking geeks.
The rest of the world is about 3-4 years behind you I'm afraid. I only just started using Java 5 about a month ago because of the number of OSX users still on JDK1.4 - now at an acceptably low 10% or so, so I can live without their money.

Cas

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.

[princec]

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

Games published by our own members! Check 'em out!

[JL235]

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!

[JL235]

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.

[BatKid]

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?

[krasse]

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.

[JL235]

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).

[krasse]

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.

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.

[gouessej]

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.

Games published by our own members! Check 'em out!

[pron]

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.

[dleskov]

Will try one more time to pester Excelsior. Last time I asked Dmitry they were looking at a low five-figure sum to get an ARM backend on their incredibly good AOT compiler/VM.

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

[kappa]

Full-fledged iOS port is a different story though.

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.

[dleskov]

Full-fledged iOS port is a different story though.

Not sure how profitable it'd be (compared to how much it'd cost to develop)

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...

[princec]

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

[dleskov]

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.

[kappa]

LWJGL + a headless port should be more then enough for any type of game.

[gouessej]

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.

[princec]

I thought JogAmp rather required AWT to work?

Cas :0

[badlogicgames]

+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.

[Matzon]

I thought JogAmp rather required AWT to work?

Cas :0

the NEWT display variant doesn't afaik,

[princec]

Aha that's the newfangled JDK7 / Prism / JavaFX plugin thingy?

Cas

[kappa]

Aha that's the newfangled JDK7 / Prism / JavaFX plugin thingy?

Cas

no, NEWT is JogAmp's own native windowing system.

[Mordan]

I will just repeat

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

2#J2SE is good because of backward compatiblity but it has grown thick and fat. Too many useless classes. Keep it for those who need it.

3#Sun should have taken the J2ME core classes Graphics, Canvas and bases classes like String and build a super lean super light framework. Scrap the LCDUI package. Scrap Vector. Keep backward compatiblity of bytecode.

4# on top of the lean base framework, create a Swing module and Game Interface module. Make it so you can load Base+GameInterface without loading Swing.

[ido]

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

That is a very minor (if at all) factor IMO. Flash didn't (and doesn't) have an "application shop" and that didn't prevent it from becoming the de-facto standard for web games.

[Mr. Gol]

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

That is a very minor (if at all) factor IMO. Flash didn't (and doesn't) have an "application shop" and that didn't prevent it from becoming the de-facto standard for web games.

Agreed. There have basically been two periods when Sun made a serious effort to improve Java on the desktop. The first was around the 1.4 release, and the other was before the release of 6 update 10. In both these time periods the concept of an App Store did not exist yet.

[princec]

So Java is no longer included in Mac OS... this presumably means that OpenJDK should be generally available for Mac really soon.

Cas

[tberthel]

I will just repeat

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

2#J2SE is good because of backward compatiblity but it has grown thick and fat. Too many useless classes. Keep it for those who need it.

3#Sun should have taken the J2ME core classes Graphics, Canvas and bases classes like String and build a super lean super light framework. Scrap the LCDUI package. Scrap Vector. Keep backward compatiblity of bytecode.

4# on top of the lean base framework, create a Swing module and Game Interface module. Make it so you can load Base+GameInterface without loading Swing.

Wow you can read my mind.  Not only that, but I actually did all those things and more all by myself.  Since, I have no funding I can't really drive my stuff very fast.  I just turtle along with FreeBlisket and the AllBinary Platform.  I only have half a million lines of code and shit to myself.  It is sad really, but I love making software.  Oh wells.

[Mordan]

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

That is a very minor (if at all) factor IMO. Flash didn't (and doesn't) have an "application shop" and that didn't prevent it from becoming the de-facto standard for web games.

well, at the time it was not called "app shop". I remember when Java Web Start came along. That was brilliant. Why not having a favorite list of JNLPs? A tool to manage downloaded JNLPs? They did nothing else but provide the mechanism of Java Web Start. They didn't bother building the bells and whistles. They might have coined the word "app store" before Apple if they did some end user/desktop work at the time.
Back then I was thinking, build a bloody Java OS layer over Windows. They did not. too bad.

It is like the failed Savaje os/phone. Sun is a failure in end user experience. You can't win it all. Their core competence was server side.

[Jacob_]

For a highly website-integrated GUI application like my own, Java was the best way to go. .NET ClickOnce sucks and is Windows-only, and system GUI widgets don't work in Flash. The second best way would be to use a custom protocol handler, but that would require an installation... with Web Start you just have to click a link. Putting out updates is a snap too.

Beyond desktop games, I think mobile gaming is where it's at, but Oracle seems more interested in pushing their server technologies than anything else.