Re: RFR: 8151876: (tz) Support tzdata2016d

CLDR locale data defines time zone names, like this (in en.xml): Almaty Time Almaty Standard Time Almaty Summer Time

Re: Review Request JDK-8152721: Java Web Start splash mechanism is not working in JDK9

On 28/05/2016 05:29, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152721/webrev.00/ The launcher does not handle the new options with whitespace separated arguments properly. This patch applies that consistently in java.c I leave arg.c as is that Kumar/Henry can

Review Request JDK-8152721: Java Web Start splash mechanism is not working in JDK9

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152721/webrev.00/ The launcher does not handle the new options with whitespace separated arguments properly. This patch applies that consistently in java.c I leave arg.c as is that Kumar/Henry can consider cleanup in the future. Mandy

RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS

Hi, Please help review the change for JDK-8061777. issue: https://bugs.openjdk.java.net/browse/JDK-8061777 webrev: http://cr.openjdk.java.net/~sherman/8061777 Cause: ZipPath/ZipFileSystem uses byte[] as the internal underlying storage for entry names (for better performance, as the "name" is

Re: RFR 8154189: Deprivilege java.sql and java.sql.rowset module

On 27/05/2016 18:28, Lance Andersen wrote: Hi all, This is a request to review the changes below to Deprivilege java.sql and java.sql.rowset modules This looks okay to me too. A minor point is that it would be good to keep PLATFORM_MODULES sorted. -Alan.

Re: RFR 8154189: Deprivilege java.sql and java.sql.rowset module

Hi Mandy, > On May 27, 2016, at 1:56 PM, Mandy Chung wrote: > > >> On May 27, 2016, at 10:28 AM, Lance Andersen >> wrote: >> >> Hi all, >> >> This is a request to review the changes below to Deprivilege java.sql and >> java.sql.rowset

Re: RFR 8154189: Deprivilege java.sql and java.sql.rowset module

> On May 27, 2016, at 10:28 AM, Lance Andersen > wrote: > > Hi all, > > This is a request to review the changes below to Deprivilege java.sql and > java.sql.rowset modules > : The change looks fine. It’s okay to grants AllPermission to get started. It’d be nice

RFR 8154189: Deprivilege java.sql and java.sql.rowset module

Hi all, This is a request to review the changes below to Deprivilege java.sql and java.sql.rowset modules changes to: make/common/Modules.gmk ljanders-mac:make ljanders$ hg diff diff -r cae471d3b877 make/common/Modules.gmk --- a/make/common/Modules.gmk Thu May 26 17:17:51 2016 +

Re: RFR: 8151876: (tz) Support tzdata2016d

I guess there's a low risk of timezone not being identified if being parsed in through a formatter. Isn't such an approach discouraged though ? short IDs were already subject to change in tzdata releases. Ramanand found one issue by removal of these resource strings (so far) and that's

Re: Review Request: JDK-8157986: Runtime support for javac to determine arguments to the runtime environment

> On May 27, 2016, at 2:24 AM, Alan Bateman wrote: > > On 26/05/2016 20:40, Mandy Chung wrote: >> This patch allows jdk.compiler to get the runtime arguments without pulling >> in java.management (that requires java.rmi). We should look into use cases >> further in

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi , On 5/27/2016 7:34 PM, Daniel Fuchs wrote: On 27/05/16 15:47, Roger Riggs wrote: Hi Nadeesh, Seeing the complexity of this code expand, I can't help wonder if there is a better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or two digits) with optional ":"s. And then match

Re: RFR: 8151876: (tz) Support tzdata2016d

This change seems to beyond my proposal that the "GMT±hh:mm" format is used for *new* zones with the "±hh" format. But this change removes *existing* zones which have changed to use the "±hh" format in tzdata. Can this cause any compatibility issues? And have we agreed to use the "GMT±hh:mm"

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

On 27/05/16 15:47, Roger Riggs wrote: Hi Nadeesh, Seeing the complexity of this code expand, I can't help wonder if there is a better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or two digits) with optional ":"s. And then match that to the valid patterns. The use of numeric

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Nadeesh, Seeing the complexity of this code expand, I can't help wonder if there is a better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or two digits) with optional ":"s. And then match that to the valid patterns. The use of numeric indices obscures what is going on.

Re: RFR: 8151876: (tz) Support tzdata2016d

Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. Regards, Sean. On 26/05/16 14:22, Ramanand Patil wrote: HI all, Please review the latest TZDATA integration

Re: Review Request: JDK-8157986: Runtime support for javac to determine arguments to the runtime environment

On 26/05/2016 20:40, Mandy Chung wrote: This patch allows jdk.compiler to get the runtime arguments without pulling in java.management (that requires java.rmi). We should look into use cases further in the future and determine whether a public API should be provided.

RFR 8158023: SocketExceptions contain too little information sometimes

Hi all, please review the following change: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 During error analysis I stumbled over a place where I encountered a SocketException which was thrown along with some strerror

Re: RFR 8157996: Unneeded import in lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java

> On 26 May 2016, at 23:51, Alexandre (Shura) Iline > wrote: > > http://cr.openjdk.java.net/~shurailine/8157996/webrev.01/ Looks good Shura. > Thank you. > > Shura > >> On May 26, 2016, at 3:29 PM, Alexandre (Shura) Iline >> wrote: