Re: RFR: 8151876: (tz) Support tzdata2016d

[Masayoshi Okutsu]

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

   

Almaty Time
Almaty Standard 
Time
Almaty Summer Time



The CLDR converter tool tries to fill in the missing short names from 
the legacy TimeZoneNames data. Removing existing names causes some 
unexpected behavior. I think JDK-8157814 is an example of the unexpected 
behavior. And the suggested fix in JDK-8157814 looks to me like a 
workaround.


I still think the existing names should be kept unchanged for this fix.

Thanks,
Masayoshi

On 5/28/2016 12:04 AM, Seán Coffey wrote:
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 captured in JDK-8157814


There's a decision to be made about how to use the GMT±hh:mm format 
for new releases given IANA's new short ID identifier mechanism. I 
think that could be discussed as a separate issue. I'd like to see us 
follow a similar approach to IANA and use GMT identifiers on new 
timezones and perhaps even consider using the IANA long name format 
also for the getDisplayName(..) calls that can be made. e.g. 
"Asia/Almaty" instead of "Alma-Ata Time"

Regards,
Sean.
On 27/05/16 15:24, Masayoshi Okutsu wrote:
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" format?

Thanks,
Masayoshi


On 5/27/2016 10:19 PM, Seán Coffey wrote:
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 (tzdata2016d) to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

Patch Contains:

1.   IANA tzdata2016d integration into JDK. [It also includes 
tzdata2016b and tzdata2016c which was not integrated].


2.   "GMT[+ -]hh:mm" is used for formatting of the modified or 
newly added TimeZones in tzdata2016d.


[This is done to accommodate the IANA's new system where the zones 
use numeric time zone abbreviations like "+04" instead of invented 
abbreviations like "ASTT".]


3.   Test case: 
java/time/test/java/time/format/TestZoneTextPrinterParser.java is 
updated to include the failures because of GMT[+ -]hh:mm format names.


4.   Few other failing tests: For few other failing tests, new 
linked bugs are created and will be addressed in a separate patch.



Regards,

Ramanand.

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

[Alan Bateman]

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 consider cleanup in the future.

The new options are handled correctly on the command, I think it's just 
the JDK internal JLI_Launch entry point where this was missed. The patch 
looks okay, I just wonder if there is there are any tests that could use 
this entry point.


-Alan

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

[Mandy Chung]

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

[Xueming Shen]

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 stored as bytes inside
the zip/jar file, it is desirable to avoid the redundant String<->byte[] 
conversion,
if possible). With this design, it is natural to also work on byte[] directly 
for those
"path" operations, including the "normalization", which mainly is to remove the
redundant "/" and switch the "\" to "/". This appears to be a problem for 
non-utf8
encoded zip file (utf8 is the default encoding used to de/encode the entry name
for the Java jar/zip APIs), especially those double-byte encodings that have 
0x5c
('\') as one of the double-byte bytes. The 0x5c byte will be mistakenly 
normalized
to '\' if we normalize on the byte[] directly. The proposed change here is to
normalize on the "String" to avoid this problem. Given the fact that Java 
jar/zip
is specified to use utf-8 by default, to avoid the potential performance 
risk/cost
for most of the zip/jar files (if we switch completely to the String based 
operation)
the utf-8/byte[] path is still being used (as the default) when the encoding is 
utf-8.
The implementation only switches to "String based" code path when the encoding
is specifically specified as "non-utf8", which should be rare.

Thanks,
Sherman

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

[Alan Bateman]

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

[Lance Andersen]

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 modules
>> :
> 
> The change looks fine.
Thank you
> 
> It’s okay to grants AllPermission to get started.  It’d be nice if we could 
> grant fine-grained permissions in the future.
Agree, it is something to try and work towards.

Best
Lance
> 
> Mandy
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

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

[Mandy Chung]

> 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 if we could 
grant fine-grained permissions in the future.

Mandy

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

[Lance Andersen]

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 +
+++ b/make/common/Modules.gmk   Fri May 27 13:21:22 2016 -0400
@@ -57,7 +57,6 @@
 java.rmi \
 java.security.jgss \
 java.security.sasl \
-java.sql \
 java.xml \
 java.xml.crypto \
 jdk.httpserver \
@@ -72,7 +71,6 @@
 
 # to be deprivileged
 BOOT_MODULES += \
-java.sql.rowset \
 java.smartcardio \
 jdk.naming.rmi \
 #
@@ -105,6 +103,8 @@
 
 PLATFORM_MODULES += \
 java.compiler \
+java.sql \
+java.sql.rowset \
 java.scripting \
 jdk.accessibility \
 jdk.charsets \
ljanders-mac:make ljanders$ 




Changes to: src/java.base/share/conf/security/java.policy


ljanders-mac:jdk ljanders$ hg diff
diff -r df35a805b405 src/java.base/share/conf/security/java.policy
--- a/src/java.base/share/conf/security/java.policy Fri May 27 08:52:22 
2016 -0700
+++ b/src/java.base/share/conf/security/java.policy Fri May 27 13:24:22 
2016 -0400
@@ -33,6 +33,14 @@
 permission java.io.FilePermission 
"${java.home}/conf/security/ucrypto-solaris.cfg", "read";
 };
 
