C++ V.S Java for game programming.

Pro for the one you're familiar with:
* You're familiar with it.

Con for the one you're not familiar with:
* You're not familiar with it.

I've got a better question. Red or blue. Which one is a better car color?

So, i'll post a serious response to this, since I often ask this question myself. Firstly, I am more familar with C++ than I am with Java, however I have dabbled in Java, and know enough to be able to make a decent definition of both.

C++

- Because Java requires the JVM and converts there source to Byte Code, (I believe this is called Interpretation), which is then compiled into native by the JVM makes it
slower than C++ which compiles directly to Native Code. There C++ is a faster language, and for games, the faster they run, is generally the better.

- Ability to handle memory allocation/deallocation, I guess some would find this a disadvantage, but personally I think this little facet is very useful for a lot of things.

- Object Orientated Support, in both languages, is a pro to mean.

- Industry standard. Why fight the craze? As they say, can't beat em, join em.

Java

- With C++ you need to use external libraries to alot of things, like graphics rendering, platform handling, networking, threading, etc, etc. While with Java, this pretty much all comes with the language in a tight little package. Sure they lack support for 3D (I think, might have changed since I last checked), but it still comes with numerous elements
that make it useful to just begin programming.

- Its cross-platform, meaning you can target your games to all devices, not to mention the JVM is portable to pratically any device or most, such as mobile phones, meaning you code once, and then its gonna work on any machine running the JVM. C++ requires that you compile to native for a specific OS/Architecture, furthermore the use of libraries like WinAPI and DirectX render your application unsuitable for cross-platform usage.

- Is it my lack of thorough understanding of Java, or is that it seems to be pretty much fully OOP orientated. I heard that its supposed to support multi-paradigms, but to me, it supports generally two, OOP and Generic. (And would we even called Generic Programming a paradigm ? or a feature? ).

Thats all I can think of now, its early and I have college soon, but that pretty much defines it for me.

I forgot what programmer used to say that picking a programming language is like picking a bar to hang out in. I tend to agree

I've got a better question. Red or blue. Which one is a better car color?

I'm gonna expand on this, seeing as someone rate-- it (which is fine by me, I'm not whining about it), just so people can know what it was I was trying to get at in case it wasn't clear originally.

The answers to the C++ vs Java for game programming question don't really mean much. Both are cross-platform computer languages which one can use to create games (or other applications, if desired). Particularly, when it comes down to a person's opinion/reasoning for their conclusion, it's mostly just a matter of personal preference. I might prefer to not have a garbage collected language, whereas someone else may prefer that. I might like a red car, but someone else might like a blue car. Knowing what someone else prefers isn't going to really help anyone that much.

A much better question is "what are the differences between C++ and Java (particularly in game programming [despite the fact that the game programming part of the question doesn't really change the responses too much])?" The reason this is better is because now you get the technical differences between the languages and you can form your own opinion of the two. Having a C++ vs Java debate implies that one is better than the other. Really, they're just tools one uses to create something. One isn't inherently better than the other. There are differences between the two, and understanding those differences yourself is much more important that knowing another person's opinion.

Basically I'm trying to steer you away from the idea that any one is better than the other. If there was an absolute answer, then the question wouldn't have been asked 1000x times before (and asked again). There isn't. There are just technical differences between the two. Understanding those technical differences yourself will do you so much more good than trying to decide which one is better than the other.

For the record, you may find this interesting. Now, if there's a more specific question you have, then it'd be much easier to answer it (i.e. what tools/APIs/libraries exist between the two languages that facilitate game development; why does there seem to be more C or C++ games than Java games; etc). But this C++ vs Java question is so big and vague and meaningless, and it's been asked so many times before, and the answers never change (hence anything you find via googling the question is almost guaranteed to be the same as the responses you'd get here).

Obviously, this is a highly debated subject, and you've all heard this kind of post 1000x before. But this isn't my only question, I would like to know your reasoning. What are the pros/cons for both languages?

Thanks

How exactly are the 1000's of other threads about this not sufficient for you?

The pros and cons are too numerous to list here; frankly my reasoning doesn't matter here. My experience using each language and solving programming problems in a variety of settings and enviroments are what color my opinions of each. Reason has little to do with it.

