If IE9 supports HTML5 Canvas I'm switching to it.

If Quake 2 can be ported to JavaScript using GWT, I figure I can continue to write in Java or Scala.

JavaScript VMs are getting a lot faster. Not as fast at HotSpot, though (HotSpot really is an awesome technology and it will be hard for any company to catch up with it). But it's decent. For most 2D browser games, it will make no sense to continue using Java if HTML5 Canvas is on every browser.

I really like the JavaFX language, but it's not taking off. The latest demos still crash or freeze my browser, it's never going to run on iDevices, the coolest Java handsets run Android, and some new TVs are going to run Android. Does JavaFX currently run on any devices? Does Sun/Oracle not have the proper connections anymore?

As for downloadable desktop games, as everyone has already said, it would be nice to be able to have a clear, legal way for indies to distribute HotSpot with their games (unless there currently is a way and I didn't know - I haven't been on the board in a while)

Pogg looks promising. I just emailed the developer asking if he'd like help getting audio to work. An all LGPL-solution would be great.

Great. Uses less CPU than Flash on my Mac. Didn't see any audio sync issues.

So, Cortado is GPL. Original Ogg/Theora code (and everything else Xiph) is BSD. What are the chances we convince the Cortado devs to switch to BSD?

Gratz on the release!

BTW how does XMLVM deal with iPhone's lack of garbage collection?

Interesting. How is app-loading compared to the emulator? I'm working on an app that takes way-too-long to load it onto the official emulator.

I agree

I wrote it 11 years ago, and it hasn't changed since (except for compatibility updates as various APIs changed... it used sun.audio.* classes back then - anyone remember that?). There are no weapon upgrades, no bosses, and only one type of bad guy. Yikes. It did get me my first job, however.

As for controls, WASD + mouse to fire works best for me. That's similar to WoW controls.

It's getting better. They added a fullsceeen option for applets, which is cool. Also supposedly the speed problems have ben fixed (haven't tested it though).

Still has problems on Mac, though. The video example hosed my browser, and the Snakes & Ladders applet wouldn't load. Still seeing security popups too.

Sound interesting but yeah, the details are vague. There are tons of questions on user experience, the infrastructure, etc. I guess we'll have to wait and see. I wonder what the store is written in - HTML/AJAX or a Java app? If it's JavaFX, it will be nice to see Sun eat it's own dog food.

Also I'd like to see comparison of the Java Store to services like BMTmicro, Kagi, etc.

Well, personally, it's not fragmentation that's the problem because I don't support older versions of Java (ie PulpCore considers them obsolete). Java 1.1 had lots of bugs, and when I stopped supporting it I could remove a bunch of work-arounds. Soon I'll stop supporting Java 1.4, which will mean the removal of more work-arounds. If Java 6u10+ has no workarounds, then the situation is getter better, not worse.

As for Dalvik, yikes, it doesn't even have a JIT yet. Plus, Android has the same problem:
http://www.talkandroid.com/949-android-cupcake-15-update-apps/

I agree, it's tough. PulpCore has several places that runs code only on certain JREs. Plus, I've been logging exceptions for a while, and there are certain methods that throw exceptions on some JREs even though the documentation doesn't say anything about it. And then there's IBM's JRE which has bizarre problems. It's tough for people making applets from scratch, if they want the applets to work everywhere.

However, I think it's getting better, not worse. I haven't into any problems with 6u10 and above. Plus the auto-updating feature is a huge benefit.

As far as libraries go, there are plans for modularization in JDK7 (Project Jigsaw). Perhaps that will help.

Or install it and go here:
http://code.google.com/apis/o3d/docs/samplesdirectory.html
Here a JBox2D-JS demo:
http://o3d.googlecode.com/svn/trunk/samples/box2d-3d/box2d-3d.html

It's obviously new, but something to watch.

Nope. JavaScript.

Yeah, maybe.

This is interesting (from the FAQ):
Thoughts?

Well this came out of nowhere. Google just release a browser-based 3D API. Small download, loads fast... no security dialogs... shader language...

http://code.google.com/apis/o3d/

