Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

[Chris Hegarty]

Anthony,

Many of the Collection types throw OOME if requested to grow
greater than ~2GB. Likewise some operations of String and
StringBuilder. Though this behavior is not strictly part of
the  current specification, I suspect that it is the defacto
standard ( since the implementation has always behaved this
way ).

The java.lang.module.ModuleReader::read method is another
method that specifies the behavior if the returned type is
not capable of supporting very large amounts of data.

I agree that the use of OOME here is somewhat overloaded, but
it appears that we already well down this path, best to make
it clear and consistent in the spec.

-Chris.

On 12/03/17 14:24, Anthony Vanelverdinghe wrote:
> Files::readAllBytes is specified to throw an OutOfMemoryError "if an
> array of the required size cannot be allocated, for example the file is
> larger that 2G". Now in Java 9, InputStream::readAllBytes does the same.
>
> However, this overloads the meaning of OutOfMemoryError: either "the JVM
> is out of memory" or "the resultant array would require long-based
> indices".
>
> In my opinion, this overloading is problematic, because:
> - OutOfMemoryError has very clear semantics, and I don't see the link
> between OOME and the fact that a resultant byte[] would need to be >2G.
> If I have 5G of free heap space, and try to read a 3G file, I'd expect
> something like an UnsupportedOperationException, but definitely not an
> OutOfMemoryError.
> - the former meaning is an actual Error, whereas the latter is an
> Exception from which the application can recover.
> - developers might be tempted to catch the OOME and retry to read the
> file/input stream in chunks, no matter the cause of the OOME.
>
> What was the rationale for using OutOfMemory here? And would it still be
> possible to change this before Rampdown Phase 2?
>
> Kind regards,
> Anthony
>
>