So would a 2D array likely have been better, even though for say [y][x] (as well as the order being somewhat confusing) creates height+1 separate arrays (and then likely requires a temp and memcpy if it ever interacts with native code, e.g. to display it)? In 3D for a block game like minecraft that seems even worse.

If not then I guess that is actually a good reason to suggest building stuff like Minecraft in C.

regardless of language you really should use a single dimensional array and access it linearly to avoid cache misses most of the time (the cost of the extra arithmetics is far smaller than the cost of cache misses for large arrays). in C and C++ 2D array will be identical to a 1D array behind the scenes though and you only have to worry about iterating over it effectivly ([x][y] vs [y][x] depending on which way you're looping for example) making those languages a bit easier to work with for such cases.

in Java a 2D array will not be a single block of memory and thus requires 2 dereferences per access and is far more likely to cause cache misses, since you want to iterate over the datablock linearly anyway regardless of language you should use a 1D array as often as possible (As its most cache friendly) its best to figure out where to start and stop before the loop (then Java can usually do the bounds check just once for the whole loop making it a non issue).

It can be quite a bit easier to write such things well using a language with low level features though. (I wouldn't use C myself as C++ provides more or less the same low level features + a whole bunch of useful high level features anyway)

I'm pretty sure the JIT compiler can infer those kind of things. Once I saw a guy who showed the assembly of what the JIT compiler did to an iteration over an ArrayList, it simplified it to an iteration over a primitive array. I remind you that ArrayList is operated by accessor/mutator methods only and that it uses Iterator objects for traversing the array, so it ended up throwing all that indirection away. Bytecode tells you nothing about what will eventually get executed, the only way is to look through what the JIT compiler does to it

It can do other kinds of "magic" too, like inlining virtual method calls, thus no pointer hopping for calling methods of abstract classes or interfaces.

Some VM things are pretty neat, I'd be more worried about memory usage (which is a very documented issue) rather than performance. You can lookup Oracle's articles on object construction in HotSpot VM, which will tell you the approximate costs of doing things in Java instead of native code. IIRC, i think that avg memory costs for allocating Java objects were 30% higher on a 32 bit VM, or even more when 64 bit pointers are used.

The actual allocation of objects is fast (some people even say that its faster than doing a malloc() call) but its the additional overhead of metadata about the objects that creates memory (over)usage issues. Moreover, the GC doesn't likes to work on memory constrained environments, so the memory requirements of your program end up being even bigger than the actual memory usage of the program.

Its just a big pile of tradeoffs really :D

So, I should use Java for game development?

Yes. Go and code something.