Why Java, not C++?

[blahblahblahh]

I'm getting ready to evangelise java as a games-dev language to professional games devs. Most of this I can do no problems but there's some help I could do with: bullet-points to answer the question "why bother switching from C++ lang to java lang?".

i.e. NO platform points (got more than enough of those).

i.e. it's been sooooo long since I've been a C dev (and I never did much C++) that I now only have vague memories of what makes it so much nicer to code in java.

So...let me have em! .

NB: I'm not looking for arguments, just single sentences. If I have no idea what you're getting at, I'll ask. But I'm pretty sure I'll recognise them when I see them.

[kevglass]

* Productivity - spend time focusing on the game functions not the language functions.

* Reusability - a lanaguge designed to produce reusable components tending the developer away from "shot term hacks"

* Toolset - Development toolset is rich and for the most part free. (note this isn't a great point when you consider the current engine status)

Kev

[shawnkendall]

Security - due to impossibility of pointer/memory exploits/bugs

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

[blahblahblahh]

I was hoping for:

* Productivity - spend time focusing on the game functions not the language functions.

more specific than this - you know what programmers are like, they want concrete examples.

For instance, saying "never have to do malloc" as opposed to "it's better to have stuff managed".

* Reusability - a lanaguge designed to produce reusable components tending the developer away from "shot term hacks"

Again, need specifics.

* Toolset - Development toolset is rich and for the most part free. (note this isn't a great point when you consider the current engine status)

That's something I'd see as platform, not language.

[blahblahblahh]

Security - due to impossibility of pointer/memory exploits/bugs

Great. As above, "security" on it's own would be too general, but the details are good. Even better would be particular concrete differences such as (off the top of my head):

"buffer-overflow attacks are impossible because you cannot overflow data structures and write to memory"
"typeless references are impossible so you always know exactly what you are pointing at; modifying a pointer to point at something unexpected hardly has any effect on the program at all"
"all methods pass-by-reference-value, so you can guarantee that method args are implicitly final (as the caller; no such luck for the callee)"

etc...

[kevglass]

You asked for single sentences

Selling Java is selling the platform.

Productivity - Stop worrying about preprocessor directives, inlining and the name mangling a particular library uses. Start focusing on making your game toolset as smart as possible using the wealth of built in libraries for XML, GUI Design and Networking.

Reusability - Use a language designed around OO methodolgy instead of a lanaguge designed to illustrate an outdated unstanding of it. Stop worring about ornate intricaces of namespaces and multiple inheritence in C++ and start using the powerful yet simple syntax of Java.

No apologies for how managerial BS this sounds

Kev

[Spasi]

I think you should also get prepared (if not already) to give arguments against the reverse: why C++ and not Java.

For example, we know that any C/C++ developer will argue about speed (and the lack of it in Java). And we also know that game developers are not particularly interested in OO/design/reusability advantages.

[crystalsquid]

As a games proffesional (previously a lead core tech engineer writing graphics engines) I would have pooh-pooh'd java straight off due to the legacy of 'interpreted language'.

My advice would be to big up the JIT compilers by usingthe anology of the bytecode being the intermediate output in the compiler, and the final compile being on the target machine - hence able to optimise for the specific processor in question. Won't convince any console coders (fixed processor) but may sway a few PC programmers to the cause. Also point out that improving VMs would mean the code gets better optimised at a later point without you haveing to do any more work

[blahblahblahh]

Thanks. I've got some pretty convincing arguments lined up on the architectural and theoretical points, along similar lines. But I noticed I was short on specifics .

[oNyx]

Security - due to impossibility of pointer/memory exploits/bugs

That one is a very strong argument. If you take a look at all those *serious* bugs n loop holes... 99.99% of em are just forgotten checks... or using a signed variable where it doesn't make much sense (the bmp exploit) etc.

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

[princec]

Almost but not entirely irrelevant for client game code (one exception: network multiplayer games) (ok two exceptions: dynamic mods).

The real deal is all about productivity. More time writing game, less time chasing bugs, followed by loads more re-use later on, followed by really trivial refactoring even later.

The second deal is getting your software out on MacOS X for nothing.

Cas

[princec]

And as far as the platform goes - feck the platform, it's next to useless still as its market penetration is hopeless and broken. I've got my own platform now, a micro-VM and LWJGL. It's the bomb. I think you might want to mention that to these guys.

And I noticed your PM - would be glad to do an article on the micro-VM.

Cas

[CaptainJester]

Security - due to impossibility of pointer/memory exploits/bugs

Somewhat along these lines:

Have you EVER received a Windows GPF programming in Java?(Don't know what the equivalent is on *nix/Mac)

Sometimes you can spend hours/days/weeks tracking down a GPF bug.  Especially if it is not your code.  You will not get a GPF/Blue screen of death in Java.

[Eliwood]

You will not get a GPF/Blue screen of death in Java.

Hehe, unfortunately, this can happen, but it's not our fault. It happened in the 1.4.1.x series with some buggy graphics code. It freaked out my video card and blue screened me every time until Sun patched it up.

[Giddy]

Everytime you write a class in C++ you have to remember the 50 pieces of advice from Effective C++. (A great book)

They are all workarounds for flaws in C++, and most of them have been fixed in Java.


edit: messed up the BBCode

[TheAnalogKid]

from http://java.sun.com/developer/technicalArticles/Interviews/hamilton_qa2.html

Looking back at C++, there were a whole set of factors at work that make reading source code difficult: First, the C++ language itself became very complex. Many new ideas were added incrementally and, unfortunately, the seams show. Second, the C++ language consciously chose to emphasize "power" and "flexibility". That sounds nice initially, but, unfortunately, it also means that there is very little you can rely on and almost any simple program statement can have weird side effects. In C++ the statement "a = b;" must be approached with caution. Finally, the macro pre-processor reinforced the "power" aspect, but again at risks to comprehension.

[DaveLloyd]

My tuppen'th:

(1) Java is more than just conventional OO - it really does allow component-oriented programming where the contracts are enforced via interfaces or discovered via reflection. For games this is a real win as game engines often have a lot of different components that must interact cleanly.

(2) The great corollary of (1) is that it is sooo much easier to bolt on a third party component to a Java system and expect the result to be well behaved - in stark contrast to C/C++ where you can't even be sure all components are using the same malloc/free or where you get unexpected namespace pollution and you're no longer calling the function you first thought of.

(3) And following further on with bean-flavoured programming you get some big wins in the design stage as well as being able to drop new modules in at runtime. This usually eliminates the need for an auxiliary scripting language.

(4) The net result of all this is a platform with a truly astounding set of APIs (all cleanly documented with javadoc) - not just Sun's but all the FOSS contributions as well. I'm pulling together components from all over the place for my projects. So much effort saved, it's unimaginable to have done it any other way.

(5) The final argument on performance is JNI which is a really good way of packaging up high-performance C++ code which can focus on raw number crunching using available vectorisation etc, but where all the high level structure is kept in Java. Tools like SWIG make this pretty damn easy. (I also like the discipline that goes with separating out the performance specific kernel of the algorithms from the data structures.)

Dave
----
Fuze3D: http://www.shortfuze.co.uk/shortfuze/template/Fuze3D,Index.vm
Machinimascope: http://www.shortfuze.co.uk/shortfuze/template/Machinima,Engine.vm

[TheAnalogKid]

I totally agree with all of your arguments but with point 5, JNI calls overhead has to be considered since it's a significant performance hit. About that, are there solutions in the future to eliminate this problem since it prevents Java to be as fast as C in games in most cases?

[princec]

"significant performance hit" sounds like a mantra to me... our own testing shows that it is actually so small it can't even be measured reliably.

Cas

[TheAnalogKid]

Then how do you explain the performance hit encountered in Jake in there previous release? They clearly said that they had a significant overhead due to there numerous JNI calls.

[blahblahblahh]

it really does allow component-oriented programming where the contracts are enforced via interfaces or discovered via reflection.

Thanks. That's a great one, but I'd not really been thinking of it as a low-level practical thing - more as a platform thing - yet it *is* a low-level concrete thing.

Ditto your other good points.

all cleanly documented with javadoc

Sad but true, I was in danger of forgetting to mention javadoc. This would be unforgivable. C++ colleagues still strut around saying "yeah, I use doxygen for everything" as if it makes them a cut above the rest of the C++ developers.

Show doxygen to a typical java programmer and watch them die in horror.

Or, if you're old enough, go back through some old API docs and wonder how you retained your sanity with such horrendous documentation. I found myself stuggling to blieve that I really coded against such vaguely-defined ****!

(5) The final argument on performance is JNI

This one is bothering me quite seriously. Games devs *really* care about speed of access to memory. JNI still has significant per-call overheads, doesn't it?

I belive this is not a problem for most games dev, since you ought to be batching things to pipelines (hardware, etc) anyway if you care about performance, given the way modern hardware tends to have high-initial-hit-latency, low-subsequent-hit-latency.

But...what is the total overhead for using direct native BB's for communicating between java and C? I need to revise this (it's stuff I researched, evaluated against my own work, then didn't bother to remember the details of, only the conclusions that pertained to the work I was doing at the time  )

[DaveLloyd]

blahblahblahh wrote:

Quote:
(5) The final argument on performance is JNI

This one is bothering me quite seriously. Games devs *really* care about speed of access to memory. JNI still has significant per-call overheads, doesn't it?

I think you put your finger on it with the per-call overhead. Whatever language you use, the real high performance kernel should have its data batched up and run in very tight loops - otherwise you cannot sensibly superscalar.

An obvious example is with OpenGL where the goal is to push the bulk of the work further down the pipeline (and hopefully stay on the graphics hardware) so JNI call overheads are lost in the noise.

Or ODE (a rather good physics engine in C) where the kernel is essentially a wopping great matrix SVD (or approximation thereof). Again I've never noticed any performance loss just because I'm setting things up from Java but then running a sim step in C all via JNI.

Heck if you're writing top-end physics sims you'll probably still end up using hand-crafted BLAS libraries to get the max out rather than write it in Fortran (and Fortran generally optimises far better than C/C++).

Commercial engines these days push more and more of the basic graphics/physics and other raw computing down into middleware layers (Renderware, Gamebryo, Lithtech, ...) so that games programmers can focus on the game not on the engine.

(Aside: has anyone got any good BLAS bindings for Java?)

PS: You are so right about the days before Javadoc!!

[the2bears]

This seems obvious after thinking about it:

Why would M$ offer C# (read: Java clone) as their forward-moving replacement for C++?  Now, I'm no fan of Redmond but they must have done some research and they must have good reasons for essentially moving a huge development community to a Java clone.

Though they've made lots of mistakes before:)

Bill

[TheAnalogKid]

One reason (among others) might be that Java is a very popular ($$$) language/platform.

[DaveLloyd]

Another thought on Java evangelisation for you: tools. With NetBeans and Eclipse you get code completion and javadoc lookup with live error checking while you're writing code. You just can't do this effectively in C/C++ because even if you got over the hurdles presented by the language, you'd still have the preprocessor and the archaic header structure to contend with. You also get ANT instead of make, automake, autoheader, autoconf and configure...

[Edit] Nearly forget - and then throw in refactoring for real C21 programming!

Dave

[princec]

Ant's not really any better than anything else.

Cas

[phazer]

I would say Ant is much better than make.

[princec]

Probably, but that's not saying much, as make is beyond bad, it's almost like it was designed by a malevolent entity.

Cas

[DaveLloyd]

it's almost like it was designed by a malevolent entity.

Almost. Make was designed by a student during a summer job. Several years later now working in the industry he was horrified to discover that make was now a 'standard' tool complete will all of his bugs carefully documented - most infamously the use of tabs rather than any whitespace.
(I have the full story from comp.compilers somewhere but can't find it on google.)

[blahblahblahh]

Probably, but that's not saying much, as make is beyond bad, it's almost like it was designed by a malevolent entity.

100% agree. Except...I sometimes wonder if it was really invented by some malicious deity so that ANT users would have something to point to and say: "...it's so much better than Make". /me ducks and runs for cover

"make was a really good project for a college student [to implement] 20 years ago."
-- Tim Leonard, Intel Massachusetts Microprocessor Design Center
( http://vestasys.org/why-vesta.html )