February 2011 - core-libs-dev

hg: jdk7/tl/jdk: 7016698: test sun/security/krb5/runNameEquals.sh failed on Ubuntu
by weijun.wang＠oracle.com 11 Feb '11

11 Feb '11

Changeset: de923c0ec3c4 Author: weijun Date: 2011-02-12 07:30 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de923c0ec3c4 7016698: test sun/security/krb5/runNameEquals.sh failed on Ubuntu Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java

1 0

hg: jdk7/tl/jdk: 6742654: Code insertion/replacement attacks against signed jars; ...
by weijun.wang＠oracle.com 11 Feb '11

11 Feb '11

Changeset: 8860e17db3bd Author: weijun Date: 2011-02-12 05:09 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8860e17db3bd 6742654: Code insertion/replacement attacks against signed jars 6911041: JCK api/signaturetest tests fails for Mixed Code PIT builds (b91) for all trains 6921823: JarVerifier csdomain field not initialized 6921839: Update trusted.libraries list Reviewed-by: dgu ! make/java/security/Makefile ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java

1 0

hg: jdk7/tl/jdk: 7007596: (zipfs) FileSystems.newFileSystem(FileRef...) always employs zipfs regardless the real Path type.
by xueming.shen＠oracle.com 11 Feb '11

11 Feb '11

Changeset: 8711aedb08f2 Author: sherman Date: 2011-02-11 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8711aedb08f2 7007596: (zipfs) FileSystems.newFileSystem(FileRef...) always employs zipfs regardless the real Path type. Summary: updated newFileSystem() to throw UOE exception for non-zip/jar file Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh

1 0

Review request for 6927486: Deadlock in legacy Hashtable writeObject()
by Neil Richards 11 Feb '11

11 Feb '11

