Hi Alan,
On 2019/5/17 下午11:00, Alan Bateman wrote:
The issue isn't clear. The test only runs when on 64-bit systems with
>= 10GB memory. Is the issue related to the -concurrency setting that
you specify to jtreg?
No. Even we set the concurrency=1, the issue may still occur.
os.maxMemory >= 10g
Hi Christoph,
I'm still not entirely sure why this is so, but the introduction of a local
variable in MethodHandles.java seems to make things work for Eclipse. Addition
of a local variable seems to be minimally invasive, so it makes sense to see if
this technique can be applied to other cases.
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8224105
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8224105/webrev.00/
CLDR does not provide entire localized Japanese era names in locales
mentioned in the bug report. The
Hi Vicente,
Looks fine.
Please add a "." at the end of the summary 2nd sentence.
BTW, are you aware of the range checking methods in
java.util.Objects.checkFromToIndex(from, to, length)?
They make it easy avoid to check all the conditions on subranges.
Thanks, Roger
On 05/17/2019 04:14 PM,
Hi Roger,
Thanks again for the reviews, I have modified the CSR summary after your
suggestion [1]. I have also fixed the issue with the webrev link [2],
Thanks,
Vicente
[1] https://bugs.openjdk.java.net/browse/JDK-8223918
[2] http://cr.openjdk.java.net/~vromero/8223723/webrev.01/
On 5/17/19
Hi Roger,
Thanks for the review, my apologies, I made a mistake an applied the
change to the wrong method. I have corrected the patch [1] and the CSR
[2]. I have updated the language used as you suggested,
Thanks,
Vicente
[1] http://cr.openjdk.java.net/~vromero/8223725/webrev.01/
[2] https:/
Hi Roger!
I think that not only the name, but also the arguments compose the
signature.
So, calcLength(oldLength, minGrowth, prefGrowth) is meant to be read as
"given old length and the amount(s) to grow, calculate the new length".
And since this method is placed into ArraysSupport, it should b
Hi Vicente,
Method j.l.c.MethodTypeDesc.dropParameterTypes throws an exception in a
case
I would change the CSR summary to "Method
j.l.c.MethodTypeDesc.dropParameterTypes should specify
IndexOutOfBoundsException"
to focus on the new behavior.
The link to the webrev looks ok, but has the fi
Hi Vicente,
What's the difference in the IAE exceptions describing IAE's as
being "incorrect formats' vs 'is invalid' or 'not valid'?
Each requires a spec for valid and invalid strings or is undefined.
Can the new IAE use the same language as is used for the ofDescriptor
method?
Avoiding any
Hi Ivan,
The new calcLength method name is too generic, it does not say enough
about its function.
There is no indication that the purpose is to resize an array.
As for size vs length, sometime size is more evocative of the function
being performed
than 'length' and is more natural. In most c
Please review simple fix for [1] at [2] plus the CSR at [3]. This fix is
simply documenting all the missing cases in which method
java.lang.constant.MethodTypeDesc::of can throw exceptions. A test has
been added to cover the missing cases.
Thanks,
Vicente
[1] https://bugs.openjdk.java.net/bro
Hi Leo,
Overall looks good. One comment to the test case is that I would avoid
using the name "JavaTimeSupplementary" or "JTS", as they are the
implementation detail. Actually, a DateTimeFormatException may not
necessarily be caused by a missing JavaTimeSupplementary resource in the
runtime.
Hi Peter,
I agree that the size based optimization is problematic.
What I would most like to preserve is the performance advantages of using hash
coding, which apparently was a goal of the original design:
"implementations of the various Collections Framework interfaces are free to
take advant
ping
On 5/14/19 6:37 PM, Vicente Romero wrote:
Please review fix [1] for [2] and the corresponding CSR at [3]. The
fix is just adding a missing @throws at method
j.l.c.MethodHandleDesc::of. It is a one liner fix,
Thanks,
Vicente
[1] http://cr.openjdk.java.net/~vromero/8223725/webrev.00/
[2]
Hi,
AsynchronousChannelProvider.java: line 144: needs a space in
"anunspecified"
That sentence isn't very well worded, but is outside the scope of
this change to add the tag.
Otherwise, looks fine.
Roger
On 05/17/2019 06:49 AM, Alan Bateman wrote:
On 17/05/2019 10:49, Deepak Kejriwal
On 17/05/2019 15:25, Jie Fu wrote:
Hi all,
JBS: https://bugs.openjdk.java.net/browse/JDK-8224112
Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/
java/util/Base64/TestEncodingDecodingLength.java may fail due to
insufficient memory when our test machine is busy.
It might be bett
Okay.
Thank you Aleksey.
On 2019年05月17日 22:30, Aleksey Shipilev wrote:
On 5/17/19 4:25 PM, Jie Fu wrote:
JBS:https://bugs.openjdk.java.net/browse/JDK-8224112
Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/
java/util/Base64/TestEncodingDecodingLength.java may fail due to insuf
ping
On 5/16/19 6:52 PM, Vicente Romero wrote:
Hi,
I still need a reviewer for this simple patch and CSR,
TIA,
Vicente
On 5/14/19 4:53 PM, Vicente Romero wrote:
Please review fix for [1] at [2]. The implementation of method
java.lang.constant.MethodTypeDesc::dropParameterTypes was throwing a
On 5/17/19 4:25 PM, Jie Fu wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8224112
> Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/
>
> java/util/Base64/TestEncodingDecodingLength.java may fail due to insufficient
> memory when our test
> machine is busy.
> It might be bet
Hi all,
JBS:https://bugs.openjdk.java.net/browse/JDK-8224112
Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/
java/util/Base64/TestEncodingDecodingLength.java may fail due to
insufficient memory when our test machine is busy.
It might be better to skip it when the available mem
On 17/05/2019 10:49, Deepak Kejriwal wrote:
Hi all,
Please review the fix for following issues:-
https://bugs.openjdk.java.net/browse/JDK-8214565
https://bugs.openjdk.java.net/browse/JDK-8214563
Below is the webrev for above issues:
http://cr.openjdk.java.net/~dkejriwal/8
Hi all,
Please review the fix for following issues:-
https://bugs.openjdk.java.net/browse/JDK-8214565
https://bugs.openjdk.java.net/browse/JDK-8214563
Below is the webrev for above issues:
http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.00/
Regards,
Deepak
Thank you Lance. I pushed it with your suggestion worked in.
From: Lance Andersen
Sent: Donnerstag, 16. Mai 2019 15:44
To: Langer, Christoph
Cc: core-libs-dev ; nio-dev
; Alan Bateman
Subject: Re: RFR: 876: (zipfs) Refactoring and cleanups to prepare for
JDK-8213031
Hi Christoph,
Thank
23 matches
Mail list logo
