hg: jdk8/tl/jdk: 7122887: JDK ignores Gnome3 proxy settings

Changeset: c9562ac9b812 Author:dxu Date: 2013-10-23 22:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9562ac9b812 7122887: JDK ignores Gnome3 proxy settings Summary: Fix GConf and add to use GProxyResolver to handle network proxy resolution Reviewed-by: chegar ! src/sol

RFR: JDK-8027155 - test/java/io/File/NulFile.java failing when test run in othervm mode

Hi All, Here is a simple change to fix the test failure reported in JDK-8027155. Due to the code change in JDK-8025128, this test also needs to be updated. Bug: https://bugs.openjdk.java.net/browse/JDK-8027155 Webrev: http://cr.openjdk.java.net/~dxu/8027155/webrev/ Thanks, -Dan

hg: jdk8/tl/jdk: 8027155: test/java/io/File/NulFile.java failing when test run in othervm mode

Changeset: e93de88661ab Author:dxu Date: 2013-10-31 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e93de88661ab 8027155: test/java/io/File/NulFile.java failing when test run in othervm mode Reviewed-by: mchung, alanb ! test/java/io/File/NulFile.java

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

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 ! test/com/sun/crypto/provider/KeyFactory/TestProviderL

RFR: JDK-8027612, , java/io/File/MaxPathLength.java fails intermittently in the clean-up stage

Hi All, Please review a simple test fix. In the clean-up stage of MaxPathLength.java on windows platform, the delete operation may be interfered by anti-virus software or some Windows services, which will lead to the failure of recursive directory delete operations. In the change, the test wi

Re: RFR: JDK-8027612, , java/io/File/MaxPathLength.java fails intermittently in the clean-up stage

On 1 Nov 2013, at 22:20, Dan Xu wrote: Hi All, Please review a simple test fix. In the clean-up stage of MaxPathLength.java on windows platform, the delete operation may be interfered by anti-virus software or some Windows services, which will lead to the failure of recursive directory delet

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

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 +++ b/test/java/math/BigIn

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

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

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 ! src/solar

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

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)

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 t

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

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 co

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

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 Re

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

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

-test-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 i

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

On 11/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

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 ! test/java/nio/channels/File

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

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

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: http://cr

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

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-with

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

platforms. 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 t

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

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 ha

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

Hi Alan and Chris, Thanks for your review. Unfortunately, my jtreg is still an old version. And when I tried to use /lib/testlibrary, my jprt job also failed. -Dan On 12/10/2013 03:04 AM, Chris Hegarty wrote: On 10 Dec 2013, at 09:10, Alan Bateman wrote: On 08/12/2013 17:29, Dan Xu

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

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

01/06/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

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

6 AM, Alan 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

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

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

TRUE) 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

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

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

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 wrote

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

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

, 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

(!) 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

exception if the field cannot 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 wrote: On 10 Jan 2014, at 18:05, Dan Xu wrote: Hi Roger, My macro is

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

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 wrote: On 14/01/2014 13:56, Chris Hegarty wrote: A recent chang

Code Review Request For 7185340

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 7176485 allows the temporary buffer cache to grow to IOV MAX. Therefore, in Windows

Re: Code Review Request For 7185340

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

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 Buil

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

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 src/share/clas

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

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. make/java/jar/Makefil

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

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 element

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 http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputS

Re: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element

I also uploaded 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

Re: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element

/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) in

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

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 methods. The webrev is at http://cr.openjdk.java.net/~dxu/7193406/webrev.02/. Thanks! -Dan On 08/27/2

Re: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element

by it's {@code 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 t

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

xu/7193406/webrev.02/src/share/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 introduc

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

remove those spaces I put in as a part of this CR. Thanks! Kurchi On 8/28/2012 5:23 PM, Dan Xu wrote: I also thought the space was not needed. But when I made the changes, I found that many similar codes had the space when two or more warning types need to be suppressed. For example, java/util

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

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

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: 7193710 ByteArrayOutputStream Javadoc contains unclosed element

ecified by it's {@code 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 f

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

On 08/29/2012 12:11 PM, Dan Xu wrote: 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

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

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 met

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

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 t

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

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"

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 java/util/pref

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

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

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/ 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

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/%7E

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

allUpper ? s : new String(ca); } It also avoids instantiation of new objects, if there is nothing to change. Note: the equivalent toLower algorithm statistically would be little slower on latin characters, but maybe faster on wide spreaded Unicode characters. -Ulf Am 09.10.2012 19:46, schri

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

another round of code review. But it is a good point to improve our code performance. Please log another bug to address this issue. Thanks! -Dan On Wed 10 Oct 2012 03:58:26 AM PDT, Alan Bateman wrote: On 09/10/2012 21:02, Dan Xu wrote: : There are no code changes when moving them from

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

I see. I was not aware of -Xshare:dump. Thanks, Alan. -Dan On Thu 11 Oct 2012 03:55:34 AM PDT, Alan Bateman wrote: On 11/10/2012 11:42, Alan Bateman wrote: On 10/10/2012 21:18, Dan Xu wrote: Thanks for your good comments. I have changed access modifiers for methods in WinNTFileSystem.java

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

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

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

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

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 s

Re: Build Failure in JPRT Job

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, but

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

ginal Message Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code Date: Mon, 21 Jan 2013 23:25:25 -0800 From: Dan Xu To: nio-dev Hi, Interruptible I/O on Solaris has been highly problematicand undercut portability. And the long ter

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

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 http://www.oracle.co

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

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 remov

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

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

nputStream 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 yo

hg: jdk8/tl/jdk: 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol)

Changeset: 30e30ef6077e Author:dxu Date: 2013-03-01 14:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30e30ef6077e 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Summary: Fix test failures and update java doc of Files.move Reviewed-by

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

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 al

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

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 07

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

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

. 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 with

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

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

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 for

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

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, ma

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

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 t

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

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 nega

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

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 fun

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

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 probl

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

xed soon.) In my 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, I

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

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: ala

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

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 the

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

I merged it with jigsaw at one time. Mandy On 4/5/2013 3:35 PM, Dan Xu wrote: 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

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

Looks okay 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

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

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: mchung,

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

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 General.j

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

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

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

, 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 /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

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

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 const

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

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 to

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

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, FileOutp

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

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) method

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

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: http://c

  1   2   >