Re: RFR 8015978: Incorrect transformation of XPath expression "string(-0)"

Hi Aleksej, According to XPath spec, both positive and negative zero are converted to the string 0, so it seems doesn't matter. But if you want to detect the negative zero, you may do the following: if (d == 0.0 && 1/d < 0.0) { d=0.0 } Recognizing that (-0.0 == 0.0), and (1/(

Re: RFR JDK-8015728: (zipfs) demo/zipfs/basic.sh failing

On 07/06/2013 00:03, Xueming Shen wrote: Hi, Please help review the proposed change to fix the regression triggered by the change for #6303183, in which the change failed to update the written loc entry size correctly when the "NTFS" timestamp is used on Windows platform (return size at line#220

Re: Review request for 8016101, javadoc typos for SerialRef and SerialStruct

Hi Lance, Looks fine; approved. Cheers, -Joe On 6/6/2013 1:41 PM, Lance Andersen - Oracle wrote: Hi Aleksey, The change is 2 lines, not worth a webrev. Here it is again in case it was truncated in last email (looked OK on my end) new-host-2:serial lanceandersen$ hg diff diff -r b4742d

hg: jdk8/tl/jdk: 8016117: New sun.misc.FDBigInteger class as part of 7032154

Changeset: f5f54e493a64 Author:bpb Date: 2013-06-06 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5f54e493a64 8016117: New sun.misc.FDBigInteger class as part of 7032154 Reviewed-by: martin, iris Contributed-by: Sergey Kuksenko , Brian Burkhalter , Dmitry Nadezhin ,

RFR JDK-8015728: (zipfs) demo/zipfs/basic.sh failing

Hi, Please help review the proposed change to fix the regression triggered by the change for #6303183, in which the change failed to update the written loc entry size correctly when the "NTFS" timestamp is used on Windows platform (return size at line#2200 is not updated accordingly) http://cr.o

hg: jdk8/tl/jaxp: 8015016: Improve JAXP 1.5 error message

Changeset: c2957e596bee Author:joehw Date: 2013-06-06 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c2957e596bee 8015016: Improve JAXP 1.5 error message Reviewed-by: lancea ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/o

Re: RFR (jaxp): 8015016: Improve JAXP 1.5 error message

Hi Joe, The change looks OK. I know the messages have to be translated by the globalization team for the other languages. Best Lance On Jun 6, 2013, at 5:42 PM, huizhe wang wrote: > This is a quick fix to improve the error message so that it's clearly > differentiated from those reported by t

Re: RFR (jaxp): 8015016: Improve JAXP 1.5 error message

Hi Joe On Jun 6, 2013, at 5:56 PM, huizhe wang wrote: > Hi Lance, > > Thanks for the quick review! > > I filed a request (8005454) to translate new error messages accumulated since > the last translation. But the way the localization tool works is that the > error message has to be in the re

Re: RFR (jaxp): 8015016: Improve JAXP 1.5 error message

Hi Lance, Thanks for the quick review! I filed a request (8005454) to translate new error messages accumulated since the last translation. But the way the localization tool works is that the error message has to be in the repository before the tool can pull them out. Best, Joe On 6/6/2013

RFR (jaxp): 8015016: Improve JAXP 1.5 error message

This is a quick fix to improve the error message so that it's clearly differentiated from those reported by the Security Manager. The change is identical for both JDK7 and 8. I will backport the fix to 7u40 if approved. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8015016/webrev/ Thanks, J

hg: jdk8/tl/jdk: 8016063: getFinalAttributes should use FindClose

Changeset: d28f802ce914 Author:robm Date: 2013-06-06 22:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d28f802ce914 8016063: getFinalAttributes should use FindClose Reviewed-by: alanb ! src/windows/native/java/io/WinNTFileSystem_md.c

hg: jdk8/tl/jdk: 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal

Changeset: 986793409b2b Author:bpb Date: 2013-06-05 21:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/986793409b2b 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal Summary: Performance improvements for double/float -> String and decimal/hex

Re: Review request for 8016101, javadoc typos for SerialRef and SerialStruct

Hi Aleksey, The change is 2 lines, not worth a webrev. Here it is again in case it was truncated in last email (looked OK on my end) new-host-2:serial lanceandersen$ hg diff diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialRef.java --- a/src/share/classes/javax/sql/rowset/

Re: PhantomReference: why not cleared by GC when enqueued?

The only useful use case that I've come up with for PhantomReference is to subclass it. In one case it was used as a wrapper so that we'd know when an object was being collected so that we could reap life-cycle information from it. The behaviour was triggered by an JMX control. I suppose there w

Re: Is there a better way to throw this exception?

