Re: [12] RFR: 8212941: Loosen the range of JapaneseEra

[naoto . sato]

Hi Joe,

On 10/26/18 3:00 PM, joe darcy wrote:

Hi Naoto,

I'd like to see a bit some discussion up front about the expected 
evolution of this class.


For example, "once an era is defined, subsequent versions of the API 
will add a constant for it. etc. Eras are expected to have consecutive 
integers associated with them, etc. "


Thanks. Those will clarify the intention of the change more. Will 
incorporate them.




Once a formal name is added for the new era, will that value be serial 
equivalent to the current new era value being used in the class? 
Basically, is the name or the int value the basis of the serial identity 
of a JapaneseEra object?


Yes to the former question. The "NewEra" era should be equivalent to 
what's coming after the name is decided. Thus the int value should be 
the sole identity for the designated era. This will ensure the 
maintenance releases which cannot backport public singleton instances 
work without spec change.


Naoto



Thanks,

-Joe


On 10/26/2018 2:00 PM, naoto.s...@oracle.com wrote:

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8212941

The proposed fix and CSR (not approved yet) are located at:

http://cr.openjdk.java.net/~naoto/8212941/webrev.02/
https://bugs.openjdk.java.net/browse/JDK-8212942

This change is intended to loosen the spec of JapaneseEra so that 
later era additions won't require unnecessary spec changes. This is 
particularly important for the maintenance releases.


Naoto

Re: RFR: XXS JDK-8213056,,Nested anchor tags in java.lang.module

[Mandy Chung]

Looks good.
Mandy

On 10/26/18 3:10 PM, Jonathan Gibbons wrote:
Please review a couple of very small changes to fix some HTML issues 
in the generated docs.


The first change removes an empty paragraph; the second avoids causing 
nested  tags.


JBS: https://bugs.openjdk.java.net/browse/JDK-8213056

-- Jon



Changes inline here:

$ hg diff
diff -r 3a767a000aab src/java.base/share/classes/java/lang/String.java
--- a/src/java.base/share/classes/java/lang/String.java Fri Oct 26 
13:59:02 2018 -0700
+++ b/src/java.base/share/classes/java/lang/String.java Fri Oct 26 
15:06:33 2018 -0700

@@ -2821,7 +2821,6 @@
  * 
  * If {@code n == 0} then the line remains unchanged. However, line
  * terminators are still normalized.
- * 
  *
  * @param n  number of leading
  *   {@link Character#isWhitespace(int) white space 
characters}
diff -r 3a767a000aab 
src/java.base/share/classes/java/lang/module/package-info.java
--- a/src/java.base/share/classes/java/lang/module/package-info.java 
Fri Oct 26 13:59:02 2018 -0700
+++ b/src/java.base/share/classes/java/lang/module/package-info.java 
Fri Oct 26 15:06:33 2018 -0700

@@ -34,7 +34,7 @@
  * will cause a {@code NullPointerException}, unless otherwise 
specified. 

  *
  *
- * {@index "Module Resolution"}
+ * {@index "Module Resolution"}
  *
  *  Resolution is the process of computing how modules depend on 
each other.

  * The process occurs at compile time and run time. 

Re: RFR: XXS JDK-8213056,,Nested anchor tags in java.lang.module

[joe darcy]

+1

-Joe


On 10/26/2018 3:10 PM, Jonathan Gibbons wrote:
Please review a couple of very small changes to fix some HTML issues 
in the generated docs.


The first change removes an empty paragraph; the second avoids causing 
nested  tags.


JBS: https://bugs.openjdk.java.net/browse/JDK-8213056

-- Jon



Changes inline here:

$ hg diff
diff -r 3a767a000aab src/java.base/share/classes/java/lang/String.java
--- a/src/java.base/share/classes/java/lang/String.java Fri Oct 26 
13:59:02 2018 -0700
+++ b/src/java.base/share/classes/java/lang/String.java Fri Oct 26 
15:06:33 2018 -0700

@@ -2821,7 +2821,6 @@
  * 
  * If {@code n == 0} then the line remains unchanged. However, line
  * terminators are still normalized.
- * 
  *
  * @param n  number of leading
  *   {@link Character#isWhitespace(int) white space 
characters}
diff -r 3a767a000aab 
src/java.base/share/classes/java/lang/module/package-info.java
--- a/src/java.base/share/classes/java/lang/module/package-info.java 
Fri Oct 26 13:59:02 2018 -0700
+++ b/src/java.base/share/classes/java/lang/module/package-info.java 
Fri Oct 26 15:06:33 2018 -0700

@@ -34,7 +34,7 @@
  * will cause a {@code NullPointerException}, unless otherwise 
specified. 

  *
  *
- * {@index "Module Resolution"}
+ * {@index "Module Resolution"}
  *
  *  Resolution is the process of computing how modules depend on 
each other.

  * The process occurs at compile time and run time. 

Re: [12] RFR: 8212941: Loosen the range of JapaneseEra

[joe darcy]

Hi Naoto,

I'd like to see a bit some discussion up front about the expected 
evolution of this class.


For example, "once an era is defined, subsequent versions of the API 
will add a constant for it. etc. Eras are expected to have consecutive 
integers associated with them, etc. "


Once a formal name is added for the new era, will that value be serial 
equivalent to the current new era value being used in the class? 
Basically, is the name or the int value the basis of the serial identity 
of a JapaneseEra object?


Thanks,

-Joe


On 10/26/2018 2:00 PM, naoto.s...@oracle.com wrote:

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8212941

The proposed fix and CSR (not approved yet) are located at:

http://cr.openjdk.java.net/~naoto/8212941/webrev.02/
https://bugs.openjdk.java.net/browse/JDK-8212942

This change is intended to loosen the spec of JapaneseEra so that 
later era additions won't require unnecessary spec changes. This is 
particularly important for the maintenance releases.


Naoto

Re: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken

[Mandy Chung]

Great!  I have pushed this changeset.

Mandy

On 10/26/18 2:09 PM, Martin Buchholz wrote:

Thanks for doing this - I tested the patch and it'll work for us.

On Fri, Oct 26, 2018 at 8:46 AM, Mandy Chung > wrote:


jsr166 depends on the internal Unsafe xxxObject methods and is
currently broken. Since the rename is motivated by Valhalla, we
agree to keep the internal Unsafe xxxObject methods as deprecated
in the jdk repo.

Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00


Mandy

Re: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken

[Martin Buchholz]

Thanks for doing this - I tested the patch and it'll work for us.

On Fri, Oct 26, 2018 at 8:46 AM, Mandy Chung  wrote:

> jsr166 depends on the internal Unsafe xxxObject methods and is currently
> broken. Since the rename is motivated by Valhalla, we agree to keep the
> internal Unsafe xxxObject methods as deprecated in the jdk repo.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00
>
> Mandy
>

[12] RFR: 8212941: Loosen the range of JapaneseEra

[naoto . sato]

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8212941

The proposed fix and CSR (not approved yet) are located at:

http://cr.openjdk.java.net/~naoto/8212941/webrev.02/
https://bugs.openjdk.java.net/browse/JDK-8212942

This change is intended to loosen the spec of JapaneseEra so that later 
era additions won't require unnecessary spec changes. This is 
particularly important for the maintenance releases.


Naoto

Re: Fwd: Re: JMathConstant submission for upcoming JDK

[joe darcy]

Hello,

I would not support a class with this purpose of this scale to be added 
to the JDK.


BigDecimal has had constants for zero, one, and ten since JDK 5.0 
shipped in 2004.


I consider myself to have a reasonable math background for a 
non-mathematician and I don't know what field many of these constants 
are from. In other words, many of the constants are for more specialized 
use as opposed to being generally usable.


In terms of how the constants are structured, for a BigDecimal-based API 
I would expect a method that took a MathContext to determine how many 
digits are needed and under what rounding mode as opposed to a field 
with a fixed precision (unless the constant is some exactly 
representable number).


For example, it would be a "small matter or programming" to provide 
methods like


    BigDecimal pi(MathContext mc)
    BigDecimal tau(MathContext mc)
    BigDecimal euler(MathContext mc)

that returned suitably rounded approximation of those transcendental values.

A value like GRAVITY is a poor fit for BigDecimal; first it depends on 
the units (SI vs Imperial units) and is subject to adjustment with 
further scientific investigation.


Cheers,

-Joe


On 10/26/2018 12:12 PM, Roger Riggs wrote:

[Sorry for the repeat, this time to ensure Robert sees the question]

Hi Robert,

No doubt a useful list of constants for some developers.

Can you elaborate on why you think these constants should be in the JDK
and why they are the right constants especially as related to 
precision and length.
I would expect for some applications these would be more precise than 
they
need and hurt performance and for other applications they would not 
have enough

precision.

Thanks, Roger

On 10/26/18 12:39 PM, rob...@liguorisoftware.com wrote:

Hi Chris,

I wrote this simple utility class you may want to use in an upcoming 
version of the JDK.  Btw, I'm the author of the Java Pocket Guide.:)


Or is there a better place I can submit simple code like this for the 
JDK?


Thanks, Robert

import java.math.BigDecimal;

public class JMathConstant {

    private JMathConstant() {
    }

    // ZERO, 1/2 AND ONE
    public static final BigDecimal ZERO   = new 
BigDecimal("0.0");
    public static final BigDecimal LANDAUS   = new 
BigDecimal("0.5");
    public static final BigDecimal ONE    = new 
BigDecimal("1.0");
    public static final BigDecimal LEGENDRE   =new 
BigDecimal("1.0");


