From luchsh at linux.vnet.ibm.com Wed Feb 1 02:28:35 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 01 Feb 2012 10:28:35 +0800 Subject: POSIX compatibility change for including wait.h in UNIXProcess_md.c In-Reply-To: <1328006414.12119.32.camel@chalkhill> References: <4F0EA969.5000600@linux.vnet.ibm.com> <4F0EC525.4070507@oracle.com> <4F0FDF85.1060406@linux.vnet.ibm.com> <4F204811.6070707@oracle.com> <1328006414.12119.32.camel@chalkhill> Message-ID: <4F28A353.2020304@linux.vnet.ibm.com> On 01/31/2012 06:40 PM, Neil Richards wrote: > On Thu, 2012-01-26 at 17:45 +0800, Jonathan Lu wrote: >> >> >> I think we forgot to create a bug for this, I've created it >> now: >> >> 7133301: (process) UNIXProcess_md.c should include sys/wait.h >> rather than wait.h >> >> Thanks a lot, Alan! >> >> >> I don't mind pushing it for you but maybe this is something >> that Neil wants to do? >> >> >> Hi Neil, could you please help to push it? >> >> >> -Alan >> >> Cheers! >> - Jonathan >> > Hi Johnathan, > I've now pushed this change [1]. > > Thanks, Alan, for doing the review. > > Regards, > Neil > > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13978750cb87 > Thanks a lot, Neil! - Jonathan From joe.darcy at oracle.com Wed Feb 1 06:24:08 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 31 Jan 2012 22:24:08 -0800 Subject: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods In-Reply-To: <4F26CF12.4090104@oracle.com> References: <4F261549.5090308@oracle.com> <4F263E34.6040805@univ-mlv.fr> <4F26CF12.4090104@oracle.com> Message-ID: <4F28DA88.8010600@oracle.com> Hello, Follow-up below... On 01/30/2012 09:10 AM, Joe Darcy wrote: > On 01/29/2012 10:52 PM, R?mi Forax wrote: >> On 01/30/2012 04:58 AM, Joe Darcy wrote: >>> Hello, >>> >>> As an indirect outgrowth of warnings cleanup day, various categories >>> of warnings can be eliminated by in the use of Cloneable types by >>> overriding the >>> >>> Object clone() >>> >>> method inherited from java.lang.Object with a covariant override >>> such as >>> >>> MyType clone() >>> >>> Please review my changes for >>> >>> 7140820 Add covariant overrides to Collections clone methods >>> http://cr.openjdk.java.net/~darcy/7140820.0/ >>> >>> which add such covariant override clone methods to collections and a >>> few other classes in java.util. Doing a full JDK build with these >>> changes, I've also made alterations to other classes to remove now >>> superfuous casts (casts which are a javac lint warning!) and some >>> unneeded @SuppressWarnings annotations. I also cleaned up a few >>> rawtypes warnings while in editing files in java.util. >>> >>> (Note that the old specListeners method in EventRequestSpecList.java >>> was much buggy; it cast an ArrayList from runtime.specListeners to a >>> Vector.) >>> >>> Thanks, >>> >>> -Joe >> >> WTF ! >> >> while it's maybe a binary compatible change, I haven't take a look to >> all modified classes to be sure >> it's not a source compatible change. > > Adding the covariant override is a binary compatible change because > there would be a bridge method providing the original "Object clone()" > signature. > >> >> People had created class that inherits from ArrayList and override >> clone, >> while it's not a good practice, there is a *lot* of code from pre-1.5 >> days that does exactly that, >> this change will simply break all those codes. >> > > *sigh* > > Yes, I didn't fully consider the source compatibility implications > given that these types can be subclasses; I'll look this over some more. > > (This was meant to be part of a larger effort to review of potentially > overridable clone methods in the JDK. I wrote an annotation processor > to look over the code base to find potential classes to upgrade; I can > refine the processor to look for classes that don't override clone and > are also final or effectively final, having no accessible constructors.) > > Thanks Remi, > > -Joe I've looked into the source compatibility aspects of this change. As a simplification, I considered two versions of the parent Cloneable class: Parent A: Object clone() Parent B: Parent clone() and three versions of the Child with an explicit clone method: Child A: Object clone() Child B: Parent clone() Child C: Child clone() The Child.clone implementations dutifully calls super.clone. Using javac from JDK 7u2 I compiled each version of Child with the proper version of Parent on the classpath as a class file. The results are: Parent A Child A compiles Parent B Child A doesn't compile // Cannot override the bridge method Parent A Child B compiles [* see behavioral compatibility note below] Parent B Child B compiles Parent A Child C compiles Parent B Child C compiles All terms of binary compatibility, the continued ability to link, each version of Child when compiled against Parent A, linked against either Parent A or Parent B. In other words, adding the covariant overrides in Parent is a binary compatible change. In terms of behavioral compatibility, each version of Child when compiled against Parent A, ran against either Parent A or Parent B *except* for Child B compiled against Parent A and run against Parent B, which gave a stack overflow error. In the problematic case, we have the new expected clone methods in the class file of Parent B: public Parent clone(); flags: ACC_PUBLIC ... public java.lang.Object clone() throws java.lang.CloneNotSupportedException; flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokevirtual #10 // Method clone:()LParent; 4: areturn LineNumberTable: line 1: 0 Exceptions: throws java.lang.CloneNotSupportedException and in the class file of Child B compiled against Parent A public Parent clone(); flags: ACC_PUBLIC Code: stack=2, locals=2, args_size=1 0: aload_0 1: invokespecial #2 // Method Parent.clone:()Ljava/lang/Object; ... public java.lang.Object clone(); flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokevirtual #8 // Method clone:()LParent; 4: areturn LineNumberTable: line 1: 0 So, what happens executing the seemingly innocent code Object o = (new Child()).clone(); that gets compiled to byte code 7: invokevirtual #8 // Method clone:()LParent; is that the "Parent clone()" method on Child gets called. This in turns calls the "Object clone()" method on Parent. The "Object clone" method in Parent is a bridge method and does an invoke virtual on "Parent clone", which starts the cycle all over. In the end the following stack trace is generated: at Parent.clone(Parent.java:1) at Child.clone(Child.java:12) at Parent.clone(Parent.java:1) at Child.clone(Child.java:12) ... So, as long as the Child class either: * Didn't override clone at all * Overrode clone to return Child then all is well. There are different problems if Child overrode clone to return Object or to return Parent. The JDK generally doesn't promise 100% source compatibility between major releases so the Parent B + Child A scenario doesn't necessarily disqualify this change. (I think much more code would benefit from the covariant return on core collections than be harmed by it.) Having Child override clone to return Parent would be weird and presumably rare. So adding the covariant overrides of clone has a larger compatibility impact than I expected, but I'm still considering going cautiously forward with the work. If it does go forward, I'd grudgingly acknowledge it might have to be backed out later in the release if there was too large a compatibility impact in practice. -Joe From frederic.parain at oracle.com Wed Feb 1 14:41:59 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 01 Feb 2012 14:41:59 +0000 Subject: hg: jdk8/tl/jdk: 7120974: ManagementPermission "control" needs clarification Message-ID: <20120201144209.CB370472DA@hg.openjdk.java.net> Changeset: ac26d04e76c3 Author: fparain Date: 2012-02-01 03:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac26d04e76c3 7120974: ManagementPermission "control" needs clarification Reviewed-by: mchung, dholmes ! src/share/classes/java/lang/management/ManagementPermission.java From Alan.Bateman at oracle.com Wed Feb 1 15:18:51 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Feb 2012 15:18:51 +0000 Subject: 7140918: Remove dependency on apt and com.sun.mirror API In-Reply-To: <4F2956A3.1030808@oracle.com> References: <4F26B283.8090103@oracle.com> <4F273AD3.5070207@oracle.com> <4F274012.7090904@oracle.com> <4F274146.9050103@oracle.com> <4F27A17A.1020809@oracle.com> <4F2956A3.1030808@oracle.com> Message-ID: <4F2957DB.4090401@oracle.com> On 01/02/2012 15:13, Miroslav Kos wrote: > Hi Alan, > do you have any update about approving the changeset? The jaxws bundle > is already in place, so there should be nothing blocking us from the > final step(?) I plan to push it later this week once I've verified the the downloads and done a few test builds with and without ALLOW_DOWNLOADS. -Alan. From kumar.x.srinivasan at oracle.COM Wed Feb 1 21:37:27 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 01 Feb 2012 13:37:27 -0800 Subject: Review request : 7141141 Add 3 new test scenarios for testing Main-Class attribute in jar manifest file Message-ID: <4F29B097.6080400@oracle.COM> Hi, Here are some improvements to the launcher tests, contributed by Sonali Goel of the SQE team, please review: http://cr.openjdk.java.net/~ksrini/7141141/webrev.0/ The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141141 Thanks Kumar From bradford.wetmore at oracle.com Thu Feb 2 00:01:09 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Thu, 02 Feb 2012 00:01:09 +0000 Subject: hg: jdk8/tl/jdk: 7141910: Incorrect copyright dates on new test cases. Message-ID: <20120202000134.BD9E2472E6@hg.openjdk.java.net> Changeset: 55a82eba1986 Author: wetmore Date: 2012-02-01 16:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55a82eba1986 7141910: Incorrect copyright dates on new test cases. Reviewed-by: mullan ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh From joe.darcy at oracle.com Thu Feb 2 00:46:38 2012 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 01 Feb 2012 16:46:38 -0800 Subject: Review request : 7141141 Add 3 new test scenarios for testing Main-Class attribute in jar manifest file In-Reply-To: <4F29B097.6080400@oracle.COM> References: <4F29B097.6080400@oracle.COM> Message-ID: <4F29DCEE.8060509@oracle.com> Hello, On 2/1/2012 1:37 PM, Kumar Srinivasan wrote: > Hi, > > Here are some improvements to the launcher tests, contributed by Sonali > Goel of the SQE team, please review: > > http://cr.openjdk.java.net/~ksrini/7141141/webrev.0/ > > The CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141141 > > Thanks > Kumar > A few stylistic comments: 29 * @compile -XDignore.symbol.file MainClassAttributeTest.java It might suffice to use @build instead of @compile. 43 * only English is seleced and will pass vacuosly for other locales. 44 * 45 */ Extra line. 98 public static void main(String[] args) throws Throwable { Is it necessary to throw Throwable here? Otherwise looks fine. -Joe From schlosna at gmail.com Thu Feb 2 01:48:38 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Wed, 1 Feb 2012 20:48:38 -0500 Subject: Review request : 7141141 Add 3 new test scenarios for testing Main-Class attribute in jar manifest file In-Reply-To: <4F29DCEE.8060509@oracle.com> References: <4F29B097.6080400@oracle.COM> <4F29DCEE.8060509@oracle.com> Message-ID: On Wed, Feb 1, 2012 at 7:46 PM, Joseph Darcy wrote: > ?43 ?* only English is seleced and will pass vacuosly for other locales. Pedantic I know, but can you correct the two spelling mistakes in MainClassAttributeTest.java? s/seleced/selected/ s/vacuosly/vacuously/ 43 * only English is seleced and will pass vacuosly for other locales. ^^ ^^ Thanks, Dave From kumar.x.srinivasan at oracle.COM Thu Feb 2 03:47:00 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 01 Feb 2012 19:47:00 -0800 Subject: Review request : 7141141 Add 3 new test scenarios for testing Main-Class attribute in jar manifest file In-Reply-To: <4F29DCEE.8060509@oracle.com> References: <4F29B097.6080400@oracle.COM> <4F29DCEE.8060509@oracle.com> Message-ID: <4F2A0734.5070001@oracle.COM> Hi Joe, David, Thanks for the feedback, here is the modified delta webrev: http://cr.openjdk.java.net/~ksrini/7141141/webrev.1/webrev.delta/index.html Changes are: * Eliminated typos and fixed the comments * Replaced @compile with @build * Replaced Throwable with IOException this makes it consistent. Thanks Kumar > Hello, > > On 2/1/2012 1:37 PM, Kumar Srinivasan wrote: >> Hi, >> >> Here are some improvements to the launcher tests, contributed by Sonali >> Goel of the SQE team, please review: >> >> http://cr.openjdk.java.net/~ksrini/7141141/webrev.0/ >> >> The CR: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141141 >> >> Thanks >> Kumar >> > > A few stylistic comments: > > 29 * @compile -XDignore.symbol.file MainClassAttributeTest.java > > It might suffice to use @build instead of @compile. > > 43 * only English is seleced and will pass vacuosly for other locales. > 44 * > 45 */ > > Extra line. > > 98 public static void main(String[] args) throws Throwable { > > Is it necessary to throw Throwable here? > > Otherwise looks fine. > > -Joe From joe.darcy at oracle.com Thu Feb 2 19:26:55 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 02 Feb 2012 11:26:55 -0800 Subject: Review request : 7141141 Add 3 new test scenarios for testing Main-Class attribute in jar manifest file In-Reply-To: <4F2A0734.5070001@oracle.COM> References: <4F29B097.6080400@oracle.COM> <4F29DCEE.8060509@oracle.com> <4F2A0734.5070001@oracle.COM> Message-ID: <4F2AE37F.2030101@oracle.com> Looks fine, -Joe On 2/1/2012 7:47 PM, Kumar Srinivasan wrote: > Hi Joe, David, > > Thanks for the feedback, here is the modified delta webrev: > http://cr.openjdk.java.net/~ksrini/7141141/webrev.1/webrev.delta/index.html > > > Changes are: > * Eliminated typos and fixed the comments > * Replaced @compile with @build > * Replaced Throwable with IOException this makes it consistent. > > Thanks > Kumar > > >> Hello, >> >> On 2/1/2012 1:37 PM, Kumar Srinivasan wrote: >>> Hi, >>> >>> Here are some improvements to the launcher tests, contributed by Sonali >>> Goel of the SQE team, please review: >>> >>> http://cr.openjdk.java.net/~ksrini/7141141/webrev.0/ >>> >>> The CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141141 >>> >>> Thanks >>> Kumar >>> >> >> A few stylistic comments: >> >> 29 * @compile -XDignore.symbol.file MainClassAttributeTest.java >> >> It might suffice to use @build instead of @compile. >> >> 43 * only English is seleced and will pass vacuosly for other >> locales. >> 44 * >> 45 */ >> >> Extra line. >> >> 98 public static void main(String[] args) throws Throwable { >> >> Is it necessary to throw Throwable here? >> >> Otherwise looks fine. >> >> -Joe > From Roger.Riggs at oracle.com Thu Feb 2 20:15:41 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 02 Feb 2012 15:15:41 -0500 Subject: Need reviewer: JDK 8 CR for Support Integer overflow Message-ID: <4F2AEEED.8090805@oracle.com> There is a need for arithmetic operations that throw exceptions when the results overflow the representation of int or long. The CR is 6708398: Support integer overflow Please review this webrev to add static methods in java.lang.Math to support addExact(), subtractExact(), negateExact(), multiplyExact(), and toIntExact() for int and long primitive types. Thanks, Roger Riggs From kumar.x.srinivasan at oracle.com Thu Feb 2 23:39:04 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 02 Feb 2012 23:39:04 +0000 Subject: hg: jdk8/tl/jdk: 7141141: Add 3 new test scenarios for testing Main-Class attribute in jar manifest file Message-ID: <20120202233921.C8DF147321@hg.openjdk.java.net> Changeset: 24478d62d068 Author: ksrini Date: 2012-02-02 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24478d62d068 7141141: Add 3 new test scenarios for testing Main-Class attribute in jar manifest file Reviewed-by: ksrini, darcy Contributed-by: sonali.goel at oracle.com ! test/tools/launcher/Arrrghs.java + test/tools/launcher/MainClassAttributeTest.java From fweimer at bfk.de Fri Feb 3 08:11:27 2012 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 03 Feb 2012 08:11:27 +0000 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <4F2AEEED.8090805@oracle.com> (Roger Riggs's message of "Thu, 02 Feb 2012 15:15:41 -0500") References: <4F2AEEED.8090805@oracle.com> Message-ID: <82mx901gls.fsf@mid.bfk.de> * Roger Riggs: > to support addExact(), subtractExact(), negateExact(), multiplyExact(), > and toIntExact() for int and long primitive types. Would it make sense to replace (x ^ r) < 0 && (x ^ y) >= 0 in + public static int addExact(int x, int y) { + int r = x + y; + if ((x ^ r) < 0 && (x ^ y) >= 0) { + throw new ArithmeticException("Addition overflows an int"); + } + return r; + } with (x ^ y ^ r) < 0? For substraction, you could use ((x ^ r) & (x ^ y)) < 0. Will Hotspot be able to optimize away the string construction on the exception path in multiplyExact() if the exception is caught locally? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From rednaxelafx at gmail.com Fri Feb 3 08:38:29 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 3 Feb 2012 16:38:29 +0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <82mx901gls.fsf@mid.bfk.de> References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> Message-ID: Hi Florian, On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer wrote: > Will Hotspot be able to optimize away the string construction on the > exception path in multiplyExact() if the exception is caught locally? > > At least -XX:+OptimizeStringConcat should remove the need to construct a StringBuilder instance, in multiplyExact()'s case. Cc'ing hotspot-compiler-dev for confirmation. - Kris From luchsh at linux.vnet.ibm.com Fri Feb 3 08:47:22 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 03 Feb 2012 16:47:22 +0800 Subject: Problem of using malloc() without including stdlib.h In-Reply-To: References: <4F168084.4080305@linux.vnet.ibm.com> <4F1707B6.4060302@oracle.com> Message-ID: <4F2B9F1A.2050203@linux.vnet.ibm.com> Sorry for being absent from this thread so long, I just experienced couple of days with very limited Internet access. Actually the problem was firstly found on AIX platform, on which sizeof(malloc(1)) without including will always give 4 instead of 8. The symptom was runtime segment error not compiling time warnings, and I suspect there're more failures which were not covered in my application. I've checked the build log of Linux64 platform, as Phil mentioned there's also no such warnings except for the hotspot diagnostic ones. One reason might be that some code inlcudes "malloc.h" instead of , there's one 'extern' definition in malloc.h on Linux 64 platform, but I do not see one on AIX platform. I've also tried to trace the indirect reference relation ship for all the .c/.cpp files using malloc(), still cannot determine a explicit definition of following files. pls fix me if anything wrong, because the list is produced manually :( ./src/share/native/sun/awt/splashscreen/splashscreen_png.c ./src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c ./src/share/native/sun/awt/splashscreen/splashscreen_gif.c ./src/share/native/sun/awt/splashscreen/splashscreen_impl.c ./src/share/native/sun/awt/image/dither.c ./src/share/native/sun/font/layout/KernTable.cpp ./src/share/native/sun/java2d/cmm/lcms/cmserr.c ./src/share/native/com/sun/media/sound/PlatformMidi.c ./src/share/bin/jli_util.c ./src/share/back/debugInit.c ./src/share/demo/jvmti/hprof/hprof_init.c ./src/share/demo/jvmti/hprof/hprof_table.c ./src/share/demo/jvmti/hprof/hprof_util.c ./src/windows/native/java/lang/ProcessImpl_md.c ./src/windows/native/java/lang/java_props_md.c ./src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ./src/windows/native/java/io/dirent_md.c ./src/windows/native/java/io/io_util_md.c ./src/windows/native/sun/awt/splashscreen/splashscreen_sys.c ./src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ./src/windows/native/sun/windows/awt_new.cpp ./src/windows/native/sun/windows/CmdIDList.cpp ./src/windows/native/sun/nio/ch/DatagramDispatcher.c ./src/windows/native/sun/nio/ch/SocketDispatcher.c ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiIn.cpp ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Ports.c ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Util.c ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiOut.c ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ./src/solaris/native/sun/java2d/x11/XRBackendNative.c ./src/solaris/native/sun/java2d/x11/X11SurfaceData.c ./src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c ./src/solaris/native/sun/java2d/x11/X11Renderer.c For a simple HelloWorld.c, if we use malloc() without including stdlib.h, it will give warnings like "warning: incompatible implicit declaration of built-in function ?malloc?". No such warning were found from the build log for above files, so I guess there must be some headers has got indirect including or declaration of malloc.h, but I'm worried because I did not see one via manual search. It indeed sounds reasonable to me that if no warnings are produced and the compilation runs OK, we may just leave the code untouched, but it will improve portability if we can explicitly includes standard C library headers in the right place (of cause, the 'right' place is also something need to be discussed), right? And for the 3rd party libraries, for those whose code has been shipped with OpenJDK source, they seem OK to me since malloc() has either been included or redefined. But for some dependency libraries of compilation, such as X11 dev, are they also trustworthy? Best regards! - Jonathan On 01/19/2012 02:31 AM, Kelly O'Hair wrote: > A webrev and a code review from the appropriate teams is indeed needed. > > -kto > > On Jan 18, 2012, at 9:56 AM, Phil Race wrote: > >> Its arguable, whether harmless or not, that each file needs to include it. >> Its not unreasonable for an area of the code to have a header file such as "awt.h" >> that is supposed to be the one that's included by the other files in that area of >> the code, and which takes care of common includes. jni_util.h is not necessarily it. >> There isn't a need for every file to include that. >> Also many files are 3rd party libs and I don't like editing those as the changes >> really belong upstream. >> So a one size fits all approach might be the answer but I'd want to make sure >> of that first. >> >> So I'd like to see the list of files that generate actual warnings as well as the list >> of files that reference malloc but don't include stdlib.h. >> >> We are well aware that returning int as a default is bad in 64 bit .. I'd expect >> instant death so I'd like to see those actual warnings rather than just the >> theoretical ones. >> >> My grep of a current JDK 8 build log for 64 bit Linux shows the only malloc warnings >> are in hotspot management code. So I am waiting for the proof of the real problem >> >> And I can speak for 2d, and if there's 2D files touched I would like to see any changes >> to those files, and the reasoning discussed on 2d-dev .. >> >> -phil. >> >> On 1/18/2012 8:26 AM, Kelly O'Hair wrote: >>> On Jan 18, 2012, at 12:19 AM, Jonathan Lu wrote: >>> >>>> Hi core-libs-dev, >>>> >>>> I found that for some native code of OpenJDK code base, malloc() is used without including header file stdlib.h, such as following files, >>>> ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c >>>> ./src/solaris/native/sun/java2d/x11/XRBackendNative.c >>>> .... >>>> >>>> I assume that there's no hacking tricks involved here, right? because this may cause problem for some C compilers, which assumes 'int' as the default return type of a function if it cannot find the function's declaration during compiling. Under such a condition, actual return result of type 'void*' from malloc() will be converted to 'int', which may result in truncated pointers in 64bit platforms. If the application tries to dereference such a broken pointer, error will occur. >>>> >>>> Indeed I found some indirect includes of stdlib.h, but there're still some I do not see a stdlib.h get included from any of the direct/indirect included headers. I think in order to fix this problem, two approaches may be considered here, >>>> a) add "#include" to every missing .c file. >>>> b) add "#include" to a commonly referenced header file, such as jni_util.h. but it would not be easy to find such a file for all and creating one is the same as approach a). >>>> >>> I suggest a) It should be harmless and is the right thing to do. >>> >>> It's been a while since I studied the C standard, but I vaguely recall that there was another standard C include file >>> that would cause the malloc() prototype declaration to show up. >>> Or maybe it wasn't a standard one. In any case, I think your a) approach is correct and I don't see much a need >>> for detailed discussions on this, as long as it builds correctly with no warnings on all platforms. It should be fine and correct. >>> That's my 2 cents. >>> >>> -kto >>> >>>> But both methods need to change many files, any other ideas about how to fix it more elegantly? >>>> >>>> Thanks and best regards! >>>> - Jonathan >>>> From eamonn at mcmanus.net Fri Feb 3 12:02:55 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 3 Feb 2012 04:02:55 -0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <82mx901gls.fsf@mid.bfk.de> References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> Message-ID: On 3 February 2012 00:11, Florian Weimer wrote: > Would it make sense to replace (x ^ r) < 0 && (x ^ y) >= 0 > with (x ^ y ^ r) < 0? That would not be correct. For example, it would signal overflow for -1 + 1. ?amonn On 3 February 2012 00:11, Florian Weimer wrote: > * Roger Riggs: > > > to support addExact(), subtractExact(), negateExact(), multiplyExact(), > > and toIntExact() for int and long primitive types. > > Would it make sense to replace (x ^ r) < 0 && (x ^ y) >= 0 > in > > + public static int addExact(int x, int y) { > + int r = x + y; > + if ((x ^ r) < 0 && (x ^ y) >= 0) { > + throw new ArithmeticException("Addition overflows an int"); > + } > + return r; > + } > > with (x ^ y ^ r) < 0? > > For substraction, you could use ((x ^ r) & (x ^ y)) < 0. > > Will Hotspot be able to optimize away the string construction on the > exception path in multiplyExact() if the exception is caught locally? > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > From fweimer at bfk.de Fri Feb 3 12:12:07 2012 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 03 Feb 2012 12:12:07 +0000 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: (Eamonn McManus's message of "Fri, 3 Feb 2012 04:02:55 -0800") References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> Message-ID: <821uqcyv3c.fsf@mid.bfk.de> * Eamonn McManus: > On 3 February 2012 00:11, Florian Weimer wrote: >> Would it make sense to replace (x ^ r) < 0 && (x ^ y) >= 0 >> with (x ^ y ^ r) < 0? > > That would not be correct. For example, it would signal overflow for -1 + 1. Oops. But there has to be a way to implement this using just one comparison. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From anthony.petrov at oracle.com Fri Feb 3 13:51:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 03 Feb 2012 17:51:22 +0400 Subject: Problem of using malloc() without including stdlib.h In-Reply-To: <4F2B9F1A.2050203@linux.vnet.ibm.com> References: <4F168084.4080305@linux.vnet.ibm.com> <4F1707B6.4060302@oracle.com> <4F2B9F1A.2050203@linux.vnet.ibm.com> Message-ID: <4F2BE65A.9040200@oracle.com> Hi Jonathan, Let's consider e.g. src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c mentioned by you below. It #includes splashscreen_impl.h. This file #includes splashscreen_config.h. And finally, src/solaris/native/sun/awt/splashscreen/splashscreen_config.h #includes the stdlib.h explicitly. So, do you still see any issues with java_awt_SplashScreen.c? Could you please go through your list and verify carefully whether these files actually #include stdlib.h or not? -- best regards, Anthony On 2/3/2012 12:47 PM, Jonathan Lu wrote: > > Sorry for being absent from this thread so long, I just experienced > couple of days with very limited Internet access. > > Actually the problem was firstly found on AIX platform, on which > sizeof(malloc(1)) without including will always give 4 > instead of 8. The symptom was runtime segment error not compiling time > warnings, and I suspect there're more failures which were not covered in > my application. > > I've checked the build log of Linux64 platform, as Phil mentioned > there's also no such warnings except for the hotspot diagnostic ones. > One reason might be that some code inlcudes "malloc.h" instead of > , there's one 'extern' definition in malloc.h on Linux 64 > platform, but I do not see one on AIX platform. I've also tried to trace > the indirect reference relation ship for all the .c/.cpp files using > malloc(), still cannot determine a explicit definition of following > files. pls fix me if anything wrong, because the list is produced > manually :( > > ./src/share/native/sun/awt/splashscreen/splashscreen_png.c > ./src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c > ./src/share/native/sun/awt/splashscreen/splashscreen_gif.c > ./src/share/native/sun/awt/splashscreen/splashscreen_impl.c > ./src/share/native/sun/awt/image/dither.c > ./src/share/native/sun/font/layout/KernTable.cpp > ./src/share/native/sun/java2d/cmm/lcms/cmserr.c > ./src/share/native/com/sun/media/sound/PlatformMidi.c > ./src/share/bin/jli_util.c > ./src/share/back/debugInit.c > ./src/share/demo/jvmti/hprof/hprof_init.c > ./src/share/demo/jvmti/hprof/hprof_table.c > ./src/share/demo/jvmti/hprof/hprof_util.c > ./src/windows/native/java/lang/ProcessImpl_md.c > ./src/windows/native/java/lang/java_props_md.c > ./src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c > ./src/windows/native/java/io/dirent_md.c > ./src/windows/native/java/io/io_util_md.c > ./src/windows/native/sun/awt/splashscreen/splashscreen_sys.c > ./src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c > ./src/windows/native/sun/windows/awt_new.cpp > ./src/windows/native/sun/windows/CmdIDList.cpp > ./src/windows/native/sun/nio/ch/DatagramDispatcher.c > ./src/windows/native/sun/nio/ch/SocketDispatcher.c > ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiIn.cpp > ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Ports.c > ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp > ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_Util.c > ./src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiOut.c > ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c > ./src/solaris/native/sun/java2d/x11/XRBackendNative.c > ./src/solaris/native/sun/java2d/x11/X11SurfaceData.c > ./src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c > ./src/solaris/native/sun/java2d/x11/X11Renderer.c > > For a simple HelloWorld.c, if we use malloc() without including > stdlib.h, it will give warnings like "warning: incompatible implicit > declaration of built-in function ?malloc?". No such warning were found > from the build log for above files, so I guess there must be some > headers has got indirect including or declaration of malloc.h, but I'm > worried because I did not see one via manual search. It indeed sounds > reasonable to me that if no warnings are produced and the compilation > runs OK, we may just leave the code untouched, but it will improve > portability if we can explicitly includes standard C library headers in > the right place (of cause, the 'right' place is also something need to > be discussed), right? > > And for the 3rd party libraries, for those whose code has been shipped > with OpenJDK source, they seem OK to me since malloc() has either been > included or redefined. But for some dependency libraries of compilation, > such as X11 dev, are they also trustworthy? > > Best regards! > - Jonathan > > On 01/19/2012 02:31 AM, Kelly O'Hair wrote: >> A webrev and a code review from the appropriate teams is indeed needed. >> >> -kto >> >> On Jan 18, 2012, at 9:56 AM, Phil Race wrote: >> >>> Its arguable, whether harmless or not, that each file needs to >>> include it. >>> Its not unreasonable for an area of the code to have a header file >>> such as "awt.h" >>> that is supposed to be the one that's included by the other files in >>> that area of >>> the code, and which takes care of common includes. jni_util.h is not >>> necessarily it. >>> There isn't a need for every file to include that. >>> Also many files are 3rd party libs and I don't like editing those as >>> the changes >>> really belong upstream. >>> So a one size fits all approach might be the answer but I'd want to >>> make sure >>> of that first. >>> >>> So I'd like to see the list of files that generate actual warnings as >>> well as the list >>> of files that reference malloc but don't include stdlib.h. >>> >>> We are well aware that returning int as a default is bad in 64 bit .. >>> I'd expect >>> instant death so I'd like to see those actual warnings rather than >>> just the >>> theoretical ones. >>> >>> My grep of a current JDK 8 build log for 64 bit Linux shows the only >>> malloc warnings >>> are in hotspot management code. So I am waiting for the proof of the >>> real problem >>> >>> And I can speak for 2d, and if there's 2D files touched I would like >>> to see any changes >>> to those files, and the reasoning discussed on 2d-dev .. >>> >>> -phil. >>> >>> On 1/18/2012 8:26 AM, Kelly O'Hair wrote: >>>> On Jan 18, 2012, at 12:19 AM, Jonathan Lu wrote: >>>> >>>>> Hi core-libs-dev, >>>>> >>>>> I found that for some native code of OpenJDK code base, malloc() is >>>>> used without including header file stdlib.h, such as following files, >>>>> ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c >>>>> ./src/solaris/native/sun/java2d/x11/XRBackendNative.c >>>>> .... >>>>> >>>>> I assume that there's no hacking tricks involved here, right? >>>>> because this may cause problem for some C compilers, which assumes >>>>> 'int' as the default return type of a function if it cannot find >>>>> the function's declaration during compiling. Under such a >>>>> condition, actual return result of type 'void*' from malloc() will >>>>> be converted to 'int', which may result in truncated pointers in >>>>> 64bit platforms. If the application tries to dereference such a >>>>> broken pointer, error will occur. >>>>> >>>>> Indeed I found some indirect includes of stdlib.h, but there're >>>>> still some I do not see a stdlib.h get included from any of the >>>>> direct/indirect included headers. I think in order to fix this >>>>> problem, two approaches may be considered here, >>>>> a) add "#include" to every missing .c file. >>>>> b) add "#include" to a commonly referenced header file, >>>>> such as jni_util.h. but it would not be easy to find such a file >>>>> for all and creating one is the same as approach a). >>>>> >>>> I suggest a) It should be harmless and is the right thing to do. >>>> >>>> It's been a while since I studied the C standard, but I vaguely >>>> recall that there was another standard C include file >>>> that would cause the malloc() prototype declaration to show up. >>>> Or maybe it wasn't a standard one. In any case, I think your a) >>>> approach is correct and I don't see much a need >>>> for detailed discussions on this, as long as it builds correctly >>>> with no warnings on all platforms. It should be fine and correct. >>>> That's my 2 cents. >>>> >>>> -kto >>>> >>>>> But both methods need to change many files, any other ideas about >>>>> how to fix it more elegantly? >>>>> >>>>> Thanks and best regards! >>>>> - Jonathan >>>>> > From Roger.Riggs at oracle.com Fri Feb 3 14:46:33 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 03 Feb 2012 09:46:33 -0500 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <821uqcyv3c.fsf@mid.bfk.de> References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> <821uqcyv3c.fsf@mid.bfk.de> Message-ID: <4F2BF349.50202@oracle.com> The boolean expression can be refactored. (Only bit-31 is significant). But it becomes pretty inscrutable. (x ^ r)< 0&& (x ^ y)>= 0 becomes (x ^ r)< 0&& (~(x ^ y))< 0 becomes ((x ^ r)& ~(x ^ y))< 0 Roger On 02/03/2012 07:12 AM, Florian Weimer wrote: > * Eamonn McManus: > >> On 3 February 2012 00:11, Florian Weimer wrote: >>> Would it make sense to replace (x ^ r)< 0&& (x ^ y)>= 0 >>> with (x ^ y ^ r)< 0? >> That would not be correct. For example, it would signal overflow for -1 + 1. > Oops. But there has to be a way to implement this using just one > comparison. > From fweimer at bfk.de Fri Feb 3 14:44:39 2012 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 03 Feb 2012 14:44:39 +0000 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <4F2BF349.50202@oracle.com> (Roger Riggs's message of "Fri, 03 Feb 2012 09:46:33 -0500") References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> <821uqcyv3c.fsf@mid.bfk.de> <4F2BF349.50202@oracle.com> Message-ID: <8262fovuw8.fsf@mid.bfk.de> * Roger Riggs: > The boolean expression can be refactored. (Only bit-31 is significant). > But it becomes pretty inscrutable. > > (x ^ r)< 0&& (x ^ y)>= 0 becomes > > (x ^ r)< 0&& (~(x ^ y))< 0 becomes > > ((x ^ r)& ~(x ^ y))< 0 That's what I got in my second attempt, too. It doesn't result in a longer dependency chain because the left side of the & is two operations deep, too. Therefore, this version should be faster (at least after compilation), independent of the input arguments. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From scolebourne at joda.org Fri Feb 3 15:23:48 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 3 Feb 2012 15:23:48 +0000 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <4F2AEEED.8090805@oracle.com> References: <4F2AEEED.8090805@oracle.com> Message-ID: I prefer the method naming safeAdd/safeNegate/safeMultiply (I think they are a lot clearer), but can live with the ones proposed (which are somewhat linked to BigInteger/BigDecimal). I would like to see source code comments explaining why the algorithm works in the final version in OpenJDK. Thats because OpenJDK code is used by everyone to read and understand what is good Java code, and for debugging. Being given a clue to understand the algorithm is highly desirable. It would be desirable to see safe increment and decrement methods as well. These are faster than just an add/subtract (simpler implementation). Most of the methods do not specify the arguments in the exception, but the multiply methods do. It should be consistent one way or the other. It may be worth considering (by testing) if methods taking one long and one int are worthwhile. More efficient implementations of the algorithms may be possible, but at the expense of additional API size. Separately but related, there are missing methods in BigInteger, longValueExact() and intValueExact() Also see here if you haven't already: http://blogs.oracle.com/darcy/entry/jvmlang_numbers Stephen On 2 February 2012 20:15, Roger Riggs wrote: > There is a need for arithmetic operations that throw exceptions > when the results overflow the representation of int or long. > > The CR is 6708398: Support integer overflow > > > Please review this webrev > to add static > methods in java.lang.Math > to support addExact(), subtractExact(), negateExact(), multiplyExact(), > and toIntExact() for int and long primitive types. > > Thanks, Roger Riggs From joe.darcy at oracle.com Fri Feb 3 17:07:59 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 03 Feb 2012 09:07:59 -0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <8262fovuw8.fsf@mid.bfk.de> References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> <821uqcyv3c.fsf@mid.bfk.de> <4F2BF349.50202@oracle.com> <8262fovuw8.fsf@mid.bfk.de> Message-ID: <4F2C146F.5070503@oracle.com> On 02/03/2012 06:44 AM, Florian Weimer wrote: > * Roger Riggs: > >> The boolean expression can be refactored. (Only bit-31 is significant). >> But it becomes pretty inscrutable. >> >> (x ^ r)< 0&& (x ^ y)>= 0 becomes >> >> (x ^ r)< 0&& (~(x ^ y))< 0 becomes >> >> ((x ^ r)& ~(x ^ y))< 0 > That's what I got in my second attempt, too. It doesn't result in a > longer dependency chain because the left side of the& is two operations > deep, too. Therefore, this version should be faster (at least after > compilation), independent of the input arguments. > These sorts of concerns and lovingly (and laboriously!) detailed to Hank Warren's bit-twiddling tome "Hacker's Delight" (http://www.hackersdelight.org/). Roger's initial code used one of the recommend idioms from that source. We should stick with those idioms unless there is a good reason not to. -Joe From eamonn at mcmanus.net Fri Feb 3 17:33:02 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 3 Feb 2012 09:33:02 -0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <4F2C146F.5070503@oracle.com> References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> <821uqcyv3c.fsf@mid.bfk.de> <4F2BF349.50202@oracle.com> <8262fovuw8.fsf@mid.bfk.de> <4F2C146F.5070503@oracle.com> Message-ID: Hacker's Delight gives a formula equivalent to this one on page 27: ((x ^ r) & (y ^ r)) < 0 Having said that, I think Florian's assertion that such a rewrite will be faster needs proof. In the original form... (x ^ r) < 0 && (x ^ y) >= 0 ...the first condition will be false half the time for random inputs and (hand-waving) probably a lot more than half the time for typical inputs. To the extent that the difference is measurable at all, I would not like to have to bet on which alternative is faster, and the original form is definitely easier to read as "both arguments have the same sign and the result has the opposite sign." ?amonn On 3 February 2012 09:07, Joe Darcy wrote: > On 02/03/2012 06:44 AM, Florian Weimer wrote: > >> * Roger Riggs: >> >> The boolean expression can be refactored. (Only bit-31 is significant). >>> But it becomes pretty inscrutable. >>> >>> (x ^ r)< 0&& (x ^ y)>= 0 becomes >>> >>> (x ^ r)< 0&& (~(x ^ y))< 0 becomes >>> >>> ((x ^ r)& ~(x ^ y))< 0 >>> >> That's what I got in my second attempt, too. It doesn't result in a >> longer dependency chain because the left side of the& is two operations >> >> deep, too. Therefore, this version should be faster (at least after >> compilation), independent of the input arguments. >> >> > These sorts of concerns and lovingly (and laboriously!) detailed to Hank > Warren's bit-twiddling tome "Hacker's Delight" (http://www.hackersdelight. > **org/ ). > > Roger's initial code used one of the recommend idioms from that source. > We should stick with those idioms unless there is a good reason not to. > > -Joe > From tom.rodriguez at oracle.com Fri Feb 3 17:47:24 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 3 Feb 2012 09:47:24 -0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> Message-ID: On Feb 3, 2012, at 12:38 AM, Krystal Mok wrote: > Hi Florian, > > On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer wrote: > Will Hotspot be able to optimize away the string construction on the > exception path in multiplyExact() if the exception is caught locally? > > At least -XX:+OptimizeStringConcat should remove the need to construct a StringBuilder instance, in multiplyExact()'s case. > > Cc'ing hotspot-compiler-dev for confirmation. Could we have some context? tom > > - Kris > > From eamonn at mcmanus.net Fri Feb 3 17:52:36 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 3 Feb 2012 09:52:36 -0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <4F2AEEED.8090805@oracle.com> References: <4F2AEEED.8090805@oracle.com> Message-ID: My initial remarks: In negateExact, the condition x == -x should be faster to evaluate than x == Integer.MIN_VALUE and reflects the intent just as well. In addExact and subtractExact, I would be inclined to implement the int versions using long arithmetic, like this: long lr = x + y; int r = (int) lr; if (r == lr) { return r; } else { throw... } I would use this technique of cast-and-compare in the int multiplyExact instead of comparing against MIN_VALUE and MAX_VALUE, and especially in toIntExact(long). I agree with Stephen Colebourne that brief implementation comments would be useful. But I disagree with his proposed further methods in Math (increment, decrement, int+long variants), which I don't think would pull their weight. ?amonn On 2 February 2012 12:15, Roger Riggs wrote: > There is a need for arithmetic operations that throw exceptions > when the results overflow the representation of int or long. > > The CR is 6708398: Support integer overflow bugdatabase/view_bug.do?bug_**id=6708398 > > > > Please review this webrev 7Erriggs/CR6708398/webrev/> > to add static methods in java.lang.Math > to support addExact(), subtractExact(), negateExact(), multiplyExact(), > and toIntExact() for int and long primitive types. > > Thanks, Roger Riggs > From scolebourne at joda.org Fri Feb 3 18:00:11 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 3 Feb 2012 18:00:11 +0000 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> Message-ID: On 3 February 2012 17:52, Eamonn McManus wrote: > I agree with Stephen Colebourne that brief implementation comments would be > useful. But I disagree with his proposed further methods in Math > (increment, decrement, int+long variants), which I don't think would pull > their weight. FWIW, JSR-310 currently has 18 non-test usages of increment/decrement, vs 42 uses of add. Less, but certainly used. The real value in increment/decrement is that it becomes a simple mapping from operator to method a++ = increment(a) a-- = decrement(a) a + b = add(a, b) This makes it easier to see what the intent would have been were the real operators safe. Stephen From vitalyd at gmail.com Fri Feb 3 18:22:19 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 3 Feb 2012 13:22:19 -0500 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> Message-ID: x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp against a constant whereas the latter requires negating x (that's a dependency too), tying up a register to store the negation, and then doing the cmp. Sent from my phone On Feb 3, 2012 12:53 PM, "Eamonn McManus" wrote: > My initial remarks: > > In negateExact, the condition x == -x should be faster to evaluate than x > == Integer.MIN_VALUE and reflects the intent just as well. > > In addExact and subtractExact, I would be inclined to implement the int > versions using long arithmetic, like this: > > long lr = x + y; > int r = (int) lr; > if (r == lr) { > return r; > } else { > throw... > } > > I would use this technique of cast-and-compare in the int multiplyExact > instead of comparing against MIN_VALUE and MAX_VALUE, and especially in > toIntExact(long). > > I agree with Stephen Colebourne that brief implementation comments would be > useful. But I disagree with his proposed further methods in Math > (increment, decrement, int+long variants), which I don't think would pull > their weight. > > ?amonn > > > On 2 February 2012 12:15, Roger Riggs wrote: > > > There is a need for arithmetic operations that throw exceptions > > when the results overflow the representation of int or long. > > > > The CR is 6708398: Support integer overflow > bugdatabase/view_bug.do?bug_**id=6708398< > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6708398> > > > > > > > Please review this webrev > 7Erriggs/CR6708398/webrev/< > http://cr.openjdk.java.net/%7Erriggs/CR6708398/webrev/>> > > to add static methods in java.lang.Math > > to support addExact(), subtractExact(), negateExact(), multiplyExact(), > > and toIntExact() for int and long primitive types. > > > > Thanks, Roger Riggs > > > From eamonn at mcmanus.net Fri Feb 3 18:58:05 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 3 Feb 2012 10:58:05 -0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> Message-ID: On 3 February 2012 10:22, Vitaly Davidovich??wrote: >?x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp against a constant whereas the latter requires negating x (that's a dependency too), tying up a register to store the negation, and then doing the cmp. The value -x is needed anyway since it's the return value. But a more important reason why my idea is a bad one is that the condition is true for x == 0! Writing x == -x && x != 0 is definitely not an improvement. ?amonn On 3 February 2012 10:22, Vitaly Davidovich wrote: > > x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp against a constant whereas the latter requires negating x (that's a dependency too), tying up a register to store the negation, and then doing the cmp. > > Sent from my phone > > On Feb 3, 2012 12:53 PM, "Eamonn McManus" wrote: >> >> My initial remarks: >> >> In negateExact, the condition x == -x should be faster to evaluate than x >> == Integer.MIN_VALUE and reflects the intent just as well. >> >> In addExact and subtractExact, I would be inclined to implement the int >> versions using long arithmetic, like this: >> >> long lr = x + y; >> int r = (int) lr; >> if (r == lr) { >> ?return r; >> } else { >> ?throw... >> } >> >> I would use this technique of cast-and-compare in the int multiplyExact >> instead of comparing against MIN_VALUE and MAX_VALUE, and especially in >> toIntExact(long). >> >> I agree with Stephen Colebourne that brief implementation comments would be >> useful. But I disagree with his proposed further methods in Math >> (increment, decrement, int+long variants), which I don't think would pull >> their weight. >> >> ?amonn >> >> >> On 2 February 2012 12:15, Roger Riggs wrote: >> >> > There is a need for arithmetic operations that throw exceptions >> > when the results overflow the representation of int or long. >> > >> > The CR is 6708398: Support integer overflow > > bugdatabase/view_bug.do?bug_**id=6708398 >> > > >> > >> > Please review this webrev > > 7Erriggs/CR6708398/webrev/> >> >> > to add static methods in java.lang.Math >> > to support addExact(), subtractExact(), negateExact(), multiplyExact(), >> > and toIntExact() for int and long primitive types. >> > >> > Thanks, Roger Riggs >> > From vitalyd at gmail.com Fri Feb 3 19:08:54 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 3 Feb 2012 14:08:54 -0500 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> Message-ID: Yeah my comment was more general - I didn't look at the entire context, just wasn't sure why you thought that comparison would be faster (nevermind that it's wrong as you mention :)). Sent from my phone On Feb 3, 2012 1:58 PM, "Eamonn McManus" wrote: > On 3 February 2012 10:22, Vitaly Davidovich wrote: > > x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp > against a constant whereas the latter requires negating x (that's a > dependency too), tying up a register to store the negation, and then doing > the cmp. > > The value -x is needed anyway since it's the return value. But a more > important reason why my idea is a bad one is that the condition is > true for x == 0! Writing x == -x && x != 0 is definitely not an > improvement. > > ?amonn > > > On 3 February 2012 10:22, Vitaly Davidovich wrote: > > > > x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp > against a constant whereas the latter requires negating x (that's a > dependency too), tying up a register to store the negation, and then doing > the cmp. > > > > Sent from my phone > > > > On Feb 3, 2012 12:53 PM, "Eamonn McManus" wrote: > >> > >> My initial remarks: > >> > >> In negateExact, the condition x == -x should be faster to evaluate than > x > >> == Integer.MIN_VALUE and reflects the intent just as well. > >> > >> In addExact and subtractExact, I would be inclined to implement the int > >> versions using long arithmetic, like this: > >> > >> long lr = x + y; > >> int r = (int) lr; > >> if (r == lr) { > >> return r; > >> } else { > >> throw... > >> } > >> > >> I would use this technique of cast-and-compare in the int multiplyExact > >> instead of comparing against MIN_VALUE and MAX_VALUE, and especially in > >> toIntExact(long). > >> > >> I agree with Stephen Colebourne that brief implementation comments > would be > >> useful. But I disagree with his proposed further methods in Math > >> (increment, decrement, int+long variants), which I don't think would > pull > >> their weight. > >> > >> ?amonn > >> > >> > >> On 2 February 2012 12:15, Roger Riggs wrote: > >> > >> > There is a need for arithmetic operations that throw exceptions > >> > when the results overflow the representation of int or long. > >> > > >> > The CR is 6708398: Support integer overflow >> > bugdatabase/view_bug.do?bug_**id=6708398< > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6708398> > >> > > > >> > > >> > Please review this webrev >> > 7Erriggs/CR6708398/webrev/< > http://cr.openjdk.java.net/%7Erriggs/CR6708398/webrev/>> > >> > >> > to add static methods in java.lang.Math > >> > to support addExact(), subtractExact(), negateExact(), > multiplyExact(), > >> > and toIntExact() for int and long primitive types. > >> > > >> > Thanks, Roger Riggs > >> > > From michael.x.mcmahon at oracle.com Fri Feb 3 21:23:21 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 03 Feb 2012 21:23:21 +0000 Subject: RFR: 7142617 De-optimize fdlibm compilation [macosx] Message-ID: <4F2C5049.8010607@oracle.com> Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/ fdlibm needs to be compiled with optimization disabled, as on Linux. Thanks Michael. From joe.darcy at oracle.com Sat Feb 4 00:54:08 2012 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 03 Feb 2012 16:54:08 -0800 Subject: RFR: 7142617 De-optimize fdlibm compilation [macosx] In-Reply-To: <4F2C5049.8010607@oracle.com> References: <4F2C5049.8010607@oracle.com> Message-ID: <4F2C81B0.7080705@oracle.com> Looks fine, -Joe On 2/3/2012 1:23 PM, Michael McMahon wrote: > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/ > > fdlibm needs to be compiled with optimization disabled, as on Linux. > > Thanks > Michael. From rednaxelafx at gmail.com Sat Feb 4 04:37:42 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 4 Feb 2012 12:37:42 +0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> Message-ID: Hi Tom, Yes, I'm sorry for not including enough context when cc'ing. The original discussion thread starts from [1]. The webrev is at [2]. For the string concats in multiplyExact(): * the StringBuilder doesn't escape * it's only concatenating Strings and ints which should meet the requirements for OptimizeStringConcat to work, Regards, Kris Mok [1]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-February/009128.html [2]: http://cr.openjdk.java.net/~rriggs/CR6708398/webrev/ On Sat, Feb 4, 2012 at 1:47 AM, Tom Rodriguez wrote: > > On Feb 3, 2012, at 12:38 AM, Krystal Mok wrote: > > > Hi Florian, > > > > On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer wrote: > > Will Hotspot be able to optimize away the string construction on the > > exception path in multiplyExact() if the exception is caught locally? > > > > At least -XX:+OptimizeStringConcat should remove the need to construct a > StringBuilder instance, in multiplyExact()'s case. > > > > Cc'ing hotspot-compiler-dev for confirmation. > > Could we have some context? > > tom > > > > > - Kris > > > > > > From chris.hegarty at oracle.com Sat Feb 4 07:38:02 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 04 Feb 2012 07:38:02 +0000 Subject: RFR: 7142617 De-optimize fdlibm compilation [macosx] In-Reply-To: <4F2C5049.8010607@oracle.com> References: <4F2C5049.8010607@oracle.com> Message-ID: <4F2CE05A.40801@oracle.com> Looks good. -Chris. On 02/ 3/12 09:23 PM, Michael McMahon wrote: > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/ > > fdlibm needs to be compiled with optimization disabled, as on Linux. > > Thanks > Michael. From chris.hegarty at oracle.com Sat Feb 4 08:12:00 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 04 Feb 2012 08:12:00 +0000 Subject: Warning Fixes from LJC Hack Session In-Reply-To: References: <4F2A6213.4040707@oracle.com> Message-ID: <4F2CE850.9090604@oracle.com> Thanks for this, looks great. Good to see JarVerifier getting some much needed TLC. -Chris. On 02/ 4/12 07:50 AM, Michael Barker wrote: >> I see R?mi has suggested a slice& dice but I think that's a bit too much >> work for the changes involved. Instead I would suggest a simple split, send >> the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything else to >> core-libs-dev. > > Attached is the patch that contains "everthing else" from LJC warning > fixes hack session. > > Mike. From chris.hegarty at oracle.com Sat Feb 4 12:05:55 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 04 Feb 2012 12:05:55 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120204120631.896834736E@hg.openjdk.java.net> Changeset: bbadb6605a1c Author: chegar Date: 2012-02-04 07:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbadb6605a1c 7041778: Move SCTP implementation out of sun.nio.ch and into its own package Reviewed-by: alanb ! make/com/sun/nio/sctp/Exportedfiles.gmk ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/Makefile ! make/com/sun/nio/sctp/mapfile-vers ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/Net.java - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java ! src/share/classes/sun/nio/ch/SelChImpl.java ! src/share/classes/sun/nio/ch/SelectionKeyImpl.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/Util.java + src/share/classes/sun/nio/ch/sctp/MessageInfoImpl.java + src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java + src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java + src/solaris/classes/sun/nio/ch/sctp/AssociationImpl.java + src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java + src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java + src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/solaris/classes/sun/nio/ch/sctp/SctpNet.java + src/solaris/classes/sun/nio/ch/sctp/SctpNotification.java + src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java + src/solaris/classes/sun/nio/ch/sctp/SendFailed.java + src/solaris/classes/sun/nio/ch/sctp/Shutdown.java - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c + src/solaris/native/sun/nio/ch/sctp/Sctp.h + src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c + src/solaris/native/sun/nio/ch/sctp/SctpNet.c + src/solaris/native/sun/nio/ch/sctp/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + src/windows/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/windows/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/windows/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java Changeset: e528a64dd21b Author: chegar Date: 2012-02-04 07:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e528a64dd21b Merge From Roger.Riggs at oracle.com Sat Feb 4 18:51:41 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Sat, 04 Feb 2012 13:51:41 -0500 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> Message-ID: <4F2D7E3D.2070302@oracle.com> The methods for increment, decrement, and also negation test for exactly one value at the extremities of the value range. The verbosity of method calls in the source code and the overhead in the execution make these a poor choice for developers. If the code must really operate correctly at the extremities then the developer needs to carefully implement and check where appropriate. The checking for overflow in addition, subtraction, and multiplication are subtle or complex enough to warrant support in the runtime. Roger On 02/03/2012 01:00 PM, Stephen Colebourne wrote: > On 3 February 2012 17:52, Eamonn McManus wrote: >> I agree with Stephen Colebourne that brief implementation comments would be >> useful. But I disagree with his proposed further methods in Math >> (increment, decrement, int+long variants), which I don't think would pull >> their weight. > FWIW, JSR-310 currently has 18 non-test usages of increment/decrement, > vs 42 uses of add. Less, but certainly used. > > The real value in increment/decrement is that it becomes a simple > mapping from operator to method > a++ = increment(a) > a-- = decrement(a) > a + b = add(a, b) > This makes it easier to see what the intent would have been were the > real operators safe. > > Stephen From eamonn at mcmanus.net Sun Feb 5 00:40:00 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Sat, 4 Feb 2012 16:40:00 -0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <4F2D7E3D.2070302@oracle.com> References: <4F2AEEED.8090805@oracle.com> <4F2D7E3D.2070302@oracle.com> Message-ID: Concerning the long multiplyExactly, I have a number of comments. public static long multiplyExact(long x, long y) { long r = x * y; long ax = Math.abs(x); long ay = Math.abs(y); if (((ax | ay) >>> 31 == 0) || (x == 1) || (y == 1)) { return r; } if (((y != 0) && r / y != x) || (r == Long.MIN_VALUE )) { throw new ArithmeticException("Multiplication overflows a long: " + x + " * " + y); } return r; } I believe that the (ax | ay) condition is an optimization, but I wonder if it is worthwhile. Presumably the intent is to avoid the division if possible, but is division really more expensive than all these extra operations (abs, abs, or, shift, compare) that we are doing? In addition to returning when x == 1 or y == 1, we could return when y == 0, since we're going to be making that check anyway to avoid divide-by-zero. The final check (r == Long.MIN_VALUE) is incorrect. I presume the intent is to detect overflow when we multiply Long.MIN_VALUE by -1 (and obtain Long.MIN_VALUE), but Long.MIN_VALUE can be the result of a non-overflowing multiplication, for example ((Long.MIN_VALUE / 2) * 2). The division check will catch the case of x=-1,y=Long.MIN_VALUE, so we could just check for the other case x=Long.MIN_VALUE,y=-1 explicitly. ?amonn On 4 February 2012 10:51, Roger Riggs wrote: > The methods for increment, decrement, and also negation test for > exactly one value at the extremities of the value range. > > The verbosity of method calls in the source code and the > overhead in the execution make these a poor choice for developers. > If the code must really operate correctly at the extremities then the > developer needs to carefully implement and check where appropriate. > > The checking for overflow in addition, subtraction, and multiplication > are subtle or complex enough to warrant support in the runtime. > > Roger > > > > > On 02/03/2012 01:00 PM, Stephen Colebourne wrote: >> >> On 3 February 2012 17:52, Eamonn McManus ?wrote: >>> >>> I agree with Stephen Colebourne that brief implementation comments would >>> be >>> useful. But I disagree with his proposed further methods in Math >>> (increment, decrement, int+long variants), which I don't think would pull >>> their weight. >> >> FWIW, JSR-310 currently has 18 non-test usages of increment/decrement, >> vs 42 uses of add. Less, but certainly used. >> >> The real value in increment/decrement is that it becomes a simple >> mapping from operator to method >> a++ = increment(a) >> a-- = decrement(a) >> a + b = add(a, b) >> This makes it easier to see what the intent would have been were the >> real operators safe. >> >> Stephen > > From alan.bateman at oracle.com Sun Feb 5 12:32:02 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 05 Feb 2012 12:32:02 +0000 Subject: hg: jdk8/tl/jaxws: 7140918: Remove dependency on apt and com.sun.mirror API Message-ID: <20120205123202.B14F64737E@hg.openjdk.java.net> Changeset: 6a8f54fb5f15 Author: alanb Date: 2012-02-05 12:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6a8f54fb5f15 7140918: Remove dependency on apt and com.sun.mirror API Reviewed-by: darcy Contributed-by: miroslav.kos at oracle.com, martin.grebac at oracle.com ! build-defs.xml ! jaxws.properties From alan.bateman at oracle.com Sun Feb 5 12:32:51 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 05 Feb 2012 12:32:51 +0000 Subject: hg: jdk8/tl/jdk: 7140918: Remove dependency on apt and com.sun.mirror API Message-ID: <20120205123319.F18E54737F@hg.openjdk.java.net> Changeset: ce5ffdb2be25 Author: alanb Date: 2012-02-05 12:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce5ffdb2be25 7140918: Remove dependency on apt and com.sun.mirror API Reviewed-by: darcy Contributed-by: miroslav.kos at oracle.com, martin.grebac at oracle.com ! make/common/Release.gmk ! make/common/internal/Defs-jaxws.gmk From joe.darcy at oracle.com Mon Feb 6 05:50:37 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 06 Feb 2012 05:50:37 +0000 Subject: hg: jdk8/tl/jdk: 7041249: Remove apt tool and API from the JDK Message-ID: <20120206055055.1861847389@hg.openjdk.java.net> Changeset: e55522710586 Author: darcy Date: 2012-02-05 21:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e55522710586 7041249: Remove apt tool and API from the JDK Reviewed-by: jjg, ohair ! make/com/sun/Makefile ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk ! make/launchers/Makefile ! make/launchers/Makefile.launcher - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 From joe.darcy at oracle.com Mon Feb 6 06:00:02 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 06 Feb 2012 06:00:02 +0000 Subject: hg: jdk8/tl/langtools: 7041249: Remove apt tool and API from the JDK Message-ID: <20120206060007.1C28F4738A@hg.openjdk.java.net> Changeset: 2360c8213989 Author: darcy Date: 2012-02-05 21:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2360c8213989 7041249: Remove apt tool and API from the JDK Reviewed-by: jjg, ohair ! make/Makefile-classic ! make/build.properties ! make/build.xml ! make/netbeans/README - make/test/lib/apt.sh ! make/test/lib/src.gold.txt - src/share/classes/com/sun/mirror/apt/AnnotationProcessor.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorEnvironment.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorFactory.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorListener.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessors.java - src/share/classes/com/sun/mirror/apt/Filer.java - src/share/classes/com/sun/mirror/apt/Messager.java - src/share/classes/com/sun/mirror/apt/RoundCompleteEvent.java - src/share/classes/com/sun/mirror/apt/RoundCompleteListener.java - src/share/classes/com/sun/mirror/apt/RoundState.java - src/share/classes/com/sun/mirror/apt/package-info.java - src/share/classes/com/sun/mirror/declaration/AnnotationMirror.java - src/share/classes/com/sun/mirror/declaration/AnnotationTypeDeclaration.java - src/share/classes/com/sun/mirror/declaration/AnnotationTypeElementDeclaration.java - src/share/classes/com/sun/mirror/declaration/AnnotationValue.java - src/share/classes/com/sun/mirror/declaration/ClassDeclaration.java - src/share/classes/com/sun/mirror/declaration/ConstructorDeclaration.java - src/share/classes/com/sun/mirror/declaration/Declaration.java - src/share/classes/com/sun/mirror/declaration/EnumConstantDeclaration.java - src/share/classes/com/sun/mirror/declaration/EnumDeclaration.java - src/share/classes/com/sun/mirror/declaration/ExecutableDeclaration.java - src/share/classes/com/sun/mirror/declaration/FieldDeclaration.java - src/share/classes/com/sun/mirror/declaration/InterfaceDeclaration.java - src/share/classes/com/sun/mirror/declaration/MemberDeclaration.java - src/share/classes/com/sun/mirror/declaration/MethodDeclaration.java - src/share/classes/com/sun/mirror/declaration/Modifier.java - src/share/classes/com/sun/mirror/declaration/PackageDeclaration.java - src/share/classes/com/sun/mirror/declaration/ParameterDeclaration.java - src/share/classes/com/sun/mirror/declaration/TypeDeclaration.java - src/share/classes/com/sun/mirror/declaration/TypeParameterDeclaration.java - src/share/classes/com/sun/mirror/declaration/package-info.java - src/share/classes/com/sun/mirror/overview.html - src/share/classes/com/sun/mirror/type/AnnotationType.java - src/share/classes/com/sun/mirror/type/ArrayType.java - src/share/classes/com/sun/mirror/type/ClassType.java - src/share/classes/com/sun/mirror/type/DeclaredType.java - src/share/classes/com/sun/mirror/type/EnumType.java - src/share/classes/com/sun/mirror/type/InterfaceType.java - src/share/classes/com/sun/mirror/type/MirroredTypeException.java - src/share/classes/com/sun/mirror/type/MirroredTypesException.java - src/share/classes/com/sun/mirror/type/PrimitiveType.java - src/share/classes/com/sun/mirror/type/ReferenceType.java - src/share/classes/com/sun/mirror/type/TypeMirror.java - src/share/classes/com/sun/mirror/type/TypeVariable.java - src/share/classes/com/sun/mirror/type/VoidType.java - src/share/classes/com/sun/mirror/type/WildcardType.java - src/share/classes/com/sun/mirror/type/package-info.java - src/share/classes/com/sun/mirror/util/DeclarationFilter.java - src/share/classes/com/sun/mirror/util/DeclarationScanner.java - src/share/classes/com/sun/mirror/util/DeclarationVisitor.java - src/share/classes/com/sun/mirror/util/DeclarationVisitors.java - src/share/classes/com/sun/mirror/util/Declarations.java - src/share/classes/com/sun/mirror/util/SimpleDeclarationVisitor.java - src/share/classes/com/sun/mirror/util/SimpleTypeVisitor.java - src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java - src/share/classes/com/sun/mirror/util/SourcePosition.java - src/share/classes/com/sun/mirror/util/TypeVisitor.java - src/share/classes/com/sun/mirror/util/Types.java - src/share/classes/com/sun/mirror/util/package-info.java - src/share/classes/com/sun/tools/apt/Main.java - src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java - src/share/classes/com/sun/tools/apt/comp/Apt.java - src/share/classes/com/sun/tools/apt/comp/BootstrapAPF.java - src/share/classes/com/sun/tools/apt/comp/PrintAP.java - src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java - src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/apt/main/CommandLine.java - src/share/classes/com/sun/tools/apt/main/Main.java - src/share/classes/com/sun/tools/apt/mirror/AptEnv.java - src/share/classes/com/sun/tools/apt/mirror/apt/AnnotationProcessorEnvironmentImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/MessagerImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/RoundStateImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationMirrorImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeElementDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationValueImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ClassDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ConstructorDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationMaker.java - src/share/classes/com/sun/tools/apt/mirror/declaration/EnumConstantDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/EnumDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ExecutableDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/FieldDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/InterfaceDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/MemberDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/MethodDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/PackageDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ParameterDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/TypeDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/TypeParameterDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/AnnotationTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/ArrayTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/ClassTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/DeclaredTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/EnumTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/InterfaceTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/PrimitiveTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeMaker.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/VoidTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/WildcardTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/TypesImpl.java - src/share/classes/com/sun/tools/apt/resources/apt.properties - src/share/classes/com/sun/tools/apt/resources/apt_ja.properties - src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties - src/share/classes/com/sun/tools/apt/util/Bark.java - test/tools/apt/Basics/Aggregate.java - test/tools/apt/Basics/ClassAnnotations.java - test/tools/apt/Basics/FreshnessApf.java - test/tools/apt/Basics/GenClass.java - test/tools/apt/Basics/Indirect.java - test/tools/apt/Basics/Lacuna.java - test/tools/apt/Basics/MethodAnnotations.java - test/tools/apt/Basics/Milk.java - test/tools/apt/Basics/MisMatch.java - test/tools/apt/Basics/Misc.java - test/tools/apt/Basics/MyMarker.java - test/tools/apt/Basics/MySimple.java - test/tools/apt/Basics/NestedClassAnnotations.java - test/tools/apt/Basics/ParameterAnnotations.java - test/tools/apt/Basics/StaticFieldAnnotations.java - test/tools/apt/Basics/StaticMethodAnnotations.java - test/tools/apt/Basics/TestGetPackageApf.java - test/tools/apt/Basics/TestGetTypeDeclarationApf.java - test/tools/apt/Basics/annot/AnnotMarker.java - test/tools/apt/Basics/annot/AnnotShangri_la.java - test/tools/apt/Basics/annot/AnnotSimple.java - test/tools/apt/Basics/annot/annot2/AnnotMarker2.java - test/tools/apt/Basics/annot/annot2/AnnotSimple2.java ! test/tools/apt/Basics/apt.sh - test/tools/apt/Basics/com.sun.mirror.apt.AnnotationProcessorFactory - test/tools/apt/Basics/foo/bar/Baz.java - test/tools/apt/Basics/foo/bar/Quux.java - test/tools/apt/Basics/golden.txt - test/tools/apt/Basics/goldenAggregate.txt - test/tools/apt/Basics/p1/p2.java - test/tools/apt/Basics/p1/p2/C1.java - test/tools/apt/Basics/print.sh - test/tools/apt/Compile/ClassDeclApf.java - test/tools/apt/Compile/ClassDeclApf2.java - test/tools/apt/Compile/Dummy1.java - test/tools/apt/Compile/ErrorAPF.java - test/tools/apt/Compile/HelloAnnotation.java - test/tools/apt/Compile/HelloWorld.java - test/tools/apt/Compile/Round1Apf.java - test/tools/apt/Compile/Round2Apf.java - test/tools/apt/Compile/Round3Apf.java - test/tools/apt/Compile/Round4Apf.java - test/tools/apt/Compile/Rounds.java - test/tools/apt/Compile/StaticApf.java - test/tools/apt/Compile/WarnAPF.java - test/tools/apt/Compile/WrappedStaticApf.java - test/tools/apt/Compile/compile.sh - test/tools/apt/Compile/golden.txt - test/tools/apt/Compile/goldenFactory.txt - test/tools/apt/Compile/goldenWarn.txt - test/tools/apt/Compile/servicesRound1 - test/tools/apt/Compile/servicesRound2 - test/tools/apt/Compile/servicesRound3 - test/tools/apt/Compile/servicesRound4 - test/tools/apt/Compile/servicesStaticApf - test/tools/apt/Compile/src/AhOneClass.java - test/tools/apt/Compile/src/AndAhTwoClass.java - test/tools/apt/Compile/src/Round1Class.java - test/tools/apt/Discovery/Dee.java - test/tools/apt/Discovery/Dum.java - test/tools/apt/Discovery/Empty.java - test/tools/apt/Discovery/PhantomTouch.java - test/tools/apt/Discovery/PhantomUpdate.java - test/tools/apt/Discovery/Touch.java - test/tools/apt/Discovery/discovery.sh - test/tools/apt/Discovery/servicesBadTouch - test/tools/apt/Discovery/servicesPhantomTouch - test/tools/apt/Discovery/servicesTouch - test/tools/apt/Discovery/servicesTweedle - test/tools/apt/Misc/Marked.java - test/tools/apt/Misc/Marker.java - test/tools/apt/Misc/Misc.java - test/tools/apt/Misc/misc.sh - test/tools/apt/Misc/servicesMisc - test/tools/apt/Options/Marked.java - test/tools/apt/Options/Marker.java - test/tools/apt/Options/OptionChecker.java - test/tools/apt/Options/options.sh - test/tools/apt/Options/servicesOptions - test/tools/apt/Scanners/Counter.java - test/tools/apt/Scanners/MemberOrderApf.java - test/tools/apt/Scanners/Order.java - test/tools/apt/Scanners/Scanner.java - test/tools/apt/Scanners/TestEnum.java - test/tools/apt/Scanners/VisitOrder.java - test/tools/apt/Scanners/scanner.sh - test/tools/apt/Scanners/servicesScanner - test/tools/apt/lib/Ignore.java - test/tools/apt/lib/Test.java - test/tools/apt/lib/TestProcessor.java - test/tools/apt/lib/TestProcessorFactory.java - test/tools/apt/lib/Tester.java - test/tools/apt/mirror/declaration/AnnoMirror.java - test/tools/apt/mirror/declaration/AnnoTypeDecl.java - test/tools/apt/mirror/declaration/AnnoTypeElemDecl.java - test/tools/apt/mirror/declaration/AnnoVal.java - test/tools/apt/mirror/declaration/ClassDecl.java - test/tools/apt/mirror/declaration/ConstExpr.java - test/tools/apt/mirror/declaration/ConstructorDecl.java - test/tools/apt/mirror/declaration/EnumDecl.java - test/tools/apt/mirror/declaration/FieldDecl.java - test/tools/apt/mirror/declaration/GetAnno.java - test/tools/apt/mirror/declaration/InterfaceDecl.java - test/tools/apt/mirror/declaration/MethodDecl.java - test/tools/apt/mirror/declaration/PackageDecl.java - test/tools/apt/mirror/declaration/ParameterDecl.java - test/tools/apt/mirror/declaration/pkg1/AClass.java - test/tools/apt/mirror/declaration/pkg1/AnAnnoType.java - test/tools/apt/mirror/declaration/pkg1/AnEnum.java - test/tools/apt/mirror/declaration/pkg1/AnInterface.java - test/tools/apt/mirror/declaration/pkg1/package-info.java - test/tools/apt/mirror/declaration/pkg1/pkg2/AnInterface.java - test/tools/apt/mirror/declaration/pkg1/pkg2/package.html - test/tools/apt/mirror/type/AnnoTyp.java - test/tools/apt/mirror/type/ArrayTyp.java - test/tools/apt/mirror/type/ClassTyp.java - test/tools/apt/mirror/type/EnumTyp.java - test/tools/apt/mirror/type/InterfaceTyp.java - test/tools/apt/mirror/type/PrimitiveTyp.java - test/tools/apt/mirror/type/TypeVar.java - test/tools/apt/mirror/type/WildcardTyp.java - test/tools/apt/mirror/util/Overrides.java - test/tools/apt/mirror/util/TypeCreation.java From Roger.Riggs at oracle.com Mon Feb 6 21:15:22 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 06 Feb 2012 16:15:22 -0500 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> Message-ID: <4F3042EA.20406@oracle.com> On 02/03/2012 10:23 AM, Stephen Colebourne wrote: > I prefer the method naming safeAdd/safeNegate/safeMultiply (I think > they are a lot clearer), but can live with the ones proposed (which > are somewhat linked to BigInteger/BigDecimal). The method names should start with the operation. > I would like to see source code comments explaining why the algorithm > works in the final version in OpenJDK. Thats because OpenJDK code is > used by everyone to read and understand what is good Java code, and > for debugging. Being given a clue to understand the algorithm is > highly desirable. yes, I will add comments to describe the implementation and refer to Hackers Delight Section 2-12 > Most of the methods do not specify the arguments in the exception, but > the multiply methods do. It should be consistent one way or the other. Simplify the exception arguments; if these exceptions occur debugging will be required by examining the source code or using a debugger so the message content is not a significant factor in debugging. > It may be worth considering (by testing) if methods taking one long > and one int are worthwhile. More efficient implementations of the > algorithms may be possible, but at the expense of additional API size. Since there is no support in the bytecode for combinations of int and long handcoding the mixing would make it harder to optimize the code to the hardware operations. Widening to long enables optimizations for those operations to be used. > Separately but related, there are missing methods in BigInteger, > longValueExact() and intValueExact() BigInteger provides a bitLength method than be tested to see if the result would overflow. That's a better API than an ArithmeticException and is easier for the developer to work with. Thanks, Roger From Roger.Riggs at oracle.com Mon Feb 6 21:15:32 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 06 Feb 2012 16:15:32 -0500 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> <4F2D7E3D.2070302@oracle.com> Message-ID: <4F3042F4.8020909@oracle.com> ?amonn, Thanks for the detailed review. I did some simple performance tests with and without the optimization test. With the optimization, performance was nearly doubled. The individual tests for x or y ==1 did not improve performance. Those cases are likely optimized inside the divide operation. Special casing the simple arguments and return values seems to slow down the non-special cases and it isn't important to speed them up. I will correct for the multiplyExact case for Long.MIN_VALUE * -1. Roger On 02/04/2012 07:40 PM, Eamonn McManus wrote: > Concerning the long multiplyExactly, I have a number of comments. > > public static long multiplyExact(long x, long y) { > long r = x * y; > long ax = Math.abs(x); > long ay = Math.abs(y); > if (((ax | ay)>>> 31 == 0) || (x == 1) || (y == 1)) { > return r; > } > if (((y != 0)&& r / y != x) || (r == Long.MIN_VALUE )) { > throw new ArithmeticException("Multiplication overflows a > long: " + x + " * " + y); > } > return r; > } > > I believe that the (ax | ay) condition is an optimization, but I > wonder if it is worthwhile. Presumably the intent is to avoid the > division if possible, but is division really more expensive than all > these extra operations (abs, abs, or, shift, compare) that we are > doing? > > In addition to returning when x == 1 or y == 1, we could return when y > == 0, since we're going to be making that check anyway to avoid > divide-by-zero. > > The final check (r == Long.MIN_VALUE) is incorrect. I presume the > intent is to detect overflow when we multiply Long.MIN_VALUE by -1 > (and obtain Long.MIN_VALUE), but Long.MIN_VALUE can be the result of a > non-overflowing multiplication, for example ((Long.MIN_VALUE / 2) * > 2). The division check will catch the case of x=-1,y=Long.MIN_VALUE, > so we could just check for the other case x=Long.MIN_VALUE,y=-1 > explicitly. > > ?amonn > > > > On 4 February 2012 10:51, Roger Riggs wrote: >> The methods for increment, decrement, and also negation test for >> exactly one value at the extremities of the value range. >> >> The verbosity of method calls in the source code and the >> overhead in the execution make these a poor choice for developers. >> If the code must really operate correctly at the extremities then the >> developer needs to carefully implement and check where appropriate. >> >> The checking for overflow in addition, subtraction, and multiplication >> are subtle or complex enough to warrant support in the runtime. >> >> Roger >> >> >> >> >> On 02/03/2012 01:00 PM, Stephen Colebourne wrote: >>> On 3 February 2012 17:52, Eamonn McManus wrote: >>>> I agree with Stephen Colebourne that brief implementation comments would >>>> be >>>> useful. But I disagree with his proposed further methods in Math >>>> (increment, decrement, int+long variants), which I don't think would pull >>>> their weight. >>> FWIW, JSR-310 currently has 18 non-test usages of increment/decrement, >>> vs 42 uses of add. Less, but certainly used. >>> >>> The real value in increment/decrement is that it becomes a simple >>> mapping from operator to method >>> a++ = increment(a) >>> a-- = decrement(a) >>> a + b = add(a, b) >>> This makes it easier to see what the intent would have been were the >>> real operators safe. >>> >>> Stephen From Roger.Riggs at oracle.com Mon Feb 6 21:16:21 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 06 Feb 2012 16:16:21 -0500 Subject: Review: JDK 8 CR for Support Integer overflow Message-ID: <4F304325.3040208@oracle.com> Thanks for the review and comments: The comments and suggestions are included in the updated webrev: http://cr.openjdk.java.net/~rriggs/6708398.1 * Corrected error in multipleExact(long,long) with the special case Long.MIN_VALUE * -1. * Verified that retaining the optimization for small (2^31) arguments is worthwhile, not doing the divide saves about 1/2 on the execution time. * Removed the negateExact methods since they don't pull their weight in the API, simple tests for MIN_VALUE and MAX_VALUE can be done by the developer more efficiently. * Simplified the arguments to the ArithmeticExceptions to be simple strings since debugging this kind of exception requires the source code. * Expanded the comments in the implementation include descriptions and references to the Hackers Delight where they are used. * Updated the tests to include missing test cases More comments, please Thanks, Roger From eamonn at mcmanus.net Mon Feb 6 22:19:25 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Mon, 6 Feb 2012 14:19:25 -0800 Subject: Review: JDK 8 CR for Support Integer overflow In-Reply-To: <4F304325.3040208@oracle.com> References: <4F304325.3040208@oracle.com> Message-ID: Looks good to me (emcmanus). One really trivial thing is that Math.java:830 is indented one space too far. I thought that the common (int)value subexpression could be put in a variable in toIntExact but it turns out that javac generates more code in that case. ?amonn On 6 February 2012 13:16, Roger Riggs wrote: > Thanks for the review and comments: > > The comments and suggestions are included in the updated webrev: > ? http://cr.openjdk.java.net/~rriggs/6708398.1 > > ?* Corrected error in multipleExact(long,long) with the special case > ? Long.MIN_VALUE * -1. > ?* Verified that retaining the optimization for small (2^31) arguments > ? is worthwhile, > ? not doing the divide saves about 1/2 on the execution time. > ?* Removed the negateExact methods since they don't pull their weight > ? in the API, > ? simple tests for MIN_VALUE and MAX_VALUE can be done by the > ? developer more efficiently. > ?* Simplified the arguments to the ArithmeticExceptions to be simple > ? strings since > ? debugging this kind of exception requires the source code. > ?* Expanded the comments in the implementation include descriptions and > ? references to the Hackers Delight where they are used. > ?* Updated the tests to include missing test cases > > More comments, please > > Thanks, Roger > From scolebourne at joda.org Mon Feb 6 22:28:49 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 6 Feb 2012 22:28:49 +0000 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: <4F3042EA.20406@oracle.com> References: <4F2AEEED.8090805@oracle.com> <4F3042EA.20406@oracle.com> Message-ID: On 6 February 2012 21:15, Roger Riggs wrote: >> Separately but related, there are missing methods in BigInteger, >> longValueExact() and intValueExact() > > BigInteger provides a bitLength method than be tested to see if the result > would overflow. ?That's a better API than an ArithmeticException and is > easier for the developer to work with. As a user, I wouldn't think to use bitLength, and the readability of the resulting code would be far lower. With BigDecimal, int and long now having these "exact" methods, not providing the equivalent on BigInteger should be raising some red flags. Stephen From scolebourne at joda.org Mon Feb 6 22:35:55 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 6 Feb 2012 22:35:55 +0000 Subject: Review: JDK 8 CR for Support Integer overflow In-Reply-To: <4F304325.3040208@oracle.com> References: <4F304325.3040208@oracle.com> Message-ID: On 6 February 2012 21:16, Roger Riggs wrote: > ?* Removed the negateExact methods since they don't pull their weight > ? in the API, > ? simple tests for MIN_VALUE and MAX_VALUE can be done by the > ? developer more efficiently. Sorry, but I can't agree with this. Developers get negation of numbers wrong all the time by ignoring the special case. Its a big source of hidden bugs. Increment/decrement are replaceable by add/subtract (with less readability), but negate is not. The whole purpose of methods like this is not to say "oh they're easy for the caller to write", but to write it once accurately, well-tested, and with clear intent for code readers. Look at the methods on Objects to see that complexity of the implementation is not the deciding factor. Many, many developers will thank you for having negate, increment and decrement. Stephen From eamonn at mcmanus.net Mon Feb 6 22:47:14 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Mon, 6 Feb 2012 14:47:14 -0800 Subject: Review: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F304325.3040208@oracle.com> Message-ID: I'm with Roger on this. > Sorry, but I can't agree with this. Developers get negation of numbers > wrong all the time by ignoring the special case. Its a big source of > hidden bugs. Increment/decrement are replaceable by add/subtract (with > less readability), but negate is not. First of all, negate(x) certainly is replaceable by subtractExact(0, x). Secondly, the problem is more that people don't realize that -x might not be exact. If you know there's a problem then it isn't any easier for you to know that a solution is to be found in Math than to know that the problem is with MIN_VALUE. ?amonn On 6 February 2012 14:35, Stephen Colebourne wrote: > On 6 February 2012 21:16, Roger Riggs wrote: >> ?* Removed the negateExact methods since they don't pull their weight >> ? in the API, >> ? simple tests for MIN_VALUE and MAX_VALUE can be done by the >> ? developer more efficiently. > > Sorry, but I can't agree with this. Developers get negation of numbers > wrong all the time by ignoring the special case. Its a big source of > hidden bugs. Increment/decrement are replaceable by add/subtract (with > less readability), but negate is not. > > The whole purpose of methods like this is not to say "oh they're easy > for the caller to write", but to write it once accurately, > well-tested, and with clear intent for code readers. Look at the > methods on Objects to see that complexity of the implementation is not > the deciding factor. > > Many, many developers will thank you for having negate, increment and decrement. > > Stephen From tom.rodriguez at oracle.com Mon Feb 6 23:59:43 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 6 Feb 2012 15:59:43 -0800 Subject: Need reviewer: JDK 8 CR for Support Integer overflow In-Reply-To: References: <4F2AEEED.8090805@oracle.com> <82mx901gls.fsf@mid.bfk.de> Message-ID: <302A5B80-4179-48FD-B0F6-4804BACE9702@oracle.com> On Feb 3, 2012, at 8:37 PM, Krystal Mok wrote: > Hi Tom, > > Yes, I'm sorry for not including enough context when cc'ing. > > The original discussion thread starts from [1]. The webrev is at [2]. > > For the string concats in multiplyExact(): > * the StringBuilder doesn't escape > * it's only concatenating Strings and ints > > > which should meet the requirements for OptimizeStringConcat to work, That's right. I believe it would be able to optimize away the string construction work in this case. tom > > Regards, > Kris Mok > > [1]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-February/009128.html > [2]: http://cr.openjdk.java.net/~rriggs/CR6708398/webrev/ > > On Sat, Feb 4, 2012 at 1:47 AM, Tom Rodriguez wrote: > > On Feb 3, 2012, at 12:38 AM, Krystal Mok wrote: > > > Hi Florian, > > > > On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer wrote: > > Will Hotspot be able to optimize away the string construction on the > > exception path in multiplyExact() if the exception is caught locally? > > > > At least -XX:+OptimizeStringConcat should remove the need to construct a StringBuilder instance, in multiplyExact()'s case. > > > > Cc'ing hotspot-compiler-dev for confirmation. > > Could we have some context? > > tom > > > > > - Kris > > > > > > From xueming.shen at oracle.com Tue Feb 7 01:02:01 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 06 Feb 2012 17:02:01 -0800 Subject: Using unsigned library work in the JDK In-Reply-To: <4F21FEFF.8040100@oracle.com> References: <4F20D879.8010800@oracle.com> <4F2192C3.3080808@oracle.com> <4F21FEFF.8040100@oracle.com> Message-ID: <4F307809.7050509@oracle.com> Joe, I did some non-scientific measure of the performance. test1() is to measure the change in a real "listing" operation on a ZipInputStream and test2() is a pure access on the byte[] directly. I don't see any significant difference on performance in both -client and -server vm. I would assume the change has no performance impact to the real zip access. In -client vm test1: 108 vs 109 test2: 280 : 283 Simple test case attached (the input is a big enough jar file, such as the rt.jar) -Sherman -------------------------------------------- public static void main(String[] args) throws IOException { byte[] data = java.nio.file.Files.readAllBytes(new File(args[0]).toPath()); ByteArrayInputStream bais = new ByteArrayInputStream(data); //warm up test1(bais, 100); System.out.printf("t=%d%n", test1(bais, 500)); test2(data, 100); System.out.printf("t=%d%n", test2(data, 100)); } static long test1(ByteArrayInputStream bais, int n) throws IOException { long t = 0; for (int i = 0; i < n; i++) { bais.reset(); ZipInputStream zis = new ZipInputStream(bais); ZipEntry e; long t0 = System.currentTimeMillis(); while ((e = zis.getNextEntry()) != null) { zis.closeEntry(); //System.out.println(new String(e.getName())); } long t1 = System.currentTimeMillis(); t += t1 - t0; } return t /= n; } static long test2(byte data[], int n) throws IOException { int j = 10000; long t = 0; if (j >= data.length -1) j = data.length -2; for (int m = 0; m < n; m++) { long t0 = System.nanoTime(); int sum = 0; for (int i = 0; i < j; i++) { sum += get16(data, i); } long t1 = System.nanoTime(); t += t1 - t0; } return t / n / 100; } private static final int get16(byte b[], int off) { return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); //return Byte.toUnsignedInt(b[off]) | (Byte.toUnsignedInt(b[off+1]) << 8); } On 1/26/2012 5:33 PM, Joe Darcy wrote: > Sherman, thanks for offering to investigate the performance impact, if > any, of this change. > > -Joe > > PS All the jar/zip regression tests pass with this change. > > On 01/26/2012 09:52 AM, Xueming Shen wrote: >> Joe, >> >> The changes look fine. However I have the same performance concern in >> cases that the vm fails to inline the toUnsignedInt(), especially >> for those >> "simple" one line utility methods, such as the get16(), CH(), SH(), my >> guess is that it might have a performance impact. It might not be a big >> deal for operation like creating or extracting a jar/zip file but >> probably will >> slow down the loc/cen table reading only operation such as list a >> jar/zip >> file. I will try to get some performance data to see if the impact is >> "significant" enough to be a real concern. >> >> -Sherman >> >> On 01/25/2012 08:37 PM, Joe Darcy wrote: >>> Hello, >>> >>> As a follow-up to the recent push of unsigned library support in the >>> JDK [1], I grepped -i for "0xff" in the JDK code base to look for >>> candidate locations to use the new methods. I choose to first >>> tackle some jar/zip code. >>> >>> Sherman, can you review the changes below? >>> >>> diff -r 303b67074666 >>> src/share/classes/java/util/jar/JarOutputStream.java >>> --- a/src/share/classes/java/util/jar/JarOutputStream.java Tue >>> Jan 24 15:13:27 2012 -0500 >>> +++ b/src/share/classes/java/util/jar/JarOutputStream.java Wed >>> Jan 25 20:31:05 2012 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -135,7 +135,7 @@ >>> * The bytes are assumed to be in Intel (little-endian) byte >>> order. >>> */ >>> private static int get16(byte[] b, int off) { >>> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); >>> + return Byte.toUnsignedInt(b[off]) | ( >>> Byte.toUnsignedInt(b[off+1]) << 8); >>> } >>> >>> /* >>> diff -r 303b67074666 src/share/classes/java/util/jar/Manifest.java >>> --- a/src/share/classes/java/util/jar/Manifest.java Tue Jan 24 >>> 15:13:27 2012 -0500 >>> +++ b/src/share/classes/java/util/jar/Manifest.java Wed Jan 25 >>> 20:31:05 2012 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -339,7 +339,7 @@ >>> return -1; >>> } >>> } >>> - return buf[pos++] & 0xff; >>> + return Byte.toUnsignedInt(buf[pos++]); >>> } >>> >>> public int read(byte[] b, int off, int len) throws >>> IOException { >>> diff -r 303b67074666 >>> src/share/classes/java/util/zip/InflaterInputStream.java >>> --- a/src/share/classes/java/util/zip/InflaterInputStream.java >>> Tue Jan 24 15:13:27 2012 -0500 >>> +++ b/src/share/classes/java/util/zip/InflaterInputStream.java >>> Wed Jan 25 20:31:05 2012 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -119,7 +119,7 @@ >>> */ >>> public int read() throws IOException { >>> ensureOpen(); >>> - return read(singleByteBuf, 0, 1) == -1 ? -1 : >>> singleByteBuf[0] & 0xff; >>> + return read(singleByteBuf, 0, 1) == -1 ? -1 : >>> Byte.toUnsignedInt(singleByteBuf[0]); >>> } >>> >>> /** >>> diff -r 303b67074666 >>> src/share/classes/java/util/zip/ZipInputStream.java >>> --- a/src/share/classes/java/util/zip/ZipInputStream.java Tue Jan >>> 24 15:13:27 2012 -0500 >>> +++ b/src/share/classes/java/util/zip/ZipInputStream.java Wed Jan >>> 25 20:31:05 2012 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -435,7 +435,7 @@ >>> * The bytes are assumed to be in Intel (little-endian) byte >>> order. >>> */ >>> private static final int get16(byte b[], int off) { >>> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); >>> + return Byte.toUnsignedInt(b[off]) | >>> (Byte.toUnsignedInt(b[off+1]) << 8); >>> } >>> >>> /* >>> diff -r 303b67074666 >>> src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java >>> --- >>> a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java Tue >>> Jan 24 15:13:27 2012 -0500 >>> +++ >>> b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java Wed >>> Jan 25 20:31:05 2012 -0800 >>> @@ -185,11 +185,11 @@ >>> */ >>> /////////////////////////////////////////////////////// >>> static final int CH(byte[] b, int n) { >>> - return b[n] & 0xff; >>> + return Byte.toUnsignedInt(b[n]); >>> } >>> >>> static final int SH(byte[] b, int n) { >>> - return (b[n] & 0xff) | ((b[n + 1] & 0xff) << 8); >>> + return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n + >>> 1]) << 8); >>> } >>> >>> static final long LG(byte[] b, int n) { >>> >>> If the changes look good, I'll file a bug for them, etc. >>> >>> In case other people want to look over candidates sites in different >>> areas, I've included the list of JDK files using "0xff" below. >>> >>> Thanks, >>> >>> -Joe >>> >>> [1] 4504839: Java libraries should provide support for unsigned >>> integer arithmetic >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008926.html >>> >>> >>> . > From joe.darcy at oracle.com Tue Feb 7 05:33:55 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 06 Feb 2012 21:33:55 -0800 Subject: Using unsigned library work in the JDK In-Reply-To: <4F307809.7050509@oracle.com> References: <4F20D879.8010800@oracle.com> <4F2192C3.3080808@oracle.com> <4F21FEFF.8040100@oracle.com> <4F307809.7050509@oracle.com> Message-ID: <4F30B7C3.3040803@oracle.com> Thanks Sherman; given the at most marginal performance cost, I'll push the changes in the next day or two. -Joe On 02/06/2012 05:02 PM, Xueming Shen wrote: > Joe, > > I did some non-scientific measure of the performance. test1() is to > measure the change > in a real "listing" operation on a ZipInputStream and test2() is a > pure access on the byte[] > directly. I don't see any significant difference on performance in > both -client and -server > vm. I would assume the change has no performance impact to the real > zip access. > > In -client vm > test1: 108 vs 109 > test2: 280 : 283 > > Simple test case attached (the input is a big enough jar file, such as > the rt.jar) > > -Sherman > > -------------------------------------------- > > public static void main(String[] args) throws IOException { > > byte[] data = java.nio.file.Files.readAllBytes(new > File(args[0]).toPath()); > ByteArrayInputStream bais = new ByteArrayInputStream(data); > > //warm up > test1(bais, 100); > System.out.printf("t=%d%n", test1(bais, 500)); > > test2(data, 100); > System.out.printf("t=%d%n", test2(data, 100)); > } > > static long test1(ByteArrayInputStream bais, int n) throws > IOException { > long t = 0; > for (int i = 0; i < n; i++) { > bais.reset(); > > ZipInputStream zis = new ZipInputStream(bais); > ZipEntry e; > long t0 = System.currentTimeMillis(); > while ((e = zis.getNextEntry()) != null) { > zis.closeEntry(); > //System.out.println(new String(e.getName())); > } > long t1 = System.currentTimeMillis(); > t += t1 - t0; > } > return t /= n; > } > > > static long test2(byte data[], int n) throws IOException { > int j = 10000; > long t = 0; > if (j >= data.length -1) > j = data.length -2; > for (int m = 0; m < n; m++) { > long t0 = System.nanoTime(); > int sum = 0; > for (int i = 0; i < j; i++) { > sum += get16(data, i); > } > long t1 = System.nanoTime(); > t += t1 - t0; > } > return t / n / 100; > } > > private static final int get16(byte b[], int off) { > return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); > //return Byte.toUnsignedInt(b[off]) | > (Byte.toUnsignedInt(b[off+1]) << 8); > > } > > > On 1/26/2012 5:33 PM, Joe Darcy wrote: >> Sherman, thanks for offering to investigate the performance impact, >> if any, of this change. >> >> -Joe >> >> PS All the jar/zip regression tests pass with this change. >> >> On 01/26/2012 09:52 AM, Xueming Shen wrote: >>> Joe, >>> >>> The changes look fine. However I have the same performance concern in >>> cases that the vm fails to inline the toUnsignedInt(), especially >>> for those >>> "simple" one line utility methods, such as the get16(), CH(), SH(), my >>> guess is that it might have a performance impact. It might not be a big >>> deal for operation like creating or extracting a jar/zip file but >>> probably will >>> slow down the loc/cen table reading only operation such as list a >>> jar/zip >>> file. I will try to get some performance data to see if the impact is >>> "significant" enough to be a real concern. >>> >>> -Sherman >>> >>> On 01/25/2012 08:37 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> As a follow-up to the recent push of unsigned library support in >>>> the JDK [1], I grepped -i for "0xff" in the JDK code base to look >>>> for candidate locations to use the new methods. I choose to first >>>> tackle some jar/zip code. >>>> >>>> Sherman, can you review the changes below? >>>> >>>> diff -r 303b67074666 >>>> src/share/classes/java/util/jar/JarOutputStream.java >>>> --- a/src/share/classes/java/util/jar/JarOutputStream.java Tue >>>> Jan 24 15:13:27 2012 -0500 >>>> +++ b/src/share/classes/java/util/jar/JarOutputStream.java Wed >>>> Jan 25 20:31:05 2012 -0800 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -135,7 +135,7 @@ >>>> * The bytes are assumed to be in Intel (little-endian) byte >>>> order. >>>> */ >>>> private static int get16(byte[] b, int off) { >>>> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); >>>> + return Byte.toUnsignedInt(b[off]) | ( >>>> Byte.toUnsignedInt(b[off+1]) << 8); >>>> } >>>> >>>> /* >>>> diff -r 303b67074666 src/share/classes/java/util/jar/Manifest.java >>>> --- a/src/share/classes/java/util/jar/Manifest.java Tue Jan 24 >>>> 15:13:27 2012 -0500 >>>> +++ b/src/share/classes/java/util/jar/Manifest.java Wed Jan 25 >>>> 20:31:05 2012 -0800 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -339,7 +339,7 @@ >>>> return -1; >>>> } >>>> } >>>> - return buf[pos++] & 0xff; >>>> + return Byte.toUnsignedInt(buf[pos++]); >>>> } >>>> >>>> public int read(byte[] b, int off, int len) throws >>>> IOException { >>>> diff -r 303b67074666 >>>> src/share/classes/java/util/zip/InflaterInputStream.java >>>> --- a/src/share/classes/java/util/zip/InflaterInputStream.java >>>> Tue Jan 24 15:13:27 2012 -0500 >>>> +++ b/src/share/classes/java/util/zip/InflaterInputStream.java >>>> Wed Jan 25 20:31:05 2012 -0800 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -119,7 +119,7 @@ >>>> */ >>>> public int read() throws IOException { >>>> ensureOpen(); >>>> - return read(singleByteBuf, 0, 1) == -1 ? -1 : >>>> singleByteBuf[0] & 0xff; >>>> + return read(singleByteBuf, 0, 1) == -1 ? -1 : >>>> Byte.toUnsignedInt(singleByteBuf[0]); >>>> } >>>> >>>> /** >>>> diff -r 303b67074666 >>>> src/share/classes/java/util/zip/ZipInputStream.java >>>> --- a/src/share/classes/java/util/zip/ZipInputStream.java Tue >>>> Jan 24 15:13:27 2012 -0500 >>>> +++ b/src/share/classes/java/util/zip/ZipInputStream.java Wed >>>> Jan 25 20:31:05 2012 -0800 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -435,7 +435,7 @@ >>>> * The bytes are assumed to be in Intel (little-endian) byte >>>> order. >>>> */ >>>> private static final int get16(byte b[], int off) { >>>> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); >>>> + return Byte.toUnsignedInt(b[off]) | >>>> (Byte.toUnsignedInt(b[off+1]) << 8); >>>> } >>>> >>>> /* >>>> diff -r 303b67074666 >>>> src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java >>>> --- >>>> a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java >>>> Tue Jan 24 15:13:27 2012 -0500 >>>> +++ >>>> b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java >>>> Wed Jan 25 20:31:05 2012 -0800 >>>> @@ -185,11 +185,11 @@ >>>> */ >>>> /////////////////////////////////////////////////////// >>>> static final int CH(byte[] b, int n) { >>>> - return b[n] & 0xff; >>>> + return Byte.toUnsignedInt(b[n]); >>>> } >>>> >>>> static final int SH(byte[] b, int n) { >>>> - return (b[n] & 0xff) | ((b[n + 1] & 0xff) << 8); >>>> + return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n >>>> + 1]) << 8); >>>> } >>>> >>>> static final long LG(byte[] b, int n) { >>>> >>>> If the changes look good, I'll file a bug for them, etc. >>>> >>>> In case other people want to look over candidates sites in >>>> different areas, I've included the list of JDK files using "0xff" >>>> below. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> [1] 4504839: Java libraries should provide support for unsigned >>>> integer arithmetic >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008926.html >>>> >>>> >>>> . >> From alan.bateman at oracle.com Tue Feb 7 13:28:48 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 07 Feb 2012 13:28:48 +0000 Subject: hg: jdk8/tl/jdk: 7142847: TEST_BUG: java/nio/file/WatchService/SensitivityModifier.java has incorrect @run tag, runs Basic Message-ID: <20120207132908.58363473BC@hg.openjdk.java.net> Changeset: c6d6ef8ec2bf Author: alanb Date: 2012-02-07 13:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6d6ef8ec2bf 7142847: TEST_BUG: java/nio/file/WatchService/SensitivityModifier.java has incorrect @run tag, runs Basic Reviewed-by: chegar ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/SensitivityModifier.java From Ulf.Zibis at gmx.de Tue Feb 7 15:23:32 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 07 Feb 2012 16:23:32 +0100 Subject: Using unsigned library work in the JDK - please rename them! In-Reply-To: <4F30B7C3.3040803@oracle.com> References: <4F20D879.8010800@oracle.com> <4F2192C3.3080808@oracle.com> <4F21FEFF.8040100@oracle.com> <4F307809.7050509@oracle.com> <4F30B7C3.3040803@oracle.com> Message-ID: <4F3141F4.1060203@gmx.de> Hi again, isn' there any chance for a renaming? I think, e.g., + return unsigned(b[n]) | (unsigned(b[n + 1]) << 8); would be much more writeable + readable than ... + return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n + 1]) << 8); In 2nd case, static import is not possible, as we have: - int Byte.toUnsignedInt(byte) - int Short.toUnsignedInt(short) but would be very easy, if we only would have: - short Short.unsigned(byte) - int Integer.unsigned(short) - long Long.unsigned(int) - BigInteger BigInteger.unsigned(long) Nothing would be ambiguous, using static import + we should not use casting to get an unsigned short from a byte. Sherman, could you do your performance test, using instead "int Byte.toUnsignedInt(byte)"? : public class Short { public short unsigned(byte b) { return b & 0xFF; } -Ulf Am 07.02.2012 06:33, schrieb Joe Darcy: > Thanks Sherman; given the at most marginal performance cost, I'll push the changes in the next day > or two. > > -Joe > > > On 02/06/2012 05:02 PM, Xueming Shen wrote: >> Joe, >> >> I did some non-scientific measure of the performance. test1() is to measure the change >> in a real "listing" operation on a ZipInputStream and test2() is a pure access on the byte[] >> directly. I don't see any significant difference on performance in both -client and -server >> vm. I would assume the change has no performance impact to the real zip access. >> >> In -client vm >> test1: 108 vs 109 >> test2: 280 : 283 >> >> Simple test case attached (the input is a big enough jar file, such as the rt.jar) >> >> -Sherman >> >> -------------------------------------------- >> >> public static void main(String[] args) throws IOException { >> >> byte[] data = java.nio.file.Files.readAllBytes(new File(args[0]).toPath()); >> ByteArrayInputStream bais = new ByteArrayInputStream(data); >> >> //warm up >> test1(bais, 100); >> System.out.printf("t=%d%n", test1(bais, 500)); >> >> test2(data, 100); >> System.out.printf("t=%d%n", test2(data, 100)); >> } >> >> static long test1(ByteArrayInputStream bais, int n) throws IOException { >> long t = 0; >> for (int i = 0; i < n; i++) { >> bais.reset(); >> >> ZipInputStream zis = new ZipInputStream(bais); >> ZipEntry e; >> long t0 = System.currentTimeMillis(); >> while ((e = zis.getNextEntry()) != null) { >> zis.closeEntry(); >> //System.out.println(new String(e.getName())); >> } >> long t1 = System.currentTimeMillis(); >> t += t1 - t0; >> } >> return t /= n; >> } >> >> >> static long test2(byte data[], int n) throws IOException { >> int j = 10000; >> long t = 0; >> if (j >= data.length -1) >> j = data.length -2; >> for (int m = 0; m < n; m++) { >> long t0 = System.nanoTime(); >> int sum = 0; >> for (int i = 0; i < j; i++) { >> sum += get16(data, i); >> } >> long t1 = System.nanoTime(); >> t += t1 - t0; >> } >> return t / n / 100; >> } >> >> private static final int get16(byte b[], int off) { >> return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); >> //return Byte.toUnsignedInt(b[off]) | (Byte.toUnsignedInt(b[off+1]) << 8); >> >> } >> >> >> On 1/26/2012 5:33 PM, Joe Darcy wrote: >>> Sherman, thanks for offering to investigate the performance impact, if any, of this change. >>> >>> -Joe >>> >>> PS All the jar/zip regression tests pass with this change. >>> >>> On 01/26/2012 09:52 AM, Xueming Shen wrote: >>>> Joe, >>>> >>>> The changes look fine. However I have the same performance concern in >>>> cases that the vm fails to inline the toUnsignedInt(), especially for those >>>> "simple" one line utility methods, such as the get16(), CH(), SH(), my >>>> guess is that it might have a performance impact. It might not be a big >>>> deal for operation like creating or extracting a jar/zip file but probably will >>>> slow down the loc/cen table reading only operation such as list a jar/zip >>>> file. I will try to get some performance data to see if the impact is >>>> "significant" enough to be a real concern. >>>> >>>> -Sherman >>>> >>>> On 01/25/2012 08:37 PM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> As a follow-up to the recent push of unsigned library support in the JDK [1], I grepped -i for >>>>> "0xff" in the JDK code base to look for candidate locations to use the new methods. I choose >>>>> to first tackle some jar/zip code. >>>>> >>>>> Sherman, can you review the changes below? >>>>> >>>>> diff -r 303b67074666 src/share/classes/java/util/jar/JarOutputStream.java >>>>> --- a/src/share/classes/java/util/jar/JarOutputStream.java Tue Jan 24 15:13:27 2012 -0500 >>>>> +++ b/src/share/classes/java/util/jar/JarOutputStream.java Wed Jan 25 20:31:05 2012 -0800 >>>>> @@ -1,5 +1,5 @@ >>>>> /* >>>>> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights reserved. >>>>> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights reserved. >>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> * >>>>> * This code is free software; you can redistribute it and/or modify it >>>>> @@ -135,7 +135,7 @@ >>>>> * The bytes are assumed to be in Intel (little-endian) byte order. >>>>> */ >>>>> private static int get16(byte[] b, int off) { >>>>> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); >>>>> + return Byte.toUnsignedInt(b[off]) | ( Byte.toUnsignedInt(b[off+1]) << 8); >>>>> } >>>>> >>>>> /* >>>>> diff -r 303b67074666 src/share/classes/java/util/jar/Manifest.java >>>>> --- a/src/share/classes/java/util/jar/Manifest.java Tue Jan 24 15:13:27 2012 -0500 >>>>> +++ b/src/share/classes/java/util/jar/Manifest.java Wed Jan 25 20:31:05 2012 -0800 >>>>> @@ -1,5 +1,5 @@ >>>>> /* >>>>> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights reserved. >>>>> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights reserved. >>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> * >>>>> * This code is free software; you can redistribute it and/or modify it >>>>> @@ -339,7 +339,7 @@ >>>>> return -1; >>>>> } >>>>> } >>>>> - return buf[pos++] & 0xff; >>>>> + return Byte.toUnsignedInt(buf[pos++]); >>>>> } >>>>> >>>>> public int read(byte[] b, int off, int len) throws IOException { >>>>> diff -r 303b67074666 src/share/classes/java/util/zip/InflaterInputStream.java >>>>> --- a/src/share/classes/java/util/zip/InflaterInputStream.java Tue Jan 24 15:13:27 2012 -0500 >>>>> +++ b/src/share/classes/java/util/zip/InflaterInputStream.java Wed Jan 25 20:31:05 2012 -0800 >>>>> @@ -1,5 +1,5 @@ >>>>> /* >>>>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights reserved. >>>>> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights reserved. >>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> * >>>>> * This code is free software; you can redistribute it and/or modify it >>>>> @@ -119,7 +119,7 @@ >>>>> */ >>>>> public int read() throws IOException { >>>>> ensureOpen(); >>>>> - return read(singleByteBuf, 0, 1) == -1 ? -1 : singleByteBuf[0] & 0xff; >>>>> + return read(singleByteBuf, 0, 1) == -1 ? -1 : Byte.toUnsignedInt(singleByteBuf[0]); >>>>> } >>>>> >>>>> /** >>>>> diff -r 303b67074666 src/share/classes/java/util/zip/ZipInputStream.java >>>>> --- a/src/share/classes/java/util/zip/ZipInputStream.java Tue Jan 24 15:13:27 2012 -0500 >>>>> +++ b/src/share/classes/java/util/zip/ZipInputStream.java Wed Jan 25 20:31:05 2012 -0800 >>>>> @@ -1,5 +1,5 @@ >>>>> /* >>>>> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights reserved. >>>>> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights reserved. >>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> * >>>>> * This code is free software; you can redistribute it and/or modify it >>>>> @@ -435,7 +435,7 @@ >>>>> * The bytes are assumed to be in Intel (little-endian) byte order. >>>>> */ >>>>> private static final int get16(byte b[], int off) { >>>>> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8); >>>>> + return Byte.toUnsignedInt(b[off]) | (Byte.toUnsignedInt(b[off+1]) << 8); >>>>> } >>>>> >>>>> /* >>>>> diff -r 303b67074666 src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java >>>>> --- a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java Tue Jan 24 15:13:27 >>>>> 2012 -0500 >>>>> +++ b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java Wed Jan 25 20:31:05 >>>>> 2012 -0800 >>>>> @@ -185,11 +185,11 @@ >>>>> */ >>>>> /////////////////////////////////////////////////////// >>>>> static final int CH(byte[] b, int n) { >>>>> - return b[n] & 0xff; >>>>> + return Byte.toUnsignedInt(b[n]); >>>>> } >>>>> >>>>> static final int SH(byte[] b, int n) { >>>>> - return (b[n] & 0xff) | ((b[n + 1] & 0xff) << 8); >>>>> + return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n + 1]) << 8); >>>>> } >>>>> >>>>> static final long LG(byte[] b, int n) { >>>>> >>>>> If the changes look good, I'll file a bug for them, etc. >>>>> >>>>> In case other people want to look over candidates sites in different areas, I've included the >>>>> list of JDK files using "0xff" below. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> [1] 4504839: Java libraries should provide support for unsigned integer arithmetic >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008926.html >>>>> >>>>> . >>> > > From kelly.ohair at oracle.com Tue Feb 7 22:56:01 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 7 Feb 2012 14:56:01 -0800 Subject: Strange messages sent to stderr when using a fastdebug JDK build Message-ID: <03C81FEB-A7E0-4841-8E35-1341D6C13879@oracle.com> I'm seeing all kinds of messages like: bit length overflow code 12 bits 6->7 bit length overflow code 5 bits 6->7 bit length overflow code 5 bits 6->7 When ever a jdk7u or jdk8 fastdebug built jdk is used. It appears to be coming from here: jdk/src/share/native/java/util/zip/zlib-1.2.5/trees.c: Trace((stderr,"\nbit length overflow\n")); These stderr messages get folded into the java users stderr... I don't think we want that. -kto From joe.darcy at oracle.com Wed Feb 8 01:40:05 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 08 Feb 2012 01:40:05 +0000 Subject: hg: jdk8/tl/jdk: 7143629: JDK jar/zip code should use unsigned library support Message-ID: <20120208014023.43199473D2@hg.openjdk.java.net> Changeset: 946056e6116e Author: darcy Date: 2012-02-07 17:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/946056e6116e 7143629: JDK jar/zip code should use unsigned library support Reviewed-by: sherman ! src/share/classes/java/util/jar/JarOutputStream.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/zip/InflaterInputStream.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java From weijun.wang at oracle.com Wed Feb 8 03:45:21 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 08 Feb 2012 03:45:21 +0000 Subject: hg: jdk8/tl/jdk: 6880619: reg tests for 6879540 Message-ID: <20120208034540.77D12473DC@hg.openjdk.java.net> Changeset: 085c4f780d4e Author: weijun Date: 2012-02-08 11:44 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/085c4f780d4e 6880619: reg tests for 6879540 Reviewed-by: valeriep + test/sun/security/krb5/auto/EmptyPassword.java From Alan.Bateman at oracle.com Wed Feb 8 09:35:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Feb 2012 09:35:30 +0000 Subject: Strange messages sent to stderr when using a fastdebug JDK build In-Reply-To: <03C81FEB-A7E0-4841-8E35-1341D6C13879@oracle.com> References: <03C81FEB-A7E0-4841-8E35-1341D6C13879@oracle.com> Message-ID: <4F3241E2.8010703@oracle.com> On 07/02/2012 22:56, Kelly O'Hair wrote: > I'm seeing all kinds of messages like: > > bit length overflow > code 12 bits 6->7 > > bit length overflow > code 5 bits 6->7 > > bit length overflow > code 5 bits 6->7 > > When ever a jdk7u or jdk8 fastdebug built jdk is used. > > It appears to be coming from here: > > jdk/src/share/native/java/util/zip/zlib-1.2.5/trees.c: Trace((stderr,"\nbit length overflow\n")); > > These stderr messages get folded into the java users stderr... I don't think we want that. > > -kto Hopefully Sherman has time to look at this for you. Off-hand, it's probably that the fastdebug build is turning on z_verbose so you are seeing trace messages from the bit twiddling in zlib. -Alan. From chris.hegarty at oracle.com Wed Feb 8 11:20:44 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 08 Feb 2012 11:20:44 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120208112123.3591B473E4@hg.openjdk.java.net> Changeset: c64c815974ff Author: chegar Date: 2012-02-08 11:16 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c64c815974ff 7105929: java/util/concurrent/FutureTask/BlockingTaskExecutor.java fails on solaris sparc Reviewed-by: dholmes ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java Changeset: 7289599216fe Author: gadams Date: 2012-02-08 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7289599216fe 6736316: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient Reviewed-by: chegar, dholmes, alanb ! test/java/util/concurrent/locks/Lock/FlakyMutex.java Changeset: 72d8f91514d1 Author: gadams Date: 2012-02-08 11:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72d8f91514d1 6957683: test/java/util/concurrent/ThreadPoolExecutor/Custom.java failing Reviewed-by: chegar, dholmes, alanb ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java From miroslav.kos at oracle.com Wed Feb 1 15:13:39 2012 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Wed, 01 Feb 2012 16:13:39 +0100 Subject: 7140918: Remove dependency on apt and com.sun.mirror API In-Reply-To: <4F27A17A.1020809@oracle.com> References: <4F26B283.8090103@oracle.com> <4F273AD3.5070207@oracle.com> <4F274012.7090904@oracle.com> <4F274146.9050103@oracle.com> <4F27A17A.1020809@oracle.com> Message-ID: <4F2956A3.1030808@oracle.com> Hi Alan, do you have any update about approving the changeset? The jaxws bundle is already in place, so there should be nothing blocking us from the final step(?) We already have PIT Certificate from QA: https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=13491649 Regards Miran On 31.1.2012 9:08, Alan Bateman wrote: > On 31/01/2012 01:17, David Holmes wrote: >> : >> Okay. So as part of this will the new zip file be installed before >> the change gets pushed? > Yes, that's right. > > -Alan From mikeb01 at gmail.com Sat Feb 4 07:50:15 2012 From: mikeb01 at gmail.com (Michael Barker) Date: Sat, 4 Feb 2012 07:50:15 +0000 Subject: Warning Fixes from LJC Hack Session In-Reply-To: <4F2A6213.4040707@oracle.com> References: <4F2A6213.4040707@oracle.com> Message-ID: > I see R?mi has suggested a slice & dice but I think that's a bit too much > work for the changes involved. Instead I would suggest a simple split, send > the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything else to > core-libs-dev. Attached is the patch that contains "everthing else" from LJC warning fixes hack session. Mike. -------------- next part -------------- diff -r 55a82eba1986 src/share/classes/java/util/jar/Attributes.java --- a/src/share/classes/java/util/jar/Attributes.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/classes/java/util/jar/Attributes.java Sat Feb 04 07:39:48 2012 +0000 @@ -71,7 +71,7 @@ * @param size the initial number of attributes */ public Attributes(int size) { - map = new HashMap(size); + map = new HashMap<>(size); } /** @@ -81,7 +81,7 @@ * @param attr the specified Attributes */ public Attributes(Attributes attr) { - map = new HashMap(attr); + map = new HashMap<>(attr); } @@ -296,9 +296,9 @@ * XXX Need to handle UTF8 values and break up lines longer than 72 bytes */ void write(DataOutputStream os) throws IOException { - Iterator it = entrySet().iterator(); + Iterator> it = entrySet().iterator(); while (it.hasNext()) { - Map.Entry e = (Map.Entry)it.next(); + Map.Entry e = it.next(); StringBuffer buffer = new StringBuffer( ((Name)e.getKey()).toString()); buffer.append(": "); @@ -340,9 +340,9 @@ // write out all attributes except for the version // we wrote out earlier - Iterator it = entrySet().iterator(); + Iterator> it = entrySet().iterator(); while (it.hasNext()) { - Map.Entry e = (Map.Entry)it.next(); + Map.Entry e = it.next(); String name = ((Name)e.getKey()).toString(); if ((version != null) && ! (name.equalsIgnoreCase(vername))) { @@ -499,7 +499,7 @@ */ public boolean equals(Object o) { if (o instanceof Name) { - Comparator c = ASCIICaseInsensitiveComparator.CASE_INSENSITIVE_ORDER; + Comparator c = ASCIICaseInsensitiveComparator.CASE_INSENSITIVE_ORDER; return c.compare(name, ((Name)o).name) == 0; } else { return false; diff -r 55a82eba1986 src/share/classes/java/util/jar/JarVerifier.java --- a/src/share/classes/java/util/jar/JarVerifier.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/classes/java/util/jar/JarVerifier.java Sat Feb 04 07:39:48 2012 +0000 @@ -48,21 +48,21 @@ /* a table mapping names to code signers, for jar entries that have had their actual hashes verified */ - private Hashtable verifiedSigners; + private Hashtable verifiedSigners; /* a table mapping names to code signers, for jar entries that have passed the .SF/.DSA/.EC -> MANIFEST check */ - private Hashtable sigFileSigners; + private Hashtable sigFileSigners; /* a hash table to hold .SF bytes */ - private Hashtable sigFileData; + private Hashtable sigFileData; /** "queue" of pending PKCS7 blocks that we couldn't parse * until we parsed the .SF file */ - private ArrayList pendingBlocks; + private ArrayList pendingBlocks; /* cache of CodeSigner objects */ - private ArrayList signerCache; + private ArrayList signerCache; /* Are we parsing a block? */ private boolean parsingBlockOrSF = false; @@ -94,10 +94,10 @@ public JarVerifier(byte rawBytes[]) { manifestRawBytes = rawBytes; - sigFileSigners = new Hashtable(); - verifiedSigners = new Hashtable(); - sigFileData = new Hashtable(11); - pendingBlocks = new ArrayList(); + sigFileSigners = new Hashtable<>(); + verifiedSigners = new Hashtable<>(); + sigFileData = new Hashtable<>(11); + pendingBlocks = new ArrayList<>(); baos = new ByteArrayOutputStream(); manifestDigests = new ArrayList<>(); } @@ -248,10 +248,9 @@ sigFileData.put(key, bytes); // check pending blocks, we can now process // anyone waiting for this .SF file - Iterator it = pendingBlocks.iterator(); + Iterator it = pendingBlocks.iterator(); while (it.hasNext()) { - SignatureFileVerifier sfv = - (SignatureFileVerifier) it.next(); + SignatureFileVerifier sfv = it.next(); if (sfv.needSignatureFile(key)) { if (debug != null) { debug.println( @@ -270,7 +269,7 @@ String key = uname.substring(0, uname.lastIndexOf(".")); if (signerCache == null) - signerCache = new ArrayList(); + signerCache = new ArrayList<>(); if (manDig == null) { synchronized(manifestRawBytes) { @@ -287,7 +286,7 @@ if (sfv.needSignatureFileBytes()) { // see if we have already parsed an external .SF file - byte[] bytes = (byte[]) sigFileData.get(key); + byte[] bytes = sigFileData.get(key); if (bytes == null) { // put this block on queue for later processing @@ -343,7 +342,7 @@ */ public CodeSigner[] getCodeSigners(String name) { - return (CodeSigner[])verifiedSigners.get(name); + return verifiedSigners.get(name); } public CodeSigner[] getCodeSigners(JarFile jar, JarEntry entry) @@ -376,15 +375,14 @@ CodeSigner[] signers) { if (signers != null) { - ArrayList certChains = new ArrayList(); + ArrayList certChains = new ArrayList<>(); for (int i = 0; i < signers.length; i++) { certChains.addAll( signers[i].getSignerCertPath().getCertificates()); } // Convert into a Certificate[] - return (java.security.cert.Certificate[]) - certChains.toArray( + return certChains.toArray( new java.security.cert.Certificate[certChains.size()]); } return null; @@ -418,8 +416,8 @@ // MANIFEST.MF is always treated as signed and verified, // move its signers from sigFileSigners to verifiedSigners. if (sigFileSigners.containsKey(JarFile.MANIFEST_NAME)) { - verifiedSigners.put(JarFile.MANIFEST_NAME, - sigFileSigners.remove(JarFile.MANIFEST_NAME)); + CodeSigner[] codeSigners = sigFileSigners.remove(JarFile.MANIFEST_NAME); + verifiedSigners.put(JarFile.MANIFEST_NAME, codeSigners); } } @@ -493,10 +491,10 @@ // Extended JavaUtilJarAccess CodeSource API Support - private Map urlToCodeSourceMap = new HashMap(); - private Map signerToCodeSource = new HashMap(); + private Map> urlToCodeSourceMap = new HashMap<>(); + private Map signerToCodeSource = new HashMap<>(); private URL lastURL; - private Map lastURLMap; + private Map lastURLMap; /* * Create a unique mapping from codeSigner cache entries to CodeSource. @@ -504,19 +502,19 @@ * and shared JAR file although in practice there will be a single URL in use. */ private synchronized CodeSource mapSignersToCodeSource(URL url, CodeSigner[] signers) { - Map map; + Map map; if (url == lastURL) { map = lastURLMap; } else { - map = (Map) urlToCodeSourceMap.get(url); + map = urlToCodeSourceMap.get(url); if (map == null) { - map = new HashMap(); + map = new HashMap<>(); urlToCodeSourceMap.put(url, map); } lastURLMap = map; lastURL = url; } - CodeSource cs = (CodeSource) map.get(signers); + CodeSource cs = map.get(signers); if (cs == null) { cs = new VerifierCodeSource(csdomain, url, signers); signerToCodeSource.put(signers, cs); @@ -524,16 +522,16 @@ return cs; } - private CodeSource[] mapSignersToCodeSources(URL url, List signers, boolean unsigned) { - List sources = new ArrayList(); + private CodeSource[] mapSignersToCodeSources(URL url, List signers, boolean unsigned) { + List sources = new ArrayList<>(); for (int i = 0; i < signers.size(); i++) { - sources.add(mapSignersToCodeSource(url, (CodeSigner[]) signers.get(i))); + sources.add(mapSignersToCodeSource(url, signers.get(i))); } if (unsigned) { sources.add(mapSignersToCodeSource(url, null)); } - return (CodeSource[]) sources.toArray(new CodeSource[sources.size()]); + return sources.toArray(new CodeSource[sources.size()]); } private CodeSigner[] emptySigner = new CodeSigner[0]; @@ -553,7 +551,7 @@ * but this handles a CodeSource of any type, just in case. */ CodeSource[] sources = mapSignersToCodeSources(cs.getLocation(), getJarCodeSigners(), true); - List sourceList = new ArrayList(); + List sourceList = new ArrayList<>(); for (int i = 0; i < sources.length; i++) { sourceList.add(sources[i]); } @@ -574,6 +572,7 @@ * signing data that can be compared by object reference identity. */ private static class VerifierCodeSource extends CodeSource { + private static final long serialVersionUID = -9047366145967768825L; URL vlocation; CodeSigner[] vsigners; @@ -641,16 +640,16 @@ return vcerts; } } - private Map signerMap; + private Map signerMap; - private synchronized Map signerMap() { + private synchronized Map signerMap() { if (signerMap == null) { /* * Snapshot signer state so it doesn't change on us. We care * only about the asserted signatures. Verification of * signature validity happens via the JarEntry apis. */ - signerMap = new HashMap(verifiedSigners.size() + sigFileSigners.size()); + signerMap = new HashMap<>(verifiedSigners.size() + sigFileSigners.size()); signerMap.putAll(verifiedSigners); signerMap.putAll(sigFileSigners); } @@ -658,15 +657,15 @@ } public synchronized Enumeration entryNames(JarFile jar, final CodeSource[] cs) { - final Map map = signerMap(); - final Iterator itor = map.entrySet().iterator(); + final Map map = signerMap(); + final Iterator> itor = map.entrySet().iterator(); boolean matchUnsigned = false; /* * Grab a single copy of the CodeSigner arrays. Check * to see if we can optimize CodeSigner equality test. */ - List req = new ArrayList(cs.length); + List req = new ArrayList<>(cs.length); for (int i = 0; i < cs.length; i++) { CodeSigner[] match = findMatchingSigners(cs[i]); if (match != null) { @@ -678,8 +677,8 @@ } } - final List signersReq = req; - final Enumeration enum2 = (matchUnsigned) ? unsignedEntryNames(jar) : emptyEnumeration; + final List signersReq = req; + final Enumeration enum2 = (matchUnsigned) ? unsignedEntryNames(jar) : emptyEnumeration; return new Enumeration() { @@ -691,14 +690,14 @@ } while (itor.hasNext()) { - Map.Entry e = (Map.Entry) itor.next(); - if (signersReq.contains((CodeSigner[]) e.getValue())) { - name = (String) e.getKey(); + Map.Entry e = itor.next(); + if (signersReq.contains(e.getValue())) { + name = e.getKey(); return true; } } while (enum2.hasMoreElements()) { - name = (String) enum2.nextElement(); + name = enum2.nextElement(); return true; } return false; @@ -719,13 +718,13 @@ * Like entries() but screens out internal JAR mechanism entries * and includes signed entries with no ZIP data. */ - public Enumeration entries2(final JarFile jar, Enumeration e) { - final Map map = new HashMap(); + public Enumeration entries2(final JarFile jar, Enumeration e) { + final Map map = new HashMap<>(); map.putAll(signerMap()); - final Enumeration enum_ = e; + final Enumeration enum_ = e; return new Enumeration() { - Enumeration signers = null; + Enumeration signers = null; JarEntry entry; public boolean hasMoreElements() { @@ -744,7 +743,7 @@ signers = Collections.enumeration(map.keySet()); } while (signers.hasMoreElements()) { - String name = (String) signers.nextElement(); + String name = signers.nextElement(); entry = jar.newEntry(new ZipEntry(name)); return true; } @@ -764,7 +763,7 @@ } }; } - private Enumeration emptyEnumeration = new Enumeration() { + private Enumeration emptyEnumeration = new Enumeration() { public boolean hasMoreElements() { return false; @@ -797,8 +796,8 @@ } private Enumeration unsignedEntryNames(JarFile jar) { - final Map map = signerMap(); - final Enumeration entries = jar.entries(); + final Map map = signerMap(); + final Enumeration entries = jar.entries(); return new Enumeration() { String name; @@ -836,14 +835,14 @@ } }; } - private List jarCodeSigners; + private List jarCodeSigners; - private synchronized List getJarCodeSigners() { + private synchronized List getJarCodeSigners() { CodeSigner[] signers; if (jarCodeSigners == null) { - HashSet set = new HashSet(); + HashSet set = new HashSet<>(); set.addAll(signerMap().values()); - jarCodeSigners = new ArrayList(); + jarCodeSigners = new ArrayList<>(); jarCodeSigners.addAll(set); } return jarCodeSigners; @@ -858,7 +857,7 @@ public CodeSource getCodeSource(URL url, String name) { CodeSigner[] signers; - signers = (CodeSigner[]) signerMap().get(name); + signers = signerMap().get(name); return mapSignersToCodeSource(url, signers); } diff -r 55a82eba1986 src/share/classes/sun/tools/jar/CommandLine.java --- a/src/share/classes/sun/tools/jar/CommandLine.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/classes/sun/tools/jar/CommandLine.java Sat Feb 04 07:39:48 2012 +0000 @@ -55,7 +55,7 @@ public static String[] parse(String[] args) throws IOException { - ArrayList newArgs = new ArrayList(args.length); + List newArgs = new ArrayList<>(args.length); for (int i = 0; i < args.length; i++) { String arg = args[i]; if (arg.length() > 1 && arg.charAt(0) == '@') { @@ -69,10 +69,10 @@ newArgs.add(arg); } } - return (String[])newArgs.toArray(new String[newArgs.size()]); + return newArgs.toArray(new String[newArgs.size()]); } - private static void loadCmdFile(String name, List args) + private static void loadCmdFile(String name, List args) throws IOException { Reader r = new BufferedReader(new FileReader(name)); @@ -83,7 +83,7 @@ st.commentChar('#'); st.quoteChar('"'); st.quoteChar('\''); - while (st.nextToken() != st.TT_EOF) { + while (st.nextToken() != StreamTokenizer.TT_EOF) { args.add(st.sval); } r.close(); diff -r 55a82eba1986 src/share/classes/sun/tools/jar/Manifest.java --- a/src/share/classes/sun/tools/jar/Manifest.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/classes/sun/tools/jar/Manifest.java Sat Feb 04 07:39:48 2012 +0000 @@ -47,10 +47,10 @@ /* list of headers that all pertain to a particular * file in the archive */ - private Vector entries = new Vector(); + private Vector entries = new Vector<>(); private byte[] tmpbuf = new byte[512]; /* a hashtable of entries, for fast lookup */ - private Hashtable tableEntries = new Hashtable(); + private Hashtable tableEntries = new Hashtable<>(); static final String[] hashes = {"SHA"}; static final byte[] EOL = {(byte)'\r', (byte)'\n'}; @@ -115,14 +115,14 @@ } public MessageHeader getEntry(String name) { - return (MessageHeader) tableEntries.get(name); + return tableEntries.get(name); } public MessageHeader entryAt(int i) { - return (MessageHeader) entries.elementAt(i); + return entries.elementAt(i); } - public Enumeration entries() { + public Enumeration entries() { return entries.elements(); } @@ -214,7 +214,7 @@ /* the first header in the file should be the global one. * It should say "Manifest-Version: x.x"; if not add it */ - MessageHeader globals = (MessageHeader) entries.elementAt(0); + MessageHeader globals = entries.elementAt(0); if (globals.findValue("Manifest-Version") == null) { /* Assume this is a user-defined manifest. If it has a Name: <..> @@ -238,7 +238,7 @@ globals.print(ps); for (int i = 1; i < entries.size(); ++i) { - MessageHeader mh = (MessageHeader) entries.elementAt(i); + MessageHeader mh = entries.elementAt(i); mh.print(ps); } } diff -r 55a82eba1986 src/share/classes/sun/tools/jar/SignatureFile.java --- a/src/share/classes/sun/tools/jar/SignatureFile.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/classes/sun/tools/jar/SignatureFile.java Sat Feb 04 07:39:48 2012 +0000 @@ -66,7 +66,7 @@ /* list of headers that all pertain to a particular file in the * archive */ - private Vector entries = new Vector(); + private Vector entries = new Vector<>(); /* Right now we only support SHA hashes */ static final String[] hashes = {"SHA"}; @@ -98,7 +98,7 @@ * character in length. */ private SignatureFile(String name) throws JarException { - entries = new Vector(); + entries = new Vector<>(); if (name != null) { if (name.length() > 8 || name.indexOf('.') != -1) { @@ -142,9 +142,9 @@ this(name, true); this.manifest = manifest; - Enumeration enum_ = manifest.entries(); + Enumeration enum_ = manifest.entries(); while (enum_.hasMoreElements()) { - MessageHeader mh = (MessageHeader)enum_.nextElement(); + MessageHeader mh = enum_.nextElement(); String entryName = mh.findValue("Name"); if (entryName != null) { add(entryName); @@ -269,9 +269,9 @@ *the entry does not exist. */ public MessageHeader getEntry(String name) { - Enumeration enum_ = entries(); + Enumeration enum_ = entries(); while(enum_.hasMoreElements()) { - MessageHeader mh = (MessageHeader)enum_.nextElement(); + MessageHeader mh = enum_.nextElement(); if (name.equals(mh.findValue("Name"))) { return mh; } @@ -282,13 +282,13 @@ /** * Returns the n-th entry. The global header is a entry 0. */ public MessageHeader entryAt(int n) { - return (MessageHeader) entries.elementAt(n); + return entries.elementAt(n); } /** * Returns an enumeration of the entries. */ - public Enumeration entries() { + public Enumeration entries() { return entries.elements(); } @@ -322,11 +322,11 @@ } } - private Hashtable digests = new Hashtable(); + private Hashtable digests = new Hashtable<>(); private MessageDigest getDigest(String algorithm) throws NoSuchAlgorithmException { - MessageDigest dig = (MessageDigest)digests.get(algorithm); + MessageDigest dig = digests.get(algorithm); if (dig == null) { dig = MessageDigest.getInstance(algorithm); digests.put(algorithm, dig); @@ -344,7 +344,7 @@ /* the first header in the file should be the global one. * It should say "SignatureFile-Version: x.x"; barf if not */ - MessageHeader globals = (MessageHeader) entries.elementAt(0); + MessageHeader globals = entries.elementAt(0); if (globals.findValue("Signature-Version") == null) { throw new JarException("Signature file requires " + "Signature-Version: 1.0 in 1st header"); @@ -354,7 +354,7 @@ globals.print(ps); for (int i = 1; i < entries.size(); ++i) { - MessageHeader mh = (MessageHeader) entries.elementAt(i); + MessageHeader mh = entries.elementAt(i); mh.print(ps); } } diff -r 55a82eba1986 src/share/demo/management/MemoryMonitor/MemoryMonitor.java --- a/src/share/demo/management/MemoryMonitor/MemoryMonitor.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/demo/management/MemoryMonitor/MemoryMonitor.java Sat Feb 04 07:39:48 2012 +0000 @@ -213,10 +213,10 @@ // Calculate remaining size float ssH = ascent + descent; - float remainingHeight = (float) (y2 - (ssH*2) - 0.5f); + float remainingHeight = (y2 - (ssH*2) - 0.5f); float blockHeight = remainingHeight/10; float blockWidth = 20.0f; - float remainingWidth = (float) (x2 - blockWidth - 10); + float remainingWidth = (x2 - blockWidth - 10); // .. Memory Free .. big.setColor(mfColor); @@ -224,7 +224,7 @@ int i = 0; for ( ; i < MemUsage ; i++) { mfRect.setRect(x1+5,(float) y1+ssH+i*blockHeight, - blockWidth,(float) blockHeight-1); + blockWidth, blockHeight-1); big.fill(mfRect); } @@ -232,13 +232,13 @@ big.setColor(Color.green); for ( ; i < 10; i++) { muRect.setRect(x1+5,(float) y1 + ssH+i*blockHeight, - blockWidth,(float) blockHeight-1); + blockWidth, blockHeight-1); big.fill(muRect); } // .. Draw History Graph .. if (remainingWidth <= 30) remainingWidth = (float)30; - if (remainingHeight <= ssH) remainingHeight = (float)ssH; + if (remainingHeight <= ssH) remainingHeight = ssH; big.setColor(graphColor); int graphX = x1+30; int graphY = y1 + (int) ssH; @@ -347,8 +347,8 @@ big = bimg.createGraphics(); big.setFont(font); FontMetrics fm = big.getFontMetrics(font); - ascent = (int) fm.getAscent(); - descent = (int) fm.getDescent(); + ascent = fm.getAscent(); + descent = fm.getDescent(); } repaint(); try { diff -r 55a82eba1986 src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java --- a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java Sat Feb 04 07:39:48 2012 +0000 @@ -61,7 +61,7 @@ private final ZipFileSystem zfs; ZipFileStore(ZipPath zpath) { - this.zfs = (ZipFileSystem)zpath.getFileSystem(); + this.zfs = zpath.getFileSystem(); } @Override diff -r 55a82eba1986 src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java --- a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java Sat Feb 04 07:39:48 2012 +0000 @@ -1609,7 +1609,7 @@ synchronized (inflaters) { int size = inflaters.size(); if (size > 0) { - Inflater inf = (Inflater)inflaters.remove(size - 1); + Inflater inf = inflaters.remove(size - 1); return inf; } else { return new Inflater(true); @@ -1638,7 +1638,7 @@ synchronized (deflaters) { int size = deflaters.size(); if (size > 0) { - Deflater def = (Deflater)deflaters.remove(size - 1); + Deflater def = deflaters.remove(size - 1); return def; } else { return new Deflater(Deflater.DEFAULT_COMPRESSION, true); diff -r 55a82eba1986 src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java --- a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java Sat Feb 04 07:39:48 2012 +0000 @@ -211,7 +211,7 @@ public V getFileAttributeView(Path path, Class type, LinkOption... options) { - return (V)ZipFileAttributeView.get(toZipPath(path), type); + return ZipFileAttributeView.get(toZipPath(path), type); } @Override diff -r 55a82eba1986 src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java --- a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java Wed Feb 01 16:00:39 2012 -0800 +++ b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java Sat Feb 04 07:39:48 2012 +0000 @@ -78,12 +78,12 @@ // twice long len = LOCHDR + CENNAM(cen, pos) + CENEXT(cen, pos) + CENHDR; if (zfs.readFullyAt(buf, 0, len, locoff(cen, pos)) != len) - zfs.zerror("read loc header failed"); + ZipFileSystem.zerror("read loc header failed"); if (LOCEXT(buf) > CENEXT(cen, pos) + CENHDR) { // have to read the second time; len = LOCHDR + LOCNAM(buf) + LOCEXT(buf); if (zfs.readFullyAt(buf, 0, len, locoff(cen, pos)) != len) - zfs.zerror("read loc header failed"); + ZipFileSystem.zerror("read loc header failed"); } printLOC(buf); pos += CENHDR + CENNAM(cen, pos) + CENEXT(cen, pos) + CENCOM(cen, pos); From huizhe.wang at oracle.com Wed Feb 8 22:13:11 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 08 Feb 2012 14:13:11 -0800 Subject: Please review: 7143711 : Feature added by 7053556 should not override what's set by the constructor in secure mode In-Reply-To: References: <4EF4F236.3080200@oracle.com> <4EFAF5C7.90509@oracle.com> <4EFB4F74.9010809@oracle.com> <4EFDC736.1090302@oracle.com> <4EFDFEE5.1080803@oracle.com> Message-ID: <4F32F377.5080706@oracle.com> Hi, The 7053556 patch added a (Oracle) implementation-only feature to allow users to skip the plugability layer. In the same patch, there was also a change that in secure mode, dependent components should be loaded in a hardwired mode. The implementation-only feature therefore should not override what's set by the constructor in secure mode. Please consider this is a supplemental change to 7053556 since it itself is a change for 7u4. Below are the changes: Index: com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java --- com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java Base (BASE) +++ com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java Locally Modified (Based On LOCAL) @@ -487,6 +487,8 @@ return; } else if (name.equals(XalanConstants.ORACLE_FEATURE_SERVICE_MECHANISM)) { + //in secure mode, let _useServicesMechanism be determined by the constructor + if (!_isSecureMode) _useServicesMechanism = value; } else { Index: com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java --- com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java Base (BASE) +++ com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java Locally Modified (Based On LOCAL) @@ -226,6 +226,8 @@ return; } if (name.equals(XalanConstants.ORACLE_FEATURE_SERVICE_MECHANISM)) { + //in secure mode, let _useServicesMechanism be determined by the constructor + if (!_isSecureMode) _useServicesMechanism = value; return; } Index: com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java --- com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java Base (BASE) +++ com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java Locally Modified (Based On LOCAL) @@ -390,6 +390,10 @@ fSecurityManager = value ? new SecurityManager() : null; fXMLSchemaLoader.setProperty(SECURITY_MANAGER, fSecurityManager); return; + } else if (name.equals(Constants.ORACLE_FEATURE_SERVICE_MECHANISM)) { + //in secure mode, let _useServicesMechanism be determined by the constructor + if (System.getSecurityManager() != null) + return; } try { fXMLSchemaLoader.setFeature(name, value); Thanks, Joe From xueming.shen at oracle.com Thu Feb 9 06:26:54 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 08 Feb 2012 22:26:54 -0800 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 Message-ID: <4F33672E.7020302@oracle.com> Hi This is a long standing "regression" from 1.3.1 on how OutputStreamWriter.flush()/flushBuffer() handles escape or shift sequence in some of the charset/encoding, for example the ISO-2022-JP. ISO-2022-JP is encoding that starts with ASCII mode and then switches between ASCII andJapanese characters through an escape sequence. For example, the escape sequence ESC $ B (0x1B, 0x24 0x42) is used to indicate the following bytes are Japanese (switch from ASCII mode to Japanese mode), and the ESC ( B (0x1b 0x28 0x42) is used to switch back to ASCII. In Java's sun.io.CharToByteConvert (old generation charset converter) and the nio.io.charset.CharsetEncoder usually switches back forth between ASCII and Japanese modes based on the input character sequence (for example, if you are in ASCII mode, and your next input character is a Japanese, you add the ESC $ B into the output first and then followed the converted input character, or if you are in Japanese mode and your next input is ASCII, you output ESC ( B first to switch the mode and then the ASCII) and switch back to ASCII mode (if the last mode is non-Japanese) if either the encoding is ending or the flush() method gets invoked. In JDK1.3.1, OutputStreamWriter.flushBuffer() explicitly invokes sun.io.c2b's flushAny() to switch back to ASCII mode every time the flush() or flushBuffer() (from PrintStream) gets invoked, as showed at the end of this email. For example, as showed below, the code uses OutputStreamWriter to "write" a Japanese character \u6700 to the underlying stream with iso-2022jp, ByteArrayOutputStream bos = new ByteArrayOutputStream(); String str = "\u6700"; OutputStreamWriter osw = new OutputStreamWriter(bos, "iso-2022-jp"); osw.write(str, 0, str.length()); Since the iso-2022-jp starts with ASCII mode, we now have a Japanese, so we need to switch into Japanese mode first (the first 3 bytes) and then the encoded Japanese character (the following 2 bytes) 0x1b 0x24 0x42 0x3a 0x47 and then the code invokes osw.flush(); since we are now in Japanese, the writer continues to write out 0x1b 0x28 0x 42 to switch back to ASCII mode. The total output is 8 bytes after write() and flush(). However, when all encoidng/charset related codes were migrated from 1.3.1's sun.io based to 1.4's java.nio.charset based implementation (1.4, 1.4.1 and 1.4.2, we gradually migrated from sun.io to java.nio.charset), the "c2b.flushAny()" invocation obviously was dropped in sun.nio.cs.StreamEncoder. It results in that the "switch back to ASCII mode" sequence is no longer output when OutputStreamWriter.flush() or PrintStream.write(String) is invoked. This does not trigger problem for most use scenario, if the "stream" finally gets closed (in which the StreamEncoder does invoke encoder's flush() to output the escape sequence to switch back to ASCII) or PrintStream.println(String) is used (in which it outputs a \n character, since this \n is in ASCII range, it "accidentally " switches the mode back to ASCII). But it obviously causes problem when you can't not close the OutputStreamWriter after you're done your iso2022-jp writing (for example, you need continue to use the underlying OutputStream for other writing, but not "this" osw), for 1.3.1, these apps invoke osw.flush() to force the output switch back to ASCII, this no longer works when we switch to java.nio.charset in jdk1.4.2. (we migrated iso-2022-jp to nio.charset in 1.4.2). This is what happened in JavaMail, as described in the bug report. The solution is to re-store the "flush the encoder" mechanism in StreamEncoder's flushBuffer(). I have been hesitated to make this change for a while, mostly because this regressed behavior has been their for 3 releases, and the change triggers yet another "behavior change". But given there is no obvious workaround and it only changes the behavior of the charsets with this shift in/out mechanism, mainly the iso-2022 family and those IBM EBCDIC_DBCS charsets, I decided to give it a try. Here is the webreview http://cr.openjdk.java.net/~sherman/6995537/webrev Sherman ---------------------------------1.3.1 OutputStreamWriter----------------------- /** * Flush the output buffer to the underlying byte stream, without flushing * the byte stream itself. This method is non-private only so that it may * be invoked by PrintStream. */ void flushBuffer() throws IOException { synchronized (lock) { ensureOpen(); for (;;) { try { nextByte += ctb.flushAny(bb, nextByte, nBytes); } catch (ConversionBufferFullException x) { nextByte = ctb.nextByteIndex(); } if (nextByte == 0) break; if (nextByte > 0) { out.write(bb, 0, nextByte); nextByte = 0; } } } } /** * Flush the stream. * * @exception IOException If an I/O error occurs */ public void flush() throws IOException { synchronized (lock) { flushBuffer(); out.flush(); } } From masayoshi.okutsu at oracle.com Thu Feb 9 08:26:21 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 09 Feb 2012 17:26:21 +0900 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F33672E.7020302@oracle.com> References: <4F33672E.7020302@oracle.com> Message-ID: <4F33832D.3090807@oracle.com> First of all, is this really a Java SE bug? The usage of OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo method in the bug report doesn't seem to be able to deal with any stateful encodings. Masayoshi On 2/9/2012 3:26 PM, Xueming Shen wrote: > Hi > > This is a long standing "regression" from 1.3.1 on how > OutputStreamWriter.flush()/flushBuffer() > handles escape or shift sequence in some of the charset/encoding, for > example the ISO-2022-JP. > > ISO-2022-JP is encoding that starts with ASCII mode and then switches > between ASCII andJapanese > characters through an escape sequence. For example, the escape > sequence ESC $ B (0x1B, 0x24 0x42) > is used to indicate the following bytes are Japanese (switch from > ASCII mode to Japanese mode), and > the ESC ( B (0x1b 0x28 0x42) is used to switch back to ASCII. > > In Java's sun.io.CharToByteConvert (old generation charset converter) > and the nio.io.charset.CharsetEncoder > usually switches back forth between ASCII and Japanese modes based on > the input character sequence > (for example, if you are in ASCII mode, and your next input character > is a Japanese, you add the > ESC $ B into the output first and then followed the converted input > character, or if you are in Japanese > mode and your next input is ASCII, you output ESC ( B first to switch > the mode and then the ASCII) and > switch back to ASCII mode (if the last mode is non-Japanese) if either > the encoding is ending or the > flush() method gets invoked. > > In JDK1.3.1, OutputStreamWriter.flushBuffer() explicitly invokes > sun.io.c2b's flushAny() to switch > back to ASCII mode every time the flush() or flushBuffer() (from > PrintStream) gets invoked, as > showed at the end of this email. For example, as showed below, the > code uses OutputStreamWriter > to "write" a Japanese character \u6700 to the underlying stream with > iso-2022jp, > > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > String str = "\u6700"; > OutputStreamWriter osw = new OutputStreamWriter(bos, "iso-2022-jp"); > osw.write(str, 0, str.length()); > > Since the iso-2022-jp starts with ASCII mode, we now have a Japanese, > so we need to > switch into Japanese mode first (the first 3 bytes) and then the > encoded Japanese > character (the following 2 bytes) > > 0x1b 0x24 0x42 0x3a 0x47 > > and then the code invokes > > osw.flush(); > > since we are now in Japanese, the writer continues to write out > > 0x1b 0x28 0x 42 > > to switch back to ASCII mode. The total output is 8 bytes after > write() and flush(). > > However, when all encoidng/charset related codes were migrated from > 1.3.1's sun.io based to > 1.4's java.nio.charset based implementation (1.4, 1.4.1 and 1.4.2, we > gradually migrated from > sun.io to java.nio.charset), the "c2b.flushAny()" invocation > obviously was dropped in > sun.nio.cs.StreamEncoder. It results in that the "switch back to ASCII > mode" sequence is no longer > output when OutputStreamWriter.flush() or PrintStream.write(String) is > invoked. > > This does not trigger problem for most use scenario, if the "stream" > finally gets closed > (in which the StreamEncoder does invoke encoder's flush() to output > the escape sequence > to switch back to ASCII) or PrintStream.println(String) is used (in > which it outputs a \n character, > since this \n is in ASCII range, it "accidentally " switches the mode > back to ASCII). > > But it obviously causes problem when you can't not close the > OutputStreamWriter after > you're done your iso2022-jp writing (for example, you need continue to > use the underlying > OutputStream for other writing, but not "this" osw), for 1.3.1, these > apps invoke osw.flush() > to force the output switch back to ASCII, this no longer works when we > switch to java.nio.charset > in jdk1.4.2. (we migrated iso-2022-jp to nio.charset in 1.4.2). This > is what happened in JavaMail, > as described in the bug report. > > The solution is to re-store the "flush the encoder" mechanism in > StreamEncoder's flushBuffer(). > > I have been hesitated to make this change for a while, mostly because > this regressed behavior > has been their for 3 releases, and the change triggers yet another > "behavior change". But given > there is no obvious workaround and it only changes the behavior of the > charsets with this > shift in/out mechanism, mainly the iso-2022 family and those IBM > EBCDIC_DBCS charsets, I > decided to give it a try. > > Here is the webreview > > http://cr.openjdk.java.net/~sherman/6995537/webrev > > Sherman > > > ---------------------------------1.3.1 > OutputStreamWriter----------------------- > /** > * Flush the output buffer to the underlying byte stream, without > flushing > * the byte stream itself. This method is non-private only so > that it may > * be invoked by PrintStream. > */ > void flushBuffer() throws IOException { > synchronized (lock) { > ensureOpen(); > > for (;;) { > try { > nextByte += ctb.flushAny(bb, nextByte, nBytes); > } > catch (ConversionBufferFullException x) { > nextByte = ctb.nextByteIndex(); > } > if (nextByte == 0) > break; > if (nextByte > 0) { > out.write(bb, 0, nextByte); > nextByte = 0; > } > } > } > } > > /** > * Flush the stream. > * > * @exception IOException If an I/O error occurs > */ > public void flush() throws IOException { > synchronized (lock) { > flushBuffer(); > out.flush(); > } > } > > > > From alan.bateman at oracle.com Thu Feb 9 13:45:50 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2012 13:45:50 +0000 Subject: hg: jdk8/tl/jdk: 7114611: (fs) DirectoryStream fails with SIGBUS on some embedded platforms, dirent alignment Message-ID: <20120209134626.6B1D94740E@hg.openjdk.java.net> Changeset: 184b9cb4f13a Author: alanb Date: 2012-02-09 13:43 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184b9cb4f13a 7114611: (fs) DirectoryStream fails with SIGBUS on some embedded platforms, dirent alignment Reviewed-by: dholmes, alanb Contributed-by: carlos.lucasius at oracle.com ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c From alan.bateman at oracle.com Thu Feb 9 16:39:29 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2012 16:39:29 +0000 Subject: hg: jdk8/tl/jdk: 7144086: TEST_BUG: java/nio/file/WatchService/SensitivityModifier.java failing intermittently Message-ID: <20120209163946.4821447413@hg.openjdk.java.net> Changeset: 8326d434681d Author: alanb Date: 2012-02-09 16:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8326d434681d 7144086: TEST_BUG: java/nio/file/WatchService/SensitivityModifier.java failing intermittently Reviewed-by: chegar ! test/java/nio/file/WatchService/SensitivityModifier.java From jason_mehrens at hotmail.com Thu Feb 9 18:24:29 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 9 Feb 2012 12:24:29 -0600 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F33672E.7020302@oracle.com> References: <4F33672E.7020302@oracle.com> Message-ID: Sherman, As a workaround, what about allowing a write of empty string or empty char array to call flushBuffer? If you call PrintStream.print("") then flushBuffer is called on the internal writers. But if you try the same by doing OuputStreamWriter.write("") the flushbuffer call is trapped by a zero len if condition in StreamEncoder.write(char[], int, int). That seems inconsistent. If that check was removed then the workaround would be: =================== ByteArrayOutputStream bos = new ByteArrayOutputStream(); String str = "\u6700"; OutputStreamWriter osw = new OutputStreamWriter(bos, "iso-2022-jp"); osw.write(str, 0, str.length()); osw.write(""); //Flush buffer. osw.flush(); //Flush stream. ================== It's not pretty but, it would allow the caller to choose when flushBuffer is called. Jason > Date: Wed, 8 Feb 2012 22:26:54 -0800 > From: xueming.shen at oracle.com > To: core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net > Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 > > The solution is to re-store the "flush the encoder" mechanism in > StreamEncoder's flushBuffer(). > > I have been hesitated to make this change for a while, mostly because > this regressed behavior > has been their for 3 releases, and the change triggers yet another > "behavior change". But given > there is no obvious workaround and it only changes the behavior of the > charsets with this > shift in/out mechanism, mainly the iso-2022 family and those IBM > EBCDIC_DBCS charsets, I > decided to give it a try. > > Here is the webreview > > http://cr.openjdk.java.net/~sherman/6995537/webrev > > Sherman > From xueming.shen at oracle.com Thu Feb 9 19:10:39 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 09 Feb 2012 11:10:39 -0800 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F33832D.3090807@oracle.com> References: <4F33672E.7020302@oracle.com> <4F33832D.3090807@oracle.com> Message-ID: <4F341A2F.7060700@oracle.com> CharsetEncoder has the "flush()" method as the last step (of a series of "encoding" steps) to flush out any internal state to the output buffer. The issue here is the the upper level wrapper class, OutputStreamWriter in our case, doesn't provide a "explicit" mechanism to let the user to request a "flush" on the underlying encoder. The only "guaranteed' mechanism is the "close()" method, in which it appears it not appropriate to invoke in some use scenario, such as the JavaMail.writeTo() case. It appears we are lacking of a "close this stream, but not the underlying stream" mechanism in our layered/chained streams, I have similar request for this kind of mechanism in other area, such as in zip/gzip stream, app wraps a "outputstream" with zip/gzip, they want to release the zip/gzip layer after use (to release the native resource, for example) but want to keep the underlying stream unclosed. The only workaround now is to wrap the underlying stream with a subclass to override the "close()" method, which is really not desirable. The OutputStreamWriter.flush() does not explicitly specify in its API doc if it should actually flush the underlying charset encoder (so I would not argue strongly that this IS a SE bug) but given it is flushing it's buffer (internal status) and then the underlying "out" stream, it's reasonable to consider that the "internal status" of its encoder also needs to be flushed. Especially this has been the behavior for releases earlier than 1.4.2. As I said, while I have been hesitated to "fix" this problem for a while (one it has been here for 3 major releases, two, the API does not explicitly say so) but as long as we don't have a reasonable "close-ME-only" mechanism for those layered streams, it appears to be a reasonable approach to solve the problem, without having obvious negative impact. -Sherman PS: There is another implementation "detail" that the original iso-2022-jp c2b converter actually restores the state back to ASCII mode at the end of its "convert" method, this makes the analysis a little complicated, but should not change the issue we are discussing) On 02/09/2012 12:26 AM, Masayoshi Okutsu wrote: > First of all, is this really a Java SE bug? The usage of > OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo > method in the bug report doesn't seem to be able to deal with any > stateful encodings. > > Masayoshi > > On 2/9/2012 3:26 PM, Xueming Shen wrote: >> Hi >> >> This is a long standing "regression" from 1.3.1 on how >> OutputStreamWriter.flush()/flushBuffer() >> handles escape or shift sequence in some of the charset/encoding, for >> example the ISO-2022-JP. >> >> ISO-2022-JP is encoding that starts with ASCII mode and then switches >> between ASCII andJapanese >> characters through an escape sequence. For example, the escape >> sequence ESC $ B (0x1B, 0x24 0x42) >> is used to indicate the following bytes are Japanese (switch from >> ASCII mode to Japanese mode), and >> the ESC ( B (0x1b 0x28 0x42) is used to switch back to ASCII. >> >> In Java's sun.io.CharToByteConvert (old generation charset converter) >> and the nio.io.charset.CharsetEncoder >> usually switches back forth between ASCII and Japanese modes based on >> the input character sequence >> (for example, if you are in ASCII mode, and your next input character >> is a Japanese, you add the >> ESC $ B into the output first and then followed the converted input >> character, or if you are in Japanese >> mode and your next input is ASCII, you output ESC ( B first to switch >> the mode and then the ASCII) and >> switch back to ASCII mode (if the last mode is non-Japanese) if >> either the encoding is ending or the >> flush() method gets invoked. >> >> In JDK1.3.1, OutputStreamWriter.flushBuffer() explicitly invokes >> sun.io.c2b's flushAny() to switch >> back to ASCII mode every time the flush() or flushBuffer() (from >> PrintStream) gets invoked, as >> showed at the end of this email. For example, as showed below, the >> code uses OutputStreamWriter >> to "write" a Japanese character \u6700 to the underlying stream with >> iso-2022jp, >> >> ByteArrayOutputStream bos = new ByteArrayOutputStream(); >> String str = "\u6700"; >> OutputStreamWriter osw = new OutputStreamWriter(bos, "iso-2022-jp"); >> osw.write(str, 0, str.length()); >> >> Since the iso-2022-jp starts with ASCII mode, we now have a Japanese, >> so we need to >> switch into Japanese mode first (the first 3 bytes) and then the >> encoded Japanese >> character (the following 2 bytes) >> >> 0x1b 0x24 0x42 0x3a 0x47 >> >> and then the code invokes >> >> osw.flush(); >> >> since we are now in Japanese, the writer continues to write out >> >> 0x1b 0x28 0x 42 >> >> to switch back to ASCII mode. The total output is 8 bytes after >> write() and flush(). >> >> However, when all encoidng/charset related codes were migrated from >> 1.3.1's sun.io based to >> 1.4's java.nio.charset based implementation (1.4, 1.4.1 and 1.4.2, we >> gradually migrated from >> sun.io to java.nio.charset), the "c2b.flushAny()" invocation >> obviously was dropped in >> sun.nio.cs.StreamEncoder. It results in that the "switch back to >> ASCII mode" sequence is no longer >> output when OutputStreamWriter.flush() or PrintStream.write(String) >> is invoked. >> >> This does not trigger problem for most use scenario, if the "stream" >> finally gets closed >> (in which the StreamEncoder does invoke encoder's flush() to output >> the escape sequence >> to switch back to ASCII) or PrintStream.println(String) is used (in >> which it outputs a \n character, >> since this \n is in ASCII range, it "accidentally " switches the mode >> back to ASCII). >> >> But it obviously causes problem when you can't not close the >> OutputStreamWriter after >> you're done your iso2022-jp writing (for example, you need continue >> to use the underlying >> OutputStream for other writing, but not "this" osw), for 1.3.1, >> these apps invoke osw.flush() >> to force the output switch back to ASCII, this no longer works when >> we switch to java.nio.charset >> in jdk1.4.2. (we migrated iso-2022-jp to nio.charset in 1.4.2). This >> is what happened in JavaMail, >> as described in the bug report. >> >> The solution is to re-store the "flush the encoder" mechanism in >> StreamEncoder's flushBuffer(). >> >> I have been hesitated to make this change for a while, mostly because >> this regressed behavior >> has been their for 3 releases, and the change triggers yet another >> "behavior change". But given >> there is no obvious workaround and it only changes the behavior of >> the charsets with this >> shift in/out mechanism, mainly the iso-2022 family and those IBM >> EBCDIC_DBCS charsets, I >> decided to give it a try. >> >> Here is the webreview >> >> http://cr.openjdk.java.net/~sherman/6995537/webrev >> >> Sherman >> >> >> ---------------------------------1.3.1 >> OutputStreamWriter----------------------- >> /** >> * Flush the output buffer to the underlying byte stream, without >> flushing >> * the byte stream itself. This method is non-private only so >> that it may >> * be invoked by PrintStream. >> */ >> void flushBuffer() throws IOException { >> synchronized (lock) { >> ensureOpen(); >> >> for (;;) { >> try { >> nextByte += ctb.flushAny(bb, nextByte, nBytes); >> } >> catch (ConversionBufferFullException x) { >> nextByte = ctb.nextByteIndex(); >> } >> if (nextByte == 0) >> break; >> if (nextByte > 0) { >> out.write(bb, 0, nextByte); >> nextByte = 0; >> } >> } >> } >> } >> >> /** >> * Flush the stream. >> * >> * @exception IOException If an I/O error occurs >> */ >> public void flush() throws IOException { >> synchronized (lock) { >> flushBuffer(); >> out.flush(); >> } >> } >> >> >> >> From xueming.shen at oracle.com Thu Feb 9 19:12:06 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 09 Feb 2012 11:12:06 -0800 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F341A2F.7060700@oracle.com> References: <4F33672E.7020302@oracle.com> <4F33832D.3090807@oracle.com> <4F341A2F.7060700@oracle.com> Message-ID: <4F341A86.8090004@oracle.com> CCed Bill Shannon. On 02/09/2012 11:10 AM, Xueming Shen wrote: > > CharsetEncoder has the "flush()" method as the last step (of a series > of "encoding" steps) to > flush out any internal state to the output buffer. The issue here is > the the upper level wrapper > class, OutputStreamWriter in our case, doesn't provide a "explicit" > mechanism to let the > user to request a "flush" on the underlying encoder. The only > "guaranteed' mechanism is the > "close()" method, in which it appears it not appropriate to invoke in > some use scenario, such > as the JavaMail.writeTo() case. > > It appears we are lacking of a "close this stream, but not the > underlying stream" mechanism > in our layered/chained streams, I have similar request for this kind > of mechanism in other area, > such as in zip/gzip stream, app wraps a "outputstream" with zip/gzip, > they want to release the > zip/gzip layer after use (to release the native resource, for example) > but want to keep the > underlying stream unclosed. The only workaround now is to wrap the > underlying stream with > a subclass to override the "close()" method, which is really not > desirable. > > The OutputStreamWriter.flush() does not explicitly specify in its API > doc if it should actually > flush the underlying charset encoder (so I would not argue strongly > that this IS a SE bug) but > given it is flushing it's buffer (internal status) and then the > underlying "out" stream, it's > reasonable to consider that the "internal status" of its encoder also > needs to be flushed. > Especially this has been the behavior for releases earlier than 1.4.2. > > As I said, while I have been hesitated to "fix" this problem for a > while (one it has been here > for 3 major releases, two, the API does not explicitly say so) but as > long as we don't have a > reasonable "close-ME-only" mechanism for those layered streams, it > appears to be a > reasonable approach to solve the problem, without having obvious > negative impact. > > -Sherman > > PS: There is another implementation "detail" that the original > iso-2022-jp c2b converter > actually restores the state back to ASCII mode at the end of its > "convert" method, this makes > the analysis a little complicated, but should not change the issue we > are discussing) > > > On 02/09/2012 12:26 AM, Masayoshi Okutsu wrote: >> First of all, is this really a Java SE bug? The usage of >> OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo >> method in the bug report doesn't seem to be able to deal with any >> stateful encodings. >> >> Masayoshi >> >> On 2/9/2012 3:26 PM, Xueming Shen wrote: >>> Hi >>> >>> This is a long standing "regression" from 1.3.1 on how >>> OutputStreamWriter.flush()/flushBuffer() >>> handles escape or shift sequence in some of the charset/encoding, >>> for example the ISO-2022-JP. >>> >>> ISO-2022-JP is encoding that starts with ASCII mode and then >>> switches between ASCII andJapanese >>> characters through an escape sequence. For example, the escape >>> sequence ESC $ B (0x1B, 0x24 0x42) >>> is used to indicate the following bytes are Japanese (switch from >>> ASCII mode to Japanese mode), and >>> the ESC ( B (0x1b 0x28 0x42) is used to switch back to ASCII. >>> >>> In Java's sun.io.CharToByteConvert (old generation charset >>> converter) and the nio.io.charset.CharsetEncoder >>> usually switches back forth between ASCII and Japanese modes based >>> on the input character sequence >>> (for example, if you are in ASCII mode, and your next input >>> character is a Japanese, you add the >>> ESC $ B into the output first and then followed the converted input >>> character, or if you are in Japanese >>> mode and your next input is ASCII, you output ESC ( B first to >>> switch the mode and then the ASCII) and >>> switch back to ASCII mode (if the last mode is non-Japanese) if >>> either the encoding is ending or the >>> flush() method gets invoked. >>> >>> In JDK1.3.1, OutputStreamWriter.flushBuffer() explicitly invokes >>> sun.io.c2b's flushAny() to switch >>> back to ASCII mode every time the flush() or flushBuffer() (from >>> PrintStream) gets invoked, as >>> showed at the end of this email. For example, as showed below, the >>> code uses OutputStreamWriter >>> to "write" a Japanese character \u6700 to the underlying stream with >>> iso-2022jp, >>> >>> ByteArrayOutputStream bos = new ByteArrayOutputStream(); >>> String str = "\u6700"; >>> OutputStreamWriter osw = new OutputStreamWriter(bos, >>> "iso-2022-jp"); >>> osw.write(str, 0, str.length()); >>> >>> Since the iso-2022-jp starts with ASCII mode, we now have a >>> Japanese, so we need to >>> switch into Japanese mode first (the first 3 bytes) and then the >>> encoded Japanese >>> character (the following 2 bytes) >>> >>> 0x1b 0x24 0x42 0x3a 0x47 >>> >>> and then the code invokes >>> >>> osw.flush(); >>> >>> since we are now in Japanese, the writer continues to write out >>> >>> 0x1b 0x28 0x 42 >>> >>> to switch back to ASCII mode. The total output is 8 bytes after >>> write() and flush(). >>> >>> However, when all encoidng/charset related codes were migrated from >>> 1.3.1's sun.io based to >>> 1.4's java.nio.charset based implementation (1.4, 1.4.1 and 1.4.2, >>> we gradually migrated from >>> sun.io to java.nio.charset), the "c2b.flushAny()" invocation >>> obviously was dropped in >>> sun.nio.cs.StreamEncoder. It results in that the "switch back to >>> ASCII mode" sequence is no longer >>> output when OutputStreamWriter.flush() or PrintStream.write(String) >>> is invoked. >>> >>> This does not trigger problem for most use scenario, if the "stream" >>> finally gets closed >>> (in which the StreamEncoder does invoke encoder's flush() to output >>> the escape sequence >>> to switch back to ASCII) or PrintStream.println(String) is used (in >>> which it outputs a \n character, >>> since this \n is in ASCII range, it "accidentally " switches the >>> mode back to ASCII). >>> >>> But it obviously causes problem when you can't not close the >>> OutputStreamWriter after >>> you're done your iso2022-jp writing (for example, you need continue >>> to use the underlying >>> OutputStream for other writing, but not "this" osw), for 1.3.1, >>> these apps invoke osw.flush() >>> to force the output switch back to ASCII, this no longer works when >>> we switch to java.nio.charset >>> in jdk1.4.2. (we migrated iso-2022-jp to nio.charset in 1.4.2). This >>> is what happened in JavaMail, >>> as described in the bug report. >>> >>> The solution is to re-store the "flush the encoder" mechanism in >>> StreamEncoder's flushBuffer(). >>> >>> I have been hesitated to make this change for a while, mostly >>> because this regressed behavior >>> has been their for 3 releases, and the change triggers yet another >>> "behavior change". But given >>> there is no obvious workaround and it only changes the behavior of >>> the charsets with this >>> shift in/out mechanism, mainly the iso-2022 family and those IBM >>> EBCDIC_DBCS charsets, I >>> decided to give it a try. >>> >>> Here is the webreview >>> >>> http://cr.openjdk.java.net/~sherman/6995537/webrev >>> >>> Sherman >>> >>> >>> ---------------------------------1.3.1 >>> OutputStreamWriter----------------------- >>> /** >>> * Flush the output buffer to the underlying byte stream, >>> without flushing >>> * the byte stream itself. This method is non-private only so >>> that it may >>> * be invoked by PrintStream. >>> */ >>> void flushBuffer() throws IOException { >>> synchronized (lock) { >>> ensureOpen(); >>> >>> for (;;) { >>> try { >>> nextByte += ctb.flushAny(bb, nextByte, nBytes); >>> } >>> catch (ConversionBufferFullException x) { >>> nextByte = ctb.nextByteIndex(); >>> } >>> if (nextByte == 0) >>> break; >>> if (nextByte > 0) { >>> out.write(bb, 0, nextByte); >>> nextByte = 0; >>> } >>> } >>> } >>> } >>> >>> /** >>> * Flush the stream. >>> * >>> * @exception IOException If an I/O error occurs >>> */ >>> public void flush() throws IOException { >>> synchronized (lock) { >>> flushBuffer(); >>> out.flush(); >>> } >>> } >>> >>> >>> >>> > From xueming.shen at oracle.com Thu Feb 9 19:29:04 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 09 Feb 2012 11:29:04 -0800 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: References: <4F33672E.7020302@oracle.com> Message-ID: <4F341E80.8000307@oracle.com> Jason, I might be misunderstanding your suggestion, but the current implementation of OutputStreamWriter.flushBuffer()/StreamWriter.implFlushBuffer() does not flush the encoder, so even the caller can choose when to invoke flushBuffer(), it does not solve the problem (flush() invokes flushBuffer() before it flushes the "out" stream). The proposed the change is to put back the encoder.flush() into osw.flushBuffer (in StreamWriter.implFlushBuffer()). -Sherman On 02/09/2012 10:24 AM, Jason Mehrens wrote: > Sherman, > > As a workaround, what about allowing a write of empty string or empty > char array to call flushBuffer? If you call PrintStream.print("") > then flushBuffer is called on the internal writers. But if you try > the same by doing OuputStreamWriter.write("") the flushbuffer call is > trapped by a zero len if condition in StreamEncoder.write(char[], int, > int). That seems inconsistent. If that check was removed then the > workaround would be: > > =================== > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > String str = "\u6700"; > OutputStreamWriter osw = new OutputStreamWriter(bos, "iso-2022-jp"); > osw.write(str, 0, str.length()); > osw.write(""); //Flush buffer. > osw.flush(); //Flush stream. > ================== > > It's not pretty but, it would allow the caller to choose when > flushBuffer is called. > > Jason > > > Date: Wed, 8 Feb 2012 22:26:54 -0800 > > From: xueming.shen at oracle.com > > To: core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net > > Subject: Codereview request for 6995537: different behavior in > iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 > > > > The solution is to re-store the "flush the encoder" mechanism in > > StreamEncoder's flushBuffer(). > > > > I have been hesitated to make this change for a while, mostly because > > this regressed behavior > > has been their for 3 releases, and the change triggers yet another > > "behavior change". But given > > there is no obvious workaround and it only changes the behavior of the > > charsets with this > > shift in/out mechanism, mainly the iso-2022 family and those IBM > > EBCDIC_DBCS charsets, I > > decided to give it a try. > > > > Here is the webreview > > > > http://cr.openjdk.java.net/~sherman/6995537/webrev > > > > Sherman > > From jason_mehrens at hotmail.com Thu Feb 9 20:07:36 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 9 Feb 2012 14:07:36 -0600 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F341E80.8000307@oracle.com> References: <4F33672E.7020302@oracle.com> , <4F341E80.8000307@oracle.com> Message-ID: Sherman, My mistake, I missed the fact that flushBuffer does not flush the encoder. I incorrectly thought that write/print caused the encoder to flush and only the direct call to OSW.flush did not. Jason Date: Thu, 9 Feb 2012 11:29:04 -0800 From: xueming.shen at oracle.com To: jason_mehrens at hotmail.com CC: core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net Subject: Re: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 Jason, I might be misunderstanding your suggestion, but the current implementation of OutputStreamWriter.flushBuffer()/StreamWriter.implFlushBuffer() does not flush the encoder, so even the caller can choose when to invoke flushBuffer(), it does not solve the problem (flush() invokes flushBuffer() before it flushes the "out" stream). The proposed the change is to put back the encoder.flush() into osw.flushBuffer (in StreamWriter.implFlushBuffer()). -Sherman On 02/09/2012 10:24 AM, Jason Mehrens wrote: Sherman, As a workaround, what about allowing a write of empty string or empty char array to call flushBuffer? If you call PrintStream.print("") then flushBuffer is called on the internal writers. But if you try the same by doing OuputStreamWriter.write("") the flushbuffer call is trapped by a zero len if condition in StreamEncoder.write(char[], int, int). That seems inconsistent. If that check was removed then the workaround would be: =================== ByteArrayOutputStream bos = new ByteArrayOutputStream(); String str = "\u6700"; OutputStreamWriter osw = new OutputStreamWriter(bos, "iso-2022-jp"); osw.write(str, 0, str.length()); osw.write(""); //Flush buffer. osw.flush(); //Flush stream. ================== It's not pretty but, it would allow the caller to choose when flushBuffer is called. Jason > Date: Wed, 8 Feb 2012 22:26:54 -0800 > From: xueming.shen at oracle.com > To: core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net > Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 > > The solution is to re-store the "flush the encoder" mechanism in > StreamEncoder's flushBuffer(). > > I have been hesitated to make this change for a while, mostly because > this regressed behavior > has been their for 3 releases, and the change triggers yet another > "behavior change". But given > there is no obvious workaround and it only changes the behavior of the > charsets with this > shift in/out mechanism, mainly the iso-2022 family and those IBM > EBCDIC_DBCS charsets, I > decided to give it a try. > > Here is the webreview > > http://cr.openjdk.java.net/~sherman/6995537/webrev > > Sherman > From stuart.marks at oracle.com Fri Feb 10 03:11:08 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 09 Feb 2012 19:11:08 -0800 Subject: Warning Fixes from LJC Hack Session In-Reply-To: <4F2CE850.9090604@oracle.com> References: <4F2A6213.4040707@oracle.com> <4F2CE850.9090604@oracle.com> Message-ID: <4F348ACC.7020707@oracle.com> Hi Mike, I finally got back to this. These fixes look pretty good and knock off 100+ additional warnings! I've filed bug 7143230 [1] to track this. I took a look through the code and I took the liberty of fixing up a few very minor things: 1. Removed unnecessary casts to ZipEntry in JarVerifier.java, suggested by Chirs Hegarty [2]. (These aren't strictly redundant casts, and don't cause warnings, as the origin types are and JarEntry. However, they are unnecessary.) 2. Fixed typo in unrelated comment at line 50 in SignatureFile.java that I happened to notice. 3. Removed parentheses from expressions in MemoryMonitor.java lines 216, 219 which are now unnecessary since the cast has been removed. No need to issue another patch; I'll just include these changes when I push the changeset. Which brings me to the topic that we discussed before when I pushed LJC's previous round of warnings fixes, that is, how the Contributed-by line in the commit message should be formatted. (See [3] for the requirements.) For reference, here's what the changeset comment for the previous set of LJC fixes ended up looking like: changeset: 4802:4f0f9f9c4892 user: smarks date: Wed Dec 07 12:12:50 2011 -0800 description: 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip Reviewed-by: alanb, dholmes, forax, sherman, smarks Contributed-by: Prasannaa , Martijn Verburg , Goerge_Albrecht , Graham Allan , Michael Barker It looks like a different set of people contributed to this round of fixes. If you could send me the list of names and email addresses, I can format them into the commit message and push the fix. Thanks! s'marks [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143230 [2] http://mail.openjdk.java.net/pipermail/jdk8-dev/2012-February/000715.html [3] http://openjdk.java.net/guide/producingChangeset.html On 2/4/12 12:12 AM, Chris Hegarty wrote: > Thanks for this, looks great. > > Good to see JarVerifier getting some much needed TLC. > > -Chris. > > > On 02/ 4/12 07:50 AM, Michael Barker wrote: >>> I see R?mi has suggested a slice& dice but I think that's a bit too much >>> work for the changes involved. Instead I would suggest a simple split, send >>> the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything else to >>> core-libs-dev. >> >> Attached is the patch that contains "everthing else" from LJC warning >> fixes hack session. >> >> Mike. From weijun.wang at oracle.com Fri Feb 10 03:40:19 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 Feb 2012 11:40:19 +0800 Subject: Warning Fixes from LJC Hack Session In-Reply-To: <4F348ACC.7020707@oracle.com> References: <4F2A6213.4040707@oracle.com> <4F2CE850.9090604@oracle.com> <4F348ACC.7020707@oracle.com> Message-ID: <4F3491A3.3030709@oracle.com> Just give me anything that includes the jars not found yet. I just want to extract the hash line and cert info from them to make sure they can be removed from trusted.libraries safely. Thanks Max On 02/10/2012 11:11 AM, Stuart Marks wrote: > Hi Mike, > > I finally got back to this. These fixes look pretty good and knock off > 100+ additional warnings! I've filed bug 7143230 [1] to track this. I > took a look through the code and I took the liberty of fixing up a few > very minor things: > > 1. Removed unnecessary casts to ZipEntry in JarVerifier.java, suggested > by Chirs Hegarty [2]. (These aren't strictly redundant casts, and don't > cause warnings, as the origin types are and > JarEntry. However, they are unnecessary.) > > 2. Fixed typo in unrelated comment at line 50 in SignatureFile.java that > I happened to notice. > > 3. Removed parentheses from expressions in MemoryMonitor.java lines 216, > 219 which are now unnecessary since the cast has been removed. > > No need to issue another patch; I'll just include these changes when I > push the changeset. > > Which brings me to the topic that we discussed before when I pushed > LJC's previous round of warnings fixes, that is, how the Contributed-by > line in the commit message should be formatted. (See [3] for the > requirements.) For reference, here's what the changeset comment for the > previous set of LJC fixes ended up looking like: > > > changeset: 4802:4f0f9f9c4892 > user: smarks > date: Wed Dec 07 12:12:50 2011 -0800 > description: > 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip > Reviewed-by: alanb, dholmes, forax, sherman, smarks > Contributed-by: Prasannaa , Martijn Verburg > , Goerge_Albrecht , > Graham Allan , Michael Barker > > > > It looks like a different set of people contributed to this round of > fixes. If you could send me the list of names and email addresses, I can > format them into the commit message and push the fix. > > Thanks! > > s'marks > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143230 > > [2] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2012-February/000715.html > > [3] http://openjdk.java.net/guide/producingChangeset.html > > On 2/4/12 12:12 AM, Chris Hegarty wrote: >> Thanks for this, looks great. >> >> Good to see JarVerifier getting some much needed TLC. >> >> -Chris. >> >> >> On 02/ 4/12 07:50 AM, Michael Barker wrote: >>>> I see R?mi has suggested a slice& dice but I think that's a bit too >>>> much >>>> work for the changes involved. Instead I would suggest a simple >>>> split, send >>>> the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything >>>> else to >>>> core-libs-dev. >>> >>> Attached is the patch that contains "everthing else" from LJC warning >>> fixes hack session. >>> >>> Mike. From weijun.wang at oracle.com Fri Feb 10 03:42:30 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 10 Feb 2012 03:42:30 +0000 Subject: hg: jdk8/tl/jdk: 6879539: enable empty password support for pkcs12 keystore Message-ID: <20120210034249.51BB64742A@hg.openjdk.java.net> Changeset: bdd1dd1e1462 Author: weijun Date: 2012-02-10 11:41 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdd1dd1e1462 6879539: enable empty password support for pkcs12 keystore Reviewed-by: vinnie, weijun Contributed-by: Florian Weimer ! src/share/classes/com/sun/crypto/provider/PBEKey.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/Bug6415637.java From masayoshi.okutsu at oracle.com Fri Feb 10 08:31:18 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 10 Feb 2012 17:31:18 +0900 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F341A86.8090004@oracle.com> References: <4F33672E.7020302@oracle.com> <4F33832D.3090807@oracle.com> <4F341A2F.7060700@oracle.com> <4F341A86.8090004@oracle.com> Message-ID: <4F34D5D6.1000103@oracle.com> I tend to agree with Sherman that the real problem is the OutputStreamWriter API which isn't good enough to handle various encodings. My understanding is that the charset API was introduced in 1.4 to deal with the limitations of the java.io and other encoding handling issues. I still don't think it's correct to change the flush semantics. The flush method should just flush out any outstanding data to the given output stream as defined in java.io.Writer. What if Writer.write(int) is used write UTF-16 data with any stateful encoding? Suppose the stateful encoding can support supplementary characters which require other G0 designations, does the following calling sequence work? writer.write(highSurrogate); writer.flush(); writer.write(lowSurrogate); writer.flush(); Of course, this isn't a problem with iso-2022-jp, though. I think it's a correct fix, not a workaround, to create a filter stream to deal with stateful encodings with the java.io API. If it's OK to support only 1.4 and later, the java.nio.charset API should be used. Thanks, Masayoshi On 2/10/2012 4:12 AM, Xueming Shen wrote: > CCed Bill Shannon. > > On 02/09/2012 11:10 AM, Xueming Shen wrote: >> >> CharsetEncoder has the "flush()" method as the last step (of a series >> of "encoding" steps) to >> flush out any internal state to the output buffer. The issue here is >> the the upper level wrapper >> class, OutputStreamWriter in our case, doesn't provide a "explicit" >> mechanism to let the >> user to request a "flush" on the underlying encoder. The only >> "guaranteed' mechanism is the >> "close()" method, in which it appears it not appropriate to invoke in >> some use scenario, such >> as the JavaMail.writeTo() case. >> >> It appears we are lacking of a "close this stream, but not the >> underlying stream" mechanism >> in our layered/chained streams, I have similar request for this kind >> of mechanism in other area, >> such as in zip/gzip stream, app wraps a "outputstream" with zip/gzip, >> they want to release the >> zip/gzip layer after use (to release the native resource, for >> example) but want to keep the >> underlying stream unclosed. The only workaround now is to wrap the >> underlying stream with >> a subclass to override the "close()" method, which is really not >> desirable. >> >> The OutputStreamWriter.flush() does not explicitly specify in its API >> doc if it should actually >> flush the underlying charset encoder (so I would not argue strongly >> that this IS a SE bug) but >> given it is flushing it's buffer (internal status) and then the >> underlying "out" stream, it's >> reasonable to consider that the "internal status" of its encoder also >> needs to be flushed. >> Especially this has been the behavior for releases earlier than 1.4.2. >> >> As I said, while I have been hesitated to "fix" this problem for a >> while (one it has been here >> for 3 major releases, two, the API does not explicitly say so) but >> as long as we don't have a >> reasonable "close-ME-only" mechanism for those layered streams, it >> appears to be a >> reasonable approach to solve the problem, without having obvious >> negative impact. >> >> -Sherman >> >> PS: There is another implementation "detail" that the original >> iso-2022-jp c2b converter >> actually restores the state back to ASCII mode at the end of its >> "convert" method, this makes >> the analysis a little complicated, but should not change the issue we >> are discussing) >> >> >> On 02/09/2012 12:26 AM, Masayoshi Okutsu wrote: >>> First of all, is this really a Java SE bug? The usage of >>> OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo >>> method in the bug report doesn't seem to be able to deal with any >>> stateful encodings. >>> >>> Masayoshi >>> >>> On 2/9/2012 3:26 PM, Xueming Shen wrote: >>>> Hi >>>> >>>> This is a long standing "regression" from 1.3.1 on how >>>> OutputStreamWriter.flush()/flushBuffer() >>>> handles escape or shift sequence in some of the charset/encoding, >>>> for example the ISO-2022-JP. >>>> >>>> ISO-2022-JP is encoding that starts with ASCII mode and then >>>> switches between ASCII andJapanese >>>> characters through an escape sequence. For example, the escape >>>> sequence ESC $ B (0x1B, 0x24 0x42) >>>> is used to indicate the following bytes are Japanese (switch from >>>> ASCII mode to Japanese mode), and >>>> the ESC ( B (0x1b 0x28 0x42) is used to switch back to ASCII. >>>> >>>> In Java's sun.io.CharToByteConvert (old generation charset >>>> converter) and the nio.io.charset.CharsetEncoder >>>> usually switches back forth between ASCII and Japanese modes based >>>> on the input character sequence >>>> (for example, if you are in ASCII mode, and your next input >>>> character is a Japanese, you add the >>>> ESC $ B into the output first and then followed the converted input >>>> character, or if you are in Japanese >>>> mode and your next input is ASCII, you output ESC ( B first to >>>> switch the mode and then the ASCII) and >>>> switch back to ASCII mode (if the last mode is non-Japanese) if >>>> either the encoding is ending or the >>>> flush() method gets invoked. >>>> >>>> In JDK1.3.1, OutputStreamWriter.flushBuffer() explicitly invokes >>>> sun.io.c2b's flushAny() to switch >>>> back to ASCII mode every time the flush() or flushBuffer() (from >>>> PrintStream) gets invoked, as >>>> showed at the end of this email. For example, as showed below, the >>>> code uses OutputStreamWriter >>>> to "write" a Japanese character \u6700 to the underlying stream >>>> with iso-2022jp, >>>> >>>> ByteArrayOutputStream bos = new ByteArrayOutputStream(); >>>> String str = "\u6700"; >>>> OutputStreamWriter osw = new OutputStreamWriter(bos, >>>> "iso-2022-jp"); >>>> osw.write(str, 0, str.length()); >>>> >>>> Since the iso-2022-jp starts with ASCII mode, we now have a >>>> Japanese, so we need to >>>> switch into Japanese mode first (the first 3 bytes) and then the >>>> encoded Japanese >>>> character (the following 2 bytes) >>>> >>>> 0x1b 0x24 0x42 0x3a 0x47 >>>> >>>> and then the code invokes >>>> >>>> osw.flush(); >>>> >>>> since we are now in Japanese, the writer continues to write out >>>> >>>> 0x1b 0x28 0x 42 >>>> >>>> to switch back to ASCII mode. The total output is 8 bytes after >>>> write() and flush(). >>>> >>>> However, when all encoidng/charset related codes were migrated from >>>> 1.3.1's sun.io based to >>>> 1.4's java.nio.charset based implementation (1.4, 1.4.1 and 1.4.2, >>>> we gradually migrated from >>>> sun.io to java.nio.charset), the "c2b.flushAny()" invocation >>>> obviously was dropped in >>>> sun.nio.cs.StreamEncoder. It results in that the "switch back to >>>> ASCII mode" sequence is no longer >>>> output when OutputStreamWriter.flush() or PrintStream.write(String) >>>> is invoked. >>>> >>>> This does not trigger problem for most use scenario, if the >>>> "stream" finally gets closed >>>> (in which the StreamEncoder does invoke encoder's flush() to output >>>> the escape sequence >>>> to switch back to ASCII) or PrintStream.println(String) is used (in >>>> which it outputs a \n character, >>>> since this \n is in ASCII range, it "accidentally " switches the >>>> mode back to ASCII). >>>> >>>> But it obviously causes problem when you can't not close the >>>> OutputStreamWriter after >>>> you're done your iso2022-jp writing (for example, you need continue >>>> to use the underlying >>>> OutputStream for other writing, but not "this" osw), for 1.3.1, >>>> these apps invoke osw.flush() >>>> to force the output switch back to ASCII, this no longer works when >>>> we switch to java.nio.charset >>>> in jdk1.4.2. (we migrated iso-2022-jp to nio.charset in 1.4.2). >>>> This is what happened in JavaMail, >>>> as described in the bug report. >>>> >>>> The solution is to re-store the "flush the encoder" mechanism in >>>> StreamEncoder's flushBuffer(). >>>> >>>> I have been hesitated to make this change for a while, mostly >>>> because this regressed behavior >>>> has been their for 3 releases, and the change triggers yet another >>>> "behavior change". But given >>>> there is no obvious workaround and it only changes the behavior of >>>> the charsets with this >>>> shift in/out mechanism, mainly the iso-2022 family and those IBM >>>> EBCDIC_DBCS charsets, I >>>> decided to give it a try. >>>> >>>> Here is the webreview >>>> >>>> http://cr.openjdk.java.net/~sherman/6995537/webrev >>>> >>>> Sherman >>>> >>>> >>>> ---------------------------------1.3.1 >>>> OutputStreamWriter----------------------- >>>> /** >>>> * Flush the output buffer to the underlying byte stream, >>>> without flushing >>>> * the byte stream itself. This method is non-private only so >>>> that it may >>>> * be invoked by PrintStream. >>>> */ >>>> void flushBuffer() throws IOException { >>>> synchronized (lock) { >>>> ensureOpen(); >>>> >>>> for (;;) { >>>> try { >>>> nextByte += ctb.flushAny(bb, nextByte, nBytes); >>>> } >>>> catch (ConversionBufferFullException x) { >>>> nextByte = ctb.nextByteIndex(); >>>> } >>>> if (nextByte == 0) >>>> break; >>>> if (nextByte > 0) { >>>> out.write(bb, 0, nextByte); >>>> nextByte = 0; >>>> } >>>> } >>>> } >>>> } >>>> >>>> /** >>>> * Flush the stream. >>>> * >>>> * @exception IOException If an I/O error occurs >>>> */ >>>> public void flush() throws IOException { >>>> synchronized (lock) { >>>> flushBuffer(); >>>> out.flush(); >>>> } >>>> } >>>> >>>> >>>> >>>> >> > From Ulf.Zibis at gmx.de Fri Feb 10 13:00:22 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 10 Feb 2012 14:00:22 +0100 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F341A2F.7060700@oracle.com> References: <4F33672E.7020302@oracle.com> <4F33832D.3090807@oracle.com> <4F341A2F.7060700@oracle.com> Message-ID: <4F3514E6.6070508@gmx.de> I agree with the fix. In test/java/io/OutputStreamWriter/Flush.java I suggest: a) As all values are positive, following would be better readable: byte[] bytes = new byte[] {0x1b, 0x24, 0x42, 0x3a, 0x47, 0x1b, 0x28, 0x42}; ... or remember the format rule - which I still don't like - to insert a space after the cast. ;-) b) Use the promoted /ugly/ Byte.toUnsignedInt(b) method. c) Use smart for...each loop d) I guess, you meant one ':' after "Result" e) Print "Expected/Result: 0x12 0x34 0x56 ..." in _one_ line, with the values vertically alingned. f) Anyway, for the output you could use: private static Formatter formatBytes(CharSequence label, byte[] bytes) { Formatter f = new Formatter(new StringBuilder(label)); // Formatter f = new Formatter(new StringBuilder(label.length() + 5 * bytes.length).append(label)); for (byte b : bytes) f.format(" 0x%x", b Byte.toUnsignedInt(b)); return f; } ... System.out.println(formatBytes("Expected:", expected)); System.out.println(formatBytes("Result: ", result)); -Ulf From alexlamsl at gmail.com Fri Feb 10 13:09:10 2012 From: alexlamsl at gmail.com (Alex Lam S.L.) Date: Fri, 10 Feb 2012 13:09:10 +0000 Subject: FilterOutputStream.close() throws exception from flush() Message-ID: Hi there, I have some code which calls FilterOutputStream.close(), which calls the underlying OutputStream.flush() which throws IOException. With previous versions of JavaSE, close() returns successfully without any problems. Using JDK8-b24, I get an IOException which is propagated from flush(). Is there any reason for this change in behaviour? Regards, Alex. From alexlamsl at gmail.com Fri Feb 10 13:16:27 2012 From: alexlamsl at gmail.com (Alex Lam S.L.) Date: Fri, 10 Feb 2012 13:16:27 +0000 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: References: Message-ID: I think I have narrowed it down to this changeset: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/759aa847dcaf 7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails Which no longer catches and ignores the exception thrown by flush(): try (OutputStream ostream = out) { flush(); } To recover the previous behaviour, I think the following might just work: try (OutputStream ostream = out) { flush(); } catch (IOException ignored) { } Regards, Alex. On Fri, Feb 10, 2012 at 1:09 PM, Alex Lam S.L. wrote: > Hi there, > > I have some code which calls FilterOutputStream.close(), which calls > the underlying OutputStream.flush() which throws IOException. > > With previous versions of JavaSE, close() returns successfully without > any problems. > > Using JDK8-b24, I get an IOException which is propagated from flush(). > > Is there any reason for this change in behaviour? > > > Regards, > Alex. From Alan.Bateman at oracle.com Fri Feb 10 13:46:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2012 13:46:48 +0000 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: References: Message-ID: <4F351FC8.2050703@oracle.com> On 10/02/2012 13:09, Alex Lam S.L. wrote: > Hi there, > > I have some code which calls FilterOutputStream.close(), which calls > the underlying OutputStream.flush() which throws IOException. > > With previous versions of JavaSE, close() returns successfully without > any problems. > > Using JDK8-b24, I get an IOException which is propagated from flush(). > > Is there any reason for this change in behaviour? > > > Regards, > Alex. This was deliberate change as FilterOutputStream.close was silently ignoring the exception from the flush (a serious bug in my view). In the original discussion [1] I noted that we may have to consider a compatible switch in the event that it causes problems for applications that don't expect close to fail. You may be the first. -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007326.html From chris.hegarty at oracle.com Fri Feb 10 13:46:46 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Feb 2012 13:46:46 +0000 Subject: Warning Fixes from LJC Hack Session In-Reply-To: References: <4F2A6213.4040707@oracle.com> <4F2CE850.9090604@oracle.com> <4F348ACC.7020707@oracle.com> Message-ID: <4F351FC6.4040307@oracle.com> On 02/10/12 03:58 AM, Michael Barker wrote: > Hi Stuart, > > Thank you for the reviewing the patches. I forgot about the > Contributed-by header, sorry about that. That's one I'll put on the > list to make sure I have sorted next time. I've split the > contributors up according to the two patches supplied. See below: > > AWT, beans& printing: To close the loop on this, I pushed the AWT/bean/print changes to the jdk8/awt/tl repo. http://mail.openjdk.java.net/pipermail/awt-dev/2012-February/002252.html It looks like Stuart will take care of the ones going through jdk8/tl/jdk. -Chris. > > Contributed-by: Prasannaa, Martijn Verburg > , Goerge Albrecht, > Graham Allan, Iordanis Giannakakis > , Jose Llarena, > Abraham Mar?n P?rez > > For all of the remaining code: > > Contributed-by: Mani Sarkar, Michael Barker > , Carl Jokl, Dinuk > Weerasinghe, Markus Stoy > , Tom Anderson > > I hope these patches are providing value for the OpenJDK team as we > plan to do more. I know that there is a bit of a cost for you guys > in terms of reviewing and merging. I'm starting to get a better > picture of the type of changes that will go in smoothly and those that > will require updates to the patches. > > Mike. > > On Fri, Feb 10, 2012 at 3:11 AM, Stuart Marks wrote: >> Hi Mike, >> >> I finally got back to this. These fixes look pretty good and knock off 100+ >> additional warnings! I've filed bug 7143230 [1] to track this. I took a look >> through the code and I took the liberty of fixing up a few very minor >> things: >> >> 1. Removed unnecessary casts to ZipEntry in JarVerifier.java, suggested by >> Chirs Hegarty [2]. (These aren't strictly redundant casts, and don't cause >> warnings, as the origin types are and JarEntry. >> However, they are unnecessary.) >> >> 2. Fixed typo in unrelated comment at line 50 in SignatureFile.java that I >> happened to notice. >> >> 3. Removed parentheses from expressions in MemoryMonitor.java lines 216, 219 >> which are now unnecessary since the cast has been removed. >> >> No need to issue another patch; I'll just include these changes when I push >> the changeset. >> >> Which brings me to the topic that we discussed before when I pushed LJC's >> previous round of warnings fixes, that is, how the Contributed-by line in >> the commit message should be formatted. (See [3] for the requirements.) For >> reference, here's what the changeset comment for the previous set of LJC >> fixes ended up looking like: >> >> >> changeset: 4802:4f0f9f9c4892 >> user: smarks >> date: Wed Dec 07 12:12:50 2011 -0800 >> description: >> 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip >> Reviewed-by: alanb, dholmes, forax, sherman, smarks >> Contributed-by: Prasannaa, Martijn Verburg >> , Goerge_Albrecht, >> Graham Allan, Michael Barker >> >> >> >> It looks like a different set of people contributed to this round of fixes. >> If you could send me the list of names and email addresses, I can format >> them into the commit message and push the fix. >> >> Thanks! >> >> s'marks >> >> >> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143230 >> >> [2] >> http://mail.openjdk.java.net/pipermail/jdk8-dev/2012-February/000715.html >> >> [3] http://openjdk.java.net/guide/producingChangeset.html >> >> >> On 2/4/12 12:12 AM, Chris Hegarty wrote: >>> >>> Thanks for this, looks great. >>> >>> Good to see JarVerifier getting some much needed TLC. >>> >>> -Chris. >>> >>> >>> On 02/ 4/12 07:50 AM, Michael Barker wrote: >>>>> >>>>> I see R?mi has suggested a slice& dice but I think that's a bit too much >>>>> work for the changes involved. Instead I would suggest a simple split, >>>>> send >>>>> the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything else >>>>> to >>>>> core-libs-dev. >>>> >>>> >>>> Attached is the patch that contains "everthing else" from LJC warning >>>> fixes hack session. >>>> >>>> Mike. From alexlamsl at gmail.com Fri Feb 10 13:52:36 2012 From: alexlamsl at gmail.com (Alex Lam S.L.) Date: Fri, 10 Feb 2012 13:52:36 +0000 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: <4F351FC8.2050703@oracle.com> References: <4F351FC8.2050703@oracle.com> Message-ID: Hi there, Thanks for the pointer - I wasn't able to trace back to that email for some reasons. The problem is that: - flush() is reporting IOException because underlying stream is closed - close() is then forwarding that IOException now in JavaSE 8 I guess my question is: what is the best way to check and avoid the case where OutputStream is already closed? Regards, Alex. On Fri, Feb 10, 2012 at 1:46 PM, Alan Bateman wrote: > On 10/02/2012 13:09, Alex Lam S.L. wrote: >> >> Hi there, >> >> I have some code which calls FilterOutputStream.close(), which calls >> the underlying OutputStream.flush() which throws IOException. >> >> With previous versions of JavaSE, close() returns successfully without >> any problems. >> >> Using JDK8-b24, I get an IOException which is propagated from flush(). >> >> Is there any reason for this change in behaviour? >> >> >> Regards, >> Alex. > > This was deliberate change as FilterOutputStream.close was silently ignoring > the exception from the flush (a serious bug in my view). In the original > discussion [1] I noted that we may have to consider a compatible switch in > the event that it causes problems for applications that don't expect close > to fail. You may be the first. > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007326.html From forax at univ-mlv.fr Fri Feb 10 14:13:07 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 10 Feb 2012 15:13:07 +0100 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: References: <4F351FC8.2050703@oracle.com> Message-ID: <4F3525F3.6080701@univ-mlv.fr> On 02/10/2012 02:52 PM, Alex Lam S.L. wrote: > Hi there, > > Thanks for the pointer - I wasn't able to trace back to that email for > some reasons. > > The problem is that: > > - flush() is reporting IOException because underlying stream is closed > - close() is then forwarding that IOException now in JavaSE 8 > > I guess my question is: what is the best way to check and avoid the > case where OutputStream is already closed? > > > Regards, > Alex. In my opinion, flush() should not throw an exception when the stream is closed. close() doesn't throw an exception in that case and close() should be able to call flush(). R?mi From Alan.Bateman at oracle.com Fri Feb 10 14:15:21 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2012 14:15:21 +0000 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: References: <4F351FC8.2050703@oracle.com> Message-ID: <4F352679.1050400@oracle.com> On 10/02/2012 13:52, Alex Lam S.L. wrote: > Hi there, > > Thanks for the pointer - I wasn't able to trace back to that email for > some reasons. > > The problem is that: > > - flush() is reporting IOException because underlying stream is closed > - close() is then forwarding that IOException now in JavaSE 8 > > I guess my question is: what is the best way to check and avoid the > case where OutputStream is already closed? > Do you know what the type of the underlying stream is? Clearly flush should fail if there are bytes to flush and the stream is open. Whether calling flush on a closed stream should fail or not isn't clear from the javadoc. -Alan From alexlamsl at gmail.com Fri Feb 10 14:34:12 2012 From: alexlamsl at gmail.com (Alex Lam S.L.) Date: Fri, 10 Feb 2012 14:34:12 +0000 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: <4F352679.1050400@oracle.com> References: <4F351FC8.2050703@oracle.com> <4F352679.1050400@oracle.com> Message-ID: It is a custom OutputStream class which is not part of the JDK. In this case close() is being called multiple times, because there are actions which relies it. And flush() will throw IOException if the stream is already closed. I guess I can work around this by introducing a boolean flag to track if FilterOutp?utStream.close() has been called in the past and avoid calling it again, but it is not the best solution IMHO. Alex. On Fri, Feb 10, 2012 at 2:15 PM, Alan Bateman wrote: > On 10/02/2012 13:52, Alex Lam S.L. wrote: >> >> Hi there, >> >> Thanks for the pointer - I wasn't able to trace back to that email for >> some reasons. >> >> The problem is that: >> >> ?- flush() is reporting IOException because underlying stream is closed >> ?- close() is then forwarding that IOException now in JavaSE 8 >> >> I guess my question is: what is the best way to check and avoid the >> case where OutputStream is already closed? >> > Do you know what the type of the underlying stream is? Clearly flush should > fail if there are bytes to flush and the stream is open. Whether calling > flush on a closed stream should fail or not isn't clear from the javadoc. > > -Alan > From tom.hawtin at oracle.com Fri Feb 10 14:53:09 2012 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Fri, 10 Feb 2012 14:53:09 +0000 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: References: Message-ID: <4F352F55.80706@oracle.com> On 10/02/2012 13:16, Alex Lam S.L. wrote: > To recover the previous behaviour, I think the following might just work: > > try (OutputStream ostream = out) { > flush(); > } catch (IOException ignored) { > } Remember try-with-resource-catch works the inside-out from try-catch-finally! You are discarding the close exception. So better would be: try (OutputStream ostream = out) { try { flush(); } catch (IOException ignored) { } } It'd be kind of nice to add the flush exception to the close exception if there is one. I think that would require abandoning try-with-resource and writing it all out in longhand. Or a half-way house: IOException flushExc = null try (OutputStream ostream = out) { try { flush(); } catch (IOException exc) { flushExc = exc; } } catch (IOException exc) { if (flushExc != null) { exc.addSuppressed(flushExc); } throw exc; } The decorators should never have attempted to proxy the resource release, but it's not 1995. Tom From kumar.x.srinivasan at oracle.COM Fri Feb 10 18:37:30 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 10 Feb 2012 10:37:30 -0800 Subject: Please review: 7131266: JDK 7 pack200 + unpack200 fails on jaxb-xjc.jar Message-ID: <4F3563EA.7040200@oracle.COM> Hello, Please review fix for : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131266 The gist of the problem being addressed, the specimen jar contains two versions of class file implementations with the same package names, this tends to confuse the pack200 mechanism causing it to fire asserts. This fixes two issues: 1. Made the equals method more stringent to ensure the CP tag is compared correctly [ this can happen for MemberEntry which can have Fields, Methods and InterfaceMethods,] and some minor cleanups. 2. A class file not playing nice, ie. package name does not reflect the actual directory structure they are in, will not be considered for compression, instead these will be passed through "as-is". http://cr.openjdk.java.net/~ksrini/7131266/webrev.0/ Thanks Kumar From lana.steuck at oracle.com Fri Feb 10 18:43:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:43:54 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20120210184354.84E8547465@hg.openjdk.java.net> Changeset: 5350cd6e0cc0 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5350cd6e0cc0 Added tag jdk8-b24 for changeset 1a5f1d6b98d6 ! .hgtags Changeset: 221a378e06a3 Author: lana Date: 2012-02-07 10:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/221a378e06a3 Merge Changeset: 2accafff224a Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2accafff224a Added tag jdk8-b25 for changeset 221a378e06a3 ! .hgtags From lana.steuck at oracle.com Fri Feb 10 18:43:58 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:43:58 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20120210184358.74B1847466@hg.openjdk.java.net> Changeset: bb694c151fc7 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bb694c151fc7 Added tag jdk8-b24 for changeset 7836655e2495 ! .hgtags Changeset: dbb7283c197b Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dbb7283c197b Added tag jdk8-b25 for changeset bb694c151fc7 ! .hgtags From lana.steuck at oracle.com Fri Feb 10 18:43:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:43:54 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20120210184359.2EBE547467@hg.openjdk.java.net> Changeset: e45d6b406d5f Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e45d6b406d5f Added tag jdk8-b24 for changeset b98f0e6dddf9 ! .hgtags Changeset: 79f709a099f4 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/79f709a099f4 Added tag jdk8-b25 for changeset e45d6b406d5f ! .hgtags From lana.steuck at oracle.com Fri Feb 10 18:44:02 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:44:02 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20120210184402.CD0A847468@hg.openjdk.java.net> Changeset: b376d901e006 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b376d901e006 Added tag jdk8-b24 for changeset e0d90803439b ! .hgtags Changeset: 3518639eab6c Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3518639eab6c Added tag jdk8-b25 for changeset b376d901e006 ! .hgtags Changeset: 65977d8d348e Author: lana Date: 2012-02-09 22:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/65977d8d348e Merge From lana.steuck at oracle.com Fri Feb 10 18:44:06 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:44:06 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20120210184418.4484B47469@hg.openjdk.java.net> Changeset: 5a784dab75f1 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5a784dab75f1 Added tag jdk8-b24 for changeset 6c9d21ca92c4 ! .hgtags Changeset: 520c30f85bb5 Author: lana Date: 2012-02-07 10:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/520c30f85bb5 Merge Changeset: b556aa8a99c3 Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b556aa8a99c3 Added tag jdk8-b25 for changeset 520c30f85bb5 ! .hgtags Changeset: 2ac31f40741d Author: lana Date: 2012-02-09 22:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2ac31f40741d Merge From lana.steuck at oracle.com Fri Feb 10 18:44:36 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:44:36 +0000 Subject: hg: jdk8/tl/hotspot: 74 new changesets Message-ID: <20120210184717.ADD984746B@hg.openjdk.java.net> Changeset: 5f3fcd591768 Author: amurillo Date: 2012-01-20 17:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f3fcd591768 7131979: new hotspot build - hs23-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 53a127075045 Author: kvn Date: 2012-01-20 09:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/53a127075045 7131302: connode.cpp:205 Error: ShouldNotReachHere() Summary: Add Value() methods to short and byte Load nodes to truncate constants which does not fit. Reviewed-by: jrose ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 9164b8236699 Author: iveresov Date: 2012-01-20 15:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9164b8236699 7131028: Switch statement takes wrong path Summary: Pass correct type to branch in LIRGenerator::do_SwitchRanges() Reviewed-by: kvn, never ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: a81f60ddab06 Author: never Date: 2012-01-22 14:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a81f60ddab06 7130676: Tiered: assert(bci == 0 || 0<= bci && bciis_loaded() Summary: handle not loaded array klass in Parse::do_checkcast(). Reviewed-by: kvn, never ! src/share/vm/opto/parseHelper.cpp Changeset: 5dbed2f542ff Author: bdelsart Date: 2012-01-26 16:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5dbed2f542ff 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle Summary: improvements of TraceMethodHandles for JSR292 Reviewed-by: never, twisti ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 20334ed5ed3c Author: iveresov Date: 2012-01-26 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20334ed5ed3c 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS Summary: Make sure that CompilationPolicy::event() doesn't throw exceptions Reviewed-by: kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 072384a61312 Author: jrose Date: 2012-01-26 19:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/072384a61312 Merge Changeset: 2e966d967c5c Author: johnc Date: 2012-01-13 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e966d967c5c 7121547: G1: High number mispredicted branches while iterating over the marking bitmap Summary: There is a high number of mispredicted branches associated with calling BitMap::iteratate() from within CMBitMapRO::iterate(). Implement a version of CMBitMapRO::iterate() directly using inline-able routines. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/utilities/bitMap.inline.hpp Changeset: 851b58c26def Author: brutisso Date: 2012-01-16 11:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/851b58c26def 7130334: G1: Change comments and error messages that refer to CMS in g1/concurrentMark.cpp/hpp Summary: Removed references to CMS in the concurrentMark.cpp/hpp files. Reviewed-by: tonyp, jmasa, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 9509c20bba28 Author: brutisso Date: 2012-01-16 22:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9509c20bba28 6976060: G1: humongous object allocations should initiate marking cycles when necessary Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 0b3d1ec6eaee Author: tonyp Date: 2012-01-18 10:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b3d1ec6eaee 7097586: G1: improve the per-space output when using jmap -heap Summary: Extend the jmap -heap output for G1 to include some more G1-specific information. Reviewed-by: brutisso, johnc, poonam ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSetBase.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: 7ca7be5a6a0b Author: johnc Date: 2012-01-17 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ca7be5a6a0b 7129271: G1: Interference from multiple threads in PrintGC/PrintGCDetails output Summary: During an initial mark pause, signal the Concurrent Mark thread after the pause output from PrintGC/PrintGCDetails is complete. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: a8a126788ea0 Author: tonyp Date: 2012-01-19 09:13 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a8a126788ea0 7078465: G1: Don't use the undefined value (-1) for the G1 old memory pool max size Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 57025542827f Author: brutisso Date: 2012-01-20 18:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57025542827f 7131791: G1: Asserts in nightly testing due to 6976060 Summary: Create a handle and fake an object to make sure that we don't loose the memory we just allocated Reviewed-by: tonyp, stefank ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 6a78aa6ac1ff Author: brutisso Date: 2012-01-23 20:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a78aa6ac1ff 7132311: G1: assert((s == klass->oop_size(this)) || (Universe::heap()->is_gc_active() && ((is_typeArray()... Summary: Move the check for when to call collect() to before we do a humongous object allocation Reviewed-by: stefank, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 877914d90c57 Author: tonyp Date: 2012-01-24 17:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/877914d90c57 7132398: G1: java.lang.IllegalArgumentException: Invalid threshold: 9223372036854775807 > max (1073741824) Summary: Was not passing the right old pool max to the memory pool constructor in the fix for 7078465. Reviewed-by: brutisso, johnc ! src/share/vm/services/g1MemoryPool.cpp Changeset: d30fa85f9994 Author: johnc Date: 2012-01-12 00:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d30fa85f9994 6484965: G1: piggy-back liveness accounting phase on marking Summary: Remove the separate counting phase of concurrent marking by tracking the amount of marked bytes and the cards spanned by marked objects in marking task/worker thread local data structures, which are updated as individual objects are marked. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: eff609af17d7 Author: tonyp Date: 2012-01-25 12:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eff609af17d7 7127706: G1: re-enable survivors during the initial-mark pause Summary: Re-enable survivors during the initial-mark pause. Afterwards, the concurrent marking threads have to scan them and mark everything reachable from them. The next GC will have to wait for the survivors to be scanned. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: a5244e07b761 Author: jcoomes Date: 2012-01-25 21:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5244e07b761 7112413: JVM Crash, possibly GC-related Summary: disable UseAdaptiveSizePolicy with the CMS and ParNew Reviewed-by: johnc, brutisso ! src/share/vm/runtime/arguments.cpp Changeset: b4ebad3520bb Author: johnc Date: 2012-01-26 14:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4ebad3520bb 7133038: G1: Some small profile based optimizations Summary: Some minor profile based optimizations. Reduce the number of branches and branch mispredicts by removing some virtual calls, through closure specalization, and refactoring some conditional statements. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 0a10d80352d5 Author: brutisso Date: 2012-01-27 09:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a10d80352d5 Merge - src/os/bsd/vm/decoder_bsd.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: af739d5ab23c Author: bpittore Date: 2012-01-21 23:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af739d5ab23c 6972759: Step over not working after thrown exception and Pop Summary: reset jvmtithreadstate exception state after frame pop and forceearlyreturn processed Reviewed-by: minqi, dholmes, dlong Contributed-by: bill.pittore at oracle.com ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: 583b428aa858 Author: coleenp Date: 2012-01-23 17:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/583b428aa858 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: d6660fedbab5 Author: phh Date: 2012-01-24 14:07 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d6660fedbab5 7126732: MAC: Require Mac OS X builds/tests for JPRT integrate jobs for HotSpot Summary: Modify jprt.properties to run OSX builds and tests. Reviewed-by: dcubed, kamg, ohair, dholmes Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: bf864f701a4a Author: dsamersoff Date: 2012-01-25 02:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf864f701a4a 7066129: GarbageCollectorMXBean#getLastGcInfo leaks native memory Summary: Make GCStatInfo a resource object Reviewed-by: phh, coleenp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp Changeset: df88f58f3b61 Author: dsamersoff Date: 2012-01-24 20:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df88f58f3b61 Merge Changeset: e8a4934564b2 Author: phh Date: 2012-01-24 19:33 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8a4934564b2 7125793: MAC: test_gamma should always work Summary: Fix gamma launcher on Mac OS X and reconcile test_gamma script on Unix platforms Reviewed-by: dcubed, ohair, jcoomes, dholmes, ksrini Contributed-by: james.melvin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/posix/launcher/java_md.c Changeset: 78dadb7b16ab Author: phh Date: 2012-01-25 01:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78dadb7b16ab Merge Changeset: d708a8cdd022 Author: kamg Date: 2012-01-25 10:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d708a8cdd022 Merge Changeset: 520830f632e7 Author: fparain Date: 2012-01-25 10:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/520830f632e7 7131346: Parsing of boolean arguments to diagnostic commands is broken Reviewed-by: dholmes, dcubed ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 24ec1a6d6ef3 Author: fparain Date: 2012-01-25 16:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24ec1a6d6ef3 Merge Changeset: a42c07c38c47 Author: dsamersoff Date: 2012-01-25 21:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a42c07c38c47 7132515: Add dcmd to manage UnlockingCommercialFeature flag Summary: Added dcmd to unlock or check status of UnlockingCommercialFeature flag Reviewed-by: fparain, rottenha ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 6d00795f99a1 Author: dsamersoff Date: 2012-01-25 15:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d00795f99a1 Merge Changeset: 6db63e782d3d Author: dsamersoff Date: 2012-01-25 18:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6db63e782d3d Merge Changeset: de268c8a8075 Author: phh Date: 2012-01-26 20:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de268c8a8075 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 Summary: Add CriticalPriority == MaxPriority+1 and enable scheduling class as well as thread priority to change on Solaris. Reviewed-by: dholmes, dcubed ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp Changeset: bf5da1648543 Author: kamg Date: 2012-01-27 10:42 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf5da1648543 Merge ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9e177d44b10f Author: amurillo Date: 2012-01-27 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e177d44b10f Merge Changeset: a80fd4f45d7a Author: amurillo Date: 2012-01-27 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a80fd4f45d7a Added tag hs23-b12 for changeset 9e177d44b10f ! .hgtags Changeset: 905945c5913e Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/905945c5913e Added tag jdk8-b24 for changeset a80fd4f45d7a ! .hgtags Changeset: 9f1c2b7cdfb6 Author: amurillo Date: 2012-01-27 14:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f1c2b7cdfb6 7135385: new hotspot build - hs23-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 34e2e90e7182 Author: rbackman Date: 2012-01-24 14:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34e2e90e7182 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Reviewed-by: kamg, phh, dsamersoff Contributed-by: Rickard Backman ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/trace/traceMacros.hpp Changeset: 26a08cbbf042 Author: stefank Date: 2012-01-27 13:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26a08cbbf042 7022100: Method annotations are incorrectly set when redefining classes Summary: Changed to the correct annotation arrays Reviewed-by: kamg, dholmes, sla ! src/share/vm/oops/instanceKlass.hpp Changeset: f457154eee8b Author: brutisso Date: 2012-01-30 12:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f457154eee8b 7140882: Don't return booleans from methods returning pointers Summary: Changed "return false" to "return NULL" Reviewed-by: dholmes, rottenha Contributed-by: dbhole at redhat.com ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/loopnode.cpp Changeset: d96c130c9399 Author: brutisso Date: 2012-01-30 05:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d96c130c9399 Merge Changeset: b2cd0ee8f778 Author: acorn Date: 2012-01-30 23:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2cd0ee8f778 7114376: Make system dictionary hashtable bucket array size configurable Summary: 7u4 new experimental flag -XX:PredictedClassLoadedCount=# Reviewed-by: dholmes, phh, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 481a9443f721 Author: phh Date: 2012-02-01 15:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/481a9443f721 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X Summary: Add support for packaging HotSpot JVM builds in universal binaries Reviewed-by: dholmes, kamg, dcubed, phh Contributed-by: james.melvin at oracle.com ! make/Makefile ! make/bsd/makefiles/defs.make + make/bsd/makefiles/universal.gmk ! make/defs.make Changeset: 527cf36f4a20 Author: fparain Date: 2012-02-03 14:04 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/527cf36f4a20 Merge ! src/share/vm/runtime/globals.hpp Changeset: 1a2723f7ad8e Author: never Date: 2012-01-29 16:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a2723f7ad8e 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Reviewed-by: kvn, iveresov, dholmes ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5f17b16b3219 Author: iveresov Date: 2012-01-30 19:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f17b16b3219 7141059: 7116795 broke pure c2 builds Summary: Fix pure c2 builds Reviewed-by: kvn, brutisso, never ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ed8f599a788 Author: kvn Date: 2012-01-31 07:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ed8f599a788 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Summary: Use unknown_obj instead of empty_map for NULL or Constant Pool object constants in bytecode Escape Analyzer. Reviewed-by: iveresov, never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 2f5980b127e3 Author: twisti Date: 2012-01-31 09:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f5980b127e3 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f067b4e0e04b Author: roland Date: 2012-02-01 10:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f067b4e0e04b 7090976: Eclipse/CDT causes a JVM crash while indexing C++ code Summary: too optimistic inlining decision confuses local value numbering. Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.cpp + test/compiler/7090976/Test7090976.java Changeset: aa3d708d67c4 Author: never Date: 2012-02-01 07:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa3d708d67c4 7141200: log some interesting information in ring buffers for crashes Reviewed-by: kvn, jrose, kevinw, brutisso, twisti, jmasa ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 0382d2b469b2 Author: never Date: 2012-02-01 16:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0382d2b469b2 7013347: allow crypto functions to be called inline to enhance performance Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/nativeLookup.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 392a3f07d567 Author: twisti Date: 2012-02-02 09:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/392a3f07d567 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 Reviewed-by: twisti Contributed-by: Volker Simonis ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/7141637/SpreadNullArg.java Changeset: 379b22e03c32 Author: jcoomes Date: 2012-02-03 12:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/379b22e03c32 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: be649fefcdc2 Author: stefank Date: 2012-01-27 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be649fefcdc2 7134655: Crash in reference processing when doing single-threaded remarking Summary: Temporarily disabled multi-threaded reference discovery when entering a single-threaded remark phase. Reviewed-by: brutisso, tonyp, jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: c03e06373b47 Author: stefank Date: 2012-01-28 01:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c03e06373b47 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: 2eeebe4b4213 Author: brutisso Date: 2012-01-30 15:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2eeebe4b4213 7140909: Visual Studio project builds broken: need to define INCLUDE_TRACE Summary: Add define of INCLUDE_TRACE Reviewed-by: sla, kamg ! src/share/tools/ProjectCreator/BuildConfig.java Changeset: 24cae3e4cbaa Author: jcoomes Date: 2012-02-02 16:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24cae3e4cbaa 6679764: enable parallel compaction by default Reviewed-by: phh, jmasa ! src/share/vm/runtime/arguments.cpp Changeset: 5ab44ceb4d57 Author: jcoomes Date: 2012-02-03 12:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ab44ceb4d57 Merge Changeset: b22de8247499 Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b22de8247499 Merge Changeset: 4e9b30938cbf Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e9b30938cbf Added tag hs23-b13 for changeset b22de8247499 ! .hgtags Changeset: 1f22b536808b Author: amurillo Date: 2012-02-03 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f22b536808b 7142393: new hotspot build - hs23-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 585feefad374 Author: phh Date: 2012-02-06 14:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/585feefad374 7142852: MAC: Comment out JPRT jbb tests on Mac OS X until 7142850 is resolved Summary: Comment out JPRT jbb tests on Mac OS X until GUI hang can be fixed Reviewed-by: dholmes, brutisso, phh Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: 64b46f975ab8 Author: phh Date: 2012-02-06 14:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/64b46f975ab8 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds Summary: Fix EXPORT_PATH overrides on Mac OS X and only change default. Reviewed-by: phh, dcubed Contributed-by: james.melvin at oracle.com ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/universal.gmk Changeset: 9ad8feb5afbd Author: amurillo Date: 2012-02-06 12:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ad8feb5afbd Added tag hs23-b14 for changeset 64b46f975ab8 ! .hgtags Changeset: aaceb8ddf2e2 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaceb8ddf2e2 Added tag jdk8-b25 for changeset 9ad8feb5afbd ! .hgtags From lana.steuck at oracle.com Fri Feb 10 18:44:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:44:54 +0000 Subject: hg: jdk8/tl/jdk: 26 new changesets Message-ID: <20120210184942.23C1C4746C@hg.openjdk.java.net> Changeset: 8da468cf037b Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8da468cf037b Added tag jdk8-b24 for changeset 34029a0c69bb ! .hgtags Changeset: ad9f1c8970da Author: prr Date: 2012-01-19 12:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad9f1c8970da 7131153: GetDC called way too many times - causes bad performance. Reviewed-by: igor, jgodinez ! src/windows/native/sun/font/fontpath.c Changeset: f7dda4bbf1f9 Author: lana Date: 2012-01-28 22:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7dda4bbf1f9 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 84b153cd9bd4 Author: denis Date: 2012-01-19 14:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84b153cd9bd4 7121761: creation of java.awt.DataFlavour fails for turkish locale Reviewed-by: anthony ! src/share/classes/java/awt/datatransfer/MimeType.java Changeset: e32db6535c05 Author: alexsch Date: 2012-01-23 13:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e32db6535c05 7112854: [macosx] closed/javax/swing/JPopupMenu/Test6827786.java unstable on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/6827786/bug6827786.java Changeset: cc88a9c0474f Author: alexsch Date: 2012-01-23 13:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc88a9c0474f 7116634: [macosx] closed/javax/swing/JTree/6263446/bug6263446Tree.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTree/6263446/bug6263446.java Changeset: 19431d07bc19 Author: denis Date: 2012-01-23 17:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19431d07bc19 7130140: using horizontal scroll button on mouse causes a message to be printed on stdout Reviewed-by: art ! src/share/classes/java/awt/event/MouseEvent.java Changeset: 5255fd5b0418 Author: denis Date: 2012-01-24 18:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5255fd5b0418 7078460: JDialog is shown as separate icon on the taskbar Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: b4589ff4457c Author: malenkov Date: 2012-01-24 19:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4589ff4457c 7121905: grammatically incorrect apostrophe in BeanInfo javadoc Reviewed-by: rupashka ! src/share/classes/java/beans/BeanInfo.java Changeset: 4f2a2bf0ce84 Author: rupashka Date: 2012-01-26 17:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f2a2bf0ce84 7010561: Tab text position with Synth based LaF is different to Java 5/6 Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7010561/bug7010561.java Changeset: cc9ff174a1c3 Author: alexsch Date: 2012-01-27 16:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc9ff174a1c3 7122173: [macosx] Several Regression tests fail on MacOS Reviewed-by: rupashka + test/javax/swing/SwingUtilities/4917669/bug4917669.java + test/javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java + test/javax/swing/text/html/CSS/4530474/bug4530474.java + test/javax/swing/text/html/CSS/4530474/test.css + test/javax/swing/text/html/CSS/4530474/test.html Changeset: 96b5999af66b Author: alexsch Date: 2012-01-27 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96b5999af66b 7109962: [macosx] closed/javax/swing/JList/6462008/bug6462008.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JList/6462008/bug6462008.java Changeset: 6a7109f52966 Author: alexsch Date: 2012-01-27 17:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a7109f52966 7105040: [macosx] closed/javax/swing/JPopupMenu/4966112/bug4966112.java deadlocks on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/4966112/bug4966112.java Changeset: bc1c20ac8676 Author: chegar Date: 2012-01-27 13:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc1c20ac8676 7110002: Rename xawt/libmawt.so and headless/libmawt.so so they can be colocated with libawt Reviewed-by: art, prr, dholmes, alanb ! make/common/Release-embedded.gmk ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/jawt/Makefile ! make/sun/xawt/Makefile ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: 5dab2d55bc5b Author: lana Date: 2012-01-28 22:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5dab2d55bc5b Merge - test/java/io/File/BlockIsDirectory.java Changeset: 39b661c5867a Author: alexsch Date: 2012-01-30 12:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b661c5867a 7122149: [macosx] closed/javax/swing/UITest/UITest.java fails on MacOS Reviewed-by: rupashka ! src/share/classes/sun/awt/OSInfo.java + test/javax/swing/UITest/UITest.java Changeset: 7d6c7dd72e25 Author: malenkov Date: 2012-01-31 14:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d6c7dd72e25 7122138: IAE thrown because Introspector ignores synthetic methods Reviewed-by: rupashka ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/7122138/Test7122138.java + test/java/beans/Introspector/7122138/pack/Sub.java + test/java/beans/Introspector/7122138/pack/Super.java Changeset: c5c78f293ff8 Author: rupashka Date: 2012-01-31 17:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5c78f293ff8 7082443: JComboBox not backward compatible (with Java 6) Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java + test/javax/swing/JComboBox/7082443/bug7082443.java Changeset: 363086137375 Author: lana Date: 2012-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/363086137375 Merge Changeset: 533bc0a10233 Author: lana Date: 2012-01-31 19:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/533bc0a10233 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: ce62fb7aa1b8 Author: lana Date: 2012-02-07 10:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce62fb7aa1b8 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 1a99dad28223 Author: yhuang Date: 2012-02-06 18:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a99dad28223 7129382: change minor unit of VND to 0 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/tablea1.txt Changeset: 930756e55285 Author: yhuang Date: 2012-02-06 18:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/930756e55285 Merge Changeset: ec17fbe5b8fb Author: katleman Date: 2012-02-08 19:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec17fbe5b8fb Merge Changeset: 5aca406e87cb Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aca406e87cb Added tag jdk8-b25 for changeset ec17fbe5b8fb ! .hgtags Changeset: 7fc2797cbb4c Author: lana Date: 2012-02-09 22:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fc2797cbb4c Merge From xueming.shen at oracle.com Fri Feb 10 19:06:28 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 10 Feb 2012 11:06:28 -0800 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F34D5D6.1000103@oracle.com> References: <4F33672E.7020302@oracle.com> <4F33832D.3090807@oracle.com> <4F341A2F.7060700@oracle.com> <4F341A86.8090004@oracle.com> <4F34D5D6.1000103@oracle.com> Message-ID: <4F356AB4.2080105@oracle.com> On 2/10/2012 12:31 AM, Masayoshi Okutsu wrote: > I tend to agree with Sherman that the real problem is the > OutputStreamWriter API which isn't good enough to handle various > encodings. My understanding is that the charset API was introduced in > 1.4 to deal with the limitations of the java.io and other encoding > handling issues. > > I still don't think it's correct to change the flush semantics. The > flush method should just flush out any outstanding data to the given > output stream as defined in java.io.Writer. What if Writer.write(int) > is used write UTF-16 data with any stateful encoding? Suppose the > stateful encoding can support supplementary characters which require > other G0 designations, does the following calling sequence work? > > writer.write(highSurrogate); > writer.flush(); > writer.write(lowSurrogate); > writer.flush(); No it does not work. But I would be less concerned with such a charset that we don't have anywhere around, yet. The real concern is that if you invoke the above sequence, the implementation actually "buffered" the highSurr in its internal field "leftoverChar", and you will get "incompatible" result for above invocation (for charset that can handle surrogates, such as UTF8), "leftoverChar" would be process as a single surrogate, if you "flush" the osw before write the low surr. But, to save the "leftover" as its internal status is kinda against OutputStreamWriter's class spec "Note that the characters passed to the write() methods are not buffered", though I don't see any better solution for this scenario (you really don't want to have OutputSteamWriterto have an explicit interface to handle CoderResult...) That said, the spec also specifies that "A /malformed surrogate element/ is a high surrogate that is not followed by a low surrogate or a low surrogate that is not preceded by a high surrogate." So arguably, based on the spec, you are not supposed to invoke "flush()" between two paired surrogates, if you want them to be treated as a pair of surrogate for a supplementary character. This is what I have been debating with myself for months. As I said in my previous email, one alternative is to have a "close ME only" method for layered streams, but it's not going to solve the problems for any previous releases, we are talking about 1.4.x, 1.5, 6, and 7. Another ugly one is to have a "system property" to switch the behavior. I'm not sure I understand your suggestion of "create a filter...", are you suggesting to have a new filter stream class in java.io to handle the "stateful encodings", or you are suggesting the app like JavaMail should do the filter stream subclass to deal with this issue? -Sherman > > Of course, this isn't a problem with iso-2022-jp, though. > > I think it's a correct fix, not a workaround, to create a filter > stream to deal with stateful encodings with the java.io API. If it's > OK to support only 1.4 and later, the java.nio.charset API should be > used. > > Thanks, > Masayoshi > > On 2/10/2012 4:12 AM, Xueming Shen wrote: >> CCed Bill Shannon. >> >> On 02/09/2012 11:10 AM, Xueming Shen wrote: >>> >>> CharsetEncoder has the "flush()" method as the last step (of a >>> series of "encoding" steps) to >>> flush out any internal state to the output buffer. The issue here is >>> the the upper level wrapper >>> class, OutputStreamWriter in our case, doesn't provide a "explicit" >>> mechanism to let the >>> user to request a "flush" on the underlying encoder. The only >>> "guaranteed' mechanism is the >>> "close()" method, in which it appears it not appropriate to invoke >>> in some use scenario, such >>> as the JavaMail.writeTo() case. >>> >>> It appears we are lacking of a "close this stream, but not the >>> underlying stream" mechanism >>> in our layered/chained streams, I have similar request for this kind >>> of mechanism in other area, >>> such as in zip/gzip stream, app wraps a "outputstream" with >>> zip/gzip, they want to release the >>> zip/gzip layer after use (to release the native resource, for >>> example) but want to keep the >>> underlying stream unclosed. The only workaround now is to wrap the >>> underlying stream with >>> a subclass to override the "close()" method, which is really not >>> desirable. >>> >>> The OutputStreamWriter.flush() does not explicitly specify in its >>> API doc if it should actually >>> flush the underlying charset encoder (so I would not argue strongly >>> that this IS a SE bug) but >>> given it is flushing it's buffer (internal status) and then the >>> underlying "out" stream, it's >>> reasonable to consider that the "internal status" of its encoder >>> also needs to be flushed. >>> Especially this has been the behavior for releases earlier than 1.4.2. >>> >>> As I said, while I have been hesitated to "fix" this problem for a >>> while (one it has been here >>> for 3 major releases, two, the API does not explicitly say so) but >>> as long as we don't have a >>> reasonable "close-ME-only" mechanism for those layered streams, it >>> appears to be a >>> reasonable approach to solve the problem, without having obvious >>> negative impact. >>> >>> -Sherman >>> >>> PS: There is another implementation "detail" that the original >>> iso-2022-jp c2b converter >>> actually restores the state back to ASCII mode at the end of its >>> "convert" method, this makes >>> the analysis a little complicated, but should not change the issue >>> we are discussing) >>> >>> >>> On 02/09/2012 12:26 AM, Masayoshi Okutsu wrote: >>>> First of all, is this really a Java SE bug? The usage of >>>> OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo >>>> method in the bug report doesn't seem to be able to deal with any >>>> stateful encodings. >>>> >>>> Masayoshi >>>> >>>> On 2/9/2012 3:26 PM, Xueming Shen wrote: >>>>> Hi >>>>> >>>>> This is a long standing "regression" from 1.3.1 on how >>>>> OutputStreamWriter.flush()/flushBuffer() >>>>> handles escape or shift sequence in some of the charset/encoding, >>>>> for example the ISO-2022-JP. >>>>> >>>>> ISO-2022-JP is encoding that starts with ASCII mode and then >>>>> switches between ASCII andJapanese >>>>> characters through an escape sequence. For example, the escape >>>>> sequence ESC $ B (0x1B, 0x24 0x42) >>>>> is used to indicate the following bytes are Japanese (switch from >>>>> ASCII mode to Japanese mode), and >>>>> the ESC ( B (0x1b 0x28 0x42) is used to switch back to ASCII. >>>>> >>>>> In Java's sun.io.CharToByteConvert (old generation charset >>>>> converter) and the nio.io.charset.CharsetEncoder >>>>> usually switches back forth between ASCII and Japanese modes based >>>>> on the input character sequence >>>>> (for example, if you are in ASCII mode, and your next input >>>>> character is a Japanese, you add the >>>>> ESC $ B into the output first and then followed the converted >>>>> input character, or if you are in Japanese >>>>> mode and your next input is ASCII, you output ESC ( B first to >>>>> switch the mode and then the ASCII) and >>>>> switch back to ASCII mode (if the last mode is non-Japanese) if >>>>> either the encoding is ending or the >>>>> flush() method gets invoked. >>>>> >>>>> In JDK1.3.1, OutputStreamWriter.flushBuffer() explicitly invokes >>>>> sun.io.c2b's flushAny() to switch >>>>> back to ASCII mode every time the flush() or flushBuffer() (from >>>>> PrintStream) gets invoked, as >>>>> showed at the end of this email. For example, as showed below, the >>>>> code uses OutputStreamWriter >>>>> to "write" a Japanese character \u6700 to the underlying stream >>>>> with iso-2022jp, >>>>> >>>>> ByteArrayOutputStream bos = new ByteArrayOutputStream(); >>>>> String str = "\u6700"; >>>>> OutputStreamWriter osw = new OutputStreamWriter(bos, >>>>> "iso-2022-jp"); >>>>> osw.write(str, 0, str.length()); >>>>> >>>>> Since the iso-2022-jp starts with ASCII mode, we now have a >>>>> Japanese, so we need to >>>>> switch into Japanese mode first (the first 3 bytes) and then the >>>>> encoded Japanese >>>>> character (the following 2 bytes) >>>>> >>>>> 0x1b 0x24 0x42 0x3a 0x47 >>>>> >>>>> and then the code invokes >>>>> >>>>> osw.flush(); >>>>> >>>>> since we are now in Japanese, the writer continues to write out >>>>> >>>>> 0x1b 0x28 0x 42 >>>>> >>>>> to switch back to ASCII mode. The total output is 8 bytes after >>>>> write() and flush(). >>>>> >>>>> However, when all encoidng/charset related codes were migrated >>>>> from 1.3.1's sun.io based to >>>>> 1.4's java.nio.charset based implementation (1.4, 1.4.1 and 1.4.2, >>>>> we gradually migrated from >>>>> sun.io to java.nio.charset), the "c2b.flushAny()" invocation >>>>> obviously was dropped in >>>>> sun.nio.cs.StreamEncoder. It results in that the "switch back to >>>>> ASCII mode" sequence is no longer >>>>> output when OutputStreamWriter.flush() or >>>>> PrintStream.write(String) is invoked. >>>>> >>>>> This does not trigger problem for most use scenario, if the >>>>> "stream" finally gets closed >>>>> (in which the StreamEncoder does invoke encoder's flush() to >>>>> output the escape sequence >>>>> to switch back to ASCII) or PrintStream.println(String) is used >>>>> (in which it outputs a \n character, >>>>> since this \n is in ASCII range, it "accidentally " switches the >>>>> mode back to ASCII). >>>>> >>>>> But it obviously causes problem when you can't not close the >>>>> OutputStreamWriter after >>>>> you're done your iso2022-jp writing (for example, you need >>>>> continue to use the underlying >>>>> OutputStream for other writing, but not "this" osw), for 1.3.1, >>>>> these apps invoke osw.flush() >>>>> to force the output switch back to ASCII, this no longer works >>>>> when we switch to java.nio.charset >>>>> in jdk1.4.2. (we migrated iso-2022-jp to nio.charset in 1.4.2). >>>>> This is what happened in JavaMail, >>>>> as described in the bug report. >>>>> >>>>> The solution is to re-store the "flush the encoder" mechanism in >>>>> StreamEncoder's flushBuffer(). >>>>> >>>>> I have been hesitated to make this change for a while, mostly >>>>> because this regressed behavior >>>>> has been their for 3 releases, and the change triggers yet another >>>>> "behavior change". But given >>>>> there is no obvious workaround and it only changes the behavior of >>>>> the charsets with this >>>>> shift in/out mechanism, mainly the iso-2022 family and those IBM >>>>> EBCDIC_DBCS charsets, I >>>>> decided to give it a try. >>>>> >>>>> Here is the webreview >>>>> >>>>> http://cr.openjdk.java.net/~sherman/6995537/webrev >>>>> >>>>> Sherman >>>>> >>>>> >>>>> ---------------------------------1.3.1 >>>>> OutputStreamWriter----------------------- >>>>> /** >>>>> * Flush the output buffer to the underlying byte stream, >>>>> without flushing >>>>> * the byte stream itself. This method is non-private only so >>>>> that it may >>>>> * be invoked by PrintStream. >>>>> */ >>>>> void flushBuffer() throws IOException { >>>>> synchronized (lock) { >>>>> ensureOpen(); >>>>> >>>>> for (;;) { >>>>> try { >>>>> nextByte += ctb.flushAny(bb, nextByte, nBytes); >>>>> } >>>>> catch (ConversionBufferFullException x) { >>>>> nextByte = ctb.nextByteIndex(); >>>>> } >>>>> if (nextByte == 0) >>>>> break; >>>>> if (nextByte > 0) { >>>>> out.write(bb, 0, nextByte); >>>>> nextByte = 0; >>>>> } >>>>> } >>>>> } >>>>> } >>>>> >>>>> /** >>>>> * Flush the stream. >>>>> * >>>>> * @exception IOException If an I/O error occurs >>>>> */ >>>>> public void flush() throws IOException { >>>>> synchronized (lock) { >>>>> flushBuffer(); >>>>> out.flush(); >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> >>> >> From alexlamsl at gmail.com Fri Feb 10 19:54:52 2012 From: alexlamsl at gmail.com (Alex Lam S.L.) Date: Fri, 10 Feb 2012 19:54:52 +0000 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: <4F3525F3.6080701@univ-mlv.fr> References: <4F351FC8.2050703@oracle.com> <4F3525F3.6080701@univ-mlv.fr> Message-ID: It sounds very reasonable when you put it that way ;-) I was thinking along the lines of when flush() fails - clearly you can't flush a stream when it is closed - then it should throw an IOException. = Either way - I will sleep some more on my code and work around this in JDK8. Thank you and Alan for all the good advices! Regards, Alex. On Fri, Feb 10, 2012 at 2:13 PM, R?mi Forax wrote: > On 02/10/2012 02:52 PM, Alex Lam S.L. wrote: >> >> Hi there, >> >> Thanks for the pointer - I wasn't able to trace back to that email for >> some reasons. >> >> The problem is that: >> >> ?- flush() is reporting IOException because underlying stream is closed >> ?- close() is then forwarding that IOException now in JavaSE 8 >> >> I guess my question is: what is the best way to check and avoid the >> case where OutputStream is already closed? >> >> >> Regards, >> Alex. > > > In my opinion, flush() should not throw an exception when the stream is > closed. > close() doesn't throw an exception in that case and close() should be able > to call flush(). > > R?mi > From bradford.wetmore at oracle.com Sat Feb 11 03:13:49 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Sat, 11 Feb 2012 03:13:49 +0000 Subject: hg: jdk8/tl/jdk: 7142509: Cipher.doFinal(ByteBuffer, ByteBuffer) fails to process when in.remaining() == 0 Message-ID: <20120211031422.DFCF347479@hg.openjdk.java.net> Changeset: b16cbeb0d213 Author: wetmore Date: 2012-02-10 19:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16cbeb0d213 7142509: Cipher.doFinal(ByteBuffer,ByteBuffer) fails to process when in.remaining() == 0 Reviewed-by: valeriep ! src/share/classes/javax/crypto/CipherSpi.java + test/javax/crypto/CipherSpi/DirectBBRemaining.java From xuelei.fan at oracle.com Sat Feb 11 06:19:33 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 11 Feb 2012 06:19:33 +0000 Subject: hg: jdk8/tl/jdk: 7144781: incorrect URLs in JSSE java doc Message-ID: <20120211061952.1900B4747D@hg.openjdk.java.net> Changeset: da8b8ee281f9 Author: xuelei Date: 2012-02-10 22:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da8b8ee281f9 7144781: incorrect URLs in JSSE java doc Reviewed-by: wetmore, skannan ! src/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/share/classes/javax/net/ssl/SSLParameters.java From Roger.Riggs at oracle.com Sat Feb 11 17:31:12 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Sat, 11 Feb 2012 12:31:12 -0500 Subject: Review: JDK 8 CR for Support Integer overflow updated Message-ID: <4F36A5E0.3060706@oracle.com> Updated the webrev for CR6708398: http://cr.openjdk.java.net/~rriggs/6708398.2 - Added a paragraph to the class javadoc for Math and StrictMath to introduce the exact arithmetic methods and their uses. - Editorial correction to first sentence of each method to consistent use "Returns". - Added Tests for the StrictMath methods (they are the same tests as for Math) Thanks, Roger From chris.hegarty at oracle.com Sun Feb 12 08:49:04 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 12 Feb 2012 08:49:04 +0000 Subject: hg: jdk8/tl/jdk: 7133367: ResponseCache.put should not be called when setUseCaches(false) Message-ID: <20120212084914.C214A4748E@hg.openjdk.java.net> Changeset: 27a6b299ed6a Author: chegar Date: 2012-02-12 08:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27a6b299ed6a 7133367: ResponseCache.put should not be called when setUseCaches(false) Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/NoCache.java From Alan.Bateman at oracle.com Sun Feb 12 17:45:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 12 Feb 2012 17:45:04 +0000 Subject: 7144895: ProblemList.txt updates (2/2012) Message-ID: <4F37FAA0.2040306@oracle.com> It's time to sync up jdk/test/ProblemList.txt again. As a reminder, this is the file that serves as the exclude list when running the tests via Makefile ("cd jdk/test && make jdk_lang" for example). For this update I've removed most of the lines that have been excluding tests from the jdk_rmi and jdk_management batches. These tests have been there since the list was created and as far I can establish, all stem from attempts to run tests concurrently, something that isn't currently possible with RMI tests because so many of them use the RMI registry on the default port. As part of this I have added new entries to TEST.ROOT that will tell jtreg that the tests in the specified directories cannot run in othervm mode or concurrently. These will be ignored for now but Jon Gibbons has changes coming for jtreg to enforce this. One other thing about the RMI tests is that the activation tests are woefully slow with the result that the jdk_rmi target takes about 30m to run. I've created 7144861 for this and any help to diagnose why these tests are so slow is very welcome. I've added two serviceability tests to the file as they have been failing intermittently. I've also added two pack200 tests that are just too slow to run on a regular basis (I had a brief chat with Kumar about this last week so he agreed this is the right thing for these tests). One final change is that I noticed that the tests in java/nio/charset/** were not being run by the jdk_nio target so this is fixed. The webrev with the change is here: http://cr.openjdk.java.net/~alanb/7144895/webrev/ Thanks, Alan. From joe.darcy at oracle.com Sun Feb 12 18:41:32 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 12 Feb 2012 10:41:32 -0800 Subject: 7144895: ProblemList.txt updates (2/2012) In-Reply-To: <4F37FAA0.2040306@oracle.com> References: <4F37FAA0.2040306@oracle.com> Message-ID: <4F3807DC.9080207@oracle.com> Looks fine Alan, -Joe On 02/12/2012 09:45 AM, Alan Bateman wrote: > > It's time to sync up jdk/test/ProblemList.txt again. As a reminder, > this is the file that serves as the exclude list when running the > tests via Makefile ("cd jdk/test && make jdk_lang" for example). > > For this update I've removed most of the lines that have been > excluding tests from the jdk_rmi and jdk_management batches. These > tests have been there since the list was created and as far I can > establish, all stem from attempts to run tests concurrently, something > that isn't currently possible with RMI tests because so many of them > use the RMI registry on the default port. As part of this I have added > new entries to TEST.ROOT that will tell jtreg that the tests in the > specified directories cannot run in othervm mode or concurrently. > These will be ignored for now but Jon Gibbons has changes coming for > jtreg to enforce this. One other thing about the RMI tests is that the > activation tests are woefully slow with the result that the jdk_rmi > target takes about 30m to run. I've created 7144861 for this and any > help to diagnose why these tests are so slow is very welcome. > > I've added two serviceability tests to the file as they have been > failing intermittently. I've also added two pack200 tests that are > just too slow to run on a regular basis (I had a brief chat with Kumar > about this last week so he agreed this is the right thing for these > tests). > > One final change is that I noticed that the tests in > java/nio/charset/** were not being run by the jdk_nio target so this > is fixed. > > The webrev with the change is here: > > http://cr.openjdk.java.net/~alanb/7144895/webrev/ > > Thanks, > Alan. From kelly.ohair at oracle.com Sun Feb 12 19:21:34 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Sun, 12 Feb 2012 11:21:34 -0800 Subject: 7144895: ProblemList.txt updates (2/2012) In-Reply-To: <4F37FAA0.2040306@oracle.com> References: <4F37FAA0.2040306@oracle.com> Message-ID: <9840258A-9EC4-4B23-9A58-DD0A8CEE69E4@oracle.com> Looks good. Glad to see the ProblemList.txt file get trimmed down. -kto On Feb 12, 2012, at 9:45 AM, Alan Bateman wrote: > > It's time to sync up jdk/test/ProblemList.txt again. As a reminder, this is the file that serves as the exclude list when running the tests via Makefile ("cd jdk/test && make jdk_lang" for example). > > For this update I've removed most of the lines that have been excluding tests from the jdk_rmi and jdk_management batches. These tests have been there since the list was created and as far I can establish, all stem from attempts to run tests concurrently, something that isn't currently possible with RMI tests because so many of them use the RMI registry on the default port. As part of this I have added new entries to TEST.ROOT that will tell jtreg that the tests in the specified directories cannot run in othervm mode or concurrently. These will be ignored for now but Jon Gibbons has changes coming for jtreg to enforce this. One other thing about the RMI tests is that the activation tests are woefully slow with the result that the jdk_rmi target takes about 30m to run. I've created 7144861 for this and any help to diagnose why these tests are so slow is very welcome. > > I've added two serviceability tests to the file as they have been failing intermittently. I've also added two pack200 tests that are just too slow to run on a regular basis (I had a brief chat with Kumar about this last week so he agreed this is the right thing for these tests). > > One final change is that I noticed that the tests in java/nio/charset/** were not being run by the jdk_nio target so this is fixed. > > The webrev with the change is here: > > http://cr.openjdk.java.net/~alanb/7144895/webrev/ > > Thanks, > Alan. From alan.bateman at oracle.com Sun Feb 12 21:11:23 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 12 Feb 2012 21:11:23 +0000 Subject: hg: jdk8/tl/jdk: 7144895: ProblemList.txt updates (2/2012) Message-ID: <20120212211144.D5B8447493@hg.openjdk.java.net> Changeset: 27e746e6f3fe Author: alanb Date: 2012-02-12 21:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27e746e6f3fe 7144895: ProblemList.txt updates (2/2012) Reviewed-by: darcy, ohair ! test/Makefile ! test/ProblemList.txt ! test/TEST.ROOT From jonathan.gibbons at oracle.com Sun Feb 12 21:39:37 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 12 Feb 2012 13:39:37 -0800 Subject: Easy-to-fix javadoc warning Message-ID: <4F383199.7060809@oracle.com> Someone in the core-libs team should look at fixing this trivial javadoc warning. The replacement should presumably be {@code httpServerProvider} -- Jon # Packages (httpserver.packages): # com.sun.net.httpserver # com.sun.net.httpserver.spi /opt/jdk/1.7.0/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx612m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/langtools/dist/bootstrap/lib/javadoc.jar:/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/langtools/dist/bootstrap/lib/javac.jar:/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/langtools/dist/bootstrap/lib/doclets.jar" -jar /w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/langtools/dist/bootstrap/lib/javadoc.jar -bootclasspath /w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/classes -d /w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/docs/jre/api/net/httpserver/spec \ @/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/tmp/docs/doctmp/httpserver.options @/w/jjg/work/7144951-javadoc-issues/tl/build/linux-i586/tmp/docs/doctmp/httpserver.packages *../../src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java:81: warning - @code("httpServerProvider") is an unknown tag.* 1 warning From jonathan.gibbons at oracle.com Mon Feb 13 00:44:48 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 Feb 2012 00:44:48 +0000 Subject: hg: jdk8/tl/langtools: 7144979: incorrect path separator in make/build.xml for Windows when running jtreg tests Message-ID: <20120213004453.0CCFF47494@hg.openjdk.java.net> Changeset: cd5ca700da4c Author: jjg Date: 2012-02-12 16:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cd5ca700da4c 7144979: incorrect path separator in make/build.xml for Windows when running jtreg tests Reviewed-by: jjg Contributed-by: jan.valenta at oracle.com ! make/build.xml From stuart.marks at oracle.com Mon Feb 13 05:55:05 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Mon, 13 Feb 2012 05:55:05 +0000 Subject: hg: jdk8/tl/jdk: 7143230: fix warnings in java.util.jar, sun.tools.jar, zipfs demo, etc. Message-ID: <20120213055527.1501647499@hg.openjdk.java.net> Changeset: 445ada5e6b4a Author: smarks Date: 2012-02-12 21:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445ada5e6b4a 7143230: fix warnings in java.util.jar, sun.tools.jar, zipfs demo, etc. Reviewed-by: alanb, chegar, lancea, smarks Contributed-by: Mani Sarkar , Michael Barker , Carl Jokl , Dinuk Weerasinghe , Markus Stoy , Tom Anderson ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/sun/tools/jar/CommandLine.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java From chris.hegarty at oracle.com Mon Feb 13 11:12:56 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Feb 2012 11:12:56 +0000 Subject: Easy-to-fix javadoc warning Message-ID: <4F38F038.2060209@oracle.com> Thanks for reporting this Jon. I filed CR 7145043: "HttpServerProvider.java:81: warning - @code("httpServerProvider") is an unknown tag" You see quite a few of these type of RuntimePermission links through out the core area. The intent is to link to RuntimePermission and show the appropriate String arg "target name". The simplest fix is to add a space after the @code tag. This generates the required javadoc, "RuntimePermission("httpServerProvider")", similar to how it appears in System.getenv [1]. src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java @@ -76,7 +76,7 @@ public abstract class HttpServerProvider * * @throws SecurityException * If a security manager has been installed and it denies - * {@link RuntimePermission}{@code("httpServerProvider")} + * {@link RuntimePermission}{@code ("httpServerProvider")} */ protected HttpServerProvider() { SecurityManager sm = System.getSecurityManager(); Thanks, -Chris. [1] http://download.java.net/jdk8/docs/api/java/lang/System.html#getenv%28java.lang.String%29 From vincent.x.ryan at oracle.com Mon Feb 13 14:32:27 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 13 Feb 2012 14:32:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120213143305.349E3474A4@hg.openjdk.java.net> Changeset: 3554f175341a Author: vinnie Date: 2012-02-13 14:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3554f175341a 7142339: PKCS7.java is needlessly creating SHA1PRNG SecureRandom instances when timestamping is not done Reviewed-by: xuelei, wetmore ! src/share/classes/sun/security/pkcs/PKCS7.java Changeset: 59bd472746d6 Author: vinnie Date: 2012-02-13 14:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59bd472746d6 Merge - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java From tom.hawtin at oracle.com Mon Feb 13 16:54:17 2012 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 13 Feb 2012 16:54:17 +0000 Subject: Please review: 7143711 : Feature added by 7053556 should not override what's set by the constructor in secure mode In-Reply-To: <4F32F377.5080706@oracle.com> References: <4EF4F236.3080200@oracle.com> <4EFAF5C7.90509@oracle.com> <4EFB4F74.9010809@oracle.com> <4EFDC736.1090302@oracle.com> <4EFDFEE5.1080803@oracle.com> <4F32F377.5080706@oracle.com> Message-ID: <4F394039.1010804@oracle.com> Looks good to me. Tom On 08/02/2012 22:13, Joe Wang wrote: > Hi, > > The 7053556 patch added a (Oracle) implementation-only feature to allow > users to skip the plugability layer. In the same patch, there was also a > change that in secure mode, dependent components should be loaded in a > hardwired mode. The implementation-only feature therefore should not > override what's set by the constructor in secure mode. > > Please consider this is a supplemental change to 7053556 since it itself > is a change for 7u4. > > Below are the changes: > Index: > com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java > --- > com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java > Base (BASE) > +++ > com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java > Locally Modified (Based On LOCAL) > @@ -487,6 +487,8 @@ > return; > } > else if (name.equals(XalanConstants.ORACLE_FEATURE_SERVICE_MECHANISM)) { > + //in secure mode, let _useServicesMechanism be determined by the > constructor > + if (!_isSecureMode) > _useServicesMechanism = value; > } > else { > Index: com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java > --- com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java Base > (BASE) > +++ com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java Locally > Modified (Based On LOCAL) > @@ -226,6 +226,8 @@ > return; > } > if (name.equals(XalanConstants.ORACLE_FEATURE_SERVICE_MECHANISM)) { > + //in secure mode, let _useServicesMechanism be determined by the > constructor > + if (!_isSecureMode) > _useServicesMechanism = value; > return; > } > Index: > com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java > --- > com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java > Base (BASE) > +++ > com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java > Locally Modified (Based On LOCAL) > @@ -390,6 +390,10 @@ > fSecurityManager = value ? new SecurityManager() : null; > fXMLSchemaLoader.setProperty(SECURITY_MANAGER, fSecurityManager); > return; > + } else if (name.equals(Constants.ORACLE_FEATURE_SERVICE_MECHANISM)) { > + //in secure mode, let _useServicesMechanism be determined by the > constructor > + if (System.getSecurityManager() != null) > + return; > } > try { > fXMLSchemaLoader.setFeature(name, value); > > Thanks, > Joe From huizhe.wang at oracle.com Mon Feb 13 17:06:13 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 13 Feb 2012 09:06:13 -0800 Subject: Please review: 7143711 : Feature added by 7053556 should not override what's set by the constructor in secure mode In-Reply-To: <4F394039.1010804@oracle.com> References: <4EF4F236.3080200@oracle.com> <4EFAF5C7.90509@oracle.com> <4EFB4F74.9010809@oracle.com> <4EFDC736.1090302@oracle.com> <4EFDFEE5.1080803@oracle.com> <4F32F377.5080706@oracle.com> <4F394039.1010804@oracle.com> Message-ID: <4F394305.2030004@oracle.com> Thanks Tom. Joe On 2/13/2012 8:54 AM, Tom Hawtin wrote: > Looks good to me. > > Tom > > On 08/02/2012 22:13, Joe Wang wrote: >> Hi, >> >> The 7053556 patch added a (Oracle) implementation-only feature to allow >> users to skip the plugability layer. In the same patch, there was also a >> change that in secure mode, dependent components should be loaded in a >> hardwired mode. The implementation-only feature therefore should not >> override what's set by the constructor in secure mode. >> >> Please consider this is a supplemental change to 7053556 since it itself >> is a change for 7u4. >> >> Below are the changes: >> Index: >> com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java >> --- >> com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java >> Base (BASE) >> +++ >> com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java >> Locally Modified (Based On LOCAL) >> @@ -487,6 +487,8 @@ >> return; >> } >> else if (name.equals(XalanConstants.ORACLE_FEATURE_SERVICE_MECHANISM)) { >> + //in secure mode, let _useServicesMechanism be determined by the >> constructor >> + if (!_isSecureMode) >> _useServicesMechanism = value; >> } >> else { >> Index: com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java >> --- com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java Base >> (BASE) >> +++ com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java Locally >> Modified (Based On LOCAL) >> @@ -226,6 +226,8 @@ >> return; >> } >> if (name.equals(XalanConstants.ORACLE_FEATURE_SERVICE_MECHANISM)) { >> + //in secure mode, let _useServicesMechanism be determined by the >> constructor >> + if (!_isSecureMode) >> _useServicesMechanism = value; >> return; >> } >> Index: >> com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java >> --- >> com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java >> Base (BASE) >> +++ >> com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java >> Locally Modified (Based On LOCAL) >> @@ -390,6 +390,10 @@ >> fSecurityManager = value ? new SecurityManager() : null; >> fXMLSchemaLoader.setProperty(SECURITY_MANAGER, fSecurityManager); >> return; >> + } else if (name.equals(Constants.ORACLE_FEATURE_SERVICE_MECHANISM)) { >> + //in secure mode, let _useServicesMechanism be determined by the >> constructor >> + if (System.getSecurityManager() != null) >> + return; >> } >> try { >> fXMLSchemaLoader.setFeature(name, value); >> >> Thanks, >> Joe > From xueming.shen at oracle.com Mon Feb 13 17:36:36 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 13 Feb 2012 09:36:36 -0800 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows Message-ID: <4F394A24.5040508@oracle.com> Hi This is a long standing Windows codepage support issue on Java platform (we probably have 20 bug/rfes filed for this particular issue and closed as the dup of 4153167). Windows supports two sets of codepages, ANSI (Windows) codepage and OEM (IBM) codepage. Windows uses ANSI/Windows codepage almost "everywhere" except in its dos/command prompt window, which uses OEM codepage. For example, on a normal English Windows, the default Windows codepage isCp1252 (west European Latin) and the OEM codepage used in its dos/command prompt however is Cp437 (you can use chcp command to check/change the "active" codepage used in your dos/coomand prompt). These two obviously have different mapping for certain code points, for example those umlaut characters. J2SE runtime chooses the ANSI/Windows codepage as its default charset for its i/o character reading/writing, graphic text display, etc. including System.out&err. This causes problem when the ANSI code page and OEM codepage are not "compatible" and you happen to need to write those "in-compatible" characters to the dos/command prompt, as show in the following test case String umlaut = "\u00f6\u00e4\u00fc\u00d6\u00c4\u00dc\u00df"; PrintWriter ps = new PrintWriter(new OutputStreamWriter(System.out, "Cp437"), true ); ps.println("ps.cp437: " + umlaut); System.out.println("sys.out : " + umlaut); System.err.println("sys.err : " + umlaut); You will see the umlauts get displayed correctly from PrintWriter with explicit Cp437 encoding setting, but garbled from system.out and err (because both the System.out & err use the default charset Cp1252, which is also used for all necessary Unicode <-> Windows encoding conversion for that particular vm instance). For years, we have been debating whether or not we should and how to fix this issue, do we want to have two "default charset" for i/o. In jdk6, we have provided a java.io.Console class that specifically uses OEM codepage when running on Windows' dos/command prompt. However, the feedback is that people still want the System.out/err to work correctly with the dos/command prompt, when the OEM codepage used is not "compatible" with the default Windows codepage. The proposed change here is to use OEM codepage for System.out/err when the vm is started without its std out/err is redirected to something else, such as a file (make sure to only use OME for the dos/command prompt), if vm's std out/err is redirected, then continue to use the default charset (file.encoding) for the System.out/err. I believe this approach solves the problem without breaking any existing assumption/use scenario. The webrev is at http://cr.openjdk.java.net/~sherman/4153167/webrev Here is a simple"manual" test case. public class HelloWorld { public static void main(String[] args) throws Exception { String umlaut = "\u00f6\u00e4\u00fc\u00d6\u00c4\u00dc\u00df"; System.out.println("file.encoding =" + System.getProperty("file.encoding")); System.out.println("stdout.encoding=" + System.getProperty("sun.stdout.encoding")); System.out.println("stderr.encoding=" + System.getProperty("sun.stderr.encoding")); System.out.println("-----------------------"); PrintWriter ps = new PrintWriter(new OutputStreamWriter(System.out, "Cp437"), true ); ps.println("ps.cp437: " + umlaut); System.out.println("sys.out : " + umlaut); System.err.println("sys.err : " + umlaut); Console con = System.console(); if (con != null) con.printf("console : %s%n", umlaut); } } -Sherman From scolebourne at joda.org Mon Feb 13 17:52:48 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 13 Feb 2012 17:52:48 +0000 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <4F36A5E0.3060706@oracle.com> References: <4F36A5E0.3060706@oracle.com> Message-ID: On 11 February 2012 17:31, Roger Riggs wrote: > Updated the webrev for CR6708398: > ? ? ? ? http://cr.openjdk.java.net/~rriggs/6708398.2 > ?- Added a paragraph to the class javadoc for Math and StrictMath to > ? introduce the exact arithmetic methods and their uses. > ?- Editorial correction to first sentence of each method to consistent use > "Returns". > ?- Added Tests for the StrictMath methods ?(they are the same tests as for > Math) In case you didn't see it, the question as to what to include was asked here http://blog.joda.org/2012/02/jdk-helper-math-methods.html The answers were inconclusive, however I would argue that negate has enough supporters to justify inclusion. Stephen From Ulf.Zibis at gmx.de Mon Feb 13 18:15:20 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 13 Feb 2012 19:15:20 +0100 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F394A24.5040508@oracle.com> References: <4F394A24.5040508@oracle.com> Message-ID: <4F395338.7090803@gmx.de> Interesting issue, especially for us germans! What is about System.in, if one types some umlaute at Windows console? Why are there theoretically different code pages for stdout and stderr? -Ulf Am 13.02.2012 18:36, schrieb Xueming Shen: > Hi > > This is a long standing Windows codepage support issue on Java platform (we probably have > 20 bug/rfes filed for this particular issue and closed as the dup of 4153167). Windows supports > two sets of codepages, ANSI (Windows) codepage and OEM (IBM) codepage. Windows uses > ANSI/Windows codepage almost "everywhere" except in its dos/command prompt window, > which uses OEM codepage. For example, on a normal English Windows, the default Windows > codepage isCp1252 (west European Latin) and > the OEM codepage used in its dos/command > prompt however is Cp437 (you can use chcp > command to check/change the "active" codepage > used in your dos/coomand prompt). These two obviously have different mapping for certain > code points, for example those umlaut characters. > > J2SE runtime chooses the ANSI/Windows codepage as its default charset for its i/o character > reading/writing, graphic text display, etc. including System.out&err. This causes problem when > the ANSI code page and OEM codepage are not "compatible" and you happen to need to write > those "in-compatible" characters to the dos/command prompt, as show in the following test > case > > String umlaut = "\u00f6\u00e4\u00fc\u00d6\u00c4\u00dc\u00df"; > PrintWriter ps = new PrintWriter(new OutputStreamWriter(System.out, "Cp437"), true ); > ps.println("ps.cp437: " + umlaut); > System.out.println("sys.out : " + umlaut); > System.err.println("sys.err : " + umlaut); > > You will see the umlauts get displayed correctly from PrintWriter with explicit Cp437 encoding > setting, but garbled from system.out and err (because both the System.out & err use the default > charset Cp1252, which is also used for all necessary Unicode <-> Windows encoding conversion > for that particular vm instance). > > For years, we have been debating whether or not we should and how to fix this issue, do we > want to have two "default charset" for i/o. In jdk6, we have provided a java.io.Console class > that specifically uses OEM codepage when running on Windows' dos/command prompt. > However, the feedback is that people still want the System.out/err to work correctly with > the dos/command prompt, when the OEM codepage used is not "compatible" with the default > Windows codepage. > > The proposed change here is to use OEM codepage for System.out/err when the vm is > started without its std out/err is redirected to something else, such as a file (make sure > to only use OME for the dos/command prompt), if vm's std out/err is redirected, then > continue to use the default charset (file.encoding) for the System.out/err. I believe this > approach solves the problem without breaking any existing assumption/use scenario. > > The webrev is at > > http://cr.openjdk.java.net/~sherman/4153167/webrev > > Here is a simple"manual" test case. > > public class HelloWorld { > > public static void main(String[] args) throws Exception { > > String umlaut = "\u00f6\u00e4\u00fc\u00d6\u00c4\u00dc\u00df"; > > System.out.println("file.encoding =" + System.getProperty("file.encoding")); > System.out.println("stdout.encoding=" + System.getProperty("sun.stdout.encoding")); > System.out.println("stderr.encoding=" + System.getProperty("sun.stderr.encoding")); > System.out.println("-----------------------"); > > PrintWriter ps = new PrintWriter(new OutputStreamWriter(System.out, "Cp437"), > true ); > ps.println("ps.cp437: " + umlaut); > System.out.println("sys.out : " + umlaut); > System.err.println("sys.err : " + umlaut); > Console con = System.console(); > if (con != null) > con.printf("console : %s%n", umlaut); > } > } > > -Sherman > From xueming.shen at oracle.com Mon Feb 13 18:35:27 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 13 Feb 2012 10:35:27 -0800 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F395338.7090803@gmx.de> References: <4F394A24.5040508@oracle.com> <4F395338.7090803@gmx.de> Message-ID: <4F3957EF.5070200@oracle.com> On 2/13/2012 10:15 AM, Ulf Zibis wrote: > Interesting issue, especially for us germans! > > What is about System.in, if one types some umlaute at Windows console? System.in is a "InputStream", no charset involved there, you build your own "reader" on top of that yourself. > > Why are there theoretically different code pages for stdout and stderr? you can re-direct std err to a log file file but keep the std out to the console, or re-direct the std out but keep the std.err to the console, in these scenario, the stderr and stdout will use different code page. Basically the approach is that if the otuput stream gets re-directed, it keeps using the default charset (with the assumption that the rest of the world is using the Windows codepage), if not, use the oem codepage from the console on Windows, to make sure the System.out/err outputs the bits that the underlying console can understand. -Sherman -Sherman > > -Ulf > > > Am 13.02.2012 18:36, schrieb Xueming Shen: >> Hi >> >> This is a long standing Windows codepage support issue on Java >> platform (we probably have >> 20 bug/rfes filed for this particular issue and closed as the dup of >> 4153167). Windows supports >> two sets of codepages, ANSI (Windows) codepage and OEM (IBM) >> codepage. Windows uses >> ANSI/Windows codepage almost "everywhere" except in its dos/command >> prompt window, >> which uses OEM codepage. For example, on a normal English Windows, >> the default Windows >> codepage isCp1252 >> (west European Latin) and the OEM codepage used in its dos/command >> prompt however is Cp437 >> (you can use chcp >> command to check/change the "active" codepage >> used in your dos/coomand prompt). These two obviously have different >> mapping for certain >> code points, for example those umlaut characters. >> >> J2SE runtime chooses the ANSI/Windows codepage as its default charset >> for its i/o character >> reading/writing, graphic text display, etc. including System.out&err. >> This causes problem when >> the ANSI code page and OEM codepage are not "compatible" and you >> happen to need to write >> those "in-compatible" characters to the dos/command prompt, as show >> in the following test >> case >> >> String umlaut = "\u00f6\u00e4\u00fc\u00d6\u00c4\u00dc\u00df"; >> PrintWriter ps = new PrintWriter(new >> OutputStreamWriter(System.out, "Cp437"), true ); >> ps.println("ps.cp437: " + umlaut); >> System.out.println("sys.out : " + umlaut); >> System.err.println("sys.err : " + umlaut); >> >> You will see the umlauts get displayed correctly from PrintWriter >> with explicit Cp437 encoding >> setting, but garbled from system.out and err (because both the >> System.out & err use the default >> charset Cp1252, which is also used for all necessary Unicode <-> >> Windows encoding conversion >> for that particular vm instance). >> >> For years, we have been debating whether or not we should and how to >> fix this issue, do we >> want to have two "default charset" for i/o. In jdk6, we have provided >> a java.io.Console class >> that specifically uses OEM codepage when running on Windows' >> dos/command prompt. >> However, the feedback is that people still want the System.out/err to >> work correctly with >> the dos/command prompt, when the OEM codepage used is not >> "compatible" with the default >> Windows codepage. >> >> The proposed change here is to use OEM codepage for System.out/err >> when the vm is >> started without its std out/err is redirected to something else, such >> as a file (make sure >> to only use OME for the dos/command prompt), if vm's std out/err is >> redirected, then >> continue to use the default charset (file.encoding) for the >> System.out/err. I believe this >> approach solves the problem without breaking any existing >> assumption/use scenario. >> >> The webrev is at >> >> http://cr.openjdk.java.net/~sherman/4153167/webrev >> >> Here is a simple"manual" test case. >> >> public class HelloWorld { >> >> public static void main(String[] args) throws Exception { >> >> String umlaut = "\u00f6\u00e4\u00fc\u00d6\u00c4\u00dc\u00df"; >> >> System.out.println("file.encoding =" + >> System.getProperty("file.encoding")); >> System.out.println("stdout.encoding=" + >> System.getProperty("sun.stdout.encoding")); >> System.out.println("stderr.encoding=" + >> System.getProperty("sun.stderr.encoding")); >> System.out.println("-----------------------"); >> >> PrintWriter ps = new PrintWriter(new >> OutputStreamWriter(System.out, "Cp437"), >> true ); >> ps.println("ps.cp437: " + umlaut); >> System.out.println("sys.out : " + umlaut); >> System.err.println("sys.err : " + umlaut); >> Console con = System.console(); >> if (con != null) >> con.printf("console : %s%n", umlaut); >> } >> } >> >> -Sherman >> From Ulf.Zibis at gmx.de Mon Feb 13 21:20:50 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 13 Feb 2012 22:20:50 +0100 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F3957EF.5070200@oracle.com> References: <4F394A24.5040508@oracle.com> <4F395338.7090803@gmx.de> <4F3957EF.5070200@oracle.com> Message-ID: <4F397EB2.6050507@gmx.de> Am 13.02.2012 19:35, schrieb Xueming Shen: > On 2/13/2012 10:15 AM, Ulf Zibis wrote: >> Interesting issue, especially for us germans! >> >> What is about System.in, if one types some umlaute at Windows console? > > System.in is a "InputStream", no charset involved there, you build your own "reader" > on top of that yourself. Well, in normal case, one would use the InputStreamReader with default charset. In case of Windows console, characters likely would be decoded wrong. So IMO there should be a mechanism, that e.g. InputStreamReader chooses the correct OEM charset, if not explicitly defined otherwise and if the underlying input stream System.in is directly reading from the Windows console. >> Why are there theoretically different code pages for stdout and stderr? > > you can re-direct std err to a log file file but keep the std out to the console, or re-direct > the std out but keep the std.err to the console, in these scenario, the stderr and stdout > will use different code page. Basically the approach is that if the otuput stream gets > re-directed, it keeps using the default charset (with the assumption that the rest of the > world is using the Windows codepage), if not, use the oem codepage from the console > on Windows, to make sure the System.out/err outputs the bits that the underlying > console can understand. Oops, I'm not sure, if you didn't misunderstood me. I mean, why are there 2 different properties? : "sun.stdout.encoding" "sun.stderr.encoding" Shouldn't something be enough like "console.encoding" as counterpart to "file.encoding" ? -Ulf From Roger.Riggs at oracle.com Mon Feb 13 21:32:11 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 13 Feb 2012 16:32:11 -0500 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: References: <4F36A5E0.3060706@oracle.com> Message-ID: <4F39815B.6070509@oracle.com> Thanks for the raising the question on the blog and the comments. I see support based only on general principles and not from use cases where the function would be essential. At this point, we're not trying to provide a complete set of exact arithmetic functions but to cover the cases where developers can benefit from not having to deal with the tricky parts themselves. On 02/13/2012 12:52 PM, Stephen Colebourne wrote: > On 11 February 2012 17:31, Roger Riggs wrote: >> Updated the webrev for CR6708398: >> http://cr.openjdk.java.net/~rriggs/6708398.2 >> - Added a paragraph to the class javadoc for Math and StrictMath to >> introduce the exact arithmetic methods and their uses. >> - Editorial correction to first sentence of each method to consistent use >> "Returns". >> - Added Tests for the StrictMath methods (they are the same tests as for >> Math) > In case you didn't see it, the question as to what to include was asked here > http://blog.joda.org/2012/02/jdk-helper-math-methods.html > > The answers were inconclusive, however I would argue that negate has > enough supporters to justify inclusion. > > Stephen From xueming.shen at oracle.com Mon Feb 13 23:02:05 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 13 Feb 2012 15:02:05 -0800 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F397EB2.6050507@gmx.de> References: <4F394A24.5040508@oracle.com> <4F395338.7090803@gmx.de> <4F3957EF.5070200@oracle.com> <4F397EB2.6050507@gmx.de> Message-ID: <4F39966D.4000804@oracle.com> To have separate sun.stdout.encoding and sun.stderr.encoding is mainly because of implementation convenience. I need three things from the native (1) is std.out tty (2) is std.err tty (3) the console encoding if (1) or (2) are true, and I tried to avoid to go down to native multiple times it appears passing back two encoding name is the easiest approach. The original plan was to remove them after use, maybe via sun.misc.VM.saveAndRemoveProperties() (or simply remove them directly), but then thought the info might be useful... Auto detect the encoding of InputStreamReader when it is attached the console is nice to have, but I would try to avoid doing that until I have to, before that I would still advise the use of java.io.Console class:-) -Sherman > >>> Why are there theoretically different code pages for stdout and stderr? >> >> you can re-direct std err to a log file file but keep the std out to >> the console, or re-direct >> the std out but keep the std.err to the console, in these scenario, >> the stderr and stdout >> will use different code page. Basically the approach is that if the >> otuput stream gets >> re-directed, it keeps using the default charset (with the assumption >> that the rest of the >> world is using the Windows codepage), if not, use the oem codepage >> from the console >> on Windows, to make sure the System.out/err outputs the bits that the >> underlying >> console can understand. > Oops, I'm not sure, if you didn't misunderstood me. > I mean, why are there 2 different properties? : > "sun.stdout.encoding" > "sun.stderr.encoding" > Shouldn't something be enough like > "console.encoding" > as counterpart to > "file.encoding" > ? > > -Ulf > From xueming.shen at oracle.com Mon Feb 13 23:16:21 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 13 Feb 2012 15:16:21 -0800 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F395F7F.6000509@oracle.com> References: <4F394A24.5040508@oracle.com> <4F395F7F.6000509@oracle.com> Message-ID: <4F3999C5.2010707@oracle.com> On 2/13/2012 11:07 AM, Bill Shannon wrote: > Thanks for fixing this! > >> The webrev is at >> >> http://cr.openjdk.java.net/~sherman/4153167/webrev > > You probably don't need to malloc 64 bytes for a string that's > going to be less than 16 bytes. And shouldn't you use snprintf > in any event? > > Unlike Unix, I assume Windows has no way to have multiple "console" > devices, with stdout and stderr pointing to different devices? > > Is the console the only device that's FILE_TYPE_CHAR? Are there no > serial port devices or other devices that are also of that type? The Windows API doc says "LPT device or a console". The wiki's LPT section suggests it should also use IBM style extended ASCII cs, so I would assume it's fine to use the oem code page, if there is any > LPT usage. * LPT* (Line Print Terminal or Local Print Terminal) is the original, and still common, name of the parallel port interface on IBM PC-compatible computers . It was designed to operate a text printer that used IBM 's 8-bit extended ASCII character set . -Sherman > > Can you detect the case of creating an InputStreamReader using the > default encoding, wrapped around the InputStream from System.in > that refers to the console? If so, it might be good to handle that > case as well, although at this point I would consider that to be > "extra credit"! :-) From Ulf.Zibis at gmx.de Mon Feb 13 23:15:22 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 14 Feb 2012 00:15:22 +0100 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F39966D.4000804@oracle.com> References: <4F394A24.5040508@oracle.com> <4F395338.7090803@gmx.de> <4F3957EF.5070200@oracle.com> <4F397EB2.6050507@gmx.de> <4F39966D.4000804@oracle.com> Message-ID: <4F39998A.2000704@gmx.de> Sherman, thanks for your additional explanation. One nit more... Why you use the "sun." prefix? I think, "stdout.encoding" "stderr.encoding" would be enough + nicer. In some years, nobody will have any association with 'sun'. On the other hand, it would be more true to use: "windows.stdout.encoding" "windows.stderr.encoding" -Ulf Am 14.02.2012 00:02, schrieb Xueming Shen: > > To have separate sun.stdout.encoding and sun.stderr.encoding is mainly because of implementation > convenience. I need three things from the native (1) is std.out tty (2) is std.err tty (3) the > console > encoding if (1) or (2) are true, and I tried to avoid to go down to native multiple times it appears > passing back two encoding name is the easiest approach. The original plan was to remove them after > use, maybe via sun.misc.VM.saveAndRemoveProperties() (or simply remove them directly), but then > thought the info might be useful... > > Auto detect the encoding of InputStreamReader when it is attached the console is nice to have, but > I would try to avoid doing that until I have to, before that I would still advise the use of > java.io.Console > class:-) > > -Sherman > >> >>>> Why are there theoretically different code pages for stdout and stderr? >>> >>> you can re-direct std err to a log file file but keep the std out to the console, or re-direct >>> the std out but keep the std.err to the console, in these scenario, the stderr and stdout >>> will use different code page. Basically the approach is that if the otuput stream gets >>> re-directed, it keeps using the default charset (with the assumption that the rest of the >>> world is using the Windows codepage), if not, use the oem codepage from the console >>> on Windows, to make sure the System.out/err outputs the bits that the underlying >>> console can understand. >> Oops, I'm not sure, if you didn't misunderstood me. >> I mean, why are there 2 different properties? : >> "sun.stdout.encoding" >> "sun.stderr.encoding" >> Shouldn't something be enough like >> "console.encoding" >> as counterpart to >> "file.encoding" >> ? >> >> -Ulf >> > From jeffhain at rocketmail.com Mon Feb 13 23:41:19 2012 From: jeffhain at rocketmail.com (Jeff Hain) Date: Mon, 13 Feb 2012 23:41:19 +0000 (GMT) Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <4F36A5E0.3060706@oracle.com> References: <4F36A5E0.3060706@oracle.com> Message-ID: <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> Hello. - It could be great to have versions of these methods that don't throw an ArithmeticException in case of overflow, but would return the closest value (XXX.MAX_VALUE or XXX.MIN_VALUE). ? A common use-case I see (and have) for this is when dealing with dates and durations (*), in which case Long.MAX_VALUE or such is so far that it's equal to use that instead of a theoretically higher deadline or timeout. ? The throwing methods could also be named "xxxInRange" (multiplyInRange, etc.), and the others "xxxToRange"(but non-throwing "toInt" method could be named "toIntRange", not to repeat the "to"). ? (I don't really like the term "exact", which supposes modulo arithmetic is not exact in its kind, and it doesn't contain the supposition that the result should be in range.) - Replacing current implementation of "Math.abs(int)" with "(value^(value>>31))-(value>>31)", and equivalent for "Math.abs(long)", seems to speeds things up nicely, which is interesting for so low-level treatments. ? These optimizations could be piggybacked along (unless there is a reason not to do them, which would explain why they haven't been done yet). - multiplyToRange(int,int) could be coded efficiently as "return (int)(x * (double)y);" (*) JodaTime uses throwing versions, but they do exact time arithmetic; I m talking about low-level timing treatments, like scheduling and such, which don't provide the results but just use them. ???? [BTW if the maintainer reads this, JodaTime's FieldUtils.safeMultiply(long,long) doesn't handle (Long.MIN_VALUE,-1)] Jeff ________________________________ De?: Roger Riggs ??: core-Libs-Dev Envoy? le : Samedi 11 f?vrier 2012 18h31 Objet?: Review: JDK 8 CR for Support Integer overflow updated Updated the webrev for CR6708398: ? ? ? ? http://cr.openjdk.java.net/~rriggs/6708398.2 - Added a paragraph to the class javadoc for Math and StrictMath to ? introduce the exact arithmetic methods and their uses. - Editorial correction to first sentence of each method to consistent use "Returns". - Added Tests for the StrictMath methods? (they are the same tests as for Math) Thanks, Roger From Ulf.Zibis at gmx.de Mon Feb 13 23:41:31 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 14 Feb 2012 00:41:31 +0100 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F3999C5.2010707@oracle.com> References: <4F394A24.5040508@oracle.com> <4F395F7F.6000509@oracle.com> <4F3999C5.2010707@oracle.com> Message-ID: <4F399FAB.8080204@gmx.de> > On 2/13/2012 11:07 AM, Bill Shannon wrote: > >> Can you detect the case of creating an InputStreamReader using the >> default encoding, wrapped around the InputStream from System.in >> that refers to the console? If so, it might be good to handle that >> case as well, although at this point I would consider that to be >> "extra credit"! :-) From a nitpickers point of view it should, as bug 4153167 evaluation states: Will investiage the possibility of use cmd/console encoding (OEM by default on Windows) for System.in/err when the System.in/out is attached to a real "terminal" when jvm is started, in jdk8 timeframe -Ulf From Ulf.Zibis at gmx.de Mon Feb 13 23:55:42 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 14 Feb 2012 00:55:42 +0100 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> References: <4F36A5E0.3060706@oracle.com> <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> Message-ID: <4F39A2FE.3090404@gmx.de> Am 14.02.2012 00:41, schrieb Jeff Hain: > (I don't really like the term "exact", which supposes modulo arithmetic is not exact in its kind, and it doesn't contain the supposition that the result should be in range.) +1 -Ulf From jim.holmlund at sun.com Tue Feb 14 00:02:52 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Tue, 14 Feb 2012 00:02:52 +0000 Subject: hg: jdk8/tl/langtools: 7142672: Problems with the value passed to the 'classes' param of JavaCompiler.CompilationTask.getTask(...) Message-ID: <20120214000256.8A6B1474B4@hg.openjdk.java.net> Changeset: 237198ef45f5 Author: jjh Date: 2012-02-13 16:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/237198ef45f5 7142672: Problems with the value passed to the 'classes' param of JavaCompiler.CompilationTask.getTask(...) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/T7142672/AnnoProcessor.java + test/tools/javac/T7142672/Bug.java + test/tools/javac/T7142672/Test2.java + test/tools/javac/T7142672/Test3.java From stuart.marks at oracle.com Tue Feb 14 01:00:07 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 13 Feb 2012 17:00:07 -0800 Subject: Warning Fixes from LJC Hack Session In-Reply-To: References: <4F2A6213.4040707@oracle.com> <4F2CE850.9090604@oracle.com> <4F348ACC.7020707@oracle.com> Message-ID: <4F39B217.7050300@oracle.com> Great, I've pushed in the remaining changes: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445ada5e6b4a >> I hope these patches are providing value for the OpenJDK team as we >> plan to do more. I know that there is a bit of a cost for you guys >> in terms of reviewing and merging. I'm starting to get a better >> picture of the type of changes that will go in smoothly and those that >> will require updates to the patches. Yes, I think this activity is of net value, for a couple reasons. One, it is a goal to reduce the number of warnings in the system. It's not the highest priority, but it is a goal. So these changes directly impact the quality of the code base. Two, community-building is important too. It's worth a couple hours of time to help get you guys generating clean changes and to get them pushed. It might take me the better part of a week to find that hour or two, so I hope you can live with that. :-) And thanks to Chris Hegarty for jumping in and handling the awt/beans/printing hunk of patches. s'marks On 2/9/12 7:58 PM, Michael Barker wrote: > Hi Stuart, > > Thank you for the reviewing the patches. I forgot about the > Contributed-by header, sorry about that. That's one I'll put on the > list to make sure I have sorted next time. I've split the > contributors up according to the two patches supplied. See below: > > AWT, beans& printing: > > Contributed-by: Prasannaa, Martijn Verburg > , Goerge Albrecht, > Graham Allan, Iordanis Giannakakis > , Jose Llarena, > Abraham Mar?n P?rez > > For all of the remaining code: > > Contributed-by: Mani Sarkar, Michael Barker > , Carl Jokl, Dinuk > Weerasinghe, Markus Stoy > , Tom Anderson > > > Mike. > > On Fri, Feb 10, 2012 at 3:11 AM, Stuart Marks wrote: >> Hi Mike, >> >> I finally got back to this. These fixes look pretty good and knock off 100+ >> additional warnings! I've filed bug 7143230 [1] to track this. I took a look >> through the code and I took the liberty of fixing up a few very minor >> things: >> >> 1. Removed unnecessary casts to ZipEntry in JarVerifier.java, suggested by >> Chirs Hegarty [2]. (These aren't strictly redundant casts, and don't cause >> warnings, as the origin types are and JarEntry. >> However, they are unnecessary.) >> >> 2. Fixed typo in unrelated comment at line 50 in SignatureFile.java that I >> happened to notice. >> >> 3. Removed parentheses from expressions in MemoryMonitor.java lines 216, 219 >> which are now unnecessary since the cast has been removed. >> >> No need to issue another patch; I'll just include these changes when I push >> the changeset. >> >> Which brings me to the topic that we discussed before when I pushed LJC's >> previous round of warnings fixes, that is, how the Contributed-by line in >> the commit message should be formatted. (See [3] for the requirements.) For >> reference, here's what the changeset comment for the previous set of LJC >> fixes ended up looking like: >> >> >> changeset: 4802:4f0f9f9c4892 >> user: smarks >> date: Wed Dec 07 12:12:50 2011 -0800 >> description: >> 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip >> Reviewed-by: alanb, dholmes, forax, sherman, smarks >> Contributed-by: Prasannaa, Martijn Verburg >> , Goerge_Albrecht, >> Graham Allan, Michael Barker >> >> >> >> It looks like a different set of people contributed to this round of fixes. >> If you could send me the list of names and email addresses, I can format >> them into the commit message and push the fix. >> >> Thanks! >> >> s'marks >> >> >> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143230 >> >> [2] >> http://mail.openjdk.java.net/pipermail/jdk8-dev/2012-February/000715.html >> >> [3] http://openjdk.java.net/guide/producingChangeset.html >> >> >> On 2/4/12 12:12 AM, Chris Hegarty wrote: >>> >>> Thanks for this, looks great. >>> >>> Good to see JarVerifier getting some much needed TLC. >>> >>> -Chris. >>> >>> >>> On 02/ 4/12 07:50 AM, Michael Barker wrote: >>>>> >>>>> I see R?mi has suggested a slice& dice but I think that's a bit too much >>>>> work for the changes involved. Instead I would suggest a simple split, >>>>> send >>>>> the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything else >>>>> to >>>>> core-libs-dev. >>>> >>>> >>>> Attached is the patch that contains "everthing else" from LJC warning >>>> fixes hack session. >>>> >>>> Mike. From frederic.parain at oracle.com Tue Feb 14 11:01:19 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 14 Feb 2012 12:01:19 +0100 Subject: Request for Review: 7144833 sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Message-ID: <4F3A3EFF.7030306@oracle.com> This is a request for review for 7144833: sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144833 The problem occurs when one or several lines printed by the jcmd tool match several rules in the awk script checking the output. The counter counting the number of lines matching the expected pattern is incremented each time the line matches a rule. If the line matches several rules, the counter is incremented several times. When this occurs, the test at the end of the script checking that the number of lines matching the pattern is equal to the number of lines of the output fails. The proposed fix is a modification of the awk script. Each rule checking a pattern now sets a variable to 1 when a match is found, and the variable is added to the counter only once per line. Here's the Webrev: http://cr.openjdk.java.net/~fparain/7144833/webrev.00/ The webrev also contains the removal of the sun/tools/jps/jps-Vvml.sh test from the problem list. The test has been fixed (see CR 6986875) but the test was still in the exclusion list. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From vincent.x.ryan at oracle.com Tue Feb 14 11:48:04 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 14 Feb 2012 11:48:04 +0000 Subject: hg: jdk8/tl/jdk: 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc Message-ID: <20120214114829.7A0B1474C0@hg.openjdk.java.net> Changeset: f62077973f9b Author: vinnie Date: 2012-02-14 11:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f62077973f9b 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc Reviewed-by: xuelei ! test/sun/security/tools/jarsigner/ec.sh From jeffhain at rocketmail.com Tue Feb 14 20:08:11 2012 From: jeffhain at rocketmail.com (Jeff Hain) Date: Tue, 14 Feb 2012 20:08:11 +0000 (GMT) Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> References: <4F36A5E0.3060706@oracle.com> <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> Message-ID: <1329250091.95225.YahooMailNeo@web132105.mail.ird.yahoo.com> For "toInt" method(s), and other methods that don't involve mathematical operations but just transtyping, I think the naming conventions I was talking about (xxxInRange/xxxToRange for add/substract/multiply/negate/increment/etc.) don't need to apply. One could just use "asInt" for the throwing version, and "toInt" for the non-throwing version. "toInt" can also be interpreted as "to int range" (and not only "to int type"), which matches what it would do then, and "toInt" is also the first method name that comes to mind when wanting to cast a long to an int, as one can cast a double to an int (or to a long), which in Java also does not throw an exception if the specified value is out of range, but returns the closest one. Jeff From Roger.Riggs at oracle.com Tue Feb 14 21:01:19 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 14 Feb 2012 16:01:19 -0500 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> References: <4F36A5E0.3060706@oracle.com> <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> Message-ID: <4F3ACB9F.2020601@oracle.com> On 02/13/2012 06:41 PM, Jeff Hain wrote: > Hello. > > - It could be great to have versions of these methods that don't throw an ArithmeticException in case of overflow, but would return the closest value (XXX.MAX_VALUE or XXX.MIN_VALUE). > A common use-case I see (and have) for this is when dealing with dates and durations (*), in which case Long.MAX_VALUE or such is so far that it's equal to use that instead of a theoretically higher deadline or timeout. Saturating arithmetic can be useful but there have been few requests. > The throwing methods could also be named "xxxInRange" (multiplyInRange, etc.), and the others "xxxToRange"(but non-throwing "toInt" method could be named "toIntRange", not to repeat the "to"). > (I don't really like the term "exact", which supposes modulo arithmetic is not exact in its kind, and it doesn't contain the supposition that the result should be in range.) Choosing names can be difficult to get the right meaning. I don't see these are an improvement. The current xxxExact naming reflected similar use in BigDecimal. In your subsequent email, I found that the asXXX and toXXX variants to be too similar to make it clear which throws and which does not or other differences unless it were a pervasive pattern that all developers would know and use. > > > - Replacing current implementation of "Math.abs(int)" with "(value^(value>>31))-(value>>31)", and equivalent for "Math.abs(long)", seems to speeds things up nicely, which is interesting for so low-level treatments. > These optimizations could be piggybacked along (unless there is a reason not to do them, which would explain why they haven't been done yet). Interesting, my impression from some trials was the Hotspot already had some speedup for abs(). > > - multiplyToRange(int,int) could be coded efficiently as "return (int)(x * (double)y);" > > (*) JodaTime uses throwing versions, but they do exact time arithmetic; I m talking about low-level timing treatments, like scheduling and such, which don't provide the results but just use them. > [BTW if the maintainer reads this, JodaTime's FieldUtils.safeMultiply(long,long) doesn't handle (Long.MIN_VALUE,-1)] Thanks, Roger > > Jeff > > > > ________________________________ > De : Roger Riggs > ? : core-Libs-Dev > Envoy? le : Samedi 11 f?vrier 2012 18h31 > Objet : Review: JDK 8 CR for Support Integer overflow updated > > Updated the webrev for CR6708398: > http://cr.openjdk.java.net/~rriggs/6708398.2 > - Added a paragraph to the class javadoc for Math and StrictMath to > introduce the exact arithmetic methods and their uses. > - Editorial correction to first sentence of each method to consistent use "Returns". > - Added Tests for the StrictMath methods (they are the same tests as for Math) > > Thanks, Roger From jeffhain at rocketmail.com Tue Feb 14 22:20:27 2012 From: jeffhain at rocketmail.com (Jeff Hain) Date: Tue, 14 Feb 2012 22:20:27 +0000 (GMT) Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <4F3ACB9F.2020601@oracle.com> References: <4F36A5E0.3060706@oracle.com> <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> <4F3ACB9F.2020601@oracle.com> Message-ID: <1329258027.31290.YahooMailNeo@web132105.mail.ird.yahoo.com> >Saturating arithmetic can be useful but there have been few requests. Some needs can be unformulated until someone fulfils them :) But indeed not being hit by integer/modulo arithmetic while still being exact is surely a more common need than "jumping" to the closest value. I must be biased due to mostly using the later. >Choosing names can be difficult to get the right meaning. I don't see these are an improvement. Indeed "exact" can be understood as "mathematically exact", and it's concise. The main problem I see with "exact" is if wanting to add some non-throwing version afterwards: it should have a close but different name, and I don't see how if using "xxxExact". But if such methods shall never be added, it's all right. >In your subsequent email, I found that the asXXX and toXXX variants to be too similar to >make it clear which throws and which does not or other differences unless it were a pervasive >pattern that all developers would know and use. I had in mind that "as" contained an idea of identity, and "to" an idea of movement/change, so that "asInt" implies that the value does not change (throws if out of range) and "toInt" that it could change, but maybe that's only true in my (too low) english :) >Interesting, my impression from some trials was the Hotspot already had some speedup for abs(). Hotspot doesn't seem to always use its speedup then, or it's not as good, or it (or my CPU) has even better speedups for bits shifts :) Jeff PS: About JodaTime I said "if the maintainer reads this": I had in mind it was someone used to this list, but of course it's Stephen :) From maurizio.cimadamore at oracle.com Tue Feb 14 23:54:11 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 14 Feb 2012 23:54:11 +0000 Subject: hg: jdk8/tl/langtools: 7142086: performance problem in Check.checkOverrideClashes(...) Message-ID: <20120214235415.85ADC474DA@hg.openjdk.java.net> Changeset: 84b61130cbed Author: mcimadamore Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84b61130cbed 7142086: performance problem in Check.checkOverrideClashes(...) Summary: Code in Check.checkOverrideClashes() causes too many calls to MethodSymbol.overrides Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/7142086/T7142086.java From brian.goetz at oracle.com Wed Feb 15 05:07:52 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 Feb 2012 21:07:52 -0800 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <4F3ACB9F.2020601@oracle.com> References: <4F36A5E0.3060706@oracle.com> <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> <4F3ACB9F.2020601@oracle.com> Message-ID: > In your subsequent email, I found that the asXXX and toXXX variants to be too similar to > make it clear which throws and which does not or other differences unless it were a pervasive > pattern that all developers would know and use. We encourage this convention: - Use "asXxx" to describe creating an Xxx view of the object; - Use "toXxx" to describe converting the object to an Xxx. There are two dimensions along which you might make the distinction: - If the object is mutable, a view would reflect state changes to the original, whereas a conversion would not (e.g., HashMap.values()); - Regardless of mutability, "as" suggests a more or less trivial operation (casting, wrapping with a trivial wrapper such as Collections.immutableSet), whereas "to" suggests a heavier operation that involves copying the data (StringBuffer.toString, List.toArray). In general, "as" operations are perceived as cheaper than "to" operations. From Alan.Bateman at oracle.com Wed Feb 15 09:04:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2012 09:04:27 +0000 Subject: Request for Review: 7144833 sun/tools/jcmd/jcmd-Defaults.sh failing intermittently In-Reply-To: <4F3A3EFF.7030306@oracle.com> References: <4F3A3EFF.7030306@oracle.com> Message-ID: <4F3B751B.5080803@oracle.com> On 14/02/2012 11:01, Frederic Parain wrote: > This is a request for review for 7144833: > sun/tools/jcmd/jcmd-Defaults.sh failing intermittently > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144833 > > The problem occurs when one or several lines printed by the jcmd tool > match several rules in the awk script checking the output. The counter > counting the number of lines matching the expected pattern is > incremented each time the line matches a rule. If the line matches > several rules, the counter is incremented several times. When this > occurs, the test at the end of the script checking that the number > of lines matching the pattern is equal to the number of lines of the > output fails. > > The proposed fix is a modification of the awk script. Each rule > checking a pattern now sets a variable to 1 when a match is found, > and the variable is added to the counter only once per line. > > Here's the Webrev: > > http://cr.openjdk.java.net/~fparain/7144833/webrev.00/ > > The webrev also contains the removal of the sun/tools/jps/jps-Vvml.sh > test from the problem list. The test has been fixed (see CR 6986875) > but the test was still in the exclusion list. Looks good to me although you might want to check the indentation in the BEGIN block. Also thanks for updating the ProblemList file. -Alan From frederic.parain at oracle.com Wed Feb 15 10:20:18 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 15 Feb 2012 10:20:18 +0000 Subject: hg: jdk8/tl/jdk: 7140868: TEST_BUG: jcmd tests need to use -XX:+UsePerfData Message-ID: <20120215102030.50B12474E7@hg.openjdk.java.net> Changeset: 13aef38438d8 Author: fparain Date: 2012-02-14 07:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13aef38438d8 7140868: TEST_BUG: jcmd tests need to use -XX:+UsePerfData Reviewed-by: fparain, dholmes ! test/sun/tools/jcmd/jcmd-Defaults.sh ! test/sun/tools/jcmd/jcmd-f.sh ! test/sun/tools/jcmd/jcmd-help-help.sh ! test/sun/tools/jcmd/jcmd-help.sh ! test/sun/tools/jcmd/jcmd-pid.sh From frederic.parain at oracle.com Wed Feb 15 10:22:42 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 15 Feb 2012 11:22:42 +0100 Subject: Request for Review: 7144833 sun/tools/jcmd/jcmd-Defaults.sh failing intermittently In-Reply-To: <4F3B751B.5080803@oracle.com> References: <4F3A3EFF.7030306@oracle.com> <4F3B751B.5080803@oracle.com> Message-ID: <4F3B8772.8050407@oracle.com> Thanks Alan, I've fixed the indentation in the BEGIN block. Fred On 02/15/12 10:04 AM, Alan Bateman wrote: > On 14/02/2012 11:01, Frederic Parain wrote: >> This is a request for review for 7144833: >> sun/tools/jcmd/jcmd-Defaults.sh failing intermittently >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144833 >> >> The problem occurs when one or several lines printed by the jcmd tool >> match several rules in the awk script checking the output. The counter >> counting the number of lines matching the expected pattern is >> incremented each time the line matches a rule. If the line matches >> several rules, the counter is incremented several times. When this >> occurs, the test at the end of the script checking that the number >> of lines matching the pattern is equal to the number of lines of the >> output fails. >> >> The proposed fix is a modification of the awk script. Each rule >> checking a pattern now sets a variable to 1 when a match is found, >> and the variable is added to the counter only once per line. >> >> Here's the Webrev: >> >> http://cr.openjdk.java.net/~fparain/7144833/webrev.00/ >> >> The webrev also contains the removal of the sun/tools/jps/jps-Vvml.sh >> test from the problem list. The test has been fixed (see CR 6986875) >> but the test was still in the exclusion list. > Looks good to me although you might want to check the indentation in the > BEGIN block. > > Also thanks for updating the ProblemList file. > > -Alan -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From sean.mullan at oracle.com Wed Feb 15 13:02:08 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 15 Feb 2012 13:02:08 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120215130235.9079D474EA@hg.openjdk.java.net> Changeset: 0720542d6c1e Author: mullan Date: 2012-02-15 07:45 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0720542d6c1e 7024604: OID.1 causes IAE in X500Principal constructor Reviewed-by: vinnie ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/auth/x500/package.html ! test/javax/security/auth/x500/X500Principal/Parse.java Changeset: 3207b3e271f2 Author: mullan Date: 2012-02-15 07:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3207b3e271f2 Merge From Alan.Bateman at oracle.com Wed Feb 15 15:00:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2012 15:00:05 +0000 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F394A24.5040508@oracle.com> References: <4F394A24.5040508@oracle.com> Message-ID: <4F3BC875.9000005@oracle.com> On 13/02/2012 17:36, Xueming Shen wrote: > : > > The webrev is at > > http://cr.openjdk.java.net/~sherman/4153167/webrev > The changes look reasonable to me and looks like you have all the combinations of redirection covered. I'm not sure about the sun.std*.encoding properties as folks will find them. Probably okay for now. Minor comments - in System.java then it might be better to name the method newPrintStream. It would also be good to add a comment block to that method. In java_props_md.c then I agree with Bill's comment that you don't need 64 bytes. Minor nit is that you don't need spaces are both sides of the *. -Alan. From ahughes at redhat.com Wed Feb 15 17:01:07 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 15 Feb 2012 12:01:07 -0500 (EST) Subject: 7121110 : JAXP 1.4.5 update 1 for 7u4 & jaxp source in jdk7 repo In-Reply-To: <4EFA0CA8.2000204@oracle.com> Message-ID: ----- Original Message ----- > Thanks Kelly! > Only just saw all this now I'm imported jdk7u4 into IcedTea7. Good news! Glad you decided to join us with having the source in tree! > Indeed, that was the original intention when you designed the bundle > process. Besides the unfortunate download problem, it actually works > great in terms of guaranteeing that we have one single editable > source. > I've never understood why editability is an issue. Surely, all patches have to be reviewed (and for 6 and 7 release trees, approved by the release manager), so if you don't want a change to be made, you can just not approve it. Where's the issue? > Next, maybe we could start to work on migrating the jaxp project > source > into the jdk. But it's the holiday season, we don't have to think too > hard :). In the meantime, we just have to make sure patches are > applied > to the jaxp project first (through JIRA report for example) since > that's > how our dev/test process is set up. This sounds good. Is it planned for jaxws too? How about CORBA? With IcedTea we've had to hack things in the build to work around the fact that these repos depend on stuff in the JDK, so having just the three repositories (langtools, hotspot and jdk) would be great! > > --Joe > > On 12/24/2011 8:56 AM, Kelly O'Hair wrote: > > Looks great to me. > > > > There is still the issue of making sure the right people (like you > > :^) are the ones patching this code, so we know > > what we have matches the public JAXP project. > > > > -kto > > > > On Dec 23, 2011, at 1:27 PM, Joe Wang wrote: > > > >> Hi All, > >> > >> We have prepared a jaxp update for 7u4. The listed changes have > >> been posted to the jdk7u-dev alias with "7u4 Request for approval > >> for CR 7121110 - JAXP 1.4.5 update 1 for 7u4". > >> > >> With this update, we are adding jaxp sources back into the jdk7 > >> repository, which means we are abandoning the jaxp bundle > >> download process. This is a significant change. We'd like to hear > >> if you have any concerns. If no objection, we'd like to push the > >> change within the next week. > >> > >> The webrev is here: > >> http://cr.openjdk.java.net/~joehw/jaxp145u1-changeset/webrev/ > >> > >> Thanks, > >> Joe > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Wed Feb 15 17:23:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2012 17:23:15 +0000 Subject: 7145910: Remove dependency on apt and com.sun.mirror API (breaks boot cycle builds). Message-ID: <4F3BEA03.9040202@oracle.com> The current JAX-WS has a residual dependency on com.sun.mirror that breaks SKIP_BOOT_CYCLE=false builds. There's a new code drop that fixes this so I need to change the bundle name to pick it up. Can I get a quick review of this so that I can pushed it - thanks. diff --git a/jaxws.properties b/jaxws.properties --- a/jaxws.properties +++ b/jaxws.properties @@ -25,8 +25,8 @@ drops.master.copy.base=${drops.dir} -jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11.zip -jaxws_src.bundle.md5.checksum=90aa4ed0818f19561f32b81e2ae02dc8 +jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11-patched.zip +jaxws_src.bundle.md5.checksum=005b93d1a2d6e66438c3c84c49c10b13 jaxws_src.master.bundle.dir=${drops.master.copy.base} jaxws_src.master.bundle.url.base=http://download.java.net/glassfish/components/jax-ws/openjdk/jdk8 From kelly.ohair at oracle.com Wed Feb 15 17:29:08 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 15 Feb 2012 09:29:08 -0800 Subject: 7145910: Remove dependency on apt and com.sun.mirror API (breaks boot cycle builds). In-Reply-To: <4F3BEA03.9040202@oracle.com> References: <4F3BEA03.9040202@oracle.com> Message-ID: Change looks fine, but the jax-ws team needs to place this zip bundle at http://download.java.net/glassfish/components/jax-ws/openjdk/jdk8 -kto On Feb 15, 2012, at 9:23 AM, Alan Bateman wrote: > > The current JAX-WS has a residual dependency on com.sun.mirror that breaks SKIP_BOOT_CYCLE=false builds. There's a new code drop that fixes this so I need to change the bundle name to pick it up. > > Can I get a quick review of this so that I can pushed it - thanks. > > > diff --git a/jaxws.properties b/jaxws.properties > --- a/jaxws.properties > +++ b/jaxws.properties > @@ -25,8 +25,8 @@ > > drops.master.copy.base=${drops.dir} > > -jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11.zip > -jaxws_src.bundle.md5.checksum=90aa4ed0818f19561f32b81e2ae02dc8 > +jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11-patched.zip > +jaxws_src.bundle.md5.checksum=005b93d1a2d6e66438c3c84c49c10b13 > jaxws_src.master.bundle.dir=${drops.master.copy.base} > jaxws_src.master.bundle.url.base=http://download.java.net/glassfish/components/jax-ws/openjdk/jdk8 > From frederic.parain at oracle.com Wed Feb 15 17:29:42 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 15 Feb 2012 17:29:42 +0000 Subject: hg: jdk8/tl/jdk: 7144833: sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Message-ID: <20120215173008.2669A474F4@hg.openjdk.java.net> Changeset: 59884f656b7d Author: fparain Date: 2012-02-15 09:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59884f656b7d 7144833: sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Reviewed-by: alanb ! test/ProblemList.txt ! test/sun/tools/jcmd/jcmd_Output1.awk From Alan.Bateman at oracle.com Wed Feb 15 17:30:33 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2012 17:30:33 +0000 Subject: 7145910: Remove dependency on apt and com.sun.mirror API (breaks boot cycle builds). In-Reply-To: References: <4F3BEA03.9040202@oracle.com> Message-ID: <4F3BEBB9.9080104@oracle.com> On 15/02/2012 17:29, Kelly O'Hair wrote: > Change looks fine, but the jax-ws team needs to place this zip bundle at > http://download.java.net/glassfish/components/jax-ws/openjdk/jdk8 > > -kto > It's there's: http://dlc.sun.com.edgesuite.net/glassfish/components/jax-ws/openjdk/jdk8/jdk8-jaxws-2_2-SNAPSHOT-2012_01_11-patched.zip and it's just that the download servers don't refresh their directory lists very often. -Alan From forax at univ-mlv.fr Wed Feb 15 17:34:09 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 15 Feb 2012 18:34:09 +0100 Subject: java.io.File field "path" is not declared final In-Reply-To: References: Message-ID: <4F3BEC91.3060308@univ-mlv.fr> Reported by a user on the concurrency-interest mailing list, File field "path" is not declared final but should be. cheers, R?mi -------- Original Message -------- Subject: [concurrency-interest] File object is not immutable? Date: Wed, 15 Feb 2012 19:00:59 +0400 From: Ruslan Cheremin To: concurrency-interest at cs.oswego.edu I was very surprised to see that field "path" in java.io.File is not final. I was treating File object in concurrency area is something like String -- fully immutable, and completely thread-safe, even data-race safe. Am I right supposing that File object is _not_ thread safe by itself (as String does), and it is programmer's responsibility to safe publish it between threads? Or may be it is some kind of hidden magic, which makes File safe, even without explicit final? I mean, there is native calls to FileSystem in constructor and deserialization, which can create membars implictly... ---- Cheremin Ruslan On 02/15/2012 06:15 PM, Alan Bateman wrote: > On 15/02/2012 17:14, R?mi Forax wrote: >> >> The javadoc says File is immutable so it's a bug :( >> There is no guarantee that the fs object will do a memory barrier. >> >> I think path is not final because of the serialization code but >> it should be final and the seralization code should use >> reflection or sun.misc.Unsafe. >> >> I've put Alan Bateman in CC because I don't know if java.io.File is >> managed by the core team or the nio one. >> > Definitely bring it up on core-libs-dev as we should change it to be > final. > > -Alan From alan.bateman at oracle.com Wed Feb 15 17:33:14 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 15 Feb 2012 17:33:14 +0000 Subject: hg: jdk8/tl/jaxws: 7145910: Remove dependency on apt and com.sun.mirror API (breaks boot cycle builds) Message-ID: <20120215173314.75D1F474F5@hg.openjdk.java.net> Changeset: b962e9c3eba2 Author: alanb Date: 2012-02-15 17:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b962e9c3eba2 7145910: Remove dependency on apt and com.sun.mirror API (breaks boot cycle builds) Reviewed-by: ohair ! jaxws.properties From kelly.ohair at oracle.com Wed Feb 15 17:52:45 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 15 Feb 2012 09:52:45 -0800 Subject: 7121110 : JAXP 1.4.5 update 1 for 7u4 & jaxp source in jdk7 repo In-Reply-To: References: Message-ID: <88CEE511-4720-4B5D-BEAD-ECB96D85DE94@oracle.com> On Feb 15, 2012, at 9:01 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Thanks Kelly! >> > > Only just saw all this now I'm imported jdk7u4 into IcedTea7. Good news! Glad you decided to join us with having the source in tree! Yeah... I know we had reasons for this drop zip stuff, but I want to crawl under a rock everytime it causes issues for people. :^( > >> Indeed, that was the original intention when you designed the bundle >> process. Besides the unfortunate download problem, it actually works >> great in terms of guaranteeing that we have one single editable >> source. >> > > I've never understood why editability is an issue. Surely, all patches have to be reviewed (and for 6 and 7 release trees, approved by the release manager), so if you don't want a change to be made, you can just not approve it. Where's the issue? The issue was that we had too many releases, too many people getting changes in and not notifying the jaxp or jaxws teams, and we had a series of regressions because of it. Back when we were using Teamware to manage the sources (SCCS based) it was also very difficult to understand what changes were made where, by who, and for what. Mercurial helped, open sourcing helped, and now Joe Wang is part of the jdk team (a welcome addition). So the planets have re-aligned and we need to undo the drop zip madness I created. My apologies for the pains. :^( > >> Next, maybe we could start to work on migrating the jaxp project >> source >> into the jdk. But it's the holiday season, we don't have to think too >> hard :). In the meantime, we just have to make sure patches are >> applied >> to the jaxp project first (through JIRA report for example) since >> that's >> how our dev/test process is set up. > > This sounds good. Is it planned for jaxws too? How about CORBA? > With IcedTea we've had to hack things in the build to work around the fact that these repos depend on stuff in the JDK, so > having just the three repositories (langtools, hotspot and jdk) would be great! First things first.. I'd like to pull the sources back into the jaxp and jaxws repos first. Solve the drop zip bundle stuff first. CORBA does not have drop zip bundles. There were other reasons for separating out jaxp, jaxws, and corba from the rest of the jdk. If we determine that the need is no longer there, then we can undo it. I originally wanted to make it easier for these jaxp, jaxws, and corba teams to update their components of the jdk, so we got more updates, more reliable updates, tracked the updates, and easier updates. These teams were not jdk developers back then, and the integration of new versions into the jdk was horribly painful for them. I think in general most jdk developers do not care about or need to see or work with the jaxp, jaxws, or corba sources. They are separate beasts, and that was why we separated them. It was a huge batch of source that was taken out of the normal jdk developer's domain. They were often updated separately, they had their own versions, they had their own teams and releases. I wanted to make it easy to bring in a new component version, and just as easily back it out. Having them in separate repos has it's positives. -kto > >> >> --Joe >> >> On 12/24/2011 8:56 AM, Kelly O'Hair wrote: >>> Looks great to me. >>> >>> There is still the issue of making sure the right people (like you >>> :^) are the ones patching this code, so we know >>> what we have matches the public JAXP project. >>> >>> -kto >>> >>> On Dec 23, 2011, at 1:27 PM, Joe Wang wrote: >>> >>>> Hi All, >>>> >>>> We have prepared a jaxp update for 7u4. The listed changes have >>>> been posted to the jdk7u-dev alias with "7u4 Request for approval >>>> for CR 7121110 - JAXP 1.4.5 update 1 for 7u4". >>>> >>>> With this update, we are adding jaxp sources back into the jdk7 >>>> repository, which means we are abandoning the jaxp bundle >>>> download process. This is a significant change. We'd like to hear >>>> if you have any concerns. If no objection, we'd like to push the >>>> change within the next week. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~joehw/jaxp145u1-changeset/webrev/ >>>> >>>> Thanks, >>>> Joe >> > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > From frederic.parain at oracle.com Wed Feb 15 18:47:40 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 15 Feb 2012 18:47:40 +0000 Subject: hg: jdk8/tl/jdk: 7145925: Removing remote access to diagnostic commands in the HotSpotDiagnosticMBean Message-ID: <20120215184750.89476474F9@hg.openjdk.java.net> Changeset: 20d39a0e6fdc Author: fparain Date: 2012-02-15 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/20d39a0e6fdc 7145925: Removing remote access to diagnostic commands in the HotSpotDiagnosticMBean Reviewed-by: acorn, mchung, phh ! make/java/management/mapfile-vers - src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java - src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/native/sun/management/HotSpotDiagnostic.c - test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java From weijun.wang at oracle.com Thu Feb 16 01:55:11 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 16 Feb 2012 09:55:11 +0800 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3BEC91.3060308@univ-mlv.fr> References: <4F3BEC91.3060308@univ-mlv.fr> Message-ID: <4F3C61FF.3010106@oracle.com> It's almost final. That field is only changed in readObject(), which is effectively a constructor. Max On 02/16/2012 01:34 AM, R?mi Forax wrote: > Reported by a user on the concurrency-interest mailing list, > File field "path" is not declared final but should be. > > cheers, > R?mi > > -------- Original Message -------- > Subject: [concurrency-interest] File object is not immutable? > Date: Wed, 15 Feb 2012 19:00:59 +0400 > From: Ruslan Cheremin > To: concurrency-interest at cs.oswego.edu > > > > I was very surprised to see that field "path" in java.io.File is not > final. I was treating File object in concurrency area is something > like String -- fully immutable, and completely thread-safe, even > data-race safe. > > Am I right supposing that File object is _not_ thread safe by itself > (as String does), and it is programmer's responsibility to safe > publish it between threads? Or may be it is some kind of hidden magic, > which makes File safe, even without explicit final? I mean, there is > native calls to FileSystem in constructor and deserialization, which > can create membars implictly... > > > ---- > Cheremin Ruslan > > > On 02/15/2012 06:15 PM, Alan Bateman wrote: > >> On 15/02/2012 17:14, R?mi Forax wrote: >>> >>> The javadoc says File is immutable so it's a bug :( >>> There is no guarantee that the fs object will do a memory barrier. >>> >>> I think path is not final because of the serialization code but >>> it should be final and the seralization code should use >>> reflection or sun.misc.Unsafe. >>> >>> I've put Alan Bateman in CC because I don't know if java.io.File is >>> managed by the core team or the nio one. >>> >> Definitely bring it up on core-libs-dev as we should change it to be >> final. >> >> -Alan > From david.holmes at oracle.com Thu Feb 16 07:17:00 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Feb 2012 17:17:00 +1000 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3C61FF.3010106@oracle.com> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3C61FF.3010106@oracle.com> Message-ID: <4F3CAD6C.1030709@oracle.com> On 16/02/2012 11:55 AM, Weijun Wang wrote: > It's almost final. That field is only changed in readObject(), which is > effectively a constructor. Yes but because it is not final, if a File instance is shared and unsafely published then a thread using the File may see a wrong value for the path. People may wrongly assume that because the class is immutable that instances can be safely shared without needing to use safe publication. It's not clear to me that this is a class for which we need publication guarantees however. But clarifying that either way would be a good thing. David > Max > > On 02/16/2012 01:34 AM, R?mi Forax wrote: >> Reported by a user on the concurrency-interest mailing list, >> File field "path" is not declared final but should be. >> >> cheers, >> R?mi >> >> -------- Original Message -------- >> Subject: [concurrency-interest] File object is not immutable? >> Date: Wed, 15 Feb 2012 19:00:59 +0400 >> From: Ruslan Cheremin >> To: concurrency-interest at cs.oswego.edu >> >> >> >> I was very surprised to see that field "path" in java.io.File is not >> final. I was treating File object in concurrency area is something >> like String -- fully immutable, and completely thread-safe, even >> data-race safe. >> >> Am I right supposing that File object is _not_ thread safe by itself >> (as String does), and it is programmer's responsibility to safe >> publish it between threads? Or may be it is some kind of hidden magic, >> which makes File safe, even without explicit final? I mean, there is >> native calls to FileSystem in constructor and deserialization, which >> can create membars implictly... >> >> >> ---- >> Cheremin Ruslan >> >> >> On 02/15/2012 06:15 PM, Alan Bateman wrote: >> >>> On 15/02/2012 17:14, R?mi Forax wrote: >>>> >>>> The javadoc says File is immutable so it's a bug :( >>>> There is no guarantee that the fs object will do a memory barrier. >>>> >>>> I think path is not final because of the serialization code but >>>> it should be final and the seralization code should use >>>> reflection or sun.misc.Unsafe. >>>> >>>> I've put Alan Bateman in CC because I don't know if java.io.File is >>>> managed by the core team or the nio one. >>>> >>> Definitely bring it up on core-libs-dev as we should change it to be >>> final. >>> >>> -Alan >> From xuelei.fan at oracle.com Thu Feb 16 07:55:16 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 16 Feb 2012 07:55:16 +0000 Subject: hg: jdk8/tl/jdk: 7145837: a little performance improvement on the usage of SecureRandom Message-ID: <20120216075542.114C147516@hg.openjdk.java.net> Changeset: 45804d661008 Author: xuelei Date: 2012-02-15 23:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/45804d661008 7145837: a little performance improvement on the usage of SecureRandom Reviewed-by: chegar, wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java From Alan.Bateman at oracle.com Thu Feb 16 10:37:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2012 10:37:44 +0000 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3BEC91.3060308@univ-mlv.fr> References: <4F3BEC91.3060308@univ-mlv.fr> Message-ID: <4F3CDC78.2090405@oracle.com> On 15/02/2012 17:34, R?mi Forax wrote: > Reported by a user on the concurrency-interest mailing list, > File field "path" is not declared final but should be. Thanks for forwarding R?mi. I did reply on concurrency-interest but I forgot that my original subscription there was @sun.com. I've created a bug to track this: 7146152: File.path should be final It's something that should have been fixed a long time ago (it's always been non-final). It's just the readObject that requires work, to use unsafe as you suggest. -Alan From Roger.Riggs at oracle.com Thu Feb 16 16:05:01 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 16 Feb 2012 11:05:01 -0500 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <1329258027.31290.YahooMailNeo@web132105.mail.ird.yahoo.com> References: <4F36A5E0.3060706@oracle.com> <1329176479.89596.YahooMailNeo@web132104.mail.ird.yahoo.com> <4F3ACB9F.2020601@oracle.com> <1329258027.31290.YahooMailNeo@web132105.mail.ird.yahoo.com> Message-ID: <4F3D292D.8080701@oracle.com> On 02/14/2012 05:20 PM, Jeff Hain wrote: > Indeed "exact" can be understood as "mathematically exact", and it's > concise. The main problem I see with "exact" is if wanting to add some > non-throwing version afterwards: it should have a close but different > name, and I don't see how if using "xxxExact". But if such methods > shall never be added, it's all right. The methods would not be added, these methods are introduced *to* throw exceptions. The normal Java Language operators { *, +, -, (int) } are used if no exceptions are needed. From Roger.Riggs at oracle.com Thu Feb 16 16:09:13 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 16 Feb 2012 11:09:13 -0500 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <4F36A5E0.3060706@oracle.com> References: <4F36A5E0.3060706@oracle.com> Message-ID: <4F3D2A29.1040101@oracle.com> I don't anticipate making any more changes though a few of the comments deserve followup as a separate CR. Is there an OpenJDK committer who would commit? Thanks, Roger > Updated the webrev for CR6708398: > http://cr.openjdk.java.net/~rriggs/6708398.2 > From xueming.shen at oracle.com Thu Feb 16 16:23:17 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 16 Feb 2012 08:23:17 -0800 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <4F3D2A29.1040101@oracle.com> References: <4F36A5E0.3060706@oracle.com> <4F3D2A29.1040101@oracle.com> Message-ID: <4F3D2D75.7060902@oracle.com> I can do the commit. On 2/16/2012 8:09 AM, Roger Riggs wrote: > I don't anticipate making any more changes though a few of the > comments deserve followup as a separate CR. > > Is there an OpenJDK committer who would commit? > > Thanks, Roger > >> Updated the webrev for CR6708398: >> http://cr.openjdk.java.net/~rriggs/6708398.2 >> > From eamonn at mcmanus.net Thu Feb 16 19:14:32 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Thu, 16 Feb 2012 11:14:32 -0800 Subject: Review: JDK 8 CR for Support Integer overflow updated In-Reply-To: <4F3D2D75.7060902@oracle.com> References: <4F36A5E0.3060706@oracle.com> <4F3D2A29.1040101@oracle.com> <4F3D2D75.7060902@oracle.com> Message-ID: Reviewed-by: emcmanus ?amonn On 16 February 2012 08:23, Xueming Shen wrote: > I can do the commit. > > > On 2/16/2012 8:09 AM, Roger Riggs wrote: >> >> I don't anticipate making any more changes though a few of the >> comments deserve followup as a separate CR. >> >> Is there an OpenJDK committer who would commit? >> >> Thanks, Roger >> >>> Updated the webrev for CR6708398: >>> ? ? ? ? http://cr.openjdk.java.net/~rriggs/6708398.2 >>> >> > From xueming.shen at oracle.com Thu Feb 16 19:38:48 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 16 Feb 2012 19:38:48 +0000 Subject: hg: jdk8/tl/jdk: 6708398: Support integer overflow Message-ID: <20120216193906.57FC347522@hg.openjdk.java.net> Changeset: b971b51bec01 Author: sherman Date: 2012-02-16 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b971b51bec01 6708398: Support integer overflow Summary: Added add/sub/multiply/toIntExact methods to j.l.Math and StrictMath classes Reviewed-by: emcmanus Contributed-by: roger.riggs at oracle.com ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java + test/java/lang/Math/ExactArithTests.java + test/java/lang/StrictMath/ExactArithTests.java From xueming.shen at oracle.com Thu Feb 16 20:18:00 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 16 Feb 2012 12:18:00 -0800 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F3BC875.9000005@oracle.com> References: <4F394A24.5040508@oracle.com> <4F3BC875.9000005@oracle.com> Message-ID: <4F3D6478.3040606@oracle.com> Thanks Alan, webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/4153167/webrev -Sherman On 02/15/2012 07:00 AM, Alan Bateman wrote: > On 13/02/2012 17:36, Xueming Shen wrote: >> : >> >> The webrev is at >> >> http://cr.openjdk.java.net/~sherman/4153167/webrev >> > The changes look reasonable to me and looks like you have all the > combinations of redirection covered. > > I'm not sure about the sun.std*.encoding properties as folks will find > them. Probably okay for now. > > Minor comments - in System.java then it might be better to name the > method newPrintStream. It would also be good to add a comment block to > that method. In java_props_md.c then I agree with Bill's comment that > you don't need 64 bytes. Minor nit is that you don't need spaces are > both sides of the *. > > -Alan. > > > > > > From ysr1729 at gmail.com Thu Feb 16 20:42:45 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 16 Feb 2012 12:42:45 -0800 Subject: cost of Java "assert" when disabled? Message-ID: A Java language newbie question: Does anyone have any ballpark numbers on the cost (and its scaling) of peppering assert's in your Java code, but with asserts disabled (-da) ? In other words, is the disabled cost so vanishingly small that we need not think twice when using them, or should one be careful because the cost is non-negligible and can affect (bytecode) footprint or rutime performace even when switched off? thanks for any advice. -- ramki From Alan.Bateman at oracle.com Thu Feb 16 20:47:51 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2012 20:47:51 +0000 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F3D6478.3040606@oracle.com> References: <4F394A24.5040508@oracle.com> <4F3BC875.9000005@oracle.com> <4F3D6478.3040606@oracle.com> Message-ID: <4F3D6B77.1050706@oracle.com> On 16/02/2012 20:18, Xueming Shen wrote: > Thanks Alan, webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/4153167/webrev > > > -Sherman > This looks reasonable to me, will be interesting to see if anyone notices. -Alan. From david.holmes at oracle.com Thu Feb 16 23:15:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Feb 2012 09:15:39 +1000 Subject: cost of Java "assert" when disabled? In-Reply-To: References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> Message-ID: <4F3D8E1B.8000305@oracle.com> The corelibs side of things seems to have gotten dropped from the cc list - added back. On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: > Don't want to sidetrack this thread but I really wish javac had proper > conditional compilation support, which would make this issue mostly moot. But the whole point of Java assertions is to make them available at runtime. I seem to recall a very similar question only recently on the core-libs mailing list. So summary is: - Every assert requires checking if asserts are enabled - JIT Compiler can elide the checks - Presence of assert related bytecodes can impact JIT compiler inlining decisions David > Sent from my phone > > On Feb 16, 2012 5:14 PM, "John Rose" > wrote: > > On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: > >> I think one problem with them is that they count towards the >> inlining budget since their bytecodes still take up space. Not >> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. > > Optimized object code has (probably) no trace of the assertions > themselves, but as Vitaly said, they perturb the inlining budget. > Larger methods have a tendency to "discourage" the inliner from > inlining, causing more out-of-line calls and a rough net slowdown. > Currently, the non-executed bytecodes for assertions (which can be > arbitrarily complex) make methods look bigger than they really are. > This is (IMO) a bug in the inlining heuristics, which should be > fixed by examining inlining candidates with a little more care. > Since the escape analysis does a similar method summarization, > there isn't necessarily even a need for an extra pass over the methods. > > -- John > From vitalyd at gmail.com Thu Feb 16 23:40:04 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 16 Feb 2012 18:40:04 -0500 Subject: cost of Java "assert" when disabled? In-Reply-To: <4F3D8E1B.8000305@oracle.com> References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> <4F3D8E1B.8000305@oracle.com> Message-ID: The asserts can be enabled/disabled at startup time, but I don't consider that an advantage over conditional compilation. In fact, it's less convenient in some cases, e.g. you can't conditionally add/remove class fields, can't surround blocks of code with condition, etc. There are workarounds, but it's not ideal. C#/.Net have conditional compilation (conditional blocks + assert statements) and it's a handy tool and no need to worry about dead IL code causing opto issues - don't see a reason why java couldn't have done the same from the beginning. Sent from my phone On Feb 16, 2012 6:16 PM, "David Holmes" wrote: > The corelibs side of things seems to have gotten dropped from the cc list > - added back. > > On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: > >> Don't want to sidetrack this thread but I really wish javac had proper >> conditional compilation support, which would make this issue mostly moot. >> > > But the whole point of Java assertions is to make them available at > runtime. I seem to recall a very similar question only recently on the > core-libs mailing list. > > So summary is: > > - Every assert requires checking if asserts are enabled > - JIT Compiler can elide the checks > - Presence of assert related bytecodes can impact JIT compiler inlining > decisions > > David > > Sent from my phone >> >> On Feb 16, 2012 5:14 PM, "John Rose" > > wrote: >> >> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: >> >> I think one problem with them is that they count towards the >>> inlining budget since their bytecodes still take up space. Not >>> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. >>> >> >> Optimized object code has (probably) no trace of the assertions >> themselves, but as Vitaly said, they perturb the inlining budget. >> Larger methods have a tendency to "discourage" the inliner from >> inlining, causing more out-of-line calls and a rough net slowdown. >> Currently, the non-executed bytecodes for assertions (which can be >> arbitrarily complex) make methods look bigger than they really are. >> This is (IMO) a bug in the inlining heuristics, which should be >> fixed by examining inlining candidates with a little more care. >> Since the escape analysis does a similar method summarization, >> there isn't necessarily even a need for an extra pass over the methods. >> >> -- John >> >> From ysr1729 at gmail.com Fri Feb 17 00:39:48 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 16 Feb 2012 16:39:48 -0800 Subject: cost of Java "assert" when disabled? In-Reply-To: <4F3D8E1B.8000305@oracle.com> References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> <4F3D8E1B.8000305@oracle.com> Message-ID: Thanks to all for the prompt and enlightening discussion, and especially to David for the succinct summary. -- ramki On Thu, Feb 16, 2012 at 3:15 PM, David Holmes wrote: > The corelibs side of things seems to have gotten dropped from the cc list > - added back. > > > On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: > >> Don't want to sidetrack this thread but I really wish javac had proper >> conditional compilation support, which would make this issue mostly moot. >> > > But the whole point of Java assertions is to make them available at > runtime. I seem to recall a very similar question only recently on the > core-libs mailing list. > > So summary is: > > - Every assert requires checking if asserts are enabled > - JIT Compiler can elide the checks > - Presence of assert related bytecodes can impact JIT compiler inlining > decisions > > David > > Sent from my phone >> >> On Feb 16, 2012 5:14 PM, "John Rose" > > wrote: >> >> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: >> >> I think one problem with them is that they count towards the >>> inlining budget since their bytecodes still take up space. Not >>> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. >>> >> >> Optimized object code has (probably) no trace of the assertions >> themselves, but as Vitaly said, they perturb the inlining budget. >> Larger methods have a tendency to "discourage" the inliner from >> inlining, causing more out-of-line calls and a rough net slowdown. >> Currently, the non-executed bytecodes for assertions (which can be >> arbitrarily complex) make methods look bigger than they really are. >> This is (IMO) a bug in the inlining heuristics, which should be >> fixed by examining inlining candidates with a little more care. >> Since the escape analysis does a similar method summarization, >> there isn't necessarily even a need for an extra pass over the methods. >> >> -- John >> >> From david.holmes at oracle.com Fri Feb 17 01:27:36 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Feb 2012 11:27:36 +1000 Subject: cost of Java "assert" when disabled? In-Reply-To: References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> <4F3D8E1B.8000305@oracle.com> Message-ID: <4F3DAD08.9020502@oracle.com> On 17/02/2012 9:40 AM, Vitaly Davidovich wrote: > The asserts can be enabled/disabled at startup time, but I don't consider > that an advantage over conditional compilation. In fact, it's less > convenient in some cases, e.g. you can't conditionally add/remove class > fields, can't surround blocks of code with condition, etc. There are > workarounds, but it's not ideal. I'm not going to get drawn into the whole "conditional compilation is [not] evil" debate. :) If I recall correctly the suggested buld-time idiom was to do: static final boolean ASSERT = true; // or false ... if (ASSERT) assert ... that way you could compile with ASSERT set true to get assertions in the code; or false to have them elided by javac. > C#/.Net have conditional compilation (conditional blocks + assert > statements) and it's a handy tool and no need to worry about dead IL code > causing opto issues - don't see a reason why java couldn't have done the > same from the beginning. Simply because the people defining the language didn't want it. I suspect there's a blog or two out there somewhere discussing this. David ----- > > Sent from my phone > On Feb 16, 2012 6:16 PM, "David Holmes" wrote: > >> The corelibs side of things seems to have gotten dropped from the cc list >> - added back. >> >> On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: >> >>> Don't want to sidetrack this thread but I really wish javac had proper >>> conditional compilation support, which would make this issue mostly moot. >>> >> >> But the whole point of Java assertions is to make them available at >> runtime. I seem to recall a very similar question only recently on the >> core-libs mailing list. >> >> So summary is: >> >> - Every assert requires checking if asserts are enabled >> - JIT Compiler can elide the checks >> - Presence of assert related bytecodes can impact JIT compiler inlining >> decisions >> >> David >> >> Sent from my phone >>> >>> On Feb 16, 2012 5:14 PM, "John Rose">> > wrote: >>> >>> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: >>> >>> I think one problem with them is that they count towards the >>>> inlining budget since their bytecodes still take up space. Not >>>> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. >>>> >>> >>> Optimized object code has (probably) no trace of the assertions >>> themselves, but as Vitaly said, they perturb the inlining budget. >>> Larger methods have a tendency to "discourage" the inliner from >>> inlining, causing more out-of-line calls and a rough net slowdown. >>> Currently, the non-executed bytecodes for assertions (which can be >>> arbitrarily complex) make methods look bigger than they really are. >>> This is (IMO) a bug in the inlining heuristics, which should be >>> fixed by examining inlining candidates with a little more care. >>> Since the escape analysis does a similar method summarization, >>> there isn't necessarily even a need for an extra pass over the methods. >>> >>> -- John >>> >>> From xueming.shen at oracle.com Fri Feb 17 06:08:11 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 17 Feb 2012 06:08:11 +0000 Subject: hg: jdk8/tl/jdk: 4153167: separate between ANSI and OEM code pages on Windows Message-ID: <20120217060835.1958E4755D@hg.openjdk.java.net> Changeset: d38fed7d2ea7 Author: sherman Date: 2012-02-16 22:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d38fed7d2ea7 4153167: separate between ANSI and OEM code pages on Windows Summary: To use OEM code page for System.out&err when not redirected Reviewed-by: alanb ! src/share/classes/java/lang/System.java ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/windows/native/java/lang/java_props_md.c From forax at univ-mlv.fr Fri Feb 17 11:36:53 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 17 Feb 2012 12:36:53 +0100 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3CDC78.2090405@oracle.com> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> Message-ID: <4F3E3BD5.5020101@univ-mlv.fr> On 02/16/2012 11:37 AM, Alan Bateman wrote: > On 15/02/2012 17:34, R?mi Forax wrote: >> Reported by a user on the concurrency-interest mailing list, >> File field "path" is not declared final but should be. > Thanks for forwarding R?mi. I did reply on concurrency-interest but I > forgot that my original subscription there was @sun.com. > > I've created a bug to track this: > > 7146152: File.path should be final > > It's something that should have been fixed a long time ago (it's > always been non-final). It's just the readObject that requires work, > to use unsafe as you suggest. > > -Alan Hi Alan, hi all, here is a possible fix. R?mi From forax at univ-mlv.fr Fri Feb 17 12:00:27 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 17 Feb 2012 13:00:27 +0100 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E3BD5.5020101@univ-mlv.fr> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> Message-ID: <4F3E415B.1040700@univ-mlv.fr> On 02/17/2012 12:36 PM, R?mi Forax wrote: > On 02/16/2012 11:37 AM, Alan Bateman wrote: >> On 15/02/2012 17:34, R?mi Forax wrote: >>> Reported by a user on the concurrency-interest mailing list, >>> File field "path" is not declared final but should be. >> Thanks for forwarding R?mi. I did reply on concurrency-interest but I >> forgot that my original subscription there was @sun.com. >> >> I've created a bug to track this: >> >> 7146152: File.path should be final >> >> It's something that should have been fixed a long time ago (it's >> always been non-final). It's just the readObject that requires work, >> to use unsafe as you suggest. >> >> -Alan > > Hi Alan, hi all, > here is a possible fix. > > R?mi > Better with the attachment inlined :) R?mi diff --git a/src/share/classes/java/io/File.java b/src/share/classes/java/io/File.java --- a/src/share/classes/java/io/File.java +++ b/src/share/classes/java/io/File.java @@ -153,7 +153,7 @@ /** * The FileSystem object representing the platform's local file system. */ - static private FileSystem fs = FileSystem.getFileSystem(); + private static final FileSystem fs = FileSystem.getFileSystem(); /** * This abstract pathname's normalized pathname string. A normalized @@ -162,13 +162,13 @@ * * @serial */ - private String path; + private final String path; /** * The length of this abstract pathname's prefix, or zero if it has no * prefix. */ - private transient int prefixLength; + private final transient int prefixLength; /** * Returns the length of this abstract pathname's prefix. @@ -2023,10 +2023,28 @@ char sep = s.readChar(); // read the previous separator char if (sep != separatorChar) pathField = pathField.replace(sep, separatorChar); - this.path = fs.normalize(pathField); - this.prefixLength = fs.prefixLength(this.path); + String path = fs.normalize(pathField); + UNSAFE.putObject(this, PATH_OFFSET, path); + UNSAFE.putIntVolatile(this, PREFIX_LENGTH_OFFSET, fs.prefixLength(path)); } + private static final long PATH_OFFSET; + private static final long PREFIX_LENGTH_OFFSET; + private static final sun.misc.Unsafe UNSAFE; + static { + try { + sun.misc.Unsafe unsafe = sun.misc.Unsafe.getUnsafe(); + PATH_OFFSET = unsafe.objectFieldOffset( + File.class.getDeclaredField("path")); + PREFIX_LENGTH_OFFSET = unsafe.objectFieldOffset( + File.class.getDeclaredField("prefixLength")); + UNSAFE = unsafe; + } catch (ReflectiveOperationException e) { + throw new Error(e); + } + } + + /** use serialVersionUID from JDK 1.0.2 for interoperability */ private static final long serialVersionUID = 301077366599181567L; From Alan.Bateman at oracle.com Fri Feb 17 12:11:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Feb 2012 12:11:59 +0000 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E415B.1040700@univ-mlv.fr> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> Message-ID: <4F3E440F.3020507@oracle.com> On 17/02/2012 12:00, R?mi Forax wrote: > : > Better with the attachment inlined :) Thanks R?mi, this looks okay to me although I probably would have used putObjectVolatile for the path field. -Alan. From david.holmes at oracle.com Fri Feb 17 12:37:35 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Feb 2012 22:37:35 +1000 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E440F.3020507@oracle.com> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <4F3E440F.3020507@oracle.com> Message-ID: <4F3E4A0F.9090300@oracle.com> On 17/02/2012 10:11 PM, Alan Bateman wrote: > On 17/02/2012 12:00, R?mi Forax wrote: >> : >> Better with the attachment inlined :) > Thanks R?mi, this looks okay to me although I probably would have used > putObjectVolatile for the path field. You only need one "volatile" store and it should be the last one. The approximate affect is: path = ... membar: LoadStore | StoreStore prefixlength = ... membar: StoreLoad David ----- > -Alan. From Alan.Bateman at oracle.com Fri Feb 17 12:41:12 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Feb 2012 12:41:12 +0000 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E4A0F.9090300@oracle.com> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <4F3E440F.3020507@oracle.com> <4F3E4A0F.9090300@oracle.com> Message-ID: <4F3E4AE8.8060602@oracle.com> On 17/02/2012 12:37, David Holmes wrote: > On 17/02/2012 10:11 PM, Alan Bateman wrote: >> On 17/02/2012 12:00, R?mi Forax wrote: >>> : >>> Better with the attachment inlined :) >> Thanks R?mi, this looks okay to me although I probably would have used >> putObjectVolatile for the path field. > > You only need one "volatile" store and it should be the last one. The > approximate affect is: > > path = ... > membar: LoadStore | StoreStore > prefixlength = ... > membar: StoreLoad I understand, I just remarking that I probably would have used a volatile store for both to make it clearer but that would be less efficient. -Alan From forax at univ-mlv.fr Fri Feb 17 12:54:15 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 17 Feb 2012 13:54:15 +0100 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E4AE8.8060602@oracle.com> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <4F3E440F.3020507@oracle.com> <4F3E4A0F.9090300@oracle.com> <4F3E4AE8.8060602@oracle.com> Message-ID: <4F3E4DF7.7070802@univ-mlv.fr> On 02/17/2012 01:41 PM, Alan Bateman wrote: > On 17/02/2012 12:37, David Holmes wrote: >> On 17/02/2012 10:11 PM, Alan Bateman wrote: >>> On 17/02/2012 12:00, R?mi Forax wrote: >>>> : >>>> Better with the attachment inlined :) >>> Thanks R?mi, this looks okay to me although I probably would have used >>> putObjectVolatile for the path field. >> >> You only need one "volatile" store and it should be the last one. The >> approximate affect is: >> >> path = ... >> membar: LoadStore | StoreStore >> prefixlength = ... >> membar: StoreLoad > I understand, I just remarking that I probably would have used a > volatile store for both to make it clearer but that would be less > efficient. Knowing that some codes already serialize File instances, I wanted to minimize the perf impact of this change. That's why I've put only one volatile store even if I agree with Alan that it's better to use two putObjectVolatile for the readability. > > -Alan R?mi From david.holmes at oracle.com Fri Feb 17 12:52:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Feb 2012 22:52:46 +1000 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E4AE8.8060602@oracle.com> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <4F3E440F.3020507@oracle.com> <4F3E4A0F.9090300@oracle.com> <4F3E4AE8.8060602@oracle.com> Message-ID: <4F3E4D9E.5040704@oracle.com> On 17/02/2012 10:41 PM, Alan Bateman wrote: > On 17/02/2012 12:37, David Holmes wrote: >> On 17/02/2012 10:11 PM, Alan Bateman wrote: >>> On 17/02/2012 12:00, R?mi Forax wrote: >>>> : >>>> Better with the attachment inlined :) >>> Thanks R?mi, this looks okay to me although I probably would have used >>> putObjectVolatile for the path field. >> >> You only need one "volatile" store and it should be the last one. The >> approximate affect is: >> >> path = ... >> membar: LoadStore | StoreStore >> prefixlength = ... >> membar: StoreLoad > I understand, I just remarking that I probably would have used a > volatile store for both to make it clearer but that would be less > efficient. For completeness I'll add that if only using one volatile store then it needs to be prefixlength. The reason being that the freeze action on final fields requires a storeStore barrier "at the end of the constructor" (or deserialization in this case) - or more specifically it needs it after setting all final object references. If the path setting was the only volatile and came last then the storestore barrier would be in the wrong place. David > -Alan From vitalyd at gmail.com Fri Feb 17 13:55:17 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 17 Feb 2012 08:55:17 -0500 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E4D9E.5040704@oracle.com> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <4F3E440F.3020507@oracle.com> <4F3E4A0F.9090300@oracle.com> <4F3E4AE8.8060602@oracle.com> <4F3E4D9E.5040704@oracle.com> Message-ID: Why not just have one putObjectOrdered for the path as the last action in deserialization? I think a volatile store is overkill here. Sent from my phone On Feb 17, 2012 7:54 AM, "David Holmes" wrote: > On 17/02/2012 10:41 PM, Alan Bateman wrote: > >> On 17/02/2012 12:37, David Holmes wrote: >> >>> On 17/02/2012 10:11 PM, Alan Bateman wrote: >>> >>>> On 17/02/2012 12:00, R?mi Forax wrote: >>>> >>>>> : >>>>> Better with the attachment inlined :) >>>>> >>>> Thanks R?mi, this looks okay to me although I probably would have used >>>> putObjectVolatile for the path field. >>>> >>> >>> You only need one "volatile" store and it should be the last one. The >>> approximate affect is: >>> >>> path = ... >>> membar: LoadStore | StoreStore >>> prefixlength = ... >>> membar: StoreLoad >>> >> I understand, I just remarking that I probably would have used a >> volatile store for both to make it clearer but that would be less >> efficient. >> > > For completeness I'll add that if only using one volatile store then it > needs to be prefixlength. The reason being that the freeze action on final > fields requires a storeStore barrier "at the end of the constructor" (or > deserialization in this case) - or more specifically it needs it after > setting all final object references. If the path setting was the only > volatile and came last then the storestore barrier would be in the wrong > place. > > David > > -Alan >> > From vitalyd at gmail.com Fri Feb 17 14:27:41 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 17 Feb 2012 09:27:41 -0500 Subject: java.io.File field "path" is not declared final In-Reply-To: References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <4F3E440F.3020507@oracle.com> <4F3E4A0F.9090300@oracle.com> <4F3E4AE8.8060602@oracle.com> <4F3E4D9E.5040704@oracle.com> Message-ID: Actually, I don't even think a volatile write helps here - it doesn't prevent a subsequent (data racy) publishing of the instance from moving before the volatile write. It'll probably work in practice, but isn't JMM compliant, so to speak. Sent from my phone On Feb 17, 2012 8:55 AM, "Vitaly Davidovich" wrote: > Why not just have one putObjectOrdered for the path as the last action in > deserialization? I think a volatile store is overkill here. > > Sent from my phone > On Feb 17, 2012 7:54 AM, "David Holmes" wrote: > >> On 17/02/2012 10:41 PM, Alan Bateman wrote: >> >>> On 17/02/2012 12:37, David Holmes wrote: >>> >>>> On 17/02/2012 10:11 PM, Alan Bateman wrote: >>>> >>>>> On 17/02/2012 12:00, R?mi Forax wrote: >>>>> >>>>>> : >>>>>> Better with the attachment inlined :) >>>>>> >>>>> Thanks R?mi, this looks okay to me although I probably would have used >>>>> putObjectVolatile for the path field. >>>>> >>>> >>>> You only need one "volatile" store and it should be the last one. The >>>> approximate affect is: >>>> >>>> path = ... >>>> membar: LoadStore | StoreStore >>>> prefixlength = ... >>>> membar: StoreLoad >>>> >>> I understand, I just remarking that I probably would have used a >>> volatile store for both to make it clearer but that would be less >>> efficient. >>> >> >> For completeness I'll add that if only using one volatile store then it >> needs to be prefixlength. The reason being that the freeze action on final >> fields requires a storeStore barrier "at the end of the constructor" (or >> deserialization in this case) - or more specifically it needs it after >> setting all final object references. If the path setting was the only >> volatile and came last then the storestore barrier would be in the wrong >> place. >> >> David >> >> -Alan >>> >> From vitalyd at gmail.com Fri Feb 17 14:45:34 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 17 Feb 2012 09:45:34 -0500 Subject: java.io.File field "path" is not declared final In-Reply-To: References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <4F3E440F.3020507@oracle.com> <4F3E4A0F.9090300@oracle.com> <4F3E4AE8.8060602@oracle.com> <4F3E4D9E.5040704@oracle.com> Message-ID: Nevermind, the storestore barrier won't be in the right place. Where's that Fences API? :) Sent from my phone On Feb 17, 2012 8:55 AM, "Vitaly Davidovich" wrote: > Why not just have one putObjectOrdered for the path as the last action in > deserialization? I think a volatile store is overkill here. > > Sent from my phone > On Feb 17, 2012 7:54 AM, "David Holmes" wrote: > >> On 17/02/2012 10:41 PM, Alan Bateman wrote: >> >>> On 17/02/2012 12:37, David Holmes wrote: >>> >>>> On 17/02/2012 10:11 PM, Alan Bateman wrote: >>>> >>>>> On 17/02/2012 12:00, R?mi Forax wrote: >>>>> >>>>>> : >>>>>> Better with the attachment inlined :) >>>>>> >>>>> Thanks R?mi, this looks okay to me although I probably would have used >>>>> putObjectVolatile for the path field. >>>>> >>>> >>>> You only need one "volatile" store and it should be the last one. The >>>> approximate affect is: >>>> >>>> path = ... >>>> membar: LoadStore | StoreStore >>>> prefixlength = ... >>>> membar: StoreLoad >>>> >>> I understand, I just remarking that I probably would have used a >>> volatile store for both to make it clearer but that would be less >>> efficient. >>> >> >> For completeness I'll add that if only using one volatile store then it >> needs to be prefixlength. The reason being that the freeze action on final >> fields requires a storeStore barrier "at the end of the constructor" (or >> deserialization in this case) - or more specifically it needs it after >> setting all final object references. If the path setting was the only >> volatile and came last then the storestore barrier would be in the wrong >> place. >> >> David >> >> -Alan >>> >> From tom.hawtin at oracle.com Fri Feb 17 15:35:13 2012 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Fri, 17 Feb 2012 15:35:13 +0000 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F3D6478.3040606@oracle.com> References: <4F394A24.5040508@oracle.com> <4F3BC875.9000005@oracle.com> <4F3D6478.3040606@oracle.com> Message-ID: <4F3E73B1.3020006@oracle.com> On 16/02/2012 20:18, Xueming Shen wrote: > Thanks Alan, webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/4153167/webrev > Although it's in some sense safe in this case, you might get a grumble about introducing a new sprintf. +static char* getConsoleEncoding() +{ + char* buf = malloc(16); + int cp = GetConsoleCP(); + if (cp >= 874 && cp <= 950) + sprintf(buf, "ms%d", cp); + else + sprintf(buf, "cp%d", cp); + return buf; +} Tom From Alan.Bateman at oracle.com Fri Feb 17 15:48:03 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Feb 2012 15:48:03 +0000 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F3E73B1.3020006@oracle.com> References: <4F394A24.5040508@oracle.com> <4F3BC875.9000005@oracle.com> <4F3D6478.3040606@oracle.com> <4F3E73B1.3020006@oracle.com> Message-ID: <4F3E76B3.2050202@oracle.com> On 17/02/2012 15:35, Tom Hawtin wrote: > > Although it's in some sense safe in this case, you might get a grumble > about introducing a new sprintf. > > +static char* getConsoleEncoding() > +{ > + char* buf = malloc(16); > + int cp = GetConsoleCP(); > + if (cp >= 874 && cp <= 950) > + sprintf(buf, "ms%d", cp); > + else > + sprintf(buf, "cp%d", cp); > + return buf; > +} > > Tom You're right, we should avoid sprintf. It's not an issue here but will be flagged by tools that do static analysis on the source. -Alan. From mike.duigou at oracle.com Fri Feb 17 16:57:25 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 17 Feb 2012 08:57:25 -0800 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E415B.1040700@univ-mlv.fr> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> Message-ID: <301C11DA-A3FC-414B-B6DD-54E4496F8314@oracle.com> Throwing plain Error could probably be improved to InternalError. (Though it will probably never be thrown). Mike On Feb 17 2012, at 04:00 , R?mi Forax wrote: > On 02/17/2012 12:36 PM, R?mi Forax wrote: >> On 02/16/2012 11:37 AM, Alan Bateman wrote: >>> On 15/02/2012 17:34, R?mi Forax wrote: >>>> Reported by a user on the concurrency-interest mailing list, >>>> File field "path" is not declared final but should be. >>> Thanks for forwarding R?mi. I did reply on concurrency-interest but I forgot that my original subscription there was @sun.com. >>> >>> I've created a bug to track this: >>> >>> 7146152: File.path should be final >>> >>> It's something that should have been fixed a long time ago (it's always been non-final). It's just the readObject that requires work, to use unsafe as you suggest. >>> >>> -Alan >> >> Hi Alan, hi all, >> here is a possible fix. >> >> R?mi >> > Better with the attachment inlined :) > > R?mi > > diff --git a/src/share/classes/java/io/File.java b/src/share/classes/java/io/File.java > --- a/src/share/classes/java/io/File.java > +++ b/src/share/classes/java/io/File.java > @@ -153,7 +153,7 @@ > /** > * The FileSystem object representing the platform's local file system. > */ > - static private FileSystem fs = FileSystem.getFileSystem(); > + private static final FileSystem fs = FileSystem.getFileSystem(); > > /** > * This abstract pathname's normalized pathname string. A normalized > @@ -162,13 +162,13 @@ > * > * @serial > */ > - private String path; > + private final String path; > > /** > * The length of this abstract pathname's prefix, or zero if it has no > * prefix. > */ > - private transient int prefixLength; > + private final transient int prefixLength; > > /** > * Returns the length of this abstract pathname's prefix. > @@ -2023,10 +2023,28 @@ > char sep = s.readChar(); // read the previous separator char > if (sep != separatorChar) > pathField = pathField.replace(sep, separatorChar); > - this.path = fs.normalize(pathField); > - this.prefixLength = fs.prefixLength(this.path); > + String path = fs.normalize(pathField); > + UNSAFE.putObject(this, PATH_OFFSET, path); > + UNSAFE.putIntVolatile(this, PREFIX_LENGTH_OFFSET, fs.prefixLength(path)); > } > > + private static final long PATH_OFFSET; > + private static final long PREFIX_LENGTH_OFFSET; > + private static final sun.misc.Unsafe UNSAFE; > + static { > + try { > + sun.misc.Unsafe unsafe = sun.misc.Unsafe.getUnsafe(); > + PATH_OFFSET = unsafe.objectFieldOffset( > + File.class.getDeclaredField("path")); > + PREFIX_LENGTH_OFFSET = unsafe.objectFieldOffset( > + File.class.getDeclaredField("prefixLength")); > + UNSAFE = unsafe; > + } catch (ReflectiveOperationException e) { > + throw new Error(e); > + } > + } > + > + > /** use serialVersionUID from JDK 1.0.2 for interoperability */ > private static final long serialVersionUID = 301077366599181567L; > From mikeb01 at gmail.com Fri Feb 10 03:58:00 2012 From: mikeb01 at gmail.com (Michael Barker) Date: Fri, 10 Feb 2012 03:58:00 +0000 Subject: Warning Fixes from LJC Hack Session In-Reply-To: <4F348ACC.7020707@oracle.com> References: <4F2A6213.4040707@oracle.com> <4F2CE850.9090604@oracle.com> <4F348ACC.7020707@oracle.com> Message-ID: Hi Stuart, Thank you for the reviewing the patches. I forgot about the Contributed-by header, sorry about that. That's one I'll put on the list to make sure I have sorted next time. I've split the contributors up according to the two patches supplied. See below: AWT, beans & printing: Contributed-by: Prasannaa , Martijn Verburg , Goerge Albrecht , Graham Allan , Iordanis Giannakakis , Jose Llarena , Abraham Mar?n P?rez For all of the remaining code: Contributed-by: Mani Sarkar , Michael Barker , Carl Jokl , Dinuk Weerasinghe , Markus Stoy , Tom Anderson I hope these patches are providing value for the OpenJDK team as we plan to do more. I know that there is a bit of a cost for you guys in terms of reviewing and merging. I'm starting to get a better picture of the type of changes that will go in smoothly and those that will require updates to the patches. Mike. On Fri, Feb 10, 2012 at 3:11 AM, Stuart Marks wrote: > Hi Mike, > > I finally got back to this. These fixes look pretty good and knock off 100+ > additional warnings! I've filed bug 7143230 [1] to track this. I took a look > through the code and I took the liberty of fixing up a few very minor > things: > > 1. Removed unnecessary casts to ZipEntry in JarVerifier.java, suggested by > Chirs Hegarty [2]. (These aren't strictly redundant casts, and don't cause > warnings, as the origin types are and JarEntry. > However, they are unnecessary.) > > 2. Fixed typo in unrelated comment at line 50 in SignatureFile.java that I > happened to notice. > > 3. Removed parentheses from expressions in MemoryMonitor.java lines 216, 219 > which are now unnecessary since the cast has been removed. > > No need to issue another patch; I'll just include these changes when I push > the changeset. > > Which brings me to the topic that we discussed before when I pushed LJC's > previous round of warnings fixes, that is, how the Contributed-by line in > the commit message should be formatted. (See [3] for the requirements.) For > reference, here's what the changeset comment for the previous set of LJC > fixes ended up looking like: > > > changeset: ? 4802:4f0f9f9c4892 > user: ? ? ? ?smarks > date: ? ? ? ?Wed Dec 07 12:12:50 2011 -0800 > description: > 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip > Reviewed-by: alanb, dholmes, forax, sherman, smarks > Contributed-by: Prasannaa , Martijn Verburg > , Goerge_Albrecht , > Graham Allan , Michael Barker > > > > It looks like a different set of people contributed to this round of fixes. > If you could send me the list of names and email addresses, I can format > them into the commit message and push the fix. > > Thanks! > > s'marks > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143230 > > [2] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2012-February/000715.html > > [3] http://openjdk.java.net/guide/producingChangeset.html > > > On 2/4/12 12:12 AM, Chris Hegarty wrote: >> >> Thanks for this, looks great. >> >> Good to see JarVerifier getting some much needed TLC. >> >> -Chris. >> >> >> On 02/ 4/12 07:50 AM, Michael Barker wrote: >>>> >>>> I see R?mi has suggested a slice& dice but I think that's a bit too much >>>> work for the changes involved. Instead I would suggest a simple split, >>>> send >>>> the AWT/Printing/Beans changes to awt-dev + 2d-dev, and everything else >>>> to >>>> core-libs-dev. >>> >>> >>> Attached is the patch that contains "everthing else" from LJC warning >>> fixes hack session. >>> >>> Mike. From bill.shannon at oracle.com Fri Feb 10 18:55:19 2012 From: bill.shannon at oracle.com (Bill Shannon) Date: Fri, 10 Feb 2012 10:55:19 -0800 Subject: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7 In-Reply-To: <4F34D5D6.1000103@oracle.com> References: <4F33672E.7020302@oracle.com> <4F33832D.3090807@oracle.com> <4F341A2F.7060700@oracle.com> <4F341A86.8090004@oracle.com> <4F34D5D6.1000103@oracle.com> Message-ID: <4F356817.8020504@oracle.com> If you flush the stream while in the middle of writing a "character", I would expect the results to be undefined, just as if you closed the stream at that point. But at the end of a consistent set of data, I would expect flush to behave like close, but without the actual closing of the stream. Masayoshi Okutsu wrote on 02/10/12 00:31: > I tend to agree with Sherman that the real problem is the OutputStreamWriter API > which isn't good enough to handle various encodings. My understanding is that > the charset API was introduced in 1.4 to deal with the limitations of the > java.io and other encoding handling issues. > > I still don't think it's correct to change the flush semantics. The flush method > should just flush out any outstanding data to the given output stream as defined > in java.io.Writer. What if Writer.write(int) is used write UTF-16 data with any > stateful encoding? Suppose the stateful encoding can support supplementary > characters which require other G0 designations, does the following calling > sequence work? > > writer.write(highSurrogate); > writer.flush(); > writer.write(lowSurrogate); > writer.flush(); > > Of course, this isn't a problem with iso-2022-jp, though. > > I think it's a correct fix, not a workaround, to create a filter stream to deal > with stateful encodings with the java.io API. If it's OK to support only 1.4 and > later, the java.nio.charset API should be used. > > Thanks, > Masayoshi > > On 2/10/2012 4:12 AM, Xueming Shen wrote: >> CCed Bill Shannon. >> >> On 02/09/2012 11:10 AM, Xueming Shen wrote: >>> >>> CharsetEncoder has the "flush()" method as the last step (of a series of >>> "encoding" steps) to >>> flush out any internal state to the output buffer. The issue here is the the >>> upper level wrapper >>> class, OutputStreamWriter in our case, doesn't provide a "explicit" mechanism >>> to let the >>> user to request a "flush" on the underlying encoder. The only "guaranteed' >>> mechanism is the >>> "close()" method, in which it appears it not appropriate to invoke in some >>> use scenario, such >>> as the JavaMail.writeTo() case. >>> >>> It appears we are lacking of a "close this stream, but not the underlying >>> stream" mechanism >>> in our layered/chained streams, I have similar request for this kind of >>> mechanism in other area, >>> such as in zip/gzip stream, app wraps a "outputstream" with zip/gzip, they >>> want to release the >>> zip/gzip layer after use (to release the native resource, for example) but >>> want to keep the >>> underlying stream unclosed. The only workaround now is to wrap the underlying >>> stream with >>> a subclass to override the "close()" method, which is really not desirable. >>> >>> The OutputStreamWriter.flush() does not explicitly specify in its API doc if >>> it should actually >>> flush the underlying charset encoder (so I would not argue strongly that this >>> IS a SE bug) but >>> given it is flushing it's buffer (internal status) and then the underlying >>> "out" stream, it's >>> reasonable to consider that the "internal status" of its encoder also needs >>> to be flushed. >>> Especially this has been the behavior for releases earlier than 1.4.2. >>> >>> As I said, while I have been hesitated to "fix" this problem for a while (one >>> it has been here >>> for 3 major releases, two, the API does not explicitly say so) but as long as >>> we don't have a >>> reasonable "close-ME-only" mechanism for those layered streams, it appears to >>> be a >>> reasonable approach to solve the problem, without having obvious negative >>> impact. >>> >>> -Sherman >>> >>> PS: There is another implementation "detail" that the original iso-2022-jp >>> c2b converter >>> actually restores the state back to ASCII mode at the end of its "convert" >>> method, this makes >>> the analysis a little complicated, but should not change the issue we are >>> discussing) >>> >>> >>> On 02/09/2012 12:26 AM, Masayoshi Okutsu wrote: >>>> First of all, is this really a Java SE bug? The usage of OutputSteamWriter >>>> in JavaMail seems to be wrong to me. The writeTo method in the bug report >>>> doesn't seem to be able to deal with any stateful encodings. >>>> >>>> Masayoshi >>>> >>>> On 2/9/2012 3:26 PM, Xueming Shen wrote: >>>>> Hi >>>>> >>>>> This is a long standing "regression" from 1.3.1 on how >>>>> OutputStreamWriter.flush()/flushBuffer() >>>>> handles escape or shift sequence in some of the charset/encoding, for >>>>> example the ISO-2022-JP. >>>>> >>>>> ISO-2022-JP is encoding that starts with ASCII mode and then switches >>>>> between ASCII andJapanese >>>>> characters through an escape sequence. For example, the escape sequence ESC >>>>> $ B (0x1B, 0x24 0x42) >>>>> is used to indicate the following bytes are Japanese (switch from ASCII >>>>> mode to Japanese mode), and >>>>> the ESC ( B (0x1b 0x28 0x42) is used to switch back to ASCII. >>>>> >>>>> In Java's sun.io.CharToByteConvert (old generation charset converter) and >>>>> the nio.io.charset.CharsetEncoder >>>>> usually switches back forth between ASCII and Japanese modes based on the >>>>> input character sequence >>>>> (for example, if you are in ASCII mode, and your next input character is a >>>>> Japanese, you add the >>>>> ESC $ B into the output first and then followed the converted input >>>>> character, or if you are in Japanese >>>>> mode and your next input is ASCII, you output ESC ( B first to switch the >>>>> mode and then the ASCII) and >>>>> switch back to ASCII mode (if the last mode is non-Japanese) if either the >>>>> encoding is ending or the >>>>> flush() method gets invoked. >>>>> >>>>> In JDK1.3.1, OutputStreamWriter.flushBuffer() explicitly invokes >>>>> sun.io.c2b's flushAny() to switch >>>>> back to ASCII mode every time the flush() or flushBuffer() (from >>>>> PrintStream) gets invoked, as >>>>> showed at the end of this email. For example, as showed below, the code >>>>> uses OutputStreamWriter >>>>> to "write" a Japanese character \u6700 to the underlying stream with >>>>> iso-2022jp, >>>>> >>>>> ByteArrayOutputStream bos = new ByteArrayOutputStream(); >>>>> String str = "\u6700"; >>>>> OutputStreamWriter osw = new OutputStreamWriter(bos, "iso-2022-jp"); >>>>> osw.write(str, 0, str.length()); >>>>> >>>>> Since the iso-2022-jp starts with ASCII mode, we now have a Japanese, so we >>>>> need to >>>>> switch into Japanese mode first (the first 3 bytes) and then the encoded >>>>> Japanese >>>>> character (the following 2 bytes) >>>>> >>>>> 0x1b 0x24 0x42 0x3a 0x47 >>>>> >>>>> and then the code invokes >>>>> >>>>> osw.flush(); >>>>> >>>>> since we are now in Japanese, the writer continues to write out >>>>> >>>>> 0x1b 0x28 0x 42 >>>>> >>>>> to switch back to ASCII mode. The total output is 8 bytes after write() and >>>>> flush(). >>>>> >>>>> However, when all encoidng/charset related codes were migrated from 1.3.1's >>>>> sun.io based to >>>>> 1.4's java.nio.charset based implementation (1.4, 1.4.1 and 1.4.2, we >>>>> gradually migrated from >>>>> sun.io to java.nio.charset), the "c2b.flushAny()" invocation obviously was >>>>> dropped in >>>>> sun.nio.cs.StreamEncoder. It results in that the "switch back to ASCII >>>>> mode" sequence is no longer >>>>> output when OutputStreamWriter.flush() or PrintStream.write(String) is >>>>> invoked. >>>>> >>>>> This does not trigger problem for most use scenario, if the "stream" >>>>> finally gets closed >>>>> (in which the StreamEncoder does invoke encoder's flush() to output the >>>>> escape sequence >>>>> to switch back to ASCII) or PrintStream.println(String) is used (in which >>>>> it outputs a \n character, >>>>> since this \n is in ASCII range, it "accidentally " switches the mode back >>>>> to ASCII). >>>>> >>>>> But it obviously causes problem when you can't not close the >>>>> OutputStreamWriter after >>>>> you're done your iso2022-jp writing (for example, you need continue to use >>>>> the underlying >>>>> OutputStream for other writing, but not "this" osw), for 1.3.1, these apps >>>>> invoke osw.flush() >>>>> to force the output switch back to ASCII, this no longer works when we >>>>> switch to java.nio.charset >>>>> in jdk1.4.2. (we migrated iso-2022-jp to nio.charset in 1.4.2). This is >>>>> what happened in JavaMail, >>>>> as described in the bug report. >>>>> >>>>> The solution is to re-store the "flush the encoder" mechanism in >>>>> StreamEncoder's flushBuffer(). >>>>> >>>>> I have been hesitated to make this change for a while, mostly because this >>>>> regressed behavior >>>>> has been their for 3 releases, and the change triggers yet another >>>>> "behavior change". But given >>>>> there is no obvious workaround and it only changes the behavior of the >>>>> charsets with this >>>>> shift in/out mechanism, mainly the iso-2022 family and those IBM >>>>> EBCDIC_DBCS charsets, I >>>>> decided to give it a try. >>>>> >>>>> Here is the webreview >>>>> >>>>> http://cr.openjdk.java.net/~sherman/6995537/webrev >>>>> >>>>> Sherman >>>>> >>>>> >>>>> ---------------------------------1.3.1 >>>>> OutputStreamWriter----------------------- >>>>> /** >>>>> * Flush the output buffer to the underlying byte stream, without flushing >>>>> * the byte stream itself. This method is non-private only so that it may >>>>> * be invoked by PrintStream. >>>>> */ >>>>> void flushBuffer() throws IOException { >>>>> synchronized (lock) { >>>>> ensureOpen(); >>>>> >>>>> for (;;) { >>>>> try { >>>>> nextByte += ctb.flushAny(bb, nextByte, nBytes); >>>>> } >>>>> catch (ConversionBufferFullException x) { >>>>> nextByte = ctb.nextByteIndex(); >>>>> } >>>>> if (nextByte == 0) >>>>> break; >>>>> if (nextByte > 0) { >>>>> out.write(bb, 0, nextByte); >>>>> nextByte = 0; >>>>> } >>>>> } >>>>> } >>>>> } >>>>> >>>>> /** >>>>> * Flush the stream. >>>>> * >>>>> * @exception IOException If an I/O error occurs >>>>> */ >>>>> public void flush() throws IOException { >>>>> synchronized (lock) { >>>>> flushBuffer(); >>>>> out.flush(); >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> >>> >> From bill.shannon at oracle.com Mon Feb 13 19:07:43 2012 From: bill.shannon at oracle.com (Bill Shannon) Date: Mon, 13 Feb 2012 11:07:43 -0800 Subject: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows In-Reply-To: <4F394A24.5040508@oracle.com> References: <4F394A24.5040508@oracle.com> Message-ID: <4F395F7F.6000509@oracle.com> Thanks for fixing this! > The webrev is at > > http://cr.openjdk.java.net/~sherman/4153167/webrev You probably don't need to malloc 64 bytes for a string that's going to be less than 16 bytes. And shouldn't you use snprintf in any event? Unlike Unix, I assume Windows has no way to have multiple "console" devices, with stdout and stderr pointing to different devices? Is the console the only device that's FILE_TYPE_CHAR? Are there no serial port devices or other devices that are also of that type? Can you detect the case of creating an InputStreamReader using the default encoding, wrapped around the InputStream from System.in that refers to the console? If so, it might be good to handle that case as well, although at this point I would consider that to be "extra credit"! :-) From Dmitry.Samersoff at oracle.com Fri Feb 17 10:49:09 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 17 Feb 2012 14:49:09 +0400 Subject: cost of Java "assert" when disabled? In-Reply-To: References: Message-ID: <4F3E30A5.2050603@oracle.com> Ramki, Please notice: a) asserts causes new object allocation, stackmaptable and exception table grows. Bytecodes for: int value = 10; assert false : value; 0: bipush 10 2: istore_1 3: getstatic #2; //Field $assertionsDisabled:Z 6: ifne 18 9: new #3; //class java/lang/AssertionError 12: dup 13: iload_1 14: invokespecial #4; //Method java/lang/AssertionError."":(I)V 17: athrow b) assert MyClass.openFile(); cause that openFile() will never be executed if assertions is disabled. So you have to write: bool value = MyClass.openFile(); assert value; c) code below assert false : System.err.println("False"); will not ever compile, because System.err.println is void. so you have to write try{ assert false : "False"; } catch(AssertionError ex){ System.err.println(ex); } and then rely on C1/C2 to eliminate useless code. ** IMHO, counting all above it's better to write your own function MyAssert doing exactly what you need rather than use build-in one. ** Sidestepping to conditional compilation - I vote for it with both hands. -Dmitry On 2012-02-17 00:42, Srinivas Ramakrishna wrote: > A Java language newbie question: > > Does anyone have any ballpark numbers on the cost (and its scaling) of > peppering assert's in your Java code, but with asserts disabled (-da) ? > In other words, is the disabled cost so vanishingly small that we need > not think twice when using them, or should one be > careful because the cost is non-negligible and can affect (bytecode) > footprint or rutime performace even when switched off? > > thanks for any advice. > -- ramki -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Alan.Bateman at oracle.com Sun Feb 19 16:55:55 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 Feb 2012 16:55:55 +0000 Subject: java.io.File field "path" is not declared final In-Reply-To: <301C11DA-A3FC-414B-B6DD-54E4496F8314@oracle.com> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <301C11DA-A3FC-414B-B6DD-54E4496F8314@oracle.com> Message-ID: <4F41299B.7070301@oracle.com> On 17/02/2012 16:57, Mike Duigou wrote: > Throwing plain Error could probably be improved to InternalError. > > (Though it will probably never be thrown). > > Mike > This is something where we have never been consistent. I did a quick search through the jdk repository and see 246 places where Error is thrown, 410 where InternalError is thrown, and 278 where AssertionError is thrown. Most of these are "should not here here" sites and so the error will never be thrown. Definitely wroth a bit clean-up some day. For now, I think I'll push R?mi as is, if for no reason other than File.toURI also throws Error. -Alan. From alan.bateman at oracle.com Sun Feb 19 16:56:53 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Feb 2012 16:56:53 +0000 Subject: hg: jdk8/tl/jdk: 7146152: File.path should be final Message-ID: <20120219165725.8D0CE4758B@hg.openjdk.java.net> Changeset: 24c298ef20a8 Author: forax Date: 2012-02-19 16:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24c298ef20a8 7146152: File.path should be final Reviewed-by: alanb, dholmes, mduigou ! src/share/classes/java/io/File.java From forax at univ-mlv.fr Sun Feb 19 17:01:40 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 19 Feb 2012 18:01:40 +0100 Subject: hg: jdk8/tl/jdk: 7146152: File.path should be final In-Reply-To: <20120219165725.8D0CE4758B@hg.openjdk.java.net> References: <20120219165725.8D0CE4758B@hg.openjdk.java.net> Message-ID: <4F412AF4.7070804@univ-mlv.fr> On 02/19/2012 05:56 PM, alan.bateman at oracle.com wrote: > Changeset: 24c298ef20a8 > Author: forax > Date: 2012-02-19 16:51 +0000 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24c298ef20a8 > > 7146152: File.path should be final > Reviewed-by: alanb, dholmes, mduigou > > ! src/share/classes/java/io/File.java > thanks, Alan. R?mi From Ulf.Zibis at gmx.de Sun Feb 19 17:30:03 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 19 Feb 2012 18:30:03 +0100 Subject: java.io.File field "path" is not declared final In-Reply-To: <4F3E4DF7.7070802@univ-mlv.fr> References: <4F3BEC91.3060308@univ-mlv.fr> <4F3CDC78.2090405@oracle.com> <4F3E3BD5.5020101@univ-mlv.fr> <4F3E415B.1040700@univ-mlv.fr> <4F3E440F.3020507@oracle.com> <4F3E4A0F.9090300@oracle.com> <4F3E4AE8.8060602@oracle.com> <4F3E4DF7.7070802@univ-mlv.fr> Message-ID: <4F41319B.8060803@gmx.de> Am 17.02.2012 13:54, schrieb R?mi Forax: > On 02/17/2012 01:41 PM, Alan Bateman wrote: >> I understand, I just remarking that I probably would have used a volatile store for both to make >> it clearer but that would be less efficient. > > Knowing that some codes already serialize File instances, I wanted > to minimize the perf impact of this change. > That's why I've put only one volatile store even if I agree with Alan that > it's better to use two putObjectVolatile for the readability. Maybe too late, but what about adding a comment on that to the source code. -Ulf From littlee at linux.vnet.ibm.com Mon Feb 20 03:25:10 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Mon, 20 Feb 2012 03:25:10 +0000 Subject: hg: jdk8/tl/jdk: 7146506: (fc) Add EACCES check to the return of fcntl native method Message-ID: <20120220032520.DF77C47592@hg.openjdk.java.net> Changeset: de7f6d5841b6 Author: littlee Date: 2012-02-20 11:24 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de7f6d5841b6 7146506: (fc) Add EACCES check to the return of fcntl native method Summary: Add EACCES check according to the spec of fcntl Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c From Alan.Bateman at oracle.com Mon Feb 20 12:46:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Feb 2012 12:46:11 +0000 Subject: 7147087: Remove AWT/Swing/client tests from ProblemList Message-ID: <4F424093.6050505@oracle.com> When Kelly setup the ProblemList file to exclude tests then he initially excluded dozens of tests that he observed failing on platform or in some configuration. We've been chipping away at these issues since then but there are lots of tests for the client area that have not been removed (my guess is that folks in these areas were unaware of this file or do not run the tests via the make file). It's time to do a "reset" and just remove the these tests from the list. For those that are running these tests then feel free to re-add tests that are buggy, just make sure that there are bugs submitted. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7147087/webrev/ Note that I've used the opportunity to add a few other tests that have been failing intermittently (one persistently). Thanks, -Alan. From kelly.ohair at oracle.com Mon Feb 20 16:45:53 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 20 Feb 2012 08:45:53 -0800 Subject: 7147087: Remove AWT/Swing/client tests from ProblemList In-Reply-To: <4F424093.6050505@oracle.com> References: <4F424093.6050505@oracle.com> Message-ID: <4588043E-FC10-4598-A1BF-8D3224DA8B6C@oracle.com> Looks ok to me. -kto On Feb 20, 2012, at 4:46 AM, Alan Bateman wrote: > > When Kelly setup the ProblemList file to exclude tests then he initially excluded dozens of tests that he observed failing on platform or in some configuration. We've been chipping away at these issues since then but there are lots of tests for the client area that have not been removed (my guess is that folks in these areas were unaware of this file or do not run the tests via the make file). It's time to do a "reset" and just remove the these tests from the list. For those that are running these tests then feel free to re-add tests that are buggy, just make sure that there are bugs submitted. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/7147087/webrev/ > > Note that I've used the opportunity to add a few other tests that have been failing intermittently (one persistently). > > Thanks, > > -Alan. From alan.bateman at oracle.com Mon Feb 20 19:17:49 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 20 Feb 2012 19:17:49 +0000 Subject: hg: jdk8/tl/jdk: 6346658: (se) Selector briefly spins when asynchronously closing a registered channel [win] Message-ID: <20120220191811.BFD3E4759A@hg.openjdk.java.net> Changeset: 7326971f09af Author: alanb Date: 2012-02-20 18:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7326971f09af 6346658: (se) Selector briefly spins when asynchronously closing a registered channel [win] Reviewed-by: chegar, coffeys ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/windows/classes/sun/nio/ch/NativeThread.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/native/sun/nio/ch/SocketDispatcher.c From alan.bateman at oracle.com Mon Feb 20 19:46:44 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 20 Feb 2012 19:46:44 +0000 Subject: hg: jdk8/tl/jdk: 7147087: Remove AWT/Swing/client tests from ProblemList Message-ID: <20120220194653.9333B4759B@hg.openjdk.java.net> Changeset: 5e56d498e913 Author: alanb Date: 2012-02-20 19:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e56d498e913 7147087: Remove AWT/Swing/client tests from ProblemList Reviewed-by: ohair ! test/Makefile ! test/ProblemList.txt From weijun.wang at oracle.com Tue Feb 21 00:51:46 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 21 Feb 2012 00:51:46 +0000 Subject: hg: jdk8/tl/jdk: 7144530: KeyTab.getInstance(String) no longer handles keyTabNames with "file:" prefix Message-ID: <20120221005205.244BC475A7@hg.openjdk.java.net> Changeset: 0243e7c0b0fb Author: weijun Date: 2012-02-21 08:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0243e7c0b0fb 7144530: KeyTab.getInstance(String) no longer handles keyTabNames with "file:" prefix Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/ktab/FileKeyTab.java From weijun.wang at oracle.com Tue Feb 21 07:12:04 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 21 Feb 2012 07:12:04 +0000 Subject: hg: jdk8/tl/jdk: 7147336: clarification on warning of keytool -printcrl Message-ID: <20120221071214.6B8A9475AC@hg.openjdk.java.net> Changeset: b739dd7ce59c Author: weijun Date: 2012-02-21 15:11 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b739dd7ce59c 7147336: clarification on warning of keytool -printcrl Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java From xuelei.fan at oracle.com Tue Feb 21 13:45:19 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 21 Feb 2012 13:45:19 +0000 Subject: hg: jdk8/tl/jdk: 7147407: remove never used debug code in DnsClient.java Message-ID: <20120221134528.F0E75475B5@hg.openjdk.java.net> Changeset: a4e3dde9a8a7 Author: xuelei Date: 2012-02-21 05:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4e3dde9a8a7 7147407: remove never used debug code in DnsClient.java Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/dns/DnsClient.java From sean.coffey at oracle.com Tue Feb 21 18:19:38 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 21 Feb 2012 18:19:38 +0000 Subject: RFR: 7133138 Improve io performance around timezone lookups Message-ID: <4F43E03A.1020404@oracle.com> I've worked with Masayoshi on this issue. Hoping to push to JDK8 and backport to 7u and a jdk6 once baked for a while. Some windows boxes were showing performance issues when attempting to iterate through all available timezones available in the JRE. Changes made here should reduce the amount of file stat calls made on jre/lib/zi/* files. Tweaks are made to the alias table also to reduce number of aliases that require lookup. All TZ regression tests run without issue. I've seen a 20-30% speed up on iteration of timezones on windows as a result. Unix doesn't appear to suffer as badly from such a file IO hit. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133138 http://cr.openjdk.java.net/~coffeys/webrev.7133138/ regards, Sean. From kurchi.subhra.hazra at oracle.com Wed Feb 22 05:48:20 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 21 Feb 2012 21:48:20 -0800 Subject: Code review request: 7088502 Security libraries don't build with javac -Werror Message-ID: <4F4481A4.40701@oracle.com> Hi, The following webrev removes warnings in sun.rmi.* packages. I have neglected nearly all deprecation warnings, since this code uses deprecated classes such as java.rmi.server.LogStream with no suggested replacements. I have included -Xlint:all,-deprecation as an option instead in the appropriate Makefiles. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146763 Webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.00/ Thanks, Kurchi From kurchi.subhra.hazra at oracle.com Wed Feb 22 05:50:29 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 21 Feb 2012 21:50:29 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F4481A4.40701@oracle.com> References: <4F4481A4.40701@oracle.com> Message-ID: <4F448225.60009@oracle.com> Corrected the subject line. Hi, The following webrev removes warnings in sun.rmi.* packages. I have neglected nearly all deprecation warnings, since this code uses deprecated classes such as java.rmi.server.LogStream with no suggested replacements. I have included -Xlint:all,-deprecation as an option instead in the appropriate Makefiles. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146763 Webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.00/ Thanks, Kurchi From chris.hegarty at oracle.com Wed Feb 22 11:16:29 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Feb 2012 11:16:29 +0000 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F448225.60009@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> Message-ID: <4F44CE8D.3050403@oracle.com> Kurchi, Great work. I've been through the complete webrev and I think it looks good. Just a few minor comments: - there are API changes, but only in sun private implementation classes, so this should be fine. - Minor indentation nit where method declaration return type was generified. The method args on subsequent lines should be equally indented. Example LoaderHandler.java L152: public static Class loadClass(String codebase, String name, >>>> ClassLoader defaultLoader) - There are opportunities to use auto boxing/unboxing >: diff RMIGenerator.java 99c99 < version = versionOptions.get(arg); --- > version = (versionOptions.get(arg)).intValue(); ConnectionMultiplexer.java >: diff ConnectionMultiplexer.java ConnectionMultiplexer.java.1 133a134 < Integer idObj; 150c151,152 > info = connectionTable.get(id); --- < idObj = new Integer(id); < info = connectionTable.get(idObj); 158c160 > connectionTable.put(id, info); --- < connectionTable.put(idObj, info); ..... -Chris. On 22/02/2012 05:50, Kurchi Hazra wrote: > Corrected the subject line. > > > Hi, > > The following webrev removes warnings in sun.rmi.* packages. I have > neglected nearly all > deprecation warnings, since this code uses deprecated classes such as > java.rmi.server.LogStream > with no suggested replacements. I have included -Xlint:all,-deprecation > as an option instead > in the appropriate Makefiles. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146763 > Webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.00/ > > > Thanks, > Kurchi From sean.coffey at oracle.com Wed Feb 22 13:25:01 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 22 Feb 2012 13:25:01 +0000 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) Message-ID: <4F44ECAD.70206@oracle.com> Bug recently reported. We enter infinite recursion on a boundary case for Collections.synchronizedList.remove(..) Fix is a simple equals check in class method before delegating the call. bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144488 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7144488/ regards, Sean. From Alan.Bateman at oracle.com Wed Feb 22 14:22:51 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 14:22:51 +0000 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F44ECAD.70206@oracle.com> References: <4F44ECAD.70206@oracle.com> Message-ID: <4F44FA3B.8060001@oracle.com> On 22/02/2012 13:25, Se?n Coffey wrote: > Bug recently reported. We enter infinite recursion on a boundary case > for Collections.synchronizedList.remove(..) > > Fix is a simple equals check in class method before delegating the call. > > bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144488 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7144488/ Sean - the fix looks okay to me but I assume there are other cases, like with SynchronizedSet and hashCode for example. I don't know if they are all fixable, at least not the hashCode cases. -Alan. From Roger.Riggs at oracle.com Wed Feb 22 14:24:01 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 22 Feb 2012 09:24:01 -0500 Subject: Code review request: 6282196 There should be Math.mod(number, modulo) methods Message-ID: <4F44FA81.9020108@oracle.com> Hi, 6282196 There should be Math.mod(number, modulo) methods Requests that floor and modulus methods be provided for primitive types. Floor division is pretty straight-forward, rounding toward minus infinity. For modulus of int and long, the sign and range follow the exiting floor method in java.util.Math and satisfy the relation that mod(x, y) = (x - floorDiv(x, y) * y). Please review and comment, http://cr.openjdk.java.net/~rriggs/6282196.1/ Thanks, Roger From scolebourne at joda.org Wed Feb 22 14:37:42 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 22 Feb 2012 14:37:42 +0000 Subject: Code review request: 6282196 There should be Math.mod(number, modulo) methods In-Reply-To: <4F44FA81.9020108@oracle.com> References: <4F44FA81.9020108@oracle.com> Message-ID: Can you explain why the mod implementation differs from that in JSR-310? https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/MathUtils.java#L401 The code ((a % b) + b) % b; is short and involves no branches, which should aid performance and inlining. Is this to do with accepting a negative second argument? Perofmance testing? I'd like to see performance numbers comparing the two approaches, as JSR-310 might need to continue using the double % version if it is faster. Similarly, the proposed floorDiv requires evaluation of the complex if statement every time, whereas the JSR-310 one only requires an if check against zero. Whats the rationale for the difference, which is intuitively (non-proven) slower. thanks Stephen On 22 February 2012 14:24, Roger Riggs wrote: > Hi, > > 6282196 There should be Math.mod(number, modulo) methods > > > Requests that floor and modulus methods be provided for primitive types. > Floor division is pretty straight-forward, rounding toward minus infinity. > For modulus of int and long, the sign and range follow ?the exiting floor > method > in java.util.Math and satisfy the relation that mod(x, y) = (x - floorDiv(x, > y) * y). > > Please review and comment, > ? ?http://cr.openjdk.java.net/~rriggs/6282196.1/ > > Thanks, Roger > > From sean.coffey at oracle.com Wed Feb 22 14:43:02 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 22 Feb 2012 14:43:02 +0000 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F44FA3B.8060001@oracle.com> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com> Message-ID: <4F44FEF6.2060907@oracle.com> Yes, I stumbled across another few issues in the Collections class while looking to expand the testcase for this one. Below are other such cases. Various hashCode methods lead to recursive calls and this has been discussed in the past. It's also mentioned in the javadocs (albeit somewhat vaguely) > Note: While it is permissible for lists to contain themselves as > elements, extreme caution is advised: the equals and hashCode methods > are no longer well defined on a such a list. http://www.velocityreviews.com/forums/t134246-infinite-loops-in-hashcode-and-equals.html Due to the known issue, I wasn't planning on making any further changes. regards, Sean. List list = Collections.synchronizedList(new ArrayList()); list.add(list); //int i = list.hashCode(); // recursive call //list.remove(list); // recursive call (FIXED with 7144488) /* Sets also suffer similar problems */ Set s = Collections.synchronizedSet(new HashSet()); s.add(s); //s.remove(s); // recursive call On 22/02/12 14:22, Alan Bateman wrote: > Sean - the fix looks okay to me but I assume there are other cases, > like with SynchronizedSet and hashCode for example. I don't know if > they are all fixable, at least not the hashCode cases. > > -Alan. From Roger.Riggs at oracle.com Wed Feb 22 16:21:28 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 22 Feb 2012 11:21:28 -0500 Subject: Code review request: 6282196 There should be Math.mod(number, modulo) methods In-Reply-To: References: <4F44FA81.9020108@oracle.com> Message-ID: <4F451608.2020502@oracle.com> On 02/22/2012 09:37 AM, Stephen Colebourne wrote: > Can you explain why the mod implementation differs from that in JSR-310? > https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/MathUtils.java#L401 > > The code ((a % b) + b) % b; is short and involves no branches, which > should aid performance and inlining. Is this to do with accepting a > negative second argument? Performance testing? For floorMod, the numeric results are the same but the performance is slightly better. The performance difference is very noticeable for long's, using a single divide and a multiply with the branch is about 1.5 times as fast as the alternative using two % operations. For int's the difference was minimal but still faster. I did not compare against floating point divide. Since it depends on the performance of the divide instruction it will be sensitive to specific processors. For interpreters and devices without floating point hardware (yes they exist) and slower hardware minimizing the number of divides makes sense. I would rather not try to tune for specific hardware and leave that to the VM. > > I'd like to see performance numbers comparing the two approaches, as > JSR-310 might need to continue using the double % version if it is > faster. > > Similarly, the proposed floorDiv requires evaluation of the complex if > statement every time, whereas the JSR-310 one only requires an if > check against zero. Whats the rationale for the difference, which is > intuitively (non-proven) slower., For floorDiv, the results are different when the sign of the divisor is negative. Using the definition of the largest integer less than the quotient with the arguments (4, -3) should be -1.3333, the largest integer less than that is -2. The JSR 310 expression (a/v) evaluates to -1. I choose to be consistent with the Math.floor behavior. Roger > > thanks > Stephen > > > On 22 February 2012 14:24, Roger Riggs wrote: >> Hi, >> >> 6282196 There should be Math.mod(number, modulo) methods >> >> >> Requests that floor and modulus methods be provided for primitive types. >> Floor division is pretty straight-forward, rounding toward minus infinity. >> For modulus of int and long, the sign and range follow the exiting floor >> method >> in java.util.Math and satisfy the relation that mod(x, y) = (x - floorDiv(x, >> y) * y). >> >> Please review and comment, >> http://cr.openjdk.java.net/~rriggs/6282196.1/ >> >> Thanks, Roger >> >> From scolebourne at joda.org Wed Feb 22 16:49:03 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 22 Feb 2012 16:49:03 +0000 Subject: Code review request: 6282196 There should be Math.mod(number, modulo) methods In-Reply-To: <4F451608.2020502@oracle.com> References: <4F44FA81.9020108@oracle.com> <4F451608.2020502@oracle.com> Message-ID: Thanks for the explanation, I don't think that the change in floorDiv behaviour will cause JSR-310 a problem Stephen On 22 February 2012 16:21, Roger Riggs wrote: > > On 02/22/2012 09:37 AM, Stephen Colebourne wrote: > > Can you explain why the mod implementation differs from that in JSR-310? > https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/MathUtils.java#L401 > > The code ((a % b) + b) % b; is short and involves no branches, which > should aid performance and inlining. Is this to do with accepting a > negative second argument? Performance testing? > > For floorMod, the numeric results are the same but the performance is > slightly better. > > The performance difference is very noticeable for long's, using > a single divide and a multiply with the branch is about 1.5 times as fast > as the alternative using two % operations. > > For int's the difference was minimal but still faster.? I did not compare > against > floating point divide. > > Since it depends on the performance of the divide instruction it will > be sensitive to specific processors. For interpreters and devices > without floating point hardware (yes they exist) and slower hardware > minimizing > the number of divides makes sense. I would rather not try to tune for > specific hardware and leave that to the VM. > > > I'd like to see performance numbers comparing the two approaches, as > JSR-310 might need to continue using the double % version if it is > faster. > > Similarly, the proposed floorDiv requires evaluation of the complex if > statement every time, whereas the JSR-310 one only requires an if > check against zero. Whats the rationale for the difference, which is > intuitively (non-proven) slower., > > For floorDiv, the results are different when the sign of the divisor is > negative. > Using the definition of the largest integer less than the quotient with the > arguments (4, -3) should be -1.3333, the largest integer less than that is > -2. > The JSR 310 expression?? (a/v) evaluates to -1. > > I choose to be consistent with the Math.floor behavior. > > Roger > > > > > thanks > Stephen > > > On 22 February 2012 14:24, Roger Riggs wrote: > > Hi, > > 6282196 There should be Math.mod(number, modulo) methods > > > Requests that floor and modulus methods be provided for primitive types. > Floor division is pretty straight-forward, rounding toward minus infinity. > For modulus of int and long, the sign and range follow ?the exiting floor > method > in java.util.Math and satisfy the relation that mod(x, y) = (x - floorDiv(x, > y) * y). > > Please review and comment, > ? ?http://cr.openjdk.java.net/~rriggs/6282196.1/ > > Thanks, Roger > > > From forax at univ-mlv.fr Wed Feb 22 18:01:43 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 22 Feb 2012 19:01:43 +0100 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F44CE8D.3050403@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> Message-ID: <4F452D87.9050709@univ-mlv.fr> Hi Kurchi, hi all, in ReliableLog, you can get ride of the @SupressWarnings, getLogClassConstructor should return a Constructor and not a Constructor, the field logClassConstructor should be typed Constructor and in openLogFile, the log should be constructed like this log = (logClassConstructor == null ? new LogFile(logName, "rw") : (LogFile)logClassConstructor.newInstance(logName, "rw")); The idea is that a cast on a LogFile is typesafe but not a cast on a Constructor. In the same file, the try-with-resources is not correcly used try (DataOutputStream out = new DataOutputStream(new FileOutputStream(fName(name)))) { writeInt(out, version); } should be try (FileOutputStream fos = new FileOutputStream(fName(name)); DataOutputStream out = new DataOutputStream(fos)) { writeInt(out, version); } because if new DataOutputStream throws an exception, the FileOutputStream will not be closed. Basically, all stream filters should have it's own line in a try-with-resources. cheers, R?mi On 02/22/2012 12:16 PM, Chris Hegarty wrote: > Kurchi, > > Great work. I've been through the complete webrev and I think it looks > good. Just a few minor comments: > > - there are API changes, but only in sun private implementation > classes, so this should be fine. > > - Minor indentation nit where method declaration return type > was generified. The method args on subsequent lines should be > equally indented. Example LoaderHandler.java L152: > > public static Class loadClass(String codebase, String name, > >>>> ClassLoader defaultLoader) > > - There are opportunities to use auto boxing/unboxing > > >: diff RMIGenerator.java > 99c99 > < version = versionOptions.get(arg); > --- > > version = (versionOptions.get(arg)).intValue(); > > ConnectionMultiplexer.java > >: diff ConnectionMultiplexer.java ConnectionMultiplexer.java.1 > 133a134 > < Integer idObj; > 150c151,152 > > info = connectionTable.get(id); > --- > < idObj = new Integer(id); > < info = connectionTable.get(idObj); > 158c160 > > connectionTable.put(id, info); > --- > < connectionTable.put(idObj, info); > ..... > > -Chris. > > On 22/02/2012 05:50, Kurchi Hazra wrote: >> Corrected the subject line. >> >> >> Hi, >> >> The following webrev removes warnings in sun.rmi.* packages. I have >> neglected nearly all >> deprecation warnings, since this code uses deprecated classes such as >> java.rmi.server.LogStream >> with no suggested replacements. I have included -Xlint:all,-deprecation >> as an option instead >> in the appropriate Makefiles. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146763 >> Webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.00/ >> >> >> Thanks, >> Kurchi From darryl.mocek at oracle.com Wed Feb 22 18:14:21 2012 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Wed, 22 Feb 2012 10:14:21 -0800 (PST) Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F448225.60009@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> Message-ID: <4F45307D.10907@oracle.com> Hi Kurchi, overall the changes look good. I have a few comments: - TCPTransport: Lines #552/553: I actually prefer the way it was as I think it's more readable. - RMIMasterSocketFactory: Line #244: The comment was removed, was there a reason for this? - HttpInputStream: Line #73: Why even have this if statement? I'd make this a comment instead, something like if contentLengthFound, we should probably do something in this case. - CGIHandler: Line #288: Why even have this if statement? I'd make this a comment instead, something like if contentLengthFound, we should probably do something in this case. Darryl On 02/21/2012 09:50 PM, Kurchi Hazra wrote: > Corrected the subject line. > > > Hi, > > The following webrev removes warnings in sun.rmi.* packages. I have > neglected nearly all > deprecation warnings, since this code uses deprecated classes such as > java.rmi.server.LogStream > with no suggested replacements. I have included > -Xlint:all,-deprecation as an option instead > in the appropriate Makefiles. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146763 > Webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.00/ > > > Thanks, > Kurchi From kurchi.subhra.hazra at oracle.com Wed Feb 22 21:25:27 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 22 Feb 2012 13:25:27 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F452D87.9050709@univ-mlv.fr> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> Message-ID: <4F455D47.1080002@oracle.com> Hi Remi, Thanks for your review. Please see my comment: On 2/22/2012 10:01 AM, R?mi Forax wrote: > Hi Kurchi, hi all, > > in ReliableLog, you can get ride of the @SupressWarnings, > getLogClassConstructor should return a Constructor and not a > Constructor, > the field logClassConstructor should be typed Constructor and > in openLogFile, the log should be constructed like this > > log = (logClassConstructor == null ? > new LogFile(logName, "rw") : > (LogFile)logClassConstructor.newInstance(logName, > "rw")); > > > The idea is that a cast on a LogFile is typesafe but not a cast on a > Constructor. If I change the return type to Constructor, I get the following error: ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:122: error: incompatible types logClassConstructor = getLogClassConstructor(); ^ required: Constructor found: Constructor where CAP#1 is a fresh type-variable: CAP#1 extends Object from capture of ? And the following warning: ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:350: warning: [unchecked] unchecked cast cl.getConstructor(String.class, String.class); ^ required: Constructor found: Constructor where CAP#1 is a fresh type-variable: CAP#1 extends Object from capture of ? Thanks, Kurchi > > In the same file, the try-with-resources is not correcly used > > try (DataOutputStream out = new DataOutputStream(new > FileOutputStream(fName(name)))) { > writeInt(out, version); > } > > should be > > try (FileOutputStream fos = new FileOutputStream(fName(name)); > DataOutputStream out = new DataOutputStream(fos)) { > writeInt(out, version); > } > > because if new DataOutputStream throws an exception, the FileOutputStream > will not be closed. > Basically, all stream filters should have it's own line in a > try-with-resources. > > cheers, > R?mi > > On 02/22/2012 12:16 PM, Chris Hegarty wrote: >> Kurchi, >> >> Great work. I've been through the complete webrev and I think it >> looks good. Just a few minor comments: >> >> - there are API changes, but only in sun private implementation >> classes, so this should be fine. >> >> - Minor indentation nit where method declaration return type >> was generified. The method args on subsequent lines should be >> equally indented. Example LoaderHandler.java L152: >> >> public static Class loadClass(String codebase, String name, >> >>>> ClassLoader defaultLoader) >> >> - There are opportunities to use auto boxing/unboxing >> >> >: diff RMIGenerator.java >> 99c99 >> < version = versionOptions.get(arg); >> --- >> > version = (versionOptions.get(arg)).intValue(); >> >> ConnectionMultiplexer.java >> >: diff ConnectionMultiplexer.java ConnectionMultiplexer.java.1 >> 133a134 >> < Integer idObj; >> 150c151,152 >> > info = connectionTable.get(id); >> --- >> < idObj = new Integer(id); >> < info = connectionTable.get(idObj); >> 158c160 >> > connectionTable.put(id, info); >> --- >> < connectionTable.put(idObj, info); >> ..... >> >> -Chris. >> >> On 22/02/2012 05:50, Kurchi Hazra wrote: >>> Corrected the subject line. >>> >>> >>> Hi, >>> >>> The following webrev removes warnings in sun.rmi.* packages. I have >>> neglected nearly all >>> deprecation warnings, since this code uses deprecated classes such as >>> java.rmi.server.LogStream >>> with no suggested replacements. I have included -Xlint:all,-deprecation >>> as an option instead >>> in the appropriate Makefiles. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146763 >>> Webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.00/ >>> >>> >>> Thanks, >>> Kurchi > -- -Kurchi From david.holmes at oracle.com Thu Feb 23 02:44:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Feb 2012 18:44:57 -0800 (PST) Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F44FA3B.8060001@oracle.com> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com> Message-ID: <4F45A829.6030509@oracle.com> On 23/02/2012 12:22 AM, Alan Bateman wrote: > On 22/02/2012 13:25, Se?n Coffey wrote: >> Bug recently reported. We enter infinite recursion on a boundary case >> for Collections.synchronizedList.remove(..) >> >> Fix is a simple equals check in class method before delegating the call. >> >> bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144488 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7144488/ > Sean - the fix looks okay to me but I assume there are other cases, like > with SynchronizedSet and hashCode for example. I don't know if they are > all fixable, at least not the hashCode cases. All of the SynchronizedX.equals methods should be fixed ie SynchronizedSet, SynchronizedList and SynchronizedMap. It should always be valid to ask if a.equals(a). The idiomatic form used elsewhere (CheckedXXX) is: public boolean equals(Object o) { return o == this || list.equals(o); } I'm not a fan of collections containing themselves, but I think it is simple to fix contains(o)/contains[Key]|[Value](o) and remove(o) in a similar way. Though none of the wrapped collections currently handle that case, so I'm okay with not addressing this part. I don't see the recursion potential in hashCode() in the wrappers. David > -Alan. From lana.steuck at oracle.com Thu Feb 23 05:25:59 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:25:59 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b26 for changeset 2accafff224a Message-ID: <20120223052559.7CF2F47648@hg.openjdk.java.net> Changeset: 1533dfab9903 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1533dfab9903 Added tag jdk8-b26 for changeset 2accafff224a ! .hgtags From lana.steuck at oracle.com Thu Feb 23 05:25:59 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:25:59 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b26 for changeset 79f709a099f4 Message-ID: <20120223052601.C861347649@hg.openjdk.java.net> Changeset: 4fffe75e4edd Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4fffe75e4edd Added tag jdk8-b26 for changeset 79f709a099f4 ! .hgtags From lana.steuck at oracle.com Thu Feb 23 05:26:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:03 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b26 for changeset dbb7283c197b Message-ID: <20120223052603.12C034764A@hg.openjdk.java.net> Changeset: 80c47eb83d24 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/80c47eb83d24 Added tag jdk8-b26 for changeset dbb7283c197b ! .hgtags From lana.steuck at oracle.com Thu Feb 23 05:26:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:07 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120223052608.070D04764B@hg.openjdk.java.net> Changeset: 329ace7198ac Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/329ace7198ac Added tag jdk8-b26 for changeset 3518639eab6c ! .hgtags Changeset: 38c037af4127 Author: lana Date: 2012-02-18 16:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/38c037af4127 Merge From lana.steuck at oracle.com Thu Feb 23 05:26:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:12 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120223052620.EA04C4764C@hg.openjdk.java.net> Changeset: fba3cbee0fa3 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fba3cbee0fa3 Added tag jdk8-b26 for changeset b556aa8a99c3 ! .hgtags Changeset: e127334a64fe Author: darcy Date: 2012-02-17 15:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e127334a64fe 7143910: test/tools/apt/Basics/apt.sh fails with 'real' sh Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! test/tools/apt/Basics/apt.sh Changeset: be456f9c64e8 Author: lana Date: 2012-02-18 16:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be456f9c64e8 Merge - make/test/lib/apt.sh - src/share/classes/com/sun/mirror/apt/AnnotationProcessor.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorEnvironment.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorFactory.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorListener.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessors.java - src/share/classes/com/sun/mirror/apt/Filer.java - src/share/classes/com/sun/mirror/apt/Messager.java - src/share/classes/com/sun/mirror/apt/RoundCompleteEvent.java - src/share/classes/com/sun/mirror/apt/RoundCompleteListener.java - src/share/classes/com/sun/mirror/apt/RoundState.java - src/share/classes/com/sun/mirror/apt/package-info.java - src/share/classes/com/sun/mirror/declaration/AnnotationMirror.java - src/share/classes/com/sun/mirror/declaration/AnnotationTypeDeclaration.java - src/share/classes/com/sun/mirror/declaration/AnnotationTypeElementDeclaration.java - src/share/classes/com/sun/mirror/declaration/AnnotationValue.java - src/share/classes/com/sun/mirror/declaration/ClassDeclaration.java - src/share/classes/com/sun/mirror/declaration/ConstructorDeclaration.java - src/share/classes/com/sun/mirror/declaration/Declaration.java - src/share/classes/com/sun/mirror/declaration/EnumConstantDeclaration.java - src/share/classes/com/sun/mirror/declaration/EnumDeclaration.java - src/share/classes/com/sun/mirror/declaration/ExecutableDeclaration.java - src/share/classes/com/sun/mirror/declaration/FieldDeclaration.java - src/share/classes/com/sun/mirror/declaration/InterfaceDeclaration.java - src/share/classes/com/sun/mirror/declaration/MemberDeclaration.java - src/share/classes/com/sun/mirror/declaration/MethodDeclaration.java - src/share/classes/com/sun/mirror/declaration/Modifier.java - src/share/classes/com/sun/mirror/declaration/PackageDeclaration.java - src/share/classes/com/sun/mirror/declaration/ParameterDeclaration.java - src/share/classes/com/sun/mirror/declaration/TypeDeclaration.java - src/share/classes/com/sun/mirror/declaration/TypeParameterDeclaration.java - src/share/classes/com/sun/mirror/declaration/package-info.java - src/share/classes/com/sun/mirror/overview.html - src/share/classes/com/sun/mirror/type/AnnotationType.java - src/share/classes/com/sun/mirror/type/ArrayType.java - src/share/classes/com/sun/mirror/type/ClassType.java - src/share/classes/com/sun/mirror/type/DeclaredType.java - src/share/classes/com/sun/mirror/type/EnumType.java - src/share/classes/com/sun/mirror/type/InterfaceType.java - src/share/classes/com/sun/mirror/type/MirroredTypeException.java - src/share/classes/com/sun/mirror/type/MirroredTypesException.java - src/share/classes/com/sun/mirror/type/PrimitiveType.java - src/share/classes/com/sun/mirror/type/ReferenceType.java - src/share/classes/com/sun/mirror/type/TypeMirror.java - src/share/classes/com/sun/mirror/type/TypeVariable.java - src/share/classes/com/sun/mirror/type/VoidType.java - src/share/classes/com/sun/mirror/type/WildcardType.java - src/share/classes/com/sun/mirror/type/package-info.java - src/share/classes/com/sun/mirror/util/DeclarationFilter.java - src/share/classes/com/sun/mirror/util/DeclarationScanner.java - src/share/classes/com/sun/mirror/util/DeclarationVisitor.java - src/share/classes/com/sun/mirror/util/DeclarationVisitors.java - src/share/classes/com/sun/mirror/util/Declarations.java - src/share/classes/com/sun/mirror/util/SimpleDeclarationVisitor.java - src/share/classes/com/sun/mirror/util/SimpleTypeVisitor.java - src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java - src/share/classes/com/sun/mirror/util/SourcePosition.java - src/share/classes/com/sun/mirror/util/TypeVisitor.java - src/share/classes/com/sun/mirror/util/Types.java - src/share/classes/com/sun/mirror/util/package-info.java - src/share/classes/com/sun/tools/apt/Main.java - src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java - src/share/classes/com/sun/tools/apt/comp/Apt.java - src/share/classes/com/sun/tools/apt/comp/BootstrapAPF.java - src/share/classes/com/sun/tools/apt/comp/PrintAP.java - src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java - src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/apt/main/CommandLine.java - src/share/classes/com/sun/tools/apt/main/Main.java - src/share/classes/com/sun/tools/apt/mirror/AptEnv.java - src/share/classes/com/sun/tools/apt/mirror/apt/AnnotationProcessorEnvironmentImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/MessagerImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/RoundStateImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationMirrorImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeElementDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationValueImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ClassDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ConstructorDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationMaker.java - src/share/classes/com/sun/tools/apt/mirror/declaration/EnumConstantDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/EnumDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ExecutableDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/FieldDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/InterfaceDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/MemberDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/MethodDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/PackageDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ParameterDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/TypeDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/TypeParameterDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/AnnotationTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/ArrayTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/ClassTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/DeclaredTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/EnumTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/InterfaceTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/PrimitiveTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeMaker.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/VoidTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/WildcardTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/TypesImpl.java - src/share/classes/com/sun/tools/apt/resources/apt.properties - src/share/classes/com/sun/tools/apt/resources/apt_ja.properties - src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties - src/share/classes/com/sun/tools/apt/util/Bark.java - test/tools/apt/Basics/Aggregate.java - test/tools/apt/Basics/ClassAnnotations.java - test/tools/apt/Basics/FreshnessApf.java - test/tools/apt/Basics/GenClass.java - test/tools/apt/Basics/Indirect.java - test/tools/apt/Basics/Lacuna.java - test/tools/apt/Basics/MethodAnnotations.java - test/tools/apt/Basics/Milk.java - test/tools/apt/Basics/MisMatch.java - test/tools/apt/Basics/Misc.java - test/tools/apt/Basics/MyMarker.java - test/tools/apt/Basics/MySimple.java - test/tools/apt/Basics/NestedClassAnnotations.java - test/tools/apt/Basics/ParameterAnnotations.java - test/tools/apt/Basics/StaticFieldAnnotations.java - test/tools/apt/Basics/StaticMethodAnnotations.java - test/tools/apt/Basics/TestGetPackageApf.java - test/tools/apt/Basics/TestGetTypeDeclarationApf.java - test/tools/apt/Basics/annot/AnnotMarker.java - test/tools/apt/Basics/annot/AnnotShangri_la.java - test/tools/apt/Basics/annot/AnnotSimple.java - test/tools/apt/Basics/annot/annot2/AnnotMarker2.java - test/tools/apt/Basics/annot/annot2/AnnotSimple2.java - test/tools/apt/Basics/com.sun.mirror.apt.AnnotationProcessorFactory - test/tools/apt/Basics/foo/bar/Baz.java - test/tools/apt/Basics/foo/bar/Quux.java - test/tools/apt/Basics/golden.txt - test/tools/apt/Basics/goldenAggregate.txt - test/tools/apt/Basics/p1/p2.java - test/tools/apt/Basics/p1/p2/C1.java - test/tools/apt/Basics/print.sh - test/tools/apt/Compile/ClassDeclApf.java - test/tools/apt/Compile/ClassDeclApf2.java - test/tools/apt/Compile/Dummy1.java - test/tools/apt/Compile/ErrorAPF.java - test/tools/apt/Compile/HelloAnnotation.java - test/tools/apt/Compile/HelloWorld.java - test/tools/apt/Compile/Round1Apf.java - test/tools/apt/Compile/Round2Apf.java - test/tools/apt/Compile/Round3Apf.java - test/tools/apt/Compile/Round4Apf.java - test/tools/apt/Compile/Rounds.java - test/tools/apt/Compile/StaticApf.java - test/tools/apt/Compile/WarnAPF.java - test/tools/apt/Compile/WrappedStaticApf.java - test/tools/apt/Compile/compile.sh - test/tools/apt/Compile/golden.txt - test/tools/apt/Compile/goldenFactory.txt - test/tools/apt/Compile/goldenWarn.txt - test/tools/apt/Compile/servicesRound1 - test/tools/apt/Compile/servicesRound2 - test/tools/apt/Compile/servicesRound3 - test/tools/apt/Compile/servicesRound4 - test/tools/apt/Compile/servicesStaticApf - test/tools/apt/Compile/src/AhOneClass.java - test/tools/apt/Compile/src/AndAhTwoClass.java - test/tools/apt/Compile/src/Round1Class.java - test/tools/apt/Discovery/Dee.java - test/tools/apt/Discovery/Dum.java - test/tools/apt/Discovery/Empty.java - test/tools/apt/Discovery/PhantomTouch.java - test/tools/apt/Discovery/PhantomUpdate.java - test/tools/apt/Discovery/Touch.java - test/tools/apt/Discovery/discovery.sh - test/tools/apt/Discovery/servicesBadTouch - test/tools/apt/Discovery/servicesPhantomTouch - test/tools/apt/Discovery/servicesTouch - test/tools/apt/Discovery/servicesTweedle - test/tools/apt/Misc/Marked.java - test/tools/apt/Misc/Marker.java - test/tools/apt/Misc/Misc.java - test/tools/apt/Misc/misc.sh - test/tools/apt/Misc/servicesMisc - test/tools/apt/Options/Marked.java - test/tools/apt/Options/Marker.java - test/tools/apt/Options/OptionChecker.java - test/tools/apt/Options/options.sh - test/tools/apt/Options/servicesOptions - test/tools/apt/Scanners/Counter.java - test/tools/apt/Scanners/MemberOrderApf.java - test/tools/apt/Scanners/Order.java - test/tools/apt/Scanners/Scanner.java - test/tools/apt/Scanners/TestEnum.java - test/tools/apt/Scanners/VisitOrder.java - test/tools/apt/Scanners/scanner.sh - test/tools/apt/Scanners/servicesScanner - test/tools/apt/lib/Ignore.java - test/tools/apt/lib/Test.java - test/tools/apt/lib/TestProcessor.java - test/tools/apt/lib/TestProcessorFactory.java - test/tools/apt/lib/Tester.java - test/tools/apt/mirror/declaration/AnnoMirror.java - test/tools/apt/mirror/declaration/AnnoTypeDecl.java - test/tools/apt/mirror/declaration/AnnoTypeElemDecl.java - test/tools/apt/mirror/declaration/AnnoVal.java - test/tools/apt/mirror/declaration/ClassDecl.java - test/tools/apt/mirror/declaration/ConstExpr.java - test/tools/apt/mirror/declaration/ConstructorDecl.java - test/tools/apt/mirror/declaration/EnumDecl.java - test/tools/apt/mirror/declaration/FieldDecl.java - test/tools/apt/mirror/declaration/GetAnno.java - test/tools/apt/mirror/declaration/InterfaceDecl.java - test/tools/apt/mirror/declaration/MethodDecl.java - test/tools/apt/mirror/declaration/PackageDecl.java - test/tools/apt/mirror/declaration/ParameterDecl.java - test/tools/apt/mirror/declaration/pkg1/AClass.java - test/tools/apt/mirror/declaration/pkg1/AnAnnoType.java - test/tools/apt/mirror/declaration/pkg1/AnEnum.java - test/tools/apt/mirror/declaration/pkg1/AnInterface.java - test/tools/apt/mirror/declaration/pkg1/package-info.java - test/tools/apt/mirror/declaration/pkg1/pkg2/AnInterface.java - test/tools/apt/mirror/declaration/pkg1/pkg2/package.html - test/tools/apt/mirror/type/AnnoTyp.java - test/tools/apt/mirror/type/ArrayTyp.java - test/tools/apt/mirror/type/ClassTyp.java - test/tools/apt/mirror/type/EnumTyp.java - test/tools/apt/mirror/type/InterfaceTyp.java - test/tools/apt/mirror/type/PrimitiveTyp.java - test/tools/apt/mirror/type/TypeVar.java - test/tools/apt/mirror/type/WildcardTyp.java - test/tools/apt/mirror/util/Overrides.java - test/tools/apt/mirror/util/TypeCreation.java From lana.steuck at oracle.com Thu Feb 23 05:26:31 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:31 +0000 Subject: hg: jdk8/tl/hotspot: 69 new changesets Message-ID: <20120223052854.021A74764D@hg.openjdk.java.net> Changeset: 3c4621be5149 Author: amurillo Date: 2012-02-06 12:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c4621be5149 7143122: new hotspot build - hs23-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 869be5c8882e Author: phh Date: 2012-02-03 17:21 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/869be5c8882e 7142586: Cannot build on Solaris 11 due to use of ia_nice Summary: Delete the single use of ia_nice in os_solaris.cpp Reviewed-by: kamg, kvn ! src/os/solaris/vm/os_solaris.cpp Changeset: c77d473e71f7 Author: ohrstrom Date: 2012-01-31 13:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c77d473e71f7 7132779: build-infra merge: Enable ccache to work for most developer builds. Summary: When a build number is not specified, the JRE_RELEASE_VERSION define contains a date and timestamp. Thus ccache cannot cache the object files for longer than a minute since the define is passed to the compilation of all source files. This change passes JRE_RELEASE_VERSION only to vm_version.cpp and adds a function jre_release_version() to Abstract_VM_Version. This allows all other source files to be ccached. Reviewed-by: ohair, rottenha Contributed-by: fredrik.ohrstrom at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 719f7007c8e8 Author: erikj Date: 2012-02-06 09:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/719f7007c8e8 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Summary: Cleaned up make variables for compilers and linker to consistently use CXX for C++ compiler, CC for C compiler and LD for linker. Reviewed-by: dholmes, ohrstrom ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make Changeset: ea677dbdd883 Author: fparain Date: 2012-02-07 12:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea677dbdd883 Merge Changeset: 5e9fba4e8718 Author: kvn Date: 2012-02-07 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e9fba4e8718 7142167: MAC: _get_previous_fp broken on bsd with llvm-gcc Summary: LLVM-GCC (__llvm__) should use the same _get_previous_fp implementation as __clang__ (as is the case for os::current_stack_pointer). Reviewed-by: twisti, never, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: b9bc6cae88f2 Author: kvn Date: 2012-02-07 16:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9bc6cae88f2 7143491: G1 C2 CTW: assert(p2x->outcnt() == 2) failed: expects 2 users: Xor and URShift nodes Summary: Adjust the assert and code in eliminate_card_mark() method for case when stored value is NULL. Reviewed-by: iveresov, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp Changeset: c742b0b47fe5 Author: roland Date: 2012-02-08 09:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c742b0b47fe5 7119286: JSR292: SIGSEGV in JNIHandleBlock::release_block(JNIHandleBlock*, Thread*)+0x3c Summary: unaligned stack in throw_NullPointerException_at_call_entry(). Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 2f985b6ce7ff Author: jrose Date: 2012-02-09 18:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f985b6ce7ff Merge Changeset: 1ac084126285 Author: dlong Date: 2012-01-24 18:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ac084126285 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log Summary: Relax assert to allow the VMThread to close the log while the compiler thread is still writing to it. Reviewed-by: dholmes, never Contributed-by: dean.long at oracle.com ! src/share/vm/utilities/xmlstream.cpp Changeset: d851f3714641 Author: dholmes Date: 2012-01-25 19:26 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d851f3714641 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: a79cb7c55012 Author: jiangli Date: 2012-01-25 17:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a79cb7c55012 7132690: InstanceKlass:_reference_type should be u1 type Summary: Change InstanceKlass::_reference_type to u1 type. Reviewed-by: dholmes, coleenp, acorn Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f3fa16bd7159 Author: bobv Date: 2012-01-25 21:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3fa16bd7159 Merge Changeset: b7b8b6d2f97d Author: bpittore Date: 2012-02-06 10:57 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7b8b6d2f97d Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f174909614bd Author: bpittore Date: 2012-02-10 10:55 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f174909614bd Merge ! src/share/vm/opto/library_call.cpp Changeset: d71e662fe037 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d71e662fe037 Merge Changeset: fd3060701216 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd3060701216 Added tag hs23-b15 for changeset d71e662fe037 ! .hgtags Changeset: 087daaec688d Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/087daaec688d Added tag jdk8-b26 for changeset fd3060701216 ! .hgtags Changeset: 094138495da4 Author: amurillo Date: 2012-02-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/094138495da4 7144322: new hotspot build - hs23-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 77a488cd4af2 Author: dlong Date: 2012-02-15 00:51 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77a488cd4af2 7140866: assert(covered) failed: Card for end of new region not committed Summary: resize covered region only after successfully mapping shared archive Reviewed-by: brutisso, ysr Contributed-by: dean.long at oracle.com ! src/share/vm/memory/compactingPermGenGen.cpp Changeset: f9961b6498f9 Author: bpittore Date: 2012-02-15 16:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9961b6498f9 Merge Changeset: 95f6641e38e0 Author: iveresov Date: 2012-02-10 17:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95f6641e38e0 7144296: PS: Optimize nmethods processing Summary: Prunes scavenge roots in code list every young GC, promote objects directly pointed by the code immediately Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp Changeset: caa4652b4414 Author: tonyp Date: 2012-02-14 08:21 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/caa4652b4414 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle Summary: If we try to schedule an initial-mark GC in order to explicit start a conc mark cycle and it gets pre-empted by antoher GC, we should retry the attempt as long as it's appropriate for the GC cause. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: d903bf750e9f Author: johnc Date: 2012-01-18 09:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d903bf750e9f 7129514: time warp warnings after 7117303 Summary: Replace calls to os::javaTimeMillis() that are used to update the milliseconds since the last GC to an equivalent that uses a monotonically non-decreasing time source. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: a9647476d1a4 Author: tonyp Date: 2012-02-15 13:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9647476d1a4 7132029: G1: mixed GC phase lasts for longer than it should Summary: Revamp of the mechanism that chooses old regions for inclusion in the CSet. It simplifies the code and introduces min and max bounds on the number of old regions added to the CSet at each mixed GC to avoid pathological cases. It also ensures that when we do a mixed GC we'll always find old regions to add to the CSet (i.e., it eliminates the case where a mixed GC will collect no old regions which can happen today). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: ab4422d0ed59 Author: jcoomes Date: 2012-02-16 13:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab4422d0ed59 7146343: PS invoke methods should indicate the type of gc done Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp Changeset: 23c0eb012d6f Author: jcoomes Date: 2012-02-16 13:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23c0eb012d6f 6330863: vm/gc/InfiniteList.java fails intermittently due to timeout Summary: in some cases, allocate from the old gen before doing a full gc Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp Changeset: be398bba40e9 Author: stefank Date: 2012-02-17 13:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be398bba40e9 Merge Changeset: 1b0e0f8be510 Author: minqi Date: 2012-02-09 00:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b0e0f8be510 7131006: java/lang/management/ThreadMXBean/ThreadLists.java Reviewed-by: dholmes, acorn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/utilities/preserveException.cpp Changeset: db006a85bf91 Author: zgu Date: 2012-02-09 10:16 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db006a85bf91 7141259: Native stack is missing in hs_err Summary: Code cleanup and creating a private decoder for error handler, since it can be triggered from in signal handler, where no lock can be taken Reviewed-by: dholmes, kamg, acorn, coleenp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/vmError.hpp Changeset: ea527c5cde03 Author: zgu Date: 2012-02-09 07:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea527c5cde03 Merge Changeset: 54d3535a6dd3 Author: poonam Date: 2012-02-12 19:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54d3535a6dd3 7009098: SA cannot open core files larger than 2GB on Linux 32-bit Summary: Added Large File Support by compiling libsaproc.so with -D_FILE_OFFSET_BITS=64, and a small change with which SA should first load libraries from the path specified with SA_ALTROOT. Reviewed-by: dholmes, kevinw, dcubed, minqi ! agent/src/os/linux/Makefile ! agent/src/os/linux/libproc_impl.c ! make/linux/makefiles/saproc.make Changeset: 1bb2838e2fc1 Author: fparain Date: 2012-02-13 06:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1bb2838e2fc1 Merge Changeset: 849412a95e45 Author: coleenp Date: 2012-02-13 12:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/849412a95e45 7059899: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh ! src/cpu/x86/vm/globals_x86.hpp Changeset: 1891640ca63f Author: fparain Date: 2012-02-14 06:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1891640ca63f 7143760: Memory leak in GarbageCollectionNotifications Reviewed-by: dholmes, dcubed, kamg ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp Changeset: a9831b955a0a Author: kamg Date: 2012-02-13 14:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9831b955a0a 7069991: Setup make/jprt.properties files for jdk8 Summary: Change default release value to jdk8 (but overrideable) Reviewed-by: phh, jcoomes, dholmes, ohair ! make/jprt.properties Changeset: a9ac4910e7f2 Author: kamg Date: 2012-02-14 15:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9ac4910e7f2 Merge Changeset: 28d91e43ab6d Author: coleenp Date: 2012-02-14 16:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28d91e43ab6d 7145587: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV (sparc version) Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh, dcubed, kamg, dsamersoff ! src/cpu/sparc/vm/globals_sparc.hpp Changeset: cf772dff4bfd Author: coleenp Date: 2012-02-14 18:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cf772dff4bfd Merge Changeset: b8a4e1d372a0 Author: kamg Date: 2012-02-14 20:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b8a4e1d372a0 7145589: First JSDT provider creation fails Summary: 0 is a successful return from an ioctl() call Reviewed-by: dcubed, phh, dsamersoff ! src/share/vm/runtime/dtraceJSDT.cpp Changeset: 91a81502a27d Author: kamg Date: 2012-02-15 00:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91a81502a27d Merge Changeset: 2b150750d53d Author: sspitsyn Date: 2012-02-14 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b150750d53d 7130993: nsk/jdi/ReferenceType/instances/instances004 fails with JFR: assert(ServiceUtil::visible_oop(obj)) Summary: Skip reporting invisible refs in iterate_over_object to avoid assert(ServiceUtil::visible_oop(obj)) Reviewed-by: dcubed, mgronlun, rbackman Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: cd239a88b90c Author: minqi Date: 2012-02-14 20:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd239a88b90c Merge Changeset: 64fc5ac1b770 Author: minqi Date: 2012-02-14 23:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/64fc5ac1b770 Merge Changeset: f1cb6f9cfe21 Author: fparain Date: 2012-02-15 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1cb6f9cfe21 7145243: Need additional specializations for argument parsing framework Reviewed-by: acorn, fparain Contributed-by: nils.loodin at oracle.com ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp Changeset: 4a24c4f648bd Author: phh Date: 2012-02-16 13:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a24c4f648bd 7142113: Add Ivy Bridge to the known Intel x86 cpu families Summary: In vm_version_x86.hpp, add and use CPU_MODEL_IVYBRIDGE_EP, and restrict is_intel_tsc_synced_at_init() to EP models. Reviewed-by: kvn, acorn ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: 7df3125953cb Author: coleenp Date: 2012-02-16 15:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7df3125953cb 7146354: Re-enable Compressed OOPs after 7118647 is resolved Summary: Relax the assertion to simply check for COOP mode rather than an exact address. Reviewed-by: coleenp, kvn, phh, dcubed Contributed-by: james.melvin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: df4927a3b82e Author: coleenp Date: 2012-02-16 17:19 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df4927a3b82e Merge Changeset: d3384450b649 Author: fparain Date: 2012-02-17 06:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d3384450b649 Merge Changeset: 73df3733f2eb Author: kvn Date: 2012-02-10 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73df3733f2eb 7129284: +DoEscapeAnalysis regression w/ early build of 7u4 (HotSpot 23) on Linux Summary: Removed code which tried to create edges from fields of destination objects of arraycopy to fields of source objects. Added 30 sec time limit for EA graph construction. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: de34c646c3f7 Author: kvn Date: 2012-02-10 17:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de34c646c3f7 7140985: HSDIS does not handle caller options correctly Summary: Fix typo. Reviewed-by: jrose, kvn Contributed-by: Andrew Haley ! src/share/tools/hsdis/hsdis.c Changeset: 45a1bf98f1bb Author: twisti Date: 2012-02-13 02:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/45a1bf98f1bb 7141329: Strange values of stack_size in -XX:+TraceMethodHandles output Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f09ae3853e3b Author: twisti Date: 2012-02-13 04:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f09ae3853e3b 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk Reviewed-by: rbackman, jrose, dholmes ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/top.make ! make/defs.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/top.make Changeset: b522995d91f0 Author: roland Date: 2012-02-14 09:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b522995d91f0 7144405: JumbleGC002 assert(m->offset() == pc_offset) failed: oopmap not found Summary: oop map needs pc stored in frame anchor in StubGenerator::generate_throw_exception() Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 8f4eb44b3b76 Author: never Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f4eb44b3b76 7143061: nsk/stress/stack/b4525850 crash VM Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp Changeset: 80107dc493db Author: roland Date: 2012-02-15 09:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/80107dc493db 7126041: jdk7u4 b05 and b06 crash with RubyMine 3.2.4, works well with b04 Summary: Goto that replaces a If mistaken to be a back branch and triggers erroneous OSR compilation. Reviewed-by: never, iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 09d00c18e323 Author: never Date: 2012-02-15 10:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/09d00c18e323 7145537: minor tweaks to LogEvents Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp Changeset: cfdfbeac0a5b Author: iveresov Date: 2012-02-15 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfdfbeac0a5b 7145345: Code cache sweeper must cooperate with safepoints Summary: Safepoint in the sweeper loop in necessary Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 69333a2fbae2 Author: iveresov Date: 2012-02-15 16:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69333a2fbae2 7142680: default GC affected by jvm path Summary: Removed old tiered code Reviewed-by: never, kvn ! src/share/vm/runtime/arguments.cpp Changeset: fd8114661503 Author: kvn Date: 2012-02-15 21:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd8114661503 7125136: SIGILL on linux amd64 in gc/ArrayJuggle/Juggle29 Summary: For C2 moved saving EBP after ESP adjustment. For C1 generated 5 byte nop instruction first if needed. Reviewed-by: never, twisti, azeemj ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/output.cpp Changeset: c7401dcad8bf Author: roland Date: 2012-02-16 09:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7401dcad8bf 7143038: SIGSEGV in assert_equal / LinearScan::assign_reg_num Summary: forced exit may destory global objects that are still in use. Reviewed-by: twisti, never, kvn ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp Changeset: ad3b47344802 Author: never Date: 2012-02-16 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad3b47344802 7144318: GCLocker assert failure: assert(_needs_gc || SafepointSynchronize::is_at_safepoint( Reviewed-by: kvn, twisti ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp Changeset: 9b8ce46870df Author: kvn Date: 2012-02-16 17:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b8ce46870df 7145346: VerifyStackAtCalls is broken Summary: Replace call_epilog() encoding with macroassembler use. Moved duplicated code to x86.ad. Fixed return_addr() definition. Reviewed-by: never ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_32.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/opto/chaitin.cpp Changeset: 72c425c46102 Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72c425c46102 7146729: nightly failure after 7141200: tty is sometimes null during shutdown of main thread Reviewed-by: kvn ! src/share/vm/utilities/events.hpp Changeset: 15085a6eb50c Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15085a6eb50c Merge ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/runtime/arguments.cpp Changeset: f92a171cf007 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f92a171cf007 Merge Changeset: 98cd09d11a21 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98cd09d11a21 Added tag hs23-b16 for changeset f92a171cf007 ! .hgtags Changeset: 931e5f39e365 Author: kvn Date: 2012-02-20 13:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/931e5f39e365 7147064: assert(allocates2(pc)) failed: not in CodeBuffer memory: 0xffffffff778d9d60 <= 0xffffffff778da69c Summary: Increase size of deopt_blob and uncommon_trap_blob by size of stack bang code (SPARC). Reviewed-by: azeemj, iveresov, never, phh ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 3b24e7e01d20 Author: jcoomes Date: 2012-02-20 22:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b24e7e01d20 Added tag hs23-b16 for changeset 931e5f39e365 ! .hgtags From lana.steuck at oracle.com Thu Feb 23 05:26:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:54 +0000 Subject: hg: jdk8/tl/jdk: 21 new changesets Message-ID: <20120223053034.269E347650@hg.openjdk.java.net> Changeset: 4196fc971f65 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4196fc971f65 Added tag jdk8-b26 for changeset 5aca406e87cb ! .hgtags Changeset: 7a5c8c6f1c6b Author: prr Date: 2012-02-03 09:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a5c8c6f1c6b 7141914: Draw glyph cause JVM crash Reviewed-by: bae, igor ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java Changeset: 996cd6e8d00e Author: lana Date: 2012-02-09 19:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/996cd6e8d00e Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: a06fd6ada85c Author: prr Date: 2012-02-14 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a06fd6ada85c 7143612: improve backwards compatibility of OSIS post-CR6887286 Reviewed-by: flar, prr Contributed-by: david.buck at oracle.com ! src/share/classes/sun/awt/image/OffScreenImageSource.java Changeset: 45ce82d366ec Author: anthony Date: 2012-02-02 17:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/45ce82d366ec 7132194: GtkFileDialog does not point to the correct file(s) is Recent Files are used. Summary: Handle the file list differently if gtk_file_chooser_get_current_folder() returns NULL Reviewed-by: anthony Contributed-by: Matthew Smith ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: 10fa63972ad5 Author: rupashka Date: 2012-02-03 17:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10fa63972ad5 7141573: JProgressBar resize exception, if setStringPainted in Windows LAF Reviewed-by: malenkov ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsProgressBarUI.java + test/javax/swing/JProgressBar/7141573/bug7141573.java Changeset: 34571be262e9 Author: rupashka Date: 2012-02-03 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34571be262e9 7071775: javax/swing/JFileChooser/6396844/TwentyThousandTest.java failed on winxp Reviewed-by: alexp ! test/javax/swing/JFileChooser/6396844/TwentyThousandTest.java Changeset: 1880e8cc89b8 Author: rupashka Date: 2012-02-08 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1880e8cc89b8 7138665: JOptionPane.getValue() unexpected change between JRE 1.6 and JRE 1.7 Reviewed-by: alexp ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java + test/javax/swing/JOptionPane/7138665/bug7138665.java Changeset: d2e067142112 Author: bagiras Date: 2012-02-08 18:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d2e067142112 7132367: [macosx] ChoiceMouseWheelTest should be adapted for mac toolkit Reviewed-by: art ! test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java Changeset: d43447758eba Author: rupashka Date: 2012-02-09 14:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d43447758eba 7143857: Memory leak in javax.swing.plaf.synth.SynthTreeUI Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java Changeset: 403e3bb8a162 Author: rupashka Date: 2012-02-09 18:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/403e3bb8a162 7142955: DefaultTreeCellRenderer doesn't honor 'Tree.rendererFillBackground' LAF property Reviewed-by: malenkov ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java + test/javax/swing/tree/DefaultTreeCellRenderer/7142955/bug7142955.java Changeset: a3b50244bd10 Author: chegar Date: 2012-02-10 11:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3b50244bd10 7144475: fix some warnings in java.awt, javax.print.attribute.standard, and sun.beans.infos Reviewed-by: chegar, prr, alanb, anthony Contributed-by: Prasannaa , Martijn Verburg , Goerge Albrecht , Graham Allan , Iordanis Giannakakis , Jose Llarena , Abrahamn Marin Perez ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/share/classes/sun/beans/infos/ComponentBeanInfo.java Changeset: 55adee49df8e Author: alexsch Date: 2012-02-10 18:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55adee49df8e 7109991: SwingUtilities.isXMouseButton behaves unexpectedly starting from JDK8 b08 Reviewed-by: rupashka ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java Changeset: de74d3310e96 Author: lana Date: 2012-02-09 23:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de74d3310e96 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 081a44952699 Author: lana Date: 2012-02-10 10:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/081a44952699 Merge Changeset: 3f4701d08418 Author: bagiras Date: 2012-02-13 17:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f4701d08418 7143070: test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java freezes on exit Reviewed-by: anthony ! test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java Changeset: a1dc74291966 Author: alexsch Date: 2012-02-14 18:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1dc74291966 7133577: [macosx] closed/javax/swing/JTree/4314199/bug4314199.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTree/4314199/bug4314199.html + test/javax/swing/JTree/4314199/bug4314199.java Changeset: 24e30ae2a192 Author: lana Date: 2012-02-15 15:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24e30ae2a192 Merge Changeset: 2a3f026b3a29 Author: lana Date: 2012-02-15 15:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a3f026b3a29 Merge - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java - src/share/classes/com/sun/management/DiagnosticCommandInfo.java - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java - test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java Changeset: c68342532e2e Author: lana Date: 2012-02-18 16:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c68342532e2e Merge - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java - src/share/classes/com/sun/management/DiagnosticCommandInfo.java - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java - test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java Changeset: 6a5d6b2800f6 Author: lana Date: 2012-02-22 16:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a5d6b2800f6 Merge From Alan.Bateman at oracle.com Thu Feb 23 09:55:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Feb 2012 09:55:26 +0000 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F45A829.6030509@oracle.com> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com> <4F45A829.6030509@oracle.com> Message-ID: <4F460D0E.9090604@oracle.com> On 23/02/2012 02:44, David Holmes wrote: > > All of the SynchronizedX.equals methods should be fixed ie > SynchronizedSet, SynchronizedList and SynchronizedMap. It should > always be valid to ask if a.equals(a). The idiomatic form used > elsewhere (CheckedXXX) is: > > public boolean equals(Object o) { return o == this || list.equals(o); } > > I'm not a fan of collections containing themselves, but I think it is > simple to fix contains(o)/contains[Key]|[Value](o) and remove(o) in a > similar way. Though none of the wrapped collections currently handle > that case, so I'm okay with not addressing this part. > > I don't see the recursion potential in hashCode() in the wrappers. The hashCode of a Set requires summing the hash codes of each of the elements so it can't work for the case that a set contains itself. Anyway, I think the best we can do it to have the equals methods use the above form. I wasn't aware of the warning in List that Sean pointed out and maybe there should be similar warnings elsewhere. -Alan From david.holmes at oracle.com Thu Feb 23 09:56:58 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Feb 2012 19:56:58 +1000 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F460D0E.9090604@oracle.com> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com> <4F45A829.6030509@oracle.com> <4F460D0E.9090604@oracle.com> Message-ID: <4F460D6A.4080303@oracle.com> On 23/02/2012 7:55 PM, Alan Bateman wrote: > On 23/02/2012 02:44, David Holmes wrote: >> >> All of the SynchronizedX.equals methods should be fixed ie >> SynchronizedSet, SynchronizedList and SynchronizedMap. It should >> always be valid to ask if a.equals(a). The idiomatic form used >> elsewhere (CheckedXXX) is: >> >> public boolean equals(Object o) { return o == this || list.equals(o); } >> >> I'm not a fan of collections containing themselves, but I think it is >> simple to fix contains(o)/contains[Key]|[Value](o) and remove(o) in a >> similar way. Though none of the wrapped collections currently handle >> that case, so I'm okay with not addressing this part. >> >> I don't see the recursion potential in hashCode() in the wrappers. > The hashCode of a Set requires summing the hash codes of each of the > elements so it can't work for the case that a set contains itself. Right, but that's a general problem with collections, not with the wrappers specifically. Cheers, David > Anyway, I think the best we can do it to have the equals methods use the > above form. I wasn't aware of the warning in List that Sean pointed out > and maybe there should be similar warnings elsewhere. > > -Alan From dl at cs.oswego.edu Thu Feb 23 12:41:53 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 23 Feb 2012 07:41:53 -0500 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F45A829.6030509@oracle.com> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com> <4F45A829.6030509@oracle.com> Message-ID: <4F463411.7020806@cs.oswego.edu> On 02/22/12 21:44, David Holmes wrote: > I'm not a fan of collections containing themselves, but I think it is simple to > fix contains(o)/contains[Key]|[Value](o) and remove(o) in a similar way. Though > none of the wrapped collections currently handle that case, so I'm okay with not > addressing this part. > It was a deliberate decision not to include any evasive schemes for collections that contain themselves, because the problem is unsolvable in general. The patch addresses those that directly contain themselves, but not the transitive closure, as in: c1 contains c2 that in turn contains c1. Our take was that it is a feature, not a bug, that anyone using equals or hashCode in such cases hits infinite recursion. People are free to change policies about this, but do bear in mind that any changes along these lines are intrinsically incomplete. (Although for pre-collections (Java1.1) legacy compatibility reasons, java.util.Hashtable.hashCode does include an ugly stopgap to avoid infinite recursion in the direct case.) -Doug From sean.coffey at oracle.com Thu Feb 23 14:46:50 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 23 Feb 2012 14:46:50 +0000 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F460D6A.4080303@oracle.com> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com> <4F45A829.6030509@oracle.com> <4F460D0E.9090604@oracle.com> <4F460D6A.4080303@oracle.com> Message-ID: <4F46515A.9000904@oracle.com> ok, I've updated the changes (and bug synopsis) based on comments. equals method tweaked for : Collections.SynchronizedList Collections.SynchronizedSet Collections.SynchronizedMap Collections.UnmodifiableEntry Testcase updated also. JCK java_util tests run also. http://cr.openjdk.java.net/~coffeys/webrev.7144488.1/ regards, Sean. On 23/02/2012 09:56, David Holmes wrote: > On 23/02/2012 7:55 PM, Alan Bateman wrote: >> On 23/02/2012 02:44, David Holmes wrote: >>> >>> All of the SynchronizedX.equals methods should be fixed ie >>> SynchronizedSet, SynchronizedList and SynchronizedMap. It should >>> always be valid to ask if a.equals(a). The idiomatic form used >>> elsewhere (CheckedXXX) is: >>> >>> public boolean equals(Object o) { return o == this || list.equals(o); } >>> >>> I'm not a fan of collections containing themselves, but I think it is >>> simple to fix contains(o)/contains[Key]|[Value](o) and remove(o) in a >>> similar way. Though none of the wrapped collections currently handle >>> that case, so I'm okay with not addressing this part. >>> >>> I don't see the recursion potential in hashCode() in the wrappers. >> The hashCode of a Set requires summing the hash codes of each of the >> elements so it can't work for the case that a set contains itself. > > Right, but that's a general problem with collections, not with the > wrappers specifically. > > Cheers, > David > >> Anyway, I think the best we can do it to have the equals methods use the >> above form. I wasn't aware of the warning in List that Sean pointed out >> and maybe there should be similar warnings elsewhere. >> >> -Alan From frederic.parain at oracle.com Thu Feb 23 15:36:39 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 23 Feb 2012 16:36:39 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale Message-ID: <4F465D07.5000302@oracle.com> This a simple fix to solve CR 6988220: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220 The use of String.intern() in the ObjectName class prevents the class the scale well when more than 20K ObjectNames are managed. The fix simply removes the use of String.intern(), and uses regular String instead. The Object.equals() method is modified too to make a regular String comparison. The complexity of this method now depends on the length of the ObjectName's canonical name, and is not impacted any more by the number of ObjectName instances being handled. The Webrev: http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ I've tested this fix with the jdk_lang and jdk_management test suites. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From vitalyd at gmail.com Thu Feb 23 15:58:47 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2012 10:58:47 -0500 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F465D07.5000302@oracle.com> References: <4F465D07.5000302@oracle.com> Message-ID: Hi Frederic, Just curious - why are you checking string equality via compareTo() instead of equals()? Thanks Sent from my phone On Feb 23, 2012 10:37 AM, "Frederic Parain" wrote: > This a simple fix to solve CR 6988220: > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6988220 > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~**fparain/6988220/webrev.00/ > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com > > From frederic.parain at oracle.com Thu Feb 23 17:01:26 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 23 Feb 2012 18:01:26 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com> Message-ID: <4F4670E6.3040407@oracle.com> No particular reason. But after thinking more about it, equals() should be a better choice, clearer code, and the length check in equals() implementation is likely to help performance of ObjectName's comparisons as ObjectNames are often long with a common section at the beginning. I've updated the webrev: http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ Thanks, Fred On 2/23/12 4:58 PM, Vitaly Davidovich wrote: > Hi Frederic, > > Just curious - why are you checking string equality via compareTo() > instead of equals()? > > Thanks > > Sent from my phone > > On Feb 23, 2012 10:37 AM, "Frederic Parain" > wrote: > > This a simple fix to solve CR 6988220: > http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 > > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ > > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From joe.darcy at oracle.com Thu Feb 23 17:53:29 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 23 Feb 2012 17:53:29 +0000 Subject: hg: jdk8/tl/langtools: 7148025: javac should not warn about InterrupttedException on the declaration of AutoCloseable itself Message-ID: <20120223175333.927C347658@hg.openjdk.java.net> Changeset: 3ad851a7e884 Author: darcy Date: 2012-02-23 09:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ad851a7e884 7148025: javac should not warn about InterrupttedException on the declaration of AutoCloseable itself Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java From schlosna at gmail.com Thu Feb 23 18:46:25 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 23 Feb 2012 13:46:25 -0500 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F4670E6.3040407@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> Message-ID: On Thu, Feb 23, 2012 at 12:01 PM, Frederic Parain wrote: > No particular reason. But after thinking more about it, > equals() should be a better choice, clearer code, and > the length check in equals() implementation is likely > to help performance of ObjectName's comparisons as > ObjectNames are often long with a common section at the > beginning. > > I've updated the webrev: > http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ > > Thanks, > > Fred Was the main bottleneck the contention on the interned string pool that prevented concurrent addition of ObjectNames? Are there other places within the JDK where use of intern() should be analyzed for similar scalability bottlenecks? I'm also curious what the heap implications are of no longer using interned strings. A minor nit is that the equals method could be simplified slightly, making it more clear that the canonical names must match for equality: @Override public boolean equals(Object object) { // same object case if (this == object) return true; // object is not an object name case if (!(object instanceof ObjectName)) return false; ObjectName on = (ObjectName) object; return _canonicalName.equals(on._canonicalName); } Thanks, Dave From olivier.lagneau at oracle.com Thu Feb 23 18:52:16 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Thu, 23 Feb 2012 19:52:16 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F4670E6.3040407@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> Message-ID: <4F468AE0.4030406@oracle.com> Hi Frederic, Performance and typo comments. Regarding performance of ObjectName.equals method, which is certainely a frequent call on ObjectNames, I think that using inner fields (Property array for canonical name and domain length) would be more efficient than using String.equals() on these potentially very long strings. Two differents objectNames may often have the same length with different key/properties values, and may often be different only on the last property of the canonical name. The Property array field ca_array (comparing length and property contents) and domain length are good candidates to filter out more efficiently different objectNames, knowing that String.equals will compare every single char of the two char arrays. So for performance purpose, I suggest to filter out different objectNames by doing inner comparisons in the following order : length of the two canonical names, then domain_length, then ca_array size, then its content, and lastly if all of this fails to filter out, then use String.equals. > _canonicalName = (new String(canonical_chars, 0, prop_index)); Typo : useless parentheses. Thanks, Olivier. -- Olivier Lagneau, olivier.lagneau at oracle.com Oracle, Grenoble Engineering Center - France Phone : +33 4 76 18 80 09 Fax : +33 4 76 18 80 23 Frederic Parain said on date 2/23/2012 6:01 PM: > No particular reason. But after thinking more about it, > equals() should be a better choice, clearer code, and > the length check in equals() implementation is likely > to help performance of ObjectName's comparisons as > ObjectNames are often long with a common section at the > beginning. > > I've updated the webrev: > http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ > > Thanks, > > Fred > > On 2/23/12 4:58 PM, Vitaly Davidovich wrote: >> Hi Frederic, >> >> Just curious - why are you checking string equality via compareTo() >> instead of equals()? >> >> Thanks >> >> Sent from my phone >> >> On Feb 23, 2012 10:37 AM, "Frederic Parain" > > wrote: >> >> This a simple fix to solve CR 6988220: >> http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 >> >> >> The use of String.intern() in the ObjectName class prevents >> the class the scale well when more than 20K ObjectNames are >> managed. The fix simply removes the use of String.intern(), >> and uses regular String instead. The Object.equals() method >> is modified too to make a regular String comparison. The >> complexity of this method now depends on the length of >> the ObjectName's canonical name, and is not impacted any >> more by the number of ObjectName instances being handled. >> >> The Webrev: >> http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ >> >> >> I've tested this fix with the jdk_lang and jdk_management >> test suites. >> >> Thanks, >> >> Fred >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com >> >> > From mike.duigou at oracle.com Thu Feb 23 19:04:16 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 23 Feb 2012 11:04:16 -0800 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F46515A.9000904@oracle.com> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com> <4F45A829.6030509@oracle.com> <4F460D0E.9090604@oracle.com> <4F460D6A.4080303@oracle.com> <4F46515A.9000904@oracle.com> Message-ID: <04170C33-3EB2-4547-8275-E26FC2B2D7B1@oracle.com> The revised version looks good to me. It's worth getting all four. On Feb 23 2012, at 06:46 , Se?n Coffey wrote: > ok, > > I've updated the changes (and bug synopsis) based on comments. > equals method tweaked for : > > Collections.SynchronizedList > Collections.SynchronizedSet > Collections.SynchronizedMap > Collections.UnmodifiableEntry > > Testcase updated also. JCK java_util tests run also. > > http://cr.openjdk.java.net/~coffeys/webrev.7144488.1/ > > regards, > Sean. > > On 23/02/2012 09:56, David Holmes wrote: >> On 23/02/2012 7:55 PM, Alan Bateman wrote: >>> On 23/02/2012 02:44, David Holmes wrote: >>>> >>>> All of the SynchronizedX.equals methods should be fixed ie >>>> SynchronizedSet, SynchronizedList and SynchronizedMap. It should >>>> always be valid to ask if a.equals(a). The idiomatic form used >>>> elsewhere (CheckedXXX) is: >>>> >>>> public boolean equals(Object o) { return o == this || list.equals(o); } >>>> >>>> I'm not a fan of collections containing themselves, but I think it is >>>> simple to fix contains(o)/contains[Key]|[Value](o) and remove(o) in a >>>> similar way. Though none of the wrapped collections currently handle >>>> that case, so I'm okay with not addressing this part. >>>> >>>> I don't see the recursion potential in hashCode() in the wrappers. >>> The hashCode of a Set requires summing the hash codes of each of the >>> elements so it can't work for the case that a set contains itself. >> >> Right, but that's a general problem with collections, not with the wrappers specifically. >> >> Cheers, >> David >> >>> Anyway, I think the best we can do it to have the equals methods use the >>> above form. I wasn't aware of the warning in List that Sean pointed out >>> and maybe there should be similar warnings elsewhere. >>> >>> -Alan From eamonn at mcmanus.net Thu Feb 23 19:44:54 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Thu, 23 Feb 2012 11:44:54 -0800 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F468AE0.4030406@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> Message-ID: I am not sure it is worth the complexity of extra checks. Do you have data showing that ObjectName.equals usually returns false? In a successful HashMap lookup, for example, it will usually return true since the equals method is used to guard against collisions, and collisions are rare by design. Meanwhile, String.equals is intrinsic in HotSpot so we may assume that it is highly optimized, and you are giving up that optimization if you use other comparisons. ?amonn On 23 February 2012 10:52, Olivier Lagneau wrote: > Hi Frederic, > > Performance and typo comments. > > Regarding performance of ObjectName.equals method, which is certainely > a frequent call on ObjectNames, I think that using inner fields > (Property array for canonical name and domain length) would be more > efficient > than using String.equals() on these potentially very long strings. > > Two differents objectNames may often have the same length with > different key/properties values, and may often be different only > on the last property of the canonical name. > > The Property array field ca_array (comparing length and property contents) > and domain length are good candidates to filter out more efficiently > different objectNames, knowing that String.equals will compare every > single char of the two char arrays. > > So for performance purpose, I suggest to filter out different objectNames > by doing inner comparisons in the following order : length of the two > canonical names, then domain_length, then ca_array size, then its content, > and lastly if all of this fails to filter out, then use String.equals. > > _canonicalName = (new String(canonical_chars, 0, prop_index)); >> > Typo : useless parentheses. > > Thanks, > Olivier. > > -- Olivier Lagneau, olivier.lagneau at oracle.com > Oracle, Grenoble Engineering Center - France > Phone : +33 4 76 18 80 09 Fax : +33 4 76 18 80 23 > > > > > Frederic Parain said on date 2/23/2012 6:01 PM: > > No particular reason. But after thinking more about it, >> equals() should be a better choice, clearer code, and >> the length check in equals() implementation is likely >> to help performance of ObjectName's comparisons as >> ObjectNames are often long with a common section at the >> beginning. >> >> I've updated the webrev: >> http://cr.openjdk.java.net/~**fparain/6988220/webrev.01/ >> >> Thanks, >> >> Fred >> >> On 2/23/12 4:58 PM, Vitaly Davidovich wrote: >> >>> Hi Frederic, >>> >>> Just curious - why are you checking string equality via compareTo() >>> instead of equals()? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Feb 23, 2012 10:37 AM, "Frederic Parain" >> >> >>> wrote: >>> >>> This a simple fix to solve CR 6988220: >>> http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___**id=6988220 >>> >>> > >>> >>> The use of String.intern() in the ObjectName class prevents >>> the class the scale well when more than 20K ObjectNames are >>> managed. The fix simply removes the use of String.intern(), >>> and uses regular String instead. The Object.equals() method >>> is modified too to make a regular String comparison. The >>> complexity of this method now depends on the length of >>> the ObjectName's canonical name, and is not impacted any >>> more by the number of ObjectName instances being handled. >>> >>> The Webrev: >>> http://cr.openjdk.java.net/~__**fparain/6988220/webrev.00/ >>> >>> > >>> >>> I've tested this fix with the jdk_lang and jdk_management >>> test suites. >>> >>> Thanks, >>> >>> Fred >>> >>> -- >>> Frederic Parain - Oracle >>> Grenoble Engineering Center - France >>> Phone: +33 4 76 18 81 17 >>> Email: Frederic.Parain at oracle.com >> oracle.com > >>> >>> >> > From kurchi.subhra.hazra at oracle.com Thu Feb 23 21:32:14 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 23 Feb 2012 13:32:14 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F452D87.9050709@univ-mlv.fr> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> Message-ID: <4F46B05E.9030103@oracle.com> Updated webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.01/ I have included all changes/suggestion except the Constructor modification that Remi suggested. Darryl: - TCPTransport: Lines #552/553: I actually prefer the way it was as I think it's more readable. RemoteCall is deprecated and I was trying to avoid creating an instance there to remove the resultant Deprecation warning - but I reverted this back - RMIMasterSocketFactory: Line #244: The comment was removed, was there a reason for this? This was a mistake. Changed it now. - Kurchi On 2/22/2012 10:01 AM, R?mi Forax wrote: > Hi Kurchi, hi all, > > in ReliableLog, you can get ride of the @SupressWarnings, > getLogClassConstructor should return a Constructor and not a > Constructor, > the field logClassConstructor should be typed Constructor and > in openLogFile, the log should be constructed like this > > log = (logClassConstructor == null ? > new LogFile(logName, "rw") : > (LogFile)logClassConstructor.newInstance(logName, > "rw")); > > > The idea is that a cast on a LogFile is typesafe but not a cast on a > Constructor. > > In the same file, the try-with-resources is not correcly used > > try (DataOutputStream out = new DataOutputStream(new > FileOutputStream(fName(name)))) { > writeInt(out, version); > } > > should be > > try (FileOutputStream fos = new FileOutputStream(fName(name)); > DataOutputStream out = new DataOutputStream(fos)) { > writeInt(out, version); > } > > because if new DataOutputStream throws an exception, the FileOutputStream > will not be closed. > Basically, all stream filters should have it's own line in a > try-with-resources. > > cheers, > R?mi > > On 02/22/2012 12:16 PM, Chris Hegarty wrote: >> Kurchi, >> >> Great work. I've been through the complete webrev and I think it >> looks good. Just a few minor comments: >> >> - there are API changes, but only in sun private implementation >> classes, so this should be fine. >> >> - Minor indentation nit where method declaration return type >> was generified. The method args on subsequent lines should be >> equally indented. Example LoaderHandler.java L152: >> >> public static Class loadClass(String codebase, String name, >> >>>> ClassLoader defaultLoader) >> >> - There are opportunities to use auto boxing/unboxing >> >> >: diff RMIGenerator.java >> 99c99 >> < version = versionOptions.get(arg); >> --- >> > version = (versionOptions.get(arg)).intValue(); >> >> ConnectionMultiplexer.java >> >: diff ConnectionMultiplexer.java ConnectionMultiplexer.java.1 >> 133a134 >> < Integer idObj; >> 150c151,152 >> > info = connectionTable.get(id); >> --- >> < idObj = new Integer(id); >> < info = connectionTable.get(idObj); >> 158c160 >> > connectionTable.put(id, info); >> --- >> < connectionTable.put(idObj, info); >> ..... >> >> -Chris. >> >> On 22/02/2012 05:50, Kurchi Hazra wrote: >>> Corrected the subject line. >>> >>> >>> Hi, >>> >>> The following webrev removes warnings in sun.rmi.* packages. I have >>> neglected nearly all >>> deprecation warnings, since this code uses deprecated classes such as >>> java.rmi.server.LogStream >>> with no suggested replacements. I have included -Xlint:all,-deprecation >>> as an option instead >>> in the appropriate Makefiles. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146763 >>> Webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.00/ >>> >>> >>> Thanks, >>> Kurchi > -- -Kurchi From david.holmes at oracle.com Thu Feb 23 21:31:49 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Feb 2012 07:31:49 +1000 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F463411.7020806@cs.oswego.edu> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com> <4F45A829.6030509@oracle.com> <4F463411.7020806@cs.oswego.edu> Message-ID: <4F46B045.7070804@oracle.com> On 23/02/2012 10:41 PM, Doug Lea wrote: > On 02/22/12 21:44, David Holmes wrote: > >> I'm not a fan of collections containing themselves, but I think it is >> simple to fix contains(o)/contains[Key]|[Value](o) and remove(o) in a similar >> way. Though none of the wrapped collections currently handle that case, so I'm >> okay with not addressing this part. >> > > It was a deliberate decision not to include any evasive schemes > for collections that contain themselves, because the problem is > unsolvable in general. The patch addresses those that directly contain > themselves, but not the transitive closure, as in: > c1 contains c2 that in turn contains c1. Our take was that > it is a feature, not a bug, that anyone using equals or hashCode > in such cases hits infinite recursion. I must confess that I had misunderstood the basic issue here and thought that there was a problem independent of self-containment. That said, an equals method that checks for o==this is pretty normal (and recommended by Effective Java Item 7) and we at least now have consistency amongst the wrapper classes. I'll add a note to the CR to that effect. Michael: good to go (if it hasn't already) Thanks, David > People are free to change policies about this, but do bear in > mind that any changes along these lines are intrinsically > incomplete. > > (Although for pre-collections (Java1.1) legacy > compatibility reasons, java.util.Hashtable.hashCode does > include an ugly stopgap to avoid infinite recursion > in the direct case.) > > -Doug > From david.holmes at oracle.com Thu Feb 23 21:53:05 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Feb 2012 07:53:05 +1000 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F465D07.5000302@oracle.com> References: <4F465D07.5000302@oracle.com> Message-ID: <4F46B541.50706@oracle.com> Hi Fred, java.lang.ObjectName? :) Need to fix that. So often we intern strings precisely so that equals() can use == to improve performance. It seems to me that this is a case of "fixing" something for one use-case without knowing what the impact will be on other use-cases! Is there perhaps a solution that makes String.intern more scalable? David ----- On 24/02/2012 1:36 AM, Frederic Parain wrote: > This a simple fix to solve CR 6988220: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220 > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > From jason_mehrens at hotmail.com Thu Feb 23 21:55:39 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 23 Feb 2012 15:55:39 -0600 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: <4F46B045.7070804@oracle.com> References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com>,<4F45A829.6030509@oracle.com> <4F463411.7020806@cs.oswego.edu>,<4F46B045.7070804@oracle.com> Message-ID: David, For completeness, you might want to link this bug to bug id 6360946 "(coll) SetFromMap.equals should perform identity check". Most of the wrapper classes were fixed to include an identity check for that bug. Digging up some old messages from December 2005, the synchXXX wrappers were not updated because we were only trying to fix the reflexive test for equals method in the face of concurrent modification. For the synchXXX wrappers it doesn't apply but, we missed the need for it when used in methods like remove. Jason > That said, an equals method that checks for o==this is pretty normal > (and recommended by Effective Java Item 7) and we at least now have > consistency amongst the wrapper classes. I'll add a note to the CR to > that effect. > > Michael: good to go (if it hasn't already) > > Thanks, > David > From david.holmes at oracle.com Thu Feb 23 21:59:07 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Feb 2012 07:59:07 +1000 Subject: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) In-Reply-To: References: <4F44ECAD.70206@oracle.com> <4F44FA3B.8060001@oracle.com>, <4F45A829.6030509@oracle.com> <4F463411.7020806@cs.oswego.edu>, <4F46B045.7070804@oracle.com> Message-ID: <4F46B6AB.1040505@oracle.com> On 24/02/2012 7:55 AM, Jason Mehrens wrote: > David, > > For completeness, you might want to link this bug to bug id 6360946 > "(coll) SetFromMap.equals should perform identity check". Most of the > wrapper classes were fixed to include an identity check for that bug. > Digging up some old messages from December 2005, the synchXXX wrappers > were not updated because we were only trying to fix the reflexive test > for equals method in the face of concurrent modification. For the > synchXXX wrappers it doesn't apply but, we missed the need for it when > used in methods like remove. Thanks for the info Jason, I've added the cross-reference. Not bad if this issue only crops up every 6 years or so :) Cheers, David > Jason > > > That said, an equals method that checks for o==this is pretty normal > > (and recommended by Effective Java Item 7) and we at least now have > > consistency amongst the wrapper classes. I'll add a note to the CR to > > that effect. > > > > Michael: good to go (if it hasn't already) > > > > Thanks, > > David > > > From frederic.parain at oracle.com Fri Feb 24 08:34:20 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Feb 2012 09:34:20 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> Message-ID: <4F474B8C.5080302@oracle.com> I'm in favor of not adding complexity to ObjectName.equals(). The goal of this CR is to remove a bottleneck created by the use of String.intern() in ObjectName's constructors. This CR doesn't aim to optimize the ObjectName.equals() method. An application can define an optimized method to compare two ObjectNames based on its knowledge of the patterns used by its ObjectNames. However, there's no simple way to workaround the bottleneck created by the String.intern() call. The Ops-Center team has experimented the removal of String.intern() by providing their own implementation of ObjectName and playing with the bootclasspath, but this is not a solution easy to deploy in a production environment. Fred On 2/23/12 8:44 PM, Eamonn McManus wrote: > I am not sure it is worth the complexity of extra checks. Do you have > data showing that ObjectName.equals usually returns false? In a > successful HashMap lookup, for example, it will usually return true > since the equals method is used to guard against collisions, and > collisions are rare by design. Meanwhile, String.equals is intrinsic in > HotSpot so we may assume that it is highly optimized, and you are giving > up that optimization if you use other comparisons. > > ?amonn > > > On 23 February 2012 10:52, Olivier Lagneau > wrote: > > Hi Frederic, > > Performance and typo comments. > > Regarding performance of ObjectName.equals method, which is certainely > a frequent call on ObjectNames, I think that using inner fields > (Property array for canonical name and domain length) would be more > efficient > than using String.equals() on these potentially very long strings. > > Two differents objectNames may often have the same length with > different key/properties values, and may often be different only > on the last property of the canonical name. > > The Property array field ca_array (comparing length and property > contents) > and domain length are good candidates to filter out more efficiently > different objectNames, knowing that String.equals will compare every > single char of the two char arrays. > > So for performance purpose, I suggest to filter out different > objectNames > by doing inner comparisons in the following order : length of the two > canonical names, then domain_length, then ca_array size, then its > content, > and lastly if all of this fails to filter out, then use String.equals. > > _canonicalName = (new String(canonical_chars, 0, prop_index)); > > Typo : useless parentheses. > > Thanks, > Olivier. > > -- Olivier Lagneau, olivier.lagneau at oracle.com > > Oracle, Grenoble Engineering Center - France > Phone : +33 4 76 18 80 09 Fax : > +33 4 76 18 80 23 > > > > > Frederic Parain said on date 2/23/2012 6:01 PM: > > No particular reason. But after thinking more about it, > equals() should be a better choice, clearer code, and > the length check in equals() implementation is likely > to help performance of ObjectName's comparisons as > ObjectNames are often long with a common section at the > beginning. > > I've updated the webrev: > http://cr.openjdk.java.net/~__fparain/6988220/webrev.01/ > > > Thanks, > > Fred > > On 2/23/12 4:58 PM, Vitaly Davidovich wrote: > > Hi Frederic, > > Just curious - why are you checking string equality via > compareTo() > instead of equals()? > > Thanks > > Sent from my phone > > On Feb 23, 2012 10:37 AM, "Frederic Parain" > > >> wrote: > > This a simple fix to solve CR 6988220: > http://bugs.sun.com/____bugdatabase/view_bug.do?bug_____id=6988220 > > > > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~____fparain/6988220/webrev.00/ > > > > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > > > Email: Frederic.Parain at oracle.com > > > > > > > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From stuart.marks at oracle.com Fri Feb 24 08:54:11 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 24 Feb 2012 00:54:11 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F455D47.1080002@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> <4F455D47.1080002@oracle.com> Message-ID: <4F475033.4040002@oracle.com> On 2/22/12 1:25 PM, Kurchi Hazra wrote: > On 2/22/2012 10:01 AM, R?mi Forax wrote: >> Hi Kurchi, hi all, >> >> in ReliableLog, you can get ride of the @SupressWarnings, >> getLogClassConstructor should return a Constructor and not a Constructor> extends LogFile>, >> the field logClassConstructor should be typed Constructor and >> in openLogFile, the log should be constructed like this >> >> log = (logClassConstructor == null ? >> new LogFile(logName, "rw") : >> (LogFile)logClassConstructor.newInstance(logName, "rw")); >> >> The idea is that a cast on a LogFile is typesafe but not a cast on a >> Constructor. > > If I change the return type to Constructor, I get the following error: > ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:122: error: > incompatible types > logClassConstructor = getLogClassConstructor(); > ^ > required: Constructor > found: Constructor > where CAP#1 is a fresh type-variable: > CAP#1 extends Object from capture of ? > And the following warning: > > ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:350: warning: > [unchecked] unchecked cast > cl.getConstructor(String.class, String.class); > ^ > required: Constructor > found: Constructor > where CAP#1 is a fresh type-variable: > CAP#1 extends Object from capture of ? > > > Thanks, > Kurchi Hi Kurchi, To implement R?mi's suggestion fully, you would also have to change the type of logClassConstructor to Contructor near line 122, remove the cast of cl.getConstructor() near line 350, and then add the cast to LogFile at the call to newInstance() near line 546. This works to get rid of the warnings and errors, but the declaration of Constructor is somewhat imprecise. The code checks to make sure that the loaded class is a subclass of LogFile (that's what the isAssignableFrom check is doing). Thus the type of the loaded class really should be Class, and correspondingly the logClassConstructor should be Constructor. That's how logClassConstructor is declared now and it would be nice to keep it that way. It turns out that Class.asSubclass() does this conversion without generating an unchecked warning. This internally does an isAssignableFrom() check and casts to the right wildcarded type, so this can simplify the code in getLogClassConstructor() somewhat as well. (Incidentally, asSubClass() has @SuppressWarnings on its implementation.) I've appended some diffs below (to be applied on top of your most recent webrev) to show how this can be done. The behavior is slightly different, as it throws ClassCastException (which is caught by the catch clause below, emitting a log message) instead of silently returning null. This is probably an improvement, since if the user specifies the wrong class in the property name, the exception stack trace should indicate what happened. s'marks diff -r 72d32fd57d89 src/share/classes/sun/rmi/log/ReliableLog.java --- a/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 00:01:53 2012 -0800 +++ b/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 00:39:02 2012 -0800 @@ -330,9 +330,7 @@ * property a) can be loaded, b) is a subclass of LogFile, and c) has a * public two-arg constructor (String, String); otherwise returns null. **/ - @SuppressWarnings("unchecked") - private static Constructor - getLogClassConstructor() { + private static Constructor getLogClassConstructor() { String logClassName = AccessController.doPrivileged( new GetPropertyAction("sun.rmi.log.class")); @@ -345,11 +343,9 @@ return ClassLoader.getSystemClassLoader(); } }); - Class cl = loader.loadClass(logClassName); - if (LogFile.class.isAssignableFrom(cl)) { - return (Constructor) - cl.getConstructor(String.class, String.class); - } + Class cl = + loader.loadClass(logClassName).asSubclass(LogFile.class); + return cl.getConstructor(String.class, String.class); } catch (Exception e) { System.err.println("Exception occurred:"); e.printStackTrace(); From forax at univ-mlv.fr Fri Feb 24 09:00:00 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 24 Feb 2012 10:00:00 +0100 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F475033.4040002@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> <4F455D47.1080002@oracle.com> <4F475033.4040002@oracle.com> Message-ID: <4F475190.1010108@univ-mlv.fr> On 02/24/2012 09:54 AM, Stuart Marks wrote: > On 2/22/12 1:25 PM, Kurchi Hazra wrote: >> On 2/22/2012 10:01 AM, R?mi Forax wrote: >>> Hi Kurchi, hi all, >>> >>> in ReliableLog, you can get ride of the @SupressWarnings, >>> getLogClassConstructor should return a Constructor and not a >>> Constructor>> extends LogFile>, >>> the field logClassConstructor should be typed Constructor and >>> in openLogFile, the log should be constructed like this >>> >>> log = (logClassConstructor == null ? >>> new LogFile(logName, "rw") : >>> >>> (LogFile)logClassConstructor.newInstance(logName, "rw")); >>> >>> The idea is that a cast on a LogFile is typesafe but not a cast on a >>> Constructor. >> >> If I change the return type to Constructor, I get the following >> error: >> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:122: error: >> incompatible types >> logClassConstructor = getLogClassConstructor(); >> ^ >> required: Constructor >> found: Constructor >> where CAP#1 is a fresh type-variable: >> CAP#1 extends Object from capture of ? >> And the following warning: >> >> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:350: warning: >> [unchecked] unchecked cast >> cl.getConstructor(String.class, >> String.class); >> ^ >> required: Constructor >> found: Constructor >> where CAP#1 is a fresh type-variable: >> CAP#1 extends Object from capture of ? >> >> >> Thanks, >> Kurchi > > Hi Kurchi, > > To implement R?mi's suggestion fully, you would also have to change > the type of logClassConstructor to Contructor near line 122, remove > the cast of cl.getConstructor() near line 350, and then add the cast > to LogFile at the call to newInstance() near line 546. > > This works to get rid of the warnings and errors, but the declaration > of Constructor is somewhat imprecise. The code checks to make sure > that the loaded class is a subclass of LogFile (that's what the > isAssignableFrom check is doing). Thus the type of the loaded class > really should be Class, and correspondingly the > logClassConstructor should be Constructor. That's > how logClassConstructor is declared now and it would be nice to keep > it that way. > > It turns out that Class.asSubclass() does this conversion without > generating an unchecked warning. This internally does an > isAssignableFrom() check and casts to the right wildcarded type, so > this can simplify the code in getLogClassConstructor() somewhat as > well. (Incidentally, asSubClass() has @SuppressWarnings on its > implementation.) I've appended some diffs below (to be applied on top > of your most recent webrev) to show how this can be done. > > The behavior is slightly different, as it throws ClassCastException > (which is caught by the catch clause below, emitting a log message) > instead of silently returning null. This is probably an improvement, > since if the user specifies the wrong class in the property name, the > exception stack trace should indicate what happened. > > s'marks Hi Stuart, hi Kurchi, sorry to not have answer before, and yes, using asSubClass is better that what I've proposed. cheers, R?mi From masayoshi.okutsu at oracle.com Fri Feb 24 09:00:16 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 24 Feb 2012 18:00:16 +0900 Subject: RFR: 7133138 Improve io performance around timezone lookups In-Reply-To: <4F43E03A.1020404@oracle.com> References: <4F43E03A.1020404@oracle.com> Message-ID: <4F4751A0.5080108@oracle.com> The fix looks good. Thanks, Masayoshi On 2/22/2012 3:19 AM, Se?n Coffey wrote: > I've worked with Masayoshi on this issue. Hoping to push to JDK8 and > backport to 7u and a jdk6 once baked for a while. > > Some windows boxes were showing performance issues when attempting to > iterate through all available timezones available in the JRE. Changes > made here should reduce the amount of file stat calls made on > jre/lib/zi/* files. Tweaks are made to the alias table also to reduce > number of aliases that require lookup. > > All TZ regression tests run without issue. I've seen a 20-30% speed up > on iteration of timezones on windows as a result. Unix doesn't appear > to suffer as badly from such a file IO hit. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133138 > http://cr.openjdk.java.net/~coffeys/webrev.7133138/ > > regards, > Sean. > From frederic.parain at oracle.com Fri Feb 24 09:06:05 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Feb 2012 10:06:05 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F475299.6010407@oracle.com> References: <4F475299.6010407@oracle.com> Message-ID: <4F4752FD.5000700@oracle.com> Making String.intern() more scalable doesn't seem to be a solution for short (or medium?) time frame. Even if the computation cost of ObjectName.equals() is increased by this fix, there's no performance measurement in favor or against this change. I've looked for benchmarks stressing the ObjectName class, but I haven't found one yet. Using java.util "Set" or "Map" introduces new issues, like the memory footprint and new synchronizations to protect consistency of the collection. The Ops-Center team is stuck with this scalability issue for two years now. They have identified the problem in JDK6 and we're not able to provide them with a solution for JDK7 or JDK8. David, I agree that I have no data about the impact on other use-cases, but I know that the use of String.intern() cannot be easily workaround. We can remove the use of String.intern() and if the performance of the new ObjectName.equals() method really becomes a performance bottleneck for other use-cases, them we can re-work this method to improve its performance. But I'd prefer not starting complex optimizations on a method without having real indication that it causes real performance issues. Fred On 2/23/12 11:23 PM, Keith McGuigan wrote: > > Making String.intern() more scalable has been on our list of > things-to-do for a long, long time. But, it's not trivial. Simply > increasing the size of the hashtable is no good because we'd be upping > our footprint unconditionally, so really we want a growing hashtable > which is a bit more effort (though not impossible, of course, it just > hasn't bubbled up to the top of the priority list). > > Another problem with using 'intern()' is that when you intern a string > you're placing it into the permgen, and space there is at a premium. (no > perm gen project will hopefully fix this soon). > > If you really want to use == instead of "equals()", you can use a > java.util "set" or "map" data structure and stash all of your strings in > there. Then you'll have canonicalized references that == will work upon, > and you won't run into the intern() scalability (or concurrency) issues. > > -- > - Keith > > > On 2/23/2012 4:53 PM, David Holmes wrote: >> Hi Fred, >> >> java.lang.ObjectName? :) Need to fix that. >> >> So often we intern strings precisely so that equals() can use == to >> improve performance. >> >> It seems to me that this is a case of "fixing" something for one >> use-case without knowing what the impact will be on other use-cases! >> >> Is there perhaps a solution that makes String.intern more scalable? >> >> David >> ----- >> >> On 24/02/2012 1:36 AM, Frederic Parain wrote: >>> This a simple fix to solve CR 6988220: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220 >>> >>> The use of String.intern() in the ObjectName class prevents >>> the class the scale well when more than 20K ObjectNames are >>> managed. The fix simply removes the use of String.intern(), >>> and uses regular String instead. The Object.equals() method >>> is modified too to make a regular String comparison. The >>> complexity of this method now depends on the length of >>> the ObjectName's canonical name, and is not impacted any >>> more by the number of ObjectName instances being handled. >>> >>> The Webrev: >>> http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ >>> >>> I've tested this fix with the jdk_lang and jdk_management >>> test suites. >>> >>> Thanks, >>> >>> Fred >>> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From dmytro_sheyko at hotmail.com Fri Feb 24 09:08:50 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Fri, 24 Feb 2012 12:08:50 +0300 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com>, Message-ID: Hi, Though "compareTo" tends to be less efficient than "equals", it offers better type safety. When we (mistakenly!) compare objects of different type, "equals" silently accepts parameter of wrong type, but returns false. Comparison with "compareTo" is rejected by compiler. Consider, String string = ... Date date = ... if (string.equals(date)) { // always false } if (string.compareTo(date) == 0) { // compilation error } Regards, Dmytro > Date: Thu, 23 Feb 2012 10:58:47 -0500 > Subject: Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale > From: vitalyd at gmail.com > To: frederic.parain at oracle.com > CC: serviceability-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > Hi Frederic, > > Just curious - why are you checking string equality via compareTo() instead > of equals()? > > Thanks > > Sent from my phone > On Feb 23, 2012 10:37 AM, "Frederic Parain" > wrote: > > > This a simple fix to solve CR 6988220: > > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6988220 > > > > The use of String.intern() in the ObjectName class prevents > > the class the scale well when more than 20K ObjectNames are > > managed. The fix simply removes the use of String.intern(), > > and uses regular String instead. The Object.equals() method > > is modified too to make a regular String comparison. The > > complexity of this method now depends on the length of > > the ObjectName's canonical name, and is not impacted any > > more by the number of ObjectName instances being handled. > > > > The Webrev: > > http://cr.openjdk.java.net/~**fparain/6988220/webrev.00/ > > > > I've tested this fix with the jdk_lang and jdk_management > > test suites. > > > > Thanks, > > > > Fred > > > > -- > > Frederic Parain - Oracle > > Grenoble Engineering Center - France > > Phone: +33 4 76 18 81 17 > > Email: Frederic.Parain at oracle.com > > > > From sean.coffey at oracle.com Fri Feb 24 09:11:01 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 24 Feb 2012 09:11:01 +0000 Subject: hg: jdk8/tl/jdk: 7133138: Improve io performance around timezone lookups Message-ID: <20120224091125.C4DCC47689@hg.openjdk.java.net> Changeset: a589a8dbde79 Author: coffeys Date: 2012-02-24 09:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a589a8dbde79 7133138: Improve io performance around timezone lookups Reviewed-by: okutsu ! make/tools/src/build/tools/javazic/Mappings.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java From frederic.parain at oracle.com Fri Feb 24 09:13:43 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Feb 2012 10:13:43 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> Message-ID: <4F4754C7.4010007@oracle.com> On 2/23/12 7:46 PM, David Schlosnagle wrote: > Was the main bottleneck the contention on the interned string pool > that prevented concurrent addition of ObjectNames? Are there other > places within the JDK where use of intern() should be analyzed for > similar scalability bottlenecks? I'm also curious what the heap > implications are of no longer using interned strings. I haven't looked for similar use of intern() within the JDK. However, the scalability issue of String.intern() is known for a long term, but the fix is not that simple, as Keith explained, this is why it has been delayed for a long time due to other higher priority tasks. > A minor nit is that the equals method could be simplified slightly, > making it more clear that the canonical names must match for equality: > > @Override > public boolean equals(Object object) { > // same object case > if (this == object) return true; > > // object is not an object name case > if (!(object instanceof ObjectName)) return false; > ObjectName on = (ObjectName) object; > return _canonicalName.equals(on._canonicalName); > } Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From sean.coffey at oracle.com Fri Feb 24 09:16:34 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 24 Feb 2012 09:16:34 +0000 Subject: hg: jdk8/tl/jdk: 7144488: Infinite recursion for some equals tests in Collections Message-ID: <20120224091644.B9B114768A@hg.openjdk.java.net> Changeset: 0a350fb8b174 Author: coffeys Date: 2012-02-24 09:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a350fb8b174 7144488: Infinite recursion for some equals tests in Collections Reviewed-by: alanb, dholmes, mduigou ! src/share/classes/java/util/Collections.java + test/java/util/Collections/EqualsTest.java From olivier.lagneau at oracle.com Fri Feb 24 11:38:59 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 24 Feb 2012 12:38:59 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> Message-ID: <4F4776D3.6010901@oracle.com> Hi ?amonn, Eamonn McManus said on date 2/23/2012 8:44 PM: > I am not sure it is worth the complexity of extra checks. Do you have > data showing that ObjectName.equals usually returns false?In a > successful HashMap lookup, for example, it will usually return true > since the equals method is used to guard against collisions, and > collisions are rare by design. Meanwhile, String.equals is intrinsic > in HotSpot so we may assume that it is highly optimized, and you are > giving up that optimization if you use other comparisons. Don't have this kind of data indeed. I don't know of any benchmark/data about usage of ObjectName.equals() in most applications. That would be needed to evaluate the exact impact of the change. And I agree with the argument that usual semantics of an equals call is to check for equality, not the difference. My argument is mainly that we are moving from comparing identity to equality. Thus there will be an impact on the throughput of equals, possibly impacting some applications. Olivier. > ?amonn > > > On 23 February 2012 10:52, Olivier Lagneau > wrote: > > Hi Frederic, > > Performance and typo comments. > > Regarding performance of ObjectName.equals method, which is certainely > a frequent call on ObjectNames, I think that using inner fields > (Property array for canonical name and domain length) would be > more efficient > than using String.equals() on these potentially very long strings. > > Two differents objectNames may often have the same length with > different key/properties values, and may often be different only > on the last property of the canonical name. > > The Property array field ca_array (comparing length and property > contents) > and domain length are good candidates to filter out more efficiently > different objectNames, knowing that String.equals will compare every > single char of the two char arrays. > > So for performance purpose, I suggest to filter out different > objectNames > by doing inner comparisons in the following order : length of the two > canonical names, then domain_length, then ca_array size, then its > content, > and lastly if all of this fails to filter out, then use String.equals. > > _canonicalName = (new String(canonical_chars, 0, prop_index)); > > Typo : useless parentheses. > > Thanks, > Olivier. > > -- Olivier Lagneau, olivier.lagneau at oracle.com > > Oracle, Grenoble Engineering Center - France > Phone : +33 4 76 18 80 09 Fax > : +33 4 76 18 80 23 > > > > > Frederic Parain said on date 2/23/2012 6:01 PM: > > No particular reason. But after thinking more about it, > equals() should be a better choice, clearer code, and > the length check in equals() implementation is likely > to help performance of ObjectName's comparisons as > ObjectNames are often long with a common section at the > beginning. > > I've updated the webrev: > http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ > > > Thanks, > > Fred > > On 2/23/12 4:58 PM, Vitaly Davidovich wrote: > > Hi Frederic, > > Just curious - why are you checking string equality via > compareTo() > instead of equals()? > > Thanks > > Sent from my phone > > On Feb 23, 2012 10:37 AM, "Frederic Parain" > > >> wrote: > > This a simple fix to solve CR 6988220: > http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 > > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ > > > > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > > > Email: Frederic.Parain at oracle.com > > > > > > > From olivier.lagneau at oracle.com Fri Feb 24 15:21:05 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 24 Feb 2012 16:21:05 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F4776D3.6010901@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> <4F4776D3.6010901@oracle.com> Message-ID: <4F47AAE1.1020705@oracle.com> I think I have not been clear enough here. I Agree with Eammon's argument, and anyway ok with this change. Olivier. Olivier Lagneau said on date 2/24/2012 12:38 PM: > Hi ?amonn, > > Eamonn McManus said on date 2/23/2012 8:44 PM: >> I am not sure it is worth the complexity of extra checks. Do you have >> data showing that ObjectName.equals usually returns false?In a >> successful HashMap lookup, for example, it will usually return true >> since the equals method is used to guard against collisions, and >> collisions are rare by design. Meanwhile, String.equals is intrinsic >> in HotSpot so we may assume that it is highly optimized, and you are >> giving up that optimization if you use other comparisons. > Don't have this kind of data indeed. I don't know of any > benchmark/data about usage of ObjectName.equals() > in most applications. That would be needed to evaluate the exact > impact of the change. > And I agree with the argument that usual semantics of an equals call > is to check for equality, > not the difference. > > My argument is mainly that we are moving from comparing identity to > equality. > Thus there will be an impact on the throughput of equals, possibly > impacting > some applications. > > Olivier. > >> ?amonn >> >> >> On 23 February 2012 10:52, Olivier Lagneau >> > wrote: >> >> Hi Frederic, >> >> Performance and typo comments. >> >> Regarding performance of ObjectName.equals method, which is >> certainely >> a frequent call on ObjectNames, I think that using inner fields >> (Property array for canonical name and domain length) would be >> more efficient >> than using String.equals() on these potentially very long strings. >> >> Two differents objectNames may often have the same length with >> different key/properties values, and may often be different only >> on the last property of the canonical name. >> >> The Property array field ca_array (comparing length and property >> contents) >> and domain length are good candidates to filter out more efficiently >> different objectNames, knowing that String.equals will compare every >> single char of the two char arrays. >> >> So for performance purpose, I suggest to filter out different >> objectNames >> by doing inner comparisons in the following order : length of the >> two >> canonical names, then domain_length, then ca_array size, then its >> content, >> and lastly if all of this fails to filter out, then use >> String.equals. >> >> _canonicalName = (new String(canonical_chars, 0, prop_index)); >> >> Typo : useless parentheses. >> >> Thanks, >> Olivier. >> >> -- Olivier Lagneau, olivier.lagneau at oracle.com >> >> Oracle, Grenoble Engineering Center - France >> Phone : +33 4 76 18 80 09 Fax >> : +33 4 76 18 80 23 >> >> >> >> >> Frederic Parain said on date 2/23/2012 6:01 PM: >> >> No particular reason. But after thinking more about it, >> equals() should be a better choice, clearer code, and >> the length check in equals() implementation is likely >> to help performance of ObjectName's comparisons as >> ObjectNames are often long with a common section at the >> beginning. >> >> I've updated the webrev: >> http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ >> >> >> Thanks, >> >> Fred >> >> On 2/23/12 4:58 PM, Vitaly Davidovich wrote: >> >> Hi Frederic, >> >> Just curious - why are you checking string equality via >> compareTo() >> instead of equals()? >> >> Thanks >> >> Sent from my phone >> >> On Feb 23, 2012 10:37 AM, "Frederic Parain" >> > >> > >> wrote: >> >> This a simple fix to solve CR 6988220: >> >> http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 >> >> >> The use of String.intern() in the ObjectName class >> prevents >> the class the scale well when more than 20K >> ObjectNames are >> managed. The fix simply removes the use of >> String.intern(), >> and uses regular String instead. The Object.equals() >> method >> is modified too to make a regular String comparison. The >> complexity of this method now depends on the length of >> the ObjectName's canonical name, and is not impacted any >> more by the number of ObjectName instances being handled. >> >> The Webrev: >> http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ >> >> > > >> >> I've tested this fix with the jdk_lang and jdk_management >> test suites. >> >> Thanks, >> >> Fred >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> >> >> Email: Frederic.Parain at oracle.com >> >> > > >> >> >> >> > From daniel.daugherty at oracle.com Fri Feb 24 15:33:15 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Feb 2012 08:33:15 -0700 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F47AAE1.1020705@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> <4F4776D3.6010901@oracle.com> <4F47AAE1.1020705@oracle.com> Message-ID: <4F47ADBB.5070701@oracle.com> Just FYI: I haven't seen ?amonn's posting come in. Just replies to his posting. This may mean that other comments are stuck in the ether somewhere... I suspect that the OpenJDK list server is again having issues... Dan On 2/24/12 8:21 AM, Olivier Lagneau wrote: > I think I have not been clear enough here. > > I Agree with Eammon's argument, and anyway ok with this change. > > Olivier. > > > Olivier Lagneau said on date 2/24/2012 12:38 PM: >> Hi ?amonn, >> >> Eamonn McManus said on date 2/23/2012 8:44 PM: >>> I am not sure it is worth the complexity of extra checks. Do you >>> have data showing that ObjectName.equals usually returns false?In a >>> successful HashMap lookup, for example, it will usually return true >>> since the equals method is used to guard against collisions, and >>> collisions are rare by design. Meanwhile, String.equals is intrinsic >>> in HotSpot so we may assume that it is highly optimized, and you are >>> giving up that optimization if you use other comparisons. >> Don't have this kind of data indeed. I don't know of any >> benchmark/data about usage of ObjectName.equals() >> in most applications. That would be needed to evaluate the exact >> impact of the change. >> And I agree with the argument that usual semantics of an equals call >> is to check for equality, >> not the difference. >> >> My argument is mainly that we are moving from comparing identity to >> equality. >> Thus there will be an impact on the throughput of equals, possibly >> impacting >> some applications. >> >> Olivier. >> >>> ?amonn >>> >>> >>> On 23 February 2012 10:52, Olivier Lagneau >>> > wrote: >>> >>> Hi Frederic, >>> >>> Performance and typo comments. >>> >>> Regarding performance of ObjectName.equals method, which is >>> certainely >>> a frequent call on ObjectNames, I think that using inner fields >>> (Property array for canonical name and domain length) would be >>> more efficient >>> than using String.equals() on these potentially very long strings. >>> >>> Two differents objectNames may often have the same length with >>> different key/properties values, and may often be different only >>> on the last property of the canonical name. >>> >>> The Property array field ca_array (comparing length and property >>> contents) >>> and domain length are good candidates to filter out more >>> efficiently >>> different objectNames, knowing that String.equals will compare >>> every >>> single char of the two char arrays. >>> >>> So for performance purpose, I suggest to filter out different >>> objectNames >>> by doing inner comparisons in the following order : length of >>> the two >>> canonical names, then domain_length, then ca_array size, then its >>> content, >>> and lastly if all of this fails to filter out, then use >>> String.equals. >>> >>> _canonicalName = (new String(canonical_chars, 0, prop_index)); >>> >>> Typo : useless parentheses. >>> >>> Thanks, >>> Olivier. >>> >>> -- Olivier Lagneau, olivier.lagneau at oracle.com >>> >>> Oracle, Grenoble Engineering Center - France >>> Phone : +33 4 76 18 80 09 Fax >>> : +33 4 76 18 80 23 >>> >>> >>> >>> >>> Frederic Parain said on date 2/23/2012 6:01 PM: >>> >>> No particular reason. But after thinking more about it, >>> equals() should be a better choice, clearer code, and >>> the length check in equals() implementation is likely >>> to help performance of ObjectName's comparisons as >>> ObjectNames are often long with a common section at the >>> beginning. >>> >>> I've updated the webrev: >>> http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ >>> >>> >>> Thanks, >>> >>> Fred >>> >>> On 2/23/12 4:58 PM, Vitaly Davidovich wrote: >>> >>> Hi Frederic, >>> >>> Just curious - why are you checking string equality via >>> compareTo() >>> instead of equals()? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Feb 23, 2012 10:37 AM, "Frederic Parain" >>> >> >>> >> >> wrote: >>> >>> This a simple fix to solve CR 6988220: >>> http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 >>> >>> >>> The use of String.intern() in the ObjectName class >>> prevents >>> the class the scale well when more than 20K >>> ObjectNames are >>> managed. The fix simply removes the use of >>> String.intern(), >>> and uses regular String instead. The Object.equals() >>> method >>> is modified too to make a regular String comparison. The >>> complexity of this method now depends on the length of >>> the ObjectName's canonical name, and is not impacted any >>> more by the number of ObjectName instances being >>> handled. >>> >>> The Webrev: >>> http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ >>> >>> >> > >>> >>> I've tested this fix with the jdk_lang and >>> jdk_management >>> test suites. >>> >>> Thanks, >>> >>> Fred >>> >>> -- >>> Frederic Parain - Oracle >>> Grenoble Engineering Center - France >>> Phone: +33 4 76 18 81 17 >>> >>> >>> Email: Frederic.Parain at oracle.com >>> >>> >> > >>> >>> >>> >>> >> > From iris.clark at oracle.com Fri Feb 24 16:05:32 2012 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 24 Feb 2012 08:05:32 -0800 (PST) Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F47ADBB.5070701@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> <4F4776D3.6010901@oracle.com> <4F47AAE1.1020705@oracle.com> <4F47ADBB.5070701@oracle.com> Message-ID: Hi, Dan. > Just FYI: I haven't seen ?amonn's posting come in. Just replies to his > posting. This may mean that other comments are stuck in the ether > somewhere... > > I suspect that the OpenJDK list server is again having issues... I just checked the core-libs-dev admin interface to see if anything was waiting for moderation, but there wasn't anything. (Not that I'd expect that to be the case for messages from ?amonn.) Must be a failure at some other level... Sorry. iris From eamonn at mcmanus.net Fri Feb 24 16:06:55 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 24 Feb 2012 10:06:55 -0600 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F47ADBB.5070701@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> <4F4776D3.6010901@oracle.com> <4F47AAE1.1020705@oracle.com> <4F47ADBB.5070701@oracle.com> Message-ID: Hi Dan, I got a bounce from serviceability-dev because I wasn't subscribed to it, but the message went out to core-libs-dev because I was subscribed to that. That probably explains what you saw. Regards, ?amonn On 24 February 2012 09:33, Daniel D. Daugherty wrote: > > Just FYI: I haven't seen ?amonn's posting come in. Just replies to > his posting. This may mean that other comments are stuck in the > ether somewhere... > > I suspect that the OpenJDK list server is again having issues... > > Dan > > > On 2/24/12 8:21 AM, Olivier Lagneau wrote: > > I think I have not been clear enough here. > > I Agree with Eammon's argument, and anyway ok with this change. > > Olivier. > > > Olivier Lagneau said? on date 2/24/2012 12:38 PM: > > Hi ?amonn, > > Eamonn McManus said? on date 2/23/2012 8:44 PM: > > I am not sure it is worth the complexity of extra checks. Do you have data showing that ObjectName.equals usually returns false?In a successful HashMap lookup, for example, it will usually return true since the equals method is used to guard against collisions, and collisions are rare by design. Meanwhile, String.equals is intrinsic in HotSpot so we may assume that it is highly optimized, and you are giving up that optimization if you use other comparisons. > > Don't have this kind of data indeed. I don't know of any benchmark/data about usage of ObjectName.equals() > in most applications. That would be needed to evaluate the exact impact of the change. > And I agree with the argument that usual semantics of an equals call is to check for equality, > not the difference. > > My argument is mainly that we are moving from comparing identity to equality. > Thus there will be an impact on the throughput of equals, possibly impacting > some applications. > > Olivier. > > ?amonn > > > On 23 February 2012 10:52, Olivier Lagneau > wrote: > > ??? Hi Frederic, > > ??? Performance and typo comments. > > ??? Regarding performance of ObjectName.equals method, which is certainely > ??? a frequent call on ObjectNames, I think that using inner fields > ??? (Property array for canonical name and domain length) would be > ??? more efficient > ??? than using String.equals() on these potentially very long strings. > > ??? Two differents objectNames may often have the same length with > ??? different key/properties values, and may often be different only > ??? on the last property of the canonical name. > > ??? The Property array field ca_array (comparing length and property > ??? contents) > ??? and domain length are good candidates to filter out more efficiently > ??? different objectNames, knowing that String.equals will compare every > ??? single char of the two char arrays. > > ??? So for performance purpose, I suggest to filter out different > ??? objectNames > ??? by doing inner comparisons in the following order : length of the two > ??? canonical names, then domain_length, then ca_array size, then its > ??? content, > ??? and lastly if all of this fails to filter out, then use String.equals. > > ???????? _canonicalName = (new String(canonical_chars, 0, prop_index)); > > ??? Typo : useless parentheses. > > ??? Thanks, > ??? Olivier. > > ??? -- Olivier Lagneau, olivier.lagneau at oracle.com > ??? > ??? Oracle, Grenoble Engineering Center - France > ??? Phone : +33 4 76 18 80 09 Fax > ??? : +33 4 76 18 80 23 > > > > > ??? Frederic Parain said? on date 2/23/2012 6:01 PM: > > ??????? No particular reason. But after thinking more about it, > ??????? equals() should be a better choice, clearer code, and > ??????? the length check in equals() implementation is likely > ??????? to help performance of ObjectName's comparisons as > ??????? ObjectNames are often long with a common section at the > ??????? beginning. > > ??????? I've updated the webrev: > ??????? http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ > ??????? > > ??????? Thanks, > > ??????? Fred > > ??????? On 2/23/12 4:58 PM, Vitaly Davidovich wrote: > > ??????????? Hi Frederic, > > ??????????? Just curious - why are you checking string equality via > ??????????? compareTo() > ??????????? instead of equals()? > > ??????????? Thanks > > ??????????? Sent from my phone > > ??????????? On Feb 23, 2012 10:37 AM, "Frederic Parain" > ??????????? ??????????? > ??????????? ??????????? >> wrote: > > ?????????????? This a simple fix to solve CR 6988220: > ??????????? http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 > ??????????? > > ?????????????? The use of String.intern() in the ObjectName class prevents > ?????????????? the class the scale well when more than 20K ObjectNames are > ?????????????? managed. The fix simply removes the use of String.intern(), > ?????????????? and uses regular String instead. The Object.equals() method > ?????????????? is modified too to make a regular String comparison. The > ?????????????? complexity of this method now depends on the length of > ?????????????? the ObjectName's canonical name, and is not impacted any > ?????????????? more by the number of ObjectName instances being handled. > > ?????????????? The Webrev: > ??????????? http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ > ??????????? > ??????????? ??????????? > > > ?????????????? I've tested this fix with the jdk_lang and jdk_management > ?????????????? test suites. > > ?????????????? Thanks, > > ?????????????? Fred > > ?????????????? -- > ?????????????? Frederic Parain - Oracle > ?????????????? Grenoble Engineering Center - France > ?????????????? Phone: +33 4 76 18 81 17 > ??????????? > ??????????? > ?????????????? Email: Frederic.Parain at oracle.com > ??????????? > ??????????? ??????????? > > > > > > > From jonathan.gibbons at oracle.com Fri Feb 24 18:40:46 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 24 Feb 2012 18:40:46 +0000 Subject: hg: jdk8/tl/langtools: 7137836: tidy up Names.java Message-ID: <20120224184049.000AA4769A@hg.openjdk.java.net> Changeset: e6b5c3aff85c Author: jjg Date: 2012-02-24 10:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6b5c3aff85c 7137836: tidy up Names.java Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/util/Names.java From kurchi.subhra.hazra at oracle.com Fri Feb 24 19:01:18 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 24 Feb 2012 11:01:18 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F475033.4040002@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> <4F455D47.1080002@oracle.com> <4F475033.4040002@oracle.com> Message-ID: <4F47DE7E.9010107@oracle.com> Hi Stuart, Thanks for the detailed explanation. Here is an updated webrev: http://cr.openjdk.java.net/~khazra/7146763/webrev.02/ - Kurchi On 2/24/2012 12:54 AM, Stuart Marks wrote: > On 2/22/12 1:25 PM, Kurchi Hazra wrote: >> On 2/22/2012 10:01 AM, R?mi Forax wrote: >>> Hi Kurchi, hi all, >>> >>> in ReliableLog, you can get ride of the @SupressWarnings, >>> getLogClassConstructor should return a Constructor and not a >>> Constructor>> extends LogFile>, >>> the field logClassConstructor should be typed Constructor and >>> in openLogFile, the log should be constructed like this >>> >>> log = (logClassConstructor == null ? >>> new LogFile(logName, "rw") : >>> >>> (LogFile)logClassConstructor.newInstance(logName, "rw")); >>> >>> The idea is that a cast on a LogFile is typesafe but not a cast on a >>> Constructor. >> >> If I change the return type to Constructor, I get the following >> error: >> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:122: error: >> incompatible types >> logClassConstructor = getLogClassConstructor(); >> ^ >> required: Constructor >> found: Constructor >> where CAP#1 is a fresh type-variable: >> CAP#1 extends Object from capture of ? >> And the following warning: >> >> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:350: warning: >> [unchecked] unchecked cast >> cl.getConstructor(String.class, >> String.class); >> ^ >> required: Constructor >> found: Constructor >> where CAP#1 is a fresh type-variable: >> CAP#1 extends Object from capture of ? >> >> >> Thanks, >> Kurchi > > Hi Kurchi, > > To implement R?mi's suggestion fully, you would also have to change > the type of logClassConstructor to Contructor near line 122, remove > the cast of cl.getConstructor() near line 350, and then add the cast > to LogFile at the call to newInstance() near line 546. > > This works to get rid of the warnings and errors, but the declaration > of Constructor is somewhat imprecise. The code checks to make sure > that the loaded class is a subclass of LogFile (that's what the > isAssignableFrom check is doing). Thus the type of the loaded class > really should be Class, and correspondingly the > logClassConstructor should be Constructor. That's > how logClassConstructor is declared now and it would be nice to keep > it that way. > > It turns out that Class.asSubclass() does this conversion without > generating an unchecked warning. This internally does an > isAssignableFrom() check and casts to the right wildcarded type, so > this can simplify the code in getLogClassConstructor() somewhat as > well. (Incidentally, asSubClass() has @SuppressWarnings on its > implementation.) I've appended some diffs below (to be applied on top > of your most recent webrev) to show how this can be done. > > The behavior is slightly different, as it throws ClassCastException > (which is caught by the catch clause below, emitting a log message) > instead of silently returning null. This is probably an improvement, > since if the user specifies the wrong class in the property name, the > exception stack trace should indicate what happened. > > s'marks > > > > > diff -r 72d32fd57d89 src/share/classes/sun/rmi/log/ReliableLog.java > --- a/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 > 00:01:53 2012 -0800 > +++ b/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 > 00:39:02 2012 -0800 > @@ -330,9 +330,7 @@ > * property a) can be loaded, b) is a subclass of LogFile, and c) > has a > * public two-arg constructor (String, String); otherwise returns > null. > **/ > - @SuppressWarnings("unchecked") > - private static Constructor > - getLogClassConstructor() { > + private static Constructor > getLogClassConstructor() { > > String logClassName = AccessController.doPrivileged( > new GetPropertyAction("sun.rmi.log.class")); > @@ -345,11 +343,9 @@ > return > ClassLoader.getSystemClassLoader(); > } > }); > - Class cl = loader.loadClass(logClassName); > - if (LogFile.class.isAssignableFrom(cl)) { > - return (Constructor) > - cl.getConstructor(String.class, > String.class); > - } > + Class cl = > + > loader.loadClass(logClassName).asSubclass(LogFile.class); > + return cl.getConstructor(String.class, String.class); > } catch (Exception e) { > System.err.println("Exception occurred:"); > e.printStackTrace(); > > -- -Kurchi From staffan.larsen at oracle.com Fri Feb 24 19:06:28 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 24 Feb 2012 19:06:28 +0000 Subject: hg: jdk8/tl/jdk: 7073626: RmiBootstrapTest.sh and RmiSslBootstrapTest.sh fail under Cygwin Message-ID: <20120224190646.BA9E74769B@hg.openjdk.java.net> Changeset: 585f2c72d042 Author: sla Date: 2012-02-24 20:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/585f2c72d042 7073626: RmiBootstrapTest.sh and RmiSslBootstrapTest.sh fail under Cygwin Summary: Detect and handle cygwin correctly Reviewed-by: alanb, sspitsyn ! test/ProblemList.txt ! test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh From staffan.larsen at oracle.com Fri Feb 24 19:09:54 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 24 Feb 2012 19:09:54 +0000 Subject: hg: jdk8/tl/jdk: 7079093: TEST_BUG: java/lang/instrument/ManifestTest.sh fails with cygwin Message-ID: <20120224191004.765204769C@hg.openjdk.java.net> Changeset: 4893a89b4916 Author: sla Date: 2012-02-24 20:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4893a89b4916 7079093: TEST_BUG: java/lang/instrument/ManifestTest.sh fails with cygwin Summary: Work around problems in some cygwin installations Reviewed-by: alanb, sspitsyn ! test/ProblemList.txt ! test/java/lang/instrument/ManifestTest.sh From forax at univ-mlv.fr Fri Feb 24 21:45:08 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 24 Feb 2012 22:45:08 +0100 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F47DE7E.9010107@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> <4F455D47.1080002@oracle.com> <4F475033.4040002@oracle.com> <4F47DE7E.9010107@oracle.com> Message-ID: <4F4804E4.6090009@univ-mlv.fr> On 02/24/2012 08:01 PM, Kurchi Hazra wrote: > Hi Stuart, > > Thanks for the detailed explanation. Here is an updated webrev: > http://cr.openjdk.java.net/~khazra/7146763/webrev.02/ Hi Kurchi, the field logClassConstructor should not be changed after all, it should be declared as a Constructor so you can remove the cast to LogFile at line 542. with this change, the patch looks good to me. > > > - Kurchi cheers, R?mi From kurchi.subhra.hazra at oracle.com Fri Feb 24 22:24:20 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 24 Feb 2012 14:24:20 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F47DE7E.9010107@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> <4F455D47.1080002@oracle.com> <4F475033.4040002@oracle.com> <4F47DE7E.9010107@oracle.com> Message-ID: <4F480E14.8030109@oracle.com> Hi, Please ignore the previous webrev and see this instead: http://cr.openjdk.java.net/~khazra/7146763/webrev.03/ This has Stuart's suggestion integrated correctly. In addition, I realized that make/sun/rmi/rmic/Makefile is not yet ready to have the JAVAC_WARNINGS_FATAL flag turned on, since it implicitly also builds files from sun/tools with more then 400 warnings in them. The change in this file has now been removed. - Kurchi On 2/24/2012 11:01 AM, Kurchi Hazra wrote: > Hi Stuart, > > Thanks for the detailed explanation. Here is an updated webrev: > http://cr.openjdk.java.net/~khazra/7146763/webrev.02/ > > > - Kurchi > > On 2/24/2012 12:54 AM, Stuart Marks wrote: >> On 2/22/12 1:25 PM, Kurchi Hazra wrote: >>> On 2/22/2012 10:01 AM, R?mi Forax wrote: >>>> Hi Kurchi, hi all, >>>> >>>> in ReliableLog, you can get ride of the @SupressWarnings, >>>> getLogClassConstructor should return a Constructor and not a >>>> Constructor>>> extends LogFile>, >>>> the field logClassConstructor should be typed Constructor and >>>> in openLogFile, the log should be constructed like this >>>> >>>> log = (logClassConstructor == null ? >>>> new LogFile(logName, "rw") : >>>> >>>> (LogFile)logClassConstructor.newInstance(logName, "rw")); >>>> >>>> The idea is that a cast on a LogFile is typesafe but not a cast on a >>>> Constructor. >>> >>> If I change the return type to Constructor, I get the following >>> error: >>> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:122: error: >>> incompatible types >>> logClassConstructor = getLogClassConstructor(); >>> ^ >>> required: Constructor >>> found: Constructor >>> where CAP#1 is a fresh type-variable: >>> CAP#1 extends Object from capture of ? >>> And the following warning: >>> >>> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:350: >>> warning: >>> [unchecked] unchecked cast >>> cl.getConstructor(String.class, >>> String.class); >>> ^ >>> required: Constructor >>> found: Constructor >>> where CAP#1 is a fresh type-variable: >>> CAP#1 extends Object from capture of ? >>> >>> >>> Thanks, >>> Kurchi >> >> Hi Kurchi, >> >> To implement R?mi's suggestion fully, you would also have to change >> the type of logClassConstructor to Contructor near line 122, >> remove the cast of cl.getConstructor() near line 350, and then add >> the cast to LogFile at the call to newInstance() near line 546. >> >> This works to get rid of the warnings and errors, but the declaration >> of Constructor is somewhat imprecise. The code checks to make sure >> that the loaded class is a subclass of LogFile (that's what the >> isAssignableFrom check is doing). Thus the type of the loaded class >> really should be Class, and correspondingly the >> logClassConstructor should be Constructor. That's >> how logClassConstructor is declared now and it would be nice to keep >> it that way. >> >> It turns out that Class.asSubclass() does this conversion without >> generating an unchecked warning. This internally does an >> isAssignableFrom() check and casts to the right wildcarded type, so >> this can simplify the code in getLogClassConstructor() somewhat as >> well. (Incidentally, asSubClass() has @SuppressWarnings on its >> implementation.) I've appended some diffs below (to be applied on top >> of your most recent webrev) to show how this can be done. >> >> The behavior is slightly different, as it throws ClassCastException >> (which is caught by the catch clause below, emitting a log message) >> instead of silently returning null. This is probably an improvement, >> since if the user specifies the wrong class in the property name, the >> exception stack trace should indicate what happened. >> >> s'marks >> >> >> >> >> diff -r 72d32fd57d89 src/share/classes/sun/rmi/log/ReliableLog.java >> --- a/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 >> 00:01:53 2012 -0800 >> +++ b/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 >> 00:39:02 2012 -0800 >> @@ -330,9 +330,7 @@ >> * property a) can be loaded, b) is a subclass of LogFile, and >> c) has a >> * public two-arg constructor (String, String); otherwise >> returns null. >> **/ >> - @SuppressWarnings("unchecked") >> - private static Constructor >> - getLogClassConstructor() { >> + private static Constructor >> getLogClassConstructor() { >> >> String logClassName = AccessController.doPrivileged( >> new GetPropertyAction("sun.rmi.log.class")); >> @@ -345,11 +343,9 @@ >> return >> ClassLoader.getSystemClassLoader(); >> } >> }); >> - Class cl = loader.loadClass(logClassName); >> - if (LogFile.class.isAssignableFrom(cl)) { >> - return (Constructor) >> - cl.getConstructor(String.class, >> String.class); >> - } >> + Class cl = >> + >> loader.loadClass(logClassName).asSubclass(LogFile.class); >> + return cl.getConstructor(String.class, String.class); >> } catch (Exception e) { >> System.err.println("Exception occurred:"); >> e.printStackTrace(); >> >> > -- -Kurchi From Alan.Bateman at oracle.com Sun Feb 26 10:09:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Feb 2012 10:09:09 +0000 Subject: 7148921: More ProblemList updates (2/2012) Message-ID: <4F4A04C5.4060509@oracle.com> The war on tests continues and I'd like to several tests to the ProblemList until the relevant issues are resolved. There are changes in hs23-b15 and b16 that expose tests that are too sensitive to the GC behavior and minimum thread stack size. There are also a couple of tests that need to made more robust so that they can reliably. Thanks, Alan. diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -131,6 +131,9 @@ java/lang/management/ThreadMXBean/Thread # 7067973 java/lang/management/MemoryMXBean/CollectionUsageThreshold.java generic-all +# 7148492 +java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java generic-all + ############################################################################ # jdk_management @@ -179,6 +182,10 @@ java/net/InetAddress/CheckJNI.java # 7102702 java/net/PortUnreachableException/OneExceptionOnly.java windows-all +# 7148829 +sun/net/InetAddress/nameservice/simple/CacheTest.java generic-all +sun/net/InetAddress/nameservice/simple/DefaultCaching.java generic-all + ############################################################################ # jdk_io @@ -208,6 +215,9 @@ java/rmi/server/Unreferenced/finiteGCLat # 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java generic-all + +# 7146541 +java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java linux-all # 7132247 java/rmi/registry/readTest/readTest.sh windows-all @@ -319,6 +329,9 @@ tools/pack200/CommandLineTests.java tools/pack200/CommandLineTests.java generic-all tools/pack200/Pack200Test.java generic-all +# 7148499 +tools/launcher/Settings.java generic-all + ############################################################################ # jdk_util From chris.hegarty at oracle.com Sun Feb 26 10:41:13 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 26 Feb 2012 10:41:13 +0000 Subject: 7148921: More ProblemList updates (2/2012) Message-ID: Looks fine to me. -Chris Alan Bateman wrote: > >The war on tests continues and I'd like to several tests to the >ProblemList until the relevant issues are resolved. There are changes in >hs23-b15 and b16 that expose tests that are too sensitive to the GC >behavior and minimum thread stack size. There are also a couple of tests >that need to made more robust so that they can reliably. > >Thanks, >Alan. > > >diff --git a/test/ProblemList.txt b/test/ProblemList.txt >--- a/test/ProblemList.txt >+++ b/test/ProblemList.txt >@@ -131,6 +131,9 @@ java/lang/management/ThreadMXBean/Thread > # 7067973 > java/lang/management/MemoryMXBean/CollectionUsageThreshold.java >generic-all > >+# 7148492 >+java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java generic-all >+ > ############################################################################ > > # jdk_management >@@ -179,6 +182,10 @@ java/net/InetAddress/CheckJNI.java > # 7102702 > java/net/PortUnreachableException/OneExceptionOnly.java >windows-all > >+# 7148829 >+sun/net/InetAddress/nameservice/simple/CacheTest.java generic-all >+sun/net/InetAddress/nameservice/simple/DefaultCaching.java generic-all >+ > ############################################################################ > > # jdk_io >@@ -208,6 +215,9 @@ java/rmi/server/Unreferenced/finiteGCLat > > # 6948101 > java/rmi/transport/pinLastArguments/PinLastArguments.java generic-all >+ >+# 7146541 >+java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java >linux-all > > # 7132247 > java/rmi/registry/readTest/readTest.sh windows-all >@@ -319,6 +329,9 @@ tools/pack200/CommandLineTests.java > tools/pack200/CommandLineTests.java generic-all > tools/pack200/Pack200Test.java generic-all > >+# 7148499 >+tools/launcher/Settings.java generic-all >+ > ############################################################################ > > # jdk_util > From alan.bateman at oracle.com Sun Feb 26 17:26:47 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 26 Feb 2012 17:26:47 +0000 Subject: hg: jdk8/tl/jdk: 7148921: More ProblemList updates (2/2012) Message-ID: <20120226172716.20F87476C2@hg.openjdk.java.net> Changeset: 434e680b444f Author: alanb Date: 2012-02-26 17:25 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/434e680b444f 7148921: More ProblemList updates (2/2012) Reviewed-by: chegar ! test/ProblemList.txt From sean.mullan at oracle.com Mon Feb 27 18:51:45 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 27 Feb 2012 18:51:45 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120227185215.8C0DA476D6@hg.openjdk.java.net> Changeset: 805fc337bbe8 Author: mullan Date: 2012-02-27 11:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/805fc337bbe8 7147830: NullPointerException in java.security.Policy.implies() when the ProtectionDomain has a null code sou Reviewed-by: vinnie ! src/share/classes/sun/security/provider/PolicyFile.java + test/sun/security/provider/PolicyFile/NullCodeSource.java Changeset: cdf6184a7d5c Author: mullan Date: 2012-02-27 13:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf6184a7d5c Merge From mike.duigou at oracle.com Tue Feb 28 02:20:50 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 28 Feb 2012 02:20:50 +0000 Subject: hg: jdk8/tl/jdk: 7143162: Allow disable building of jdk demos and samples Message-ID: <20120228022101.E996C476D9@hg.openjdk.java.net> Changeset: 323abe0e8973 Author: mduigou Date: 2012-02-27 18:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/323abe0e8973 7143162: Allow disable building of jdk demos and samples Reviewed-by: ohair ! make/Makefile ! make/common/Release.gmk ! make/common/shared/Sanity-Settings.gmk From mike.duigou at oracle.com Tue Feb 28 02:22:59 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 28 Feb 2012 02:22:59 +0000 Subject: hg: jdk8/tl: 7143162: Allow disable building of jdk demos and samples Message-ID: <20120228022259.4B308476DA@hg.openjdk.java.net> Changeset: 28f2fe471725 Author: mduigou Date: 2012-02-27 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/28f2fe471725 7143162: Allow disable building of jdk demos and samples Reviewed-by: ohair ! make/sanity-rules.gmk From mike.duigou at oracle.com Tue Feb 28 03:57:48 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 27 Feb 2012 19:57:48 -0800 Subject: RFR 7149320: Move sun.misc.VM.booted() to end of System.initializeSystemClass() Message-ID: <200CDD79-6284-4E79-AF57-C883721E9F78@oracle.com> Hello all; This issue is a patch for review that I have split out of a larger issue I'll be submitting later. WEBREV @ http://cr.openjdk.java.net/~mduigou/7149320/0/webrev/ sun.misc.VM.booted() is currently called before setJavaLangAccess(). For code which uses the JavaLangAccess shared secrets it's convenient to be able to check whether the secrets are initialized without having to call sun.misc.SharedSecrets.getJavaLangAccess() every time the secrets are used and checking for null. In particular with the static inner class holder idiom it would be desirable to do : static class Holder { final sun.misc.JavaLangAccess ACCESS = sun.misc.SharedSecrets.getJavaLangAccess(); } ... if(sun.misc.VM.isBooted() && Holder.ACCESS... In my research on this issue I was unable to determine why sun.misc.VM.booted() isn't the currently the last activity in System.initSystemClass(). Neither of the two tasks which currently follow it depend upon booted state in any way that I could determine. I am tempted, thinking about it, to add a comment to System.initSystemClass before the call to sun.misc.VM.booted() asking future maintainers to leave boot() as the last activity or explain why not. I have done JTReg runs on linux x86, linux x64 and Solaris 64 which incorporated this change without any problems encountered. It's rather difficult to write a unit test for this issue as it requires a class that is initialized after java.lang.System but before java.lang.System.initSystemClass() and uses JavaLangAccess. Thanks, Mike From david.holmes at oracle.com Tue Feb 28 04:50:23 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Feb 2012 14:50:23 +1000 Subject: RFR 7149320: Move sun.misc.VM.booted() to end of System.initializeSystemClass() In-Reply-To: <200CDD79-6284-4E79-AF57-C883721E9F78@oracle.com> References: <200CDD79-6284-4E79-AF57-C883721E9F78@oracle.com> Message-ID: <4F4C5D0F.8060900@oracle.com> Hi Mike, The problem with changing initialization order is that you can never enumerate all the possible initialization paths. I don't see anything problematic with the move in relation to Thread.currentThread() or ThreadGroup.add(). But the call to setJavaLangAccess requires initialization of SharedSecrets which in turn requires initialization of Unsafe which in turn initializes sun.reflect.Reflection which in turn initializes a bunch of Collection classes - and suddenly we may have a whole swag of classes now being initialized before the VM appears to be booted. If you then throw into the mix the possibility of different system properties affecting initialization actions, or the existence of an agent, then who knows what might actually happen. Cheers, David ----- On 28/02/2012 1:57 PM, Mike Duigou wrote: > Hello all; > > This issue is a patch for review that I have split out of a larger issue I'll be submitting later. > > WEBREV @ http://cr.openjdk.java.net/~mduigou/7149320/0/webrev/ > > sun.misc.VM.booted() is currently called before setJavaLangAccess(). For code which uses the JavaLangAccess shared secrets it's convenient to be able to check whether the secrets are initialized without having to call sun.misc.SharedSecrets.getJavaLangAccess() every time the secrets are used and checking for null. In particular with the static inner class holder idiom it would be desirable to do : > > static class Holder { > final sun.misc.JavaLangAccess ACCESS = sun.misc.SharedSecrets.getJavaLangAccess(); > } > > ... > > if(sun.misc.VM.isBooted()&& Holder.ACCESS... > > In my research on this issue I was unable to determine why sun.misc.VM.booted() isn't the currently the last activity in System.initSystemClass(). Neither of the two tasks which currently follow it depend upon booted state in any way that I could determine. I am tempted, thinking about it, to add a comment to System.initSystemClass before the call to sun.misc.VM.booted() asking future maintainers to leave boot() as the last activity or explain why not. > > I have done JTReg runs on linux x86, linux x64 and Solaris 64 which incorporated this change without any problems encountered. It's rather difficult to write a unit test for this issue as it requires a class that is initialized after java.lang.System but before java.lang.System.initSystemClass() and uses JavaLangAccess. > > Thanks, > > Mike From ptisnovs at redhat.com Tue Feb 28 13:36:51 2012 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Tue, 28 Feb 2012 14:36:51 +0100 Subject: Reviewer needed: (JDK7) fixed three typos in a class ScriptEngineManager Message-ID: <4F4CD873.9080307@redhat.com> Hi, I'd like to fix three typos in ScriptEngineManager class's JavaDoc. This class contains method getEngineFactories() which returns list of factories, not an array of factories. Here is a webrew created against OpenJDK7: http://cr.openjdk.java.net/~ptisnovs/ScriptEngineManager/ Can anybody review this change please? PS: similar typos exist in OpenJDK6 too. Thank you in advance, Pavel Tisnovsky From Alan.Bateman at oracle.com Tue Feb 28 13:48:58 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Feb 2012 13:48:58 +0000 Subject: Reviewer needed: (JDK7) fixed three typos in a class ScriptEngineManager In-Reply-To: <4F4CD873.9080307@redhat.com> References: <4F4CD873.9080307@redhat.com> Message-ID: <4F4CDB4A.4060005@oracle.com> On 28/02/2012 13:36, Pavel Tisnovsky wrote: > Hi, > > I'd like to fix three typos in ScriptEngineManager class's JavaDoc. > This class contains method getEngineFactories() which returns > list of factories, not an array of factories. > > Here is a webrew created against OpenJDK7: > > http://cr.openjdk.java.net/~ptisnovs/ScriptEngineManager/ > > Can anybody review this change please? > > PS: similar typos exist in OpenJDK6 too. > > Thank you in advance, > Pavel Tisnovsky Looks okay to me. One of the rules [1] for changes going into jdk7u is that the change be in jdk8 first. The jdk8/tl/jdk repository would be the best place to push this. -Alan [1] http://openjdk.java.net/projects/jdk7u/groundrules.html From forax at univ-mlv.fr Tue Feb 28 13:54:45 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 28 Feb 2012 14:54:45 +0100 Subject: Reviewer needed: (JDK7) fixed three typos in a class ScriptEngineManager In-Reply-To: <4F4CDB4A.4060005@oracle.com> References: <4F4CD873.9080307@redhat.com> <4F4CDB4A.4060005@oracle.com> Message-ID: <4F4CDCA5.7050502@univ-mlv.fr> On 02/28/2012 02:48 PM, Alan Bateman wrote: > On 28/02/2012 13:36, Pavel Tisnovsky wrote: >> Hi, >> >> I'd like to fix three typos in ScriptEngineManager class's JavaDoc. >> This class contains method getEngineFactories() which returns >> list of factories, not an array of factories. >> >> Here is a webrew created against OpenJDK7: >> >> http://cr.openjdk.java.net/~ptisnovs/ScriptEngineManager/ >> >> Can anybody review this change please? >> >> PS: similar typos exist in OpenJDK6 too. >> >> Thank you in advance, >> Pavel Tisnovsky > Looks okay to me. One of the rules [1] for changes going into jdk7u is > that the change be in jdk8 first. The jdk8/tl/jdk repository would be > the best place to push this. > > -Alan > > [1] http://openjdk.java.net/projects/jdk7u/groundrules.html It's ok for me too. R?mi From vitalyd at gmail.com Tue Feb 28 14:26:35 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 28 Feb 2012 09:26:35 -0500 Subject: java.util.UUID.fromString performance Message-ID: Hi all, I noticed that this method could be made a bit more performant by: 1) creating a statically initialized Pattern for "-" and then calling split() on that. Currently the method calls name.split() which compiles the pattern on each invocation. 2) use Long.parseLong() instead of Long.decode() to extract the bits. With these changes, the method runs at least 20% faster (some runs were significantly faster) on an Intel Westmere server and should be a bit more GC friendly. Any thoughts? I can send the full code a bit later when I'm in front of my computer. Thanks Sent from my phone From Alan.Bateman at oracle.com Tue Feb 28 14:37:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Feb 2012 14:37:09 +0000 Subject: java.util.UUID.fromString performance In-Reply-To: References: Message-ID: <4F4CE695.50501@oracle.com> On 28/02/2012 14:26, Vitaly Davidovich wrote: > Hi all, > > I noticed that this method could be made a bit more performant by: > > 1) creating a statically initialized Pattern for "-" and then calling > split() on that. Currently the method calls name.split() which compiles > the pattern on each invocation. > > 2) use Long.parseLong() instead of Long.decode() to extract the bits. > > With these changes, the method runs at least 20% faster (some runs were > significantly faster) on an Intel Westmere server and should be a bit more > GC friendly. > > Any thoughts? I can send the full code a bit later when I'm in front of my > computer. > > Thanks > > Sent from my phone Just on name.split, are you sure this is compiling a pattern each time? There is a fast path in String.split since jdk7 for the common case so I would not expect the regex code to be used. -Alan. From vitalyd at gmail.com Tue Feb 28 14:40:23 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 28 Feb 2012 09:40:23 -0500 Subject: java.util.UUID.fromString performance In-Reply-To: <4F4CE695.50501@oracle.com> References: <4F4CE695.50501@oracle.com> Message-ID: Alan, Sorry I should've stated that I looked at this in detail in java 6 but only glanced at the UUID impl in 7 just now on my phone. If String.split() has a fast path now then forget my suggestion #1 :). Using Long.parseLong should still be applicable though. Thanks Sent from my phone On Feb 28, 2012 9:37 AM, "Alan Bateman" wrote: > On 28/02/2012 14:26, Vitaly Davidovich wrote: > >> Hi all, >> >> I noticed that this method could be made a bit more performant by: >> >> 1) creating a statically initialized Pattern for "-" and then calling >> split() on that. Currently the method calls name.split() which compiles >> the pattern on each invocation. >> >> 2) use Long.parseLong() instead of Long.decode() to extract the bits. >> >> With these changes, the method runs at least 20% faster (some runs were >> significantly faster) on an Intel Westmere server and should be a bit more >> GC friendly. >> >> Any thoughts? I can send the full code a bit later when I'm in front of my >> computer. >> >> Thanks >> >> Sent from my phone >> > Just on name.split, are you sure this is compiling a pattern each time? > There is a fast path in String.split since jdk7 for the common case so I > would not expect the regex code to be used. > > -Alan. > From ptisnovs at redhat.com Tue Feb 28 14:59:08 2012 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Tue, 28 Feb 2012 15:59:08 +0100 Subject: Reviewer needed: (JDK7) fixed three typos in a class ScriptEngineManager In-Reply-To: <4F4CDB4A.4060005@oracle.com> References: <4F4CD873.9080307@redhat.com> <4F4CDB4A.4060005@oracle.com> Message-ID: <4F4CEBBC.5090601@redhat.com> Alan Bateman wrote: > On 28/02/2012 13:36, Pavel Tisnovsky wrote: >> Hi, >> >> I'd like to fix three typos in ScriptEngineManager class's JavaDoc. >> This class contains method getEngineFactories() which returns >> list of factories, not an array of factories. >> >> Here is a webrew created against OpenJDK7: >> >> http://cr.openjdk.java.net/~ptisnovs/ScriptEngineManager/ >> >> Can anybody review this change please? >> >> PS: similar typos exist in OpenJDK6 too. >> >> Thank you in advance, >> Pavel Tisnovsky > Looks okay to me. One of the rules [1] for changes going into jdk7u is > that the change be in jdk8 first. The jdk8/tl/jdk repository would be > the best place to push this. Hi Alan and R?mi, thank you for review. According to rules I've prepared webrew for JDK8 http://cr.openjdk.java.net/~ptisnovs/ScriptEngineManager_jdk8/ (changed texts are the same, but line numbers differ) Pavel PS: I have not a chance to push anything to JDK8 yet. Do I have the rights to push anything to JDK8 tl inherited from JDK6 or 7? > > -Alan > > [1] http://openjdk.java.net/projects/jdk7u/groundrules.html From Alan.Bateman at oracle.com Tue Feb 28 15:42:19 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Feb 2012 15:42:19 +0000 Subject: Reviewer needed: (JDK7) fixed three typos in a class ScriptEngineManager In-Reply-To: <4F4CEBBC.5090601@redhat.com> References: <4F4CD873.9080307@redhat.com> <4F4CDB4A.4060005@oracle.com> <4F4CEBBC.5090601@redhat.com> Message-ID: <4F4CF5DB.1040404@oracle.com> On 28/02/2012 14:59, Pavel Tisnovsky wrote: > : > Hi Alan and R?mi, > > thank you for review. > > According to rules I've prepared webrew for JDK8 > http://cr.openjdk.java.net/~ptisnovs/ScriptEngineManager_jdk8/ > > (changed texts are the same, but line numbers differ) > > Pavel > > PS: I have not a chance to push anything to JDK8 yet. > Do I have the rights to push anything to JDK8 tl inherited from JDK6 or 7? > > The webrev looks fine. You are listed as a committer for jdk8 so you should be able to push the change. -Alan. From joe.darcy at oracle.com Tue Feb 28 17:03:24 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 28 Feb 2012 09:03:24 -0800 Subject: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method In-Reply-To: <4E268BB7.9090603@oracle.com> References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com> <62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net> <4E23E5E8.4010507@oracle.com> <4E25DFD7.4090102@oracle.com> <4E268BB7.9090603@oracle.com> Message-ID: <4F4D08DC.4030601@oracle.com> Hi David, Belatedly catching up on email, please review the patch below to address the issues you've raised. I searched for "method" and replaced it with "executable" as appropriate throughout the javadoc of the class. Thanks, -Joe --- a/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 17:00:28 2012 +0400 +++ b/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 09:01:27 2012 -0800 @@ -180,7 +180,7 @@ /** * Returns the {@code Class} object representing the class or interface - * that declares the method represented by this executable object. + * that declares the executable represented by this object. */ public abstract Class getDeclaringClass(); @@ -215,18 +215,18 @@ * Returns an array of {@code Class} objects that represent the formal * parameter types, in declaration order, of the executable * represented by this object. Returns an array of length - * 0 if the underlying method takes no parameters. + * 0 if the underlying executable takes no parameters. * - * @return the parameter types for the method this object + * @return the parameter types for the executable this object * represents */ public abstract Class[] getParameterTypes(); /** * Returns an array of {@code Type} objects that represent the formal - * parameter types, in declaration order, of the method represented by - * this executable object. Returns an array of length 0 if the - * underlying method takes no parameters. + * parameter types, in declaration order, of the executable represented by + * this object. Returns an array of length 0 if the + * underlying executable takes no parameters. * *

If a formal parameter type is a parameterized type, * the {@code Type} object returned for it must accurately reflect @@ -236,16 +236,16 @@ * type, it is created. Otherwise, it is resolved. * * @return an array of {@code Type}s that represent the formal - * parameter types of the underlying method, in declaration order + * parameter types of the underlying executable, in declaration order * @throws GenericSignatureFormatError * if the generic method signature does not conform to the format * specified in * The Java™ Virtual Machine Specification * @throws TypeNotPresentException if any of the parameter - * types of the underlying method refers to a non-existent type + * types of the underlying executable refers to a non-existent type * declaration * @throws MalformedParameterizedTypeException if any of - * the underlying method's parameter types refer to a parameterized + * the underlying executable's parameter types refer to a parameterized * type that cannot be instantiated for any reason */ public Type[] getGenericParameterTypes() { @@ -277,15 +277,15 @@ * type, it is created. Otherwise, it is resolved. * * @return an array of Types that represent the exception types - * thrown by the underlying method + * thrown by the underlying executable * @throws GenericSignatureFormatError * if the generic method signature does not conform to the format * specified in * The Java™ Virtual Machine Specification - * @throws TypeNotPresentException if the underlying method's + * @throws TypeNotPresentException if the underlying executable's * {@code throws} clause refers to a non-existent type declaration * @throws MalformedParameterizedTypeException if - * the underlying method's {@code throws} clause refers to a + * the underlying executable's {@code throws} clause refers to a * parameterized type that cannot be instantiated for any reason */ public Type[] getGenericExceptionTypes() { @@ -330,7 +330,7 @@ * Returns an array of arrays that represent the annotations on * the formal parameters, in declaration order, of the executable * represented by this object. (Returns an array of length zero if - * the underlying method is parameterless. If the executable has + * the underlying executable is parameterless. If the executable has * one or more parameters, a nested array of length zero is * returned for each parameter with no annotations.) The * annotation objects contained in the returned arrays are On 07/20/2011 01:03 AM, David Holmes wrote: > Just realized this has come in too late ... > > Joe Darcy said the following on 07/20/11 05:49: >> Agreed; I've posted a BlenderRev corresponding to the current patch at: >> >> http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html > > Thanks. So now I can more readily see that the doc for Executable > isn't quite suitable for Constructor in a few places: > > getDeclaringClass: > > 183 /** > 184 * Returns the {@code Class} object representing the class or > interface > 185 * that declares the method represented by this executable > object. > 186 */ > > For Constructor "method" should be "constructor". But I think, looking > at the terminology elsewhere that the above could be rewritten as: > > "Returns the Class object representing the class or interface that > declares the executable represented by this object." > > getParameterTypes: > > 219 * represented by this object. Returns an array of length > 220 * 0 if the underlying method takes no parameters. > > method -> executable > > getGenericParameterTypes: > > 229 * parameter types, in declaration order, of the method > represented by > 230 * this executable object. Returns an array of length 0 if the > 231 * underlying method takes no parameters. > > Again change to " the executable represented by this object". > And then: underlying method -> underlying executable > > 241 * parameter types of the underlying method, in > declaration order > 243 * if the generic method signature does not conform to the > format > 247 * types of the underlying method refers to a non-existent > type > 250 * the underlying method's parameter types refer to a > parameterized > > method -> executable > > In fact do a search for "method" in Executable and most occurrences > should be changed to "executable". > > > Finally, in getModifiers, why delete the "as an integer. The Modifier > class should be used to decode the modifiers. " ? > > > BTW I also find the multiple "Specified by:" references to be quite > strange. There can only be one specification for a method. > > David > ----- > >> Thanks, >> >> -Joe >> >> Mike Duigou wrote: >>> This looks good to me but I agree with David that it's probably >>> important to look at the generated javadoc and specdiff output >>> before finalizing. >>> >>> Mike >>> >>> On Jul 18 2011, at 00:51 , Joe Darcy wrote: >>> >>> >>>> Peter and David. >>>> >>>> Thanks for the careful review; the @throws information still needs >>>> its own {@inheritDoc}; I've uploaded a webrev with this and other >>>> corrections: >>>> >>>> http://cr.openjdk.java.net/~darcy/7007535.4 >>>> >>>> More comments interspersed below. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> Peter Jones wrote: >>>>> Hi Joe, >>>>> >>>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote: >>>>> >>>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote: >>>>>>> Please code review my JDK 8 changes for >>>>>>> >>>>>>> 7007535: (reflect) Please generalize Constructor and Method >>>>>>> http://cr.openjdk.java.net/~darcy/7007535.3 >>>>>>> >>>>>>> To summarize the changes, a new superclass is defined to capture >>>>>>> the common >>>>>>> functionality of java.lang.reflect.Method and >>>>>>> java.lang.reflect.Constructor. >>>>>>> That superclass is named "Executable" along the lines of >>>>>>> javax.lang.model.ExecutableElement, which models constructors >>>>>>> and methods in >>>>>>> the JSR 269 language model. >>>>>>> >>>>>>> Both specification and implementation code are shared. To >>>>>>> preserve the right >>>>>>> @since behavior, it is common that in Method/Constructor the >>>>>>> javadoc for a >>>>>>> method will now look like: >>>>>>> >>>>>>> /** >>>>>>> * {@inheritDoc} >>>>>>> * @since 1.5 >>>>>>> */ >>>>>> Unless they have fixed/changed javadoc (entirely possible) it >>>>>> used to be that the above would not cause @throws declarations >>>>>> for unchecked exceptions to be inherited - you have/had to >>>>>> explicitly repeat them as: >>>>>> >>>>>> @throws {@inheritDoc} >>>>> Yes, that would seem to be needed for some of the inherited >>>>> getters of generics info, which specify unchecked exception types. >>>>> >>>>> >>>>>>> Since Executable is being created in JDK 8, it would be >>>>>>> incorrect for >>>>>>> methods in that class to have an @since of 1.5; adding the >>>>>>> @since in >>>>>>> Method/Constructor preserves the right information. >>>>> In Executable.java, getAnnotation and getDeclaredAnnotations do >>>>> have "@since 1.5"-- oversight? >>>>> >>>> Yes; that was incorrect. >>>> >>>>> In Constructor.java and Method.java, getExceptionTypes has "@since >>>>> 1.5", but that method has existed in those classes since 1.1. >>>>> >>>>> >>>> Fixed. >>>> >>>>> In Executable.java: >>>>> >>>>> 216 /** >>>>> 217 * Returns an array of {@code Class} objects that >>>>> represent the formal >>>>> 218 * parameter types, in declaration order, of the method >>>>> 219 * represented by this {@code Method} object. Returns an >>>>> array of length >>>>> 220 * 0 if the underlying method takes no parameters. >>>>> 221 * >>>>> 222 * @return the parameter types for the method this object >>>>> 223 * represents >>>>> >>>>> At least "{@code Method}" needs to be generalized, and perhaps all >>>>> occurrences of "method"? >>>>> >>>> Corrected. >>> >> From jonathan.gibbons at oracle.com Tue Feb 28 18:26:38 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Feb 2012 18:26:38 +0000 Subject: hg: jdk8/tl/langtools: 7144951: fix minor javadoc issues Message-ID: <20120228182643.4D8E7476E5@hg.openjdk.java.net> Changeset: c4d6a8884ed8 Author: jjg Date: 2012-02-28 10:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c4d6a8884ed8 7144951: fix minor javadoc issues Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/tools/doclets/package.html From mike.duigou at oracle.com Tue Feb 28 17:37:01 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 28 Feb 2012 09:37:01 -0800 Subject: java.util.UUID.fromString performance In-Reply-To: References: Message-ID: <7CD0614C-5C47-42C3-995F-87748FC41966@oracle.com> The easiest wat to proceed would be for you to submit a webrev patch with both changes along with your microbenchmark test. Once the change is incorporated in the jdk8 mainline the sustaining teams can evaluate it for backporting to jdk 7 and 6. Mike On Feb 28 2012, at 06:26 , Vitaly Davidovich wrote: > Hi all, > > I noticed that this method could be made a bit more performant by: > > 1) creating a statically initialized Pattern for "-" and then calling > split() on that. Currently the method calls name.split() which compiles > the pattern on each invocation. > > 2) use Long.parseLong() instead of Long.decode() to extract the bits. > > With these changes, the method runs at least 20% faster (some runs were > significantly faster) on an Intel Westmere server and should be a bit more > GC friendly. > > Any thoughts? I can send the full code a bit later when I'm in front of my > computer. > > Thanks > > Sent from my phone From jonathan.gibbons at oracle.com Tue Feb 28 18:34:17 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Feb 2012 18:34:17 +0000 Subject: hg: jdk8/tl/langtools: 7093891: support multiple task listeners Message-ID: <20120228183419.3A7AF476E6@hg.openjdk.java.net> Changeset: 62e611704863 Author: jjg Date: 2012-02-28 10:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/62e611704863 7093891: support multiple task listeners Reviewed-by: darcy, mcimadamore ! src/share/classes/com/sun/source/util/JavacTask.java + src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + src/share/classes/com/sun/tools/javac/api/MultiTaskListener.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/api/taskListeners/TestSimpleAddRemove.java ! test/tools/javac/processing/loader/testClose/TestClose.java From jonathan.gibbons at oracle.com Tue Feb 28 18:48:24 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Feb 2012 18:48:24 +0000 Subject: hg: jdk8/tl/langtools: 7147183: test/tools/javac/apt.sh can be removed from tl/langtools repository Message-ID: <20120228184826.F249C476E7@hg.openjdk.java.net> Changeset: 6b86f7274c0a Author: jjg Date: 2012-02-28 10:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b86f7274c0a 7147183: test/tools/javac/apt.sh can be removed from tl/langtools repository Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com - test/tools/javac/apt.sh From mike.duigou at oracle.com Tue Feb 28 18:52:46 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 28 Feb 2012 10:52:46 -0800 Subject: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method In-Reply-To: <4F4D08DC.4030601@oracle.com> References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com> <62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net> <4E23E5E8.4010507@oracle.com> <4E25DFD7.4090102@oracle.com> <4E268BB7.9090603@oracle.com> <4F4D08DC.4030601@oracle.com> Message-ID: <0C8B69FB-3430-4AE4-8711-435EE5E9BFCC@oracle.com> These changes look good to me. Is there a new CR for the javadoc changes? Mike On Feb 28 2012, at 09:03 , Joe Darcy wrote: > Hi David, > > Belatedly catching up on email, please review the patch below to address the issues you've raised. I searched for "method" and replaced it with "executable" as appropriate throughout the javadoc of the class. > > Thanks, > > -Joe > > --- a/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 17:00:28 2012 +0400 > +++ b/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 09:01:27 2012 -0800 > @@ -180,7 +180,7 @@ > > /** > * Returns the {@code Class} object representing the class or interface > - * that declares the method represented by this executable object. > + * that declares the executable represented by this object. > */ > public abstract Class getDeclaringClass(); > > @@ -215,18 +215,18 @@ > * Returns an array of {@code Class} objects that represent the formal > * parameter types, in declaration order, of the executable > * represented by this object. Returns an array of length > - * 0 if the underlying method takes no parameters. > + * 0 if the underlying executable takes no parameters. > * > - * @return the parameter types for the method this object > + * @return the parameter types for the executable this object > * represents > */ > public abstract Class[] getParameterTypes(); > > /** > * Returns an array of {@code Type} objects that represent the formal > - * parameter types, in declaration order, of the method represented by > - * this executable object. Returns an array of length 0 if the > - * underlying method takes no parameters. > + * parameter types, in declaration order, of the executable represented by > + * this object. Returns an array of length 0 if the > + * underlying executable takes no parameters. > * > *

If a formal parameter type is a parameterized type, > * the {@code Type} object returned for it must accurately reflect > @@ -236,16 +236,16 @@ > * type, it is created. Otherwise, it is resolved. > * > * @return an array of {@code Type}s that represent the formal > - * parameter types of the underlying method, in declaration order > + * parameter types of the underlying executable, in declaration order > * @throws GenericSignatureFormatError > * if the generic method signature does not conform to the format > * specified in > * The Java™ Virtual Machine Specification > * @throws TypeNotPresentException if any of the parameter > - * types of the underlying method refers to a non-existent type > + * types of the underlying executable refers to a non-existent type > * declaration > * @throws MalformedParameterizedTypeException if any of > - * the underlying method's parameter types refer to a parameterized > + * the underlying executable's parameter types refer to a parameterized > * type that cannot be instantiated for any reason > */ > public Type[] getGenericParameterTypes() { > @@ -277,15 +277,15 @@ > * type, it is created. Otherwise, it is resolved. > * > * @return an array of Types that represent the exception types > - * thrown by the underlying method > + * thrown by the underlying executable > * @throws GenericSignatureFormatError > * if the generic method signature does not conform to the format > * specified in > * The Java™ Virtual Machine Specification > - * @throws TypeNotPresentException if the underlying method's > + * @throws TypeNotPresentException if the underlying executable's > * {@code throws} clause refers to a non-existent type declaration > * @throws MalformedParameterizedTypeException if > - * the underlying method's {@code throws} clause refers to a > + * the underlying executable's {@code throws} clause refers to a > * parameterized type that cannot be instantiated for any reason > */ > public Type[] getGenericExceptionTypes() { > @@ -330,7 +330,7 @@ > * Returns an array of arrays that represent the annotations on > * the formal parameters, in declaration order, of the executable > * represented by this object. (Returns an array of length zero if > - * the underlying method is parameterless. If the executable has > + * the underlying executable is parameterless. If the executable has > * one or more parameters, a nested array of length zero is > * returned for each parameter with no annotations.) The > * annotation objects contained in the returned arrays are > > > On 07/20/2011 01:03 AM, David Holmes wrote: >> Just realized this has come in too late ... >> >> Joe Darcy said the following on 07/20/11 05:49: >>> Agreed; I've posted a BlenderRev corresponding to the current patch at: >>> >>> http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html >> >> Thanks. So now I can more readily see that the doc for Executable isn't quite suitable for Constructor in a few places: >> >> getDeclaringClass: >> >> 183 /** >> 184 * Returns the {@code Class} object representing the class or interface >> 185 * that declares the method represented by this executable object. >> 186 */ >> >> For Constructor "method" should be "constructor". But I think, looking at the terminology elsewhere that the above could be rewritten as: >> >> "Returns the Class object representing the class or interface that declares the executable represented by this object." >> >> getParameterTypes: >> >> 219 * represented by this object. Returns an array of length >> 220 * 0 if the underlying method takes no parameters. >> >> method -> executable >> >> getGenericParameterTypes: >> >> 229 * parameter types, in declaration order, of the method represented by >> 230 * this executable object. Returns an array of length 0 if the >> 231 * underlying method takes no parameters. >> >> Again change to " the executable represented by this object". >> And then: underlying method -> underlying executable >> >> 241 * parameter types of the underlying method, in declaration order >> 243 * if the generic method signature does not conform to the format >> 247 * types of the underlying method refers to a non-existent type >> 250 * the underlying method's parameter types refer to a parameterized >> >> method -> executable >> >> In fact do a search for "method" in Executable and most occurrences should be changed to "executable". >> >> >> Finally, in getModifiers, why delete the "as an integer. The Modifier class should be used to decode the modifiers. " ? >> >> >> BTW I also find the multiple "Specified by:" references to be quite strange. There can only be one specification for a method. >> >> David >> ----- >> >>> Thanks, >>> >>> -Joe >>> >>> Mike Duigou wrote: >>>> This looks good to me but I agree with David that it's probably important to look at the generated javadoc and specdiff output before finalizing. >>>> >>>> Mike >>>> >>>> On Jul 18 2011, at 00:51 , Joe Darcy wrote: >>>> >>>> >>>>> Peter and David. >>>>> >>>>> Thanks for the careful review; the @throws information still needs its own {@inheritDoc}; I've uploaded a webrev with this and other corrections: >>>>> >>>>> http://cr.openjdk.java.net/~darcy/7007535.4 >>>>> >>>>> More comments interspersed below. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> Peter Jones wrote: >>>>>> Hi Joe, >>>>>> >>>>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote: >>>>>> >>>>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote: >>>>>>>> Please code review my JDK 8 changes for >>>>>>>> >>>>>>>> 7007535: (reflect) Please generalize Constructor and Method >>>>>>>> http://cr.openjdk.java.net/~darcy/7007535.3 >>>>>>>> >>>>>>>> To summarize the changes, a new superclass is defined to capture the common >>>>>>>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor. >>>>>>>> That superclass is named "Executable" along the lines of >>>>>>>> javax.lang.model.ExecutableElement, which models constructors and methods in >>>>>>>> the JSR 269 language model. >>>>>>>> >>>>>>>> Both specification and implementation code are shared. To preserve the right >>>>>>>> @since behavior, it is common that in Method/Constructor the javadoc for a >>>>>>>> method will now look like: >>>>>>>> >>>>>>>> /** >>>>>>>> * {@inheritDoc} >>>>>>>> * @since 1.5 >>>>>>>> */ >>>>>>> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as: >>>>>>> >>>>>>> @throws {@inheritDoc} >>>>>> Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types. >>>>>> >>>>>> >>>>>>>> Since Executable is being created in JDK 8, it would be incorrect for >>>>>>>> methods in that class to have an @since of 1.5; adding the @since in >>>>>>>> Method/Constructor preserves the right information. >>>>>> In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight? >>>>>> >>>>> Yes; that was incorrect. >>>>> >>>>>> In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1. >>>>>> >>>>>> >>>>> Fixed. >>>>> >>>>>> In Executable.java: >>>>>> >>>>>> 216 /** >>>>>> 217 * Returns an array of {@code Class} objects that represent the formal >>>>>> 218 * parameter types, in declaration order, of the method >>>>>> 219 * represented by this {@code Method} object. Returns an array of length >>>>>> 220 * 0 if the underlying method takes no parameters. >>>>>> 221 * >>>>>> 222 * @return the parameter types for the method this object >>>>>> 223 * represents >>>>>> >>>>>> At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"? >>>>>> >>>>> Corrected. >>>> >>> > From joe.darcy at oracle.com Tue Feb 28 18:55:54 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 28 Feb 2012 10:55:54 -0800 Subject: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method In-Reply-To: <0C8B69FB-3430-4AE4-8711-435EE5E9BFCC@oracle.com> References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com> <62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net> <4E23E5E8.4010507@oracle.com> <4E25DFD7.4090102@oracle.com> <4E268BB7.9090603@oracle.com> <4F4D08DC.4030601@oracle.com> <0C8B69FB-3430-4AE4-8711-435EE5E9BFCC@oracle.com> Message-ID: <4F4D233A.7060400@oracle.com> On 2/28/2012 10:52 AM, Mike Duigou wrote: > These changes look good to me. Is there a new CR for the javadoc changes? Thanks Mike; I was planning to file the bug after the reviews came in. -Joe > Mike > > > On Feb 28 2012, at 09:03 , Joe Darcy wrote: > >> Hi David, >> >> Belatedly catching up on email, please review the patch below to address the issues you've raised. I searched for "method" and replaced it with "executable" as appropriate throughout the javadoc of the class. >> >> Thanks, >> >> -Joe >> >> --- a/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 17:00:28 2012 +0400 >> +++ b/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 09:01:27 2012 -0800 >> @@ -180,7 +180,7 @@ >> >> /** >> * Returns the {@code Class} object representing the class or interface >> - * that declares the method represented by this executable object. >> + * that declares the executable represented by this object. >> */ >> public abstract Class getDeclaringClass(); >> >> @@ -215,18 +215,18 @@ >> * Returns an array of {@code Class} objects that represent the formal >> * parameter types, in declaration order, of the executable >> * represented by this object. Returns an array of length >> - * 0 if the underlying method takes no parameters. >> + * 0 if the underlying executable takes no parameters. >> * >> - * @return the parameter types for the method this object >> + * @return the parameter types for the executable this object >> * represents >> */ >> public abstract Class[] getParameterTypes(); >> >> /** >> * Returns an array of {@code Type} objects that represent the formal >> - * parameter types, in declaration order, of the method represented by >> - * this executable object. Returns an array of length 0 if the >> - * underlying method takes no parameters. >> + * parameter types, in declaration order, of the executable represented by >> + * this object. Returns an array of length 0 if the >> + * underlying executable takes no parameters. >> * >> *

If a formal parameter type is a parameterized type, >> * the {@code Type} object returned for it must accurately reflect >> @@ -236,16 +236,16 @@ >> * type, it is created. Otherwise, it is resolved. >> * >> * @return an array of {@code Type}s that represent the formal >> - * parameter types of the underlying method, in declaration order >> + * parameter types of the underlying executable, in declaration order >> * @throws GenericSignatureFormatError >> * if the generic method signature does not conform to the format >> * specified in >> *The Java™ Virtual Machine Specification >> * @throws TypeNotPresentException if any of the parameter >> - * types of the underlying method refers to a non-existent type >> + * types of the underlying executable refers to a non-existent type >> * declaration >> * @throws MalformedParameterizedTypeException if any of >> - * the underlying method's parameter types refer to a parameterized >> + * the underlying executable's parameter types refer to a parameterized >> * type that cannot be instantiated for any reason >> */ >> public Type[] getGenericParameterTypes() { >> @@ -277,15 +277,15 @@ >> * type, it is created. Otherwise, it is resolved. >> * >> * @return an array of Types that represent the exception types >> - * thrown by the underlying method >> + * thrown by the underlying executable >> * @throws GenericSignatureFormatError >> * if the generic method signature does not conform to the format >> * specified in >> *The Java™ Virtual Machine Specification >> - * @throws TypeNotPresentException if the underlying method's >> + * @throws TypeNotPresentException if the underlying executable's >> * {@code throws} clause refers to a non-existent type declaration >> * @throws MalformedParameterizedTypeException if >> - * the underlying method's {@code throws} clause refers to a >> + * the underlying executable's {@code throws} clause refers to a >> * parameterized type that cannot be instantiated for any reason >> */ >> public Type[] getGenericExceptionTypes() { >> @@ -330,7 +330,7 @@ >> * Returns an array of arrays that represent the annotations on >> * the formal parameters, in declaration order, of the executable >> * represented by this object. (Returns an array of length zero if >> - * the underlying method is parameterless. If the executable has >> + * the underlying executable is parameterless. If the executable has >> * one or more parameters, a nested array of length zero is >> * returned for each parameter with no annotations.) The >> * annotation objects contained in the returned arrays are >> >> >> On 07/20/2011 01:03 AM, David Holmes wrote: >>> Just realized this has come in too late ... >>> >>> Joe Darcy said the following on 07/20/11 05:49: >>>> Agreed; I've posted a BlenderRev corresponding to the current patch at: >>>> >>>> http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html >>> Thanks. So now I can more readily see that the doc for Executable isn't quite suitable for Constructor in a few places: >>> >>> getDeclaringClass: >>> >>> 183 /** >>> 184 * Returns the {@code Class} object representing the class or interface >>> 185 * that declares the method represented by this executable object. >>> 186 */ >>> >>> For Constructor "method" should be "constructor". But I think, looking at the terminology elsewhere that the above could be rewritten as: >>> >>> "Returns the Class object representing the class or interface that declares the executable represented by this object." >>> >>> getParameterTypes: >>> >>> 219 * represented by this object. Returns an array of length >>> 220 * 0 if the underlying method takes no parameters. >>> >>> method -> executable >>> >>> getGenericParameterTypes: >>> >>> 229 * parameter types, in declaration order, of the method represented by >>> 230 * this executable object. Returns an array of length 0 if the >>> 231 * underlying method takes no parameters. >>> >>> Again change to " the executable represented by this object". >>> And then: underlying method -> underlying executable >>> >>> 241 * parameter types of the underlying method, in declaration order >>> 243 * if the generic method signature does not conform to the format >>> 247 * types of the underlying method refers to a non-existent type >>> 250 * the underlying method's parameter types refer to a parameterized >>> >>> method -> executable >>> >>> In fact do a search for "method" in Executable and most occurrences should be changed to "executable". >>> >>> >>> Finally, in getModifiers, why delete the "as an integer. The Modifier class should be used to decode the modifiers. " ? >>> >>> >>> BTW I also find the multiple "Specified by:" references to be quite strange. There can only be one specification for a method. >>> >>> David >>> ----- >>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> Mike Duigou wrote: >>>>> This looks good to me but I agree with David that it's probably important to look at the generated javadoc and specdiff output before finalizing. >>>>> >>>>> Mike >>>>> >>>>> On Jul 18 2011, at 00:51 , Joe Darcy wrote: >>>>> >>>>> >>>>>> Peter and David. >>>>>> >>>>>> Thanks for the careful review; the @throws information still needs its own {@inheritDoc}; I've uploaded a webrev with this and other corrections: >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/7007535.4 >>>>>> >>>>>> More comments interspersed below. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>> Peter Jones wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote: >>>>>>> >>>>>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote: >>>>>>>>> Please code review my JDK 8 changes for >>>>>>>>> >>>>>>>>> 7007535: (reflect) Please generalize Constructor and Method >>>>>>>>> http://cr.openjdk.java.net/~darcy/7007535.3 >>>>>>>>> >>>>>>>>> To summarize the changes, a new superclass is defined to capture the common >>>>>>>>> functionality of java.lang.reflect.Method and java.lang.reflect.Constructor. >>>>>>>>> That superclass is named "Executable" along the lines of >>>>>>>>> javax.lang.model.ExecutableElement, which models constructors and methods in >>>>>>>>> the JSR 269 language model. >>>>>>>>> >>>>>>>>> Both specification and implementation code are shared. To preserve the right >>>>>>>>> @since behavior, it is common that in Method/Constructor the javadoc for a >>>>>>>>> method will now look like: >>>>>>>>> >>>>>>>>> /** >>>>>>>>> * {@inheritDoc} >>>>>>>>> * @since 1.5 >>>>>>>>> */ >>>>>>>> Unless they have fixed/changed javadoc (entirely possible) it used to be that the above would not cause @throws declarations for unchecked exceptions to be inherited - you have/had to explicitly repeat them as: >>>>>>>> >>>>>>>> @throws {@inheritDoc} >>>>>>> Yes, that would seem to be needed for some of the inherited getters of generics info, which specify unchecked exception types. >>>>>>> >>>>>>> >>>>>>>>> Since Executable is being created in JDK 8, it would be incorrect for >>>>>>>>> methods in that class to have an @since of 1.5; adding the @since in >>>>>>>>> Method/Constructor preserves the right information. >>>>>>> In Executable.java, getAnnotation and getDeclaredAnnotations do have "@since 1.5"-- oversight? >>>>>>> >>>>>> Yes; that was incorrect. >>>>>> >>>>>>> In Constructor.java and Method.java, getExceptionTypes has "@since 1.5", but that method has existed in those classes since 1.1. >>>>>>> >>>>>>> >>>>>> Fixed. >>>>>> >>>>>>> In Executable.java: >>>>>>> >>>>>>> 216 /** >>>>>>> 217 * Returns an array of {@code Class} objects that represent the formal >>>>>>> 218 * parameter types, in declaration order, of the method >>>>>>> 219 * represented by this {@code Method} object. Returns an array of length >>>>>>> 220 * 0 if the underlying method takes no parameters. >>>>>>> 221 * >>>>>>> 222 * @return the parameter types for the method this object >>>>>>> 223 * represents >>>>>>> >>>>>>> At least "{@code Method}" needs to be generalized, and perhaps all occurrences of "method"? >>>>>>> >>>>>> Corrected. From mike.duigou at oracle.com Tue Feb 28 19:23:05 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 28 Feb 2012 11:23:05 -0800 Subject: RFR 7149320: Move sun.misc.VM.booted() to end of System.initializeSystemClass() In-Reply-To: <4F4C5D0F.8060900@oracle.com> References: <200CDD79-6284-4E79-AF57-C883721E9F78@oracle.com> <4F4C5D0F.8060900@oracle.com> Message-ID: On Feb 27 2012, at 20:50 , David Holmes wrote: > Hi Mike, > > The problem with changing initialization order is that you can never enumerate all the possible initialization paths. I don't see anything problematic with the move in relation to Thread.currentThread() or ThreadGroup.add(). But the call to setJavaLangAccess requires initialization of SharedSecrets which in turn requires initialization of Unsafe which in turn initializes sun.reflect.Reflection which in turn initializes a bunch of Collection classes - and suddenly we may have a whole swag of classes now being initialized before the VM appears to be booted. The class initialization I'm interested in does occur during the SharedSecrets initialization path. Because, in the current implementation, booted() hasn't been called the only way I can determine if the class is being used before boot() is to check if the SharedSecrets have been initialized. This ends up being cumbersome and permanently leaves some checking logic in the execution path for what is a very narrow window. I've looked at where isBooted is currently being used and none of the uses would seem to be sensitive to being called > If you then throw into the mix the possibility of different system properties affecting initialization actions, or the existence of an agent, then who knows what might actually happen. Do you believe that the change is as a result too risky to consider? Are there validations that could/should be done to reduce or eliminate the risk? > Cheers, > David > ----- > > > On 28/02/2012 1:57 PM, Mike Duigou wrote: >> Hello all; >> >> This issue is a patch for review that I have split out of a larger issue I'll be submitting later. >> >> WEBREV @ http://cr.openjdk.java.net/~mduigou/7149320/0/webrev/ >> >> sun.misc.VM.booted() is currently called before setJavaLangAccess(). For code which uses the JavaLangAccess shared secrets it's convenient to be able to check whether the secrets are initialized without having to call sun.misc.SharedSecrets.getJavaLangAccess() every time the secrets are used and checking for null. In particular with the static inner class holder idiom it would be desirable to do : >> >> static class Holder { >> final sun.misc.JavaLangAccess ACCESS = sun.misc.SharedSecrets.getJavaLangAccess(); >> } >> >> ... >> >> if(sun.misc.VM.isBooted()&& Holder.ACCESS... >> >> In my research on this issue I was unable to determine why sun.misc.VM.booted() isn't the currently the last activity in System.initSystemClass(). Neither of the two tasks which currently follow it depend upon booted state in any way that I could determine. I am tempted, thinking about it, to add a comment to System.initSystemClass before the call to sun.misc.VM.booted() asking future maintainers to leave boot() as the last activity or explain why not. >> >> I have done JTReg runs on linux x86, linux x64 and Solaris 64 which incorporated this change without any problems encountered. It's rather difficult to write a unit test for this issue as it requires a class that is initialized after java.lang.System but before java.lang.System.initSystemClass() and uses JavaLangAccess. >> >> Thanks, >> >> Mike From joe.darcy at oracle.com Tue Feb 28 21:15:01 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 28 Feb 2012 21:15:01 +0000 Subject: hg: jdk8/tl/jdk: 7149626: (reflect) Improve javadoc of java.lang.reflect.Executable Message-ID: <20120228211510.AFF94476F3@hg.openjdk.java.net> Changeset: b62922b54170 Author: darcy Date: 2012-02-28 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b62922b54170 7149626: (reflect) Improve javadoc of java.lang.reflect.Executable Reviewed-by: mduigou ! src/share/classes/java/lang/reflect/Executable.java From stuart.marks at oracle.com Tue Feb 28 23:08:05 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 28 Feb 2012 15:08:05 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F480E14.8030109@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> <4F455D47.1080002@oracle.com> <4F475033.4040002@oracle.com> <4F47DE7E.9010107@oracle.com> <4F480E14.8030109@oracle.com> Message-ID: <4F4D5E55.8040109@oracle.com> Hi Kurchi, I looked at the rest of the files. Pretty good, taking on diamond, multi-catch, and try-with-resources as well! I have several comments. Mostly nitpicks, but a few items worthy of some discussion, but overall still minor changes, I think. com/sun/rmi/rmid/ExecOptionPermission.java: - L234 can use diamond com/sun/rmi/rmid/ExecPermission.java: - L238 can use diamond sun/rmi/rmic/Main.java: - L186, L194 can use diamond - At L83, the type of environmentClass can be changed to Class. The assignment to environmentClass at L426 would need to be replaced with a call to BatchEnvironment.class.asSubclass() in order to get the types to work out. (The call to isAssignableFrom() should remain since it's checking against the current value of environmentClass, not BatchEnvironment.class.) Then, the Constructor declaration at L498 should change to Constructor and then the cast at L499 can go away. sun/rmi/rmic/RMIGenerator.java: - L686 is now short enough to be joined to the previous line. sun/rmi/server/ActivatableRef.java: - L377 indentation should shift to match with previous line. sun/rmi/transport/ConnectionInputStream.java: - L91-100: Ugh! The addition of generics here makes this really bad. Not your fault; you've added generics in the precise, minimal way. But this code just cries out to be simplified. This is usually out of bounds for warnings changes but since I'm closer to this code I'd say to go ahead with it. Go ahead and replace this with an enhanced for loop and get rid of some intermediate locals: void registerRefs() throws IOException { if (!incomingRefTable.isEmpty()) { for (Map.Entry> entry : incomingRefTable.entrySet()) { DGCClient.registerRefs(entry.getKey(), entry.getValue()); } } } sun/rmi/transport/DGCClient.java: - L285, L606, L611: use diamond - L690: remove redundant parentheses sun/rmi/transport/StreamRemoteCall.java: I think it would be better to put the comment about "fall through" at line 253 or 256 instead of at the top of the method (L201) which is pretty far away. The point here is that exceptionReceivedFromServer() always throws an exception -- well, it should -- and thus this case cannot fall through to the default case. This isn't obvious, so I'd prefer to see a comment somewhere near here instead of at the top of the method. (One might ask, can't the compiler determine that the method always throws an exception, which means the case can't fall through, and thus shut off the fall through warning? Well, the method in question is protected, so a subclass might override the method and not always throw an exception. That would be a bug, but the compiler can't tell that. (Tom Hawtin suggests that it's bad style for a method always to throw an exception, and instead that it should return an exception that the caller is responsible for throwing. This would make the code clearer. (This has come up in prior warnings cleanups; see [1]. (Changing this is usually out of scope for warnings cleanup, though. I'm tempted to ask you to change this, but some tests are looking for exceptionReceivedFromServer in stack traces and it's probably not worth the risk of messing them up. (Yes, I'm using too many nested parentheses.))))) [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-December/008524.html sun/rmi/transport/proxy/RMIMasterSocketFactory.java: - L99 can use diamond - L240, hmm, refactoring to use try-with-resources. Note that the original code leaks the socket if read() throws IOException! Overall using t-w-r is good, and fixes this bug, but it can be improved further. Probably move the "trying with factory" log message outside of the try block at L230, and turn that try block into the try-with-resources, instead of adding a nested t-w-r. The semantics are almost the same, as the close() is performed before any IOException is caught. (This kind of change is usually out of bounds for warnings changes but, as above, since I'm closer to this code I'd say to go ahead with it.) Thanks, s'marks On 2/24/12 2:24 PM, Kurchi Hazra wrote: > Hi, > > Please ignore the previous webrev and see this instead: > http://cr.openjdk.java.net/~khazra/7146763/webrev.03/ > > This has Stuart's suggestion integrated correctly. In addition, I realized that > make/sun/rmi/rmic/Makefile is not yet ready to have the JAVAC_WARNINGS_FATAL > flag turned on, since it implicitly also builds files from sun/tools with more > then 400 > warnings in them. The change in this file has now been removed. > > - Kurchi > > > > On 2/24/2012 11:01 AM, Kurchi Hazra wrote: >> Hi Stuart, >> >> Thanks for the detailed explanation. Here is an updated webrev: >> http://cr.openjdk.java.net/~khazra/7146763/webrev.02/ >> >> >> - Kurchi >> >> On 2/24/2012 12:54 AM, Stuart Marks wrote: >>> On 2/22/12 1:25 PM, Kurchi Hazra wrote: >>>> On 2/22/2012 10:01 AM, R?mi Forax wrote: >>>>> Hi Kurchi, hi all, >>>>> >>>>> in ReliableLog, you can get ride of the @SupressWarnings, >>>>> getLogClassConstructor should return a Constructor and not a Constructor>>>> extends LogFile>, >>>>> the field logClassConstructor should be typed Constructor and >>>>> in openLogFile, the log should be constructed like this >>>>> >>>>> log = (logClassConstructor == null ? >>>>> new LogFile(logName, "rw") : >>>>> (LogFile)logClassConstructor.newInstance(logName, "rw")); >>>>> >>>>> The idea is that a cast on a LogFile is typesafe but not a cast on a >>>>> Constructor. >>>> >>>> If I change the return type to Constructor, I get the following error: >>>> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:122: error: >>>> incompatible types >>>> logClassConstructor = getLogClassConstructor(); >>>> ^ >>>> required: Constructor >>>> found: Constructor >>>> where CAP#1 is a fresh type-variable: >>>> CAP#1 extends Object from capture of ? >>>> And the following warning: >>>> >>>> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:350: warning: >>>> [unchecked] unchecked cast >>>> cl.getConstructor(String.class, String.class); >>>> ^ >>>> required: Constructor >>>> found: Constructor >>>> where CAP#1 is a fresh type-variable: >>>> CAP#1 extends Object from capture of ? >>>> >>>> >>>> Thanks, >>>> Kurchi >>> >>> Hi Kurchi, >>> >>> To implement R?mi's suggestion fully, you would also have to change the type >>> of logClassConstructor to Contructor near line 122, remove the cast of >>> cl.getConstructor() near line 350, and then add the cast to LogFile at the >>> call to newInstance() near line 546. >>> >>> This works to get rid of the warnings and errors, but the declaration of >>> Constructor is somewhat imprecise. The code checks to make sure that the >>> loaded class is a subclass of LogFile (that's what the isAssignableFrom >>> check is doing). Thus the type of the loaded class really should be Class>> extends LogFile>, and correspondingly the logClassConstructor should be >>> Constructor. That's how logClassConstructor is declared >>> now and it would be nice to keep it that way. >>> >>> It turns out that Class.asSubclass() does this conversion without generating >>> an unchecked warning. This internally does an isAssignableFrom() check and >>> casts to the right wildcarded type, so this can simplify the code in >>> getLogClassConstructor() somewhat as well. (Incidentally, asSubClass() has >>> @SuppressWarnings on its implementation.) I've appended some diffs below (to >>> be applied on top of your most recent webrev) to show how this can be done. >>> >>> The behavior is slightly different, as it throws ClassCastException (which >>> is caught by the catch clause below, emitting a log message) instead of >>> silently returning null. This is probably an improvement, since if the user >>> specifies the wrong class in the property name, the exception stack trace >>> should indicate what happened. >>> >>> s'marks >>> >>> >>> >>> >>> diff -r 72d32fd57d89 src/share/classes/sun/rmi/log/ReliableLog.java >>> --- a/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 00:01:53 >>> 2012 -0800 >>> +++ b/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 00:39:02 >>> 2012 -0800 >>> @@ -330,9 +330,7 @@ >>> * property a) can be loaded, b) is a subclass of LogFile, and c) has a >>> * public two-arg constructor (String, String); otherwise returns null. >>> **/ >>> - @SuppressWarnings("unchecked") >>> - private static Constructor >>> - getLogClassConstructor() { >>> + private static Constructor getLogClassConstructor() { >>> >>> String logClassName = AccessController.doPrivileged( >>> new GetPropertyAction("sun.rmi.log.class")); >>> @@ -345,11 +343,9 @@ >>> return ClassLoader.getSystemClassLoader(); >>> } >>> }); >>> - Class cl = loader.loadClass(logClassName); >>> - if (LogFile.class.isAssignableFrom(cl)) { >>> - return (Constructor) >>> - cl.getConstructor(String.class, String.class); >>> - } >>> + Class cl = >>> + loader.loadClass(logClassName).asSubclass(LogFile.class); >>> + return cl.getConstructor(String.class, String.class); >>> } catch (Exception e) { >>> System.err.println("Exception occurred:"); >>> e.printStackTrace(); >>> >>> >> > From kurchi.subhra.hazra at oracle.com Tue Feb 28 23:22:47 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 28 Feb 2012 15:22:47 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F4D5E55.8040109@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> <4F455D47.1080002@oracle.com> <4F475033.4040002@oracle.com> <4F47DE7E.9010107@oracle.com> <4F480E14.8030109@oracle.com> <4F4D5E55.8040109@oracle.com> Message-ID: <4F4D61C7.2010704@oracle.com> Hi Stuart, Thanks for your comments. Regarding the use of diamonds, I remember this issue coming up when i was fixing networking warnings. See : http://mail.openjdk.java.net/pipermail/net-dev/2011-September/003547.html We had stuck to using diamond only when both declaration and assignment were on the same line. - Kurchi On 2/28/2012 3:08 PM, Stuart Marks wrote: > Hi Kurchi, > > I looked at the rest of the files. Pretty good, taking on diamond, > multi-catch, and try-with-resources as well! > > I have several comments. Mostly nitpicks, but a few items worthy of > some discussion, but overall still minor changes, I think. > > > com/sun/rmi/rmid/ExecOptionPermission.java: > > - L234 can use diamond > > > com/sun/rmi/rmid/ExecPermission.java: > > - L238 can use diamond > > > sun/rmi/rmic/Main.java: > > - L186, L194 can use diamond > > - At L83, the type of environmentClass can be changed to Class extends BatchEnvironment>. The assignment to environmentClass at L426 > would need to be replaced with a call to > BatchEnvironment.class.asSubclass() in order to get the types to work > out. (The call to isAssignableFrom() should remain since it's checking > against the current value of environmentClass, not > BatchEnvironment.class.) Then, the Constructor declaration at L498 > should change to Constructor and then the > cast at L499 can go away. > > > sun/rmi/rmic/RMIGenerator.java: > > - L686 is now short enough to be joined to the previous line. > > > sun/rmi/server/ActivatableRef.java: > > - L377 indentation should shift to match with previous line. > > > sun/rmi/transport/ConnectionInputStream.java: > > - L91-100: Ugh! The addition of generics here makes this really bad. > Not your fault; you've added generics in the precise, minimal way. But > this code just cries out to be simplified. This is usually out of > bounds for warnings changes but since I'm closer to this code I'd say > to go ahead with it. Go ahead and replace this with an enhanced for > loop and get rid of some intermediate locals: > > void registerRefs() throws IOException { > if (!incomingRefTable.isEmpty()) { > for (Map.Entry> entry : > incomingRefTable.entrySet()) { > DGCClient.registerRefs(entry.getKey(), entry.getValue()); > } > } > } > > > sun/rmi/transport/DGCClient.java: > > - L285, L606, L611: use diamond > - L690: remove redundant parentheses > > > sun/rmi/transport/StreamRemoteCall.java: > > I think it would be better to put the comment about "fall through" at > line 253 or 256 instead of at the top of the method (L201) which is > pretty far away. The point here is that exceptionReceivedFromServer() > always throws an exception -- well, it should -- and thus this case > cannot fall through to the default case. This isn't obvious, so I'd > prefer to see a comment somewhere near here instead of at the top of > the method. > > (One might ask, can't the compiler determine that the method always > throws an exception, which means the case can't fall through, and thus > shut off the fall through warning? Well, the method in question is > protected, so a subclass might override the method and not always > throw an exception. That would be a bug, but the compiler can't tell > that. (Tom Hawtin suggests that it's bad style for a method always to > throw an exception, and instead that it should return an exception > that the caller is responsible for throwing. This would make the code > clearer. (This has come up in prior warnings cleanups; see [1]. > (Changing this is usually out of scope for warnings cleanup, though. > I'm tempted to ask you to change this, but some tests are looking for > exceptionReceivedFromServer in stack traces and it's probably not > worth the risk of messing them up. (Yes, I'm using too many nested > parentheses.))))) > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-December/008524.html > > > sun/rmi/transport/proxy/RMIMasterSocketFactory.java: > > - L99 can use diamond > > - L240, hmm, refactoring to use try-with-resources. Note that the > original code leaks the socket if read() throws IOException! Overall > using t-w-r is good, and fixes this bug, but it can be improved > further. Probably move the "trying with factory" log message outside > of the try block at L230, and turn that try block into the > try-with-resources, instead of adding a nested t-w-r. The semantics > are almost the same, as the close() is performed before any > IOException is caught. (This kind of change is usually out of bounds > for warnings changes but, as above, since I'm closer to this code I'd > say to go ahead with it.) > > Thanks, > > s'marks > > On 2/24/12 2:24 PM, Kurchi Hazra wrote: >> Hi, >> >> Please ignore the previous webrev and see this instead: >> http://cr.openjdk.java.net/~khazra/7146763/webrev.03/ >> >> This has Stuart's suggestion integrated correctly. In addition, I >> realized that >> make/sun/rmi/rmic/Makefile is not yet ready to have the >> JAVAC_WARNINGS_FATAL >> flag turned on, since it implicitly also builds files from sun/tools >> with more >> then 400 >> warnings in them. The change in this file has now been removed. >> >> - Kurchi >> >> >> >> On 2/24/2012 11:01 AM, Kurchi Hazra wrote: >>> Hi Stuart, >>> >>> Thanks for the detailed explanation. Here is an updated webrev: >>> http://cr.openjdk.java.net/~khazra/7146763/webrev.02/ >>> >>> >>> - Kurchi >>> >>> On 2/24/2012 12:54 AM, Stuart Marks wrote: >>>> On 2/22/12 1:25 PM, Kurchi Hazra wrote: >>>>> On 2/22/2012 10:01 AM, R?mi Forax wrote: >>>>>> Hi Kurchi, hi all, >>>>>> >>>>>> in ReliableLog, you can get ride of the @SupressWarnings, >>>>>> getLogClassConstructor should return a Constructor and not a >>>>>> Constructor>>>>> extends LogFile>, >>>>>> the field logClassConstructor should be typed Constructor and >>>>>> in openLogFile, the log should be constructed like this >>>>>> >>>>>> log = (logClassConstructor == null ? >>>>>> new LogFile(logName, "rw") : >>>>>> (LogFile)logClassConstructor.newInstance(logName, "rw")); >>>>>> >>>>>> The idea is that a cast on a LogFile is typesafe but not a cast on a >>>>>> Constructor. >>>>> >>>>> If I change the return type to Constructor, I get the following >>>>> error: >>>>> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:122: >>>>> error: >>>>> incompatible types >>>>> logClassConstructor = getLogClassConstructor(); >>>>> ^ >>>>> required: Constructor >>>>> found: Constructor >>>>> where CAP#1 is a fresh type-variable: >>>>> CAP#1 extends Object from capture of ? >>>>> And the following warning: >>>>> >>>>> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:350: >>>>> warning: >>>>> [unchecked] unchecked cast >>>>> cl.getConstructor(String.class, String.class); >>>>> ^ >>>>> required: Constructor >>>>> found: Constructor >>>>> where CAP#1 is a fresh type-variable: >>>>> CAP#1 extends Object from capture of ? >>>>> >>>>> >>>>> Thanks, >>>>> Kurchi >>>> >>>> Hi Kurchi, >>>> >>>> To implement R?mi's suggestion fully, you would also have to change >>>> the type >>>> of logClassConstructor to Contructor near line 122, remove the >>>> cast of >>>> cl.getConstructor() near line 350, and then add the cast to LogFile >>>> at the >>>> call to newInstance() near line 546. >>>> >>>> This works to get rid of the warnings and errors, but the >>>> declaration of >>>> Constructor is somewhat imprecise. The code checks to make sure >>>> that the >>>> loaded class is a subclass of LogFile (that's what the >>>> isAssignableFrom >>>> check is doing). Thus the type of the loaded class really should be >>>> Class>>> extends LogFile>, and correspondingly the logClassConstructor >>>> should be >>>> Constructor. That's how logClassConstructor is >>>> declared >>>> now and it would be nice to keep it that way. >>>> >>>> It turns out that Class.asSubclass() does this conversion without >>>> generating >>>> an unchecked warning. This internally does an isAssignableFrom() >>>> check and >>>> casts to the right wildcarded type, so this can simplify the code in >>>> getLogClassConstructor() somewhat as well. (Incidentally, >>>> asSubClass() has >>>> @SuppressWarnings on its implementation.) I've appended some diffs >>>> below (to >>>> be applied on top of your most recent webrev) to show how this can >>>> be done. >>>> >>>> The behavior is slightly different, as it throws ClassCastException >>>> (which >>>> is caught by the catch clause below, emitting a log message) >>>> instead of >>>> silently returning null. This is probably an improvement, since if >>>> the user >>>> specifies the wrong class in the property name, the exception stack >>>> trace >>>> should indicate what happened. >>>> >>>> s'marks >>>> >>>> >>>> >>>> >>>> diff -r 72d32fd57d89 src/share/classes/sun/rmi/log/ReliableLog.java >>>> --- a/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 >>>> 00:01:53 >>>> 2012 -0800 >>>> +++ b/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 >>>> 00:39:02 >>>> 2012 -0800 >>>> @@ -330,9 +330,7 @@ >>>> * property a) can be loaded, b) is a subclass of LogFile, and c) has a >>>> * public two-arg constructor (String, String); otherwise returns null. >>>> **/ >>>> - @SuppressWarnings("unchecked") >>>> - private static Constructor >>>> - getLogClassConstructor() { >>>> + private static Constructor >>>> getLogClassConstructor() { >>>> >>>> String logClassName = AccessController.doPrivileged( >>>> new GetPropertyAction("sun.rmi.log.class")); >>>> @@ -345,11 +343,9 @@ >>>> return ClassLoader.getSystemClassLoader(); >>>> } >>>> }); >>>> - Class cl = loader.loadClass(logClassName); >>>> - if (LogFile.class.isAssignableFrom(cl)) { >>>> - return (Constructor) >>>> - cl.getConstructor(String.class, String.class); >>>> - } >>>> + Class cl = >>>> + loader.loadClass(logClassName).asSubclass(LogFile.class); >>>> + return cl.getConstructor(String.class, String.class); >>>> } catch (Exception e) { >>>> System.err.println("Exception occurred:"); >>>> e.printStackTrace(); >>>> >>>> >>> >> -- -Kurchi From vitalyd at gmail.com Wed Feb 29 00:17:31 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 28 Feb 2012 19:17:31 -0500 Subject: java.util.UUID.fromString performance In-Reply-To: <7CD0614C-5C47-42C3-995F-87748FC41966@oracle.com> References: <7CD0614C-5C47-42C3-995F-87748FC41966@oracle.com> Message-ID: Mike, I can certainly try to do that. Given how trivial the change is and the somewhat obvious observation that Long.parseLong would avoid boxing compared to Long.decode, I was simply pointing out a fairly easy change that could be made in case the maintainers of this class simply haven't looked at optimizing this method a bit. Obviously touching working code shouldn't be taken lightly, but do you see any issues with using Long.parseLong? Thanks Sent from my phone On Feb 28, 2012 1:32 PM, "Mike Duigou" wrote: > The easiest wat to proceed would be for you to submit a webrev patch with > both changes along with your microbenchmark test. Once the change is > incorporated in the jdk8 mainline the sustaining teams can evaluate it for > backporting to jdk 7 and 6. > > Mike > > On Feb 28 2012, at 06:26 , Vitaly Davidovich wrote: > > > Hi all, > > > > I noticed that this method could be made a bit more performant by: > > > > 1) creating a statically initialized Pattern for "-" and then calling > > split() on that. Currently the method calls name.split() which compiles > > the pattern on each invocation. > > > > 2) use Long.parseLong() instead of Long.decode() to extract the bits. > > > > With these changes, the method runs at least 20% faster (some runs were > > significantly faster) on an Intel Westmere server and should be a bit > more > > GC friendly. > > > > Any thoughts? I can send the full code a bit later when I'm in front of > my > > computer. > > > > Thanks > > > > Sent from my phone > > From david.holmes at oracle.com Wed Feb 29 00:29:12 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Feb 2012 10:29:12 +1000 Subject: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method In-Reply-To: <4F4D08DC.4030601@oracle.com> References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com> <62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net> <4E23E5E8.4010507@oracle.com> <4E25DFD7.4090102@oracle.com> <4E268BB7.9090603@oracle.com> <4F4D08DC.4030601@oracle.com> Message-ID: <4F4D7158.30309@oracle.com> Hi Joe, On 29/02/2012 3:03 AM, Joe Darcy wrote: > Belatedly catching up on email, please review the patch below to address > the issues you've raised. I searched for "method" and replaced it with > "executable" as appropriate throughout the javadoc of the class. That substitution seems fine in the patch. Is there a full webrev/blenderrev? David > Thanks, > > -Joe > > --- a/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 > 17:00:28 2012 +0400 > +++ b/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 > 09:01:27 2012 -0800 > @@ -180,7 +180,7 @@ > > /** > * Returns the {@code Class} object representing the class or interface > - * that declares the method represented by this executable object. > + * that declares the executable represented by this object. > */ > public abstract Class getDeclaringClass(); > > @@ -215,18 +215,18 @@ > * Returns an array of {@code Class} objects that represent the formal > * parameter types, in declaration order, of the executable > * represented by this object. Returns an array of length > - * 0 if the underlying method takes no parameters. > + * 0 if the underlying executable takes no parameters. > * > - * @return the parameter types for the method this object > + * @return the parameter types for the executable this object > * represents > */ > public abstract Class[] getParameterTypes(); > > /** > * Returns an array of {@code Type} objects that represent the formal > - * parameter types, in declaration order, of the method represented by > - * this executable object. Returns an array of length 0 if the > - * underlying method takes no parameters. > + * parameter types, in declaration order, of the executable represented by > + * this object. Returns an array of length 0 if the > + * underlying executable takes no parameters. > * > *

If a formal parameter type is a parameterized type, > * the {@code Type} object returned for it must accurately reflect > @@ -236,16 +236,16 @@ > * type, it is created. Otherwise, it is resolved. > * > * @return an array of {@code Type}s that represent the formal > - * parameter types of the underlying method, in declaration order > + * parameter types of the underlying executable, in declaration order > * @throws GenericSignatureFormatError > * if the generic method signature does not conform to the format > * specified in > * The Java™ Virtual Machine Specification > * @throws TypeNotPresentException if any of the parameter > - * types of the underlying method refers to a non-existent type > + * types of the underlying executable refers to a non-existent type > * declaration > * @throws MalformedParameterizedTypeException if any of > - * the underlying method's parameter types refer to a parameterized > + * the underlying executable's parameter types refer to a parameterized > * type that cannot be instantiated for any reason > */ > public Type[] getGenericParameterTypes() { > @@ -277,15 +277,15 @@ > * type, it is created. Otherwise, it is resolved. > * > * @return an array of Types that represent the exception types > - * thrown by the underlying method > + * thrown by the underlying executable > * @throws GenericSignatureFormatError > * if the generic method signature does not conform to the format > * specified in > * The Java™ Virtual Machine Specification > - * @throws TypeNotPresentException if the underlying method's > + * @throws TypeNotPresentException if the underlying executable's > * {@code throws} clause refers to a non-existent type declaration > * @throws MalformedParameterizedTypeException if > - * the underlying method's {@code throws} clause refers to a > + * the underlying executable's {@code throws} clause refers to a > * parameterized type that cannot be instantiated for any reason > */ > public Type[] getGenericExceptionTypes() { > @@ -330,7 +330,7 @@ > * Returns an array of arrays that represent the annotations on > * the formal parameters, in declaration order, of the executable > * represented by this object. (Returns an array of length zero if > - * the underlying method is parameterless. If the executable has > + * the underlying executable is parameterless. If the executable has > * one or more parameters, a nested array of length zero is > * returned for each parameter with no annotations.) The > * annotation objects contained in the returned arrays are > > > On 07/20/2011 01:03 AM, David Holmes wrote: >> Just realized this has come in too late ... >> >> Joe Darcy said the following on 07/20/11 05:49: >>> Agreed; I've posted a BlenderRev corresponding to the current patch at: >>> >>> http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html >> >> Thanks. So now I can more readily see that the doc for Executable >> isn't quite suitable for Constructor in a few places: >> >> getDeclaringClass: >> >> 183 /** >> 184 * Returns the {@code Class} object representing the class or >> interface >> 185 * that declares the method represented by this executable object. >> 186 */ >> >> For Constructor "method" should be "constructor". But I think, looking >> at the terminology elsewhere that the above could be rewritten as: >> >> "Returns the Class object representing the class or interface that >> declares the executable represented by this object." >> >> getParameterTypes: >> >> 219 * represented by this object. Returns an array of length >> 220 * 0 if the underlying method takes no parameters. >> >> method -> executable >> >> getGenericParameterTypes: >> >> 229 * parameter types, in declaration order, of the method represented by >> 230 * this executable object. Returns an array of length 0 if the >> 231 * underlying method takes no parameters. >> >> Again change to " the executable represented by this object". >> And then: underlying method -> underlying executable >> >> 241 * parameter types of the underlying method, in declaration order >> 243 * if the generic method signature does not conform to the format >> 247 * types of the underlying method refers to a non-existent type >> 250 * the underlying method's parameter types refer to a parameterized >> >> method -> executable >> >> In fact do a search for "method" in Executable and most occurrences >> should be changed to "executable". >> >> >> Finally, in getModifiers, why delete the "as an integer. The Modifier >> class should be used to decode the modifiers. " ? >> >> >> BTW I also find the multiple "Specified by:" references to be quite >> strange. There can only be one specification for a method. >> >> David >> ----- >> >>> Thanks, >>> >>> -Joe >>> >>> Mike Duigou wrote: >>>> This looks good to me but I agree with David that it's probably >>>> important to look at the generated javadoc and specdiff output >>>> before finalizing. >>>> >>>> Mike >>>> >>>> On Jul 18 2011, at 00:51 , Joe Darcy wrote: >>>> >>>> >>>>> Peter and David. >>>>> >>>>> Thanks for the careful review; the @throws information still needs >>>>> its own {@inheritDoc}; I've uploaded a webrev with this and other >>>>> corrections: >>>>> >>>>> http://cr.openjdk.java.net/~darcy/7007535.4 >>>>> >>>>> More comments interspersed below. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> Peter Jones wrote: >>>>>> Hi Joe, >>>>>> >>>>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote: >>>>>> >>>>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote: >>>>>>>> Please code review my JDK 8 changes for >>>>>>>> >>>>>>>> 7007535: (reflect) Please generalize Constructor and Method >>>>>>>> http://cr.openjdk.java.net/~darcy/7007535.3 >>>>>>>> >>>>>>>> To summarize the changes, a new superclass is defined to capture >>>>>>>> the common >>>>>>>> functionality of java.lang.reflect.Method and >>>>>>>> java.lang.reflect.Constructor. >>>>>>>> That superclass is named "Executable" along the lines of >>>>>>>> javax.lang.model.ExecutableElement, which models constructors >>>>>>>> and methods in >>>>>>>> the JSR 269 language model. >>>>>>>> >>>>>>>> Both specification and implementation code are shared. To >>>>>>>> preserve the right >>>>>>>> @since behavior, it is common that in Method/Constructor the >>>>>>>> javadoc for a >>>>>>>> method will now look like: >>>>>>>> >>>>>>>> /** >>>>>>>> * {@inheritDoc} >>>>>>>> * @since 1.5 >>>>>>>> */ >>>>>>> Unless they have fixed/changed javadoc (entirely possible) it >>>>>>> used to be that the above would not cause @throws declarations >>>>>>> for unchecked exceptions to be inherited - you have/had to >>>>>>> explicitly repeat them as: >>>>>>> >>>>>>> @throws {@inheritDoc} >>>>>> Yes, that would seem to be needed for some of the inherited >>>>>> getters of generics info, which specify unchecked exception types. >>>>>> >>>>>> >>>>>>>> Since Executable is being created in JDK 8, it would be >>>>>>>> incorrect for >>>>>>>> methods in that class to have an @since of 1.5; adding the >>>>>>>> @since in >>>>>>>> Method/Constructor preserves the right information. >>>>>> In Executable.java, getAnnotation and getDeclaredAnnotations do >>>>>> have "@since 1.5"-- oversight? >>>>>> >>>>> Yes; that was incorrect. >>>>> >>>>>> In Constructor.java and Method.java, getExceptionTypes has "@since >>>>>> 1.5", but that method has existed in those classes since 1.1. >>>>>> >>>>>> >>>>> Fixed. >>>>> >>>>>> In Executable.java: >>>>>> >>>>>> 216 /** >>>>>> 217 * Returns an array of {@code Class} objects that represent the >>>>>> formal >>>>>> 218 * parameter types, in declaration order, of the method >>>>>> 219 * represented by this {@code Method} object. Returns an array >>>>>> of length >>>>>> 220 * 0 if the underlying method takes no parameters. >>>>>> 221 * >>>>>> 222 * @return the parameter types for the method this object >>>>>> 223 * represents >>>>>> >>>>>> At least "{@code Method}" needs to be generalized, and perhaps all >>>>>> occurrences of "method"? >>>>>> >>>>> Corrected. >>>> >>> > From stuart.marks at oracle.com Wed Feb 29 00:32:16 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 28 Feb 2012 16:32:16 -0800 Subject: Code review request: 7146763: Warnings cleanup in the sun.rmi and related packages In-Reply-To: <4F4D61C7.2010704@oracle.com> References: <4F4481A4.40701@oracle.com> <4F448225.60009@oracle.com> <4F44CE8D.3050403@oracle.com> <4F452D87.9050709@univ-mlv.fr> <4F455D47.1080002@oracle.com> <4F475033.4040002@oracle.com> <4F47DE7E.9010107@oracle.com> <4F480E14.8030109@oracle.com> <4F4D5E55.8040109@oracle.com> <4F4D61C7.2010704@oracle.com> Message-ID: <4F4D7210.8080102@oracle.com> Right, I remember this issue. In the email you referenced [1] Max said "I remember we agreed on several rules" which were basically to use diamond if it's an initializer at the point of declaration. I guess it depends on who "we" are. I recall that discussion occurring with the security team (of which Max is a member) so I thought "we" meant the security team. (Perhaps the same approach was applied to networking changes as well.) However, I had also applied changesets outside the security area that used diamond much more extensively. So, unfortunately, different areas of the code are using different conventions. Personally I don't see any problem with using diamond in initializers, assignment statements (separate from the declaration), and return statements. I wrote a blog about this: [2]. For RMI at least, I'd prefer to see diamond used in the places that I recommended. s'marks [1] http://mail.openjdk.java.net/pipermail/net-dev/2011-September/003547.html [2] http://stuartmarks.wordpress.com/2011/04/29/when-should-diamond-be-used/ On 2/28/12 3:22 PM, Kurchi Hazra wrote: > Hi Stuart, > > Thanks for your comments. Regarding the use of diamonds, I remember this issue > coming up when i was > fixing networking warnings. See : > http://mail.openjdk.java.net/pipermail/net-dev/2011-September/003547.html > > We had stuck to using diamond only when both declaration and assignment were on > the same line. > > - Kurchi > > > > On 2/28/2012 3:08 PM, Stuart Marks wrote: >> Hi Kurchi, >> >> I looked at the rest of the files. Pretty good, taking on diamond, >> multi-catch, and try-with-resources as well! >> >> I have several comments. Mostly nitpicks, but a few items worthy of some >> discussion, but overall still minor changes, I think. >> >> >> com/sun/rmi/rmid/ExecOptionPermission.java: >> >> - L234 can use diamond >> >> >> com/sun/rmi/rmid/ExecPermission.java: >> >> - L238 can use diamond >> >> >> sun/rmi/rmic/Main.java: >> >> - L186, L194 can use diamond >> >> - At L83, the type of environmentClass can be changed to Class> BatchEnvironment>. The assignment to environmentClass at L426 would need to >> be replaced with a call to BatchEnvironment.class.asSubclass() in order to >> get the types to work out. (The call to isAssignableFrom() should remain >> since it's checking against the current value of environmentClass, not >> BatchEnvironment.class.) Then, the Constructor declaration at L498 should >> change to Constructor and then the cast at L499 >> can go away. >> >> >> sun/rmi/rmic/RMIGenerator.java: >> >> - L686 is now short enough to be joined to the previous line. >> >> >> sun/rmi/server/ActivatableRef.java: >> >> - L377 indentation should shift to match with previous line. >> >> >> sun/rmi/transport/ConnectionInputStream.java: >> >> - L91-100: Ugh! The addition of generics here makes this really bad. Not your >> fault; you've added generics in the precise, minimal way. But this code just >> cries out to be simplified. This is usually out of bounds for warnings >> changes but since I'm closer to this code I'd say to go ahead with it. Go >> ahead and replace this with an enhanced for loop and get rid of some >> intermediate locals: >> >> void registerRefs() throws IOException { >> if (!incomingRefTable.isEmpty()) { >> for (Map.Entry> entry : >> incomingRefTable.entrySet()) { >> DGCClient.registerRefs(entry.getKey(), entry.getValue()); >> } >> } >> } >> >> >> sun/rmi/transport/DGCClient.java: >> >> - L285, L606, L611: use diamond >> - L690: remove redundant parentheses >> >> >> sun/rmi/transport/StreamRemoteCall.java: >> >> I think it would be better to put the comment about "fall through" at line >> 253 or 256 instead of at the top of the method (L201) which is pretty far >> away. The point here is that exceptionReceivedFromServer() always throws an >> exception -- well, it should -- and thus this case cannot fall through to the >> default case. This isn't obvious, so I'd prefer to see a comment somewhere >> near here instead of at the top of the method. >> >> (One might ask, can't the compiler determine that the method always throws an >> exception, which means the case can't fall through, and thus shut off the >> fall through warning? Well, the method in question is protected, so a >> subclass might override the method and not always throw an exception. That >> would be a bug, but the compiler can't tell that. (Tom Hawtin suggests that >> it's bad style for a method always to throw an exception, and instead that it >> should return an exception that the caller is responsible for throwing. This >> would make the code clearer. (This has come up in prior warnings cleanups; >> see [1]. (Changing this is usually out of scope for warnings cleanup, though. >> I'm tempted to ask you to change this, but some tests are looking for >> exceptionReceivedFromServer in stack traces and it's probably not worth the >> risk of messing them up. (Yes, I'm using too many nested parentheses.))))) >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-December/008524.html >> >> >> sun/rmi/transport/proxy/RMIMasterSocketFactory.java: >> >> - L99 can use diamond >> >> - L240, hmm, refactoring to use try-with-resources. Note that the original >> code leaks the socket if read() throws IOException! Overall using t-w-r is >> good, and fixes this bug, but it can be improved further. Probably move the >> "trying with factory" log message outside of the try block at L230, and turn >> that try block into the try-with-resources, instead of adding a nested t-w-r. >> The semantics are almost the same, as the close() is performed before any >> IOException is caught. (This kind of change is usually out of bounds for >> warnings changes but, as above, since I'm closer to this code I'd say to go >> ahead with it.) >> >> Thanks, >> >> s'marks >> >> On 2/24/12 2:24 PM, Kurchi Hazra wrote: >>> Hi, >>> >>> Please ignore the previous webrev and see this instead: >>> http://cr.openjdk.java.net/~khazra/7146763/webrev.03/ >>> >>> This has Stuart's suggestion integrated correctly. In addition, I realized that >>> make/sun/rmi/rmic/Makefile is not yet ready to have the JAVAC_WARNINGS_FATAL >>> flag turned on, since it implicitly also builds files from sun/tools with more >>> then 400 >>> warnings in them. The change in this file has now been removed. >>> >>> - Kurchi >>> >>> >>> >>> On 2/24/2012 11:01 AM, Kurchi Hazra wrote: >>>> Hi Stuart, >>>> >>>> Thanks for the detailed explanation. Here is an updated webrev: >>>> http://cr.openjdk.java.net/~khazra/7146763/webrev.02/ >>>> >>>> >>>> - Kurchi >>>> >>>> On 2/24/2012 12:54 AM, Stuart Marks wrote: >>>>> On 2/22/12 1:25 PM, Kurchi Hazra wrote: >>>>>> On 2/22/2012 10:01 AM, R?mi Forax wrote: >>>>>>> Hi Kurchi, hi all, >>>>>>> >>>>>>> in ReliableLog, you can get ride of the @SupressWarnings, >>>>>>> getLogClassConstructor should return a Constructor and not a >>>>>>> Constructor>>>>>> extends LogFile>, >>>>>>> the field logClassConstructor should be typed Constructor and >>>>>>> in openLogFile, the log should be constructed like this >>>>>>> >>>>>>> log = (logClassConstructor == null ? >>>>>>> new LogFile(logName, "rw") : >>>>>>> (LogFile)logClassConstructor.newInstance(logName, "rw")); >>>>>>> >>>>>>> The idea is that a cast on a LogFile is typesafe but not a cast on a >>>>>>> Constructor. >>>>>> >>>>>> If I change the return type to Constructor, I get the following error: >>>>>> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:122: error: >>>>>> incompatible types >>>>>> logClassConstructor = getLogClassConstructor(); >>>>>> ^ >>>>>> required: Constructor >>>>>> found: Constructor >>>>>> where CAP#1 is a fresh type-variable: >>>>>> CAP#1 extends Object from capture of ? >>>>>> And the following warning: >>>>>> >>>>>> ../../../../src/share/classes/sun/rmi/log/ReliableLog.java:350: warning: >>>>>> [unchecked] unchecked cast >>>>>> cl.getConstructor(String.class, String.class); >>>>>> ^ >>>>>> required: Constructor >>>>>> found: Constructor >>>>>> where CAP#1 is a fresh type-variable: >>>>>> CAP#1 extends Object from capture of ? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Kurchi >>>>> >>>>> Hi Kurchi, >>>>> >>>>> To implement R?mi's suggestion fully, you would also have to change the type >>>>> of logClassConstructor to Contructor near line 122, remove the cast of >>>>> cl.getConstructor() near line 350, and then add the cast to LogFile at the >>>>> call to newInstance() near line 546. >>>>> >>>>> This works to get rid of the warnings and errors, but the declaration of >>>>> Constructor is somewhat imprecise. The code checks to make sure that the >>>>> loaded class is a subclass of LogFile (that's what the isAssignableFrom >>>>> check is doing). Thus the type of the loaded class really should be Class>>>> extends LogFile>, and correspondingly the logClassConstructor should be >>>>> Constructor. That's how logClassConstructor is declared >>>>> now and it would be nice to keep it that way. >>>>> >>>>> It turns out that Class.asSubclass() does this conversion without generating >>>>> an unchecked warning. This internally does an isAssignableFrom() check and >>>>> casts to the right wildcarded type, so this can simplify the code in >>>>> getLogClassConstructor() somewhat as well. (Incidentally, asSubClass() has >>>>> @SuppressWarnings on its implementation.) I've appended some diffs below (to >>>>> be applied on top of your most recent webrev) to show how this can be done. >>>>> >>>>> The behavior is slightly different, as it throws ClassCastException (which >>>>> is caught by the catch clause below, emitting a log message) instead of >>>>> silently returning null. This is probably an improvement, since if the user >>>>> specifies the wrong class in the property name, the exception stack trace >>>>> should indicate what happened. >>>>> >>>>> s'marks >>>>> >>>>> >>>>> >>>>> >>>>> diff -r 72d32fd57d89 src/share/classes/sun/rmi/log/ReliableLog.java >>>>> --- a/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 00:01:53 >>>>> 2012 -0800 >>>>> +++ b/src/share/classes/sun/rmi/log/ReliableLog.java Fri Feb 24 00:39:02 >>>>> 2012 -0800 >>>>> @@ -330,9 +330,7 @@ >>>>> * property a) can be loaded, b) is a subclass of LogFile, and c) has a >>>>> * public two-arg constructor (String, String); otherwise returns null. >>>>> **/ >>>>> - @SuppressWarnings("unchecked") >>>>> - private static Constructor >>>>> - getLogClassConstructor() { >>>>> + private static Constructor getLogClassConstructor() { >>>>> >>>>> String logClassName = AccessController.doPrivileged( >>>>> new GetPropertyAction("sun.rmi.log.class")); >>>>> @@ -345,11 +343,9 @@ >>>>> return ClassLoader.getSystemClassLoader(); >>>>> } >>>>> }); >>>>> - Class cl = loader.loadClass(logClassName); >>>>> - if (LogFile.class.isAssignableFrom(cl)) { >>>>> - return (Constructor) >>>>> - cl.getConstructor(String.class, String.class); >>>>> - } >>>>> + Class cl = >>>>> + loader.loadClass(logClassName).asSubclass(LogFile.class); >>>>> + return cl.getConstructor(String.class, String.class); >>>>> } catch (Exception e) { >>>>> System.err.println("Exception occurred:"); >>>>> e.printStackTrace(); >>>>> >>>>> >>>> >>> > From david.holmes at oracle.com Wed Feb 29 01:15:56 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Feb 2012 11:15:56 +1000 Subject: RFR 7149320: Move sun.misc.VM.booted() to end of System.initializeSystemClass() In-Reply-To: References: <200CDD79-6284-4E79-AF57-C883721E9F78@oracle.com> <4F4C5D0F.8060900@oracle.com> Message-ID: <4F4D7C4C.6000108@oracle.com> Hi Mike, On 29/02/2012 5:23 AM, Mike Duigou wrote: > > On Feb 27 2012, at 20:50 , David Holmes wrote: > >> Hi Mike, >> >> The problem with changing initialization order is that you can never enumerate all the possible initialization paths. I don't see anything problematic with the move in relation to Thread.currentThread() or ThreadGroup.add(). But the call to setJavaLangAccess requires initialization of SharedSecrets which in turn requires initialization of Unsafe which in turn initializes sun.reflect.Reflection which in turn initializes a bunch of Collection classes - and suddenly we may have a whole swag of classes now being initialized before the VM appears to be booted. > > The class initialization I'm interested in does occur during the SharedSecrets initialization path. Because, in the current implementation, booted() hasn't been called the only way I can determine if the class is being used before boot() is to check if the SharedSecrets have been initialized. This ends up being cumbersome and permanently leaves some checking logic in the execution path for what is a very narrow window. I've looked at where isBooted is currently being used and none of the uses would seem to be sensitive to being called Could Win32ErrorMode.initialize() now be called too late in some case? What about sun.nio.cs.ext.ExtendedCharsets.init()? ... >> If you then throw into the mix the possibility of different system properties affecting initialization actions, or the existence of an agent, then who knows what might actually happen. > > Do you believe that the change is as a result too risky to consider? Are there validations that could/should be done to reduce or eliminate the risk? I think this change may well have unanticipated consequences that might take a long time to surface. If I was confident that regular testing might expose these then I'd say go ahead, but I think these will be obscure changes in very specific contexts that probably are not tested. Given it is only a convenience fix is it worth any risk? You could always add a new field to reflect the end of initializeSystemClass. Or make booted an integer: private static volatile int booted = 0; public static void booted() { booted++; } public static boolean isBooted() { return booted > 0; } public static void fullyBooted() { booted++; } public static boolean isFullyBooted() { return booted > 1; } Cheers, David > >> Cheers, >> David >> ----- >> >> >> On 28/02/2012 1:57 PM, Mike Duigou wrote: >>> Hello all; >>> >>> This issue is a patch for review that I have split out of a larger issue I'll be submitting later. >>> >>> WEBREV @ http://cr.openjdk.java.net/~mduigou/7149320/0/webrev/ >>> >>> sun.misc.VM.booted() is currently called before setJavaLangAccess(). For code which uses the JavaLangAccess shared secrets it's convenient to be able to check whether the secrets are initialized without having to call sun.misc.SharedSecrets.getJavaLangAccess() every time the secrets are used and checking for null. In particular with the static inner class holder idiom it would be desirable to do : >>> >>> static class Holder { >>> final sun.misc.JavaLangAccess ACCESS = sun.misc.SharedSecrets.getJavaLangAccess(); >>> } >>> >>> ... >>> >>> if(sun.misc.VM.isBooted()&& Holder.ACCESS... >>> >>> In my research on this issue I was unable to determine why sun.misc.VM.booted() isn't the currently the last activity in System.initSystemClass(). Neither of the two tasks which currently follow it depend upon booted state in any way that I could determine. I am tempted, thinking about it, to add a comment to System.initSystemClass before the call to sun.misc.VM.booted() asking future maintainers to leave boot() as the last activity or explain why not. >>> >>> I have done JTReg runs on linux x86, linux x64 and Solaris 64 which incorporated this change without any problems encountered. It's rather difficult to write a unit test for this issue as it requires a class that is initialized after java.lang.System but before java.lang.System.initSystemClass() and uses JavaLangAccess. >>> >>> Thanks, >>> >>> Mike > From david.holmes at oracle.com Wed Feb 29 01:17:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Feb 2012 11:17:14 +1000 Subject: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method In-Reply-To: <4F4D7158.30309@oracle.com> References: <4E1E52BA.6070705@oracle.com> <4E1FD4EA.4090800@oracle.com> <62598314-444F-461D-B032-5BCA73EFC9C5@roundroom.net> <4E23E5E8.4010507@oracle.com> <4E25DFD7.4090102@oracle.com> <4E268BB7.9090603@oracle.com> <4F4D08DC.4030601@oracle.com> <4F4D7158.30309@oracle.com> Message-ID: <4F4D7C9A.5070007@oracle.com> On 29/02/2012 10:29 AM, David Holmes wrote: > Hi Joe, > > On 29/02/2012 3:03 AM, Joe Darcy wrote: >> Belatedly catching up on email, please review the patch below to address >> the issues you've raised. I searched for "method" and replaced it with >> "executable" as appropriate throughout the javadoc of the class. > > That substitution seems fine in the patch. Is there a full > webrev/blenderrev? I see it was already pushed, so I just checked the complete file. David > David > >> Thanks, >> >> -Joe >> >> --- a/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 >> 17:00:28 2012 +0400 >> +++ b/src/share/classes/java/lang/reflect/Executable.java Tue Feb 28 >> 09:01:27 2012 -0800 >> @@ -180,7 +180,7 @@ >> >> /** >> * Returns the {@code Class} object representing the class or interface >> - * that declares the method represented by this executable object. >> + * that declares the executable represented by this object. >> */ >> public abstract Class getDeclaringClass(); >> >> @@ -215,18 +215,18 @@ >> * Returns an array of {@code Class} objects that represent the formal >> * parameter types, in declaration order, of the executable >> * represented by this object. Returns an array of length >> - * 0 if the underlying method takes no parameters. >> + * 0 if the underlying executable takes no parameters. >> * >> - * @return the parameter types for the method this object >> + * @return the parameter types for the executable this object >> * represents >> */ >> public abstract Class[] getParameterTypes(); >> >> /** >> * Returns an array of {@code Type} objects that represent the formal >> - * parameter types, in declaration order, of the method represented by >> - * this executable object. Returns an array of length 0 if the >> - * underlying method takes no parameters. >> + * parameter types, in declaration order, of the executable >> represented by >> + * this object. Returns an array of length 0 if the >> + * underlying executable takes no parameters. >> * >> *

If a formal parameter type is a parameterized type, >> * the {@code Type} object returned for it must accurately reflect >> @@ -236,16 +236,16 @@ >> * type, it is created. Otherwise, it is resolved. >> * >> * @return an array of {@code Type}s that represent the formal >> - * parameter types of the underlying method, in declaration order >> + * parameter types of the underlying executable, in declaration order >> * @throws GenericSignatureFormatError >> * if the generic method signature does not conform to the format >> * specified in >> * The Java™ Virtual Machine Specification >> * @throws TypeNotPresentException if any of the parameter >> - * types of the underlying method refers to a non-existent type >> + * types of the underlying executable refers to a non-existent type >> * declaration >> * @throws MalformedParameterizedTypeException if any of >> - * the underlying method's parameter types refer to a parameterized >> + * the underlying executable's parameter types refer to a parameterized >> * type that cannot be instantiated for any reason >> */ >> public Type[] getGenericParameterTypes() { >> @@ -277,15 +277,15 @@ >> * type, it is created. Otherwise, it is resolved. >> * >> * @return an array of Types that represent the exception types >> - * thrown by the underlying method >> + * thrown by the underlying executable >> * @throws GenericSignatureFormatError >> * if the generic method signature does not conform to the format >> * specified in >> * The Java™ Virtual Machine Specification >> - * @throws TypeNotPresentException if the underlying method's >> + * @throws TypeNotPresentException if the underlying executable's >> * {@code throws} clause refers to a non-existent type declaration >> * @throws MalformedParameterizedTypeException if >> - * the underlying method's {@code throws} clause refers to a >> + * the underlying executable's {@code throws} clause refers to a >> * parameterized type that cannot be instantiated for any reason >> */ >> public Type[] getGenericExceptionTypes() { >> @@ -330,7 +330,7 @@ >> * Returns an array of arrays that represent the annotations on >> * the formal parameters, in declaration order, of the executable >> * represented by this object. (Returns an array of length zero if >> - * the underlying method is parameterless. If the executable has >> + * the underlying executable is parameterless. If the executable has >> * one or more parameters, a nested array of length zero is >> * returned for each parameter with no annotations.) The >> * annotation objects contained in the returned arrays are >> >> >> On 07/20/2011 01:03 AM, David Holmes wrote: >>> Just realized this has come in too late ... >>> >>> Joe Darcy said the following on 07/20/11 05:49: >>>> Agreed; I've posted a BlenderRev corresponding to the current patch at: >>>> >>>> http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html >>> >>> Thanks. So now I can more readily see that the doc for Executable >>> isn't quite suitable for Constructor in a few places: >>> >>> getDeclaringClass: >>> >>> 183 /** >>> 184 * Returns the {@code Class} object representing the class or >>> interface >>> 185 * that declares the method represented by this executable object. >>> 186 */ >>> >>> For Constructor "method" should be "constructor". But I think, looking >>> at the terminology elsewhere that the above could be rewritten as: >>> >>> "Returns the Class object representing the class or interface that >>> declares the executable represented by this object." >>> >>> getParameterTypes: >>> >>> 219 * represented by this object. Returns an array of length >>> 220 * 0 if the underlying method takes no parameters. >>> >>> method -> executable >>> >>> getGenericParameterTypes: >>> >>> 229 * parameter types, in declaration order, of the method >>> represented by >>> 230 * this executable object. Returns an array of length 0 if the >>> 231 * underlying method takes no parameters. >>> >>> Again change to " the executable represented by this object". >>> And then: underlying method -> underlying executable >>> >>> 241 * parameter types of the underlying method, in declaration order >>> 243 * if the generic method signature does not conform to the format >>> 247 * types of the underlying method refers to a non-existent type >>> 250 * the underlying method's parameter types refer to a parameterized >>> >>> method -> executable >>> >>> In fact do a search for "method" in Executable and most occurrences >>> should be changed to "executable". >>> >>> >>> Finally, in getModifiers, why delete the "as an integer. The Modifier >>> class should be used to decode the modifiers. " ? >>> >>> >>> BTW I also find the multiple "Specified by:" references to be quite >>> strange. There can only be one specification for a method. >>> >>> David >>> ----- >>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> Mike Duigou wrote: >>>>> This looks good to me but I agree with David that it's probably >>>>> important to look at the generated javadoc and specdiff output >>>>> before finalizing. >>>>> >>>>> Mike >>>>> >>>>> On Jul 18 2011, at 00:51 , Joe Darcy wrote: >>>>> >>>>> >>>>>> Peter and David. >>>>>> >>>>>> Thanks for the careful review; the @throws information still needs >>>>>> its own {@inheritDoc}; I've uploaded a webrev with this and other >>>>>> corrections: >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/7007535.4 >>>>>> >>>>>> More comments interspersed below. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>> Peter Jones wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> On Jul 15, 2011, at 1:49 AM, David Holmes wrote: >>>>>>> >>>>>>>> On 14/07/2011 12:21 PM, joe.darcy at oracle.com wrote: >>>>>>>>> Please code review my JDK 8 changes for >>>>>>>>> >>>>>>>>> 7007535: (reflect) Please generalize Constructor and Method >>>>>>>>> http://cr.openjdk.java.net/~darcy/7007535.3 >>>>>>>>> >>>>>>>>> To summarize the changes, a new superclass is defined to capture >>>>>>>>> the common >>>>>>>>> functionality of java.lang.reflect.Method and >>>>>>>>> java.lang.reflect.Constructor. >>>>>>>>> That superclass is named "Executable" along the lines of >>>>>>>>> javax.lang.model.ExecutableElement, which models constructors >>>>>>>>> and methods in >>>>>>>>> the JSR 269 language model. >>>>>>>>> >>>>>>>>> Both specification and implementation code are shared. To >>>>>>>>> preserve the right >>>>>>>>> @since behavior, it is common that in Method/Constructor the >>>>>>>>> javadoc for a >>>>>>>>> method will now look like: >>>>>>>>> >>>>>>>>> /** >>>>>>>>> * {@inheritDoc} >>>>>>>>> * @since 1.5 >>>>>>>>> */ >>>>>>>> Unless they have fixed/changed javadoc (entirely possible) it >>>>>>>> used to be that the above would not cause @throws declarations >>>>>>>> for unchecked exceptions to be inherited - you have/had to >>>>>>>> explicitly repeat them as: >>>>>>>> >>>>>>>> @throws {@inheritDoc} >>>>>>> Yes, that would seem to be needed for some of the inherited >>>>>>> getters of generics info, which specify unchecked exception types. >>>>>>> >>>>>>> >>>>>>>>> Since Executable is being created in JDK 8, it would be >>>>>>>>> incorrect for >>>>>>>>> methods in that class to have an @since of 1.5; adding the >>>>>>>>> @since in >>>>>>>>> Method/Constructor preserves the right information. >>>>>>> In Executable.java, getAnnotation and getDeclaredAnnotations do >>>>>>> have "@since 1.5"-- oversight? >>>>>>> >>>>>> Yes; that was incorrect. >>>>>> >>>>>>> In Constructor.java and Method.java, getExceptionTypes has "@since >>>>>>> 1.5", but that method has existed in those classes since 1.1. >>>>>>> >>>>>>> >>>>>> Fixed. >>>>>> >>>>>>> In Executable.java: >>>>>>> >>>>>>> 216 /** >>>>>>> 217 * Returns an array of {@code Class} objects that represent the >>>>>>> formal >>>>>>> 218 * parameter types, in declaration order, of the method >>>>>>> 219 * represented by this {@code Method} object. Returns an array >>>>>>> of length >>>>>>> 220 * 0 if the underlying method takes no parameters. >>>>>>> 221 * >>>>>>> 222 * @return the parameter types for the method this object >>>>>>> 223 * represents >>>>>>> >>>>>>> At least "{@code Method}" needs to be generalized, and perhaps all >>>>>>> occurrences of "method"? >>>>>>> >>>>>> Corrected. >>>>> >>>> >> From lana.steuck at oracle.com Wed Feb 29 05:13:40 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:40 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20120229051340.B1D6147701@hg.openjdk.java.net> Changeset: 97bb465be99d Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/97bb465be99d Added tag jdk8-b27 for changeset 1533dfab9903 ! .hgtags Changeset: 9760a2114f51 Author: asaha Date: 2012-02-14 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9760a2114f51 Merge Changeset: d47bf204f34d Author: asaha Date: 2012-02-17 14:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d47bf204f34d Merge Changeset: 6e2541d60f4e Author: lana Date: 2012-02-24 18:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6e2541d60f4e Merge Changeset: d74f01115fb8 Author: lana Date: 2012-02-28 17:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d74f01115fb8 Merge From lana.steuck at oracle.com Wed Feb 29 05:13:40 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:40 +0000 Subject: hg: jdk8/tl/corba: 5 new changesets Message-ID: <20120229051347.DB93E47702@hg.openjdk.java.net> Changeset: 7bf4278af030 Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7bf4278af030 Added tag jdk8-b27 for changeset 4fffe75e4edd ! .hgtags Changeset: 66c7161ee588 Author: coffeys Date: 2011-11-17 10:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/66c7161ee588 7110704: Issues with some method in corba Reviewed-by: mbankal ! src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyImpl.java ! src/share/classes/com/sun/org/omg/SendingContext/_CodeBaseImplBase.java Changeset: c4afff3939d8 Author: asaha Date: 2012-02-14 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/c4afff3939d8 Merge Changeset: 695408e22b29 Author: asaha Date: 2012-02-17 14:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/695408e22b29 Merge Changeset: 2082eb35d49a Author: lana Date: 2012-02-24 18:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2082eb35d49a Merge From lana.steuck at oracle.com Wed Feb 29 05:13:49 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:49 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20120229051349.2F80247703@hg.openjdk.java.net> Changeset: 38cc4c09b847 Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/38cc4c09b847 Added tag jdk8-b27 for changeset 80c47eb83d24 ! .hgtags Changeset: 6fc515ab48c3 Author: asaha Date: 2012-02-14 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6fc515ab48c3 Merge Changeset: a8e76ac83b62 Author: asaha Date: 2012-02-17 14:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a8e76ac83b62 Merge Changeset: f3244c1f0486 Author: lana Date: 2012-02-24 18:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f3244c1f0486 Merge From lana.steuck at oracle.com Wed Feb 29 05:13:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:51 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20120229051351.93C1947704@hg.openjdk.java.net> Changeset: 6a2e8a833460 Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6a2e8a833460 Added tag jdk8-b27 for changeset 38c037af4127 ! .hgtags Changeset: 4289a81ba085 Author: asaha Date: 2012-02-14 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/4289a81ba085 Merge Changeset: 456621c5d797 Author: asaha Date: 2012-02-17 14:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/456621c5d797 Merge Changeset: c88e83be4b1a Author: lana Date: 2012-02-23 00:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c88e83be4b1a Merge Changeset: 88b85470e72c Author: lana Date: 2012-02-24 18:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88b85470e72c Merge From lana.steuck at oracle.com Wed Feb 29 05:13:44 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:44 +0000 Subject: hg: jdk8/tl/hotspot: Added tag jdk8-b27 for changeset 3b24e7e01d20 Message-ID: <20120229051351.D38E547705@hg.openjdk.java.net> Changeset: 0ed0960af27d Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0ed0960af27d Added tag jdk8-b27 for changeset 3b24e7e01d20 ! .hgtags From lana.steuck at oracle.com Wed Feb 29 05:13:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:56 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20120229051412.1140847706@hg.openjdk.java.net> Changeset: 8503479162bd Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8503479162bd Added tag jdk8-b27 for changeset be456f9c64e8 ! .hgtags Changeset: 3b168225dfc0 Author: asaha Date: 2012-02-14 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b168225dfc0 Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: d903497bf389 Author: asaha Date: 2012-02-17 14:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d903497bf389 Merge Changeset: a696a8610b2a Author: lana Date: 2012-02-23 07:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a696a8610b2a Merge Changeset: 5bed623b0c77 Author: lana Date: 2012-02-24 18:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5bed623b0c77 Merge Changeset: 3d3350aea968 Author: lana Date: 2012-02-28 18:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d3350aea968 Merge From lana.steuck at oracle.com Wed Feb 29 05:14:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:14:12 +0000 Subject: hg: jdk8/tl/jdk: 18 new changesets Message-ID: <20120229051711.E42E047707@hg.openjdk.java.net> Changeset: 7d683ab46571 Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d683ab46571 Added tag jdk8-b27 for changeset c68342532e2e ! .hgtags Changeset: 2152ac3e4575 Author: dl Date: 2011-10-12 16:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2152ac3e4575 7082299: AtomicReferenceArray should ensure that array is Object[] Reviewed-by: chegar, dholmes, alanb ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java Changeset: 23c3d1a0e150 Author: amenkov Date: 2011-10-26 14:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23c3d1a0e150 7088367: JavaSound security issue (12865443) Reviewed-by: denis ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java + test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java Changeset: 3ee041967af6 Author: smarks Date: 2011-11-11 15:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ee041967af6 7110700: Enhance exception throwing mechanism in ObjectStreamClass Reviewed-by: dmeetry, hawtin ! src/share/classes/java/io/ObjectStreamClass.java ! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java Changeset: 18335c98ab8b Author: smarks Date: 2011-11-17 15:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18335c98ab8b 7112267: clean up fix for 7110700 Reviewed-by: dmeetry ! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java Changeset: 4b98d2682c31 Author: okutsu Date: 2011-12-14 11:23 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b98d2682c31 6351654: Problem with java/classes_util_i18n Reviewed-by: hawtin, coffeys ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/awt/AppContext.java + src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/classes/sun/misc/SharedSecrets.java Changeset: 5d7e49a3a2f9 Author: bagiras Date: 2011-12-14 14:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d7e49a3a2f9 7112642: Incorrect checking for graphics rendering object Reviewed-by: art, bae ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/pipe/BufferedContext.java ! src/windows/classes/sun/java2d/d3d/D3DRenderer.java ! src/windows/classes/sun/java2d/windows/GDIRenderer.java ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp Changeset: a7cb0afadbee Author: sherman Date: 2011-12-15 14:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7cb0afadbee 7118283: Better input parameter checking in zip file processing Summary: Fixed off-by-one bug in zip_util.c Reviewed-by: alanb ! src/share/native/java/util/zip/zip_util.c Changeset: d544965b59fe Author: bagiras Date: 2011-12-28 14:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d544965b59fe 7121482: some sun/java2d and sun/awt tests failed with InvalidPipeException since 1.7.0_03b02, 6u31b02 Reviewed-by: art, bae ! src/share/classes/sun/java2d/SunGraphics2D.java Changeset: 5e6f3c8646cf Author: xuelei Date: 2012-01-09 20:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e6f3c8646cf 7123519: problems with certification path Summary: Also including the contribution from Dennis Gu Reviewed-by: mullan, weijun ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java + src/share/classes/sun/security/provider/certpath/UntrustedChecker.java + src/share/classes/sun/security/util/UntrustedCertificates.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/validator/ValidatorException.java + test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java + test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java + test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ComodoHacker.java Changeset: d9897e95323c Author: chegar Date: 2012-01-18 15:35 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d9897e95323c 7126960: Add property to limit number of request headers to the HTTP Server Reviewed-by: michaelm ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerConfig.java Changeset: 7699f0a9c6d7 Author: asaha Date: 2012-02-20 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7699f0a9c6d7 Merge ! make/java/java/FILES_java.gmk ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerConfig.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/validator/SimpleValidator.java Changeset: f525c1e9e12c Author: lana Date: 2012-02-23 00:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f525c1e9e12c Merge Changeset: fcdd5a4bae0e Author: lana Date: 2012-02-23 07:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fcdd5a4bae0e Merge Changeset: ca2218135bac Author: asaha Date: 2012-02-24 17:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca2218135bac 7148758: Resolve merge issue which caused testcase failure Reviewed-by: alanb, chegar ! src/share/classes/sun/net/httpserver/ServerConfig.java Changeset: 39dcb3264fb3 Author: lana Date: 2012-02-24 17:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39dcb3264fb3 Merge Changeset: 1e1d41daaded Author: lana Date: 2012-02-24 18:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e1d41daaded Merge Changeset: 61c36875de46 Author: lana Date: 2012-02-28 18:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61c36875de46 Merge From Alan.Bateman at oracle.com Wed Feb 29 14:41:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Feb 2012 14:41:59 +0000 Subject: RFR 7149320: Move sun.misc.VM.booted() to end of System.initializeSystemClass() In-Reply-To: <200CDD79-6284-4E79-AF57-C883721E9F78@oracle.com> References: <200CDD79-6284-4E79-AF57-C883721E9F78@oracle.com> Message-ID: <4F4E3937.4050306@oracle.com> On 28/02/2012 03:57, Mike Duigou wrote: > Hello all; > > This issue is a patch for review that I have split out of a larger issue I'll be submitting later. > > WEBREV @ http://cr.openjdk.java.net/~mduigou/7149320/0/webrev/ > > sun.misc.VM.booted() is currently called before setJavaLangAccess(). For code which uses the JavaLangAccess shared secrets it's convenient to be able to check whether the secrets are initialized without having to call sun.misc.SharedSecrets.getJavaLangAccess() every time the secrets are used and checking for null. In particular with the static inner class holder idiom it would be desirable to do : > > static class Holder { > final sun.misc.JavaLangAccess ACCESS = sun.misc.SharedSecrets.getJavaLangAccess(); > } > > ... > > if(sun.misc.VM.isBooted()&& Holder.ACCESS... > > In my research on this issue I was unable to determine why sun.misc.VM.booted() isn't the currently the last activity in System.initSystemClass(). Neither of the two tasks which currently follow it depend upon booted state in any way that I could determine. I am tempted, thinking about it, to add a comment to System.initSystemClass before the call to sun.misc.VM.booted() asking future maintainers to leave boot() as the last activity or explain why not. > > I have done JTReg runs on linux x86, linux x64 and Solaris 64 which incorporated this change without any problems encountered. It's rather difficult to write a unit test for this issue as it requires a class that is initialized after java.lang.System but before java.lang.System.initSystemClass() and uses JavaLangAccess. > > Thanks, > > Mike We do need to take great care in System.initSystemClass. I think the safest thing would be to just move setJavaLangAccess to before the call to VM.booted(). At one point the access to java.lang was setup immediately after the system properties were initialized so we've been there before. -Alan From Alan.Bateman at ORACLE.COM Wed Feb 29 15:24:38 2012 From: Alan.Bateman at ORACLE.COM (Alan Bateman) Date: Wed, 29 Feb 2012 15:24:38 +0000 Subject: Please review fix for: 7148499 In-Reply-To: <4F4E426F.7090504@oracle.COM> References: <4F4E426F.7090504@oracle.COM> Message-ID: <4F4E4336.7050507@oracle.com> On 29/02/2012 15:21, Kumar Srinivasan wrote: > Hi, > > Please review fix for launcher tests, the JVM requires a higher > stack size for 64bit systems, this fixes increases the stack size > and removes the test from the problem list. > > fyi, > The stack size is specified here so that the launcher flag under > test, parses and scales these options for human readability. > > http://cr.openjdk.java.net/~ksrini/7148499/webrev.0/ > > Thanks > Kumar > Looks fine to me. I assume this test will start failing in 7u too once the HotSpot changes to increase the stack size get there. -Alan From kumar.x.srinivasan at oracle.com Wed Feb 29 15:21:19 2012 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 29 Feb 2012 07:21:19 -0800 Subject: Please review fix for: 7148499 Message-ID: <4F4E426F.7090504@oracle.COM> Hi, Please review fix for launcher tests, the JVM requires a higher stack size for 64bit systems, this fixes increases the stack size and removes the test from the problem list. fyi, The stack size is specified here so that the launcher flag under test, parses and scales these options for human readability. http://cr.openjdk.java.net/~ksrini/7148499/webrev.0/ Thanks Kumar From sean.coffey at oracle.com Wed Feb 29 16:19:35 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 29 Feb 2012 16:19:35 +0000 Subject: Please review fix for: 7148499 In-Reply-To: <4F4E4F5E.7030306@oracle.COM> References: <4F4E426F.7090504@oracle.COM> <4F4E4336.7050507@oracle.com> <4F4E4F5E.7030306@oracle.COM> Message-ID: <4F4E5017.7000402@oracle.com> Can do Kumar. Should get these in before the week is out. regards, Sean. On 29/02/12 16:16, Kumar Srinivasan wrote: > >>> Hi, >>> >>> Please review fix for launcher tests, the JVM requires a higher >>> stack size for 64bit systems, this fixes increases the stack size >>> and removes the test from the problem list. >>> >>> fyi, >>> The stack size is specified here so that the launcher flag under >>> test, parses and scales these options for human readability. >>> >>> http://cr.openjdk.java.net/~ksrini/7148499/webrev.0/ >>> >>> Thanks >>> Kumar >>> >> Looks fine to me. I assume this test will start failing in 7u too >> once the HotSpot changes to increase the stack size get there. > > Its already failing in 7u!, I am hoping Sean can push this as he > is planning on pushing an unrelated fix on the launcher side for 7u. > > Kumar > >> >> -Alan > From kumar.x.srinivasan at oracle.com Wed Feb 29 16:21:53 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 29 Feb 2012 16:21:53 +0000 Subject: hg: jdk8/tl/jdk: 7148499: Stack size in tools/launcher/Settings.java needs to be increased Message-ID: <20120229162215.EAD964771C@hg.openjdk.java.net> Changeset: bd43a6f59c9b Author: ksrini Date: 2012-02-29 08:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd43a6f59c9b 7148499: Stack size in tools/launcher/Settings.java needs to be increased Reviewed-by: alanb ! test/ProblemList.txt ! test/tools/launcher/Settings.java From kumar.x.srinivasan at ORACLE.COM Wed Feb 29 16:16:30 2012 From: kumar.x.srinivasan at ORACLE.COM (Kumar Srinivasan) Date: Wed, 29 Feb 2012 08:16:30 -0800 Subject: Please review fix for: 7148499 In-Reply-To: <4F4E4336.7050507@oracle.com> References: <4F4E426F.7090504@oracle.COM> <4F4E4336.7050507@oracle.com> Message-ID: <4F4E4F5E.7030306@oracle.COM> >> Hi, >> >> Please review fix for launcher tests, the JVM requires a higher >> stack size for 64bit systems, this fixes increases the stack size >> and removes the test from the problem list. >> >> fyi, >> The stack size is specified here so that the launcher flag under >> test, parses and scales these options for human readability. >> >> http://cr.openjdk.java.net/~ksrini/7148499/webrev.0/ >> >> Thanks >> Kumar >> > Looks fine to me. I assume this test will start failing in 7u too once > the HotSpot changes to increase the stack size get there. Its already failing in 7u!, I am hoping Sean can push this as he is planning on pushing an unrelated fix on the launcher side for 7u. Kumar > > -Alan From david.holmes at oracle.com Wed Feb 29 21:02:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Mar 2012 07:02:44 +1000 Subject: RFR 7149320: Move sun.misc.VM.booted() to end of System.initializeSystemClass() In-Reply-To: <4F4D7C4C.6000108@oracle.com> References: <200CDD79-6284-4E79-AF57-C883721E9F78@oracle.com> <4F4C5D0F.8060900@oracle.com> <4F4D7C4C.6000108@oracle.com> Message-ID: <4F4E9274.5010505@oracle.com> Okay - Alan has pointed out that fairly recently (6888546) setJavaLangAccess and booted() were in the opposite order to today. Based on that I now think it is extremely low risk to change the order as suggested. Thanks, David On 29/02/2012 11:15 AM, David Holmes wrote: > Hi Mike, > > On 29/02/2012 5:23 AM, Mike Duigou wrote: >> >> On Feb 27 2012, at 20:50 , David Holmes wrote: >> >>> Hi Mike, >>> >>> The problem with changing initialization order is that you can never >>> enumerate all the possible initialization paths. I don't see anything >>> problematic with the move in relation to Thread.currentThread() or >>> ThreadGroup.add(). But the call to setJavaLangAccess requires >>> initialization of SharedSecrets which in turn requires initialization >>> of Unsafe which in turn initializes sun.reflect.Reflection which in >>> turn initializes a bunch of Collection classes - and suddenly we may >>> have a whole swag of classes now being initialized before the VM >>> appears to be booted. >> >> The class initialization I'm interested in does occur during the >> SharedSecrets initialization path. Because, in the current >> implementation, booted() hasn't been called the only way I can >> determine if the class is being used before boot() is to check if the >> SharedSecrets have been initialized. This ends up being cumbersome and >> permanently leaves some checking logic in the execution path for what >> is a very narrow window. I've looked at where isBooted is currently >> being used and none of the uses would seem to be sensitive to being >> called > > Could Win32ErrorMode.initialize() now be called too late in some case? > What about sun.nio.cs.ext.ExtendedCharsets.init()? > ... > >>> If you then throw into the mix the possibility of different system >>> properties affecting initialization actions, or the existence of an >>> agent, then who knows what might actually happen. >> >> Do you believe that the change is as a result too risky to consider? >> Are there validations that could/should be done to reduce or eliminate >> the risk? > > I think this change may well have unanticipated consequences that might > take a long time to surface. If I was confident that regular testing > might expose these then I'd say go ahead, but I think these will be > obscure changes in very specific contexts that probably are not tested. > Given it is only a convenience fix is it worth any risk? You could > always add a new field to reflect the end of initializeSystemClass. Or > make booted an integer: > > private static volatile int booted = 0; > public static void booted() { > booted++; > } > public static boolean isBooted() { > return booted > 0; > } > public static void fullyBooted() { > booted++; > } > public static boolean isFullyBooted() { > return booted > 1; > } > > Cheers, > David > > >> >>> Cheers, >>> David >>> ----- >>> >>> >>> On 28/02/2012 1:57 PM, Mike Duigou wrote: >>>> Hello all; >>>> >>>> This issue is a patch for review that I have split out of a larger >>>> issue I'll be submitting later. >>>> >>>> WEBREV @ http://cr.openjdk.java.net/~mduigou/7149320/0/webrev/ >>>> >>>> sun.misc.VM.booted() is currently called before setJavaLangAccess(). >>>> For code which uses the JavaLangAccess shared secrets it's >>>> convenient to be able to check whether the secrets are initialized >>>> without having to call sun.misc.SharedSecrets.getJavaLangAccess() >>>> every time the secrets are used and checking for null. In particular >>>> with the static inner class holder idiom it would be desirable to do : >>>> >>>> static class Holder { >>>> final sun.misc.JavaLangAccess ACCESS = >>>> sun.misc.SharedSecrets.getJavaLangAccess(); >>>> } >>>> >>>> ... >>>> >>>> if(sun.misc.VM.isBooted()&& Holder.ACCESS... >>>> >>>> In my research on this issue I was unable to determine why >>>> sun.misc.VM.booted() isn't the currently the last activity in >>>> System.initSystemClass(). Neither of the two tasks which currently >>>> follow it depend upon booted state in any way that I could >>>> determine. I am tempted, thinking about it, to add a comment to >>>> System.initSystemClass before the call to sun.misc.VM.booted() >>>> asking future maintainers to leave boot() as the last activity or >>>> explain why not. >>>> >>>> I have done JTReg runs on linux x86, linux x64 and Solaris 64 which >>>> incorporated this change without any problems encountered. It's >>>> rather difficult to write a unit test for this issue as it requires >>>> a class that is initialized after java.lang.System but before >>>> java.lang.System.initSystemClass() and uses JavaLangAccess. >>>> >>>> Thanks, >>>> >>>> Mike >> From mark.reinhold at oracle.com Wed Feb 29 22:03:55 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 29 Feb 2012 14:03:55 -0800 (PST) Subject: JEP 149: Reduce Core-Library Memory Usage Message-ID: <20120229220355.3122A7FC@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/149 - Mark From mark.reinhold at oracle.com Wed Feb 29 22:47:50 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 29 Feb 2012 14:47:50 -0800 (PST) Subject: JEP 150: JSR 310: Date and Time API Message-ID: <20120229224750.401B57FC@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/150 - Mark From dmitriy.samersoff at oracle.com Mon Feb 27 11:22:49 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Mon, 27 Feb 2012 11:22:49 -0000 Subject: hg: jdk8/tl/jdk: 7110104: It should be possible to stop and start JMX Agent at runtime Message-ID: <20120227112243.C879E476CF@hg.openjdk.java.net> Changeset: 1e737abbff6f Author: dsamersoff Date: 2012-02-27 15:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e737abbff6f 7110104: It should be possible to stop and start JMX Agent at runtime Summary: Added a capability to start and stop JMX Agent by jcmd Reviewed-by: acorn, mchung ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/AgentConfigurationError.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/resources/agent.properties ! test/sun/management/AgentCheckTest.java + test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java + test/sun/management/jmxremote/startstop/JMXStartStopTest.java + test/sun/management/jmxremote/startstop/JMXStartStopTest.sh + test/sun/management/jmxremote/startstop/REMOTE_TESTING.txt + test/sun/management/jmxremote/startstop/management_cl.properties + test/sun/management/jmxremote/startstop/management_jcmd.properties From dmitriy.samersoff at oracle.com Tue Feb 28 13:04:44 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Tue, 28 Feb 2012 13:04:44 -0000 Subject: hg: jdk8/tl/jdk: 7149181: sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms Message-ID: <20120228130438.7119F476E2@hg.openjdk.java.net> Changeset: c0a5140c641c Author: dsamersoff Date: 2012-02-28 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0a5140c641c 7149181: sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms Summary: Disable test until JDK and hotspot changes meet each other. Reviewed-by: alanb, acorn ! test/ProblemList.txt