Please find attached a changeset to address the problem reported in bug 6927486, "Deadlock in legacy Hashtable writeObject()". The problem reported is similar to one found in java.util.Vector, for which a fix is also currently under review (http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005529.h…) This fixes approach is similar to that in Vector - namely to record the objects to be serialized within the synchronization in Hashtable.writeObject(), so that the calls to writeObject() in that method can be moved to beyond the synchronization, thus avoiding the possibility of deadlock. (The calls to writeObject() - for the keys and value of the hashtable's entries - are the last activity within Hashtable.writeObject(), so no additional calls need be delayed). The keys and values to be written out are recorded in a stack of Entry objects, created specially for the task to form a local single-linked list of entries, which is then traversed outside the synchronized block to make the calls to s.writeObject() with each entry's key and value. I believe this is the most efficient means of addressing the problem - any suggestions on how to further improve it gratefully received. As the order of writing out the entries has effectively changed from FIFO to LIFO (as it uses a stack), I have reversed the order the code traverses the table (from low index to high). (I note that the API doc explicitly gives no guarantees as to the order the entries are serialized. Nevertheless, as the initial traversal order was the more uncommon of the two forms, I suspect that there might be some deeper reasoning as to why it was done that way, hence why I've tried to retain its spirit). Any reviews or comment gratefully received, Thanks, Neil PS: The evaluation of this bug suggests that java.util.Random and java.util.PropertyPermission may also be susceptible to serialization deadlock (ie. in addition to Vector and Hashtable). I do not believe this to be case: whilst their writeObject() methods are synchronized, neither class needs to call ObjectOutputStream.writeObject() within them, so the possibility of deadlock there cannot arise. PPS: I notice the API javadoc for PropertyPermission does not give its serialized form (and the "See Also:" section), even though it is Serializable, which strikes me as unusual. I suppose it has no serializable fields of its own (over that which BasicPermission has), but I'm sure I've seen other serializable classes with no fields having "serialized form" entries. -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

4 10

hg: jdk7/tl/jdk: 3 new changesets
by kelly.ohair＠oracle.com 11 Feb '11

11 Feb '11

Changeset: 7bb09178ffc7 Author: ohair Date: 2011-02-10 20:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7bb09178ffc7 7012644: Regression: jdk/make/common/shared/Defs-windows.gmk has problems on cygwin 7018835: Debug build issues in jdk makefiles Reviewed-by: ksrini ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk Changeset: 05a0271173a6 Author: ohair Date: 2011-02-10 20:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05a0271173a6 Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 1dc0c3021d13 Author: ohair Date: 2011-02-11 01:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1dc0c3021d13 Merge

1 0

Some issues on identifying user.name on Windows
by Dmytro Sheyko 11 Feb '11

11 Feb '11

Hi, I noticed following code openjdk-7-ea-src-b127-27_jan_2011\jdk\src\windows\native\java\lang\java_props_md.c /* * User name * We try to avoid calling GetUserName as it turns out to * be surprisingly expensive on NT. It pulls in an extra * 100 K of footprint. */ { WCHAR *uname = _wgetenv(L"USERNAME"); if (uname != NULL && wcslen(uname) > 0) { sprops.user_name = _wcsdup(uname); } else { WCHAR buf[100]; int buflen = sizeof(buf); sprops.user_name = GetUserNameW(buf, &buflen) ? _wcsdup(buf) : L"unknown"; } } In my opinion there are some issues in it. 1. We identify buffer length in bytes but GetUserNameW expects size in wchars. This can lead to buffer overflow. 2. In normal cases user name is allocated in heap (_wcsdup does this), but in problematic case user_name points to the static string "unknown". This can lead to problems once we decide to free memory. 3. Solaris and Linux return "?" in problematic case, but Windows returns "unknown". This seems inconsistent. I believe that Windows should also return "?" in order to make it consistent with Linux and Solaris and to let know whether username is definitely unknown. It's impossible to create user with name "?" because it has a forbidden character. On the other hand it is possible have user with name "unknown" literally, so if java says that user name is "unknown" we can't definitely know whether user is really unknown or he has such a name. I propose following code instead: /* * User name * We try to avoid calling GetUserName as it turns out to * be surprisingly expensive on NT. It pulls in an extra * 100 K of footprint. */ { WCHAR *uname = _wgetenv(L"USERNAME"); if (uname != NULL && wcslen(uname) > 0) { sprops.user_name = _wcsdup(uname); } else { sprops.user_name = IdentifyUserName(); } } static LPWSTR IdentifyUserName() { DWORD buflen = 0; GetUserNameW(0, &buflen); // identify buffer length if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) { // 'buflen' receives the required buffer size in WCHARs, including the terminating null character. LPWSTR result = (LPWSTR) malloc(buflen * sizeof(WCHAR)); if (result) { if (GetUserNameW(result, &buflen)) { return result; } else { free(result); } } } return _wcsdup(L"?"); // allocate username in heap, use impossible username } Regards, Dmytro

2 4

hg: jdk7/tl/jdk: 6604827: JavaDoc for ScriptEngineFactory.getMethodCallSyntax contains an error.
by sundararajan.a＠sun.com 11 Feb '11

11 Feb '11

Changeset: cfd397d86474 Author: sundar Date: 2011-02-11 10:38 +0530 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cfd397d86474 6604827: JavaDoc for ScriptEngineFactory.getMethodCallSyntax contains an error. Reviewed-by: mchung ! src/share/classes/javax/script/ScriptEngineFactory.java

1 0

hg: jdk7/tl/langtools: 6485027: javac incorrectly handles relative paths in manifest classpath
by jonathan.gibbons＠oracle.com 10 Feb '11

10 Feb '11

Changeset: e0c16199b2e0 Author: jjg Date: 2011-02-10 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e0c16199b2e0 6485027: javac incorrectly handles relative paths in manifest classpath Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/Paths.java ! test/tools/javac/Paths/Class-Path.sh + test/tools/javac/Paths/Class-Path2.sh ! test/tools/javac/Paths/Diagnostics.sh

1 0

hg: jdk7/tl/langtools: 7018452: langtools not buildable on Mac
by jonathan.gibbons＠oracle.com 10 Feb '11

10 Feb '11

Changeset: 747a7601b6d6 Author: jjg Date: 2011-02-10 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/747a7601b6d6 7018452: langtools not buildable on Mac Reviewed-by: ohair ! make/build.xml

1 0

hg: jdk7/tl/langtools: 7018098: CacheFSInfo persists too long
by jonathan.gibbons＠oracle.com 10 Feb '11

10 Feb '11

Changeset: a19b1f4f23c9 Author: jjg Date: 2011-02-10 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a19b1f4f23c9 7018098: CacheFSInfo persists too long Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/file/T7018098.java

1 0