hg: jdk7/tl/jdk: 7021582: convert jar/zip code and tests to use try-with-resources
Changeset: 8887cb2f5d19 Author:smarks Date: 2011-02-25 02:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8887cb2f5d19 7021582: convert jar/zip code and tests to use try-with-resources Reviewed-by: alanb, dholmes, sherman ! src/share/classes/java/util/jar/JarFile.java ! test/java/util/jar/JarEntry/GetMethodsReturnClones.java ! test/java/util/jar/JarFile/ScanSignedJar.java ! test/java/util/zip/Available.java ! test/java/util/zip/FileBuilder.java ! test/java/util/zip/GZIP/Accordion.java ! test/java/util/zip/GZIP/GZIPInputStreamRead.java ! test/java/util/zip/InflateIn_DeflateOut.java ! test/java/util/zip/InfoZip.java ! test/java/util/zip/LargeZip.java ! test/java/util/zip/TestEmptyZip.java ! test/java/util/zip/ZipCoding.java ! test/java/util/zip/ZipFile/Assortment.java ! test/java/util/zip/ZipFile/Comment.java ! test/java/util/zip/ZipFile/CopyJar.java ! test/java/util/zip/ZipFile/CorruptedZipFiles.java ! test/java/util/zip/ZipFile/DeleteTempJar.java ! test/java/util/zip/ZipFile/EnumAfterClose.java ! test/java/util/zip/ZipFile/GetDirEntry.java ! test/java/util/zip/ZipFile/LargeZipFile.java ! test/java/util/zip/ZipFile/ManyEntries.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/java/util/zip/ZipFile/ReadAfterClose.java ! test/java/util/zip/ZipFile/ReadZip.java ! test/java/util/zip/ZipFile/ShortRead.java ! test/java/util/zip/zip.java
hg: jdk7/tl/langtools: 7022310: test/tools/javac/diags/Example: args added twice
Changeset: 23b64ad3eec8 Author:jjg Date: 2011-02-25 12:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/23b64ad3eec8 7022310: test/tools/javac/diags/Example: args added twice Reviewed-by: mcimadamore ! test/tools/javac/diags/Example.java
hg: jdk7/tl/jdk: 7016707: Remove the BootClassLoaderHook for jkernel support
Changeset: 5dc98de2a35e Author:mchung Date: 2011-02-25 12:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5dc98de2a35e 7016707: Remove the BootClassLoaderHook for jkernel support Reviewed-by: alanb, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/zip/ZipEntry.java - src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java - test/sun/misc/BootClassLoaderHook/TestHook.java
hg: jdk7/tl/langtools: 7021650: fix Context issues
Changeset: 8f0dcb9499db Author:jjg Date: 2011-02-25 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8f0dcb9499db 7021650: fix Context issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/util/Bark.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java + test/tools/javac/util/context/T7021650.java
hg: jdk7/tl/jdk: 7021939: com.oracle.net is not a NON_CORE_PKGS
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
Re: Code Review 7022269: clean up fscanf usage in soalris networking native code
Chris Hegarty wrote: On 02/25/11 05:22 PM, Michael McMahon wrote: Chris Hegarty wrote: On 02/25/11 02:39 PM, Michael McMahon wrote: Alan Bateman wrote: Chris Hegarty wrote: Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large enough to handle the specified width and the null terminator. http://cr.openjdk.java.net/~chegar/7022269/webrev.00/webrev/ -Chris. Looks okay although slightly inconsistent in that the code in initLocalIfs allows a device name up to 32 chars but the other places it is 20. I don't know what the right answer is. -Alan Would it be better to #define a constant and use constant+1 then where the array is allocated. Maybe use the same 32 byte storage in all places. Not a big deal really. In net/ipv6/addrconf.c (kernel source) they use %8s, but then size the char array using IFNAMSIZ (16). Adding a new definition for the sizing may be a little misleading. We should probably use these values, but then I'd be nervous about making any reductions in size. I guess one issue is that the string width in scanf is always going to be a hardcoded value no matter what definitions you make. And that value has a direct impact on the array sizing. It's common practice to use scanf ( and its variants ) with defined string widths and arrays. You just need to be aware of the potential overflows. For this reason I don't see any value in a #define. Yeah, I was thinking you could do something clever with C string concatenation and/or string macros. But, I don't think there is an easy way to do it. Never mind. Are you ok with the change as is? Yes. -Chris. - Michael
Re: Code Review 7022269: clean up fscanf usage in soalris networking native code
Chris Hegarty wrote: On 02/25/11 02:39 PM, Michael McMahon wrote: Alan Bateman wrote: Chris Hegarty wrote: Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large enough to handle the specified width and the null terminator. http://cr.openjdk.java.net/~chegar/7022269/webrev.00/webrev/ -Chris. Looks okay although slightly inconsistent in that the code in initLocalIfs allows a device name up to 32 chars but the other places it is 20. I don't know what the right answer is. -Alan Would it be better to #define a constant and use constant+1 then where the array is allocated. Maybe use the same 32 byte storage in all places. Not a big deal really. In net/ipv6/addrconf.c (kernel source) they use %8s, but then size the char array using IFNAMSIZ (16). Adding a new definition for the sizing may be a little misleading. We should probably use these values, but then I'd be nervous about making any reductions in size. I guess one issue is that the string width in scanf is always going to be a hardcoded value no matter what definitions you make. And that value has a direct impact on the array sizing. It's common practice to use scanf ( and its variants ) with defined string widths and arrays. You just need to be aware of the potential overflows. For this reason I don't see any value in a #define. Yeah, I was thinking you could do something clever with C string concatenation and/or string macros. But, I don't think there is an easy way to do it. Never mind. - Michael
Re: Code Review 7022269: clean up fscanf usage in soalris networking native code
On 02/25/11 02:39 PM, Michael McMahon wrote: Alan Bateman wrote: Chris Hegarty wrote: Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large enough to handle the specified width and the null terminator. http://cr.openjdk.java.net/~chegar/7022269/webrev.00/webrev/ -Chris. Looks okay although slightly inconsistent in that the code in initLocalIfs allows a device name up to 32 chars but the other places it is 20. I don't know what the right answer is. -Alan Would it be better to #define a constant and use constant+1 then where the array is allocated. Maybe use the same 32 byte storage in all places. Not a big deal really. In net/ipv6/addrconf.c (kernel source) they use %8s, but then size the char array using IFNAMSIZ (16). Adding a new definition for the sizing may be a little misleading. We should probably use these values, but then I'd be nervous about making any reductions in size. I guess one issue is that the string width in scanf is always going to be a hardcoded value no matter what definitions you make. And that value has a direct impact on the array sizing. It's common practice to use scanf ( and its variants ) with defined string widths and arrays. You just need to be aware of the potential overflows. For this reason I don't see any value in a #define. -Chris. - Michael
Re: Code Review 7022269: clean up fscanf usage in soalris networking native code
Alan Bateman wrote: Chris Hegarty wrote: Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large enough to handle the specified width and the null terminator. http://cr.openjdk.java.net/~chegar/7022269/webrev.00/webrev/ -Chris. Looks okay although slightly inconsistent in that the code in initLocalIfs allows a device name up to 32 chars but the other places it is 20. I don't know what the right answer is. -Alan Would it be better to #define a constant and use constant+1 then where the array is allocated. Maybe use the same 32 byte storage in all places. Not a big deal really. - Michael
Re: Code Review 7022269: clean up fscanf usage in soalris networking native code
Chris Hegarty wrote: Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large enough to handle the specified width and the null terminator. http://cr.openjdk.java.net/~chegar/7022269/webrev.00/webrev/ -Chris. Looks okay although slightly inconsistent in that the code in initLocalIfs allows a device name up to 32 chars but the other places it is 20. I don't know what the right answer is. -Alan
Code Review 7022269: clean up fscanf usage in soalris networking native code
Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large enough to handle the specified width and the null terminator. http://cr.openjdk.java.net/~chegar/7022269/webrev.00/webrev/ -Chris.
hg: jdk7/tl/jdk: 7022383: add reference to CR for ReadLongZipFileName test to problem list
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
