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

[Peter Levart]

On 03/13/2017 12:33 PM, Chris Hegarty wrote:
> 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.

What about (talking about JDK10 of course) creating OutOfMemoryError 
subclasses to cover cases that don't pertain to Java heap memory?

Regards, Peter

>
> -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
>>
>>