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()
Thank you Pavel for the investigation!
I've seen some of these places, and decided not to touch them with this
refactoring for various reasons:
java.lang.AbstractStringBuilder - the case has additional complication
due to interference of coder. It may make sense to refactor it later
within
Thank you Roger so much for valuable feedback!
On 5/10/19 7:41 AM, Roger Riggs wrote:
Hi Ivan,
Thanks for refactoring[1] this sensitive function.
ArraySupport.java:
Line 33: Please add a period at the end of the sentence.
I would have added a new sentence instead of mixing functions.
Don
Hi Peter!
Thank you for reviewing!
On 5/10/19 1:52 AM, Peter Levart wrote:
Hi Ivan,
On 5/9/19 8:07 PM, Ivan Gerasimov wrote:
3. I know that this is not new and has been copied from the old
code. However,
I'm not sure I understand the meaning of "unless necessary" here:
/**
* The
On 5/10/2019 3:39 PM, Roger Riggs wrote:
Hi Andy,
Thanks for logging the issues.
CLIHelp:
- 58, 65, 72, 80: Indentation of pLaunchOptions does not line up.
I don't see what you mean here. Looks lined up to me
The lines with pLaunchOptions have tabs instead of spaces.
jcheck has some com
Hi Andy,
Thanks for logging the issues.
CLIHelp:
- 58, 65, 72, 80: Indentation of pLaunchOptions does not line up.
I don't see what you mean here. Looks lined up to me
The lines with pLaunchOptions have tabs instead of spaces.
jcheck has some complaints about tabs and trailing spaces.
IO
> On 10 May 2019, at 15:41, Roger Riggs wrote:
>
> 98: I think you've dropped the normal doubling of the buffer size that comes
> from old line 115.
> The buffer should be doubling in size, but at least minsize.
I thought about it too initially. But then I reproduced that function. It seemed
Hi Ivan,
Thanks for refactoring[1] this sensitive function.
ArraySupport.java:
Line 33: Please add a period at the end of the sentence.
I would have added a new sentence instead of mixing functions.
Line 583: Making MAX_ARRAY_SIZE public would make it accessible within
java.base module.
L
Ivan,
There seem to be more places that use a somewhat similar pattern. I was
wondering if you have seen them and decided not to include them in your patch
for some reason (e.g. they really are quite different)?
Here are some of them:
java.io.BufferedInputStream
java.io.InputStream
j
Hi Deepak, here are my comments.
- FormatData_es_PE.java: Modify the copyright year to 2019.
- Changes in "LocaleData" may be placed at the bottom of the file,
explicitly indicating it is changed with 8206879. Please follow the
similar changes' format.
- Bug8206879.java does not have proper
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8206879
The proposed fix is located at:
http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/
Summary
In case of JRE locale provider, for Peru comma (,) is used as decimal marker
which i
> On 10 May 2019, at 09:52, Peter Levart wrote:
>
>
>
> Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME?
>
> If this utility method is meant for re-sizing arrays only (currently it is
> only used for that), then perhaps the method could throw OOME explicitly in
> this
Hi Daniel,
I fully agree, @SuppressWarnings should be avoided wherever possible.
So, thanks for coming up with this alternative suggestion. It works and so I
updated my webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.1/
Any reviews for the other 3 files?
Thanks
Christoph
> -
Hi Ivan,
On 5/9/19 8:07 PM, Ivan Gerasimov wrote:
3. I know that this is not new and has been copied from the old code.
However,
I'm not sure I understand the meaning of "unless necessary" here:
/**
* The maximum size of array to allocate (unless necessary).
It means that if the min
14 matches
Mail list logo
