The various JVMs have some advantages over .Net/Mono
1) better runtime performance on *nix servers and in some cases non x86 clients.
2) Java is the "standard" language on Android. (The only good CLR implementation costs $299-$1899 per developer)
3) Some ARM CPUs can execute Java bytecode nativly.

When it comes to the actual languages i can't think of any reason to use Java over C# though and i wouldn't recommend Java over C# to anyone, (If you know C# you can easily switch to Java in the few situations where it works better anyway)

Jazelle is not really part of newer ARM ISA's, and has since been replaced by ThumbEE (now also deprecated).
ThumbEE, however, is not specific to JVM Bytecode, and can be used by CLR implementations as well.

You say this like it's a negative. Multiple inheritance is one of the worst features of C++, there is a reason later languages got rid of it.

No. Multiple inheritance has comparatively few applications, but it is not never the Right Thing. As the FAQ says: "People who spout off one-size-fits-all rules . . . make your design decisions without knowing your requirements. . . . there are some situations where a solution with multiple inheritance is cheaper to build, debug, test, optimize, and maintain than a solution without multiple inheritance."

FWIW, from a language/VM design and implementation perspective, MI is kind of a beast though, and its costs of supporting it tend to outweigh the cases where it is "actually useful", making a case for leaving it out of a language.

so, the classes+interfaces model can do "mostly similar stuff", and is much simpler/cheaper to implement (since the contents for every child class simply append onto the end of the parent class, ...).
another "cheap hack extension" to this model is making interfaces able to provide "default methods", which closes the gap a little more, but doesn't significantly increase implementation complexity (if a class implements an interface, and fails to provide an implementation of a default method, the one from the interface is simply grabbed and added into the class).

Operator overloading is another one of those language features that was so badly abused that it's value certainly becomes questionable.

No. If a language feature is abused, that doesn't mean the language feature is bad. It means that the programmers who abuse it are stupid.

In this case, not having it forces a hypothetical Java BigNum class to have an API like: "new BigNum(4).exponentiate(51).mod(6).subtract(1)". You laugh, but I have often seen method chaining of such cruftitude in production code.

yep.

traditionally, some amount of C++ code has abused operator overloading in stupid ways (some of which is present in the C++ standard library).
I suspect some of this may have been because it was still in the "new feature" stage, and many people will overuse and abuse new features until a sense of when/how they are best used develops.

but, they are still "pretty damn useful" sometimes, especially in cases where it actually makes sense, like extending the numeric tower with more types:
bignums or 128/256 bit numeric types;
vectors and matrices;
...

this is generally a big painful area in Java.

Lack of implicit control over memory manage[ment] is the only real missing feature that actually hurts the language, and even in that case, 99% of the time this is an advantage as well.

I agree somewhat, but not being aware of how memory is structured is a common pitfall of novice programmers. Exclusive use of Java encourages that. Finally, teaching ignorance of resource management is not merely suboptimal, but irresponsible.

yep.

better is to have things like structs and value-classes, and also an explicit 'delete' for cases where this is useful, ...

I'm not going to deny that C++ isn't somewhat messy and that, at least with respect to Java and C#, its syntax is somewhat less intuitive. I don't fancy perpetuating a holy war about which is better though, mostly because I don't really care. I will stick with my recommendation not because I necessarily like C++ better, but since C/C++ is the de facto standard for games, game engines, and high performance computing in general.

agreed.

The short version is that Java is more foolproof than C++, but it comes at the cost of power. C++ has a few gotchas (like implicit constructors, pointers, operator overloading and multiple inheritance) that can cause you some obscure bugs if you don't know what you're doing.

I think the major gotcha of C++ is a standard that basically states that half the things you technically can do in C++ result in undefined behavior. Especially beginners will do a lot of trial and error coding, which is absolutely fatal in a language that allows you to the most horribly wrong thing without so much as a warning.

In my experience one of the main reason for obscure bugs aren't "complicated" features, but relying on doing things in a way that "seems to work just fine" until it doesn't.

Quick example?

struct Header {
    uint16_t version : 3;
    uint16_t msgId : 3;
    uint16_t msgSize : 4;
    uint16_t msgType : 5;
    uint16_t needAck : 1;
}; 
 
uint16_t receivedHeaderData;
Header header = (Header)receivedHeaderData;

What's wrong with this? Hint: byte order is the same on every involved machine.

I use Java because it was the most used language on the Degree I recently finished. I would have preferred it focused on my first language, C++, but despite some eye-rolling at the way Java does certain things, I've stuck with it.

Using it for games programming...I've found I've not had to turn to any dedicated game or graphics api outside the standard Java library. For any 2D graphics and as far as "3D" ray-casting, I just do my own software rendering with setRGB on a backbuffer(women scream, men faint!). Years ago I would have used DirectX for everything, but I feel now that I'm at the level where I can code it myself...and doing it that way has been not only rewarding, but rather enjoyable. Bit slow, but for what I am doing its fast enough. I feel my education with Java has turned me into a better programmer where I no longer rely on API calls to deal with every problem I come across. I also keep the code to a minimum.

If you know Java well, and have good physical and online references to hand, then its a great language for at least 2D games. Another consideration is the Android platform which also uses Java...and as much as I can't stand those "hip'n'radical" tablets...there does seem to be a good games market for them. The days of "C++ is the only choice for games development" are now gone...although C++ seems to remain the main player.