Why Java, not C++?

General Discussions
#1

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.

#2

  • 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

#3

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

#4

I was hoping for:

[quote]* Productivity - spend time focusing on the game functions not the language functions.
[/quote]
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”.

Again, need specifics.

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

#5

[quote]Security - due to impossibility of pointer/memory exploits/bugs
[/quote]
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…

#6

You asked for single sentences :wink:

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 :wink:

Kev

#7

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.

#8

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 :slight_smile:

#9

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 :(.

#10

[quote]Security - due to impossibility of pointer/memory exploits/bugs
[/quote]
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.

#11

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 :slight_smile:

#12

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 :slight_smile:

#13

[quote]Security - due to impossibility of pointer/memory exploits/bugs
[/quote]
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.

#14

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.

#15

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

#16

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.

#17

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

#18

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?

#19

“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 :slight_smile:

#20

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.