RFR: 8029837: NPE seen in XMLDocumentFragmentScannerImpl.setProperty since 7u40b33
Hello, Please review the fix [1] for the following bug: https://bugs.openjdk.java.net/browse/JDK-8029837 The problem was discovered during usage of not compatible old JAXB/XJC classes on the stack with latest JDK source (starting from 7u40 release). The problem is that the JAXP XML_SECURITY_PROPERTY_MANAGER and SECURITY_MANAGER properties was not initialized by the XJC task code: new regression test recreates the similar condition. XML related regression tests and JCK tests passes with proposed fix. Thank you, Aleksej [1] Webrev: http://cr.openjdk.java.net/~aefimov/8029837/9/webrev.00/
Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
Hello Joe,
if I understand correctly the doc doesn't specify exact circumstances
leading to infinities, it just has general assertion:
* liIf the recorded values contain one or more infinities, the
* sum will be infinite or NaN.
this assertion is clarified by following child assertions which specify
just NaN-causing circumstances but what exactly can lead to infinities
is not specified therein:
* ul
*
* liIf the recorded values contain infinities of opposite sign,
* the sum will be NaN.
*
* liIf the recorded values contain infinities of one sign and
* an intermediate sum overflows to an infinity of the opposite
* sign, the sum may be NaN.
I believe that some details should be provided clarifying how exactly
+/- infinities can be resulted from input (as I see it this cannot be
inferred from the provided doc); otherwise I'm afraid this won't be
testable from conformance point of view.
Thank you,
Georgiy.
On 22.07.2014 7:33, Joe Darcy wrote:
On 07/18/2014 12:00 PM, Georgiy Rakov wrote:
On 18.07.2014 20:14, Joe Darcy wrote:
Hello Georgiy,
On 07/18/2014 05:29 AM, Georgiy Rakov wrote:
Hello Joe,
could you please clarify by short example following assertion:
154 * If the exact sum is infinite, a properly-signed infinity is
155 * returned.
I'm afraid I don't quite understand what you mean here by 'exact sum'.
By exact sum, the sum absent any floating-point rounding, the sum
you would get using infinite precision to operate on the values in
question.
The sentence in question is intended to be a short way of saying If
you have same-signed infinities in your input, the result will be an
infinity of that sign. In particular, this disallows the behavior
that was fixed before JDK 8 GA where having infinities in the input
would cause a NaN to be returned because of how the compensated
summation code manipulated those values.
Thanks, I see,
however it seems to me a bit confusing, since the term infinite
exact sum seems to me not obvious and I believe it needs some
definition. I'd like to suggest to use more straightforward approach,
that is as you've said: If you have same-signed infinities in your
input, the result will be an infinity of that sign.. I believe it
would be more clear for end user (at least for me :)) and from
conformance point of view.
Besides it seems to me a bit questionable. For instance inexact
some looks like more appropriate, since overflowing to infinity
occurs when _actual _sum exceeds the limit. By actual sum I mean sum
resulted from actual summation with all the rounding happened. There
wouldn't be such questions, provided straightforward approach is used.
Thanks,
Georgiy.
In response to previous feedback, I propose this revised change to the
specification:
--- a/src/share/classes/java/util/DoubleSummaryStatistics.java Sat Jul
19 11:22:08 2014 +0800
+++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Mon Jul
21 18:02:54 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2012, 2014, 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
@@ -129,9 +129,6 @@
* Returns the sum of values recorded, or zero if no values have been
* recorded.
*
- * If any recorded value is a NaN or the sum is at any point a NaN
- * then the sum will be NaN.
- *
* p The value of a floating-point sum is a function both of the
* input values as well as the order of addition operations. The
* order of addition operations of this method is intentionally
@@ -143,6 +140,44 @@
* numerical sum compared to a simple summation of {@code double}
* values.
*
+ * Because of the unspecified order of operations and the
+ * possibility of using differing summation schemes, the output of
+ * this method may vary on the same input values.
+ *
+ * pVarious conditions can result in a non-finite sum being
+ * computed. This can occur even if the all the recorded values
+ * being summed are finite. If any recorded value is non-finite,
+ * the sum will be non-finite:
+ *
+ * ul
+ *
+ * liIf any recorded value is a NaN, then the final sum will be
+ * NaN.
+ *
+ * liIf the recorded values contain one or more infinities, the
+ * sum will be infinite or NaN.
+ *
+ * ul
+ *
+ * liIf the recorded values contain infinities of opposite sign,
+ * the sum will be NaN.
+ *
+ * liIf the recorded values contain infinities of one sign and
+ * an intermediate sum overflows to an infinity of the opposite
+ * sign, the sum may be NaN.
+ *
+ * /ul
+ *
+ * /ul
+ *
+ * It is possible for intermediate sums of finite values to
Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
Hello Joe,
following assertion seems to me too loose:
* Because of the unspecified order of operations and the
* possibility of using differing summation schemes, the output of
* this method may vary on the same input values.
as I see it this assertion imposes no constraints on how the sum can be
varied. Strictly speaking, I'm afraid from conformance point of view it
can cause the entire method to become untestable.
Thank you,
Georgiy.
On 22.07.2014 7:33, Joe Darcy wrote:
On 07/18/2014 12:00 PM, Georgiy Rakov wrote:
On 18.07.2014 20:14, Joe Darcy wrote:
Hello Georgiy,
On 07/18/2014 05:29 AM, Georgiy Rakov wrote:
Hello Joe,
could you please clarify by short example following assertion:
154 * If the exact sum is infinite, a properly-signed infinity is
155 * returned.
I'm afraid I don't quite understand what you mean here by 'exact sum'.
By exact sum, the sum absent any floating-point rounding, the sum
you would get using infinite precision to operate on the values in
question.
The sentence in question is intended to be a short way of saying If
you have same-signed infinities in your input, the result will be an
infinity of that sign. In particular, this disallows the behavior
that was fixed before JDK 8 GA where having infinities in the input
would cause a NaN to be returned because of how the compensated
summation code manipulated those values.
Thanks, I see,
however it seems to me a bit confusing, since the term infinite
exact sum seems to me not obvious and I believe it needs some
definition. I'd like to suggest to use more straightforward approach,
that is as you've said: If you have same-signed infinities in your
input, the result will be an infinity of that sign.. I believe it
would be more clear for end user (at least for me :)) and from
conformance point of view.
Besides it seems to me a bit questionable. For instance inexact
some looks like more appropriate, since overflowing to infinity
occurs when _actual _sum exceeds the limit. By actual sum I mean sum
resulted from actual summation with all the rounding happened. There
wouldn't be such questions, provided straightforward approach is used.
Thanks,
Georgiy.
In response to previous feedback, I propose this revised change to the
specification:
--- a/src/share/classes/java/util/DoubleSummaryStatistics.java Sat Jul
19 11:22:08 2014 +0800
+++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Mon Jul
21 18:02:54 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2012, 2014, 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
@@ -129,9 +129,6 @@
* Returns the sum of values recorded, or zero if no values have been
* recorded.
*
- * If any recorded value is a NaN or the sum is at any point a NaN
- * then the sum will be NaN.
- *
* p The value of a floating-point sum is a function both of the
* input values as well as the order of addition operations. The
* order of addition operations of this method is intentionally
@@ -143,6 +140,44 @@
* numerical sum compared to a simple summation of {@code double}
* values.
*
+ * Because of the unspecified order of operations and the
+ * possibility of using differing summation schemes, the output of
+ * this method may vary on the same input values.
+ *
+ * pVarious conditions can result in a non-finite sum being
+ * computed. This can occur even if the all the recorded values
+ * being summed are finite. If any recorded value is non-finite,
+ * the sum will be non-finite:
+ *
+ * ul
+ *
+ * liIf any recorded value is a NaN, then the final sum will be
+ * NaN.
+ *
+ * liIf the recorded values contain one or more infinities, the
+ * sum will be infinite or NaN.
+ *
+ * ul
+ *
+ * liIf the recorded values contain infinities of opposite sign,
+ * the sum will be NaN.
+ *
+ * liIf the recorded values contain infinities of one sign and
+ * an intermediate sum overflows to an infinity of the opposite
+ * sign, the sum may be NaN.
+ *
+ * /ul
+ *
+ * /ul
+ *
+ * It is possible for intermediate sums of finite values to
+ * overflow into opposite-signed infinities; if that occurs, the
+ * final sum will be NaN even if the recorded values are all
+ * finite.
+ *
+ * If all the recorded values are zero, the sign of zero is
+ * emnot/em guaranteed to be preserved in the final sum.
+ *
* @apiNote Values sorted by increasing absolute magnitude tend
to yield
* more accurate results.
*
@@ -193,15 +228,9 @@
* Returns the arithmetic mean of values recorded, or zero if no
* values
Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
Hello Georgiy, On 07/22/2014 08:49 AM, Georgiy Rakov wrote: Hello Joe, following assertion seems to me too loose: * Because of the unspecified order of operations and the * possibility of using differing summation schemes, the output of * this method may vary on the same input values. as I see it this assertion imposes no constraints on how the sum can be varied. Strictly speaking, I'm afraid from conformance point of view it can cause the entire method to become untestable. Thank you, Georgiy. I would argue the statement above is just a clarification of the existing (non) specification of how the method can operate. Ideally, the sum method would state an error bound for its operation. There are bugs in this subcomponent mentioning adding such a bound, which may be done later in JDK 9. -Joe
pretxnchangegroup hook raised an exception: urlopen error [Errno 60] Operation timed out
Folks, is there a timeout value somewhere that needs to be set? hg pull pulling from http://hg.openjdk.java.net/jdk8u/jdk8u-dev searching for changes adding changesets adding manifests adding file changes added 53 changesets with 56 changes to 11 files error: pretxnchangegroup hook raised an exception: urlopen error [Errno 60] Operation timed out transaction abort! rollback completed abort: error: Operation timed out - In the past, I had to do a fresh clone when I started seeing this error which does not seem right. 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: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
On 22.07.2014 20:12, Joe Darcy wrote: Hello Georgiy, On 07/22/2014 08:49 AM, Georgiy Rakov wrote: Hello Joe, following assertion seems to me too loose: * Because of the unspecified order of operations and the * possibility of using differing summation schemes, the output of * this method may vary on the same input values. as I see it this assertion imposes no constraints on how the sum can be varied. Strictly speaking, I'm afraid from conformance point of view it can cause the entire method to become untestable. Thank you, Georgiy. I would argue the statement above is just a clarification of the existing (non) specification of how the method can operate. Ideally, the sum method would state an error bound for its operation. There are bugs in this subcomponent mentioning adding such a bound, which may be done later in JDK 9. Do I understand correctly that your opinion is that for the present moment this method is actually untestable from conformance point of view? - Georgiy. -Joe
Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
On 07/22/2014 09:23 AM, Georgiy Rakov wrote: On 22.07.2014 20:12, Joe Darcy wrote: Hello Georgiy, On 07/22/2014 08:49 AM, Georgiy Rakov wrote: Hello Joe, following assertion seems to me too loose: * Because of the unspecified order of operations and the * possibility of using differing summation schemes, the output of * this method may vary on the same input values. as I see it this assertion imposes no constraints on how the sum can be varied. Strictly speaking, I'm afraid from conformance point of view it can cause the entire method to become untestable. Thank you, Georgiy. I would argue the statement above is just a clarification of the existing (non) specification of how the method can operate. Ideally, the sum method would state an error bound for its operation. There are bugs in this subcomponent mentioning adding such a bound, which may be done later in JDK 9. Do I understand correctly that your opinion is that for the present moment this method is actually untestable from conformance point of view? Whatever the testability status of the method is as of Java SE 8, I believe is unchanged by the addition of the sentence in question. Cheers, -Joe
Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs
Hello Georgiy,
On 07/22/2014 08:35 AM, Georgiy Rakov wrote:
Hello Joe,
if I understand correctly the doc doesn't specify exact circumstances
leading to infinities, it just has general assertion:
* liIf the recorded values contain one or more infinities, the
* sum will be infinite or NaN.
this assertion is clarified by following child assertions which
specify just NaN-causing circumstances but what exactly can lead to
infinities is not specified therein:
* ul
*
* liIf the recorded values contain infinities of opposite sign,
* the sum will be NaN.
*
* liIf the recorded values contain infinities of one sign and
* an intermediate sum overflows to an infinity of the opposite
* sign, the sum may be NaN.
I believe that some details should be provided clarifying how exactly
+/- infinities can be resulted from input (as I see it this cannot be
inferred from the provided doc); otherwise I'm afraid this won't be
testable from conformance point of view.
It should not be the role of this method's specification to provide a
full tutorial on IEEE floating-point arithmetic.
Overflow to infinity can occur when adding up just two floating-point
values; the sum being equal to just one of the operands can occur too.
I don't think is is helpful or appropriate to spell all that out for
this sum method. The JLS material describing floating-point in Java is
implicitly assumed:
http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.2.3
http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.2.4
Cheers,
-Joe
Thank you,
Georgiy.
On 22.07.2014 7:33, Joe Darcy wrote:
On 07/18/2014 12:00 PM, Georgiy Rakov wrote:
On 18.07.2014 20:14, Joe Darcy wrote:
Hello Georgiy,
On 07/18/2014 05:29 AM, Georgiy Rakov wrote:
Hello Joe,
could you please clarify by short example following assertion:
154 * If the exact sum is infinite, a properly-signed infinity is
155 * returned.
I'm afraid I don't quite understand what you mean here by 'exact sum'.
By exact sum, the sum absent any floating-point rounding, the sum
you would get using infinite precision to operate on the values in
question.
The sentence in question is intended to be a short way of saying
If you have same-signed infinities in your input, the result will
be an infinity of that sign. In particular, this disallows the
behavior that was fixed before JDK 8 GA where having infinities in
the input would cause a NaN to be returned because of how the
compensated summation code manipulated those values.
Thanks, I see,
however it seems to me a bit confusing, since the term infinite
exact sum seems to me not obvious and I believe it needs some
definition. I'd like to suggest to use more straightforward
approach, that is as you've said: If you have same-signed
infinities in your input, the result will be an infinity of that
sign.. I believe it would be more clear for end user (at least for
me :)) and from conformance point of view.
Besides it seems to me a bit questionable. For instance inexact
some looks like more appropriate, since overflowing to infinity
occurs when _actual _sum exceeds the limit. By actual sum I mean sum
resulted from actual summation with all the rounding happened. There
wouldn't be such questions, provided straightforward approach is used.
Thanks,
Georgiy.
In response to previous feedback, I propose this revised change to
the specification:
--- a/src/share/classes/java/util/DoubleSummaryStatistics.java Sat
Jul 19 11:22:08 2014 +0800
+++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Mon
Jul 21 18:02:54 2014 -0700
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All
rights reserved.
+ * Copyright (c) 2012, 2014, 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
@@ -129,9 +129,6 @@
* Returns the sum of values recorded, or zero if no values have
been
* recorded.
*
- * If any recorded value is a NaN or the sum is at any point a NaN
- * then the sum will be NaN.
- *
* p The value of a floating-point sum is a function both of the
* input values as well as the order of addition operations. The
* order of addition operations of this method is intentionally
@@ -143,6 +140,44 @@
* numerical sum compared to a simple summation of {@code double}
* values.
*
+ * Because of the unspecified order of operations and the
+ * possibility of using differing summation schemes, the output of
+ * this method may vary on the same input values.
+ *
+ * pVarious conditions can result in a non-finite sum being
+ * computed. This can occur even if the all the recorded values
+ * being summed are finite. If any recorded value is non-finite,
+ * the sum will be
Re: RFR: 8029837: NPE seen in XMLDocumentFragmentScannerImpl.setProperty since 7u40b33
Hi Aleksej, The change looks good. Thanks, Joe On 7/22/2014 6:10 AM, Aleksej Efimov wrote: Hello, Please review the fix [1] for the following bug: https://bugs.openjdk.java.net/browse/JDK-8029837 The problem was discovered during usage of not compatible old JAXB/XJC classes on the stack with latest JDK source (starting from 7u40 release). The problem is that the JAXP XML_SECURITY_PROPERTY_MANAGER and SECURITY_MANAGER properties was not initialized by the XJC task code: new regression test recreates the similar condition. XML related regression tests and JCK tests passes with proposed fix. Thank you, Aleksej [1] Webrev: http://cr.openjdk.java.net/~aefimov/8029837/9/webrev.00/
Re: RFR: 8029837: NPE seen in XMLDocumentFragmentScannerImpl.setProperty since 7u40b33
Joe, Thank you for the review. -Aleksej On 07/22/2014 09:52 PM, huizhe wang wrote: Hi Aleksej, The change looks good. Thanks, Joe On 7/22/2014 6:10 AM, Aleksej Efimov wrote: Hello, Please review the fix [1] for the following bug: https://bugs.openjdk.java.net/browse/JDK-8029837 The problem was discovered during usage of not compatible old JAXB/XJC classes on the stack with latest JDK source (starting from 7u40 release). The problem is that the JAXP XML_SECURITY_PROPERTY_MANAGER and SECURITY_MANAGER properties was not initialized by the XJC task code: new regression test recreates the similar condition. XML related regression tests and JCK tests passes with proposed fix. Thank you, Aleksej [1] Webrev: http://cr.openjdk.java.net/~aefimov/8029837/9/webrev.00/
RFR: 8049343: (tz) Support tzdata2014e
Hi, Please review the tzdata2014e [1] integration fix to JDK9: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/ Two issues with JSR310 implementation were discovered during integration process: First issue is related to the internal representation of the '24:00' value. The JSR310 implementation treats this value as a next day 00:00 time. The workaround already exists in the code for similar entries and this failure was resolved in similar way [2]. For the second issue JDK-8051641 [3] was filled and 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one that fails with this tzdata. Other time zone related test passes without failures. Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8049343 [2] http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/src/share/classes/sun/util/calendar/ZoneInfoFile.java.patch [3] https://bugs.openjdk.java.net/browse/JDK-8051641
RFR: 6721085 : (xxs) Fix broken link to Collections Framework Tutorial
Hello all; This is a tiny fix to the java.util package documentation to update the URL of the Collections tutorial. The entire change is below. I have also checked for other references to http://www.java.sun.com/docs/books/tutorial/; in the jdk repo. This was the only instance. https://bugs.openjdk.java.net/browse/JDK-6721085 Mike diff --git a/src/share/classes/java/util/package.html b/src/share/classes/java/u --- a/src/share/classes/java/util/package.html +++ b/src/share/classes/java/util/package.html @@ -43,7 +43,7 @@ classes (a string tokenizer, a random-nu h2Related Documentation/h2 For overviews, tutorials, examples, guides, and tool documentation, please see: ul -lia href=http://www.java.sun.com/docs/books/tutorial/collections/; +lia href=http://docs.oracle.com/javase/tutorial/collections/index.html; bCollections Framework Tutorial/b/a lia href=../../../technotes/guides/collections/designfaq.htmlbCollections
Re: RFR: 6721085 : (xxs) Fix broken link to Collections Framework Tutorial
+1 On Jul 22, 2014, at 3:58 PM, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This is a tiny fix to the java.util package documentation to update the URL of the Collections tutorial. The entire change is below. I have also checked for other references to http://www.java.sun.com/docs/books/tutorial/; in the jdk repo. This was the only instance. https://bugs.openjdk.java.net/browse/JDK-6721085 Mike diff --git a/src/share/classes/java/util/package.html b/src/share/classes/java/u --- a/src/share/classes/java/util/package.html +++ b/src/share/classes/java/util/package.html @@ -43,7 +43,7 @@ classes (a string tokenizer, a random-nu h2Related Documentation/h2 For overviews, tutorials, examples, guides, and tool documentation, please see: ul -lia href=http://www.java.sun.com/docs/books/tutorial/collections/; +lia href=http://docs.oracle.com/javase/tutorial/collections/index.html; bCollections Framework Tutorial/b/a lia href=../../../technotes/guides/collections/designfaq.htmlbCollections Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
