[3ple_alpha]

No they're not. If you're using an array with length over a billion in Java, your code stinks already before you start using binary search.

[coldtea]

That's not only wrong in itself, but totally orthogonal.

A binary search implementation should still work, regardless of the array length, or have the limitation documented.

And of course an array "with length over a billion" can be totally valid, depending on the use case, your tradeoffs, available memory, etc. It could even be the optimal data structure for some use cases.

[poincaredisk]

I'm not a Java programmer, but how would you load of a 1GB file into memory? I assume read returns some kind of an array.

Also big arrays being (supposedly) a coffeee smell doesn't mean that code handling them improperly is not buggy.

[aardvark179]

If you really needed it in memory you’d use one of the file APIs that will map it and present a direct byte buffer view over that memory.

Those APIs use long as their offset unlike the 32 ints used by arrays, and would avoid having to copy the data into some other object.

There has been some discussion over the years about how arrays could be changed in the JVM to support longer lengths, but doing so without breaking existing code and while providing truly useful functionality without providing obvious footguns isn’t as easy as you might think.

[angus_gh]

Java's arrays use a signed 32-bit int as their length, so the longest they can be is about 2 billion elements.

If your code has arrays over a billion elements, then it will fall over the moment someone inputs slightly larger data

[danvonk]

Relational databases often require searching and sorting gigabytes of data to answer queries (sometimes larger than RAM if e.g. k-way merge sort is used) so it doesn't seem that far-fetched, especially given that there are database systems written in Java.

[tehjoker]

not doing much scientific programming eh?