This is both partially true and partially false. The JVM is perfectly fine for making game engines (as Minecraft and countless smaller projects have proven over and over and over and over and over and…) but like any tool it has its gotchas. A lot of articles I’ve read that claim Java is slow or suffers from hiccups due to GC are either (a) dreadfully outdated, or (b) dreadfully misinformed (“it’s interpreted from bytecode so it CAN’T be as fast as a native language!”). It’s true that older versions of Java (i.e. Java 1.0) had speed issues, but modern (6, 7, 8, etc.) VMs are blazingly fast at runtime. The same is also true of the garbage collectors - the older ones were simple (comparatively!) and were a lot more likely to do full stop-the-world pauses than newer ones are. Newer GCs like CMS (Concurrent-Mark-and-Sweep) and G1 (Garbage 1st) are a lot more careful about reducing the number of stop-the-world pauses and the minimizing the duration of them. Sure, it’s still possible to produce vast amounts of garbage and cause your FPS to stutter because of the GC doing a stop-the-world pause. That said, Java’s GC is actually more efficient than C/C++ malloc()/free()/new/delete over the long run - i.e., if you create and toss lots of objects in a Java program, the CPU spends less time managing memory than if you create and toss lots of objects/memory regions in C++/C. If you’re being sloppy in C++ with your memory, you’re just as likely (in practice, much more likely) to get into trouble with performance (or worse, crashes) than with Java. The only thing you gain by manual memory management is that you do get to control when the pauses happen, but I find that in practice that advantage is lost in the noise to the horrendous complexity of efficient memory management and the likelihood of very subtle bugs brought by C++. Writing a game in C++ because you can control memory pauses is kind of like jumping off the side of a ship in the middle of a storm at sea because you want to go swimming with your new rubber ducky. Sure, it sounds fun, but it’s gonna be awfully unpleasant in practice and you’re going to get hit with a lot of things you weren’t expecting. (Unless , of course, you’re a hardened C++ expert, or, to keep up the analogy, an extreme sports swimmer. )
Yes. jME’s Vector3f and other math classes have GC-friendly methods that allow you to perform math operations without creating garbage. Instances of things like Vector3f.ZERO are shared too. jME itself is very GC friendly.
Almost always yes. If you’re experiencing stutters and your benchmarks show that they’re caused by GC pauses, find out what’s creating so much garbage. It’s pretty unlikely that a game needs to be creating/throwing away so many objects that the GC starts pausing like that. You can also often eliminate these by setting a few GC parameters (but be careful, don’t do that unless you know what you’re doing) without even touching code. For example, if I recall correctly, @frozenshade was able to eliminate any noticeable pauses by switching the GC to CMS.