for shooting oneself in the foot 
In about 6 months time his prediction will be true. FF 4 it (hopefully) out this month and IE 9 will probably be out within 6 months. Pretty much all FireFox users are running the current version; I’d estimate about a month for them to all switch to FF 4. For IE stats show that IE 7 users are pretty much non-existant which suggests that most users will upgrade to IE 9 quickly.
By that time FF, Chrome and IE will be more then fast enough to play pretty much all HTML5 games.
I’ve been seriously considering looking into writting an AOT bytecode to native compiler with LLVM. I too would love to have a way to target IOS and i too think that Oracle is missing a big oportunity here. Flash also goes the AOT/LLVM route on IOS, they even seem to have a nice Java wrapper around LLVM’s C API for their compiler. Suckers. Anyways, here are the problems that need to be solved.
- Getting to compile JVM bytecode to LLVM IM code and then to whatever target architecture. The target might even be another high level language like C. The biggest issue is implementing the Java memory model, e.g. atomicity of read/writes of plain old datatypes (minus double/long) among other things. That’s something you can hardly achieve when transforming to C for example. Other problems include obeying the ABI of the target platform and so on.
[list]
[li]Garbage Collection. Now, there’s a couple of ways to achieve this. The easiest route is to go full-blown libgc which is a conservative garbage collector implementation. Integration is dead simple, performance sucks a little though due to its conservative nature. Another route would be to write your own GC schema which is error prone and a general pain in the ass. Matthias mentioned the way the latest Python handles GC which looked to be rather straight forward (exact mark & sweep garbage collector). - Runtime libraries have to be ported. Now, there’s Harmony and Classpath of course. But those include a metric ton of native class which would have to be ported to all target platforms. Also, Harmony is a stinking pile of bugshit, at least on Android. Go ask Nate about how well the networking stack is implemented in Harmony. Classpath is pretty much out of the window as well for anything mobile due to its size. It’s also not straight forward to port. This is probably the most labour intensive task in this list. I’d suggest only supporting a minimal subset of the Java SE runtime, maybe even targeted at games at the beginning.
- Related to the first item, JNI support is a must. One could of course come up with a new way of letting Java interact with native code, but for portability reasons i’d not go that route.
- Debugging support, which is again related to item one. LLVM has some helpers in that regard so that should be doable. What’s unclear is the integration with toolchains/IDEs. GDB is no joy to work with in general.
That’s just the tip of the iceberg really. GCJ is not a viable option due to its dependency on Classpath and other little problems. It also uses libgc for garbage collection, just as Mono does on IOS and Android. That garbage collector is even worse than the one that’s available in Dalvik (altough the lastest GC is pretty decent from what i saw, concurrent generational gc). XMLVM is a crazy idea but suffers from so many unsolveable problems, it’s hard to even start to describe what’s wrong with it. Suffice it to say, it’s useless and won’t get any better (watch the respective Google Talk on Youtube).
JIT solutions on IOS, e.g. Oracle’s ARM VM are not viable either as those are not permitted due to Apple’s little rulebook. You can’t make read/write memory executable memory on IOS.
So here’s my reasoning for not taking on an AOT compiler (even though it would be a fun little side project). WebOS/Maemo/Meegoo/WP7 are irrelevant and don’t seem to catch up to either IOS or Android. While targeting those would probably net you some money i don’t think it makes a lot of business sense. IOS is still the most lucrative platform to develop for. Android doesn’t earn you shit as the mentality of Android people seems to be different. However, as things look at the moment, IOS is losing market share and Android seems to become the dominant mobile OS for the next few years. I therefore strongly believe that with proper business models you can make a buck on Android just due to its huge user base. Combine that with letting your app run on the desktop as well and you have some nice oportunities. I therefore will limit myself to developing for desktop/Android.
However, if someone is willing to take the AOT route, i’d be interested in helping out :)[/list]
While the XMLVM is impractical. I don’t think LLVM has any better results to show.
1 billion Android phones in 2012 will stay around for 2 decades and not just a few years.
I couldn’t ignore the 1 billion J2ME devices. That would supposedly include WP7 and Moblin/MeeGo for me. While my games have ran on Moblin and a version of MeeGo I don’t know if AppUp will ever let me in. The spec for J2ME on WP7 looks good, but I don’t have a way to test it.
Well instead of Android/Desktop I chose J2ME/J2SE/Android to give me an extra billion devices.
6 months is way too optimistic, I’d say it’ll be at least 1.5 to 2+ years before it’ll be widespread and compatible enough to be worth targeting and that is just for Canvas. WebGL is still continuing to look like a failed standard until IE either supports it or dies. Meanwhile Flash charges ahead with tech’s like Molehill likely to get 90%+ share much faster when Adobe push it out.
You didn’t quite read my post eh? Keep on trolling!
It was, to be fair, a slightly confusing and long post 
I’m currently investigating GCJ. Which I know has GC issues and may ultimately be too slow anyway. Fortunately I can work around GC to some extent without a vast amount of pain, and I use so little of the Java class libraries any bugs that might occur in Classpath should be also not difficult to find or workaround.
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.
I am beginning to think I might just give up on the iOS port of Revenge.
tberthel, please feel free to throw any serious optimisations you might have my way But I don’t want the code to end up looking like C, if you get my drift.
A few more logs for the fire: http://www.theregister.co.uk/2011/02/08/oracle_loses_client_to_server/
Cas
@badlogicgames: I assume you know about LLVM subproject VMKit? The last time I looked at it (probably over 6 months ago) it still had a long way to go before been usable. Apparently they have moved away from using the Boehm conservative collector to the JikeRVM collector since then, which should be a good thing. This could be used as a starting point for a bytecode -> native compiler. The java memory model shouldn’t be a problem as all hardware (that I can think of) insures that reads and writes of primitives (32-bits and smaller) are atomic. However, this seems like a route to insanity.
This is the trouble: these are all complicated twisty paths to extensive hair loss. This isn’t what I signed up for. I’d be better off ditching Java tech completely.
Hm.
Cas
ROFL. I can’t be the only one who won’t even consider switching in the first month because I want to see how buggy people find it, and will wait for 4.1 unless people are pretty much unanimously calling it a vast improvement. Once bitten, twice shy.
FireFox version updating is generally excellent. Unless you manually refuse it, then it’ll be installed automatically. I’ve also been running the FF 4 betas and they are fine.
That’s true about most Java tech for games. Java itself is more then capable but you have to manually build so much of the cruft to get anywhere.
One thing that might help is a framework for simply building games in Java. Perhaps LWJGL with a high-level library (libraries for collision handling, OpenGL based 2D graphics and automated loading of assets in parrallel), solutions for deployment (automatically deploys to a standalone or an applet with JNLP and non-JNLP bits sorted), a boot-loader that handles “your running an old version of Java” issues and other stuff like that.
I’m thinking that people just download, unpack/install, write just the game bits of their game and then deploy. It might also be best built as an Eclipse project template. That would make Java a more desirable platform for producing games.
I’ve got all that (in my own curious and fiddly way), I’m just shafted at the deployment stage. Sod it, I’m off to try Haxe.
Cas
he’ll be back
Indeed, first thing that happened was a virus warning in the installer. Sigh. Also realised I’m not sure I can live without stacktraces, fast GC, blah, blah. Grr. ANGRY.
Cas
Its usually the super untouchable IDE’s (namely Eclipse) and ease of coding that always gets me coming back to java
That is a bit what I try to do with TUER, someone using Eclipse only has to use a provided Ant target to generate the .classpath file (the default one works but only does not support os-dependent features) and that is all, the engine is provided, the map editor too.
What about consoles? Some people made suggestions for iphone. I’m interested in consoles because these are good platforms for first person shooters. Have you ever played with a first person shooter on Android? Except Doom, lots of them are not pleasant, you don’t see anything as you have to touch the screen to turn :s (look at Modern Combat Sandstorm, N.O.V.A, Toonwarz, Dark Area 1 & 2…).
Antiryad Gx supports the following platforms:
- AmigaOs
- Windows
- MacOsX
- Linux
- PS2
- PSP
- GameCube
- Xbox
- DS
- Wii
- PS3
- IPhone and IPod Touch
- IPad
It would be fine to have such a tool written in Java.
I’m not sure how much of a problem this is. As of now, no standard client-side environment exists, except JavaScript with its own problems and limitations (well, actually .NET is available on many types of devices, provided they’re Microsoft’s). So Java may have missed its chance on the client, but so has everyone else (except JavaScript). Java might yet make a comeback, and it might not. On the other hand, the client is becoming less and less important, and is used as a display layer only, while on the server side Java has few rivals when it comes to performance. It was beginning to be rejected on the server as well in favor of simpler technologies such as PHP and Ruby, there is now a flow back to Java when people are realizing that these techs are just not up to par, and make very bad use of concurrency. at the same time, in Java-land, new JVM languages are making big steps. Lift is slowly being recognized as the leading web framework for performance hungry applications, and soon we’ll have a fully functional Erlang implementation on the JVM. So all-in-all, I’d say that the Java ecosystem is in as good a condition as it ever has been, and it’s a pretty good one.
They actually have an AOT. The problem is porting the runtime libs. It’s indeed a good start, albeit there’s still a lot of work before that can be considered an alternative to a an Oracle/Excelsior based solution.
+1
I run it without admin privileges, so I’ll be very surprised if it manages to update itself.
Was Java ever an option for professional game development?
Forget it. No hardware vendor is interested in making it easy to port your application over to some other hardware. They want developers to be tied to their platforms and use whatever they offer.
Java would only stand a chance if some company would take the leadership to do it, and it won’t be Oracle, neither IBM, and apparently neither Google.