Earlier quoted context omitted.
It just means you don't have to special case any particular scenario such as array-of-array, it's no different than array-of-whatever. Also jagged arrays form a complication. But even for the simple case of large non-jagged arrays: In the situation where you needed this perf gain as a developer you would still need to be able to specify the order e.g. row-major or column-major, since the VM won't know your access pat…
This information could be made part of the type of the array. Bases on the type, Java could then compute the proper index.
Inside the JVM: Arrays and how they differ from other objects
131–133 of 133 posts
Re: Inside the JVM: Arrays and how they differ from other objects
#132Earlier quoted context omitted.
This information could be made part of the type of the array. Bases on the type, Java could then compute the proper index.
Yes, but you'd have a whole set of additional data (number of dimensions e.g. 2 and then the order of access for those dimensions). And that would affect the size of every array instance, which is something you really don't want. Or the compiler would need to keep track of it on the type level so that a row-major array can't be passed where a column major is expected etc. In any case it would really make the APIs ove…
API complexity could be handled by a polymorphism mechanism to make it possible to write code that is generic regarding row/column access order.
Re: Inside the JVM: Arrays and how they differ from other objects
#133Earlier quoted context omitted.
I cannot for my life remember the argument order, so I write the manual code and let IntelliJ convert it.
Doesn't autocomplete show the arguments? I usually use Netbeans when I write Java, so no idea if InelliJ is just that bad.