You want a good example of a 3d Java game? Look at Runescape.
It uses Java for most of the engine, but has an optional OpenGL "plugin" for the renderer. That plugin is written in C++, and needs a different compile version for each OS/platform. It also only targets OpenGL 1.4, and breaks on any number of systems.
The underlying game and software/Java renderer will work on -any- system... But it's very slow.

With a strictly C++ game, we'd need to recompile for each target, but it -would- be faster and if done right would take advantage of the hardware features on each target, not just the base-level of features.

My take is that so long as we have a Debian-like compile system(and even allow proprietary apps to use one repo run by Nokia), it'll work great. Without a nice build system... no.

Actually, the Debian-like compile system is going away, but the good news is that OBS, which is replacing it, IS quite a bit better.

This is very interesting. Can you provide some more info regarding the benefits of OBS?

Why there is Qt-apps for N8 which are not available to N900?
If Qt-cross-compiling would be so easy as some people talk, why they haven't done it?
For many Android-applications there is not this type of problem. Software author doesn't have to recompile and test for every device.

Let's say Qt would come really popular and all hundreds of different phones would support it (also WP7, Android and iPhones). I do not think even then there would be server farms which would cross-compile automatically and port any new app to all those devices.

The WORA-level with Qt apps will not reach WORA-level of Java or Android-apps.

This is slightly unfair as Android devices are all running the same OS. Ofcourse Symbian handsets and Maemo handsets cannot run the same compiled and packaged code. Add to that there are hardware differences, no standard DRM on the N900, and increased costs to do with device procurement and testing compared to perceived revenue gain may explain the lack of cross porting.

I don't think it can either until the devices themselves become more standardised. But you mention Java - to give one example with similar problems with J2ME - different manufacturers use different keycodes which, at the beginning, meant that the same program needed to be recompiled for each handset manufacturer you wanted to distibute your app to. Not to mention you had MIDP1.0, then MIDP 2.0.. coding one game you could use the gamecanvas class, the other you'd need to write it from scratch. Wasn't a huge job but required skills and knowlege. Different screen sizes.. different max jar file sizes.. capsule 3d or no capsule 3d.. sound capabilities etc etc. Indeed there were companies created specifically for the porting and testing of J2ME applications. With iphone there's one device (although different generations) and one manufacturer, they dont have this problem. Google do reccommend a general standardized group of specs for Android devices. Nokia (and Symbian manufacturers in general) have been behind the curve somewhat, imo, on the need for standardization even within the same company.

To get back to the thread topic, I much prefer developing in Java and I wish there was an option to do so with Qt. An official option I mean, built into and distributed with the offical SDK. IMO a large part of the rapid application catalogue development for Android is down to using Java.

You're mixing three things here. Device, Operating system, and Application framework. You *never* compile for a device, but an OS version/release. Thus, your N8 app would generally work on the C7, E7, C6-01 etc. You would, of course, need to recompile for Maemo, Android and whatever imaginary OS or CPU architecture you want. BUT. This is actually BETTER THAN ANDROID, because (at least when all the platform wrappers will be complete) you have source compatibility (can you recompile a Dalvik app to run on any non-Android platform ?).

In other words, how are you going to port the app you wrote on your Samsung Galaxy S to your Samsung Wave ? Or from HTC Desire to the HTC HD7 ?

If you think about it, Android-apps have ZERO portability - they are only portable to other Android devices And... Did you ever do Java development on mobiles ? All those JSRs and JVM versioning/tweaks... Looked great on paper, but was hell to work with. It's no accident that people mocked the WORA acronym WODE (write once, debug everywhere).

First, Android is not portable at all: if you're not Android, you can't run Android app at all. You can't reuse existing libs easily. And your libs/apps are useless for others. Kinda bad compared to Qt/GTK where same apps/libs can be reused on desktop, be it Linux, Windows or Mac - who cares: works anywhere. So, those claiming about WORA: please tell me, how do I run your Android crap under, say, Windows/Ubuntu/whatever? Huh? No easy ways? Such a pity. On other hand I use dozen of Qt and some GTK apps on all mentioned + n900 and it's not that it's bad .

Second, look: there are certain problems with their platform design. It's obvious that Java speed is bad, not matter what fanboys are claiming. Then, dev's forced to use dozen of horrible tricks to run native code. Same result, but much more headache.

As the result, you can have pidgin or qutim on n900. Free. Featured. Powerful. Multiprotocol. Now good luck to find something like this for Android. Same goes for, say, mplayer. And what? You can't install your own codec to handle new audio/video format? What an open platform! It's so open that Google can't dynamically give VP8 support and have to re-issue whole new Android version to do it. On n900 it's just a matter of small package though.

And now Google tells their 3.0 is for tablets ONLY. So, you can't run tablet apps on phone at all. Ciao, interoperability.

Bottom line: Android is a cool platform. "Written once, fixing bunch of weirdest issues everywhere". The only problem is that you will rather get some kind of spyware than working player comparable to mplayer if you want to watch VARIOUS video formats.

This debate is done since long ago: everyone is doing native applications these days. Good luck trying to find any useful Android application that does not have native code.

Read the Android SDK Changelog and tell me they're not clearly trying to make native stuff easier.

It is not surprising that most of the Android team comes from the old PalmOS team. PalmOS 5 (aka Garnet) used Motorola 68k binary code as their "VM code". Just count the number of apps released after 5.0 than do not have or use any native code at all...

Seems they didn't learn after all, and repeated the same mistake, but are slowly correcting themselves...

java is for noobz. oh noes, your phone doesnt have a prescot core p4!! how are you going to run my java appz??

wake up! this is a mobile platform and battery life is king. c++ is more efficient than java.

only an idiot would argue.

I recommend you read some of the studies, papers "the idiots" have created about the future of C.S. and programming languages:

"A Survey of Adaptive Optimization in Virtual Machines"
http://www.research.ibm.com/people/h....html#survey05

"Java will be faster than C++"
http://portal.acm.org/citation.cfm?id=345105.352548

When there is an application, which needs lots of "short" living dynamic memory, and needs to run relatively long time, for example www-browser with tab-support; JIT-interpreted code (Java) will be eventually faster than fully compiled code (C, C++).

Most of the already known running-time profiling+optimizing techniques are not yet implemented nor in use in VMs. Just think VM able to reorganize memory objects in heap memory so L2-cache usage is optimized. That trick cannot be made to fully compiled code, but can be made to bytecode based running programs.

In device drivers and such, or in parts of a 3D-game-engine, where dynamic memory can be controlled very tightly, asm/C/C++ modules are more efficient and in the time critical tasks should be used instead of JIT-code with GC.

Most of the apps nowadays are not time critical, so Java or Python are better choices than C/C++.

(Python cannot be as JIT-optimized as Java because it uses dynamic typing, but I guess some day there will be Python-IDE which lets to define typing in to separate file for optimizing in JIT, if automatic heuristic typing guessing needs help.)