http://cr.openjdk.java.net/~kvn/8185139/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8185139
For Graal to work we have to give Graal module all permissions which is
specified in default policy [1].
Unfortunately this cause problem for Graal running tests which overwrite
default policy.
On 6/19/2019 6:26 PM, Alexander Matveev wrote:
Hi Andy,
1) Looks like you forgot to update HelpResources_ja.properties and
HelpResources_zh_CN.properties.
Yes I need to re-run my script to update these.
2)
Hi Andy,
1) Looks like you forgot to update HelpResources_ja.properties and
HelpResources_zh_CN.properties.
2)
http://cr.openjdk.java.net/~herrick/8225428/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties.frames.html
Line 84: Error: creating
On 6/19/2019 2:08 PM, Alexey Semenyuk wrote:
http://cr.openjdk.java.net/~herrick/8225428/webrev.01/test/jdk/tools/jpackage/JPackageMissingArgumentsTest.java.sdiff.html:
---
private static final String [] RESULT_7 = {"--module-path",
"--runtime-image", "app-image"};
---
Should it be
http://cr.openjdk.java.net/~herrick/8225428/webrev.01/test/jdk/tools/jpackage/JPackageMissingArgumentsTest.java.sdiff.html:
---
private static final String [] RESULT_7 = {"--module-path",
"--runtime-image", "app-image"};
---
Should it be "--app-image"?
- Alexey
On 6/19/2019 1:34 PM, Andy
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8225428: CLI change to remove "mode", rename to "package", and build
only one target
[1] https://bugs.openjdk.java.net/browse/JDK-8225428
[2]
Hi Sean,
+1
> On Jun 19, 2019, at 12:29 PM, Seán Coffey wrote:
>
> Reports that this test is failing intermittently over past few months. It's a
> rare occurrence but I'd like to take steps to correct it.
>
> I've removed the dependence on randomness in the bug.
> I've fixed up the zip file
Reports that this test is failing intermittently over past few months.
It's a rare occurrence but I'd like to take steps to correct it.
I've removed the dependence on randomness in the bug.
I've fixed up the zip file creation logic to produce a real zip file
I've renamed the file to a unique
+1
Thanks,
Brian
> On Jun 19, 2019, at 4:49 AM, Claes Redestad wrote:
>
> On 2019-06-19 07:28, Tagir Valeev wrote:
>> Hello, Brian!
>> Thank you for review. Here's updated version:
>> http://cr.openjdk.java.net/~tvaleev/webrev/8226286/r2/
>>
Hi,
On 6/19/19 2:12 PM, Сергей Цыпанов wrote:
> in JDK code base we have many places (mainly in j.u.Arrays) where we
> convert array to String using verbose constructions with
> StringBuilder.
>
> As far as we have got StringJoiner for a long time we can use it
> making the code more simple.
>
Hello,
in JDK code base we have many places (mainly in j.u.Arrays) where we convert
array to String using verbose constructions with StringBuilder.
As far as we have got StringJoiner for a long time we can use it making the
code more simple.
Also toString() of AtomicIntegerArray,
On 19/06/2019 11:07, Andrew Dinn wrote:
:
Do I still need to wait for confirmation for the CSR from Joe Darcy
before pushing to the jdk13 repo? (He already knows about the CSR).
Yes, anything that has a CSR needs to wait until it is approved.
-Alan
Hi Tagir,
On 2019-06-19 07:28, Tagir Valeev wrote:
Hello, Brian!
Thank you for review. Here's updated version:
http://cr.openjdk.java.net/~tvaleev/webrev/8226286/r2/
this looks like a good cleanup!
It's partly my fault that these format methods ended up a bit messy. I
exposed some of the
Hi Abraham
Wouldn’t it have been possible to use Map::isEmpty? Ideally just returning at
the very beginning of your method if `data` is an empty Map. That way you’d
still be able to use computeIfPresent, and use emptyMap() as well.
Kind regards,
Anthony
On 19/06/2019 11:03, Alan Bateman wrote:
> I added myself as Reviewer to the the CSR so you can finalize. The
> webrev looks good.
Thanks, Alan. I have finalized the CSR.
Do I still need to wait for confirmation for the CSR from Joe Darcy
before pushing to the jdk13 repo? (He already knows about
On 19/06/2019 10:21, Andrew Dinn wrote:
:
I raised this CSR:
CSR:https://bugs.openjdk.java.net/browse/JDK-8226385
and tagged it for jdk13.
Also, I labelled it SE -- but is it, perhaps, meant to be JDK?
(apologies, I am still a noob to this process).
Yes, it's "SE" as it's normative
Hi Alan,
On 18/06/2019 18:08, Alan Bateman wrote:
> This looks good. Will you create a CSR for this? I think it can be fixed
> in jdk/jdk13 as it follows JDK-8221397 and JDK-8221696 (and there is no
> risk as it's javadoc only).
I raised this CSR:
CSR:
Hi Stuart, Roger,
First of all, thank you for such a detailed response, this really shows the big
picture. I guess no implementation will be perfect, there will always be some
wrinkles that we need to accept, and the most suitable implementation will be
the one with the fewest or least
Hi Alan,
I've updated the patch by adding the review info.
http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/
Is it OK to be pushed?
Thanks a lot.
Best regards,
Jie
On 2019/6/19 下午2:04, Ioi Lam wrote:
Sure, you can add me as reviewer.
Thanks
On Jun 18, 2019, at 10:54 PM, Jie Fu wrote:
19 matches
Mail list logo