I've got a better question. Red or blue. Which one is a better car color?

Blue. Red is more attention-grabbing to most everyone, including law enforcement. Thus, if you wish to push the speed limit more, you don't want a car that screams "Look at me!"

To keep my post on topic, I would say that for more complicated games C++ is a better choice since you can get far better speed from low level optimizations. I also would say that nothing good has ever come of Java, but that may be because my day-to-day experience with it is my crappy set top box that can't do anything right.

I also dislike that you have to download a 160-200MB runtime (not counting 3D libraries) to run a 2MB program whereas with C++ at worst it's a 20MB runtime (again not counting 3D libraries).

Finally, I hate the verbosity and poor design decisions of Java (everything must be in a class, no operator overloading, etc.) that ends up making things more complicated than they need to be.

OTOH I do like the "compile once, run anywhere" you get with most Java programs. Too bad that goes out the window once you need to use native code to do something (like 3D).

The "interpreted language, so it's slower" thing isn't so true anymore, since the JVM is more of a JIT compiler (it rebuilds the Java bytecode as native code as it runs) so a particular piece of code is slower only the first time it's run.

In all, I prefer C++ because it's less verbose, doesn't force you to adopt the "One True Project Style," allows operator overloading (which helps cut down verbosity and clarify the code if done right) and allows you to much better push the hardware to the limit.

I forgot what programmer used to say that picking a programming language is like picking a bar to hang out in. I tend to agree

If you're trying to get laid, the choice between gay and straight bar will matter a lot.

So yes, it matters.



As for Java vs. C++.

They are languages. They cannot do anything. Not even a console application.

So the choice comes down to run-time. If Java:
- JEE, JDK, JME or Android (they are different in the same way C and C++ are different)
If C++:
- The OS (Linux, OSX/iOS, Windows pre-8, Windows 8+)

Each of these is what matters. They determine what can and cannot be done.

[quote name='daviangel' timestamp='1327304010' post='4905361']
I forgot what programmer used to say that picking a programming language is like picking a bar to hang out in. I tend to agree

If you're trying to get laid, the choice between gay and straight bar will matter a lot.
[/quote]
Way too picky. Of course, if you start talking about which is better, C++ or Java, then I guess it becomes moot.

The only criteria of any value I can see here is ease of deployment. Last time I looked (and I'll grant that it may be improved by now) JVM deployment, maintenance and management was still a little - shall we say - un-polished. True, a lot is exposed via the control panel, but there were still cases where you had to hunt down text-based cfg files (which may be scattered around multiple locations) and edit them manually. That's fine if you're a programmer or an admin who does this kind of thing every day. It's not fine if you're an end-user who just wants to get on with playing the game.

I would like to know your reasoning

Reasoning? of what? If one language is better than another?

There isn't any.

If you are still asking if one language is better than another, you need to learn more languages.

My tool of choice is Java. Despite the verbosity of it, I can program a lot faster in Java because I don't have to worry much about memory management or little optimizations.

The only downside to using Java for my purpose (simple games) is ease of distribution to the end user. I have found that a lot of people either don't know you can double-click a .jar to run it, or they don't have Java installed, or they don't know what Java is. To fix this, you have to use something to convert a .jar into different EXEs for different platforms, removing the ability to run on all platforms with just 1 file. That results in the same distribution method as C++: different files for different platforms.

Also, to the person who said doing 3D in Java causes it to lose its cross-platform feature, you are wrong. If you use a library in Java, it comes with extra files specific to each platform. You simply put all those files with the .jar file and then you can still run that .jar on any Java-supported platform.

- Its cross-platform, meaning you can target your games to all devices, not to mention the JVM is portable to pratically any device or most, such as mobile phones, meaning you code once, and then its gonna work on any machine running the JVM.

I'm curious how true this - not a nitpick, this is a genuine question. Will a Java application that runs on desktops also run fine on J2ME? Then there's Android which uses some form of Java, but isn't AFAIK compatible (at least, I don't think applications for J2ME run on Android, and certainly not vice versa). OTOH, C++, whilst not supported by major platforms like S40, will run on a range of higher end mainstream platforms like Android and Symbian.

