8162520: (fs) FileStore should support file stores with > Long.MAX_VALUE capacity

[Brian Burkhalter]

> On Oct 1, 2019, at 7:59 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 01/10/2019 15:36, Brian Burkhalter wrote:
>> Here is a stab [1] at fixing [2] using the above approach.
>> 
> If we go with this approach then the new methods will need default implementations that throw UOE (and UOE will need to be specified too). This is because there are several FileSystemProvider implementations in the wild. It's good to get the jrt and zip providers updated of course.

I actually first wrote a version with default implementations instead of abstract methods but changed my mind. I’ll revert it and clean it up.

> I see you've changed the spec for the existing methods to return a negative value when the size is great than Long.MAX_VALUE. The alternative is to return MAX_VALUE, I'm not sure which is better without studying some of the existing usages of the API.

My thinking was that MAX_VALUE could be a legitimate size, albeit unlikely being an odd number.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191001/95808932/attachment-0001.html>