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
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
(!) 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
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Changeset: cb373cf43294
Author:dxu
Date: 2013-10-11 09:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb373cf43294
8025712: (props) Possible memory leak in java_props_md.c / ParseLocale
Reviewed-by: naoto, chegar
! src/solaris/native/java/lang/java_props_md.c
obsolete, let alone for MacOSX
platform. So the current code should work fine.
Naoto
On 10/10/13 1:23 PM, Dan Xu wrote:
Good catch, Chris.
Btw, according to the description, it seems the block in #ifndef
__linux__ is the workaround only for Solaris. Shall we use a more strict
macro here instead
.
While looking at this I notice that there is another potential leak.
If the malloc for temp fails, then we need to free lc ( for MAC only
), right?
-Chris.
On 10/09/2013 07:51 PM, Dan Xu wrote:
Hi All,
This fix is to solve the memory leak issue in ParseLocale() function of
jdk/src/solaris
Hi All,
This fix is to solve the memory leak issue in ParseLocale() function of
jdk/src/solaris/native/java/lang/java_props_md.c. Because the locale,
lc, is copied into temp, it is not necessary to do the strdup(), which
leads to the memery leak. The fix simply removes the line of strdup
oper
:43, Alan Bateman wrote:
On 08/10/2013 19:24, Dan Xu wrote:
Hi,
This is a backport request towards 7u-dev repository on bug
JDK-8025128 that I fixed several days ago. It is going to keep the
method, File.createTempFile(), backward compatible. Please help
review it. Thanks!
Bug: https
Hi,
This is a backport request towards 7u-dev repository on bug JDK-8025128
that I fixed several days ago. It is going to keep the method,
File.createTempFile(), backward compatible. Please help review it. Thanks!
Bug: https://bugs.openjdk.java.net/browse/JDK-8026061
Webrev: http://cr.openjdk
Changeset: 754db1268be1
Author:dxu
Date: 2013-09-27 17:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/754db1268be1
8025128: File.createTempFile fails if prefix is absolute path
Summary: Use only the file name from the supplied prefix for backward
compatibility
Reviewed-by
It looks good.
-Dan
On 09/27/2013 03:53 PM, Mike Duigou wrote:
Hello all;
As pointed out by Roger Riggs, Optional.of (and the private Optional(T) constructor)
don't explicitly document throwing NPE in response to a null value despite describing
value as "non-null". This changeset improves t
Hi,
Recently I made changes in TempDirectory.generateFile() method to
prevent using invalidparameters to create temporary files. But such
tight control will bring a compatibility issue. This change is going to
solve theseproblems. Please help review it. Thanks!
Bug: https://bugs.openjdk.java
Changeset: 5b01c851bb1d
Author:dxu
Date: 2013-08-30 16:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b01c851bb1d
8023765: Improve MaxPathLength.java testcase and reduce its test load
7160013: java/io/File/MaxPathLength.java fails
Reviewed-by: alanb
! test/ProblemList.tx
On 08/29/2013 12:20 AM, Alan Bateman wrote:
On 29/08/2013 00:49, Dan Xu wrote:
:
Stuart brought a very good point for this test failure in the main
bug, JDK-7160013. According to his comment, "Bottom line is that a
Windows daemon (not an anti-virus scanner) may hold a file in
d
Changeset: 5bf4f285
Author:dxu
Date: 2013-08-29 10:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bf4f285
4792059: test/java/io/pathNames/GeneralSolaris.java fails on symbolic links
Summary: Exclude the possible usage of linked files or directories in the test
Rev
On 08/27/2013 07:15 AM, Dan Xu wrote:
On 08/27/2013 12:12 AM, Alan Bateman wrote:
On 27/08/2013 01:18, Dan Xu wrote:
Hi All,
MaxPathLength.javais a troublesome testcase, and fails
intermittently in the nightly test. And it also runs for a long
time, especially on Windows platforms. Inorder
Thank you, Alan.
I have updated my webrev to
http://cr.openjdk.java.net/~dxu/4792059/webrev.01/.
-Dan
On 08/28/2013 04:05 AM, Alan Bateman wrote:
On 28/08/2013 00:20, Dan Xu wrote:
Hi,
When GeneralSolaris testcase follows symbolic link to pick up an
existing file or directory for
Hi,
When GeneralSolaris testcase follows symbolic link to pick up an
existing file or directory for testing, it will fail the assertion in
check()method because the file path canonicalization process will result
in the real path not a path containing symbolic link. I enforce this
test not to
On 08/27/2013 12:12 AM, Alan Bateman wrote:
On 27/08/2013 01:18, Dan Xu wrote:
Hi All,
MaxPathLength.javais a troublesome testcase, and fails intermittently
in the nightly test. And it also runs for a long time, especially on
Windows platforms. Inorder to improve the test stability, I remove
Hi All,
MaxPathLength.javais a troublesome testcase, and fails intermittently in
the nightly test. And it also runs for a long time, especially on
Windows platforms. Inorder to improve the test stability, I remove its
unnecessary test iterations, and use NIOdelete method todo the clean-up
to
Changeset: 8a7d9cc2f41c
Author:dxu
Date: 2013-08-22 11:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a7d9cc2f41c
8023430: Replace File.mkdirs with Files.createDirectories to get
MaxPathLength.java failure details
Reviewed-by: alanb
! test/ProblemList.txt
! test/java/io
On 08/20/2013 11:18 PM, Alan Bateman wrote:
On 21/08/2013 01:04, Dan Xu wrote:
Hi,
MaxPathLength.java testcase failed intermittently. And File.mkdirs()
does not throw any exceptions when it fails, which makes it even
harder for the diagnosis. As Alan suggested, I'd like to change
Hi,
MaxPathLength.java testcase failed intermittently. And File.mkdirs()
does not throw any exceptions when it fails, which makes it even harder
for the diagnosis. As Alan suggested, I'd like to change it to
Files.createDirectories to get detailed exceptions once a failure
happens. Thanks!
Changeset: 2fd841fccb2e
Author:dxu
Date: 2013-08-19 12:38 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2fd841fccb2e
8023203: Wrap RandomAccessFile.seek native method into a Java helper method
Reviewed-by: alanb, chegar
! make/java/java/mapfile-vers
! makefiles/mapfiles/lib
HiAll,
Please review the simple change for JDK-8023203 - Wrap
RandomAccessFile.seek native method into a Java helper method. Itadds a
helper java method and makes it the only place that can invoke the
native method directly. Thanks!
Webrev: http://cr.openjdk.java.net/~dxu/8023203/webrev/
Bug
ows drive-relative and directory-relative paths in
particular as these are cases where we would need to confident that it
doesn't break.
As an aside, Dan Xu and I were chatting recently about just replacing
most of the java.io.File implementation to just use java.nio.file.
This specifi
Changeset: 0d27309a87e0
Author:dxu
Date: 2013-08-15 14:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d27309a87e0
8017109: Cleanup overrides warning in
src/solaris/classes/sun/print/AttributeClass.java
Reviewed-by: jgodinez
! src/solaris/classes/sun/print/AttributeClass
Changeset: 5bb196aa183c
Author:dxu
Date: 2013-08-15 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bb196aa183c
4858457: File.getCanonicalPath() throws IOException when invoked with "nul"
(win)
Reviewed-by: alanb
! src/windows/native/java/io/canonicalize_md.c
! test/j
Hi Alan,
Thanks for pointing out. I have updated my fix in the new webrev,
http://cr.openjdk.java.net/~dxu/4858457/webrev.01/. Please take a look!
-Dan
On 08/14/2013 08:22 AM, Alan Bateman wrote:
On 08/08/2013 21:44, Dan Xu wrote:
Hi All,
Windows platforms have reserved a few names for
Looks good to me.
-Dan
On 08/14/2013 11:35 AM, Alan Bateman wrote:
On 14/08/2013 19:35, Xueming Shen wrote:
Hi,
Please help review the trivial change for 8022178.
http://cr.openjdk.java.net/~sherman/console/webrev
System.console() is not specified to throw an IOE. It is supposed to
return a
Changeset: 03822f2389bf
Author:dxu
Date: 2013-08-09 10:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/03822f2389bf
8021977: Opening a file using java.io can throw IOException on Windows
Summary: Remove IOException related error-handling code for backward
compatibility
Rev
Thank you. I will use the updated synopsis for my pushtoday.
-Dan
On 08/09/2013 08:41 AM, mark.reinh...@oracle.com wrote:
2013/8/8 9:26 -0700, dan...@oracle.com:
Webrev: http://cr.openjdk.java.net/~dxu/8021977/webrev.00/
Bug: http://bugs.sun.com/view_bug.do?bug_id=8021977
Looks good, but the
Hi All,
Please review a simple bug fix for JDK8021977. For the backward
compatibility, I have to remove the code that might throw out
IOExceptionin the native side. The issue has never been reported.But it
exists in a possible code path. And it is not easy to write a testcase
for this obvious
Hi All,
Windows platforms have reserved a few names for device usages, and "nul"
is one of them. And Windows API, such as _wfullpath() and
GetFullPathNameW, returns its full path with the prefix "\\.\", which
represents win32 device namespaces.
For example, "nul", whose full path name is "\\
Changeset: d1c82d5bee3f
Author:dxu
Date: 2013-08-07 12:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1c82d5bee3f
8022554: Fix Warnings in sun.invoke.anon Package
Reviewed-by: darcy, mduigou, lancea
! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java
Thank you for your review!
-Dan
On 08/07/2013 12:08 PM, Remi Forax wrote:
On 08/07/2013 08:59 PM, Joe Darcy wrote:
Amended version approved to go back.
Thanks,
-Joe
As one of the guys involved in the design of this API :)
I'm Ok with this change.
Rémi
On 08/07/2013 11:54 AM, D
wed as
unacceptable in modern code.
Cheers,
-Joe
On 08/07/2013 11:36 AM, Dan Xu wrote:
Thanks for your review!
I was thinking of that. But without Class[] on the left, the
compiler just worked fine.
Here is a simple example,
//Main.java
import java.util.*;
public class Main {
publi
:
Why not have Class[] on the left side as well?
Mike
On Aug 7 2013, at 10:49 , Dan Xu wrote:
Hi All,
Please review the simple warning fix in
src/share/classes/sun/invoke/anon/ConstantPoolPatch.java.
webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/
Thanks,
-Dan
Hi All,
Please review the simple warning fix in
src/share/classes/sun/invoke/anon/ConstantPoolPatch.java.
webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/
Thanks,
-Dan
Changeset: 1d21ff5c2b3f
Author:dxu
Date: 2013-08-06 18:16 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d21ff5c2b3f
8022478: Fix Warnings In sun.net.www.protocol.http Package
Reviewed-by: darcy
! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/share/c
Changeset: 4b8b811059db
Author:dxu
Date: 2013-08-06 14:33 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b8b811059db
8022410: Fix Javac Warnings in com.sun.security.auth Package
Reviewed-by: darcy
! src/share/classes/com/sun/security/auth/PolicyFile.java
! src/share/classes
I see. Thanks for your good explanation. The change looks good to me.
-Dan
On 07/18/2013 12:56 AM, Alexey Utkin wrote:
On 7/17/2013 10:29 PM, Dan Xu wrote:
I don't know the difference between (*env)->NewStringUTF(env, buf)
and JNU_NewStringPlatform(env, buf). Does the JNU_NewString
Regards,
-uta
On 7/16/2013 11:07 PM, Dan Xu wrote:
I agree. Is jdk_util.c or jni_util.c or any file under native/common/
a good place?
The fix looks good to me.
One small comment is to get the return value of swprintf() in
win32Error(). If the return value is -1, an error situation needs t
I agree. Is jdk_util.c or jni_util.c or any file under native/common/ a
good place?
The fix looks good to me.
One small comment is to get the return value of swprintf() in
win32Error(). If the return value is -1, an error situation needs to be
handled even though it seems very rare. If it is
I guess Alexey made the changes based on the existing implementation of
JVM_GetLastErrorString() in hotspot, which is os::lasterror(char* buf,
size_t len) in os_windows.cpp.
One comment about the code at line 105 in win32Error().
105 const int errnum = GetLastError();
Since in os_laste
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 tom.
On 06/25/2013 05:25 AM, Alan Bateman wrote:
On 25/06/2013 01:17, Dan Xu wrote:
HiAll,
The fix of JDK-8013827 added an unnecessary "read" permission
requirement in File.createTempFile methods. This change is going to
fix this issue. Please help review it. Thanks!
we
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
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 z
HiAll,
The fix of JDK-8013827 added an unnecessary "read" permission
requirement in File.createTempFile methods. This change is going to fix
this issue. Please help review it. Thanks!
webrev: http://cr.openjdk.java.net/~dxu/8017212/webrev.00/
bug: http://bugs.sun.com/view_bug.do?bug_id=80172
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 Wildca
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
R
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
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
Changeset: f522bbdf2859
Author:dxu
Date: 2013-05-31 13:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f522bbdf2859
8015628: Test Failure in closed/java/io/pathNames/GeneralSolaris.java
Reviewed-by: alanb
! test/java/io/pathNames/General.java
! test/java/io/pathNames/Gener
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
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 rev
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
! test/java/io/pa
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.
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
JDK-8
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 sk
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
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
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
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
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
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
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
1 - 100 of 159 matches
Mail list logo
