Pros and Cons of Java

[cylab]

http://en.wikipedia.org/wiki/HotJava

Unfortunately it's the one of the first things that manifested the "java is slow" legend

More critically, HotJava suffered from the performance limitations of Java virtual machine implementations of the day (both in speed and in memory consumption) and was consequently quite slow.

[kappa]

http://en.wikipedia.org/wiki/HotJava

Unfortunately it's the one of the first things that manifested the "java is slow" legend

that was a long time ago (16 years ago) in the dark days of dial up internet and slow low memory and cpu computers, I reckon it'd be much more successful if attempted nowadays especially with modern browsers.

[princec]

Something like, just embed a headless VM in Chrome (ie. without AWT and Swing). Pop in a decent API for DOM twiddling. Maybe Jikes, to allow actual Java source to be used as script as well as bytecode. Allow script tag to reference a jar and a class with a main method. Fiddle with security to ensure pages are sandboxed. Add LWJGL canvas for good measure That'd be seriously amazing really and make Javascript based applications look like the slow and crappy bugridden bits of shite they currently are.

Cas

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

[oNyx]

Mind you Apple have done their level best to completely break applets anyway. Grr.

What, realistically, is the performance difference between Java 6 and the fastest JS engines out there at raw compute power and memory writes?

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java

Regular expressions are super fast with V8. Generally Java (server) is at least 3 times faster. On average Java is about 5 times faster. And if you do something JS is pretty bad at, Java can be over 40 times faster.

It can be a pain to get javascript code to work the same in different browsers, let alone on totally different platforms. There will always be those hacks to get around variations between browsers, e.g. if(ie) { ... } else if(firefox) { ...}.
[...]
I've written a GUI platform in javascript that works great in Firefox, but I'd need months to get it working in Internet Explorer.

I rarely have any problems. JSLint helps a lot.

But perhaps that is all worth it. Javascript is pretty portable considering. It's the most used and widespread programming language out there.

After writing it for 5 years, I still hate how bad the OOP support is. It's like they've gone out of their way to not evolve javascript. It was never intended to be used so much, but it's #1 out there, it was supposed to be used as a "helper" scripting language for forms and stuff, and therefore doesn't even have basic OOP support. I'd really like to have classes, abstract classes, inheritence, polymorphism. I know you can simulate a lot of this stuff, but it just doesn't feel right.

http://code.google.com/p/joose-js/

"[...] classes, inheritance, mixins, traits, method modifiers and more."

Well, you can have classes and you can also have inheritance. Prototypal-inheritance, that is.

Something like, just embed a headless VM in Chrome (ie. without AWT and Swing). Pop in a decent API for DOM twiddling.[...]

Ah yea... DOM manipulation. This wouldn't be any faster with Java, C or C++. It's so slow because it's a super heavy operation. Reflowing (recalculating the layout) and redrawing are the slow parts. A faster language won't help there.

(Thankfully you don't have to touch the DOM for Canvas-based games.)

[princec]

I was under no illusions about the speed of DOM manipulation, but what would be doable in Canvases would be, well... Minecraft

Cas

[appel]

http://code.google.com/p/joose-js/

"[...] classes, inheritance, mixins, traits, method modifiers and more."

Well, you can have classes and you can also have inheritance. Prototypal-inheritance, that is.

Well, that's what I mean, it's a shitmix. Horrible syntax in that joose, just look: http://code.google.com/p/joose-js/wiki/BeforeAndAfter

I don't blame joose, I blame javascript.

Also, this doesn't run on all JS engines.

[oNyx]

>Also, this doesn't run on all JS engines.

http://code.google.com/p/joose-js/wiki/JooseAndOtherFrameworks

It even works in IE6. Why would anyone use an engine which is even worse than IE6's? It's over 9 years old and f-ing slow.

Well, I don't use Joose. Prototypal-inheritance is enough for me, but I don't even need that.

[JL235]

Java is great for big stuff, but most individual tasks I need to code with JavaScript is typically no more then half a page long. Like querying a page and displaying an error if it fails. With JQuery (or one of the other many JS frameworks) that's a trivial number of lines (and I'd argue it's far easier to read then using a Java alternative).

I personally would like to see a bytecode engine, probably similar to the JVM (plus it's dynamic extensions) in the browser. JavaScript, Java or something else would then just target that bytecode. But I believe for most games the speed issues are currently with the canvas (especially on my Linux laptop) and not with JavaScript. Like placing certain content on top or even behind the canvas can have a severe impact on it's performance in Chrome, FireFox and others (or at least for me). But all of the major browsers should be fully hardware accelerated (both canvas and the page) and adopted by the majority of people by mid-way next year.

Although there are still plenty of issues writing cross-browser JavaScript, I've yet to find any in regards to the canvas (although I'm sure some are out there).

Over the last year alone there has been plenty of development for using and improving; Flash, HTML+JavaScript and Silverlight. Over the next year I'll predict that all of those (including even Silverlight) will get more improvement then Java applets (even if it's just browser speed improvements). That is my main issue with using Java applets.

[oNyx]

>I've yet to find any [cross-browser issues] in regards to the canvas

The image returned by Chrome's Canvas got pre-multiplied alpha. Fortunately this doesn't really matter. If you want off-screen rendering you'd just draw that off-screen Canvas onto your on-screen Canvas (see: Off-Screen Rendering (Render to Texture) with HTML5's Canvas Element).

createPattern and drawing that pattern is very slow in Firefox. If you translate and then draw some image it's still pixel-snapped in Chrome. Both issues will disappear with hardware acceleration, however.

[krasse]

I go on and on about this... but by combining GWT with the HTML 5 canvas you can keep your Java, which is great for big things. The only major problem seems to be performance for non-hardware accelerated stuff.
Already discussed here:
http://www.java-gaming.org/topics/html-5-gwt-g2d-fun-for-us-java-lovers/23216/view.html