Re: RFR: 8204967: Resolve disabled warnings for libunpack

Hi Magnus/Jim, Thank you for the comments. Here is the latest webrev with suggested changes: webrev: http://cr.openjdk.java.net/~sdama/8204967/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8204967 Jim, gnu c supports -Wimplicit-fallthrough=3. clang takes -Wimplicit-fallthrough without

RFR(s): 8060192: Add default method Collection.toArray(generator)

Hi all, I wanted to restart review of the changeset for bug JDK-8060192 [1]. The latest webrev is here: [2]. The previous review was from December 2017: [3]. The only difference between the current changeset and the previous one is the removal of the overriding implementations (see

Re: Japanese New Era supporting does not accept Heisei 32

Hi, Yes, that's the expected behavior with the implementation assuming "Heisei 32" is non-existent. I see some discussion as you mentioned, whether to allow to use Heisei for a while, for transitional purpose, but at the moment there's very little & no official information available. We may

Japanese New Era supporting does not accept Heisei 32

I'm trying to use the Japanese new era supporting and have found that it does not accept Heisei 32. There are many document that include Heisei 32 or later at present. For example, the expiration date of my driver license is Heisei 32 March. JDK10 can accept Heisei 32. I think the change of the

RFR 8170159 Improve the performance of BitSet traversal

Hi, Please review this enhancement to improve the performance of BitSet traversal when using a stream. http://cr.openjdk.java.net/~psandoz/jdk/JDK-8170159-bitset-traverse/webrev/ The associated issue started out

Re: RFR: JDK-8204973: Add build support for filtering translations

On 2018-06-14 12:49, Magnus Ihse Bursie wrote: Would it have been to problematic to reverse the the logic, i.e. having a "include translation" rather than an exclude? Feels more brittle; if someone adds a translation the exclude list needs to be updated. Also, a include mechanism could

Re: RFR: JDK-8204973: Add build support for filtering translations

Looks good to me. Naoto On 6/14/18 11:52 AM, Erik Joelsson wrote: Hello, Here is a new version of the patch: http://cr.openjdk.java.net/~erikj/8204973/webrev.02/ Changes from last time: * Made the regexp for finding locales more correct. It still does not try to match 3 letter language

Re: RFR: JDK-8204973: Add build support for filtering translations

Would it have been to problematic to reverse the the logic, i.e. having a "include translation" rather than an exclude? Feels more brittle; if someone adds a translation the exclude list needs to be updated. Also, a include mechanism could possibly be used, much simpler, by someone who only

Re: RFR: [11] 8202537: CLDR 33

Looks good to me. Naoto On 6/14/18 7:01 AM, Rachna Goel wrote: Hi Naoto, Thanks a lot for the review. I have made suggested changes, Kindly have a look at : http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.07/ - Updated NumberingSystemsParseHandler.java - Updated LocaleData.cldr for

Re: RFR: JDK-8204973: Add build support for filtering translations

Hello, Here is a new version of the patch: http://cr.openjdk.java.net/~erikj/8204973/webrev.02/ Changes from last time: * Made the regexp for finding locales more correct. It still does not try to match 3 letter language strings because doing so triggers a large amount of false positives in

RFR 8202922 Method reference identity is broken by serialization

Hi, Please review an update to the specifications of LambdaMetafactory and SerializedLambda to clarify that the identity of function objects is unpredictable. A similar (informational) clarification was made to the language specification and similar wording is used. Amusingly a quirk of (or

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

I'm not an expert in the area, but the patch looks good to me, Vicente On 05/31/2018 08:39 PM, Liam Miller-Cushon wrote: Hi, Are there any concerns with the patch that I can address? I was hoping to get this in to JDK 11. I confirmed that it still builds and passes all tests at head.

Re: BiCollector

On 14/06/18 08:46, Peter Levart wrote: But there's no way to use partitioningBy to simulate all the variants of toBoth... I wasn't suggesting that - more the other way around, as you illustrated Maurizio

Re: BiCollector

Well, I don't see the need to pack the two results into a Map.Entry (or any similar) container as a drawback. From an "integrity of the JDK APIs" perspective, it is unquestionably a drawback.  These items are not a Key and an associated Value in a Map; it's merely pretending that

Re: BiCollector

Hi Peter, I am not concerned about performance of Map.Entry. I find its use awkward for similar reasons as Brian outlined. Tagir’s approach using a finisher nicely side steps this at the expense of another function. If in the future we have an officially blessed pair/2-tuple class we can

Re: RFR: [11] 8202537: CLDR 33

Hi Naoto, Thanks a lot for the review. I have made suggested changes, Kindly have a look at : http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.07/ - Updated NumberingSystemsParseHandler.java - Updated LocaleData.cldr for new test case. Thanks, Rachna On 6/13/18 10:33 PM,

Re: BiCollector

In this form (not locked to Map.Entry) it seems like a candidate for the JDK. The implementation is private, so it would be one public method that provides a new way to process streams. Stephen On 14 June 2018 at 05:56, Tagir Valeev wrote: > Hello! > > In my StreamEx library I created a

Re: RFR JDK-8204930 Reader:nullReader() spec does not match the behavior

On 14/06/2018 12:08, Patrick Reinhart wrote: Sorry, everybody it seems, that I completely messed things up :-(( @Alan can you help me getting that back in order again? Sure. BTW: I should have mentioned that the main workaround that people are using is to edit the CSR as that allows you to

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

On 12/06/2018 17:52, Joe Wang wrote: Hi all, It's been a while since the 1st round of reviews. Thank you all for the valuable comments and suggestions!  Note that Roger's last response went to nio-dev, but not core-libs-dev, I've therefore attached it below. CSR [2]: the CSR is now

Re: RFR JDK-8204930 Reader:nullReader() spec does not match the behavior

Sorry, everybody it seems, that I completely messed things up :-(( @Alan can you help me getting that back in order again? -Patrick On 2018-06-14 13:03, Alan Bateman wrote: On 14/06/2018 11:50, Patrick Reinhart wrote: Hi everybody, I re-proposed the CSR with the changed API. The CSR is

Re: RFR JDK-8204930 Reader:nullReader() spec does not match the behavior

On 14/06/2018 11:50, Patrick Reinhart wrote: Hi everybody, I re-proposed the CSR with the changed API. The CSR is associated with the original change-set that was pushed a few months so the simplest is to just create a follow-up CSR that is linked to the new bug. Somehow I'm not able to

Re: RFR JDK-8204930 Reader:nullReader() spec does not match the behavior

Hi everybody, I re-proposed the CSR with the changed API. Somehow I'm not able to add the comment explaning the change. (Tried both in proposed and draft state) :-( I also updated the webrev to represent the two small changes as proposed from Brian. -Patrick On 2018-06-13 23:16, Brian

Re: RFR: 8204967: Resolve disabled warnings for libunpack

On 2018-06-13 18:57, Srinivas Dama wrote: Hi, Please review http://cr.openjdk.java.net/~sdama/8204967/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8204967 Hi Srinivas, In src/jdk.pack/share/native/common-unpack/zip.cpp, you just read and discard the return value from fread to

Re: BiCollector

Hi Maurizio, Collectors.partitioningBy is only superficially similar. It partitions the stream into two disjunct sub-streams of elements and collects each of them using the same collector. BiCollector OTOH collects all the elemets of the original Stream "two times" into two independent

Re: BiCollector

Hi Paul, On 06/11/18 19:10, Paul Sandoz wrote: Hi Peter, I like it and can see it being useful, thanks for sharing. I am hesitating a little about it being in the JDK because there is the larger abstraction of a BiStream, where a similar form of collection would naturally fit (but perhaps

Re: BiCollector

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