March 2011 - core-libs-dev

hg: jdk7/tl/jdk: 7024172: Move BufferPoolMXBean and PlatformLoggingMXBean java.lang.management
by mandy.chung＠oracle.com 29 Mar '11

29 Mar '11

Changeset: 3e001dd50408 Author: mchung Date: 2011-03-29 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3e001dd50408 7024172: Move BufferPoolMXBean and PlatformLoggingMXBean java.lang.management Reviewed-by: alanb + src/share/classes/java/lang/management/BufferPoolMXBean.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java + src/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/package.html - src/share/classes/java/nio/BufferPoolMXBean.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LoggingMXBean.java - src/share/classes/java/util/logging/PlatformLoggingMXBean.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! test/Makefile + test/java/lang/management/BufferPoolMXBean/Basic.java ! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java + test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java + test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java - test/java/nio/BufferPoolMXBean/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java - test/java/util/logging/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java

1 0

RE: 7030249: Eliminate use of LoadLibrary and other clean-ups
by Dmytro Sheyko 29 Mar '11

29 Mar '11

Thanks for cleaning it up. Couple of questions: Why we obtain HMODULE for kernel32 this way: // get handle to kernel32 if (GetModuleHandleExW((GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT), (LPCWSTR)&CreateFileW, &h) != 0) { ... instead of handle = GetModuleHandle("kernel32"); if (handle != NULL) { ... ? Also according to MSDN GetModuleHandleEx requires at minimum "Windows XP" or "Windows Server 2003". It means that we do not support "Windows 2000", right? Thanks, Dmytro > Date: Mon, 28 Mar 2011 16:58:57 +0100 > From: Alan.Bateman(a)oracle.com > To: core-libs-dev(a)openjdk.java.net; Vincent.Ryan(a)oracle.com > Subject: 7030249: Eliminate use of LoadLibrary and other clean-ups > > > There are several places in the Windows native code where win32 > functions are looked up with GetProcAddress after loading the DLL. Many > of these places date back to when the JDK was built on Windows NT. Chris > removed several of them from the network code in a recent change-set > where he was cleaning up some code in that area. While editing > java_props_md.c I also changed the code that uses GetUserName to get the > value for the user.name property it's not set by an environment > variable. This was something Dmytro Sheyko pointed out on this list a > few weeks ago [1]. The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/7030249/webrev/ > > Vinnie - I updated the MS CAPI provider while I was at it, do you mind > reviewing that? I've run the tests in test/sun/security/mscapi to verify. > > -Alan. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-February/005837.h… >

2 3

hg: jdk7/tl/langtools: 4 new changesets
by maurizio.cimadamore＠oracle.com 29 Mar '11

29 Mar '11

Changeset: 2007998f89f2 Author: mcimadamore Date: 2011-03-29 16:40 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2007998f89f2 7030687: Diamond: compiler accepts erroneous code where diamond is used with non-generic inner class Summary: Diamond accepts non-parameterized member inner classes with parameterized outer because of a bad check Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/generics/diamond/7030687/ParserTest.java + test/tools/javac/generics/diamond/7030687/T7030687.java + test/tools/javac/generics/diamond/7030687/T7030687.out Changeset: ddec8c712e85 Author: mcimadamore Date: 2011-03-29 16:40 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ddec8c712e85 7030606: Project-coin: multi-catch types should be pairwise disjoint Summary: Bring javac in sync with latest Project Coin EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/MulticatchTypesMustBeDisjoint.java + test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java + test/tools/javac/multicatch/7030606/T7030606.java + test/tools/javac/multicatch/7030606/T7030606.out Changeset: f5b5112ee1cc Author: mcimadamore Date: 2011-03-29 16:40 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f5b5112ee1cc 7030150: Type inference for generic instance creation failed for formal type parameter Summary: Problem when explicit generic constructor type-arguments are used in conjunction with diamond Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/diamond/7030150/GenericConstructorAndDiamondTest.java + test/tools/javac/generics/diamond/7030150/Neg01.java + test/tools/javac/generics/diamond/7030150/Neg01.out + test/tools/javac/generics/diamond/7030150/Neg02.java + test/tools/javac/generics/diamond/7030150/Neg02.out + test/tools/javac/generics/diamond/7030150/Neg03.java + test/tools/javac/generics/diamond/7030150/Neg03.out + test/tools/javac/generics/diamond/7030150/Pos01.java + test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: de1c65ecfec2 Author: mcimadamore Date: 2011-03-29 16:41 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/de1c65ecfec2 7027157: Project Coin: javac warnings for AutoCloseable.close throwing InterruptedException Summary: javac should warn about use/declaration of AutoCloseable subclasses that can throw InterruptedException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/TryWithResources/InterruptedExceptionTest.java + test/tools/javac/diags/examples/TryResourceThrowsInterruptedExc.java

1 0

7030249: Eliminate use of LoadLibrary and other clean-ups
by Alan Bateman 29 Mar '11

29 Mar '11

There are several places in the Windows native code where win32 functions are looked up with GetProcAddress after loading the DLL. Many of these places date back to when the JDK was built on Windows NT. Chris removed several of them from the network code in a recent change-set where he was cleaning up some code in that area. While editing java_props_md.c I also changed the code that uses GetUserName to get the value for the user.name property it's not set by an environment variable. This was something Dmytro Sheyko pointed out on this list a few weeks ago [1]. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7030249/webrev/ Vinnie - I updated the MS CAPI provider while I was at it, do you mind reviewing that? I've run the tests in test/sun/security/mscapi to verify. -Alan. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-February/005837.h…

4 5

hg: jdk7/tl/jdk: 2 new changesets
by sean.mullan＠oracle.com 29 Mar '11

29 Mar '11