+grant codeBase "jrt:/java.sql" { 
+permission java.security.AllPermission; 
+}; 
+
+grant codeBase "jrt:/java.sql.rowset" { 
+permission java.security.AllPermission; 
+};
+
 grant codeBase "jrt:/jdk.crypto.ec" {
 permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.*";
 permission java.lang.RuntimePermission "loadLibrary.sunec";
ljanders-mac:jdk ljanders$ 



As part of the testing, we have run

- CTS  JDBC tests - against Derby embedded and client driver
- All of the Derby test suites
- JTREG tests
- JCK JDBC and RowSet tests


The Derby tests suites uncovered 2 Derby specific issues which have been 
addressed in the derby trunk, all other tests passed

thank you and have a nice weekend

Best
Lance

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: 8151876: (tz) Support tzdata2016d

[Seán Coffey]

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 
captured in JDK-8157814


There's a decision to be made about how to use the GMT±hh:mm format for 
new releases given IANA's new short ID identifier mechanism. I think 
that could be discussed as a separate issue. I'd like to see us follow a 
similar approach to IANA and use GMT identifiers on new timezones and 
perhaps even consider using the IANA long name format also for the 
getDisplayName(..) calls that can be made. e.g. "Asia/Almaty" instead of 
"Alma-Ata Time"


Regards,
Sean.

On 27/05/16 15:24, Masayoshi Okutsu wrote:
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" format?

Thanks,
Masayoshi


On 5/27/2016 10:19 PM, Seán Coffey wrote:
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 (tzdata2016d) to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

Patch Contains:

1.   IANA tzdata2016d integration into JDK. [It also includes 
tzdata2016b and tzdata2016c which was not integrated].


2.   "GMT[+ -]hh:mm" is used for formatting of the modified or 
newly added TimeZones in tzdata2016d.


[This is done to accommodate the IANA's new system where the zones 
use numeric time zone abbreviations like "+04" instead of invented 
abbreviations like "ASTT".]


3.   Test case: 
java/time/test/java/time/format/TestZoneTextPrinterParser.java is 
updated to include the failures because of GMT[+ -]hh:mm format names.


4.   Few other failing tests: For few other failing tests, new 
linked bugs are created and will be addressed in a separate patch.



Regards,

Ramanand.

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

[Mandy Chung]

> 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 the future and determine whether a public API should be provided.
>> 
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157986/webrev.00/index.html
>> 
> This looks okay to except that it might be better to drop the reference to 
> JDK-8157979 from the @implNote.

Yes I plan to drop it.

thanks
Mandy

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

[nadeesh tv]

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 that to the valid patterns.
The use of numeric indices obscures what is going on.

I will try in this direction.


Also, there are a number of conditions that depend on the length of the
remaining input.
I suspect that when appendOffset is used to parse a sequence of fields,
characters belonging
to the following fields will throw off the checks.  I didn't see any
tests that would confirm that
appendOffset with input for additional fields (and input) works as
intended.

Thanks, Roger


Hi,

Stephen is the expert here. However, I can't help feeling
that the patterns that allow you to parse/format a single
digit hour without the ':' separator ("+H" excepted) are
confusing. If we removed those (only adding +H, +H:mm, +H:MM,
+H:MM:ss, +H:MM:SS, +H:mm:ss) would the parsing be simplified?

Would that be an acceptable compromise?
I feel if we remove those patterns for Single Digit hour ( without 
colons),  it may cause confusion.


Thanks and Regards,
Nadeesh


best regards,

-- daniel




On 5/26/2016 3:49 AM, nadeesh tv wrote:

Hi all,

Please review

BugId : https://bugs.openjdk.java.net/browse/JDK-8066806

Issue: java.time.format.DateTimeFormatter cannot parse an offset with
single digit hour

webrev:  http://cr.openjdk.java.net/~ntv/8066806/webrev.03/

Solution: Added the suggested patterns but the parsing logic became
too complex.
 Appreciate any suggestion to make the  parsing less complicated







--
Thanks and Regards,
Nadeesh TV

Re: RFR: 8151876: (tz) Support tzdata2016d

[Masayoshi Okutsu]

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" format?

Thanks,
Masayoshi


On 5/27/2016 10:19 PM, Seán Coffey wrote:
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 (tzdata2016d) to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

Patch Contains:

1.   IANA tzdata2016d integration into JDK. [It also includes 
tzdata2016b and tzdata2016c which was not integrated].


2.   "GMT[+ -]hh:mm" is used for formatting of the modified or 
newly added TimeZones in tzdata2016d.


[This is done to accommodate the IANA's new system where the zones 
use numeric time zone abbreviations like "+04" instead of invented 
abbreviations like "ASTT".]


3.   Test case: 
java/time/test/java/time/format/TestZoneTextPrinterParser.java is 
updated to include the failures because of GMT[+ -]hh:mm format names.


4.   Few other failing tests: For few other failing tests, new 
linked bugs are created and will be addressed in a separate patch.



Regards,

Ramanand.

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

[Daniel Fuchs]

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 indices obscures what is going on.

Also, there are a number of conditions that depend on the length of the
remaining input.
I suspect that when appendOffset is used to parse a sequence of fields,
characters belonging
to the following fields will throw off the checks.  I didn't see any
tests that would confirm that
appendOffset with input for additional fields (and input) works as
intended.

Thanks, Roger


Hi,

Stephen is the expert here. However, I can't help feeling
that the patterns that allow you to parse/format a single
digit hour without the ':' separator ("+H" excepted) are
confusing. If we removed those (only adding +H, +H:mm, +H:MM,
+H:MM:ss, +H:MM:SS, +H:mm:ss) would the parsing be simplified?

Would that be an acceptable compromise?

best regards,

-- daniel




On 5/26/2016 3:49 AM, nadeesh tv wrote:

Hi all,

Please review

BugId : https://bugs.openjdk.java.net/browse/JDK-8066806

Issue: java.time.format.DateTimeFormatter cannot parse an offset with
single digit hour

webrev:  http://cr.openjdk.java.net/~ntv/8066806/webrev.03/

Solution: Added the suggested patterns but the parsing logic became
too complex.
 Appreciate any suggestion to make the  parsing less complicated

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

[Roger Riggs]

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.

Also, there are a number of conditions that depend on the length of the 
remaining input.
I suspect that when appendOffset is used to parse a sequence of fields, 
characters belonging
to the following fields will throw off the checks.  I didn't see any 
tests that would confirm that

appendOffset with input for additional fields (and input) works as intended.

Thanks, Roger


On 5/26/2016 3:49 AM, nadeesh tv wrote:

Hi all,

Please review

BugId : https://bugs.openjdk.java.net/browse/JDK-8066806

Issue: java.time.format.DateTimeFormatter cannot parse an offset with 
single digit hour


webrev:  http://cr.openjdk.java.net/~ntv/8066806/webrev.03/

Solution: Added the suggested patterns but the parsing logic became 
too complex.

 Appreciate any suggestion to make the  parsing less complicated

Re: RFR: 8151876: (tz) Support tzdata2016d

[Seán Coffey]

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 (tzdata2016d) to JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

Patch Contains:

1.   IANA tzdata2016d integration into JDK. [It also includes tzdata2016b 
and tzdata2016c which was not integrated].

2.   "GMT[+ -]hh:mm" is used for formatting of the modified or newly added 
TimeZones in tzdata2016d.

[This is done to accommodate the IANA's new system where the zones use numeric time zone 
abbreviations like "+04" instead of invented abbreviations like "ASTT".]

3.   Test case: 
java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to 
include the failures because of GMT[+ -]hh:mm format names.

4.   Few other failing tests: For few other failing tests, new linked bugs 
are created and will be addressed in a separate patch.

  


Regards,

Ramanand.

  

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

[Alan Bateman]

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.

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157986/webrev.00/index.html

This looks okay to except that it might be better to drop the reference 
to JDK-8157979 from the @implNote.


-Alan

RFR 8158023: SocketExceptions contain too little information sometimes

[Langer, Christoph]

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 information as 
message. I found it hard to find the originating code spot with that 
information.

So I looked at the places where we throw exceptions, namely JNU_Throw... and 
NET_Throw... functions and came up with the following enhancement:
- NET_ThrowByNameWithLastError can go completely as it does not provide any 
benefit over JNU_ThrowByNameWithLastError.
- JNU_ThrowByNameWithLastError can be cleaned up.

- I added JNU_ThrowByNameWithMessageAndLastError to print out a string like 
message + ": " + last error.

- I went over all places where NET_ThrowByNameWithLastError is used and 
replaced it appropriately.

Do you think this change is desirable/possible?

Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as 
well as JNU_Throw... code affects all.

Best regards
Christoph

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

[Chris Hegarty]

> 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:
>> 
>> 
>>> On May 26, 2016, at 3:16 PM, Mandy Chung  wrote:
>>> 
>>> 
 On May 26, 2016, at 2:30 PM, Alexandre (Shura) Iline 
  wrote:
 
 Hi.
 
 Please take a look on an obvious fix:
 http://cr.openjdk.java.net/~shurailine/8157996/webrev.00/
 
 There was an unneeded import statement which was getting in the way when 
 running tests with limited module availability. 
 
 Also in a couple of places I have added try with resources.
>>> 
>>> Looks okay.  Can you take out the extra space between “init” and “(“ while 
>>> you are on this file?
>>> 65 init (fis);
>> 
>> Then I am taking out all extra spaces in this code. Per the examples in 
>> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html. :)
>> 
>> I was thinking whether to do it to not.

I have removed the extra spaces in other areas too. It is a particular, IMHO 
bad,
style that some engineers follow.

-Chris.