HTML 5 + GWT + g2d = fun for us Java lovers?

Java 2D
#1

I really like that you now can use Java to write games that are cross-compiled into Javascript using GWT.

I found a wrapper for the canvas, sound and video parts of HTML5 here:

http://code.google.com/p/gwt-g2d/

some demos where this wrapper is used:
http://gwt-g2d.appspot.com/

Edit: Here is also a library for WebGL:
http://code.google.com/p/gwt-g3d/

All this makes me very happy!!!

but… this is not really any news since that Quake II demo has been around for some time now and uses exactly the same method.

Anyways…
What do you think? Is this a train you will jump on?

#2

Looks pretty awesome to me :slight_smile:

Kev

#3

Even JBullet and java.awt.geom has been ported:

http://code.google.com/p/gwt3d/

#4

This sounds like a terrible idea. It shouldn’t be necessary to put so much crap between the language I write in and the code being run.

#5

If you want to write games that use the new HTML 5 stuff and avoid Javascript, I think it is well worth it. Since the WebGL and all that will be part of (or at least available in) every major browser it will make the distribution easier (in my utopian fantasy world).

Why do you even care about the “crap” between? It’s just cross-complilation (or really source to source translation). If you just want that part you can extract that from the GWT source code.

#6

This looks pretty interesting!

#7

Yay!
Looks promising indeed.
I changed the first demo to use 200 sprites -> ~ 3 fps. But I don’t think performance is very important at this stage.
A service like 'compile ‘n shrink’ would be cool, where you paste some Java code and get the translated JS page… (and Exceptions).

#8

Hmm actually performance is kinda important or nobody’s gonna be really all that interested :wink:

hAxe FTW!

Though I’m sticking with Java for the foreseeable future.

Cas :slight_smile:

#9

In general, I would like to avoid overly complex solutions to non-problems. I would just use JavaScript before something like this. It is just simpler and closer to the metal. Simple apps are probably fine using this crazy stuff, but then why bother with this crazy stuff? I would hesitate to use it for large apps because the commitment is large and the complexity seems unnecessary. The risk I would ever have to debug or profile code generated JavaScript turns me off.

#10

That’s the first time I’ve heard “javascript” and “close to the metal” in a sentence before. :o

Although I agree with your main point - this kind of things just adds yet more layers of pointless, performance-sucking crap between code and actual execution. Javascript is already waaaay too removed from the actual computer to be useful for anything other than visual frippery and toy apps.

#11

This sounds rather ironic, considering this is a Java forum. You’re using the same argument a C programmer uses against Java.

It’s really no different than Java. The functionality of the language is powered completely by the evnironment/libraries given to it. E.g. the WebGL-based Quake demo running on Google’s JIT’d v8 engine runs faster for me than Jake (which it is ported from).

#12

Except that Java has a huge standard library that actually lets you do system-level tasks, and isn’t hobbled by trying to run inside a 3rd party browser (applets not counting, they’re only superficially in a browser, not tightly coupled to it like HTML5 + JS). And even then you still need to dip into native code to actually get things done (ie. LWJGL, JInput etc.). WebGL isn’t a viable alternative yet and probably will never be for high-end graphics (ie. not just vanilla GL 1.4 or whatever), and you don’t have the alternative of dropping down to the OS layer for when you really need it.

#13

Really what you’re describing is a problem with HTML5/browsers in general. Browsers aren’t meant to be touching the OS on that level. That has nothing to do with the language, though.

For example, there’s nothing stopping me from writing an “LWJGL” for v8 and running JavaScript locally to talk to the graphics card directly.

Again, it’s all relative to the environment.

#14

That would hardly be HTML5 though, would it. Which is what this is about. No-one’s really interested in running a JS VM to make desktop apps, it’s about getting rich apps on a whole range of devices.

HTML5 and JS in it’s present state, while technically interesting isn’t practical for any serious development work IMHO.

#15

You don’t have to debug the generated code. You just use the regular debugger in for example Eclipse (if you use the GWT Eclipse plugin).
You just do whatever you do when you develop normal Java applications. A lot of the classes from the standard class library are supported like collections etc.

The official version from Google: All this effort from Google is because they like to use IDEs like IDEA, Eclipse, Netbeans etc. They simply love the tools that are available for Java and they want to abstract away most of that browser-specific Javascript. It is not because they don’t like the Javascript language. It is because of the lack of good development tools and the issues with several different browser implementations.

#16

I disagree. GMail, Google Maps, Google Docs (pretty much anything with Google in the name), Microsoft Office Online and lots more are examples of very sophisticated sites and web-applications which run without HTML5.

With HTML5 there is no reason why lots of the excellent sites that heavily use Flash (such as the BBC iPlayer and Grooveshark) couldn’t be built with it (and certainly will be in the future regardless of what happens to Flash).

The problem with my examples is that they are in the minority. The average desktop application today does tend to run better and be more sophisticated then the average HTML+JS powered web-application. Part of this is performance but part of it is also a lack of good frameworks and libraries. But I believe we are on the verge of seeing this change.

As long as the tools and result are excellent whilst taking as little effort as possible then I don’t really care.

#17

I’ve been unimpressed with the speed of javascript when using Google docs spreadsheets. It’s dog slow, even a paste takes about 2 seconds. And that’s on Google Chrome browser. MS excel is way quicker…

#18

No, it is because HTML, CSS, and JS is a crappy way to do it.

#19

JS is a bit like going back to 100MHz Pentiums. Even the fancy clever engines in Chrome etc. But then you have to remember, Quake looked rather nifty on a P100.

Cas :slight_smile:

#20

I once had a P120 and a demo reported to me “PHEW - WHAT A KILLER OF A MACHINE” :wink: