hg: jdk8/tl/jdk: 8027624: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java unstable again

2013-11-01 Thread dan . xu
Changeset: 6a6faa00acc4 Author:dxu Date: 2013-11-01 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a6faa00acc4 8027624: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java unstable again Reviewed-by: wetmore !

Re: [test-only] JDK 8 RFR 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size

2013-11-01 Thread Dan Xu
Looks good to me. -Dan On 11/01/2013 05:07 PM, Brian Burkhalter wrote: Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8027625 Patch: --- a/test/java/math/BigInteger/ExtremeShiftingTests.java Fri Nov 01 14:40:03 2013 -0700 +++

hg: jdk8/tl/jdk: 8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up stage

2013-11-04 Thread dan . xu
Changeset: 6d1f3ba68db2 Author:dxu Date: 2013-11-04 15:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d1f3ba68db2 8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up stage Reviewed-by: chegar ! test/java/io/File/MaxPathLength.java

hg: jdk8/tl/jdk: 8025698: (fs) Typo in exception thrown by encode() in UnixPath.java

2013-11-06 Thread dan . xu
Changeset: 6ea1f9d8ec78 Author:dxu Date: 2013-11-06 13:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ea1f9d8ec78 8025698: (fs) Typo in exception thrown by encode() in UnixPath.java Reviewed-by: dxu, mduigou, henryjen, weijun Contributed-by: ajuc...@gmail.com !

Re: RFR doc only typo in java.io.DataInput

2013-11-07 Thread Dan Xu
Hi Roger, The change looks good. -Dan On 11/07/2013 02:29 PM, roger riggs wrote: Please review this straightforward typo correction: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-doc-readlong-8024458/ Thanks, Roger

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

2013-11-07 Thread Dan Xu
On 11/07/2013 11:04 AM, Alan Bateman wrote: On 07/11/2013 14:59, Chris Hegarty wrote: Given both Michael and Alan's comments. I've update the webrev: http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/ 1) more descriptive method names 2) deleteXXX methods return if interrupted, leaving

RFR: JDK-8028631 - Improve the test coverage to the pathname handling on unix-like platforms

2013-11-19 Thread Dan Xu
Hi All, We have java/io/pathNames/GeneralWin32.java testcase to do the general exhaustive test of pathname handling on windows. I am adding a new test GeneralSolaris.java to test the pathname handling in unix-like platforms. In the changes, I also make sure the test can run successfully in

hg: jdk8/tl/jdk: 8028631: Improve the test coverage to the pathname handling on unix-like platforms

2013-11-19 Thread dan . xu
Changeset: f496565c4eec Author:dxu Date: 2013-11-19 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f496565c4eec 8028631: Improve the test coverage to the pathname handling on unix-like platforms Summary: Add GeneralSolaris.java testcase and fix the concurrency issue

RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run

2013-11-19 Thread Dan Xu
Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows. In the fix, I remove the delete operation in initTestFile() method because

Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run

2013-11-19 Thread Dan Xu
-failures-in-java-net-URLClassLoader-Add-jdk-testlibrary-FileUtils-java-td165561.html. Thanks! -Dan On 11/19/2013 07:08 PM, Mandy Chung wrote: On 11/19/2013 3:57 PM, Dan Xu wrote: Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform

Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run

2013-11-20 Thread Dan Xu
/20/2013 04:08 AM, Alan Bateman wrote: On 19/11/2013 23:57, Dan Xu wrote: Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows

hg: jdk8/tl/jdk: 8028628: java/nio/channels/FileChannel/Size.java failed once in the same binary run

2013-11-21 Thread dan . xu
Changeset: 81708985c0a2 Author:dxu Date: 2013-11-21 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81708985c0a2 8028628: java/nio/channels/FileChannel/Size.java failed once in the same binary run Reviewed-by: alanb, chegar, mchung, lancea !

hg: jdk8/tl/jdk: 7065902: (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root

2013-11-21 Thread dan . xu
Changeset: a74d6aa51654 Author:dxu Date: 2013-11-21 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a74d6aa51654 7065902: (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root Reviewed-by: alanb ! test/java/nio/file/Files/Misc.java

RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root

2013-11-21 Thread Dan Xu
Hi All, Please review the simple fix towards test/java/nio/file/Files/Misc.java. It only fails when it is run by root. As Alan commented in the bug, the root has all permissions, so the test assumptions are wrong. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 Webrev:

Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run

2013-11-21 Thread Dan Xu
On 11/21/2013 05:41 AM, Alan Bateman wrote: On 21/11/2013 01:09, Dan Xu wrote: Hi All, I have updated my fix based on your suggestions. I have changed to create testing files in the working directory, moved those static member variables into local method variables, and used try

Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run

2013-11-21 Thread Dan Xu
. But the performance should be good. On windows, this test runs for around 0.14 seconds in jprt machines. Thanks! -Dan On Thu 21 Nov 2013 11:51:28 AM PST, Alan Bateman wrote: On 21/11/2013 17:02, Dan Xu wrote: Hi Alan, I think the map is used to enlarge the size of the largeFile to testSize

RFR: JDK-8022219,Intermittent test failures in java/util/zip/ZipFile

2013-12-08 Thread Dan Xu
Hi All, Please review the fix towards the intermittent test failure in java/util/zip/ZipFile. It is a similar failure that I encountered before, due to the interferences from other software or daemon services in Windows platforms. The fix is to use the method from FileUtils test library to

Re: RFR: JDK-8022219, Intermittent test failures in java/util/zip/ZipFile

2013-12-10 Thread Dan Xu
/2013 17:29, Dan Xu wrote: Hi All, Please review the fix towards the intermittent test failure in java/util/zip/ZipFile. It is a similar failure that I encountered before, due to the interferences from other software or daemon services in Windows platforms. The fix is to use the method from

RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

2014-01-06 Thread Dan Xu
Hi All, Please review the simple fix for JNI pending exceptions in FileSystemPreferences.c. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ -Dan

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

2014-01-06 Thread Dan Xu
/2014 02:35 PM, Lance Andersen - Oracle wrote: Dan, Looks OK, but line 914 which you did not change, notice the comments not sure if that is common in this code but seemed a bit off to me: 914 //// If at first, you don't succeed... On Jan 6, 2014, at 5:29 PM, Dan Xu wrote: Hi All

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

2014-01-07 Thread Dan Xu
Bateman wrote: On 06/01/2014 22:29, Dan Xu wrote: Hi All, Please review the simple fix for JNI pending exceptions in FileSystemPreferences.c. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ The update

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

2014-01-08 Thread Dan Xu
Thank you, Alan. I will add this change into my fix and push it today. Thanks! -Dan On 01/08/2014 01:24 AM, Alan Bateman wrote: On 08/01/2014 00:50, Dan Xu wrote: Hi All, Thanks for your good review. I have dropped the change in FileSystemPreferences.java , and created the new webrev

Re: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions

2014-01-08 Thread Dan Xu
) JNU_ReleaseStringPlatformChars(env, java_fname, fname); But according to the definition of JNU_GetStringPlatformChars(), it seems always to set *isCopy to JNI_TRUE currently. Because nativeGetStringPlatformChars() does nothing now. Thanks, -Dan On Wed 08 Jan 2014 09:56:40 AM PST, Dan Xu wrote: Thank you

RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-09 Thread Dan Xu
Hi All, Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 -Dan

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
Thanks, Chris. Right, I don't find any usage of getThreadStateValues, so it is simpler to just remove it. -Dan On 01/09/2014 11:49 PM, Chris Hegarty wrote: Looks ok to me. I presume getThreadStateValues is simply no longer needed. -Chris. On 10 Jan 2014, at 06:31, Dan Xu dan

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
On 01/10/2014 02:32 AM, Alan Bateman wrote: On 10/01/2014 06:31, Dan Xu wrote: Hi All, Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8029007

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
, Dan Xu wrote: Hi All, Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 -Dan

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
(!) with pointers. it is clearer to compare with NULL. (The CHECK_NULL macro will do the check and return). (Not a Reviewer) Thanks, Roger On 1/10/2014 1:31 AM, Dan Xu wrote: Hi All, Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! Webrev: http

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
be found. Here is the new webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.01/. Thanks! -Dan On 01/10/2014 10:21 AM, Mike Duigou wrote: On Jan 10 2014, at 10:09 , Chris Hegarty chris.hega...@oracle.com wrote: On 10 Jan 2014, at 18:05, Dan Xu dan...@oracle.com wrote: Hi Roger, My

Re: RFR 9 8031708: Windows x86 build failure: JNU_ThrowOutOfMemoryError undefined

2014-01-14 Thread Dan Xu
Hi Chris, Sorry that I did not check my previous change carefully on Windows. Thanks for fixing the issue. The change looks good to me. -Dan On 01/14/2014 06:06 AM, Chris Hegarty wrote: On 14 Jan 2014, at 14:03, Alan Bateman alan.bate...@oracle.com wrote: On 14/01/2014 13:56, Chris

Re: Code Review Request For 7185340

2012-07-29 Thread Dan Xu
On 07/29/2012 08:41 PM, Alan Bateman wrote: On 29/07/2012 04:53, Dan Xu wrote: Hi Alan, Please review the fix to bug 7185340. The webrev can be found at, http://cr.openjdk.java.net/~dxu/7185340/webrev.01/. The fix is to increase the -XX:MaxDirectMemorySize parameter from 64M to 75M. Bug

Re: Code Review Request For 7185340

2012-07-30 Thread Dan Xu
On 07/29/2012 11:17 PM, David Holmes wrote: Hi Dan, On 30/07/2012 2:20 PM, Dan Xu wrote: Thank you, Alan. I see the change is already pushed into the repository. I am going to move the bug status to 10-Fix Delivered. But I don't know what values I need put into Commit To Fix In Build, Fixed

Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

2012-08-23 Thread Dan Xu
Please review the fix of CR 7193406 at http://cr.openjdk.java.net/~dxu/7193406/webrev/. It cleans up warnings in the following java files. src/share/classes/java/io/FilePermission.java src/share/classes/java/util/ArrayDeque.java src/share/classes/java/util/Arrays.java

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

2012-08-24 Thread Dan Xu
On 08/23/2012 05:17 PM, Andrew Hughes wrote: - Original Message - - Original Message - Please review the fix of CR 7193406 at http://cr.openjdk.java.net/~dxu/7193406/webrev/. snip... And it enables fatal warning flag in the following make file.

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

2012-08-24 Thread Dan Xu
Hi David, Please see my response below. Thanks! On 08/23/2012 06:53 PM, David Holmes wrote: Hi Dan, On 24/08/2012 7:46 AM, Dan Xu wrote: Please review the fix of CR 7193406 at http://cr.openjdk.java.net/~dxu/7193406/webrev/. It cleans up warnings in the following java files. src/share

Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed code element

2012-08-27 Thread Dan Xu
This change is to fix the java doc font issue for ByteArrayOutputStream class. In current javadoc, contents change to the wrong font starting from toString(String charsetName) in ByteArrayOutputStream.html, which can be viewed at

Re: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed code element

2012-08-28 Thread Dan Xu
the generated ByteArrayOutputStream.htmlto the public java review site at, http://cr.openjdk.java.net/~dxu/7193710/javadoc/java/io/ByteArrayOutputStream.html. Thanks for your notification. -Dan On 08/27/2012 05:16 PM, David Holmes wrote: Hi Dan, On 28/08/2012 6:48 AM, Dan Xu wrote: This change

Re: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed code element

2012-08-28 Thread Dan Xu
/2012 02:20 PM, Ulf Zibis wrote: Am 28.08.2012 11:45, schrieb Alan Bateman: On 27/08/2012 21:48, Dan Xu wrote: This change is to fix the java doc font issue for ByteArrayOutputStream class. In current javadoc, contents change to the wrong font starting from toString(String charsetName

Re: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed code element

2012-08-28 Thread Dan Xu
charsetName}. And: 222 * @param charsetName the name of a supported 223 * {@link java.nio.charset.Charset} -Ulf Am 29.08.2012 01:39, schrieb Dan Xu: Thanks for your comments, Ulf. I looked at the definitions of @link and @linkplain again. And I find that this nested situation

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

2012-08-28 Thread Dan Xu
/classes/java/util/PropertyResourceBundle.java.sdiff.html. - Kurchi On 8/28/2012 4:57 PM, Dan Xu wrote: Thanks for all your good suggestions! I have updated my changes, which revoke changes to makefiles and put @SuppressWarnings outside methods instead of introducing local variables for small

Review Request: 7193683: Cleanup Warning in java.sql package

2012-08-28 Thread Dan Xu
I made a simple fix to clean up build warnings in java.sql package. The change can be reviewed at http://cr.openjdk.java.net/~dxu/7193683/webrev.01/. Thanks! -Dan

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

2012-08-29 Thread Dan Xu
On 08/29/2012 08:27 AM, Joe Darcy wrote: Hello, On 8/29/2012 1:48 AM, RĂ©mi Forax wrote: On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote: Thanks for cleaning up those spaces Dan. The changes look fine. Sorry for the extra trouble! - Kurchi On 8/28/12 10:22 PM, Dan Xu wrote: It is funny

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

2012-08-31 Thread Dan Xu
On 08/30/2012 06:45 PM, Stuart Marks wrote: On 8/30/12 7:14 AM, Ulf Zibis wrote: Am 30.08.2012 01:20, schrieb Stuart Marks: On 8/29/12 4:36 AM, Ulf Zibis wrote: @SuppressWarnings(fallthrough) is put to suppress warnings generated by another switch/case statements Can't you move it from

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

2012-09-02 Thread Dan Xu
On 09/01/2012 07:11 PM, Ulf wrote: Am 01.09.2012 03:15, schrieb Stuart Marks: On 8/31/12 3:19 AM, Ulf Zibis wrote: Stuart, much thanks for your detailed explanation. The as is situation has not been in question from my side, but anyway it seems, that it had catalysed a new solution, despite

Review Request for 7195933: There is incorrect link to Info-ZIP Application Note 970311 in doc page of Package java.util.zip

2012-09-17 Thread Dan Xu
Hi, This is the change to correct a java doc link in java.util.zip package page. The webrev can be reviewed at http://cr.openjdk.java.net/~dxu/7195933/webrev/. Thanks! -Dan

Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-09-20 Thread Dan Xu
Kurchi, Can you append bug number 7197662 to @bug field in each test so that it is easy to check its history? For your changes, I wonder why you choose to run these tests in othervm mode. Thanks! -Dan On Thu 20 Sep 2012 02:22:15 PM PDT, Kurchi Hazra wrote: Hi, The tests in

Review Request for 8000333 - Typo in : java.io.ObjectOutputStream.reset() refered

2012-10-02 Thread Dan Xu
Hi, This is a simple fix to correct a typo in the java doc. Please review the change at http://cr.openjdk.java.net/~dxu/8000333/webrev/. Thanks! -Dan

Review Request: 7186817 - Remove Windows 95/98/ME Support

2012-10-09 Thread Dan Xu
Hi folks, Please help review the code change for CR7186817 to remove Windows 95/98/ME support. The webrev has been uploaded to http://cr.openjdk.java.net/~dxu/7186817/webrev/ http://cr.openjdk.java.net/%7Edxu/7186817/webrev/ The main focus of this clean-up is in IO area. And I also cleaned

Re: Review Request: 7186817 - Remove Windows 95/98/ME Support

2012-10-09 Thread Dan Xu
On 10/09/2012 12:30 PM, Alan Bateman wrote: On 09/10/2012 18:46, Dan Xu wrote: Hi folks, Please help review the code change for CR7186817 to remove Windows 95/98/ME support. The webrev has been uploaded to http://cr.openjdk.java.net/~dxu/7186817/webrev/ http://cr.openjdk.java.net/%7Edxu

Re: Review Request: 7186817 - Remove Windows 95/98/ME Support

2012-10-09 Thread Dan Xu
Am 09.10.2012 19:46, schrieb Dan Xu: Hi folks, Please help review the code change for CR7186817 to remove Windows 95/98/ME support. The webrev has been uploaded to http://cr.openjdk.java.net/~dxu/7186817/webrev/ http://cr.openjdk.java.net/%7Edxu/7186817/webrev/ The main focus of this clean-up

Review Request - JDK-4239752: FileSystem should be a platform-specific class to avoid native code

2012-10-25 Thread Dan Xu
Hi, Please review the code change to avoid native codes when creating the FileSystem object, http://cr.openjdk.java.net/~dxu/4239752/webrev/. In the change, the native codes for windows and unix platforms are removed. Instead, corresponding Java codes are added for each platform. Thanks!

Review Request: JDK-8001565, (fs) Typo Path.endsWith(String) javadoc

2012-10-25 Thread Dan Xu
Hi, Please help review the javadoc typo fix at, http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks! -Dan

Re: Review Request: JDK-8001565, (fs) Typo Path.endsWith(String) javadoc

2012-10-25 Thread Dan Xu
Thank you. Do you need me to generate the patch? -Dan On 10/25/2012 03:12 PM, Mandy Chung wrote: On 10/25/2012 2:45 PM, Dan Xu wrote: Hi, Please help review the javadoc typo fix at, http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks! Looks good with me. I can push this for you

Build Failure in JPRT Job

2013-01-07 Thread Dan Xu
Hi, Today I submitted several jprt jobs asusual, but all jobs failed in building processat the same place. I tried to build jdk locally, and it worked fine. And I also tried to create a new jdk repo from the scratch, and then submitteda job. But the jprt job also failed in the buildwith the

Re: Build Failure in JPRT Job

2013-01-07 Thread Dan Xu
David, Thanks for your reply. I saw other jobs also had the similar jprt command. I wonder why others could succeed in the build. -Dan On Mon 07 Jan 2013 11:20:18 PM PST, David Holmes wrote: Hi Dan, On 8/01/2013 5:11 PM, Dan Xu wrote: Hi, Today I submitted several jprt jobs asusual

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-01-28 Thread Dan Xu
, 21 Jan 2013 23:25:25 -0800 From: Dan Xu dan...@oracle.com To: nio-dev nio-...@openjdk.java.net Hi, Interruptible I/O on Solaris has been highly problematicand undercut portability. And the long term plan is to remove it completely from JDK. In JDK6, the VM option, UseVMInterruptibleIO

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-01-31 Thread Dan Xu
Hi Karen, In my opinion, it is recommemded to use O_CLOEXEC flag directly in open() function than setting it later via fcntl(). And according to the man page on Solaris and Mac, open() behaves the same on those platforms. I only find the support platform list for jdk7 at

Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

2013-02-26 Thread Dan Xu
Hi All, Please help review the fix for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly. Java IO, not like NIO, does not check NUL character in the given file path name, which brings confusion to Java users. This fix is going to address this issue by

Re: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

2013-02-26 Thread Dan Xu
for the underlying operating system or filesystem then perhaps an error should be signalled. Mike On Feb 26 2013, at 16:10 , Dan Xu wrote: Hi All, Please help review the fix for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly. Java IO, not like NIO, does not check NUL

Re: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

2013-02-27 Thread Dan Xu
etc. should throw a specialized Bad Filename FnF for paths containing NUL if the underlying filesystem does not support NUL? Masking garbage input always really scares me. Mike On Feb 27 2013, at 02:40 , Alan Bateman wrote: On 27/02/2013 02:31, Dan Xu wrote: Thank you, Mike. The reason

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-03-05 Thread Dan Xu
Hi All, Thanks for your good suggestions. I have updated this fix and put the new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/. Please help review it. Thanks! -Dan On 02/01/2013 01:25 PM, Alan Bateman wrote: On 01/02/2013 18:12, Martin Buchholz wrote: : My comments are

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-03-11 Thread Dan Xu
Thanks for all your comments. I have updated the fix accordingly. Please see the webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.02/. For the language concern in getLastErrorString(char *buf, size_t len) function, I will log another bug and address it later. Thanks! -Dan On Thu

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-03-12 Thread Dan Xu
On 03/12/2013 08:19 AM, Alan Bateman wrote: On 11/03/2013 23:43, Dan Xu wrote: Thanks for all your comments. I have updated the fix accordingly. Please see the webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.02/. For the language concern in getLastErrorString(char *buf, size_t len

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-03-12 Thread Dan Xu
. Thanks! -Dan On 03/12/2013 02:22 PM, Alan Bateman wrote: On 12/03/2013 18:01, Dan Xu wrote: Hi Alan, Do you mean directly map IO_Append to handleWrite in io_util_md.h for the *nix case? And then where do we check the O_APPEND flag in our code? Or do we require users to open the file

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-03-13 Thread Dan Xu
Thank you for the review. I will push it today. -Dan On 03/13/2013 03:39 AM, Alan Bateman wrote: On 12/03/2013 22:19, Dan Xu wrote: I understand now. Here is the updated webrev to directly map IO_Append to handleWrite in *nix platforms, http://cr.openjdk.java.net/~dxu/8001334/webrev.03/. I

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-03-13 Thread Dan Xu
Thank you for your suggestions. Do you have any old bug in java deployment for my reference? In addition, I wonder whether the same language problem exists when calling strerror() function. Thanks! -Dan On 03/13/2013 04:10 AM, Alexey Utkin wrote: On 12.03.2013 3:43, Dan Xu wrote: Thanks

hg: jdk8/tl/jdk: 8001334: Remove use of JVM_* functions from java.io code

2013-03-13 Thread dan . xu
Changeset: ef0c60b93a17 Author:dxu Date: 2013-03-13 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef0c60b93a17 8001334: Remove use of JVM_* functions from java.io code Summary: Replace JVM_* functions with direct system calls in java io area Reviewed-by: alanb, uta,

Review JDK-8010837 - TEST_BUG: java/io/FileInputStream/LargeFileAvailable.java fails intermittently

2013-03-26 Thread Dan Xu
Hi All, In the old JVM function, os::available, it could return negative values because lseek() allows the file offset to be set beyond the end of a file. In the previous change of removing jvm functions, I wasn't aware of that and regardnegative values as invalid and return 0, which causes

hg: jdk8/tl/jdk: 8010837: FileInputStream.available() throw IOException when encountering negative available values

2013-03-27 Thread dan . xu
Changeset: 49602f599c08 Author:dxu Date: 2013-03-27 09:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49602f599c08 8010837: FileInputStream.available() throw IOException when encountering negative available values Summary: Remove the check in the native code to allow

Re: Review JDK-8010837 - TEST_BUG: java/io/FileInputStream/LargeFileAvailable.java fails intermittently

2013-03-30 Thread Dan Xu
I see. So we will need clarify the spec and make corresponding changes. I think as long as we don't trigger exceptions and just return 0 will be backward-compatible, right? -Dan On 03/30/2013 10:23 AM, Alan Bateman wrote: On 26/03/2013 19:29, Dan Xu wrote: Hi All, In the old JVM function

Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native

2013-04-01 Thread Dan Xu
Hi All, In this fix, I have updated files in JDK libraries to use @Native annotation instead of @GenerateNativeHeader to mark classes that contain no native methods but constants used by native codes. @GenerateNativeHeader was added earlier in the development for JDK8.This has proved

Re: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native

2013-04-03 Thread Dan Xu
change, I only add @Native annotation to constants interested by native codes. And if no such kind of constants and native methods declared, the fix does the clean-up and removes unnecessary header imports. Thanks! -Dan -phil. On 4/1/13 3:16 PM, Dan Xu wrote: Hi All, In this fix, I have updated

hg: jdk8/tl/jdk: 8000406: change files using @GenerateNativeHeader to use @Native

2013-04-04 Thread dan . xu
Changeset: 7b1189bf1d7b Author:dxu Date: 2013-04-04 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b1189bf1d7b 8000406: change files using @GenerateNativeHeader to use @Native Summary: Use @Native annotation to mark constants interested by native codes Reviewed-by:

Review Request: JDK-8011602 - jobjc build failure on Mac

2013-04-05 Thread Dan Xu
Hi All, Please review the change to fix the build issue on mac platformat http://cr.openjdk.java.net/~dxu/8011602/webrev/.It removes the un-necessary @Native annotation from src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. Therefore, the objc compilation will not dependon

Re: Review Request: JDK-8011602 - jobjc build failure on Mac

2013-04-05 Thread Dan Xu
to me - glad there was a simple solution. Still wondering why this didn't get picked up during JPRT testing though ?? Thanks, David On 6/04/2013 9:21 AM, Dan Xu wrote: Right. Even the generated native headers from jobjc are saved into its own directory. Thank you for your review! -Dan On 04

hg: jdk8/tl/jdk: 8011602: jobjc build failure on Mac

2013-04-05 Thread dan . xu
Changeset: 785f3a04ee05 Author:dxu Date: 2013-04-05 17:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/785f3a04ee05 8011602: jobjc build failure on Mac Summary: Remove @Native annotation from macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java Reviewed-by:

Re: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently

2013-04-17 Thread Dan Xu
Hi Eric, Thanks for fixing the test failures. I recently reviewed your changes. And I like your idea to add a base dir to restrict the test only touching files/directories that are created by itself to avoid the interferences from the OS or other test activities. And in Line 341 of

Re: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently

2013-04-17 Thread Dan Xu
On 04/17/2013 02:15 AM, Alan Bateman wrote: On 17/04/2013 07:36, Dan Xu wrote: : In the changes, the usages of NIO classes are not necessary. The test is against java.io packages, and it is better to keep it clean in case it might be used to test old jdk version which does not have NIO. I

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

2013-04-17 Thread Dan Xu
Adding core-libs-dev On 04/17/2013 04:47 PM, Dan Xu wrote: Hi, As for the sourcecodes for mac platform, it has a special place holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I wonder how those codes are builtand whether its compilation process has any special handling

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

2013-04-17 Thread Dan Xu
, David Holmes wrote: Hi Dan, I don't quite understand the question but all native code building is handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn utilizes the set up from top/common/makefiles/NativeCompilation.gmk HTH David On 18/04/2013 9:51 AM, Dan Xu wrote: Adding core

RFR: JDK8011946 - java.util.Currency javadoc has broken link to iso.org

2013-04-17 Thread Dan Xu
Hi All, Here is ajava doc fix. I have changed the broken link and pointed it to the page for standard ISO 4217. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8011946/webrev/ Bug: http://bugs.sun.com/view_bug.do?bug_id=8011946 -Dan

Re: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

2013-05-02 Thread Dan Xu
Hi All, Thanks for all your comments. Based on the previous feedback, I have moved to the other approach, i.e., to fail file operations if the invalid NUL characher is found in a file path. As you know, due to the compatibility issue, we cannot throw an exception immediately in the File

Re: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

2013-05-06 Thread Dan Xu
On 05/06/2013 06:59 AM, Florian Weimer wrote: On 05/03/2013 01:08 AM, Dan Xu wrote: Hi All, Thanks for all your comments. Based on the previous feedback, I have moved to the other approach, i.e., to fail file operations if the invalid NUL characher is found in a file path. As you know, due

hg: jdk8/tl/jdk: 8003992: File and other classes in java.io do not handle embedded nulls properly

2013-05-06 Thread dan . xu
Changeset: bd118033e44c Author:dxu Date: 2013-05-06 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd118033e44c 8003992: File and other classes in java.io do not handle embedded nulls properly Summary: Have every file operation done with File, FileInputStream,

RFR: JDK-8011136 - FileInputStream.available and skip inconsistencies

2013-05-10 Thread Dan Xu
Hi, The FileInputStream.available() method can return a negative value when the file position is beyond the endof afile. This is an unspecified behaviour that has the potential to break applications that expect available to return a value of 0 or greater. The FileInputStream.skip(long)

RFR: JDK-8014360-Optimize and Refactor the Normalize Process in java.io File Systems

2013-05-10 Thread Dan Xu
Hi, The normalize() implementations in UnixFileSystem.java and WinNTFileSystem.java can be improved to make it simpler, easier, and more efficient. I have refactoredthecode when working on JDK-8003992. And Iwould like to send it out for a review in this separate bug. Thanks! webrev:

Re: RFR: JDK-8011136 - FileInputStream.available and skip inconsistencies

2013-05-15 Thread Dan Xu
On 05/13/2013 06:25 AM, Alan Bateman wrote: On 10/05/2013 22:20, Dan Xu wrote: Hi, The FileInputStream.available() method can return a negative value when the file position is beyond the endof afile. This is an unspecified behaviour that has the potential to break applications that expect

hg: jdk8/tl/jdk: 8011136: FileInputStream.available and skip inconsistencies

2013-05-17 Thread dan . xu
Changeset: 3b1450ee2bb9 Author:dxu Date: 2013-05-17 12:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b1450ee2bb9 8011136: FileInputStream.available and skip inconsistencies Summary: Correct the behavior of available() and update related java specs for available() and

RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data

2013-05-28 Thread Dan Xu
Hi All, When File.createTempFile() is called with some special parameters, it runs into infiniteloop and hangs. It is because it does not always mean a file exists when the method, createFileExclusively(), returns false. This fix is going to solve such issues reported in JDK-8013827 and

Re: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently

2013-05-28 Thread Dan Xu
On 05/24/2013 07:07 AM, Alan Bateman wrote: On 24/05/2013 05:19, Eric Wang wrote: Hi Dan All, I have updated the test based on your comments, Can you please review the fix? Thanks! http://cr.openjdk.java.net/~ewang/8009258/webrev.02/ I think this is okay. Dan is going to sponsor this one.

hg: jdk8/tl/jdk: 8009258: TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently

2013-05-28 Thread dan . xu
Changeset: e59d7f0f36f7 Author:ewang Date: 2013-05-28 22:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e59d7f0f36f7 8009258: TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently Reviewed-by: dxu, alanb Contributed-by: yiming.w...@oracle.com !

RFR: JDK-8015628 - Test Failure in closed/java/io/pathNames/GeneralSolaris.java

2013-05-29 Thread Dan Xu
Hi All, The fix to JDK-8009258 solves the failure in GeneralWin32.java. But the changes in Line 311, 312 in checkNames() method of General.java file, lead to the new failure of GeneralSolaris.java testcase. Because it changes the implicit value of an empty ask parameter. This fix is to

Re: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data

2013-05-31 Thread Dan Xu
On 05/29/2013 04:54 AM, Alan Bateman wrote: On 28/05/2013 19:39, Dan Xu wrote: Hi All, When File.createTempFile() is called with some special parameters, it runs into infiniteloop and hangs. It is because it does not always mean a file exists when the method, createFileExclusively

Re: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data

2013-06-01 Thread Dan Xu
On 06/01/2013 03:05 AM, Alan Bateman wrote: On 31/05/2013 19:15, Dan Xu wrote: On 05/29/2013 04:54 AM, Alan Bateman wrote: Thanks for taking this one. The changes mean that IAE is now thrown for cases where it wasn't thrown previously and I'm wondering if this is worth doing. It might

Re: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data

2013-06-10 Thread Dan Xu
On 06/03/2013 03:23 AM, Alan Bateman wrote: On 02/06/2013 03:16, Dan Xu wrote: : As for the SpecialTempFile testcase, I wonder whether these regression tests may happen to be used to test earlier JDK versions. In that case, the thread pool will help the test framework find the test failure

hg: jdk8/tl/jdk: 8013827: File.createTempFile hangs with temp file starting with 'com1.4'; ...

2013-06-10 Thread dan . xu
Changeset: 4a66dd1d7eea Author:dxu Date: 2013-06-10 11:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a66dd1d7eea 8013827: File.createTempFile hangs with temp file starting with 'com1.4' 8011950: java.io.File.createTempFile enters infinite loop when passed invalid data

hg: jdk8/tl/jdk: 8016592: Clean-up Javac Overrides Warnings In javax/management/NotificationBroadcasterSupport.java

2013-06-19 Thread dan . xu
Changeset: f6d72c4f6bf1 Author:dxu Date: 2013-06-19 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6d72c4f6bf1 8016592: Clean-up Javac Overrides Warnings In javax/management/NotificationBroadcasterSupport.java Summary: Add hashCode() methods to ListenerInfo and

hg: jdk8/tl/jdk: 6469160: (fmt) general (%g) formatting of zero (0.0) with precision 0 or 1 throws ArrayOutOfBoundsException

2013-06-24 Thread dan . xu
Changeset: eabcb85fcabc Author:bpb Date: 2013-06-24 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eabcb85fcabc 6469160: (fmt) general (%g) formatting of zero (0.0) with precision 0 or 1 throws ArrayOutOfBoundsException Summary: For zero value ensure than an unpadded

Re: Build error with GCC4.8 on Fedora19

2013-07-08 Thread Dan Xu
Adding build-dev mailing list. On 07/08/2013 09:54 PM, Yasu wrote: Sorry, I forgot to attach a patch: -- diff -r 52454985425d makefiles/CompileNativeLibraries.gmk --- a/makefiles/CompileNativeLibraries.gmk Mon Jul 08 19:24:22 2013 -0700 +++ b/makefiles/CompileNativeLibraries.gmk Tue

hg: jdk8/tl/jdk: 8017212: File.createTempFile requires unnecessary read permission

2013-07-11 Thread dan . xu
Changeset: 10d2a4b1e576 Author:dxu Date: 2013-07-11 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10d2a4b1e576 8017212: File.createTempFile requires unnecessary read permission Summary: Directly call FileSystem method to check a file existence. Also reviewed by

  1   2   >