RE: RFR: 8151876: (tz) Support tzdata2016b

Hi Masayoshi, Thank you for clarification. Since, the tzdata2016c is already released, I will update the this bug and send a new review request to include both tzdata2016b and tzdata2016c. Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Monday, March 28, 2016 6:50

Re: JAXP default implementation and JDK-8152063

Awesome. I'll look into getting a spec change approved. Best, Joe On 3/28/2016 6:24 PM, David M. Lloyd wrote: I think that either of these options would work great for us. On 03/28/2016 05:46 PM, huizhe wang wrote: Thanks David. So I understand the dynamic nature of the server

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

> On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote: > > Hello, > > New iteration of the webrev updated after the Jigsaw integration and > incorporating the earlier feedback. > >http://cr.openjdk.java.net/~darcy/8151763.1 > # tools/jimage/JImageTest.java

Re: JDK 9 RFR of JDK-8152873: java/util/Locale/LocaleProviders.sh fails on several platforms

Looks fine; thanks Amy, -Joe On 3/28/2016 7:33 PM, Amy Lu wrote: java/util/Locale/LocaleProviders.sh starts failing after JDK-8150432, there's simple issue in JDK-8150432. Please review this quick fix. bug: https://bugs.openjdk.java.net/browse/JDK-8152873 webrev:

JDK 9 RFR of JDK-8152873: java/util/Locale/LocaleProviders.sh fails on several platforms

java/util/Locale/LocaleProviders.sh starts failing after JDK-8150432, there's simple issue in JDK-8150432. Please review this quick fix. bug: https://bugs.openjdk.java.net/browse/JDK-8152873 webrev: http://cr.openjdk.java.net/~amlu/8152873/webrev.00/ Thanks, Amy ---

Re: JAXP default implementation and JDK-8152063

I think that either of these options would work great for us. On 03/28/2016 05:46 PM, huizhe wang wrote: Thanks David. So I understand the dynamic nature of the server configuration. There maybe two options to solve it: 1) Add a system property to point to a Layer in order to find an

Re: RFR 9: 8152005: sun/misc/SunMiscSignalTest.java failed intermittently

Hi Roger, If the test is only rarely failing as-is, I'd prefer to keep the first timeout short and only fallback to the longer timeout in the fallback case. What do you think? Thanks, -Joe On 3/28/2016 11:22 AM, Roger Riggs wrote: Please review this improvement to an intermittently failing

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Hello, New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. http://cr.openjdk.java.net/~darcy/8151763.1 Thanks, -Joe On 3/16/2016 4:52 PM, Joseph D. Darcy wrote: Hi Jon, Noted; I'll make that improvement in the next round. Thanks

Re: JAXP default implementation and JDK-8152063

Thanks David. So I understand the dynamic nature of the server configuration. There maybe two options to solve it: 1) Add a system property to point to a Layer in order to find an alternative-system-default. This will add a new step to the JAXP process after the current ServiceLoader

Re: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries

Yasumasa It's a tricky call. To be honest, as I said at the very beginning, I'm not sure whether or not it's a good idea and worth the efffort to push this into the j.u.zip package to support the "traditional PKWare encryption", which is known to be "seriously flawed, and in particular is

Re: RFR: 8152733: Avoid creating Manifest when checking for Multi-Release attribute

On 2016-03-25 17:53, Paul Sandoz wrote: On 25 Mar 2016, at 17:37, Claes Redestad wrote: Interesting, my only concern is we'd add more code/complexity, but it seems the shift will always be == len when not matching a character in src (the proof is left out as an

RFR 9: 8152005: sun/misc/SunMiscSignalTest.java failed intermittently

Please review this improvement to an intermittently failing test of sun.misc.Signal. The timeout value is increased in case of a busy system and for additional debug value the raising of the signal is retried. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-signal-8152005/ Issue:

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Mandy, Kim, Per and Roger I'd like to continue the discussion about the 2nd part of removing jdk.internal.ref.Cleaner in this discussion thread. There was some discussion about whether to synchronize with ReferenceHandler thread and wait for it to enqueue the Reference(s) or simply

Re: RFR: 8151876: (tz) Support tzdata2016b

Hi Ramanand, What I meant is to remove those new resources so that "GMT+hh:mm" is used for formatting. There may be some tests that require changes. Thanks, Masayoshi On 3/28/2016 7:31 PM, Ramanand Patil wrote: Hi Masayoshi, Currently I have not defined the new TimeZoneNames with +hh

Re: JAXP default implementation and JDK-8152063

The reason is because we use a single boot path but we don't know at the time of boot whether or not we will have a JAXP provider, nor where it will come from; that is up to the server configuration that we end up running. With the system properties approach we can just clear all the

Re: [DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection

Hi Mark, Could you please review my attached patch and reproducer of JDK-8151212 [1] ? If do you have a comment(s), please let me know. [1]: https://bugs.openjdk.java.net/browse/JDK-8151212 Thanks, Yuji 2016-03-05 3:19 GMT+09:00 KUBOTA Yuji : > Hi Roger and all, > >

RE: RFR: 8151876: (tz) Support tzdata2016b

Hi Masayoshi, Currently I have not defined the new TimeZoneNames with +hh format, instead I have defined them as per the earlier convention like: +{"Asia/Barnaul", new String[] {"Barnaul Time", "BAT", + "Barnaul Summer Time", "BAST", +

PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries

PING: Could you review it? We want to move forward this enhancement. Thanks, Yasumasa 2016/03/19 22:01 "Yasumasa Suenaga" : > Hi Alan, > > > I think the main issue here is to decide whether the API > > should be extended for encryption or not. > > We've discussed on the