No, the JVM does some very smart optimisations on natively ordered direct buffers.
Simple loops and slightly more complex loops have not suffered from bound-checks for ages now. Make a benchmark in C, and you’ll get exactly the same performance as in Java, as long as SIMD is not enabled.
I’ve just tried it with JBullet. It supports both cache friendly and unfriendly accesses, here are results:
I’ve used BasicDemo which has stack of 125 boxes. To test yourself, add this code after creating DiscreteDynamicsWorld:
dynamicsWorld.getSolverInfo().solverMode &= ~SolverMode.SOLVER_CACHE_FRIENDLY;
Also remember to press ‘d’ button to disable deactivation when testing.
There is a for each statement, the syntax looks like
int b[]=new int[1024*1024];
for(int c : b)
{
c++;
}
but it’s no use for altering primitive types as in the example because of the lack of pointers to primitives. I’d have assumed everyone here knew about this, but I’m slightly surprised you wrote what you did in that case.
Remember DzzD writes for Java 1.1 IIRC.
Everybody else knew 
hehe, true, I am not really new-features&shortcut friend… basically I will never learn the full Java API spec as well as in all other languages, I am not a Java coder, just a coder!
[quote]…but it’s no use for altering primitive types as in the example because of the lack of pointers to primitives…
[/quote]
I am afraid that new bachelor will knew all high levels features without never learn about base. people say it is good for conception etc… but I think that the main reason that new software requiere so much memory and cpu even if they could have been made faster in “smaller configuration” computer. not sure but the sentence above make me thing about that a little… can you explain what you mean exactly, how to you think Java modify an int, what difference do you see between c [ x ] and *c= ?
[quote]Simple loops and slightly more complex loops have not suffered from bound-checks for ages now. Make a benchmark in C, and you’ll get exactly the same performance as in Java, as long as SIMD is not enabled.
[/quote]
nop, Java bounds checks are bottleneck, perform any smart benchmark and the result will show that random Java array acces is at least two time (up to 5 times for random acces) slower than a direct memory acces in another language as C or even in Basic… I will try to take some times and make benchmark between ASM/C/C++/Java on PC and I can already give you results :
1 - ASM
2 - C/C++
3 - Java
You showed a foreach loop: that is linear access, not random access.
You should read my post in that context. 
ok , I have to stop being “demagogic” sometimes ;), anyway I will try even if sequential acces are quit fast in Java too.
maybe I haven’t explain enought when I post above sample, sry , this was an idea only interresting for primitive, I mean this way the JIT know you wont go away bounds as you have no acces to the array index and then it will be able to perform direct memory access without bounds check. it could have been
forEach (int c in b[100-300])
c++
with forEach able to throw a ForEachBoundsCheckException and ForEachTypeException, but only check bounds once.
Fair enough, but that doesn’t quite justify proposing new syntax that has already been there for some time… anyway, nothing against you for not realising.
Well, put it this way.
int[] c = new int[8];
for (int i : c) i = 10; // won't alter the value in the array.
for (int i : c) System.out.println("i = " + i); // all default to zero
The only way the value of the primitive in the array will change, is if you explicitly assign a value to the slot in the array, which effectively nullifies the usefulness of the for each loop in many circumstances.
It also has more far-reaching effects. You essentially can’t easily pass a reference to a primitive value you want to change and it’s a PITA IMHO.
That could be useful.
Again, foreach (linear array access) already has 1 bound-check, so there is nothing to gain there.