Come on JavaFX team, you can't let Google win!

"Dalvik has no Just-in-time compiler"

The boy doesn't know the ways of the Force.

Good job Markus and Morre, both games are pretty clever.

Maybe Larry Ellison hates Microsoft so much that they'll pump money in JavaFX just to keep Silverlight down.

(Yes I was grasping at straws on that one)

Gotcha. Yeah I can see how it can mimic OS windows while a browser couldn't.
In that case, after thinking about it some more, I'd say go with Riven's idea of a coffee cup, and the as short a text as possible in the tooltip. Maybe just "Untrusted window [more info]".

I say use the coffee cup icon because JS alert dialogs show the browser's icon instead of a warning icon.

I was thinking of sites that spoof another sites login form. Really easy to do, especially since Google Account login is on a lot f different sites.
Here is an applet taking up 100% of the window content. Tested in FireFox. It doesn't show a warning. There are other JS tricks besides this one.
http://www.brackeen.com/appletwindow/
Maybe they don't. I don't have any examples where a page with a Java applet is marked as malware. But maybe that's where it should happen, since browsers warn against malware, phishing, etc.
If the goal is to make it less scary that what is implemented in 6u10, don't show any warning icon. If the problem is undecorated windows, only show the icon on undecorated windows.

Ok, well, ignoring for the moment that spoofs can be made with HTML, or an untrusted applet could be scaled to 100% of the window size and a warning wouldn't show. And ignoring that modern browsers have phishing filters.

Perhaps it should say something along the lines of "This isn't a web page - it's a Java applet. Don't enter passwords, credit card numbers, or other personal data. [more info]" Where [more info] would be a link, if needed. I'm basically paraphrasing from definitions of phishing.

I still don't understand what the warning is for. There's got to be a reason for keeping it, right?

The message should concisely describe exactly what untrusted applets can do that a normal application cannot.

What can a sandboxed (untrusted) applet do that an AJAX application cannot? If the answer is "nothing", then the message should say nothing. Otherwise, it should say what the untrusted applet can do.

"Be cautious what you type and click" is not specific, and probably scares people for no reason.

If it has to be a warning, and it's just as safe as an AJAX app, then perhaps the tooltip should simply say "Java Applet Window" or "Java Applet Window [more info]"

The thing about Apple and iPhone is, they focused on the user before the developer. How long was it before OS 2.0 came out? Apple spent tons of time making sure it *just works* before releasing the API to developers.

Sun is doing the opposite - focusing on the developer before the user. They are creating the API before fixing the show-stopping bugs (video playback bugs, browser crash bugs, etc.). JavaFX is actually a pretty cool language, and has some cool tech, but the bugs and trust dialogs make me run away in screaming horror.

That is really impressive.

Any chance of jPCT going open source?

Thanks. New version "should" be out later this week.

Hey elias, how are you guys using GAE? I only played the tutorial but it looks great, BTW.

From what I've read, creating a Thread or a Timer throws an exception.

Yeah there's the Google data store you use instead of writing files or using JDBC.

Other languages work with it (Scala, JRuby) but some frameworks don't (Lift).

PulpCore tracks dirty regions, and it's the single best optimization in the library. Even in some hardware-accelerated apps where overdraw can be a issue, it is worth it. Swing basically does it with the RepaintManager. JavaFX should do it too!

Yeah it's got some API limitations. No threads, no JDBC, no file system writes. Gotta make some sacrifices to use some of the Google magic, right?

You gotta love that the Images API has a "I'm Feeling Lucky" filter, though.

This isn't true for all 2D scenegraphs - Node-based systems can be much faster because dirty rectangles (invalid regions) can be computed automatically, therefore only changed regions of the screen need to be drawn (instead of drawing every pixel every frame). Of course it's possible to compute changed-regions by hand in immediate-mode image systems, but who would want to do that?

The fact the JavaFX isn't good with a large number of Nodes is a huge bug. Luckily trembovetski mentioned this will be fixed in JavaFX around the time of JavaOne.

*Bump*

A full Java 1.6 VM is now on App Engine:
http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html