Hi All,
Thanks for your good review. I have dropped the change in
FileSystemPreferences.java , and created the new webrev which only
changes FileSystemPreferences.c. Please help review it. Thanks!
Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev.01/
When changing FileSystemPreferences.c, I noticed the code like
"JNU_GetStringPlatformChars(env, java_fname, JNI_FALSE)". Because
JNI_FALSE is passed into this function, I am wondering why our code
still release string by calling JNU_ReleaseStringPlatformChars(env,
java_fname, fname). Thanks!
-Dan
On 01/07/2014 01:36 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 update to FIleSystemPreferences.c looks okay but if I read it
correctly then lockFile0 can never return NULL without a pending
exception (meaning that the change to FileSystemPreferences.java could
mask an underlying bug if it existed).
One passing comment is that this native methods could be completely
eliminated here by changing FileSystemPreferences to lock the file via
a FileChannel (use a FileLock as the lock handle). Also the chmod
usage can be eliminated by mkdirs with Files.createDirectory and
specify the permission files when creating the directory. I realize
this is beyond the scope of what you are doing here (but an
opportunity none the less).
-Alan
