February 2011 - core-libs-dev

hg: jdk7/tl/jdk: 7021939: com.oracle.net is not a NON_CORE_PKGS
by mandy.chung＠oracle.com 25 Feb '11

25 Feb '11

Changeset: 32dc1cb2b995 Author: mchung Date: 2011-02-25 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/32dc1cb2b995 7021939: com.oracle.net is not a NON_CORE_PKGS Reviewed-by: ohair, alanb ! make/common/Release.gmk ! make/docs/NON_CORE_PKGS.gmk

1 0

updated review request for 7021582, use try-with-resources in jar/zip implementation and tests
by Stuart Marks 25 Feb '11

25 Feb '11

Hi all, updated webrev is here: http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.1/ I've removed the pack200 files (i.e. those in src/share/classes/com/sun/java/util/jar/pack) so I can do more thorough deploy/install testing per Kumar's request. The change to PropMap.java, which generated a fair bit of discussion, is actually in the pack200 library so it's no longer part of this webrev. Otherwise there are only a couple changes which shouldn't come as a surprise to anyone: test/java/util/jar/JarEntry/GetMethodsReturnClones.java - use diamond test/java/util/zip/Available.java test/java/util/zip/GZIP/GZIPInputStreamRead.java - unrolled constructors test/java/util/zip/Available.java - add use of TWR for a couple ZipFile instances Thanks, s'marks

2 1

hg: jdk7/tl/jdk: 7022383: add reference to CR for ReadLongZipFileName test to problem list
by stuart.marks＠oracle.com 25 Feb '11

25 Feb '11

Changeset: b74f1b830484 Author: smarks Date: 2011-02-24 22:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b74f1b830484 7022383: add reference to CR for ReadLongZipFileName test to problem list Reviewed-by: ohair ! test/ProblemList.txt

1 0

review request for 7021582, use try-with-resources in jar/zip implementation and tests
by Stuart Marks 25 Feb '11

25 Feb '11

Hi Sherman, all, Here's a webrev to convert code in the jar/zip implementation files and tests to use the new Java 7 try-with-resources construct. http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.0/ There are rather a lot of files, however, most of the changes are pretty straightforward. A typical conversion changes code like this: FileInputStream fis = new FileInputStream(filename); // use fis fis.close(); to this: try (FileInputStream fis = new FileInputStream(filename)) { // use fis } The majority of the conversions are like the above. However, there are a several places where I had to rearrange things either in order to get them to work at all, to improve robustness, or for general cleanup. Some of these are marked with "TODO". I will of course remove these comments before committing the changes. Where you see these comments, you might want to give the code a bit more scrutiny. Specific examples of things to look at follow: * test/java/util/jar/JarEntry/GetMethodsReturnClones.java I had to change the ordering of local variable declarations so that the variable was visible where it's used. TWR introduces a nested block, so obviously a local declared within will have to be moved outside in order to be used outside. This occurs in several other places as well. In some cases initialization order was changed. This shouldn't matter, though, since it's things like opening a file vs. allocating an array. * src/share/classes/com/sun/java/util/jar/pack/Driver.java I narrowed the scope of the open resource. No sense keeping it open any longer than necessary. This occurs in several other places as well. * src/share/classes/com/sun/java/util/jar/pack/PackageReader.java * src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java These changes rely on recent changes to TWR's handling of null resources. Currently, TWR will avoid calling close if the resource is null. Joe checked in this change just last week. Before that, a null resource would generate an unavoidable NPE when it attempted to call close(). Handling of non-null resources is unchanged. I don't think the change to null handling is in a promoted build yet. Is it OK to check in code that depends on it? All tests pass, but that just means that the path where the resource is null isn't tested. * src/share/classes/com/sun/java/util/jar/pack/PropMap.java Narrowed the scope of catch IOException; should be OK since the code that was migrated out cannot throw IOException. * src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java This closes its input after successful processing. I changed this so that it also closes its input if an exception is thrown. * test/java/util/zip/LargeZip.java I've "unrolled" a cascade of constructors into separate resource variables. This also occurs in several other places. Basically code that used to look like this: ZipOutputStream zos = new ZipOutputStream( new BufferedOutputStream( new FileOutputStream(largeFile))); // process zos zos.close(); is converted to this: try (FileOutputStream fos = new FileOutputStream(largeFile); BufferedOutputStream bos = new BufferedOutputStream(fos); ZipOutputStream zos = new ZipOutputStream(bos)) { // process zos } I think this more robust, since it closes the FileOutputStream if an exception occurs during the construction of one of the stacked streams, which the original code did not handle. Since the wrapper streams will close their underlying streams, this will result in redundant close() calls. However, close() is supposed to be idempotent so this should be OK. * test/java/util/zip/ZipFile/DeleteTempJar.java I'm not sure if this properly handles an IOException caused by HttpExchange.close(). Funny, the method isn't declared to throw IOE, but this test did compile and pass. * test/java/util/zip/ZipFile/LargeZipFile.java I changed this to fail the test if close() were to throw IOE. I think this is proper for test code. * test/java/util/zip/ZipFile/ReadZip.java I took the liberty of converting the file copying code to use the new java.nio.file.Files utilities. Well, I'm really following Alan's lead here since he's prompted me to do so in other places a couple times already. :-) Thanks for reviewing! s'marks