Whilst C++ doesn't have a standard libary as complete as Java for things like graphics rendering, platform handling, networking, threading, etc, there are cross-platform libraries available which do all of this (e.g., Qt, SDL).

Will a Java application that runs on desktops also run fine on J2ME? Then there's Android which uses some form of Java, but isn't AFAIK compatible (at least, I don't think applications for J2ME run on Android, and certainly not vice versa). OTOH, C++, whilst not supported by major platforms like S40, will run on a range of higher end mainstream platforms like Android and Symbian.
[/quote]
Java and C++ are the same in this regard. Your dependencies are your dependencies, and they must be present and correct on your target platform for your software to work. You depend on the runtime, at minimum This is essentially Antheus's point.

Java has the advantage of a smaller set of richer standard runtimes and dependencies, but supported on a more limited set of devices. You will be able to get some kind of C++ application on almost any device, but the standard C++ runtime is almost non-existent. C++ dependencies tend to focus on a particular thing (requiring more of them overall), and also may have chaotic levels of support across devices (they may be present, but are they reasonably bug free?).

You generally do not want a Java application that acts the same on the desktop as on a phone. You can certainly have a base set of pure-language logic that can be shared between two similar applications, but the U.I. stuff should be tailored to the device anyway.

[quote name='DevSykes' timestamp='1327302463' post='4905357']- Its cross-platform, meaning you can target your games to all devices, not to mention the JVM is portable to pratically any device or most, such as mobile phones, meaning you code once, and then its gonna work on any machine running the JVM.

I'm curious how true this - not a nitpick, this is a genuine question. Will a Java application that runs on desktops also run fine on J2ME? Then there's Android which uses some form of Java, but isn't AFAIK compatible (at least, I don't think applications for J2ME run on Android, and certainly not vice versa). OTOH, C++, whilst not supported by major platforms like S40, will run on a range of higher end mainstream platforms like Android and Symbian.

Whilst C++ doesn't have a standard libary as complete as Java for things like graphics rendering, platform handling, networking, threading, etc, there are cross-platform libraries available which do all of this (e.g., Qt, SDL).
[/quote]

I can't really answer that question as Java isn't a language I choose, I work with C++ mostly, and even then I consider myself a beginner. I was saying as more of a front for my personal opinions what define it for me. The reason I stated that java runs on a magnitude of platforms, android realistically is because of android. Meaning you can program android applications in a familar language, I should have been more specific. Nevertheless C++ can be, but to my knowledge requires a driver, and a bit more work to actual run for a device, I could be wrong, but thats what i've come to understand. Generally, and advantage I forgot to mention, Java runs on the web, C++ doesn,t (unless you count Native Client).

I stated to my knowledge I was under the impression that JVM could run on a variety of platforms, being portable, and because it was ported to the mobile phone so easily. (although, it does require the Linux Kernel to back it) it seemed to me it could be transported to other platforms as well. Anyway, going on a tangent.

Something to research into I guess.

I'm curious how true this - not a nitpick, this is a genuine question. Will a Java application that runs on desktops also run fine on J2ME?

It won't even run. About 98% of classes used by desktop are missing. JME has 20 or so classes total + vendor extensions. JDK has about 100k in standard library alone.