Changeset: b8259e08543b Author: mullan Date: 2011-03-29 10:39 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8259e08543b 7019937: Translatability bug - Remove Unused String - String ID , read end of file 7019938: Translatability bug - Remove Unused String - String ID can not specify Principal with a 7019940: Translatability bug - Remove unused string - String ID: provided null name 7019942: Translatability bug - String ID: trustedCertEntry, 7019945: Translatability bug - Translatability issue - String ID: * has NOT been verified! In order to veri 7019947: Translatability bug - Translatability issue - String ID: * The integrity of the information stored i 7019949: Translatability bug - Translatability issue - String ID: * you must provide your keystore password. Reviewed-by: weijun, wetmore ! src/share/classes/com/sun/security/auth/PolicyParser.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/AuthResources.java ! src/share/classes/sun/security/util/Resources.java Changeset: 77077940fad6 Author: mullan Date: 2011-03-29 11:37 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/77077940fad6 Merge

1 0

Minor performance enhancement on FileInputStream read()
by Jing LV 29 Mar '11

29 Mar '11

Hello, I am reading the code in FileInputStream.read(), I find the current API was: Java_java_io_RandomAccessFile_read(JNIEnv *env, jobject this) readSingle(JNIEnv *env, jobject this, jfieldID fid) It brings a object down into native and as we know reflection costs a lot. I am wondering if we can improve this. I see the real pointer is stored in class FileDescriptor, a quick solution may be: 1. add a method read() in FileDescriptor, and it delgate to a native method read(fd), fd is the real pointer stored 2. modify readSingle(JNIEnv *env, jobject this, jfieldID fid) to readSingle(JNIEnv *env, jobject this, jlong fd) 3. add Java_java_io_FileDescriptor_read(JNIEnv *env, jobject this, jlong fd) in FileDescriptor_md.c, which calls readSingle As FileDescriptor is used in Socket as well, we may add similar approach, i.e, readSocket() etc. And this approach may be available for write and other operations. Any comments? -- Best Regards, Jimmy, Jing LV

2 1

hg: jdk7/tl/jdk: 7031929: Variable names typos in Release-embedded.gmk
by david.holmes＠oracle.com 29 Mar '11

29 Mar '11

Changeset: 19567f9d6962 Author: dholmes Date: 2011-03-29 08:15 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/19567f9d6962 7031929: Variable names typos in Release-embedded.gmk Reviewed-by: alanb ! make/common/Release-embedded.gmk

1 0

Review request for 6381464: "SimpleFormatter should use one single line format"
by Mandy Chung 29 Mar '11

29 Mar '11

6381464: SimpleFormatter should use one single line format This is a follow-up of the review for 7006814. I came up with a better solution that allows a user to customize the output format for SimpleFormatter. You can specify the format string using the java.util.Formatter syntax in a new property: "java.util.logging.SimpleFormatter" that you can customize your own output format. See the javadoc for details: http://cr.openjdk.java.net/~mchung/jdk7/6381464/api/java/util/logging/Simpl… Webrev at: http://cr.openjdk.java.net/~mchung/jdk7/6381464/webrev.00/ Thanks Mandy

3 6

Review Request for 7024172 "Move platform MXBeans to java.lang.management"
by Mandy Chung 29 Mar '11

29 Mar '11

7024172: Move BufferPoolMXBean and PlatformLoggingMXBean to java.lang.management Webrev at: http://cr.openjdk.java.net/~mchung/jdk7/7024172/webrev.00/ javadoc at: http://cr.openjdk.java.net/~mchung/jdk7/7024172/api Problem: java.nio.BufferPoolMXBean and java.util.logging.PlatformLoggingMXBean are new PlatformManagedObject added in JDK 7. However, the management interfaces and its implementation have a dependency on JMX. Having the management interfaces in the same package as its runtime component (e.g. BufferPoolMXBean in java.nio package) leads to split packages. That is, the java.nio.BufferPoolMXBean will be in the management module separated from all other java.nio.* classes that are in the base module which is awkward. Similarly, java.util.logging is split across the management module and the logging module. On the other hand, management interfaces typically are accessed through JMX. In addition, an ObjectName is defined for each platform MXBean as an identifier for remote access. Types referenced by management interfaces are generally the basic types and custom data type specific for monitoring and management purpose. java.nio.BufferPoolMXBean and java.util.logging.PlatformLoggingMXBean do not define attributes of type defined in the java.nio and java.util.logging package. This fix will eliminate the split package situation by moving the management interfaces to another package. These two MXBeans are new and we can set the right precedence for future management interfaces. Summary of Changes: 1. Move java.nio.BufferPoolMXBean to java.lang.management 2. Move java.util.logging.PlatformLoggingMXBean to java.lang.management 3. PlatformLoggingMXBean does not implement java.util.logging.LoggingMXBean but instead it defines the same methods as in LoggingMXBean. 4. java.lang.management.ManagementFactory spec change - Added methods to return a singleton platform MXBean i.e. getPlatformMXBean(Class) and getPlatformMXBean(MBeanServerConnection, Class) method - Replace getAllPlatformMXBeanInterfaces() that returns a List with a new getPlatformManagementInterfaces() method that returns a Set. Thanks Mandy

2 4

hg: jdk7/tl/jdk: 7031166: (pack200) tools/pack200/CommandLineTests.java fail with testsdk on RO filesystem
by kumar.x.srinivasan＠oracle.com 28 Mar '11

28 Mar '11

Changeset: a42760dae179 Author: ksrini Date: 2011-03-28 13:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a42760dae179 7031166: (pack200) tools/pack200/CommandLineTests.java fail with testsdk on RO filesystem Reviewed-by: alanb ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/TimeStamp.java ! test/tools/pack200/Utils.java

1 0