    // SILVER AND GOLD
    public static final BigDecimal ARCHIMEDES_RATIO   = new 
BigDecimal("3.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127372458700660631558817488152092096282925409171536436789259036001133053054882046652138414695194151160943305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912983367336244065664308602139494639522473719070217986094370277053921717629317675238467481846766940513200056812714526356082778577134275778960917363717872146844090122495343014654958537105079227968925892354201995611212902196086403441815981362977477130996051870721134998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001! 


927876611
1959092164201989");
    public static final BigDecimal UNKNOWN_NAME   = new 
BigDecimal("2.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127372458700660631558817488152092096282925409171536436789259036001133053054882046652138414695194151160943305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912983367336244065664308602139494639522473719070217986094370277053921717629317675238467481846766940513200056812714526356082778577134275778960917363717872146844090122495343014654958537105079227968925892354201995611212902196086403441815981362977477130996051870721134998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001! 


927876611
1959092164201989");
    public static final BigDecimal SILVER_RATIO   = new 
BigDecimal("2.4142135623730950488");
    public static final BigDecimal PYTHAGORAS = new 
BigDecimal("1.4142135623730950488");
    public static final BigDecimal GOLDEN_RATIO   = new 

Re: RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com

[Joe Wang]

Thanks Lance!

On 10/26/18, 12:27 PM, Lance Andersen wrote:

looks OK Joe

On Oct 26, 2018, at 3:24 PM, Joe Wang > wrote:


Hi,

Looks like schematron.com  is gone. Tested 
since the issue was reported 3 days ago, each time got a database 
connection error. Schematron became an ISO standard later after the 
JAXP specification and this packageinfo page was written, so 
replacing the link to schematron.com  with a 
pointer to the ISO page. There's no landing page on iso.org 
, the link is a direct download of the standard.


Please review:

diff --git 
a/src/java.xml/share/classes/javax/xml/validation/package-info.java 
b/src/java.xml/share/classes/javax/xml/validation/package-info.java

--- a/src/java.xml/share/classes/javax/xml/validation/package-info.java
+++ b/src/java.xml/share/classes/javax/xml/validation/package-info.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All 
rights reserved.
+ * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All 
rights reserved.

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
@@ -53,13 +53,13 @@
 * and an http://www.iso.org;>ISO (International 
Organization

 * for Standardization) standard.
 * 
- * href="http://www.schematron.com/;>Schematron -
+ * href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c055982_ISO_IEC_19757-3_2016.zip;>Schematron 
-
 * a rules-based XML schema language. Whereas DTD, WXS, and 
RNG are designed
 * to express the structure of a content model, Schematron is 
designed to
 * enforce individual rules that are difficult or impossible 
to express
 * with other schema languages. Schematron is intended to 
supplement a
 * schema written in structural schema language such as the 
aforementioned.

- * Schematron is in the process of becoming an ISO standard.
+ * Schematron is href="http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html;>an 
ISO standard.

 * 
 * 
 * 


Thanks,
Joe







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: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

[Brian Burkhalter]

Hi Roger,

> On Oct 25, 2018, at 7:15 AM, Roger Riggs  wrote:
> 
> The FIS skipping past of end of file is puzzling.

Quite so.

> If the  'were beyond EOF' was considering the possibility that the file was 
> being
> extended concurrently with the skip operation then it would not be random,
> just a normal writer/reader race.  The return value from skip would be 
> accurate
> and still usable for skipNBytes.
> 
> If the spec for skipNBytes describes its behavior in terms of the normal 
> behaviors
> of skip(n) and read(n) then it will not making promises it can't keep 
> regardless of the subclass behavior.

That sounds like a good idea.

> FIS also says it can do negative seeks which seems in conflict with 
> InputStream.
> The FIS.skip(-n) behavior raises the question about whether 
> InputStream.skipNBytes should
> allow -n?

Actually I think the specification [1] is inconsistent. On the one hand it 
states "If n is negative, the method will try to skip backwards.” and on the 
other “Throws: IOException 

 - if n is negative ….”. It’s the throws clause that appears inaccurate, at 
least on macOS. Output of program below [2] is

Position 0
Skipped 1024 / 1024
Position 1024
Skipped -512 / -512
Position 512

This is not actually in conflict with InputStream [3] which states "If n is 
negative, the skip method for class InputStream always returns 0, and no bytes 
are skipped. Subclasses may handle the negative value differently.”

Ugly stuff.

Thanks,

Brian

[1] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/FileInputStream.html#skip(long)
 

[2] FISTest

import java.io.FileInputStream;
import java.nio.channels.FileChannel;

public class FISTest {
public static void main(String[] args) throws Exception {
FileInputStream fis  = new FileInputStream(args[0]);
FileChannel fc = fis.getChannel();
System.out.format("Position %d%n", fc.position());
System.out.format("Skipped %d / %d%n", fis.skip(1024), 1024);
System.out.format("Position %d%n", fc.position());
System.out.format("Skipped %d / %d%n", fis.skip(-512), -512);
System.out.format("Position %d%n", fc.position());
fis.close();
}
}

[3] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/InputStream.html#skip(long)
 

RE: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions

[Langer, Christoph]

Hi Andrew,

you might have a point here. I'll revisit that.

Thanks
Christoph

> -Original Message-
> From: Andrew Luo 
> Sent: Freitag, 26. Oktober 2018 20:43
> To: Langer, Christoph ; core-libs-dev  d...@openjdk.java.net>; nio-dev ; Xueming
> Shen 
> Cc: Schmelter, Ralf 
> Subject: RE: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File
> Permissions
> 
> I'm not a committer/reviewer but noticed something:
> 
> In ZipUtils.java:
> 
> private static final Map> permCache =
> new WeakHashMap<>();
> 
> This is static, and is concurrently modified, so will it cause issues if 
> multiple
> threads are operating on ZIP filesystems (even if they are different
> objects/ZIP files)?
> 
> Thanks,
> 
> -Andrew
> 
> -Original Message-
> From: core-libs-dev  On Behalf
> Of Langer, Christoph
> Sent: Friday, October 26, 2018 8:13 AM
> To: core-libs-dev ; nio-dev  d...@openjdk.java.net>; Xueming Shen 
> Cc: Schmelter, Ralf 
> Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions
> 
> Hi,
> 
> please review this enhancement of jdk.nio.zipfs to support Posix file
> permissions.
> 
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213031
> 
> I had already posted this change as part of a larger fix for "6194856: Zip 
> Files
> lose ALL ownership and permissions of the files" [1]. With the original
> proposal I was also addressing the java.util.zip API and the jar tool. 
> However,
> I've decided to split this endeavor into 2 parts. While I still want to 
> follow up
> on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in 
> first.
> Both places don't have dependencies to each other and since zipfs does not
> change an external API, I guess the bar here is lower. Maybe it is even a
> candidate for down-porting to jdk11u in the future.
> 
> After my fix, zipfs will support the PosixFileAttributeView. Posix file
> attributes can't be fully supported since owner and group are not handled in
> zip files. So methods supposed to get these attributes will return an
> UnsupportedOperationException. But the posix permissions will now be
> correctly handled, that is stored into and read from the zip file.
> 
> @Sherman:
> Following suggestions from your review, I removed the test with the binary
> zip file. I initially thought it is a good idea to test on a well-known file.
> However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip
> file and reading it again so I guess test coverage is quite complete here.
> Furthermore, I made some public declarations in ZipUtils package private
> which should suffice.
> I also tried to address your performance concerns with permsToFlags and
> permsFromFlags. In permsToFlags I will now simply iterate to the set of
> permissions and add the flags to the return value. It's probably more
> performant than the streaming approach and doesn't look much worse in the
> code. In permsFromFlags I added a cache of permission sets which should
> avoid constant calls to the streaming. However, as the return value needs to
> be mutable, I have to clone the cached permissions. Maybe it would have
> the same or even better performance if we iteratively fill a new set of
> permissions each time permsToFlags gets called. What do you think?
> 
> Do we need a CSR for this patch?
> 
> Thanks & Best regards
> Christoph
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
> October/055971.html

Re: JMathConstant submission for upcoming JDK

[Hohensee, Paul]

Redirecting to core-libs-dev. I filed 
https://bugs.openjdk.java.net/browse/JDK-8213045.

Paul

On 10/26/18, 10:50 AM, "jdk-dev on behalf of Hohensee, Paul" 
 wrote:

This would go to core-libs-dev, and would be a spec change since it adds a 
class. The concept could be expanded to BigInteger, Long, Integer, etc. Instead 
of adding a class, one could add these constants directly to BigDecimal (and 
the others), but that would also be a spec change since it adds public members.

You should file a JBS bug. If you don't have access to JBS, I'd be happy to 
file it for you.

Thanks,

Paul

On 10/26/18, 9:41 AM, "jdk-dev on behalf of rob...@liguorisoftware.com" 
 
wrote:

Hi Chris,

I wrote this simple utility class you may want to use in an upcoming 
version of the JDK.  Btw, I'm the author of the Java Pocket Guide. :)

Or is there a better place I can submit simple code like this for the 
JDK?

Thanks, Robert

import java.math.BigDecimal;

public class JMathConstant {

 private JMathConstant() {
 }

 // ZERO, 1/2 AND ONE
 public static final BigDecimal ZERO   = new 
BigDecimal("0.0");
 public static final BigDecimal LANDAUS= new 
BigDecimal("0.5");
 public static final BigDecimal ONE= new 
BigDecimal("1.0");
 public static final BigDecimal LEGENDRE   = new 
BigDecimal("1.0");

 // SILVER AND GOLD
 public static final BigDecimal ARCHIMEDES_RATIO   = new 

BigDecimal("3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019
 27876611
1959092164201989");
 public static final BigDecimal UNKNOWN_NAME   = new 

BigDecimal("2.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019
 27876611
1959092164201989");
 public static final BigDecimal SILVER_RATIO   = new 
BigDecimal("2.4142135623730950488");
 public static final BigDecimal PYTHAGORAS = new 
BigDecimal("1.4142135623730950488");
 public static final BigDecimal GOLDEN_RATIO   = new 

BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890");
 public static final BigDecimal INVERSE_GOLDEN_RATIO   = new 

BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890");

 // ADDITIONAL RATIO CONSTANTS
 public static final BigDecimal FEIGENBAUMS_RATIO_1 = new 
BigDecimal("4.66920160910299067185320382046620161");
 public static final BigDecimal FEIGENBAUMS_RATIO_2 = new 
BigDecimal("2.50290787509589282228390287321821578");

 // OTHERS
 public static final BigDecimal MEISSEL_MERTENS= new 

Re: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f

[naoto . sato]

+1

Naoto

On 10/26/18 12:38 PM, Martin Buchholz wrote:

Looks good to me.

On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil 
wrote:


Hi all,
Please review the latest TZDATA integration (tzdata2018f) into JDK12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8213016
Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/

All the TimeZone related tests are passed after integration.

Note:
The used tzdata files are from the rearguard version of the tzdata2018f
release with the patch applied given by the IANA maintainers[1].
This is done to avoid the value "25:00" from the Japanese ZoneRule. But,
as proposed by Stephen[2], a fix from JDK side is also required which will
be tracked via a new bug [3].

[1] https://mm.icann.org/pipermail/tz/2018-October/027032.html
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
October/056167.html
[3] https://bugs.openjdk.java.net/browse/JDK-8212970


Regards,
Ramanand.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Alan Snyder]

I noticed the following statement in the JEP:

  In this latter case, the tool can either create a native package from a 
previously created application image, or it can create a native package 
directly.

I cannot tell from the command summary whether this option has been implemented 
or not.

Without this feature, the ability to create a signed DMG is not very useful, 
except in the case where the tool creates exactly the right application image.

  Alan

Re: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f

[Martin Buchholz]

Looks good to me.

On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil 
wrote:

> Hi all,
> Please review the latest TZDATA integration (tzdata2018f) into JDK12.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213016
> Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/
>
> All the TimeZone related tests are passed after integration.
>
> Note:
> The used tzdata files are from the rearguard version of the tzdata2018f
> release with the patch applied given by the IANA maintainers[1].
> This is done to avoid the value "25:00" from the Japanese ZoneRule. But,
> as proposed by Stephen[2], a fix from JDK side is also required which will
> be tracked via a new bug [3].
>
> [1] https://mm.icann.org/pipermail/tz/2018-October/027032.html
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
> October/056167.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8212970
>
>
> Regards,
> Ramanand.
>

Re: RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com

[Lance Andersen]

looks OK Joe

> On Oct 26, 2018, at 3:24 PM, Joe Wang  wrote:
> 
> Hi,
> 
> Looks like schematron.com is gone. Tested since the issue was reported 3 days 
> ago, each time got a database connection error. Schematron became an ISO 
> standard later after the JAXP specification and this packageinfo page was 
> written, so replacing the link to schematron.com with a pointer to the ISO 
> page. There's no landing page on iso.org, the link is a direct download of 
> the standard.
> 
> Please review:
> 
> diff --git 
> a/src/java.xml/share/classes/javax/xml/validation/package-info.java 
> b/src/java.xml/share/classes/javax/xml/validation/package-info.java
> --- a/src/java.xml/share/classes/javax/xml/validation/package-info.java
> +++ b/src/java.xml/share/classes/javax/xml/validation/package-info.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights 
> reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -53,13 +53,13 @@
>  * and an http://www.iso.org;>ISO (International Organization
>  * for Standardization) standard.
>  * 
> - * http://www.schematron.com/;>Schematron -
> + *  href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c055982_ISO_IEC_19757-3_2016.zip;>Schematron
>  -
>  * a rules-based XML schema language. Whereas DTD, WXS, and RNG are 
> designed
>  * to express the structure of a content model, Schematron is 
> designed to
>  * enforce individual rules that are difficult or impossible to 
> express
>  * with other schema languages. Schematron is intended to supplement a
>  * schema written in structural schema language such as the 
> aforementioned.
> - * Schematron is in the process of becoming an ISO standard.
> + * Schematron is  href="http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html;>an 
> ISO standard.
>  * 
>  * 
>  * 
> 
> 
> Thanks,
> Joe
> 
> 
> 

 
  

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

RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com

[Joe Wang]

Hi,

Looks like schematron.com is gone. Tested since the issue was reported 3 
days ago, each time got a database connection error. Schematron became 
an ISO standard later after the JAXP specification and this packageinfo 
page was written, so replacing the link to schematron.com with a pointer 
to the ISO page. There's no landing page on iso.org, the link is a 
direct download of the standard.


Please review:

diff --git 
a/src/java.xml/share/classes/javax/xml/validation/package-info.java 
b/src/java.xml/share/classes/javax/xml/validation/package-info.java

--- a/src/java.xml/share/classes/javax/xml/validation/package-info.java
+++ b/src/java.xml/share/classes/javax/xml/validation/package-info.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -53,13 +53,13 @@
  * and an http://www.iso.org;>ISO (International 
Organization

  * for Standardization) standard.
  * 
- * href="http://www.schematron.com/;>Schematron -
+ * href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c055982_ISO_IEC_19757-3_2016.zip;>Schematron 
-
  * a rules-based XML schema language. Whereas DTD, WXS, and 
RNG are designed
  * to express the structure of a content model, Schematron is 
designed to
  * enforce individual rules that are difficult or impossible 
to express
  * with other schema languages. Schematron is intended to 
supplement a
  * schema written in structural schema language such as the 
aforementioned.

- * Schematron is in the process of becoming an ISO standard.
+ * Schematron is href="http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html;>an 
ISO standard.

  * 
  * 
  * 


Thanks,
Joe

Fwd: Re: JMathConstant submission for upcoming JDK

[Roger Riggs]

[Sorry for the repeat, this time to ensure Robert sees the question]

Hi Robert,

No doubt a useful list of constants for some developers.

Can you elaborate on why you think these constants should be in the JDK
and why they are the right constants especially as related to precision 
and length.

I would expect for some applications these would be more precise than they
need and hurt performance and for other applications they would not have 
enough

precision.

Thanks, Roger

On 10/26/18 12:39 PM, rob...@liguorisoftware.com wrote:

Hi Chris,

I wrote this simple utility class you may want to use in an upcoming 
version of the JDK.  Btw, I'm the author of the Java Pocket Guide.:)


Or is there a better place I can submit simple code like this for the JDK?

Thanks, Robert

import java.math.BigDecimal;

public class JMathConstant {

    private JMathConstant() {
    }

    // ZERO, 1/2 AND ONE
    public static final BigDecimal ZERO   = new 
BigDecimal("0.0");
    public static final BigDecimal LANDAUS   = new 
BigDecimal("0.5");
    public static final BigDecimal ONE    = new 
BigDecimal("1.0");
    public static final BigDecimal LEGENDRE   =new 
BigDecimal("1.0");


    // SILVER AND GOLD
    public static final BigDecimal ARCHIMEDES_RATIO   = new 
BigDecimal("3.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127372458700660631558817488152092096282925409171536436789259036001133053054882046652138414695194151160943305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912983367336244065664308602139494639522473719070217986094370277053921717629317675238467481846766940513200056812714526356082778577134275778960917363717872146844090122495343014654958537105079227968925892354201995611212902196086403441815981362977477130996051870721134998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001!

927876611
1959092164201989");
    public static final BigDecimal UNKNOWN_NAME   = new 
BigDecimal("2.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127372458700660631558817488152092096282925409171536436789259036001133053054882046652138414695194151160943305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912983367336244065664308602139494639522473719070217986094370277053921717629317675238467481846766940513200056812714526356082778577134275778960917363717872146844090122495343014654958537105079227968925892354201995611212902196086403441815981362977477130996051870721134998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001!

927876611
1959092164201989");
    public static final BigDecimal SILVER_RATIO   = new 
BigDecimal("2.4142135623730950488");
    public static final BigDecimal PYTHAGORAS = new 
BigDecimal("1.4142135623730950488");
    public static final BigDecimal GOLDEN_RATIO   = new 
BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890");
    public static final BigDecimal INVERSE_GOLDEN_RATIO   = new 
BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890");


    // ADDITIONAL RATIO CONSTANTS
    public static final BigDecimal FEIGENBAUMS_RATIO_1 = new 
BigDecimal("4.66920160910299067185320382046620161");
    public static final BigDecimal FEIGENBAUMS_RATIO_2 = new 
BigDecimal("2.50290787509589282228390287321821578");


    // OTHERS
    public static final BigDecimal MEISSEL_MERTENS    = new 
BigDecimal("0.26149721284764278375542683860869585");
    public static final BigDecimal BERNSTEINS = new 
BigDecimal("0.28016949902386913303");
    public static final BigDecimal GAUSS_KKUZMIN_WIRSING  = new 
BigDecimal("0.30366300289873265859744812190155623");
    public static final BigDecimal HAFNER_SARNAK_MCCURLEY = new 
BigDecimal("0.35323637185499598454351655043268201");
    public static final BigDecimal OMEGA  = new 
BigDecimal("0.567143290409783872686622103");
    public static final BigDecimal EULER_MASCHERONI   = new 
BigDecimal("0.57721");
    public static final BigDecimal GOLOMB_DICKMAN = new 

RE: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions

[Andrew Luo]

I'm not a committer/reviewer but noticed something:

In ZipUtils.java:

private static final Map> permCache = new 
WeakHashMap<>();

This is static, and is concurrently modified, so will it cause issues if 
multiple threads are operating on ZIP filesystems (even if they are different 
objects/ZIP files)?

Thanks,

-Andrew

-Original Message-
From: core-libs-dev  On Behalf Of 
Langer, Christoph
Sent: Friday, October 26, 2018 8:13 AM
To: core-libs-dev ; nio-dev 
; Xueming Shen 
Cc: Schmelter, Ralf 
Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions

Hi,

please review this enhancement of jdk.nio.zipfs to support Posix file 
permissions.

Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8213031

I had already posted this change as part of a larger fix for "6194856: Zip 
Files lose ALL ownership and permissions of the files" [1]. With the original 
proposal I was also addressing the java.util.zip API and the jar tool. However, 
I've decided to split this endeavor into 2 parts. While I still want to follow 
up on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in 
first. Both places don't have dependencies to each other and since zipfs does 
not change an external API, I guess the bar here is lower. Maybe it is even a 
candidate for down-porting to jdk11u in the future.

After my fix, zipfs will support the PosixFileAttributeView. Posix file 
attributes can't be fully supported since owner and group are not handled in 
zip files. So methods supposed to get these attributes will return an 
UnsupportedOperationException. But the posix permissions will now be correctly 
handled, that is stored into and read from the zip file.

@Sherman:
Following suggestions from your review, I removed the test with the binary zip 
file. I initially thought it is a good idea to test on a well-known file. 
However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip file 
and reading it again so I guess test coverage is quite complete here.
Furthermore, I made some public declarations in ZipUtils package private which 
should suffice.
I also tried to address your performance concerns with permsToFlags and 
permsFromFlags. In permsToFlags I will now simply iterate to the set of 
permissions and add the flags to the return value. It's probably more 
performant than the streaming approach and doesn't look much worse in the code. 
In permsFromFlags I added a cache of permission sets which should avoid 
constant calls to the streaming. However, as the return value needs to be 
mutable, I have to clone the cached permissions. Maybe it would have the same 
or even better performance if we iteratively fill a new set of permissions each 
time permsToFlags gets called. What do you think?

Do we need a CSR for this patch?

Thanks & Best regards
Christoph

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055971.html

RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f

[Ramanand Patil]

Hi all,
Please review the latest TZDATA integration (tzdata2018f) into JDK12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8213016
Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/

All the TimeZone related tests are passed after integration.

Note:
The used tzdata files are from the rearguard version of the tzdata2018f release 
with the patch applied given by the IANA maintainers[1].
This is done to avoid the value "25:00" from the Japanese ZoneRule. But, as 
proposed by Stephen[2], a fix from JDK side is also required which will be 
tracked via a new bug [3].

[1] https://mm.icann.org/pipermail/tz/2018-October/027032.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056167.html
[3] https://bugs.openjdk.java.net/browse/JDK-8212970


Regards,
Ramanand.

Re: JMathConstant submission for upcoming JDK

[Roger Riggs]

Hi Robert,

No doubt a useful list of constants for some developers.

Can you elaborate on why you think these constants should be in the JDK
and why they are the right constants especially as related to precision 
and length.

I would expect for some applications these would be more precise than they
need and hurt performance and for other applications they would not have 
enough

precision.

Thanks, Roger

On 10/26/18 12:39 PM, rob...@liguorisoftware.com wrote:

Hi Chris,

I wrote this simple utility class you may want to use in an upcoming 
version of the JDK.  Btw, I'm the author of the Java Pocket Guide. :)


Or is there a better place I can submit simple code like this for the 
JDK?


Thanks, Robert

import java.math.BigDecimal;

public class JMathConstant {

    private JMathConstant() {
    }

    // ZERO, 1/2 AND ONE
    public static final BigDecimal ZERO   = new 
BigDecimal("0.0");
    public static final BigDecimal LANDAUS    = new 
BigDecimal("0.5");
    public static final BigDecimal ONE    = new 
BigDecimal("1.0");
    public static final BigDecimal LEGENDRE   = new 
BigDecimal("1.0");


    // SILVER AND GOLD
    public static final BigDecimal ARCHIMEDES_RATIO   = new 
BigDecimal("3.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127372458700660631558817488152092096282925409171536436789259036001133053054882046652138414695194151160943305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912983367336244065664308602139494639522473719070217986094370277053921717629317675238467481846766940513200056812714526356082778577134275778960917363717872146844090122495343014654958537105079227968925892354201995611212902196086403441815981362977477130996051870721134998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001!

927876611
1959092164201989");
    public static final BigDecimal UNKNOWN_NAME   = new 
BigDecimal("2.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127372458700660631558817488152092096282925409171536436789259036001133053054882046652138414695194151160943305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912983367336244065664308602139494639522473719070217986094370277053921717629317675238467481846766940513200056812714526356082778577134275778960917363717872146844090122495343014654958537105079227968925892354201995611212902196086403441815981362977477130996051870721134998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001!

927876611
1959092164201989");
    public static final BigDecimal SILVER_RATIO   = new 
BigDecimal("2.4142135623730950488");
    public static final BigDecimal PYTHAGORAS = new 
BigDecimal("1.4142135623730950488");
    public static final BigDecimal GOLDEN_RATIO   = new 
BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890");
    public static final BigDecimal INVERSE_GOLDEN_RATIO   = new 
BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890");


    // ADDITIONAL RATIO CONSTANTS
    public static final BigDecimal FEIGENBAUMS_RATIO_1 = new 
BigDecimal("4.66920160910299067185320382046620161");
    public static final BigDecimal FEIGENBAUMS_RATIO_2 = new 
BigDecimal("2.50290787509589282228390287321821578");


    // OTHERS
    public static final BigDecimal MEISSEL_MERTENS    = new 
BigDecimal("0.26149721284764278375542683860869585");
    public static final BigDecimal BERNSTEINS = new 
BigDecimal("0.28016949902386913303");
    public static final BigDecimal GAUSS_KKUZMIN_WIRSING  = new 
BigDecimal("0.30366300289873265859744812190155623");
    public static final BigDecimal HAFNER_SARNAK_MCCURLEY = new 
BigDecimal("0.35323637185499598454351655043268201");
    public static final BigDecimal OMEGA  = new 
BigDecimal("0.567143290409783872686622103");
    public static final BigDecimal EULER_MASCHERONI   = new 
BigDecimal("0.57721");
    public static final BigDecimal GOLOMB_DICKMAN = new 
BigDecimal("0.6243299885435508709929363831083724");
    public static final 

Re: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken

[Alan Bateman]

On 26/10/2018 16:46, Mandy Chung wrote:
jsr166 depends on the internal Unsafe xxxObject methods and is 
currently broken. Since the rename is motivated by Valhalla, we agree 
to keep the internal Unsafe xxxObject methods as deprecated in the jdk 
repo.


Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00

This looks okay to me.

-Alan

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

[Rob McKenna]

On 26/10/18 16:14, Daniel Fuchs wrote:
> Hi Rob,
> 
> Looks better to me know. Though I admit that:
> 
> 53 this.replies = new LinkedBlockingQueue<>(8 *
> replyQueueCapacity / 10);
> 
> is still a bit mystifying... Why not use the full
> replyQueueCapacity provided? That doesn't look
> strictly equivalent to the highWatermark logic that
> you have removed.

Pavel may be able to shed more light on this part. (as it was his
suggested fix originally I believe)

It looks to me like the intention is to mimic the pre-fix behaviour,
which only allowed the queue to fill to 80% of its capacity before
pausing. I agree though, it doesn't really make sense to keep that. I'll
remove it.

> 
> On 25/10/2018 21:53, Rob McKenna wrote:
> > I'm planning to follow up on the test side of things with a separate
> > bug. I think the technique used in some of the recent SQE LDAP tests
> > might be applicable.
> 
> It will be good to have a test and try to shake the implementation
> a bit with some repeating jobs in our test system to get some
> confidence that we've not harmed anything else.

You've convinced me to wait until we can get one together. I'll hold off
on the push until that point. jdk-tier1-4 pass, but that may not be
saying much unfortunately.

-Rob

> 
> I admit that my only acquaintance to the JNDI/LDAP code of the JDK
> has been through reviews, so I'd probably only spot the obvious.
> 
> best regards,
> 
> -- daniel
> 
> 
> On 26/10/2018 15:55, Rob McKenna wrote:
> > Thanks again Daniel,
> > 
> > http://cr.openjdk.java.net/~robm/8139965/webrev.04/
> > 
> >  -Rob
> > 
> 

Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken

[Mandy Chung]

jsr166 depends on the internal Unsafe xxxObject methods and is currently 
broken. Since the rename is motivated by Valhalla, we agree to keep the 
internal Unsafe xxxObject methods as deprecated in the jdk repo.


Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00

Mandy

Proposal: Stream.iterateWhile(T seed, Function> mapper)

[Tomasz Linkowski]

Hi,

Please, consider adding a new static method to the `Stream` interface
(names TBD):

static  Stream iterateWhile(
T seed, Function>
mapper
);


== OVERVIEW ==

+ non-null equivalent of `Stream.iterate(seed, hasNext, next)` [1]
+ `mapper` like in `Optional.flatMap(mapper)` [2]
+ shift from two operations to one operation, like in:
- `Iterator.hasNext/next` => `Spliterator.tryAdvance`
- pattern matching (test/bind)
+ intent: "nudge towards writing clearer code" (Brian Goetz about LVTI [3])
+ useful for `Optional`-based APIs
+ trivial implementation


== JUSTIFICATION ==

`Stream.iterate(seed, hasNext, next)` is great for nullable-return-based
APIs. Example: returning a chain of `Throwable` causes:

Stream.iterate(throwable, Objects::nonNull, Throwable::getCause)

For `Optional`-based APIs, using `Stream.iterate` becomes cumbersome.
Example (assume `Throwable.findCause()` returns `Optional`):

Stream.iterate(throwable, Objects::nonNull, t ->
t.findCause().orElse(null))

Using the proposed method, the above can become much clearer:

Stream.iterateWhile(throwable, Throwable::findCause)

This is just one example - I can provide more if needed.


== IMPLEMENTATION ==

Preferred implementation:

iterateWhile(seed, mapper) -> Stream.iterate(
seed, Objects::nonNull,
t ->  mapper.apply(t).orElse(null)
);

Equivalent `Optional`-based implementation:

iterateWhile(seed, mapper) -> Stream.iterate(
Optional.ofNullable(seed), Optional::isPresent,
optional ->  optional.flatMap(mapper)
).map(Optional::get);

Note that both implementations assume that `null` seed yields an empty
`Stream`.


== NAMING ==

Name `iterate` cannot be safely overloaded because of
`Stream.iterate(UnaryOperator)` so another name needs to be used. I
proposed `iterateWhile` inspired by `takeWhile` but maybe it's a wrong
trail (`takeWhile` takes a `Predicate`). Other names that come to my mind:
`iterateWhilePresent`, `iterateOptional`, `iterateNonNull`.


[1]
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/stream/Stream.html#iterate(T,java.util.function.Predicate,java.util.function.UnaryOperator)
[2]
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Optional.html#flatMap(java.util.function.Function)
[3]
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-October/000826.html

-- 
Regards,
Tomasz Linkowski

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

[Daniel Fuchs]

Hi Rob,

Looks better to me know. Though I admit that:

53 this.replies = new LinkedBlockingQueue<>(8 * 
replyQueueCapacity / 10);


is still a bit mystifying... Why not use the full
replyQueueCapacity provided? That doesn't look
strictly equivalent to the highWatermark logic that
you have removed.

On 25/10/2018 21:53, Rob McKenna wrote:

I'm planning to follow up on the test side of things with a separate
bug. I think the technique used in some of the recent SQE LDAP tests
might be applicable.


It will be good to have a test and try to shake the implementation
a bit with some repeating jobs in our test system to get some
confidence that we've not harmed anything else.

I admit that my only acquaintance to the JNDI/LDAP code of the JDK
has been through reviews, so I'd probably only spot the obvious.

best regards,

-- daniel


On 26/10/2018 15:55, Rob McKenna wrote:

Thanks again Daniel,

http://cr.openjdk.java.net/~robm/8139965/webrev.04/

 -Rob

RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions

[Langer, Christoph]

Hi,

please review this enhancement of jdk.nio.zipfs to support Posix file 
permissions.

Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8213031

I had already posted this change as part of a larger fix for "6194856: Zip 
Files lose ALL ownership and permissions of the files" [1]. With the original 
proposal I was also addressing the java.util.zip API and the jar tool. However, 
I've decided to split this endeavor into 2 parts. While I still want to follow 
up on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in 
first. Both places don't have dependencies to each other and since zipfs does 
not change an external API, I guess the bar here is lower. Maybe it is even a 
candidate for down-porting to jdk11u in the future.

After my fix, zipfs will support the PosixFileAttributeView. Posix file 
attributes can't be fully supported since owner and group are not handled in 
zip files. So methods supposed to get these attributes will return an 
UnsupportedOperationException. But the posix permissions will now be correctly 
handled, that is stored into and read from the zip file.

@Sherman:
Following suggestions from your review, I removed the test with the binary zip 
file. I initially thought it is a good idea to test on a well-known file. 
However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip file 
and reading it again so I guess test coverage is quite complete here.
Furthermore, I made some public declarations in ZipUtils package private which 
should suffice.
I also tried to address your performance concerns with permsToFlags and 
permsFromFlags. In permsToFlags I will now simply iterate to the set of 
permissions and add the flags to the return value. It's probably more 
performant than the streaming approach and doesn't look much worse in the code. 
In permsFromFlags I added a cache of permission sets which should avoid 
constant calls to the streaming. However, as the return value needs to be 
mutable, I have to clone the cached permissions. Maybe it would have the same 
or even better performance if we iteratively fill a new set of permissions each 
time permsToFlags gets called. What do you think?

Do we need a CSR for this patch?

Thanks & Best regards
Christoph

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055971.html

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

[Rob McKenna]

Yes, thanks a lot Alan.

Vyom and Martin both had some very helpful feedback so I'm hoping to
hear from both!

-Rob

On 26/10/18 15:34, Alan Bateman wrote:
> On 25/10/2018 17:34, Rob McKenna wrote:
> > This recently received CSR approval, so it seems like a good time to pick
> > the codereview up again:
> > 
> > http://cr.openjdk.java.net/~robm/8160768/webrev.08/
> > 
> I went through a number of iterations with Rob on the API/javadoc so I think
> the API parts in webrev.08 are good. I have not had time to go through the
> implementation and test changes so hopefully that someone else has cycles to
> help on that.
> 
> -Alan
> 

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

[Rob McKenna]

Thanks again Daniel,

http://cr.openjdk.java.net/~robm/8139965/webrev.04/

-Rob

On 26/10/18 09:54, Daniel Fuchs wrote:
> Hi Rob,
> 
> Now I'm concerned about this method:
> 
>   71 synchronized boolean addReplyBer(BerDecoder ber) {
>   72 // check the closed boolean value here as we don't want
> anything
>   73 // to be added to the queue after close() has been called.
>   74 if (cancelled || closed) {
>   75 return false;
>   76 }
>   77
>   78 // Add a new reply to the queue of unprocessed replies.
>   79 try {
>   80 replies.put(ber);
>   81 } catch (InterruptedException e) {
>   82 // ignore
>   83 }
>   84
>   85 // peek at the BER buffer to check if it is a SearchResultDone
> PDU
>   86 try {
>   87 ber.parseSeq(null);
>   88 ber.parseInt();
>   89 completed = (ber.peekByte() == LdapClient.LDAP_REP_RESULT);
>   90 } catch (IOException e) {
>   91 // ignore
>   92 }
>   93 ber.reset();
>   94 return pauseAfterReceipt;
>   95 }
> 
> getReplyBer() is not synchronized, so AFAICS there is a
> chance that line 93 executes after another thread as got
> hold of the `ber` object.
> 
> Is that an issue? Should the `ber` object be added to
> the reply queue only after it's been reset?
> 
> best regards,
> 
> -- daniel
> 
> On 25/10/2018 21:53, Rob McKenna wrote:
> > Thanks Daniel:
> > 
> > http://cr.openjdk.java.net/~robm/8139965/webrev.03/
> > 
> > I'm planning to follow up on the test side of things with a separate
> > bug. I think the technique used in some of the recent SQE LDAP tests
> > might be applicable.
> > 
> >  -Rob
> > 
> > On 05/09/18 09:53, Daniel Fuchs wrote:
> > > Hi Rob,
> > > 
> > > That looks better but I believe that:
> > > 
> > > 1. closed should be volatile since it's read from outside
> > > synchronized block
> > > 
> > > 2. it seems there might be a race where the last response
> > > received could be dropped, if the connection is closed
> > > just after it's been pulled from the queue.
> > > 
> > > So I would suggest exchanging:
> > > 
> > >   115 if (isClosed()) {
> > >   116 return null;
> > >   117 }
> > >   118
> > >   119 return result;
> > > 
> > > with:
> > > 
> > >   return result == EOF ? null : result;
> > > 
> > > best regards,
> > > 
> > > -- daniel
> > > 
> > > On 05/09/2018 02:05, Rob McKenna wrote:
> > > > Thanks for the reviews folks.
> > > > 
> > > > I believe the following captures your recommended changes:
> > > > 
> > > > http://cr.openjdk.java.net/~robm/8139965/webrev.02/
> > > > 
> > > > W.r.t. testing I think this area has been difficult to test
> > > > traditionally. I'll have a dig through the existing testbase (and I'll
> > > > get back to you) to see if there's anything similar but afaik most tests
> > > > simply mimic a bindable dummy ldap server.
> > > > 
> > > > Vyom, are you aware of any more rigorous tests / ldap test frameworks?
> > > > 
> > > >   -Rob
> > > > 
> > > > On 04/09/18 10:22, Daniel Fuchs wrote:
> > > > > Hi Rob,
> > > > > 
> > > > > I concur with Chris.
> > > > > completed needs to be volatile and close() needs to
> > > > > set a flag and use offer like cancel().
> > > > > 
> > > > > The condition for testing for closed then becomes
> > > > > that the flag is set and the queue is empty or has EOF
> > > > > as its head.
> > > > > 
> > > > > Is there any way this could be tested by a regression
> > > > > test?
> > > > > 
> > > > > best regards,
> > > > > 
> > > > > -- daniel
> > > > > 
> > > > > On 04/09/2018 10:00, Chris Hegarty wrote:
> > > > > > Rob,
> > > > > > 
> > > > > > > On 3 Sep 2018, at 22:48, Rob McKenna  
> > > > > > > wrote:
> > > > > > > 
> > > > > > > Hi folks,
> > > > > > > 
> > > > > > > I'd like to get a re-review of this change:
> > > > > > > 
> > > > > > > https://bugs.openjdk.java.net/browse/JDK-8139965 
> > > > > > > 
> > > > > > 
> > > > > > This issue is closed as `will not fix`. I presume you will re-open 
> > > > > > it before pushing.
> > > > > > 
> > > > > > > http://cr.openjdk.java.net/~robm/8139965/webrev/ 
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 43 private boolean completed;
> > > > > > Won’t `completed` need to be volatile now? ( since the removal of 
> > > > > > synchronized from hasSearchCompleted )
> > > > > > 
> > > > > > LdapRequest.close puts EOF into the queue, but that is a 
> > > > > > potentially blocking operation ( while holding the lock ). If the 
> > > > > > queue is at capacity, then it will block forever. This model will 
> > > > > > only work if `getReplyBer` is always guaranteed to be running 
> > > > > > concurrently. Is it?
> > > > > > 
> > > > > > Please check the indentation of LdapRequest.java L103 ( 

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

[Alan Bateman]

On 25/10/2018 17:34, Rob McKenna wrote:

This recently received CSR approval, so it seems like a good time to pick
the codereview up again:

http://cr.openjdk.java.net/~robm/8160768/webrev.08/

I went through a number of iterations with Rob on the API/javadoc so I 
think the API parts in webrev.08 are good. I have not had time to go 
through the implementation and test changes so hopefully that someone 
else has cycles to help on that.


-Alan

Re: Exceptions in Iterator.forEachRemaining()

[Martin Buchholz]

Mostly my fault, and even more inconsistent than you say.  I filed
https://bugs.openjdk.java.net/browse/JDK-8213038
(but don't use an iterator after a call to forEachRemaining!)

On Thu, Oct 25, 2018 at 11:55 PM, Zheka Kozlov 
wrote:

> Hi everyone.
>
> I noticed that different Iterator implementations behave differently when
> an Exception is thrown inside a Consumer passed to forEachRemaining():
>
> private static void test(List list) {
> Iterator iterator = list.iterator();
> try {
> iterator.forEachRemaining(i -> {
> if (i == 3) {
> throw new RuntimeException();
> } else {
> System.out.print(i);
> }
> });
> } catch (RuntimeException ex) {
> }
> iterator.forEachRemaining(System.out::print);
> }
>
> public static void main(String... args) throws Throwable {
> test(List.of(1, 2, 3, 4, 5)); // Prints 1245
> System.out.println();
> test(Arrays.asList(1, 2, 3, 4, 5)); // Prints 1245
> System.out.println();
> test(new LinkedList<>(List.of(1, 2, 3, 4, 5))); // Prints 12345 (BAD)
> System.out.println();
> test(new ArrayList<>(List.of(1, 2, 3, 4, 5))); // Prints 1212345 (BAD)
> }
>
> Is this a bug? I think yes because an overridden forEachRemaining() should
> behave the same as the default implementation:
>
> while (hasNext()) {
> action.accept(next());
> }
>
> So, in this case, List.of() and Arrays.asList() are correct while
> LinkedList and ArrayList are not.
>

RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

[Ichiroh Takiguchi]

Hello.

Could you review the fix ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/

I'd like to obtain a sponsor for this issue.


IBM964 charset and IBM29626C charset are required for default charset
on AIX zh_TW and ja_JP locale.
OpenJDK already has IBM964, but it could not be configured for default 
charset.

IBM29626C is new one.
(IBM33722 extends IBM29626C class)

I knew IBM charsets would need to move to somewhere.
The discussion was started by "Adding new IBM extended charsets". [1]
But it's related default charset issue.
Please put them inside of OpenJDK.

About IBM964,
Bhaktavatsal started the discussion [2].
Sherman said that [3]
  the new model (open/make/data/charetmapping), instead of hard-coding 
the map

  into the source code.

This fix only has small sized hard-coded mapping,
IBM964/IBM29626C/IBM33722 refer other charsets conversion table
which are using the new model.
And class file is smaller then before.
Still I used SimpleEUCEncoder class because it's stable.
I think we may re-write it by IBM charsets renewal.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054248.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html
[3] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html

Re: Time-zone database issues

[Stephen Colebourne]

On Fri, 26 Oct 2018 at 08:52, Ramanand Patil  wrote:
> Hi Naoto,
> Thank you for filing the bug. As far as tzdata2018f release is concerned I am 
> going ahead with the integration, with the help of the patch provided here- 
> https://mm.icann.org/pipermail/tz/2018-October/027032.html Which avoids 25:00 
> in rearguard format.
> [ https://bugs.openjdk.java.net/browse/JDK-8213016 ]

Yes the right course of action for now is to use the patch that avoids 25:00.

Thanks Naoto for raising JDK-8212970 to cover the longer term change.

Stephen

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

[Daniel Fuchs]

Hi Rob,

Now I'm concerned about this method:

  71 synchronized boolean addReplyBer(BerDecoder ber) {
  72 // check the closed boolean value here as we don't want 
anything

  73 // to be added to the queue after close() has been called.
  74 if (cancelled || closed) {
  75 return false;
  76 }
  77
  78 // Add a new reply to the queue of unprocessed replies.
  79 try {
  80 replies.put(ber);
  81 } catch (InterruptedException e) {
  82 // ignore
  83 }
  84
  85 // peek at the BER buffer to check if it is a 
SearchResultDone PDU

  86 try {
  87 ber.parseSeq(null);
  88 ber.parseInt();
  89 completed = (ber.peekByte() == 
LdapClient.LDAP_REP_RESULT);

  90 } catch (IOException e) {
  91 // ignore
  92 }
  93 ber.reset();
  94 return pauseAfterReceipt;
  95 }

getReplyBer() is not synchronized, so AFAICS there is a
chance that line 93 executes after another thread as got
hold of the `ber` object.

Is that an issue? Should the `ber` object be added to
the reply queue only after it's been reset?

best regards,

-- daniel

On 25/10/2018 21:53, Rob McKenna wrote:

Thanks Daniel:

http://cr.openjdk.java.net/~robm/8139965/webrev.03/

I'm planning to follow up on the test side of things with a separate
bug. I think the technique used in some of the recent SQE LDAP tests
might be applicable.

 -Rob

On 05/09/18 09:53, Daniel Fuchs wrote:

Hi Rob,

That looks better but I believe that:

1. closed should be volatile since it's read from outside
synchronized block

2. it seems there might be a race where the last response
received could be dropped, if the connection is closed
just after it's been pulled from the queue.

So I would suggest exchanging:

  115 if (isClosed()) {
  116 return null;
  117 }
  118
  119 return result;

with:

  return result == EOF ? null : result;

best regards,

-- daniel

On 05/09/2018 02:05, Rob McKenna wrote:

Thanks for the reviews folks.

I believe the following captures your recommended changes:

http://cr.openjdk.java.net/~robm/8139965/webrev.02/

W.r.t. testing I think this area has been difficult to test
traditionally. I'll have a dig through the existing testbase (and I'll
get back to you) to see if there's anything similar but afaik most tests
simply mimic a bindable dummy ldap server.

Vyom, are you aware of any more rigorous tests / ldap test frameworks?

  -Rob

On 04/09/18 10:22, Daniel Fuchs wrote:

Hi Rob,

I concur with Chris.
completed needs to be volatile and close() needs to
set a flag and use offer like cancel().

The condition for testing for closed then becomes
that the flag is set and the queue is empty or has EOF
as its head.

Is there any way this could be tested by a regression
test?

best regards,

-- daniel

On 04/09/2018 10:00, Chris Hegarty wrote:

Rob,


On 3 Sep 2018, at 22:48, Rob McKenna  wrote:

Hi folks,

I'd like to get a re-review of this change:

https://bugs.openjdk.java.net/browse/JDK-8139965 



This issue is closed as `will not fix`. I presume you will re-open it before 
pushing.


http://cr.openjdk.java.net/~robm/8139965/webrev/ 




43 private boolean completed;
Won’t `completed` need to be volatile now? ( since the removal of synchronized 
from hasSearchCompleted )

LdapRequest.close puts EOF into the queue, but that is a potentially blocking 
operation ( while holding the lock ). If the queue is at capacity, then it will 
block forever. This model will only work if `getReplyBer` is always guaranteed 
to be running concurrently. Is it?

Please check the indentation of LdapRequest.java L103 ( in
the new file ). It appears, in the webrev, that the trailing `}` is
not lined up.

The indentation doesn’t look right here either.
624 if (nparent) {
625 LdapRequest ldr = pendingRequests;
626 while (ldr != null) {
627 ldr.close();
628 ldr = ldr.next;
629 }
630 }
631 }

-Chris

RE: Time-zone database issues

[Ramanand Patil]

Hi Naoto,
Thank you for filing the bug. As far as tzdata2018f release is concerned I am 
going ahead with the integration, with the help of the patch provided here- 
https://mm.icann.org/pipermail/tz/2018-October/027032.html Which avoids 25:00 
in rearguard format.
[ https://bugs.openjdk.java.net/browse/JDK-8213016 ]


Regards,
Ramanand.

> -Original Message-
> From: Naoto Sato
> Sent: Thursday, October 25, 2018 8:48 PM
> To: Stephen Colebourne ; core-libs-dev  d...@openjdk.java.net>
> Subject: Re: Time-zone database issues
> 
> Thanks, Stephen.
> 
> I filed an issue for your suggestion:
> 
> https://bugs.openjdk.java.net/browse/JDK-8212970
> 
> I will need to look into the issue, but so far as I understand, will it be 
> fine to
> modify the offending transition date to the next day for 2018f's immediate
> issue?
> 
> Naoto
> 
> On 10/22/18 3:25 PM, Stephen Colebourne wrote:
> > The IANA time-zone database [1] provides details of how time-zones
> > change over time. The latest release - 2018f - cannot be processed
> > successfully by the current JDK parser [2].  A workaround exists
> > however unlike previous cases of tzdb incompatibility, this time it
> > makes sense for the JDK parser and API to be changed.
> >
> > Problem
> > ---
> > The JDK parser and API make the assumption that a time-zone change can
> > occur at any LocalTime or midnight-end-of-day, ie. from 00:00 to
> > 24:00. Unfortunately, the tzdb source files allow (and now include)
> > rules outside those valid values, in this case a value of 25:00.
> > Specifically, the rule that causes problems says that clocks change at
> > 25:00 on the first Saturday on or after the 8th of September.
> >
> > In the current problematic case, the rule can be rewritten to say that
> > clocks change at 01:00 on the first Sunday on or after the 9th of
> > September. However, there are cases where it is difficult to
> > impossible to rewrite the rule (such as 25:00 on the last Saturday in
> > a month, difficult because it goes into the next month).
> >
> > Proposed solution
> > 
> >
> > Fixing the parser to handle values like 25:00 would be relatively
> > easy. However, these rules are also exposed in the public API of
> > java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has
> > methods `getLocalTime()` and `isMidnightEndOfDay()`. These would need
> > to be deprecated and replaced by a new method `getLocalTimeDuration()`
> > (or some other name) that returns an instance of `Duration`.
> >
> > A user of ThreeTen-Backport [4] has provided a branch to do this, so I
> > know the change to be possible. However, since I have looked at the
> > code I cannot implement the change in OpenJDK (compromised IP). It
> > needs a cleanroom implementation by someone else.
> >
> > Is there agreement on the need for change? Is anyone (Oracle or
> > otherwise) willing to volunteer do the work?
> >
> > thanks
> > Stephen
> >
> >
> > [1] https://www.iana.org/time-zones
> > [2] https://bugs.openjdk.java.net/browse/JDK-8212684
> > [3]
> > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time
> > /zone/ZoneOffsetTransitionRule.html
> > [4] https://www.threeten.org/threetenbp/
> >

Exceptions in Iterator.forEachRemaining()

[Zheka Kozlov]

Hi everyone.

I noticed that different Iterator implementations behave differently when
an Exception is thrown inside a Consumer passed to forEachRemaining():

private static void test(List list) {
Iterator iterator = list.iterator();
try {
iterator.forEachRemaining(i -> {
if (i == 3) {
throw new RuntimeException();
} else {
System.out.print(i);
}
});
} catch (RuntimeException ex) {
}
iterator.forEachRemaining(System.out::print);
}

public static void main(String... args) throws Throwable {
test(List.of(1, 2, 3, 4, 5)); // Prints 1245
System.out.println();
test(Arrays.asList(1, 2, 3, 4, 5)); // Prints 1245
System.out.println();
test(new LinkedList<>(List.of(1, 2, 3, 4, 5))); // Prints 12345 (BAD)
System.out.println();
test(new ArrayList<>(List.of(1, 2, 3, 4, 5))); // Prints 1212345 (BAD)
}

Is this a bug? I think yes because an overridden forEachRemaining() should
behave the same as the default implementation:

while (hasNext()) {
action.accept(next());
}

So, in this case, List.of() and Arrays.asList() are correct while
LinkedList and ArrayList are not.