Then there's Android which uses some form of Java, but isn't AFAIK compatible (at least, I don't think applications for J2ME run on Android, and certainly not vice versa). OTOH, C++, whilst not supported by major platforms like S40, will run on a range of higher end mainstream platforms like Android and Symbian.[/quote]

They are different things. Android isn't even Java. It's Java like syntax (that whole licensing dispute with Oracle they had back then was over Google not licensing Java).

I've listed options above:
JEE (enterprise edition, IBM WebSphere, Rational* tools, App servers)
JDK (standard edition)
JME (there's about 3 basic profiles, and a lot of proprietary extensions, the only thing shared is the very basics of some classes and syntax)
Android (Java compatible syntax, but uses custom JVM and unlicensed runtime, if lawyers had it their way it wouldn't be even called Java).

These are the most common ones. There's some other variations but not in widespread use.

Then there is the Open vs. proprietary libraries dispute. Oracle holds some patents on parts of standard library. Despite being open, one isn't allowed to do certain things with it, so the open versions of JVM runtime are missing some minor parts or are a patent minefield so they are available as part of optional install. It's a mess really.

JDK is subset of JEE. Both run on same VM, difference is in tooling and standard library. JDK is what desktop users install, there's plugin + SDK downloads.
JME is simply per-device, there is nothing portable about it.
Android is something different again.

Soon there will be commercial edition of some of Java platform, but it should be compatible with JDK/JEE. Then again, who knows.

JVM could run on a variety of platforms, being portable, and because it was ported to the mobile phone so easily. (although, it does require the Linux Kernel to back it) it seemed to me it could be transported to other platforms as well.[/quote]

Bytecode and source code could. But if mobile device uses a non-standard proprietary API that exposes OGL/ES mapping which isn't available anywhere else, then you're stuck. Same goes for all media and 2D/3D rendering code. It's either abandoned, not standardized or proprietary. So hypothetical portability in general sense isn't possible since crucial libraries aren't portable.

Between equal class of JVM however, things are write-once-run-anywhere, barring some major vendor snafus. JDK and JEE, for all practical purposes work everywhere, but only for standard libraries. OGL, for example, is not officially supported. Nor is anything beyond the most basic media playback, which requires native support from codecs, again due to patent and licensing issues. Good luck getting your special decoder for Solaris or somesuch non-mainstream (Windows XP+, Linux or OSX) OS.

If you stick in console or on server, things are ok-ish. Mostly. If staying on mainstream OSes. The recent versions. That do not block standard update channels (like Apple). Or mark JVM as malware (like Firefox).


Isn't this fun?

Hmm, thanks for that Antheus, seems to me that Java is a bit of a mess, however you have cleared up some part. So it's right in believing that the JVM and the code used on Android is not really the JVM used by the JDK or JEE but rather a modified version to run the Java Like Syntax code for the android devices? And you mention that Bytecode and Source could be ported, so if you used a basic application in java and tried to port classes to a device/platform to run on its JVM, then it's likely to run or have I missed the point entirely there?

Thanks

Java as language and syntax is trivial and can be easily parsed and compiled.

Then there are the basics, which not technically part of Java are still the absolute minimum needed. Stuff like java.lang.Object, java.lang.Thread. Anything Java will assume at least basic versions of these to exist. Then things start diverging.

java.lang.Object on JME has only a few members while standard editions have more.

Android is mostly a legal mess. It's Java as one would expect, but since Google refused to play on Sun's and later Oracle's terms, it's sort of unofficial Java version. As such, anything goes. There are currently no applications that would make sense to run unmodified on both, desktop and android. The differences in functionality and interaction are simply too big and Swing/AWT/SWT have been stuck at around year 2000. So it's a non-issue. Android also doesn't strictly use a VM, Java code is compiled. That makes some full-blown Java functionality difficult or impossible to implement (run-time compilation or similar, somewhat common in enterprise app servers).


Benefits of using Java:
- programming model is identical. Listeners, patterns, methods, ... same everywhere
- idiot-proof. Java as language really is simple. It keeps you from getting distracted with various tweaks.
- GC and resource management behavior. The most radical, but also only one that completely avoids edge cases. These choices keep VM simple and at same time keep performance characteristics across platforms. Something slow on desktop will be slow in same way on phone and vice versa. In other languages the classes of bottlenecks vary greatly depending on hardware

As far as portability goes - the closer the device class, the better. Phones to phones is usually good, phone to desktop likely not. This applies to libraries only, not language or bytecode, those can alway be recompiled if needed.

- Industry standard. Why fight the craze? As they say, can't beat em, join em.

That's a pro under Java as well, mate. Wasn't ten years ago, but it is today.

I also dislike that you have to download a 160-200MB runtime (not counting 3D libraries) to run a 2MB program whereas with C++ at worst it's a 20MB runtime (again not counting 3D libraries).

I'm sorry, I really need to take umbrage with this. The JRE is only 16 MB, and typical libraries such as LWJGL are under 3 MB per platform. The JDK is 90+ MB, yes, but you only need that if you're developing in Java. Meanwhile, most C++ apps made using Visual Studio need to install a 12 to 32 MB Visual Studio runtime package, though there's no point mentioning DirectX runtimes these days as it's pre-installed in Windows 7.