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.
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."
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.
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).
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.
Operator overloading is another one of those language features that was so badly abused that it's value certainly becomes questionable.
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.
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.
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.
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.
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.