Please review this patch to remove
java/util/Map/InPlaceOpsCollisions.java from ProblemList.txt,
related bug JDK-8203387 (JDK-8203425) has been fixed.
Thanks,
Amy
--- old/test/jdk/ProblemList.txt 2018-06-13 17:23:33.0 +0800
+++ new/test/jdk/ProblemList.txt 2018-06-13 17:23:32.
May I have a second review please.
Thanks, Thomas
On Mon, Jun 11, 2018, 15:13 Thomas Stüfe wrote:
> Hi,
>
> may I please have reviews for this small cleanup.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204663
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8204663-clean-up-aft
Hi Joe,
The CSR text is still in draft and got out of sync with the open review
and comments.
The updated apiNote clarifies that changes made through the
System.*property* methods
may not affect the value cached during initialization.
The implementation changes affect a very short list of p
Hi Rachna,
How much of the updates are done mechanically between the CLDR data and
the .xml files?
Manually reviewing that many files is likely to be error prone.
Thanks, Roger
On 6/13/2018 1:33 AM, Rachna Goel wrote:
Hi,
Kindly review fix for JDK-8202537. Fix is to upgrade Unicode
consor
Hi Roger,
No update is done mechanically between CLDR data and .xml files.
CLDR's data in .xml files are generated into resourcebundles at build
time by cldrconverter tool.
Already existing regression test
"test/jdk/sun/text/resources/LocaleDataTest.java" verify that same data
is retrieved
+1
Paul.
> On Jun 13, 2018, at 2:56 AM, Thomas Stüfe wrote:
>
> May I have a second review please.
>
> Thanks, Thomas
>
> On Mon, Jun 11, 2018, 15:13 Thomas Stüfe wrote:
>
>> Hi,
>>
>> may I please have reviews for this small cleanup.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-820
+1
Paul.
> On Jun 13, 2018, at 2:31 AM, Amy Lu wrote:
>
> Please review this patch to remove java/util/Map/InPlaceOpsCollisions.java
> from ProblemList.txt,
> related bug JDK-8203387 (JDK-8203425) has been fixed.
>
> Thanks,
> Amy
>
> --- old/test/jdk/ProblemList.txt2018-06-13 17:23:33.00
Hi,
Please review http://cr.openjdk.java.net/~sdama/8204967/webrev.00/
for https://bugs.openjdk.java.net/browse/JDK-8204967
Regards,
Srinivas
Hi Rachna,
A couple of comments:
- NumberingSystemsParseHandler.java
Since the code substitutes latin digits for supplementary digits, it can
skip line 68-79.
- A test should be written for the above substitution.
Naoto
On 6/12/18 10:33 PM, Rachna Goel wrote:
Hi,
Kindly review fix for JD
Does -Wimplicit-fallthrough=3 work for gnu c and clang?
unpack.cpp redundant comment
3713 // else fall through:
+1
— Jim
> On Jun 13, 2018, at 1:57 PM, Srinivas Dama wrote:
>
> Hi,
>
> Please review http://cr.openjdk.java.net/~sdama/8204967/webrev.00/
> for https://bugs.openjdk.java.
Thank you Paul!
On Wed, Jun 13, 2018 at 6:19 PM, Paul Sandoz wrote:
> +1
> Paul.
>
>> On Jun 13, 2018, at 2:56 AM, Thomas Stüfe wrote:
>>
>> May I have a second review please.
>>
>> Thanks, Thomas
>>
>> On Mon, Jun 11, 2018, 15:13 Thomas Stüfe wrote:
>>
>>> Hi,
>>>
>>> may I please have reviews
CSR: https://bugs.openjdk.java.net/browse/JDK-8204959
webrev: http://cr.openjdk.java.net/~jlaskey/8204172/webrev/index.html
Thank you,
— Jim
Hello,
Oracle will reduce the number of languages that it maintains
translations of JDK resources for. The current translations will remain
in the source for now, but we need a way to filter out a set of
translations at build time so that we only include the ones we support.
This patch adds s
Thanks Roger!
I pushed the changeset after s/unmappble/unmappable, it found three of
them :-)
Best,
Joe
On 6/12/18, 10:37 AM, Roger Riggs wrote:
Hi Joe,
Looks good to me.
Typo: StringCoding.java:1026 "unmappble" (no new webrev needed)
Regards, Roger
On 6/12/2018 12:52 PM, Joe Wang wrot
Hi Erik,
The modifications to the logging test look good to me.
Caveat: I don't speak chinese nor japanese ;-)
cheers,
-- daniel
On 13/06/18 20:47, Erik Joelsson wrote:
Hello,
Oracle will reduce the number of languages that it maintains
translations of JDK resources for. The current transla
Hi Jim,
Looks good to me.
best regards,
-- daniel
On 13/06/18 20:36, Jim Laskey wrote:
CSR: https://bugs.openjdk.java.net/browse/JDK-8204959
webrev: http://cr.openjdk.java.net/~jlaskey/8204172/webrev/index.html
Thank you,
— Jim
Hi everybody,
While looking into the current Reader Spec and the failing methods I found that
the ready() method actually does behave wrong and I fixed this.
For the case of mark() I would like to revise the specification to align with
the Reader’s default behavior that states for the mark meth
Hi Patrick,
Not part of your change, but I noticed that at line 66 of Reader.java there is
an extra parenthesis after ready().
In the test, the bug ID at line 39 could simply be appended to line 38.
Otherwise looks good although I suppose given the specification update you’ll
need an approved
Hi Patrick,
Yes, looks good to me too.
For the CSR, the easiest path to clarify the spec is to withdraw the
CSR, update the spec,
and add a note on the revised behavior.
Then finalize the CSR again. That's enough to get it reviewed and approved.
(Using a new CSR would just spread the behavi
Thanks for the explanation, Joe. I see the subtle difference on these
terminologies.
I'm okay with this patch.
I like the other option better to remove @apiNote since the spec states
that the duplicates may not be removed.
Mandy
On 6/12/18 5:49 PM, Joseph D. Darcy wrote:
On 6/11/2018 10:3
Hi Roger,
Thanks for pointing this out: simpler and cleaner.
Brian
On Jun 13, 2018, at 2:06 PM, Roger Riggs wrote:
> For the CSR, the easiest path to clarify the spec is to withdraw the CSR,
> update the spec,
> and add a note on the revised behavior.
>
> Then finalize the CSR again. That's
I really like how BiCollector can be private, so all we'd have to expose
is toBoth(), and the arguments of toBoth() are just ordinary
collectors. So no new types or abstractions; just a multiplexing.
The use of Map.Entry as a pair surrogate is unfortunate -- its
definitely not an Entry -- tho
Hello,
Please review the small patch below to address
JDK-8205003: Replace selected link tags with linkplain in
java.lang.Class
Thanks,
-Joe
diff -r 0742a087710e src/java.base/share/classes/java/lang/Class.java
--- a/src/java.base/share/classes/java/lang/Class.java Wed Jun 13
13:12:
Hi Joe,
+1
Brian
On Jun 13, 2018, at 5:51 PM, joe darcy wrote:
> Please review the small patch below to address
>
> JDK-8205003: Replace selected link tags with linkplain in java.lang.Class
+1
Mandy
On 6/13/18 5:51 PM, joe darcy wrote:
Hello,
Please review the small patch below to address
JDK-8205003: Replace selected link tags with linkplain in
java.lang.Class
Thanks,
-Joe
diff -r 0742a087710e src/java.base/share/classes/java/lang/Class.java
--- a/src/java.base/share/
+1
--
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPhone
> On Jun 13, 2018, at 8:51 PM, joe darcy wrote:
>
> Hello,
>
> Please review the small patch below to addres
Thanks a lot for the explanation. Everything looks OK to me now.
--Max
> On Jun 13, 2018, at 10:10 PM, Roger Riggs wrote:
>
> Hi Joe,
>
> The CSR text is still in draft and got out of sync with the open review and
> comments.
>
> The updated apiNote clarifies that changes made through the Sy
Hi Thomas,
I've added testcase along with fix. Please find webrev at
http://cr.openjdk.java.net/~aleonard/8202329/webrev.01/
Thanks,
Bhaktavatsal Reddy
-"core-libs-dev" wrote: -
To: "Thomas Stüfe"
From: "Bhaktavatsal R Maram"
Sent by: "core-libs-dev"
Date: 06/01/2018 01:34PM
Cc:
On 13/06/2018 4:08 PM, joe darcy wrote:
Hi David,
On 5/24/2018 10:52 PM, David Holmes wrote:
Here are the further minor updates so far in response to all the
review comments.
Incremental corelibs webrev:
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v3-incr/
Full core
Hello!
In my StreamEx library I created a "pairing" collector which does similar
job, but allows user to decide how to combine the results of two
collectors. This adds more flexibility. The signature is like this:
public static Collector pairing(
Collector c1,
Collector c2,
BiFunctio
Hi Tagir,
Great! I've been thinking about the same trick - just add another
function and you don't have to hard code the decision about the choice
of imperfect tuple type. But are we just talking of aestetics here? In
the absence of value types, every choice is imperfect. Ok, sometimes you
ma
31 matches
Mail list logo