5 11

AUTO: I'm off on 25th Feb 2011 (returning 28/02/2011)
by Lakshmi Narasimhan 24 Feb '11

24 Feb '11

I am out of the office until 28/02/2011. Please contact Anshu Verma (ansverma(a)in.ibm.com) for any CL issues. Note: This is an automated response to your message "core-libs-dev Digest, Vol 46, Issue 39" sent on 25/2/11 0:00:46. This is the only notification you will receive while this person is away.

1 0

Review request for 7016707 "Remove the BootClassLoaderHook for jkernel support"
by Mandy Chung 24 Feb '11

24 Feb '11

7016707: Remove the BootClassLoaderHook for jkernel support Webrev at: http://cr.openjdk.java.net/~mchung/7016707/webrev.00/ The sun.jkernel.* classes have been removed from JDK 7: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/e4802c87e5c7 This fix is to remove sun.misc.BootClassLoaderHook that was added to remove classloader dependency on jkernel: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c499401bc138 Thanks Mandy

3 2

hg: jdk7/tl/jdk: 6835668: Use of /usr/include/linux/ files creates a dependence on kernel-headers
by michael.x.mcmahon＠oracle.com 24 Feb '11

24 Feb '11

Changeset: 51ef29aafc1b Author: michaelm Date: 2011-02-24 18:35 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51ef29aafc1b 6835668: Use of /usr/include/linux/ files creates a dependence on kernel-headers Reviewed-by: chegar ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c

1 0

hg: jdk7/tl/langtools: 7018753: tools/javac/varargs/warning/Warn5.java times out on slow machines
by jim.holmlund＠sun.com 24 Feb '11

24 Feb '11

Changeset: 3e30c95da3c6 Author: jjh Date: 2011-02-24 08:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3e30c95da3c6 7018753: tools/javac/varargs/warning/Warn5.java times out on slow machines Summary: Use a single file manager for all JavacTasks Reviewed-by: jjg, mcimadamore ! test/tools/javac/varargs/6199075/T6199075.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java

1 0

Review CR #6611830: UUID thread-safety and performance improvements
by Mike Duigou 24 Feb '11

24 Feb '11

Daniel Aioanei reported via Josh Bloch a data race issue with the UUID accessor and hashCode() methods. I've prepared a webrev with the suggested changes: http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ I've tested the change against the standard UUID tests and did a microbenchmark test of one method, variant(), to see what impact not caching had on performance. Since there was only negligible change in performance vs. the existing UUID implementation I am comfortable with eliminating the cache values. It would appear that a field access plus a shift is not a significant cost over a field access. Mike

6 6

FW: [concurrency-interest] ForkJoin Improvements
by David Holmes 24 Feb '11

24 Feb '11

FYI David Holmes -----Original Message----- From: concurrency-interest-bounces(a)cs.oswego.edu [mailto:concurrency-interest-bounces@cs.oswego.edu]On Behalf Of Doug Lea Sent: Tuesday, 22 February 2011 11:21 AM To: Concurrency-interest(a)cs.oswego.edu Subject: [concurrency-interest] ForkJoin Improvements Another round of improvements to ForkJoin framework is now available in the usual places (see below). The main change is an overhaul to core control that better avoids creating or restarting more threads than needed. You'll probably see better overall performance too. Also, exceptions stemming from user errors are now more informative. Please try these out let us know about any problems. Pasting from http://gee.cs.oswego.edu/dl/concurrency-interest/index.html jsr166y versions * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/ * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166y.jar (compiled using Java6 javac). * Browsable CVS sources: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/ java7 java.util.concurrent versions * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/ * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar * Browsable CVS sources: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/ * Browsable CVS TCK test sources: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/tests/tck/ You may be able to use these versions now, without waiting for JDK releases, by obtaining jsr166 jar and running java using the option -Xbootclasspath/p:jsr166.jar (You may need to precede "jsr166.jar" with its full file path.) _______________________________________________ Concurrency-interest mailing list Concurrency-interest(a)cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest

2 1