On Jun 6, 2013, at 2:42 AM, Weijun Wang wrote: > Hi All > > I have a method that could throw two kinds of checked exceptions and possibly > other unchecked ones: > > void once() throws One, Two > > Now I have a wrapper method that calls once() for multiple times, and want to > throw the f

Re: hg: jdk8/tl/jdk: 8014383: StringJoiner example in class description not in sync with streams API

Looking at the implementation, the code in toString suggest that it's worthwhile to optimize for an empty suffix (although I doubt that this optimization has any measurable effects). But the constructor always concatenates the prefix and the suffix, which results in both a new string instance and a

Review request for 8016101, javadoc typos for SerialRef and SerialStruct

Hi, Need a reviewer for this minor javadoc update for bug 8016101 SerialStruct was missing a javadoc @param tag in the constructor SerialRef had an extra '.' Best Lance hg diff diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialRef.java --- a/src/share/classes/javax/sql/ro

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 69d566198fe4 Author:henryjen Date: 2013-06-05 15:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69d566198fe4 8015522: CharSequence.codePoints can be faster Reviewed-by: martin, psandoz, alanb Contributed-by: henry@oracle.com ! src/share/classes/java/lang/Ch

hg: jdk8/tl/jaxp: 8013434: Xalan and Xerces internal ObjectFactory need rework

Changeset: e93beba07830 Author:dfuchs Date: 2013-06-06 20:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e93beba07830 8013434: Xalan and Xerces internal ObjectFactory need rework Summary: With this changeset, DTMManager and XSLTCDTMManager will always use their own defau

Re: RFR: 8016063 - getFinalAttributes should use FindClose

On 06/06/2013 19:04, Rob McKenna wrote: Hi folks, When fixing 7038105 I overlooked the fact I should have use FindClose instead of CloseHandle after calling FindFirstFileW: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx http://cr.openjdk.java.net/~robm/

RFR: 8016063 - getFinalAttributes should use FindClose

Hi folks, When fixing 7038105 I overlooked the fact I should have use FindClose instead of CloseHandle after calling FindFirstFileW: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx http://cr.openjdk.java.net/~robm/8016063/webrev.01/ Thanks, -Rob

hg: jdk8/tl/jdk: 8009579: Xpathexception does not honor initcause()

Changeset: e6d2c605930c Author:dmeetry Date: 2013-06-06 20:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6d2c605930c 8009579: Xpathexception does not honor initcause() Reviewed-by: alanb, dholmes, joehw Contributed-by: aleksej.efi...@oracle.com + test/javax/xml/jaxp/XPa

hg: jdk8/tl/jaxp: 8009579: Xpathexception does not honor initcause()

Changeset: 7d14fea1e893 Author:dmeetry Date: 2013-06-06 20:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7d14fea1e893 8009579: Xpathexception does not honor initcause() Reviewed-by: alanb, dholmes, joehw Contributed-by: aleksej.efi...@oracle.com ! src/javax/xml/xpath/XP

RFR 8015978: Incorrect transformation of XPath expression "string(-0)"

Hi, The expression "string(-0.0)" incorrectly transformed to -0, but it should be 0 according to W3C specification: http://www.w3.org/TR/xpath/#function-string The webrev with fix and the test case: http://cr.openjdk.java.net/~dmeetry/8015978/webrev.1/

Re: Is there a better way to throw this exception?

On Jun 6, 2013, at 2:42 AM, Weijun Wang wrote: > Hi All > > I have a method that could throw two kinds of checked exceptions and possibly > other unchecked ones: > > void once() throws One, Two > > Now I have a wrapper method that calls once() for multiple times, and want to > throw the f

Re: Is there a better way to throw this exception?

On 06/06/2013 11:42 AM, Weijun Wang wrote: Hi All I have a method that could throw two kinds of checked exceptions and possibly other unchecked ones: void once() throws One, Two Now I have a wrapper method that calls once() for multiple times, and want to throw the first exception if *al

hg: jdk8/tl/langtools: 6 new changesets

Changeset: 6e30a513c945 Author:mcimadamore Date: 2013-06-06 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6e30a513c945 6360970: javac erroneously accept ambiguous field reference Summary: clash between ambiguous fields in superinterface and unambiguous field in

Re: JDK-8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK

Thanks, Alan. On 06/06/13 09:22, Alan Bateman wrote: > On 06/06/2013 14:07, Eric McCorkle wrote: >> Hello, >> >> Please review this simple patch that removes setProtectionDomain0 from >> java.lang.Class. This is part of a two-stage process to remove the >> function from the JVM as well. >> >> Thi

hg: jdk8/tl/jdk: 8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK

Changeset: 37aa82c52317 Author:emc Date: 2013-06-06 09:51 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37aa82c52317 8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK Summary: setProtectionDomain0 and JVM_SetProtectionDomain are unused since at least 1

hg: jdk8/tl/jdk: 8000450: Restrict access to com/sun/corba/se/impl package

