Add x-IBM-1129 charset

Hello, With the following three bugs, all the default locale charsets except two (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) are fixed for AIX platform. - JDK-8201540: [AIX] Extend the set of supported charsets in java.base - JDK-8202329: Codepage mappings for IBM-943 and Big5 (aix) -

Re: 8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017

On 18/05/2018 23:08, Brian Burkhalter wrote: : Here is another version which incorporates your suggestion: http://cr.openjdk.java.net/~bpb/8202076/webrev.02/ GetFileAttributesEx follows sym links, FindFirstFile does not. You should be able to quickly check it but I think the patch means that

Re: FW: RFR: 8177276: MethodHandles.insertArguments doesn't specify IllegalArgumentException on index mismatch

Hi Vivek, IMHO, assigning back to methodHandle on  line 109, 115, 122,123 is confusing Regards, Nadeesh On 19/05/18 3:07 AM, Vivek Theeyarath wrote: Hi All, A gentle reminder seeking review. Regards Vivek From: Vivek Theeyarath Sent: Thursday, May 17, 2018 6:22 AM To:

Re: RFR: jsr166 jdk integration 2018-05

Sorry Paul but all this does is endorse the second camp: they want structural and content modifications to trigger CME. Further it assumes that doing a replaceAll while an iterator is active is always an error which need not be the case. CME is about the safety of the implementation, not the

Re: RFR: jsr166 jdk integration 2018-05

I like thinking of ArrayList as just an optimized HashMap, Lua-style, and HashMap.replaceAll also does not increment modCount, supporting our "structural modification" position. The thing that bothers me most about the status quo is the *inconsistency* - between root list and subList, between

Re: RFR: jsr166 jdk integration 2018-05

On Fri, May 18, 2018 at 4:30 PM, joe darcy wrote: > Hello, > > On 5/17/2018 8:51 PM, Stuart Marks wrote: > >> >> Given that the replaceAll methods have incremented modCount since they > were introduced in JDK 8, changing that behavior in widely-used classes > merits a CSR

Re: Review Request JDK-8202113: Reflection API is causing caller classes to leak

Hi Peter, Sorry for the late reply.  I was on vacation last week and just returned. On 5/14/18 8:43 AM, Peter Levart wrote: Hi Mandy, Sorry for noticing this too late, but... If it was not necessary to keep legacy hacky behavior (to honor the patched "modifiers" field), wouldn't it be

Re: RFR: Small cleanups in java.lang.ref

On 5/18/18 7:47 AM, Martin Buchholz wrote: On the contrary, I'm very happy to see gc team actively maintaining java.lang.ref. I've reverted changes to Reference.java http://cr.openjdk.java.net/~martin/webrevs/jdk/Reference-cleanup-1/ This looks okay.

Re: RFR: jsr166 jdk integration 2018-05

On May 19, 2018, at 9:42 AM, Martin Buchholz wrote: > > I like thinking of ArrayList as just an optimized HashMap, Lua-style, and > HashMap.replaceAll also does not increment modCount, supporting our > "structural modification" position. > > The thing that bothers me most