Thank you Pavel and Roger for reviewing!
I apologize for reiterating this.
After off-line discussion with Stuart Marks, the fix was modified once
again.
The modifications were mostly stylistic: The used terminology now
reflects that we work with arrays (thus 'length', not 'size' or 'capacity').
Functionally, the fix remains exactly the same.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/02/webrev/
With kind regards,
Ivan
On 5/14/19 7:50 AM, Roger Riggs wrote:
Hi Ivan,
The updated patch looks fine.
Strictly speaking, the change to Files.readAllBytes is not indicated
by the bug report
so please update or comment on the bug report to mention that change.
Thanks, Roger
On 05/13/2019 10:44 AM, Pavel Rappo wrote:
Thanks for updating your patch. The updated code seems fine.
-Pavel
On 11 May 2019, at 05:01, Ivan Gerasimov<ivan.gerasi...@oracle.com> wrote:
Hello!
Please help review the updated fix.
This new webrev includes changes suggested by Pavel, Peter and Roger.
BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
Please note that the behavior of j.n.f.Files.readAllBytes() has changed
slightly, so now it *may* be possible to read a file larger than
(Integer.MAX_VALUE - 8), if VM is able to allocate that large array.
With kind regards,
Ivan
On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
Hello!
Jdk has several places with similar logic: an array needs to be reallocated
(by at least some defined amount), taking into account the maximum allowed size
of arrays.
There's clearly an opportunity for refactoring, so it is proposed to introduce
a dedicated utility method for calculating the best new size of an array.
Would you please help review this enhancement?
BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
Mach5 job ran fine.
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
--
With kind regards,
Ivan Gerasimov