Changeset: c4480e0d9f53 Author:coffeys Date: 2013-06-06 14:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4480e0d9f53 8000450: Restrict access to com/sun/corba/se/impl package Reviewed-by: alanb, chegar, lancea ! src/share/lib/security/java.security-linux ! src/share/lib

Re: JDK-8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK

On 06/06/2013 14:07, Eric McCorkle wrote: Hello, Please review this simple patch that removes setProtectionDomain0 from java.lang.Class. This is part of a two-stage process to remove the function from the JVM as well. This method is not used, and has not been used in some time (at least before

JDK-8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK

Hello, Please review this simple patch that removes setProtectionDomain0 from java.lang.Class. This is part of a two-stage process to remove the function from the JVM as well. This method is not used, and has not been used in some time (at least before 1.5) The webrev is here: http://cr.openjdk

hg: jdk8/tl/langtools: 8015701: MethodParameters are not filled in for synthetic captured local variables

Changeset: 8717586f7b05 Author:emc Date: 2013-06-06 08:48 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8717586f7b05 8015701: MethodParameters are not filled in for synthetic captured local variables Summary: Synthetic parameters for captured local variables in an ano

Re: RFR 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator

On Jun 6, 2013, at 2:38 PM, Chris Hegarty wrote: > The changes look fine to me Paul. > Thanks. > Strangely, the webrev seems to indicate mercurial history of other bugs, but > I don't see any evidence of them. Maybe an issue with webrev and mq? > I don't think it an issue. There are patch

Re: RFR 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator

The changes look fine to me Paul. Strangely, the webrev seems to indicate mercurial history of other bugs, but I don't see any evidence of them. Maybe an issue with webrev and mq? -Chris. On 06/03/2013 05:09 PM, Paul Sandoz wrote: Hi, The following patch renames the Spliterators.spliterator

Re: RFR: 8000450: Restrict access to com/sun/corba/se/impl package

On 06/06/2013 01:09 PM, Alan Bateman wrote: On 05/06/2013 09:22, Seán Coffey wrote: There are plans to introduce a more robust testcase to test all restricted packages. Hope to have that brought into jdk8 in coming weeks. Good points on the @summary text. Meant to update that. Test now checks p

Re: RFR (jaxp): JDK-8013434: Xalan and Xerces internal ObjectFactory need rework

On 03/06/2013 17:54, Daniel Fuchs wrote: Hi, In order to prepare for modularization, we need to review all the places where META-INF/services is parsed directly. : I've skimmed over the changes and it looks good to me (might be awkwar

Re: RFR: 8000450: Restrict access to com/sun/corba/se/impl package

On 05/06/2013 09:22, Seán Coffey wrote: There are plans to introduce a more robust testcase to test all restricted packages. Hope to have that brought into jdk8 in coming weeks. Good points on the @summary text. Meant to update that. Test now checks package definition : http://cr.openjdk.ja

Re: Backport CR 7132378: fix for FutureTask.set() race

On 06/06/2013 01:44 PM, Alan Bateman wrote: > On 06/06/2013 10:38, Aleksey Shipilev wrote: >> Hi guys, >> >> What is the process to back port the issue to 7u? >> >> Specifically, I think we need to have this issue backported: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 >> >> -Al

Re: Backport CR 7132378: fix for FutureTask.set() race

On 06/06/2013 10:38, Aleksey Shipilev wrote: Hi guys, What is the process to back port the issue to 7u? Specifically, I think we need to have this issue backported: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 -Aleksey. The process is on the jdk7u project page [1]. As this on

Re: Backport CR 7132378: fix for FutureTask.set() race

If the changeset applies cleanly to 7u-dev, then its a simple approval request [1]. -Chris. [1] http://openjdk.java.net/projects/jdk7u/approval-template.html On 06/06/2013 10:38 AM, Aleksey Shipilev wrote: Hi guys, What is the process to back port the issue to 7u? Specifically, I think we n

Is there a better way to throw this exception?

Hi All I have a method that could throw two kinds of checked exceptions and possibly other unchecked ones: void once() throws One, Two Now I have a wrapper method that calls once() for multiple times, and want to throw the first exception if *all* fails. Now it looks like void multip

Backport CR 7132378: fix for FutureTask.set() race

Hi guys, What is the process to back port the issue to 7u? Specifically, I think we need to have this issue backported: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 -Aleksey.

hg: jdk8/tl/jdk: 8015470: Remove redundant calls of toString() on String objects

Changeset: 571e5f452640 Author:dholmes Date: 2013-06-06 05:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/571e5f452640 8015470: Remove redundant calls of toString() on String objects Reviewed-by: dholmes, alanb Contributed-by: Otavio Goncalves ! src/share/classes/com/sun