From nicholas+openjdk at nicholaswilliams.net Sun Sep 1 08:16:40 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Sun, 1 Sep 2013 03:16:40 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 Message-ID: I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. *Summary of Changes* Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! *The Code Changes* I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. Thanks! Nick From Alan.Bateman at oracle.com Sun Sep 1 09:25:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 01 Sep 2013 10:25:47 +0100 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: References: Message-ID: <5223081B.6030005@oracle.com> On 01/09/2013 09:16, Nick Williams wrote: > : > > I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. > You may need to check your https server as it doesn't look like it's possible to establish a SSL connection ("no common encryption algorithms" is one of the errors I see). Just to set expectations, you are proposing changes in an area that is very security sensitive. As your patches are not currently accessible then I can't say whether you have taken this into account or not. I bring it up because it will have an influence on what we do here. Your mail also mentions moving sun.reflect.CallerSensitive to java.lang but as I recall, this was an explicit non-goal of JEP 176. So I would suggest be prepared for changes to the proposal, also the potential to take time to get agreement on any new APIs. My comments are not meant in any way to discourage you, rather just to highlight that this is a sensitive area. -Alan From jhuxhorn at googlemail.com Sun Sep 1 15:40:48 2013 From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=) Date: Sun, 1 Sep 2013 17:40:48 +0200 Subject: =?UTF-8?Q?Re=3A_=5BPATCH=5D_4851444=3A_Exposing_sun.reflect.Reflection=23getCallerClass_as_a_public_API_in_Java_8?= In-Reply-To: References: Message-ID: This looks pretty awesome! There are just two small things I'd suggest: Rename StackTraceFrame[] getCurrentStackTrace() to StackTraceFrame[] getStackFrames() (I'd prefer this one?) or StackTraceFrame[] getStackTraceFrames() (?while this one is probably more accurate.) or StackTraceFrame[] getCurrentStackFrames() or StackTraceFrame[] getCurrentStackTraceFrames() Rename StackTraceFrame[] getStackTrace(Throwable throwable) to StackTraceFrame[] getStackFrames(Throwable throwable)?(I'd prefer this one?) or StackTraceFrame[] getStackTraceFrames(Throwable throwable)??(?while this one is probably more accurate.) The rationale for this is that previous get[..]StackTrace methods always returned StackTraceElement[] while get[..]StackFrames methods would then always return a StackTraceFrame[]. So essentially I'd like to establish the notion of either StackFrames or StackTraceFrames. I did a quick visual review and I didn't find anything horrific or questionable - which obviously wasn't a security audit, just a sanity check. And, yes, https is broken. I got the patches by using http instead. Cheer, J?rn. On 1. September 2013 at 10:17:51, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote: I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. *Summary of Changes* Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! *The Code Changes* I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. Thanks! Nick From nicholas+openjdk at nicholaswilliams.net Sun Sep 1 15:50:13 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Sun, 1 Sep 2013 10:50:13 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: References: Message-ID: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> Interesting. I can access HTTPS in all of my browsers. OT, to help my figure out what's up with my HTTPS, what browsers and versions are y'all using, J?rn and Alan? N On Sep 1, 2013, at 10:40 AM, J?rn Huxhorn wrote: > This looks pretty awesome! > > There are just two small things I'd suggest: > > Rename > StackTraceFrame[] getCurrentStackTrace() > to > StackTraceFrame[] getStackFrames() (I'd prefer this one?) > or > StackTraceFrame[] getStackTraceFrames() (?while this one is probably more accurate.) > or > StackTraceFrame[] getCurrentStackFrames() > or > StackTraceFrame[] getCurrentStackTraceFrames() > > Rename > StackTraceFrame[] getStackTrace(Throwable throwable) > to > StackTraceFrame[] getStackFrames(Throwable throwable) (I'd prefer this one?) > or > StackTraceFrame[] getStackTraceFrames(Throwable throwable) (?while this one is probably more accurate.) > > > The rationale for this is that previous get[..]StackTrace methods always returned StackTraceElement[] while get[..]StackFrames methods would then always return a StackTraceFrame[]. So essentially I'd like to establish the notion of either StackFrames or StackTraceFrames. > > I did a quick visual review and I didn't find anything horrific or questionable - which obviously wasn't a security audit, just a sanity check. > > And, yes, https is broken. I got the patches by using http instead. > > Cheer, > J?rn. > > On 1. September 2013 at 10:17:51, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote: > I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). > > I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. > > *Summary of Changes* > Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: > > Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. > > Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. > > StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. > > StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. > > StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. > > StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. > > As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. > > I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. > > However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). > > Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. > > I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! > > *The Code Changes* > I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): > > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch > > I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. > > Thanks! > > Nick From nicholas+openjdk at nicholaswilliams.net Sun Sep 1 15:58:43 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Sun, 1 Sep 2013 10:58:43 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <5223081B.6030005@oracle.com> References: <5223081B.6030005@oracle.com> Message-ID: As J?rn pointed out, you can also use HTTP. Could you tell me which browser/version you're using? I'd love to figure out what's up with my HTTPS. I can access it in all my browsers. I understand your point about making CallerSensitive public being a non-goal of JEP 176. But, if we're going to make getCallerClass public (which everyone in the community seems to want), we either have to also make @CallerSensitive public or just remove the security check of CallerSensitive's presence (which means CallerSensitive is no longer necessary). Nick On Sep 1, 2013, at 4:25 AM, Alan Bateman wrote: > On 01/09/2013 09:16, Nick Williams wrote: >> : >> >> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. >> > You may need to check your https server as it doesn't look like it's possible to establish a SSL connection ("no common encryption algorithms" is one of the errors I see). > > Just to set expectations, you are proposing changes in an area that is very security sensitive. As your patches are not currently accessible then I can't say whether you have taken this into account or not. I bring it up because it will have an influence on what we do here. Your mail also mentions moving sun.reflect.CallerSensitive to java.lang but as I recall, this was an explicit non-goal of JEP 176. So I would suggest be prepared for changes to the proposal, also the potential to take time to get agreement on any new APIs. My comments are not meant in any way to discourage you, rather just to highlight that this is a sensitive area. > > -Alan From eliasen at mindspring.com Sun Sep 1 17:13:45 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Sun, 01 Sep 2013 11:13:45 -0600 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> Message-ID: <522375C9.8010005@mindspring.com> On 09/01/2013 09:50 AM, Nick Williams wrote: > Interesting. I can access HTTPS in all of my browsers. OT, to help my > figure out what's up with my HTTPS, what browsers and versions are > y'all using, J?rn and Alan? I get the same problems with Firefox 23 on Linux. This will help you debug some of your problems: https://www.ssllabs.com/ssltest/analyze.html?d=java.nicholaswilliams.net As you can see, it won't work with most browsers. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From nicholas+openjdk at nicholaswilliams.net Sun Sep 1 20:04:43 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Sun, 1 Sep 2013 15:04:43 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <522375C9.8010005@mindspring.com> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> Message-ID: <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> Thanks for the help, everyone! The Qualys SSL Labs tool was invaluable. Apparently using "-SSLv3" in the SSLCipherSuite setting in Apache also disables TLSv1.0 and TLSv1.2, breaking most clients. Not very intuitive, but I got it sorted out so that I'm supporting only TLSv1.0 through TLSv1.2, which works in all modern browsers. Thankfully I only changed these settings like five days ago, so it hasn't been broken very long. Back to the discussion at hand :-)... One of my helpful Twitter friends pointed out the email I was referring to regarding a sponsor: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019381.html So David says he thinks he can find someone at RedHat to sponsor this, assuming it looks good. Nick On Sep 1, 2013, at 12:13 PM, Alan Eliasen wrote: > On 09/01/2013 09:50 AM, Nick Williams wrote: >> Interesting. I can access HTTPS in all of my browsers. OT, to help my >> figure out what's up with my HTTPS, what browsers and versions are >> y'all using, J?rn and Alan? > > I get the same problems with Firefox 23 on Linux. This will help you > debug some of your problems: > > https://www.ssllabs.com/ssltest/analyze.html?d=java.nicholaswilliams.net > > As you can see, it won't work with most browsers. > > -- > Alan Eliasen > eliasen at mindspring.com > http://futureboy.us/ From david.holmes at oracle.com Mon Sep 2 00:49:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Sep 2013 10:49:09 +1000 Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues In-Reply-To: <52208720.90305@oracle.com> References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>, , <521F47DD.2020502@oracle.com> <521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com> <521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com> <521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com> <521FF518.7060803@oracle.com> <52203F81.8080903@oracle.com> <522047DC.4030502@oracle.com> <522059F3.7040408@oracle.com> <52208720.90305@oracle.com> Message-ID: <5223E085.1070607@oracle.com> Ship it! :) Thanks, David On 30/08/2013 9:50 PM, Daniel Fuchs wrote: > Hi, > > Please find below an updated patch for solution (c) > > > > best regards, > > -- daniel > > >>> It seems we have 5 choices: > >>> > >>> a. Not fixing > >>> b. Using regular 'synchronized' pattern [1] > >>> c. Using volatiles, synchronize setters only [2] > >>> d. Using volatiles, only synchronize setters when obviously necessary > >>> e. other? (like introducing new private locks - but I don't think > >>> anybody would want that) > >>> > >>> [1] > >>> [2] > >>> > >>> My own preference would lean to either b) or c). > > > > On 8/30/13 10:38 AM, Daniel Fuchs wrote: >> On 8/30/13 9:21 AM, David Holmes wrote: >>> Hi Daniel, >>> >>> I'm fine with the approach in (c), just wanted to highlight the >>> performance considerations (volatile and synchronized need not be >>> equivalent in the uncontended case - biased-locking can mean there are >>> no barriers emitted.) >>> >>> A few specific comments on [2]: >>> >>> Handler.java: >>> >>> reportError doesn't need changing now that the field is volatile and you >>> aren't doing sync. >> >> right. I will revert to original code. >> >>> MemoryHandler.java: >>> >>> pushLevel should/could be volatile and the sync removed from >>> getPushLevel. >> >> right. thanks - I missed that. >> >>> In setPushLevel this seems to be unused code: >>> >>> 262 LogManager manager = LogManager.getLogManager(); >>> >>> unless there is some obscure side-effect in calling getLogManager ?? >> >> Well - yes it triggers the initialization of the logging system. >> However the super class will already have called getLogManager() - >> so this call should have no effect. I will remove it. >> >>> setPushLevel might as well also be synchronized at the method level. All >>> the Handler methods already include checkPermission inside the >>> sync-block. Though I'm actually more inclined to change all the existing >>> code to use sync-blocks so that checkPermission is done outside the lock >>> region. But a consistent approach either way would be preferable. >> >> Agreed. Once I have removed the call to LogManager then the method can >> be synchronized at method level. >> >>> StreamHandler.java >>> >>> writer doesn't need to be volatile - AFAICS it is only accessed within >>> synchronized methods. >> >> Ah - no - it's called in isLoggable() actually. The whole point of using >> volatiles instead of regular synchronization was to allow isLoggable() >> to be called concurrently with e.g. publish() - so I would think >> it's better to make writer volatile too. >> >> Thanks for the valuable comments! I will update the webrev and send out >> a new revision... >> >> best regards, >> >> -- daniel >> >>> >>> Thanks, >>> David >>> >>> On 30/08/2013 4:45 PM, Daniel Fuchs wrote: >>>> On 8/30/13 3:27 AM, David Holmes wrote: >>>>> Hi Daniel, >>>>> >>>>> As usual with these kinds of changes we start by trying to complete an >>>>> incomplete/incorrect synchronization pattern and get diverted into >>>>> changing the synchronization pattern. :) The latter of course has more >>>>> risk than the former. >>>>> >>>>> Making everything synchronized has the benefit that we don't need to >>>>> analyse the "real" methods to check what would happen if one of these >>>>> data values changed mid-method. Might be harmless, might not. >>>>> Atomicity makes things easy to reason about. >>>> Agreed. We can analyze the 'real methods' of Handler classes in the >>>> JDK. >>>> But I'm sure there are plenty of >>>> subclasses of handlers in applications out there that we don't know >>>> about. So we can't really be sure >>>> what the effect of changing synchronization might have on those >>>> subclasses. >>>> >>>>> Making the fields volatile and un-sync'ing the getters is a potential >>>>> optimization for readers. But are these fields that are read >>>>> frequently by multiple threads? >>>> >>>> At least three of them are accessed by isLoggable() which I believe is >>>> called very frequently by >>>> multiple threads (level, filter, and writer). >>>> >>>>> The downside of doing so is a negative performance impact inside the >>>>> "real" methods where every volatile field access requires >>>>> (platform-dependent) memory barriers. >>>> That - I think - should not be such an issue since the fields are >>>> private. >>>> I mean - we can see whether there are methods that do multiple >>>> access to >>>> the fields in the >>>> classes that define these fields - and fix that if necessary. >>>> For subclasses, they will have to call the getter, which will require >>>> synchronization anyway. >>>> I mean - for subclasses - isn't the fact that the getter accesses a >>>> volatile field or the fact that the >>>> getter is synchronized equivalent in terms of performance? >>>> >>>> JDK 8 is a major version of the JDK - so I think if we want to fix this >>>> bug it's >>>> probably better to do it now rather than in a minor update. >>>> >>>> It seems we have 5 choices: >>>> >>>> a. Not fixing >>>> b. Using regular 'synchronized' pattern [1] >>>> c. Using volatiles, synchronize setters only [2] >>>> d. Using volatiles, only synchronize setters when obviously necessary >>>> e. other? (like introducing new private locks - but I don't think >>>> anybody would want that) >>>> >>>> [1] >>>> [2] >>>> >>>> My own preference would lean to either b) or c). >>>> >>>> -- daniel >>>> >>>> >>>>> >>>>> David >>>>> >>>>> On 30/08/2013 5:54 AM, Daniel Fuchs wrote: >>>>>> On 8/29/13 9:45 PM, Mandy Chung wrote: >>>>>>> On 8/29/13 11:04 AM, Daniel Fuchs wrote: >>>>>>>> On 8/29/13 7:58 PM, Mandy Chung wrote: >>>>>>>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote: >>>>>>>>>> Here is the new webrev implementing Jason's suggestion. >>>>>>>>>> Compared to previous webrev only Handler.java & >>>>>>>>>> StreamHandler.java >>>>>>>>>> have changed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Looks good. I also agree that making those fields to be volatile >>>>>>>>> is a >>>>>>>>> good suggestion and only requires writer to acquire the lock. >>>>>>>>> >>>>>>>>> A minor comment: The setter methods in Handler class are >>>>>>>>> synchronized >>>>>>>>> at the method entry whereas StreamHandler.setPushLevel >>>>>>>>> synchronizes >>>>>>>>> after checkPermission() is called. checkPermission doesn't need >>>>>>>>> to be >>>>>>>>> synchronized. Either way is fine with me and it'd be good to >>>>>>>>> do it >>>>>>>>> consistently. >>>>>>>> >>>>>>>> Hi Mandy, >>>>>>>> >>>>>>>> Are you suggesting I should put checkPermission() within >>>>>>>> the synchronized block? It might be more consistent with >>>>>>>> what the other setters do. Although as you state it does >>>>>>>> not matter much. >>>>>>> >>>>>>> Having a second thought - do the setters really need to be >>>>>>> synchronized? My guess is that StreamHandler.publish is >>>>>>> synchronized >>>>>>> so as to ensure that the log messages are sequential and not >>>>>>> interpersed >>>>>>> when multiple threads are publishing. The spec is unclear. >>>>>>> Perhaps it >>>>>>> worths looking into this further? >>>>>> >>>>>> I believe at least setEncodings() needs synchronization. >>>>>> setLevel() had it - so are we going to cause subtle race conditions >>>>>> if we remove it? >>>>>> >>>>>> My own feeling is that keeping setters synchronized might be better. >>>>>> >>>>>> We could of course say that a subclass which needs to prevent >>>>>> e.g. setFormatter() from being called concurrently with publish() >>>>>> should override setFormatter just for the purpose of synchronizing >>>>>> it... >>>>>> >>>>>>> One more minor note: MemoryHandler.pushLevel can also be made >>>>>>> volatile. >>>>>>> L262: look like the log manager is not needed in the existing code. >>>>>> >>>>>> hmmm. Right. It's already called once in the super class so removing >>>>>> this call should have no effect. I will remove it. >>>>>> >>>>>> -- daniel >>>>>> >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>> >>>> >> > From xuelei.fan at oracle.com Mon Sep 2 03:01:03 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 02 Sep 2013 03:01:03 +0000 Subject: hg: jdk8/tl/jdk: 8024068: sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java fails Message-ID: <20130902030200.A5CDA6248B@hg.openjdk.java.net> Changeset: ead6babac5a9 Author: xuelei Date: 2013-09-01 20:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ead6babac5a9 8024068: sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java fails Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java From Alan.Bateman at oracle.com Mon Sep 2 08:33:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 09:33:20 +0100 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> Message-ID: <52244D50.5080603@oracle.com> On 01/09/2013 21:04, Nick Williams wrote: > : > > So David says he thinks he can find someone at RedHat to sponsor this, assuming it looks good. > > Nick I see the patch is accessible now. From a quick scan then it appears that you've decided to ignore the security concerns so I don't think anyone can (or should) sponsor this patch until there is further discussion on the API and the security implications. To help things then one suggestion is start small and just focus on the no-arg getCallerClass and the method to return the array of stack traces (be it an extended StackTraceElement or the new StackTraceFrame that you are proposing). The getCallerClass will need a permission check, as will the method to get the extended stack trace. I think it would also be useful to lay out the points on extending StackTraceEment vs. introducing a few StackTraceFrame type. -Alan. From dl at cs.oswego.edu Mon Sep 2 11:18:58 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 02 Sep 2013 07:18:58 -0400 Subject: Potential issue with CHM.toArray In-Reply-To: <521DF795.8070905@gmail.com> References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com> <521DF795.8070905@gmail.com> Message-ID: <52247422.1060607@cs.oswego.edu> On 08/28/2013 09:13 AM, Peter Levart wrote: > On 08/28/2013 12:10 PM, Paul Sandoz wrote: >> Hi, >> >> Intermittent failures were reported with the CHM toArray test in the JDK. >> >> I updated the tests to increase the number of runs and the number of workers >> and i can reliably reproduce on my laptop, see below. >> >> The test presumes the size should always increase but fails when it observes a >> new new size less than the previously observed size. >> >> Is that a valid assumption? > > I guess it should be a valid assumption. Thanks to Peter for a good suggestion for preserving this assumption without needing to block (or messily avoid blocking) on traversal, and to Paul for helping to re-test. An update is now in our CVS and in lambda, so can also now move to tl. -Doug From chris.hegarty at oracle.com Mon Sep 2 12:10:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 02 Sep 2013 13:10:16 +0100 Subject: RFR 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg Message-ID: <52248028.6080108@oracle.com> This is a small issue that was spotted by one of the TCK engineers. Trivially, the args should be long. Doug has already pull this change into his CVS. This RFR is to pull the change into JDK8. diff --git a/src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java b/src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java --- a/src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java +++ b/src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java @@ -303,7 +303,7 @@ public class AtomicLongArray implements * @return the previous value * @since 1.8 */ - public final long getAndAccumulate(int i, int x, + public final long getAndAccumulate(int i, long x, LongBinaryOperator accumulatorFunction) { long offset = checkedByteOffset(i); long prev, next; @@ -329,7 +329,7 @@ public class AtomicLongArray implements * @return the updated value * @since 1.8 */ - public final long accumulateAndGet(int i, int x, + public final long accumulateAndGet(int i, long x, LongBinaryOperator accumulatorFunction) { long offset = checkedByteOffset(i); long prev, next; -Chris. From Alan.Bateman at oracle.com Mon Sep 2 12:19:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 13:19:49 +0100 Subject: RFR 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg In-Reply-To: <52248028.6080108@oracle.com> References: <52248028.6080108@oracle.com> Message-ID: <52248265.2050401@oracle.com> On 02/09/2013 13:10, Chris Hegarty wrote: > This is a small issue that was spotted by one of the TCK engineers. > Trivially, the args should be long. Looks fine to me (and no compatibility issues as these are new methods in 8). -Alan. From chris.hegarty at oracle.com Mon Sep 2 12:33:59 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 02 Sep 2013 13:33:59 +0100 Subject: RFR 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg In-Reply-To: <52248265.2050401@oracle.com> References: <52248028.6080108@oracle.com> <52248265.2050401@oracle.com> Message-ID: <522485B7.8010709@oracle.com> Thanks Alan. On 09/02/2013 01:19 PM, Alan Bateman wrote: > On 02/09/2013 13:10, Chris Hegarty wrote: >> This is a small issue that was spotted by one of the TCK engineers. >> Trivially, the args should be long. > Looks fine to me (and no compatibility issues as these are new methods > in 8). Yes, of course. I meant to highlight that. -Chris. > > -Alan. > > From paul.sandoz at oracle.com Mon Sep 2 12:44:51 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Sep 2013 14:44:51 +0200 Subject: RFR 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg In-Reply-To: <52248265.2050401@oracle.com> References: <52248028.6080108@oracle.com> <52248265.2050401@oracle.com> Message-ID: On Sep 2, 2013, at 2:19 PM, Alan Bateman wrote: > On 02/09/2013 13:10, Chris Hegarty wrote: >> This is a small issue that was spotted by one of the TCK engineers. Trivially, the args should be long. > Looks fine to me (and no compatibility issues as these are new methods in 8). > +1. Paul. From paul.sandoz at oracle.com Mon Sep 2 13:03:28 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Sep 2013 15:03:28 +0200 Subject: Review: lamda expressions and bulk data operations on collections. In-Reply-To: References: <521F93F8.50809@oracle.com> <521FA346.9090603@oracle.com> <5220F467.8020209@oracle.com> Message-ID: <6012D6F7-C40D-4796-9CFF-7E0B4242A34A@oracle.com> On Aug 31, 2013, at 8:25 AM, Ali Ebrahimi wrote: > I see nobody using mangled (comparing&map) methods (even oracle guys) and > this is the thing that I already have expected, just since we all lazy and > this would hurt performance. I suspect this is more to do with the examples being coded against an older version of tl/lambda as evidenced by the use of the 2-type-arg Collector: $ javac *.java CSVProcessor.java:191: error: wrong number of type arguments; required 3 private static class Statistics implements Collector { -- Andrey, there are still some differences between tl and lambda, mainly around closeable streams, which i think will require you to make some changes to the examples. So i strongly recommend that you update the examples to compile and run against the tip of the lambda repo, then we can push/refine in that repo, and once we are happy with it review and push to tl. I can push to lambda for you. Paul. From chris.hegarty at oracle.com Mon Sep 2 13:03:13 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 02 Sep 2013 13:03:13 +0000 Subject: hg: jdk8/tl/jdk: 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg Message-ID: <20130902130401.1BB7E624A1@hg.openjdk.java.net> Changeset: 441da45931fa Author: chegar Date: 2013-09-02 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/441da45931fa 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg Reviewed-by: alanb, psandoz ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java From paul.sandoz at oracle.com Mon Sep 2 13:24:09 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Sep 2013 15:24:09 +0200 Subject: RFR 8010293 Re: Potential issue with CHM.toArray In-Reply-To: <52247422.1060607@cs.oswego.edu> References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com> <521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu> Message-ID: <3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com> On Sep 2, 2013, at 1:18 PM, Doug Lea
wrote: > On 08/28/2013 09:13 AM, Peter Levart wrote: >> On 08/28/2013 12:10 PM, Paul Sandoz wrote: >>> Hi, >>> >>> Intermittent failures were reported with the CHM toArray test in the JDK. >>> >>> I updated the tests to increase the number of runs and the number of workers >>> and i can reliably reproduce on my laptop, see below. >>> >>> The test presumes the size should always increase but fails when it observes a >>> new new size less than the previously observed size. >>> >>> Is that a valid assumption? >> >> I guess it should be a valid assumption. > > Thanks to Peter for a good suggestion for preserving this > assumption without needing to block (or messily avoid blocking) > on traversal, and to Paul for helping to re-test. An update is > now in our CVS and in lambda, so can also now move to tl. > Here is the fix in the lambda repo which can be applied to tl: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b73937e96ae0 http://hg.openjdk.java.net/lambda/lambda/jdk/raw-rev/b73937e96ae0 Paul. From daniel.fuchs at oracle.com Mon Sep 2 13:29:11 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 02 Sep 2013 15:29:11 +0200 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation Message-ID: <522492A7.2010408@oracle.com> Hi, Please find below a fix for: 8016127: NLS: logging.properties translatability recommendation This fix corrects localized Level names in JDK 8. It updates the logging.properties resource bundles to follow internationalization guidelines: all caps words are usually considered as constant names that must not be translated - and the base resource bundle logging.properties - will no longer contain capitalized names. The changeset contains a test that will verify that the logging.properties bundles are correct - which should hopefully catch translation issues early int the process and avoid last minutes fire-drills like we had in the past. To make the test pass, I had to replace the untranslated bundles from JDK 8 by their translated version from JDK 7u-dev. The fix also makes sure that the Level names will still be printed in all caps, even if their translation isn't. As per Mandy's request I also took this opportunity to fix the localized name caching mechanism which didn't take into account possible changes of the default locale returned by Locale.getDefault(). best regards, -- daniel From tom.hawtin at oracle.com Mon Sep 2 13:56:02 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 02 Sep 2013 14:56:02 +0100 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <52244D50.5080603@oracle.com> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> Message-ID: <522498F2.6050001@oracle.com> On 02/09/2013 09:33, Alan Bateman wrote: > From a quick scan then it appears that you've decided to ignore the > security concerns so I don't think anyone can (or should) sponsor this > patch until there is further discussion on the API and the security > implications. I've barely looked through the patch, let alone audited it. However: As the method appears to be mostly for tracing, performing a security check per invocation is likely to hurt performance. Unless it was caller sensitive (which seems to be equated with Bad Practice these days) it would also require a doPrivileged block. Much better to perform a single security check when acquiring a capability object, in a similar(ish) way to sun.misc.Unsafe or SharedSecrets. In order to work with less privileged code, it may also be worthwhile to provide a version of the capability object parameterised with a class loader. If code has access to a ClassLoader object, then it is consistent for it to be given access to Classes loaded by it or child loaders, and in practice from parent loaders (but not children of parents). Security relating to Class objects is "interesting". The genuine security issue with Class objects is that they have are an attenuation of the capability of their ClassLoader. There are many ways to acquire Class objects. Some have confusing defence-in-depth security; some, such as Object.getClass used for quick null checks, do not. Tom From Alan.Bateman at oracle.com Mon Sep 2 14:00:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 15:00:47 +0100 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation In-Reply-To: <522492A7.2010408@oracle.com> References: <522492A7.2010408@oracle.com> Message-ID: <52249A0F.6020209@oracle.com> On 02/09/2013 14:29, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8016127: NLS: logging.properties translatability recommendation > > One thing I notice is that you've changed Level.localizedLevelName to be transient so this changes the serialized form (so technically an API change). Any issues for interop if this field is null when deserialized? -Alan From jhuxhorn at googlemail.com Mon Sep 2 14:08:01 2013 From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=) Date: Mon, 2 Sep 2013 16:08:01 +0200 Subject: =?UTF-8?Q?Re=3A_=5BPATCH=5D_4851444=3A_Exposing_sun.reflect.Reflection=23getCallerClass_as_a_public_API_in_Java_8?= In-Reply-To: <52244D50.5080603@oracle.com> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> Message-ID: On 2. September 2013 at 10:33:59, Alan Bateman (alan.bateman at oracle.com) wrote: On 01/09/2013 21:04, Nick Williams wrote:? > :? >? > So David says he thinks he can find someone at RedHat to sponsor this, assuming it looks good.? >? > Nick? I see the patch is accessible now.? From a quick scan then it appears that you've decided to ignore the? security concerns so I don't think anyone can (or should) sponsor this? patch until there is further discussion on the API and the security? implications.? I don't think Nick "decided to ignore the security concerns". I know about [0] but I'm not exactly sure which security measures are necessary. He can simply add security checks as requested. What exactly are the security concerns, anyway? Calling methods on a class retrieved in that way would still require a potentially installed SecurityManager to allow the call, right? I don't say that there are no security issues, I'd just like to get a better understanding of the issues at hand. To help things then one suggestion is start small and just focus on the? no-arg getCallerClass and the method to return the array of stack traces? (be it an extended StackTraceElement or the new StackTraceFrame that you? are proposing). The getCallerClass will need a permission check, as will? the method to get the extended stack trace. I think it would also be? useful to lay out the points on extending StackTraceEment vs.? introducing a few StackTraceFrame type.? I think the rationale for StackTraceFrame vs. enhanced StackTraceElement is serialization. StackTraceElement is Serializable but Class, while being Serializable, would likely fail deserializing on remote systems with a different classpath. It's a common use case to serialize StackTraceElements in case of logging frameworks, which would then be deserialized on a remote server.?It would be possible to declare that field transient but this would result in null values in deserialized instances. StackTraceFrame, on the other hand, does not implement Serializable and?declaringClass is a mandatory field. Two distinct classes are the cleaner solution (no impact on Throwable, no null checks required retrieving the class). (A convenience method to transform a StackTraceFrame into a StackTraceElement would probably be handy, though.) This was discussed in [1] and [2]. I had the impression that going for a separate class was the way to go. Making?sun.reflect.CallerSensitive public was discussed in [3]. Doing so sounds like a good idea to me if going for the "full" JEPS-176 instead of the "alternative". Nick also explained a performance issue in?Thread#getStackTrace() and Throwable#getStackTrace(). Keeping that in mind, I'm not sure if going for "start small" (i.e. leaving that issue alone) would be a wise decision. The thing is that we really need a proper solution before API freeze on?2013-10-10. This is a proper solution with regards to the API, with as little side effects as possible (due to not changing StackTraceElement, Throwable or Thread regarding declaringClass). I'd suggest to not restart the discussion about whether adding this to StackTraceElement or putting it into a separate class. We should instead try to discuss this existing API and clarify what needs to be changed to get this approved. I hope I don't come across rude or something. The prospect of a Java 8 without a proper replacement API for?sun.reflect.Reflection#getCallerClass is simply giving me serious creeps and time is very pressing if we want to pull this off. J?rn. --- [0]?http://openjdk.java.net/jeps/176 [1]?http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-October/thread.html#11665 [2]?http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/thread.html#18049 [3]?http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/thread.html#18353 From paul.sandoz at oracle.com Mon Sep 2 14:12:49 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Sep 2013 16:12:49 +0200 Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black) In-Reply-To: <83BF5EA9-9D8C-48FC-B539-B6579DB7E12F@oracle.com> References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com> <83BF5EA9-9D8C-48FC-B539-B6579DB7E12F@oracle.com> Message-ID: <09C37AD7-3D75-46DB-8258-B1B911ECDB8D@oracle.com> FYI: this has been soaking in the lambda repo for over a weak now. AFAICT there have been no issues. Paul. On Aug 24, 2013, at 6:31 PM, Mike Duigou wrote: > I will need to spend more time reviewing the HashMap/LinkedHashMap implementations but here are some initial comments. > > Mike From daniel.fuchs at oracle.com Mon Sep 2 14:21:27 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 02 Sep 2013 16:21:27 +0200 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation In-Reply-To: <52249A0F.6020209@oracle.com> References: <522492A7.2010408@oracle.com> <52249A0F.6020209@oracle.com> Message-ID: <52249EE7.6020901@oracle.com> On 9/2/13 4:00 PM, Alan Bateman wrote: > On 02/09/2013 14:29, Daniel Fuchs wrote: >> Hi, >> >> Please find below a fix for: >> >> 8016127: NLS: logging.properties translatability recommendation >> >> > One thing I notice is that you've changed Level.localizedLevelName to be > transient so this changes the serialized form (so technically an API > change). Any issues for interop if this field is null when deserialized? Hi Alan, This field was introduced recently by changeset d1668eca22bf, and should have been declared transient from the start. Mandy asked me to correct it here. -- daniel > > -Alan From Alan.Bateman at oracle.com Mon Sep 2 14:57:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 15:57:58 +0100 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation In-Reply-To: <52249EE7.6020901@oracle.com> References: <522492A7.2010408@oracle.com> <52249A0F.6020209@oracle.com> <52249EE7.6020901@oracle.com> Message-ID: <5224A776.60904@oracle.com> On 02/09/2013 15:21, Daniel Fuchs wrote: > > Hi Alan, > > This field was introduced recently by changeset d1668eca22bf, > and should have been declared transient from the start. > > > > > Mandy asked me to correct it here. > > -- daniel I just checked jdk7u and it appears to have this field in its serialized form. Was it removed or re-added at some point? -Alan From Alan.Bateman at oracle.com Mon Sep 2 14:59:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 15:59:55 +0100 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> Message-ID: <5224A7EB.5070608@oracle.com> On 02/09/2013 15:08, J?rn Huxhorn wrote: > : > > Nick also explained a performance issue in Thread#getStackTrace() and Throwable#getStackTrace(). Keeping that in mind, I'm not sure if going for "start small" (i.e. leaving that issue alone) would be a wise decision. > It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So the suggestion to start out small was to leave that out and focus on some of the use-cases initially. I don't think this suggestion is unreasonable as it allows the less controversial part to move forward. -Alan. From forax at univ-mlv.fr Mon Sep 2 15:07:09 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 02 Sep 2013 17:07:09 +0200 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <522498F2.6050001@oracle.com> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> <522498F2.6050001@oracle.com> Message-ID: <5224A99D.2040708@univ-mlv.fr> On 09/02/2013 03:56 PM, Tom Hawtin wrote: > On 02/09/2013 09:33, Alan Bateman wrote: > >> From a quick scan then it appears that you've decided to ignore the >> security concerns so I don't think anyone can (or should) sponsor this >> patch until there is further discussion on the API and the security >> implications. > > I've barely looked through the patch, let alone audited it. However: > > As the method appears to be mostly for tracing, performing a security > check per invocation is likely to hurt performance. Unless it was > caller sensitive (which seems to be equated with Bad Practice these > days) it would also require a doPrivileged block. Much better to > perform a single security check when acquiring a capability object, in > a similar(ish) way to sun.misc.Unsafe or SharedSecrets. > > In order to work with less privileged code, it may also be worthwhile > to provide a version of the capability object parameterised with a > class loader. If code has access to a ClassLoader object, then it is > consistent for it to be given access to Classes loaded by it or child > loaders, and in practice from parent loaders (but not children of > parents). > > Security relating to Class objects is "interesting". The genuine > security issue with Class objects is that they have are an attenuation > of the capability of their ClassLoader. There are many ways to acquire > Class objects. Some have confusing defence-in-depth security; some, > such as Object.getClass used for quick null checks, do not. > > Tom I wonder if a java.lang.invoke.MethodHandles.Lookup is not a better object than a ClassLoader for a capability object. R?mi From Alan.Bateman at oracle.com Mon Sep 2 15:26:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 16:26:52 +0100 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation In-Reply-To: <5224A776.60904@oracle.com> References: <522492A7.2010408@oracle.com> <52249A0F.6020209@oracle.com> <52249EE7.6020901@oracle.com> <5224A776.60904@oracle.com> Message-ID: <5224AE3C.50208@oracle.com> On 02/09/2013 15:57, Alan Bateman wrote: > On 02/09/2013 15:21, Daniel Fuchs wrote: >> >> Hi Alan, >> >> This field was introduced recently by changeset d1668eca22bf, >> and should have been declared transient from the start. >> >> >> >> >> Mandy asked me to correct it here. >> >> -- daniel > I just checked jdk7u and it appears to have this field in its > serialized form. Was it removed or re-added at some point? Okay, I see what happened, this was added to jdk7u too and the docs must have been re-generated. I've looked through the code and I think it's harmless (in the sense that I don't think it will cause any interop issues). Anyway, the changes in the webrev looks fine. -Alan. From mandy.chung at oracle.com Mon Sep 2 15:43:14 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 02 Sep 2013 08:43:14 -0700 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation In-Reply-To: <522492A7.2010408@oracle.com> References: <522492A7.2010408@oracle.com> Message-ID: <5224B212.8040406@oracle.com> On 9/2/2013 6:29 AM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8016127: NLS: logging.properties translatability recommendation > > > This change looks fine. As for the cached localized name and the tranisent localizedLevelName field which was a regression introduced in 7u13, it'd be worth filing a separate bug to track it. Having one changeset with two bug ids is fine. thanks Mandy > This fix corrects localized Level names in JDK 8. > > It updates the logging.properties resource bundles to follow > internationalization guidelines: all caps words are usually considered > as constant names that must not be translated - and the base > resource bundle logging.properties - will no longer contain > capitalized names. > > The changeset contains a test that will verify that > the logging.properties bundles are correct - which should > hopefully catch translation issues early int the process and avoid > last minutes fire-drills like we had in the past. > > To make the test pass, I had to replace the untranslated bundles > from JDK 8 by their translated version from JDK 7u-dev. > The fix also makes sure that the Level names will still be printed > in all caps, even if their translation isn't. > > As per Mandy's request I also took this opportunity to fix the > localized name caching mechanism which didn't take into account > possible changes of the default locale returned by > Locale.getDefault(). > > best regards, > > -- daniel From sean.coffey at oracle.com Mon Sep 2 15:47:11 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 16:47:11 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext Message-ID: <5224B2FF.7090904@oracle.com> Performance regression reported where a high number of threads calling TimeZone.getDefault can run into a bottleneck on AppContext accessor calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. Turns out that we're unnecessarily going through the AppContext in certain scenarios. Main aim is to use AppContext when using applets. We should check for presence of security manager (along with loading for AppContext class) in such cases. http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ This fix is not applicable to jdk8 as new code is currently being worked on there which eliminates AppContext use. Regards, Sean. From Alan.Bateman at oracle.com Mon Sep 2 16:05:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 17:05:10 +0100 Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates In-Reply-To: <71E57086-0BAF-41D6-BB1E-6815DC3FF922@oracle.com> References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> <52202FA8.1010405@oracle.com> <71E57086-0BAF-41D6-BB1E-6815DC3FF922@oracle.com> Message-ID: <5224B736.20703@oracle.com> On 30/08/2013 21:30, Mike Duigou wrote: > : > Did you see David Holmes' suggestion? Do you think it's adequate? I agree about the maintainability aspect as I really felt guilty re-creating FILES_JAVA.gmk... Sorry Mike, I somehow missed your reply on this topic. Do you mean reorganizing the tests, say to move the collection tests down a level? I don't see a problem with that except that moving tests around can be mildly disruptive, bugs tracking test failures for example. -Alan From daniel.fuchs at oracle.com Mon Sep 2 16:40:14 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 02 Sep 2013 16:40:14 +0000 Subject: hg: jdk8/tl/jdk: 8016127: NLS: logging.properties translatability recommendation; ... Message-ID: <20130902164042.DF39A624A9@hg.openjdk.java.net> Changeset: 92d594a938ff Author: dfuchs Date: 2013-09-02 18:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d594a938ff 8016127: NLS: logging.properties translatability recommendation 8024131: Issues with cached localizedLevelName in java.util.logging.Level Summary: This fix updates logging.properties resource bundles to follow internationalization guidelines. It also fixes a caching issue with localizedLevelName. The regression test that was added needs both fixes to pass. Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/Level.java ! src/share/classes/sun/util/logging/resources/logging.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties + test/java/util/logging/LocalizedLevelName.java From nicholas+openjdk at nicholaswilliams.net Mon Sep 2 17:45:08 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Mon, 2 Sep 2013 12:45:08 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <5224A99D.2040708@univ-mlv.fr> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> <522498F2.6050001@oracle.com> <5224A99D.2040708@univ-mlv.fr> Message-ID: <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote: > It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So the suggestion to start out small was to leave that out and focus on some of the use-cases initially. I don't think this suggestion is unreasonable as it allows the less controversial part to move forward. To be blunt, this goal is incompatible with the need to make getCallerClass public. Either we need to remove CallerSensitive entirely (which I have nothing against), or we need to make it public. But we can't keep CallerSensitive private and make getCallerClass public. Now if you just have a general objection to making getCallerClass public, then please, state it. In fact, if anything, I'm actually in favor of removing CallerSensitive entirely. It prevents code compiled on Java 6 from using those two methods, since they can't be annotated with @CallerSensitive. On Sep 2, 2013, at 3:33 AM, Alan Bateman wrote: > From a quick scan then it appears that you've decided to ignore the security concerns so I don't think anyone can (or should) sponsor this patch until there is further discussion on the API and the security implications. > > To help things then one suggestion is start small and just focus on the no-arg getCallerClass and the method to return the array of stack traces (be it an extended StackTraceElement or the new StackTraceFrame that you are proposing). The getCallerClass will need a permission check, as will the method to get the extended stack trace. I think it would also be useful to lay out the points on extending StackTraceEment vs. introducing a few StackTraceFrame type. I didn't decide to ignore the security concerns, I just don't see any security concerns. As has been /clearly/ established in the last three months, frameworks have been using getCallerClass for years, if not a decade. It has never caused a security problem. Ever. If I'm wrong, please point out to me a specific vulnerability that this has led to. I have worked on this API for a MONTH. We discussed it for TWO months before that. I am a month behind on the deadline for my Java 8 / Java EE 7 book because I essentially dropped it to work on this. I don't have the ability to go back and start from the beginning on something that I had the understanding was generally agreed upon before I started. It's simply not an option. We /clearly/ outlined these use cases in multiple emails over the last three months: 1. The need to get the immediate caller class. 2. The need to get the caller class N levels back. 3. The need to get the entire current stack trace, except with Classes instead of class names. 4. The need to get the stack trace for a Throwable, except with Classes instead of class names. This API meets all of these needs. The one you suggest us starting over on does not. It also adds the ability to get single frames from the stack trace, because that's a natural extension of the above four use cases, and it was trivial to include. There is /no/ need to lay out the points of extending StackTraceElement versus adding StackTraceFrame. It was made /very/ clear to me by several people in June that changing/extending StackTraceElement was /not/ an option due to serialization issues. The very clear intent was for this change to have minimal/no impact on the existing APIs, and that's what I did. The exact interface I used for StackTraceFrame was present in many previous emails (and evolved over about a month of communications), and when I said that I was starting on a patch there were no specific objections to the API that I ever saw. J?rn's email links to several of these discussions. I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. In general, doing things like instantiating a class or calling methods on a class using the Class involves security checks already. I don't see how an additional security check before retrieving a class would be helpful here. Additionally, nothing ever stops me from calling Object#getClass if I have an instance of an object; I may not be able to do anything with that Class (newInstance, invoke methods, etc.), but I can call getClass. On Sep 2, 2013, at 9:08 AM, J?rn Huxhorn wrote: > Nick also explained a performance issue in Thread#getStackTrace() and Throwable#getStackTrace(). Keeping that in mind, I'm not sure if going for "start small" (i.e. leaving that issue alone) would be a wise decision. > > The thing is that we really need a proper solution before API freeze on 2013-10-10. This is a proper solution with regards to the API, with as little side effects as possible (due to not changing StackTraceElement, Throwable or Thread regarding declaringClass). I'd suggest to not restart the discussion about whether adding this to StackTraceElement or putting it into a separate class. We should instead try to discuss this existing API and clarify what needs to be changed to get this approved. > > I hope I don't come across rude or something. The prospect of a Java 8 without a proper replacement API for sun.reflect.Reflection#getCallerClass is simply giving me serious creeps and time is very pressing if we want to pull this off. All of that: my sentiments exactly. Nick On Sep 2, 2013, at 10:07 AM, Remi Forax wrote: > On 09/02/2013 03:56 PM, Tom Hawtin wrote: >> On 02/09/2013 09:33, Alan Bateman wrote: >> >>> From a quick scan then it appears that you've decided to ignore the >>> security concerns so I don't think anyone can (or should) sponsor this >>> patch until there is further discussion on the API and the security >>> implications. >> >> I've barely looked through the patch, let alone audited it. However: >> >> As the method appears to be mostly for tracing, performing a security check per invocation is likely to hurt performance. Unless it was caller sensitive (which seems to be equated with Bad Practice these days) it would also require a doPrivileged block. Much better to perform a single security check when acquiring a capability object, in a similar(ish) way to sun.misc.Unsafe or SharedSecrets. >> >> In order to work with less privileged code, it may also be worthwhile to provide a version of the capability object parameterised with a class loader. If code has access to a ClassLoader object, then it is consistent for it to be given access to Classes loaded by it or child loaders, and in practice from parent loaders (but not children of parents). >> >> Security relating to Class objects is "interesting". The genuine security issue with Class objects is that they have are an attenuation of the capability of their ClassLoader. There are many ways to acquire Class objects. Some have confusing defence-in-depth security; some, such as Object.getClass used for quick null checks, do not. >> >> Tom > > I wonder if a java.lang.invoke.MethodHandles.Lookup is not a better object than a ClassLoader for a capability object. > > R?mi From sean.coffey at oracle.com Mon Sep 2 18:06:49 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 19:06:49 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224B2FF.7090904@oracle.com> References: <5224B2FF.7090904@oracle.com> Message-ID: <5224D3B9.1050905@oracle.com> This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ regards, Sean. On 02/09/13 16:47, Se?n Coffey wrote: > Performance regression reported where a high number of threads calling > TimeZone.getDefault can run into a bottleneck on AppContext accessor > calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. > > Turns out that we're unnecessarily going through the AppContext in > certain scenarios. Main aim is to use AppContext when using applets. > We should check for presence of security manager (along with loading > for AppContext class) in such cases. > > http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ > > This fix is not applicable to jdk8 as new code is currently being > worked on there which eliminates AppContext use. > > Regards, > Sean. From chris.hegarty at oracle.com Mon Sep 2 18:09:01 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 02 Sep 2013 19:09:01 +0100 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> <522498F2.6050001@oracle.com> <5224A99D.2040708@univ-mlv.fr> <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> Message-ID: <5224D43D.3040405@oracle.com> On 09/02/2013 06:45 PM, Nick Williams wrote: > On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote: >> It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So the suggestion to start out small was to leave that out and focus on some of the use-cases initially. I don't think this suggestion is unreasonable as it allows the less controversial part to move forward. > > To be blunt, this goal is incompatible with the need to make getCallerClass public. Either we need to remove CallerSensitive entirely (which I have nothing against), or we need to make it public. But we can't keep CallerSensitive private and make getCallerClass public. Now if you just have a general objection to making getCallerClass public, then please, state it. Sorry, I don't understand why this is incompatible. Other public platform classes are annotated with @CS without it being made public. Why the difference here? I quickly skimmed the patch to see if could get the answer to my above question. I could be wrong, but it appears that you expose the native methods that wrap the calls into the VM directly, and expect users of these methods to be annotated with @CS. I know it may not be ideal, but could similar functionality be achieved by not exposing these methods directly? Say having a non-native public method call a private implementation method that calls into the VM. There may be some knock on changes in the VM to support this, but it could be an option? -Chris. > > In fact, if anything, I'm actually in favor of removing CallerSensitive entirely. It prevents code compiled on Java 6 from using those two methods, since they can't be annotated with @CallerSensitive. > > On Sep 2, 2013, at 3:33 AM, Alan Bateman wrote: >> From a quick scan then it appears that you've decided to ignore the security concerns so I don't think anyone can (or should) sponsor this patch until there is further discussion on the API and the security implications. >> >> To help things then one suggestion is start small and just focus on the no-arg getCallerClass and the method to return the array of stack traces (be it an extended StackTraceElement or the new StackTraceFrame that you are proposing). The getCallerClass will need a permission check, as will the method to get the extended stack trace. I think it would also be useful to lay out the points on extending StackTraceEment vs. introducing a few StackTraceFrame type. > > I didn't decide to ignore the security concerns, I just don't see any security concerns. As has been /clearly/ established in the last three months, frameworks have been using getCallerClass for years, if not a decade. It has never caused a security problem. Ever. If I'm wrong, please point out to me a specific vulnerability that this has led to. > > I have worked on this API for a MONTH. We discussed it for TWO months before that. I am a month behind on the deadline for my Java 8 / Java EE 7 book because I essentially dropped it to work on this. I don't have the ability to go back and start from the beginning on something that I had the understanding was generally agreed upon before I started. It's simply not an option. We /clearly/ outlined these use cases in multiple emails over the last three months: > > 1. The need to get the immediate caller class. > 2. The need to get the caller class N levels back. > 3. The need to get the entire current stack trace, except with Classes instead of class names. > 4. The need to get the stack trace for a Throwable, except with Classes instead of class names. > > This API meets all of these needs. The one you suggest us starting over on does not. It also adds the ability to get single frames from the stack trace, because that's a natural extension of the above four use cases, and it was trivial to include. There is /no/ need to lay out the points of extending StackTraceElement versus adding StackTraceFrame. It was made /very/ clear to me by several people in June that changing/extending StackTraceElement was /not/ an option due to serialization issues. The very clear intent was for this change to have minimal/no impact on the existing APIs, and that's what I did. The exact interface I used for StackTraceFrame was present in many previous emails (and evolved over about a month of communications), and when I said that I was starting on a patch there were no specific objections to the API that I ever saw. J?rn's email links to several of these discussions. > > I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. > > In general, doing things like instantiating a class or calling methods on a class using the Class involves security checks already. I don't see how an additional security check before retrieving a class would be helpful here. Additionally, nothing ever stops me from calling Object#getClass if I have an instance of an object; I may not be able to do anything with that Class (newInstance, invoke methods, etc.), but I can call getClass. > > On Sep 2, 2013, at 9:08 AM, J?rn Huxhorn wrote: >> Nick also explained a performance issue in Thread#getStackTrace() and Throwable#getStackTrace(). Keeping that in mind, I'm not sure if going for "start small" (i.e. leaving that issue alone) would be a wise decision. >> >> The thing is that we really need a proper solution before API freeze on 2013-10-10. This is a proper solution with regards to the API, with as little side effects as possible (due to not changing StackTraceElement, Throwable or Thread regarding declaringClass). I'd suggest to not restart the discussion about whether adding this to StackTraceElement or putting it into a separate class. We should instead try to discuss this existing API and clarify what needs to be changed to get this approved. >> >> I hope I don't come across rude or something. The prospect of a Java 8 without a proper replacement API for sun.reflect.Reflection#getCallerClass is simply giving me serious creeps and time is very pressing if we want to pull this off. > > All of that: my sentiments exactly. > > Nick > > On Sep 2, 2013, at 10:07 AM, Remi Forax wrote: > >> On 09/02/2013 03:56 PM, Tom Hawtin wrote: >>> On 02/09/2013 09:33, Alan Bateman wrote: >>> >>>> From a quick scan then it appears that you've decided to ignore the >>>> security concerns so I don't think anyone can (or should) sponsor this >>>> patch until there is further discussion on the API and the security >>>> implications. >>> >>> I've barely looked through the patch, let alone audited it. However: >>> >>> As the method appears to be mostly for tracing, performing a security check per invocation is likely to hurt performance. Unless it was caller sensitive (which seems to be equated with Bad Practice these days) it would also require a doPrivileged block. Much better to perform a single security check when acquiring a capability object, in a similar(ish) way to sun.misc.Unsafe or SharedSecrets. >>> >>> In order to work with less privileged code, it may also be worthwhile to provide a version of the capability object parameterised with a class loader. If code has access to a ClassLoader object, then it is consistent for it to be given access to Classes loaded by it or child loaders, and in practice from parent loaders (but not children of parents). >>> >>> Security relating to Class objects is "interesting". The genuine security issue with Class objects is that they have are an attenuation of the capability of their ClassLoader. There are many ways to acquire Class objects. Some have confusing defence-in-depth security; some, such as Object.getClass used for quick null checks, do not. >>> >>> Tom >> >> I wonder if a java.lang.invoke.MethodHandles.Lookup is not a better object than a ClassLoader for a capability object. >> >> R?mi > From staffan.larsen at oracle.com Mon Sep 2 18:11:04 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 02 Sep 2013 18:11:04 +0000 Subject: hg: jdk8/tl/jdk: 7172176: java/jconsole test/sun/tools/jconsole/ImmutableResourceTest.sh failing Message-ID: <20130902181123.8FC20624AC@hg.openjdk.java.net> Changeset: a7d463f5a5b9 Author: egahlin Date: 2013-09-02 16:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7d463f5a5b9 7172176: java/jconsole test/sun/tools/jconsole/ImmutableResourceTest.sh failing Reviewed-by: mchung, mfang ! src/share/classes/sun/tools/jconsole/Resources.java ! test/ProblemList.txt - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/sun/tools/jconsole/ResourceCheckTest.java ! test/sun/tools/jconsole/ResourceCheckTest.sh From chris.hegarty at oracle.com Mon Sep 2 18:15:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 02 Sep 2013 19:15:16 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224D3B9.1050905@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> Message-ID: <5224D5B4.7060900@oracle.com> On 09/02/2013 07:06 PM, Se?n Coffey wrote: > This might be a slightly easier one to read. (fast path logic code first) > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ The 'javaAWTAccess != null ' checks are redundant. It will always be the case, right? -Chris. > > regards, > Sean. > > > On 02/09/13 16:47, Se?n Coffey wrote: >> Performance regression reported where a high number of threads calling >> TimeZone.getDefault can run into a bottleneck on AppContext accessor >> calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. >> >> Turns out that we're unnecessarily going through the AppContext in >> certain scenarios. Main aim is to use AppContext when using applets. >> We should check for presence of security manager (along with loading >> for AppContext class) in such cases. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ >> >> This fix is not applicable to jdk8 as new code is currently being >> worked on there which eliminates AppContext use. >> >> Regards, >> Sean. > From sean.coffey at oracle.com Mon Sep 2 18:31:14 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 19:31:14 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224D5B4.7060900@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224D5B4.7060900@oracle.com> Message-ID: <5224D972.4070003@oracle.com> On 02/09/13 19:15, Chris Hegarty wrote: > On 09/02/2013 07:06 PM, Se?n Coffey wrote: >> This might be a slightly easier one to read. (fast path logic code >> first) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ > > The 'javaAWTAccess != null ' checks are redundant. It will always be > the case, right? if (System.getSecurityManager() == null || javaAWTAccess == null) { I'm covering for the case here where we may have a security manager but it's not the plugin one (which would have triggered loading of javaAWTAccess) - I'll double check. regards, Sean. > > -Chris. > >> >> regards, >> Sean. >> >> >> On 02/09/13 16:47, Se?n Coffey wrote: >>> Performance regression reported where a high number of threads calling >>> TimeZone.getDefault can run into a bottleneck on AppContext accessor >>> calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. >>> >>> Turns out that we're unnecessarily going through the AppContext in >>> certain scenarios. Main aim is to use AppContext when using applets. >>> We should check for presence of security manager (along with loading >>> for AppContext class) in such cases. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ >>> >>> This fix is not applicable to jdk8 as new code is currently being >>> worked on there which eliminates AppContext use. >>> >>> Regards, >>> Sean. >> From sean.coffey at oracle.com Mon Sep 2 19:07:42 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 20:07:42 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224D5B4.7060900@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224D5B4.7060900@oracle.com> Message-ID: <5224E1FE.5010805@oracle.com> Chris - you're right on the redundant checks. Had to re-read it! Will get those removed. Thanks. regards, Sean. On 02/09/13 19:15, Chris Hegarty wrote: > On 09/02/2013 07:06 PM, Se?n Coffey wrote: >> This might be a slightly easier one to read. (fast path logic code >> first) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ > > The 'javaAWTAccess != null ' checks are redundant. It will always be > the case, right? > > -Chris. > >> >> regards, >> Sean. >> >> >> On 02/09/13 16:47, Se?n Coffey wrote: >>> Performance regression reported where a high number of threads calling >>> TimeZone.getDefault can run into a bottleneck on AppContext accessor >>> calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. >>> >>> Turns out that we're unnecessarily going through the AppContext in >>> certain scenarios. Main aim is to use AppContext when using applets. >>> We should check for presence of security manager (along with loading >>> for AppContext class) in such cases. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ >>> >>> This fix is not applicable to jdk8 as new code is currently being >>> worked on there which eliminates AppContext use. >>> >>> Regards, >>> Sean. >> From chris.hegarty at oracle.com Mon Sep 2 19:35:03 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 2 Sep 2013 20:35:03 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224E1FE.5010805@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224D5B4.7060900@oracle.com> <5224E1FE.5010805@oracle.com> Message-ID: On 2 Sep 2013, at 20:07, Se?n Coffey wrote: > Chris - > > you're right on the redundant checks. Had to re-read it! Will get those removed. Thanks. Otherwise looks fine to me. -Chris. > > regards, > Sean. > > On 02/09/13 19:15, Chris Hegarty wrote: >> On 09/02/2013 07:06 PM, Se?n Coffey wrote: >>> This might be a slightly easier one to read. (fast path logic code first) >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ >> >> The 'javaAWTAccess != null ' checks are redundant. It will always be the case, right? >> >> -Chris. >> >>> >>> regards, >>> Sean. >>> >>> >>> On 02/09/13 16:47, Se?n Coffey wrote: >>>> Performance regression reported where a high number of threads calling >>>> TimeZone.getDefault can run into a bottleneck on AppContext accessor >>>> calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. >>>> >>>> Turns out that we're unnecessarily going through the AppContext in >>>> certain scenarios. Main aim is to use AppContext when using applets. >>>> We should check for presence of security manager (along with loading >>>> for AppContext class) in such cases. >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8023563/webrev/ >>>> >>>> This fix is not applicable to jdk8 as new code is currently being >>>> worked on there which eliminates AppContext use. >>>> >>>> Regards, >>>> Sean. > From Alan.Bateman at oracle.com Mon Sep 2 20:07:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 02 Sep 2013 21:07:12 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224D3B9.1050905@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> Message-ID: <5224EFF0.4030405@oracle.com> On 02/09/2013 19:06, Se?n Coffey wrote: > This might be a slightly easier one to read. (fast path logic code first) > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ This is nicer (and I see Chris has already pointed out the redundant check). -Alan From vicente.romero at oracle.com Mon Sep 2 21:45:09 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 02 Sep 2013 21:45:09 +0000 Subject: hg: jdk8/tl/langtools: 8022162: Incorrect signature determination for certain inner class generics Message-ID: <20130902214512.172BA624B1@hg.openjdk.java.net> Changeset: 2bf4c132bf90 Author: vromero Date: 2013-09-02 22:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2bf4c132bf90 8022162: Incorrect signature determination for certain inner class generics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/T8022162/IncorrectSignatureDeterminationForInnerClassesTest.java From sean.coffey at oracle.com Mon Sep 2 21:58:36 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 02 Sep 2013 22:58:36 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <5224EFF0.4030405@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224EFF0.4030405@oracle.com> Message-ID: <52250A0C.7000409@oracle.com> Some minor modification (and further simplifying of conditions) : http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ regards, Sean. On 02/09/13 21:07, Alan Bateman wrote: > On 02/09/2013 19:06, Se?n Coffey wrote: >> This might be a slightly easier one to read. (fast path logic code >> first) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ > This is nicer (and I see Chris has already pointed out the redundant > check). > > -Alan From vicente.romero at oracle.com Mon Sep 2 21:39:43 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 02 Sep 2013 21:39:43 +0000 Subject: hg: jdk8/tl/langtools: 8016177: structural most specific and stuckness Message-ID: <20130902213946.1D225624AF@hg.openjdk.java.net> Changeset: 4a6acc42c3a1 Author: vromero Date: 2013-09-02 22:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a6acc42c3a1 8016177: structural most specific and stuckness Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/share/classes/com/sun/tools/javac/util/List.java ! test/tools/javac/Diagnostics/compressed/T8012003c.out ! test/tools/javac/diags/examples/BadArgTypesInLambda.java - test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/IncompatibleArgTypesInMethodRef.java + test/tools/javac/diags/examples/PotentiallyAmbiguousOverload.java + test/tools/javac/lambda/8016177/T8016177a.java + test/tools/javac/lambda/8016177/T8016177a.out + test/tools/javac/lambda/8016177/T8016177b.java + test/tools/javac/lambda/8016177/T8016177b.out + test/tools/javac/lambda/8016177/T8016177c.java + test/tools/javac/lambda/8016177/T8016177c.out + test/tools/javac/lambda/8016177/T8016177d.java + test/tools/javac/lambda/8016177/T8016177e.java + test/tools/javac/lambda/8016177/T8016177f.java + test/tools/javac/lambda/8016177/T8016177g.java + test/tools/javac/lambda/8016177/T8016177g.out ! test/tools/javac/lambda/BadRecovery.out ! test/tools/javac/lambda/ErroneousLambdaExpr.java + test/tools/javac/lambda/ErroneousLambdaExpr.out ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference23.out ! test/tools/javac/lambda/MethodReference41.java + test/tools/javac/lambda/MethodReference41.out ! test/tools/javac/lambda/MethodReference42.java + test/tools/javac/lambda/MethodReference42.out ! test/tools/javac/lambda/MethodReference43.java + test/tools/javac/lambda/MethodReference43.out ! test/tools/javac/lambda/MethodReference44.java + test/tools/javac/lambda/MethodReference44.out ! test/tools/javac/lambda/MethodReference46.java + test/tools/javac/lambda/MethodReference46.out ! test/tools/javac/lambda/MethodReference47.java ! test/tools/javac/lambda/MethodReference47.out ! test/tools/javac/lambda/MethodReference48.java + test/tools/javac/lambda/MethodReference48.out ! test/tools/javac/lambda/MethodReference70.out ! test/tools/javac/lambda/MethodReference71.out ! test/tools/javac/lambda/MostSpecific04.java + test/tools/javac/lambda/MostSpecific04.out ! test/tools/javac/lambda/MostSpecific05.java + test/tools/javac/lambda/MostSpecific05.out ! test/tools/javac/lambda/MostSpecific08.java + test/tools/javac/lambda/MostSpecific08.out ! test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType01.out ! test/tools/javac/lambda/TargetType02.java + test/tools/javac/lambda/TargetType02.out ! test/tools/javac/lambda/TargetType10.java - test/tools/javac/lambda/TargetType10.out ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType24.java ! test/tools/javac/lambda/TargetType24.out ! test/tools/javac/lambda/TargetType26.out ! test/tools/javac/lambda/TargetType27.out ! test/tools/javac/lambda/TargetType39.out ! test/tools/javac/lambda/TargetType43.out ! test/tools/javac/lambda/TargetType66.java ! test/tools/javac/lambda/TargetType66.out ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java - test/tools/javac/lambda/typeInference/InferenceTest5.java + test/tools/javac/lambda/typeInference/InferenceTest6.java ! test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out - test/tools/javac/lambda/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.out ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java From david.holmes at oracle.com Mon Sep 2 23:23:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Sep 2013 09:23:26 +1000 Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates In-Reply-To: <5224B736.20703@oracle.com> References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> <52202FA8.1010405@oracle.com> <71E57086-0BAF-41D6-BB1E-6815DC3FF922@oracle.com> <5224B736.20703@oracle.com> Message-ID: <52251DEE.7050402@oracle.com> On 3/09/2013 2:05 AM, Alan Bateman wrote: > On 30/08/2013 21:30, Mike Duigou wrote: >> : >> Did you see David Holmes' suggestion? Do you think it's adequate? I >> agree about the maintainability aspect as I really felt guilty >> re-creating FILES_JAVA.gmk... > Sorry Mike, I somehow missed your reply on this topic. Do you mean > reorganizing the tests, say to move the collection tests down a level? I I think he meant my suggesting on how to define the groups without needing to list everything that comprises "other". David > don't see a problem with that except that moving tests around can be > mildly disruptive, bugs tracking test failures for example. > > -Alan From david.holmes at oracle.com Tue Sep 3 03:02:58 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Sep 2013 13:02:58 +1000 Subject: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo Message-ID: <52255162.9010907@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8024140/webrev/ Similar to what was recently done on the hotspot side, this introduces profile-based test groups for the jdk regression tests. The primary groups are: - jdk - jre - compact3 - compact2 - compact2_minimal - compact1 - compact1_minimal The minimal VM is only supported on compact1 and compact2. The groups are defined hierarchically in two forms: - The need_xxx groups list all the tests that have a dependency on a specific profile. This is either because it tests a feature in that profile, or the test infrastructure uses a feature in that profile. - The primary groups are defined in terms of the other primary groups combined with the needs_xxx groups (including and excluding them as appropriate). For example the jre can run all tests from compact3, plus those from needs_jre, but excluding those from need_jdk. The bottom group defines all the actual tests to be considered, simply by listing the top-level test directories, and then excluding all the needs_xxx groups. To select a group of tests you use : Eg to run only those tests that can run on compact1 use: jtreg :compact1 Of course you still need to point jtreg at the right kind of runtime image (and give it a full JDK as the compile-jdk!); and if testing the minimal VM you need to tell jtreg to select it using -javaoptions:-minimal These top-level groups are not as useful standalone as they are for hotspot due to the fact that there are so many regression tests that are problematic in one way or another. In most cases what is desired is a way to run sub-set of tests for a given profile eg all jdk_core tests that can run on compact1. At present this would require a new group to be defined for each permutation and that is not scalable. I hope that in the near future jtreg will allow you to implicitly define such ad-hoc groups via the command-line, simply by listing groups to include and groups to exclude. The full jtreg group facility is only available in the most recent jtreg builds, so you will need to grab the latest nightly build, or latest sources. Note: once this is in place, anyone writing regression tests will need to be aware of whether that test is limited to certain profiles and update the group file accordingly. Sometimes it is not the item being tested that determines the minimum needed profile, but the test infrastructure eg if it uses XML. See TEST.groups for more information. Note: The initial group definitions proposed here are not complete. There are over 4000 tests of the "desktop" that can not be readily executed manually and it may be that a number of these tests will require a JDK rather than the full JRE. Our full test processes will discover this and update the lists as needed. (Or we fix the tests to not need full JDKs.) Thanks, David From mandy.chung at oracle.com Tue Sep 3 03:04:14 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 02 Sep 2013 20:04:14 -0700 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: References: Message-ID: <522551AE.7060000@oracle.com> Hi Nick, Thanks for the patch. JEP 176 [1] describes the caller-sensitive method and the need for a mechanical checking of caller-sensitive methods. Also Peter Levart in [2] explained the change in MethodHandles.Lookup related to @CS. I assume you understand the rationale behind and the potential security issues. In general defining caller-sensitive API is discouraged. Defining a SE supported @CallerSensitive and also getCallerClass API poses the risk of "encouraging" developers to implement more @CS methods while not fully understand its implication. It was a non-goal of JEP 176 to provide @CallerSensitive as a public API and I would suggest not to define it as a public API in JDK 8. While I'll take the time to look at your patch, I would like to restart the discussion from the use cases (in which led to what you summarized the need of your proposed API [3]): 1. Groovy 1.x and 2.x use the sun.reflect.Reflection.getCallerClass(int depth) method to: * emulates the way ResourceBundle.getBundle(String, Locale) works. Groovy runtime introduces intermediary stack frame between a caller and the call to getBundle, these frames needs to be filtered out; when looking for the caller classloader. * support the annotation @Grab, @Grab allows to specify a dependency between a code and a module (using apache ivy under the hood). The resolution is done at runtime and require a specific Classloader (the GroovyClassLoader), getCallerClass is used to find the class loader of the caller, again filtering out the intermediary stack frame. Groovy 3.x has a different implementation that doesn't need to do stack walk to filter its runtime frames and find the caller. 2. Log4j Log4j offers "extended stack trace" patterns that requires access to a Class object when exceptions or stack traces are logged to provide additional information for troubleshooting such as the implementation version of the Package, code source, etc. It currently uses the sun.reflect.Reflection.getCallerClass(int depth) method to find the Class object matching the StackTraceElement in a Throwable or stack trace. If the sun.reflect.Reflection.getCallerClass(int depth) method doesn't exist, it will use SecurityManager.getClassContext(). This approach is not reliable since the HotSpot implementation of getCallerClass filters out the frames corresponding to reflection machinery (its intent is to find the true caller) whereas a stack trace contains all Java frames up to MaxJavaStackTraceDepth (default is 1024). When there is no Class object matching a StackTraceElement, it will fall back and load the class (does Log4j know which class loader to use?) Log4j currently works in the absence of the sun.reflect.Reflection.getCallerClass(int depth) method but performance is a very major issue. 3. APIs on behalf of the caller For example, locating a resource on behalf of the caller class to avoid explicit additional Class and/or ClassLoader parameters. Please correct/add if I miss anything. More will be discussed tomorrow. Mandy [1] http://openjdk.java.net/jeps/176 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019397.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html On 9/1/2013 1:16 AM, Nick Williams wrote: > I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). > > I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. > > *Summary of Changes* > Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: > > Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. > > Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. > > StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. > > StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. > > StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. > > StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. > > As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. > > I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. > > However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). > > Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. > > I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! > > *The Code Changes* > I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): > > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch > > I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. > > Thanks! > > Nick From bradford.wetmore at oracle.com Tue Sep 3 05:14:47 2013 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 02 Sep 2013 22:14:47 -0700 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) Message-ID: <52257047.3090503@oracle.com> Sorry, I haven't been following the Random discussions until now, I haven't been subscribed to core-lib-dev in a while. I was specifically asked to comment on Brian's proposed change. Paul pointed out something Bill Pugh wrote: > Right, see here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/009176.html > > "I spent some time looking at the implementation of SecureRandom and > of sun.security.provider.NativePRNG. The implementation of NativePRNG > uses a static singleton to perform all of the work, so that looked > like the concurrency bottleneck. But when I rewrote that class, it > turns out that even removing all of the Java level concurrency > bottlenecks, we still can't generate concurrent secure random > numbers, because the NativePRNG reads /dev/urandom for each byte, and > that is inherently sequential and is the bottleneck to the entire > process of generating secure random numbers." What Bill Pugh wrote is correct for NativePRNG. "new SecureRandom()" chooses its implementation based on the most preferred provider. Different OS's have different preferred implementations: Solaris (x86/sparc): PKCS11 (from the SunPKCS11 provider) Linux: NativePRNG MacOS: NativePRNG Windows: SHA1PRNG PKCS11 probably has a similar OS bottleneck. SHA1PRNG doesn't go to native MSCAPI after the initial seeding of the class, so on windows you would just have Java level contention. A bit of background: SHA1PRNG is the only implementation that is available on all platforms. How the class is initially seeded depends on some additional steps not mentioned in the threads I've seen to date (getSystemEntropy), and NativeSeedGenerators from the underlying OS: src/share/classes/sun/security/provider/SecureRandom.java src/share/classes/sun/security/provider/SeedGenerator.java src/*/classes/sun/security/provder/NativeSeedGenerator.java Bill also wrote in that email: > add the following method to BigInteger > public boolean isProbablePrime(int certainty, Random end) , > which allows primality testing with arbitrary Random objects. > In many cases, using a well seeded normal Random object will work > just fine, and this will give users the ability to provide their own > Random objects This sounds like a very good solution to me. That way someone can decide whether they want to take the hit with SecureRandom, or if Random is good enough. Paul Sandoz wrote: > I don't know about the PRNG requirements for Miller-Rabin but the > changes to TLR in review might be a possible substitute for SR in > this case, since TLR will be updated to use the same PRNG algorithm > as SplittableRandom, which passes DieHarder tests. Otherwise, i > think we may just be stuck with SR. In my brief read of the Miller-Rabin tests, it just selects several random values to use for guessing whether another number selected by a different random number generator is prime or not. Given initial seed values (i.e. one not set via new Random(seed) constructor), manipulating the Random implementation to ensure a steady stream of strong liars seems rather difficult. In addition we run a secondary test which reduces that attack surface (LucasLehmer). So offhand, I wouldn't commit to saying if SecureRandom is necessary or not, but it wouldn't surprise me. But I think Bill's suggestion is worth pursuing. Various comments: Paul Sandoz wrote: > Perhaps it would also allow us to deprecate Random in a future JDK? SecureRandom is a subclass of Random, so I'm wondering how it will be perceived to have the "secure" version based on a deprecated base class. I know the underlying implementations are *COMPLETELY* different, but I've been working with this code for a while now. > Perhaps there could be factory methods to obtain a PRNG based on > generator properties rather than picking a specific class. There is an RFE for something like that (similar to SecureRandom.getInstance()), but I can't find it at the moment. Martin Buchholz wrote: > full support for a variety of generators and distributions is a > career path) Yes, I'm hoping to add some more crypto PRNGs, ala NIST Special Publication 800-90A in JDK 9. Brad From ralph.goers at dslextreme.com Tue Sep 3 05:48:47 2013 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Mon, 2 Sep 2013 22:48:47 -0700 Subject: Replacement of sun.reflect.Reflection#getCallerClass Message-ID: <852C0BFF-2B88-4A7D-93FA-4CEAF50382AD@dslextreme.com> I just subscribed so I apologize that this message is probably not going to be threaded properly. It seems mailman has no way for me to retrieve a message. I'd like to add a couple points to what you have below: 1. In addition to Log4j, Logback has been adding this same information to the stack traces it prints for years. [1] 2. Log4j also uses getCallerClass to determine the caller of the getLogger method so that the Logger can be associated with the LoggerContext associated with that classes ClassLoader. See [2] for a description of the problem and [3] for how Log4j is handling it. Ralph [1] https://github.com/qos-ch/logback/blob/master/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java [2] http://logback.qos.ch/manual/loggingSeparation.html#tamingStaticRefs [3] https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/log4j-core/src/main/java/org/apache/logging/log4j/core/selector/ClassLoaderContextSelector.java Mandy Chung mandy.chung at oracle.com Mon Sep 2 20:04:14 PDT 2013 Previous message: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 Next message: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi Nick, Thanks for the patch. JEP 176 [1] describes the caller-sensitive method and the need for a mechanical checking of caller-sensitive methods. Also Peter Levart in [2] explained the change in MethodHandles.Lookup related to @CS. I assume you understand the rationale behind and the potential security issues. In general defining caller-sensitive API is discouraged. Defining a SE supported @CallerSensitive and also getCallerClass API poses the risk of "encouraging" developers to implement more @CS methods while not fully understand its implication. It was a non-goal of JEP 176 to provide @CallerSensitive as a public API and I would suggest not to define it as a public API in JDK 8. While I'll take the time to look at your patch, I would like to restart the discussion from the use cases (in which led to what you summarized the need of your proposed API [3]): 1. Groovy 1.x and 2.x use the sun.reflect.Reflection.getCallerClass(int depth) method to: * emulates the way ResourceBundle.getBundle(String, Locale) works. Groovy runtime introduces intermediary stack frame between a caller and the call to getBundle, these frames needs to be filtered out; when looking for the caller classloader. * support the annotation @Grab, @Grab allows to specify a dependency between a code and a module (using apache ivy under the hood). The resolution is done at runtime and require a specific Classloader (the GroovyClassLoader), getCallerClass is used to find the class loader of the caller, again filtering out the intermediary stack frame. Groovy 3.x has a different implementation that doesn't need to do stack walk to filter its runtime frames and find the caller. 2. Log4j Log4j offers "extended stack trace" patterns that requires access to a Class object when exceptions or stack traces are logged to provide additional information for troubleshooting such as the implementation version of the Package, code source, etc. It currently uses the sun.reflect.Reflection.getCallerClass(int depth) method to find the Class object matching the StackTraceElement in a Throwable or stack trace. If the sun.reflect.Reflection.getCallerClass(int depth) method doesn't exist, it will use SecurityManager.getClassContext(). This approach is not reliable since the HotSpot implementation of getCallerClass filters out the frames corresponding to reflection machinery (its intent is to find the true caller) whereas a stack trace contains all Java frames up to MaxJavaStackTraceDepth (default is 1024). When there is no Class object matching a StackTraceElement, it will fall back and load the class (does Log4j know which class loader to use?) Log4j currently works in the absence of the sun.reflect.Reflection.getCallerClass(int depth) method but performance is a very major issue. 3. APIs on behalf of the caller For example, locating a resource on behalf of the caller class to avoid explicit additional Class and/or ClassLoader parameters. Please correct/add if I miss anything. More will be discussed tomorrow. Mandy [1] http://openjdk.java.net/jeps/176 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019397.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html From chris.hegarty at oracle.com Tue Sep 3 07:25:22 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 Sep 2013 08:25:22 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <52250A0C.7000409@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224EFF0.4030405@oracle.com> <52250A0C.7000409@oracle.com> Message-ID: <7E7C8F10-16F9-4DB6-9473-0AFB35A769AE@oracle.com> On 2 Sep 2013, at 22:58, Se?n Coffey wrote: > Some minor modification (and further simplifying of conditions) : > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ Looks good to me. -Chris. > > regards, > Sean. > > On 02/09/13 21:07, Alan Bateman wrote: >> On 02/09/2013 19:06, Se?n Coffey wrote: >>> This might be a slightly easier one to read. (fast path logic code first) >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ >> This is nicer (and I see Chris has already pointed out the redundant check). >> >> -Alan > From Alan.Bateman at oracle.com Tue Sep 3 07:55:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 08:55:43 +0100 Subject: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo In-Reply-To: <52255162.9010907@oracle.com> References: <52255162.9010907@oracle.com> Message-ID: <522595FF.3070709@oracle.com> On 03/09/2013 04:02, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/8024140/webrev/ > > : > > Note: once this is in place, anyone writing regression tests will need > to be aware of whether that test is limited to certain profiles and > update the group file accordingly. Sometimes it is not the item being > tested that determines the minimum needed profile, but the test > infrastructure eg if it uses XML. > I don't think this is very maintainable and I don't think we should force everyone that adds/changes tests to have to also maintain this file. In general I worry that this approach will just not scale when we move to modules. That said, I know you are under short term pressure to put in a solution to allow the profiles be tested. So my view is that we should start looking for a replacement to this as soon as we can. In the mean-time then I think we have to assume that it will get out of sync periodically and maybe it's possible to provide tooling (maybe based on jdeps) that would help keep it up to date. As regards the definitions then one observation is the TestNG tests that you've listed in needs_compact2 are actually compact1 tests. I wonder if this is a TestNG dependency on XML rather than dependencies in the test themselves. You've listed most of the tests in sun/nio/cs in needs_charsets and I wonder whether it would be simpler to just move these to sun/nio/cs/ext. We've already moved several tests (the ftp tests for example) in preparation for profiles and maybe this is an option here. I see that needs_jre includes jdk_jdi but JDI is not in the JRE. Is it possible that you are testing JDI in the compile JDK here? -Alan. From Alan.Bateman at oracle.com Tue Sep 3 08:15:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 09:15:38 +0100 Subject: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext In-Reply-To: <52250A0C.7000409@oracle.com> References: <5224B2FF.7090904@oracle.com> <5224D3B9.1050905@oracle.com> <5224EFF0.4030405@oracle.com> <52250A0C.7000409@oracle.com> Message-ID: <52259AAA.5030807@oracle.com> On 02/09/2013 22:58, Se?n Coffey wrote: > Some minor modification (and further simplifying of conditions) : > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ This looks much better. -Alan. From blackdrag at gmx.org Tue Sep 3 08:17:23 2013 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 03 Sep 2013 10:17:23 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <522551AE.7060000@oracle.com> References: <522551AE.7060000@oracle.com> Message-ID: <52259B13.8060100@gmx.org> Am 03.09.2013 05:04, schrieb Mandy Chung: > Hi Nick, > > Thanks for the patch. > > JEP 176 [1] describes the caller-sensitive method and the need for a > mechanical checking of caller-sensitive methods. Also Peter Levart in > [2] explained the change in MethodHandles.Lookup related to @CS. I > assume you understand the rationale behind and the potential security > issues. In general defining caller-sensitive API is discouraged. The problem is, and the JDK itself shows that, that you sometimes cannot avoid caller-sensitive API. I thought that was clear by now. I am not the patch author, so understanding the potential security issues was not addressed to me, but I would like to understand them. So far I did hear only that if you have the Class object, you can do something, you normally cannot do. I would be interested in an example. Java security is really complicated to understand, and this would help to shed some light on the issue for others. Also I am wondering, if the Class object is a no-go, then how about class name and class loader? For Groovy we need the loader, but since we need to filter stack elements ourselves too, we also need the class names. A Class-object provides both, but I am sure almost all usages out there could work with the name and the loader only and if needed loading the class from the loader, with permissions set accordingly. Not sure how it is with internal class names here of course. AnonymousClassLoader would probably cause trouble here, but afaik that did not make it out of JSR292. A different way to solve the issue was suggested as using an annotation to define frames which are not looked up by getCallerClass. But it did not get any interest. So I am really curious how you want to solve this. > Defining a SE supported @CallerSensitive and also getCallerClass API > poses the risk of "encouraging" developers to implement more @CS methods > while not fully understand its implication. Again I am curious... what is such an implication? That your method will behave different depending on from where it got called and, depending on if that is from an expected or unexpected source, you may get an expected or unexpected result here? [...] > 1. Groovy 1.x and 2.x use the sun.reflect.Reflection.getCallerClass(int > depth) method to: > > * emulates the way ResourceBundle.getBundle(String, Locale) works. > Groovy runtime introduces intermediary stack frame between a caller > and the call to getBundle, these frames needs to be filtered out; > when looking for the caller classloader. > * support the annotation @Grab, @Grab allows to specify a dependency > between a code and a module (using apache ivy under the hood). The > resolution is done at runtime and require a specific Classloader > (the GroovyClassLoader), getCallerClass is used to find the class > loader of the caller, again filtering out the intermediary stack frame. > > Groovy 3.x has a different implementation that doesn't need to do stack > walk to filter its runtime frames and find the caller. To add here, I will build into Groovy 3.x the ability to transport the caller class from the Groovy class, that makes the call. So there will be no filtering and no magic caller class API at all. Still there will be several years we will have at least a Groovy 2.x out there. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From Alan.Bateman at oracle.com Tue Sep 3 08:18:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 09:18:59 +0100 Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates In-Reply-To: <52251DEE.7050402@oracle.com> References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> <52202FA8.1010405@oracle.com> <71E57086-0BAF-41D6-BB1E-6815DC3FF922@oracle.com> <5224B736.20703@oracle.com> <52251DEE.7050402@oracle.com> Message-ID: <52259B73.30609@oracle.com> On 03/09/2013 00:23, David Holmes wrote: > On 3/09/2013 2:05 AM, Alan Bateman wrote: >> On 30/08/2013 21:30, Mike Duigou wrote: >>> : >>> Did you see David Holmes' suggestion? Do you think it's adequate? I >>> agree about the maintainability aspect as I really felt guilty >>> re-creating FILES_JAVA.gmk... >> Sorry Mike, I somehow missed your reply on this topic. Do you mean >> reorganizing the tests, say to move the collection tests down a level? I > > I think he meant my suggesting on how to define the groups without > needing to list everything that comprises "other". > That form of composition is fine, it's defining the contents of jdk_collections that I'm concerned about. -Alan From paul.sandoz at oracle.com Tue Sep 3 08:21:25 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Sep 2013 10:21:25 +0200 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: <52257047.3090503@oracle.com> References: <52257047.3090503@oracle.com> Message-ID: <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> On Sep 3, 2013, at 7:14 AM, Bradford Wetmore wrote: > Bill also wrote in that email: > > > add the following method to BigInteger > > public boolean isProbablePrime(int certainty, Random end) , > > which allows primality testing with arbitrary Random objects. > > In many cases, using a well seeded normal Random object will work > > just fine, and this will give users the ability to provide their own > > Random objects > > This sounds like a very good solution to me. That way someone can decide whether they want to take the hit with SecureRandom, or if Random is good enough. > Yes. > Paul Sandoz wrote: > > > I don't know about the PRNG requirements for Miller-Rabin but the > > changes to TLR in review might be a possible substitute for SR in > > this case, since TLR will be updated to use the same PRNG algorithm > > as SplittableRandom, which passes DieHarder tests. Otherwise, i > > think we may just be stuck with SR. > > In my brief read of the Miller-Rabin tests, it just selects several random values to use for guessing whether another number selected by a different random number generator is prime or not. Given initial seed values (i.e. one not set via new Random(seed) constructor), manipulating the Random implementation to ensure a steady stream of strong liars seems rather difficult. > > In addition we run a secondary test which reduces that attack surface (LucasLehmer). > > So offhand, I wouldn't commit to saying if SecureRandom is necessary or not, but it wouldn't surprise me. > My intuition is that the new algorithm for TLR might be sufficient as input to this Monte-Carlo algorithm, but i don't have any hard empirical data. > Paul Sandoz wrote: > > > Perhaps it would also allow us to deprecate Random in a future JDK? > > SecureRandom is a subclass of Random, so I'm wondering how it will be perceived to have the "secure" version based on a deprecated base class. Yeah there is a PR thing that would have to be managed :-) Paul. > I know the underlying implementations are *COMPLETELY* different, but I've been working with this code for a while now. > From david.holmes at oracle.com Tue Sep 3 08:26:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Sep 2013 18:26:33 +1000 Subject: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo In-Reply-To: <522595FF.3070709@oracle.com> References: <52255162.9010907@oracle.com> <522595FF.3070709@oracle.com> Message-ID: <52259D39.6090906@oracle.com> Hi Alan, On 3/09/2013 5:55 PM, Alan Bateman wrote: > On 03/09/2013 04:02, David Holmes wrote: >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/8024140/webrev/ >> >> : >> >> Note: once this is in place, anyone writing regression tests will need >> to be aware of whether that test is limited to certain profiles and >> update the group file accordingly. Sometimes it is not the item being >> tested that determines the minimum needed profile, but the test >> infrastructure eg if it uses XML. >> > I don't think this is very maintainable and I don't think we should > force everyone that adds/changes tests to have to also maintain this > file. In general I worry that this approach will just not scale when we > move to modules. That said, I know you are under short term pressure to > put in a solution to allow the profiles be tested. As I've said elsewhere, but for the public record I will repeat, whatever mechanism we use anyone writing regression tests has to start thinking about what dependencies their test has. Then they have to record those dependencies somewhere. While tagging a single test in the future seems fine, it is not fine to have to tag a few thousand tests initially. Conversely having to potentially edit one line in the groups file hardly seems burdensome. But perhaps down the track we can use the group definitions as input to a tool that will auto-tag the tests - if/when a complete tagging scheme is devised. As for the move to modules ... I think that is a whole new ball game. > So my view is that we should start looking for a replacement to this as > soon as we can. In the mean-time then I think we have to assume that it > will get out of sync periodically and maybe it's possible to provide > tooling (maybe based on jdeps) that would help keep it up to date. Tooling/automation would of course be good, I just don't see the pieces in place as yet. > As regards the definitions then one observation is the TestNG tests that > you've listed in needs_compact2 are actually compact1 tests. I wonder if > this is a TestNG dependency on XML rather than dependencies in the test > themselves. Yes. As noted in the file the dependencies are not only what is being tested but what test infrastructure is being used. The testng tests uses xml which restricts them to compact2. Some tests use jps/jcmd or tools.jar which restricts them to a full jdk. > You've listed most of the tests in sun/nio/cs in needs_charsets and I > wonder whether it would be simpler to just move these to sun/nio/cs/ext. > We've already moved several tests (the ftp tests for example) in > preparation for profiles and maybe this is an option here. That is up to the nio-dev folk but I certainly wouldn't object! I was contemplating simply adding sun/nio/cs to needs_charsets, which would artificially restrict some of those tests, but simplify the expression. There are 67 tests, of which 41 actually need charsets.jar. > I see that needs_jre includes jdk_jdi but JDI is not in the JRE. Is it > possible that you are testing JDI in the compile JDK here? Thanks! - that's a simple oversight on my part. Fixed. Thanks for the review. David > -Alan. > > > From paul.sandoz at oracle.com Tue Sep 3 09:03:05 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Sep 2013 11:03:05 +0200 Subject: RFR: 8021591 : (s) Additional explicit null checks In-Reply-To: <74270D6C-72EE-4768-98CB-B74E79952C1F@oracle.com> References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> <74270D6C-72EE-4768-98CB-B74E79952C1F@oracle.com> Message-ID: <0FF66111-33CD-49C5-89BE-3C2F7F523410@oracle.com> On Aug 28, 2013, at 12:56 AM, Mike Duigou wrote: > Hello all; > > Here's an updated version of the patch which incorporates feedback and improves the tests (the reason for delay): > > http://cr.openjdk.java.net/~mduigou/JDK-8021591/1/webrev/ > > The substance of the patch is largely to add missing checks that the collection provided to removeAll()/retainAll() is not null. The specification of these methods in the Collection interface has always indicated that an NPE should be thrown if the passed collection was null. Historically various implementations were inconsistent about whether they threw the NPE if a null collection was passed. Some collections would throw the NPE, some would not. The intent of this patch is to improve consistency and since there were examples of the NPE being correctly thrown the most prudent approach seems to have all implementations throw the NPE. If there had been no examples of the NPE being thrown then it would have been more prudent to amend the interface spec to remove the NPE notice. > > A few other inconsistencies around null handling were also resolved. Some unit tests issues were also cleaned up. > Looks OK. If you have the will I bet you could transform the following pattern repeated in many tests: @Test public void testForEach() throws Exception { CollectionSupplier> supplier = new CollectionSupplier((Supplier>[]) TEST_CLASSES, SIZE); for (final CollectionSupplier.TestCase> test : supplier.get()) { ... } to: @DataProvider(name="CollectionSupplier") private static Iterator>> CollectionSupplierDataProvider() { CollectionSupplier> supplier = new CollectionSupplier((Supplier>[]) TEST_CLASSES, SIZE); return supplier.get(); } @Test(dataProvider = "CollectionSupplier") public void testForEach(CollectionSupplier.TestCase> test) throws Exception { Paul. From forax at univ-mlv.fr Tue Sep 3 09:04:07 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 03 Sep 2013 11:04:07 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <52259B13.8060100@gmx.org> References: <522551AE.7060000@oracle.com> <52259B13.8060100@gmx.org> Message-ID: <5225A607.7080909@univ-mlv.fr> On 09/03/2013 10:17 AM, Jochen Theodorou wrote: > Am 03.09.2013 05:04, schrieb Mandy Chung: >> Hi Nick, >> >> Thanks for the patch. >> >> JEP 176 [1] describes the caller-sensitive method and the need for a >> mechanical checking of caller-sensitive methods. Also Peter Levart in >> [2] explained the change in MethodHandles.Lookup related to @CS. I >> assume you understand the rationale behind and the potential security >> issues. In general defining caller-sensitive API is discouraged. > > The problem is, and the JDK itself shows that, that you sometimes > cannot avoid caller-sensitive API. I thought that was clear by now. I > am not the patch author, so understanding the potential security > issues was not addressed to me, but I would like to understand them. > So far I did hear only that if you have the Class object, you can do > something, you normally cannot do. I would be interested in an > example. Java security is really complicated to understand, and this > would help to shed some light on the issue for others. Also I am > wondering, if the Class object is a no-go, then how about class name > and class loader? For Groovy we need the loader, but since we need to > filter stack elements ourselves too, we also need the class names. A > Class-object provides both, but I am sure almost all usages out there > could work with the name and the loader only and if needed loading the > class from the loader, with permissions set accordingly. Not sure how > it is with internal class names here of course. AnonymousClassLoader > would probably cause trouble here, but afaik that did not make it out > of JSR292. > > A different way to solve the issue was suggested as using an > annotation to define frames which are not looked up by getCallerClass. > But it did not get any interest. So I am really curious how you want > to solve this. I think there are two different things, first, there are several methods in the JDK that allows operations or not (like calling a method by example) based on the caller class. So if you can impersonate the caller class, you can do privilege escalation. The fact that the method that does a security check based on the caller class (or the caller stack trace) has to be tagged using @CallerSensitive for the method handle API is an implementation detail. The current implementation of the method handle API invocation in Hotspot may used intermediary stack frame between the method call do a methodHandle.invoke/invokeEaxct and the actual called method. If the actual method do a security check using the caller class, it may see an intermediary method and not the original caller method so if you are not able to detect the caller sensitive method, you can use the method handle API to do privilege escalation. That's why in the JDK, methods that are caller sensitive are marked with the annotation @CallerSensitive. Again, this is an implementation issue specific to the way the method handles are implemented, so that's why @CallerSensitive is defined in package sun.invoke and not in a public API. Now, correct me if I'm wrong, for Groovy, you need to get the groovy caller method, (it can be a Java method because you can implement a callback in Groovy and send it to a Java code) so you should not use getCallerClass which should be reserved for security checks but another method that will return the caller method (or caller methods) that will filter out and the intermediary methods due to the method handle implementation and the intermediary methods due to the Groovy runtime (those can be marked with an annotations). So there is a need for an API to get the caller classes which is not getCallerClass (or any methods in a package sun.*) that will hide you the method handle API impementation and allow you choose to filter caller methods using a user defined API. [...] > bye Jochen > cheers, R?mi From Alan.Bateman at oracle.com Tue Sep 3 09:07:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 10:07:31 +0100 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> <522498F2.6050001@oracle.com> <5224A99D.2040708@univ-mlv.fr> <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> Message-ID: <5225A6D3.509@oracle.com> On 02/09/2013 18:45, Nick Williams wrote: > : > > I didn't decide to ignore the security concerns, I just don't see any security concerns. As has been /clearly/ established in the last three months, frameworks have been using getCallerClass for years, if not a decade. It has never caused a security problem. Ever. If I'm wrong, please point out to me a specific vulnerability that this has led to. I am not allowed to discuss any details about vulnerabilities here. However, as a general point then caller sensitive methods have been highly problematic in the JDK. As regards frameworks using sun.reflect.Reflection.getCallerClass directly then it's as I said previously, they are probably not run with a security manager very often (at least not unless the policy is configured to allow direct access to sun.*). > > I don't have the ability to go back and start from the beginning on something that I had the understanding was generally agreed upon before I started. You've done good work and no one is suggesting you throw it again. However I don't recall any agreement on a solution, rather the discussion mostly fizzled out. In particular I do not recall any discussions about changing the goals of JEP 176 and make @CS a public API. Whatever about @CS methods being a bad there is also the issue of annotations changing runtime behavior. I see Mandy has restarted the discussion on use-cases (thank you Mandy) and working through these and addressing a subset initially might be good way to move this forward. More so as this is your first patch/contribution to OpenJDK - a first patch does not have to solve world peace, starting out with smaller changes is good. > : > > I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API. -Alan. From Alan.Bateman at oracle.com Tue Sep 3 09:13:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 10:13:39 +0100 Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black) In-Reply-To: <09C37AD7-3D75-46DB-8258-B1B911ECDB8D@oracle.com> References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com> <83BF5EA9-9D8C-48FC-B539-B6579DB7E12F@oracle.com> <09C37AD7-3D75-46DB-8258-B1B911ECDB8D@oracle.com> Message-ID: <5225A843.90807@oracle.com> On 02/09/2013 15:12, Paul Sandoz wrote: > FYI: this has been soaking in the lambda repo for over a weak now. AFAICT there have been no issues. > > Paul. > If you can pull into a clone of jdk8/tl, run the tests to make sure that all is okay then I think we should just get it in. -Alan. From chris.hegarty at oracle.com Tue Sep 3 09:22:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 03 Sep 2013 10:22:14 +0100 Subject: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo In-Reply-To: <52255162.9010907@oracle.com> References: <52255162.9010907@oracle.com> Message-ID: <5225AA46.2080200@oracle.com> David, I share Alan's concerns about the maintainability of this, but I don't have a better answer ( without much reorganizing/tagging ). Out of interest, how did you come up with the lists? For example, java/net/URLClassLoader/closetest/GetResourceAsStream.java is in needs_jdk. I presume because of a dependency on javac. The test could be trivially changed to remove this dependency ( I don't expect you to have the time to do this for all tests ). Maybe, over time, with some socializing of these find of issues, enough tests can be changed/moved to greatly reduce the number of specific tests explicitly listed in these groups. I resolved some of the ftp issues Alan referred to, a while back, and I guess this helped reduce the need to have a few more specific tests listed in needs_jdk. This really seems like a task for the actual component teams, with higher level guidance. Once this gets in I'll take a look to see if it is possible to remove some of the obvious networking tests. What is the recommended test cycle to verify that all this is working well after making changes? -Chris. On 09/03/2013 04:02 AM, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/8024140/webrev/ > > Similar to what was recently done on the hotspot side, this introduces > profile-based test groups for the jdk regression tests. > > The primary groups are: > - jdk > - jre > - compact3 > - compact2 > - compact2_minimal > - compact1 > - compact1_minimal > > The minimal VM is only supported on compact1 and compact2. > > The groups are defined hierarchically in two forms: > - The need_xxx groups list all the tests that have a dependency on a > specific profile. This is either because it tests a feature in that > profile, or the test infrastructure uses a feature in that profile. > - The primary groups are defined in terms of the other primary groups > combined with the needs_xxx groups (including and excluding them as > appropriate). For example the jre can run all tests from compact3, plus > those from needs_jre, but excluding those from need_jdk. > > The bottom group defines all the actual tests to be considered, simply > by listing the top-level test directories, and then excluding all the > needs_xxx groups. > > To select a group of tests you use : > > Eg to run only those tests that can run on compact1 use: > > jtreg :compact1 > > Of course you still need to point jtreg at the right kind of runtime > image (and give it a full JDK as the compile-jdk!); and if testing the > minimal VM you need to tell jtreg to select it using -javaoptions:-minimal > > These top-level groups are not as useful standalone as they are for > hotspot due to the fact that there are so many regression tests that are > problematic in one way or another. In most cases what is desired is a > way to run sub-set of tests for a given profile eg all jdk_core tests > that can run on compact1. At present this would require a new group to > be defined for each permutation and that is not scalable. I hope that in > the near future jtreg will allow you to implicitly define such ad-hoc > groups via the command-line, simply by listing groups to include and > groups to exclude. > > The full jtreg group facility is only available in the most recent jtreg > builds, so you will need to grab the latest nightly build, or latest > sources. > > Note: once this is in place, anyone writing regression tests will need > to be aware of whether that test is limited to certain profiles and > update the group file accordingly. Sometimes it is not the item being > tested that determines the minimum needed profile, but the test > infrastructure eg if it uses XML. > > See TEST.groups for more information. > > Note: The initial group definitions proposed here are not complete. > There are over 4000 tests of the "desktop" that can not be readily > executed manually and it may be that a number of these tests will > require a JDK rather than the full JRE. Our full test processes will > discover this and update the lists as needed. (Or we fix the tests to > not need full JDKs.) > > Thanks, > David From forax at univ-mlv.fr Tue Sep 3 09:46:32 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 03 Sep 2013 11:46:32 +0200 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <5225A6D3.509@oracle.com> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> <522498F2.6050001@oracle.com> <5224A99D.2040708@univ-mlv.fr> <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> <5225A6D3.509@oracle.com> Message-ID: <5225AFF8.5090607@univ-mlv.fr> On 09/03/2013 11:07 AM, Alan Bateman wrote: > On 02/09/2013 18:45, Nick Williams wrote: >> : >> >> I didn't decide to ignore the security concerns, I just don't see any >> security concerns. As has been /clearly/ established in the last >> three months, frameworks have been using getCallerClass for years, if >> not a decade. It has never caused a security problem. Ever. If I'm >> wrong, please point out to me a specific vulnerability that this has >> led to. > I am not allowed to discuss any details about vulnerabilities here. > However, as a general point then caller sensitive methods have been > highly problematic in the JDK. > > As regards frameworks using sun.reflect.Reflection.getCallerClass > directly then it's as I said previously, they are probably not run > with a security manager very often (at least not unless the policy is > configured to allow direct access to sun.*). > >> >> I don't have the ability to go back and start from the beginning on >> something that I had the understanding was generally agreed upon >> before I started. > You've done good work and no one is suggesting you throw it again. > However I don't recall any agreement on a solution, rather the > discussion mostly fizzled out. In particular I do not recall any > discussions about changing the goals of JEP 176 and make @CS a public > API. Whatever about @CS methods being a bad there is also the issue of > annotations changing runtime behavior. > > I see Mandy has restarted the discussion on use-cases (thank you > Mandy) and working through these and addressing a subset initially > might be good way to move this forward. More so as this is your first > patch/contribution to OpenJDK - a first patch does not have to solve > world peace, starting out with smaller changes is good. One fix that is very interresting IMO is to fix the way the stacktrace is created in Throwable. It will not solve the world peace but in the same time it will speedup all programs that create a stacktrace, not that bad too. > >> : >> >> I'm not voicing any objection to any kind of security/permissions >> checks in these methods. Before I can pass judgement one way or >> another, I'd want to know 1) specifically what type of permissions >> check you are looking for, and 2) what you're looking to achieve with >> said permissions check. > I would say this is TBD and start by asking the question as to whether > there are concerns about leaking reference to Class objects that > untrusted code wouldn't normally be able to get a reference to. Tom > brings up the cost of the permission check and also whether any API > should be tied to class loader. There are clearly discussion points > here that could potentially influence the API. > > -Alan. > > R?mi From sean.coffey at oracle.com Tue Sep 3 09:49:52 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 03 Sep 2013 10:49:52 +0100 Subject: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\' Message-ID: <5225B0C0.1020301@oracle.com> Bug report not public at moment. (should appear shortly) Issue with wsimport tool. Use of jar files created from wsimport on windows don't work on unix systems. Portability issue. Simple fix. wsimport testcase to accompany it. http://cr.openjdk.java.net/~coffeys/webrev.8016271/ regards, Sean. From david.holmes at oracle.com Tue Sep 3 09:50:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Sep 2013 19:50:42 +1000 Subject: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo In-Reply-To: <5225AA46.2080200@oracle.com> References: <52255162.9010907@oracle.com> <5225AA46.2080200@oracle.com> Message-ID: <5225B0F2.8010505@oracle.com> On 3/09/2013 7:22 PM, Chris Hegarty wrote: > David, > > I share Alan's concerns about the maintainability of this, but I don't > have a better answer ( without much reorganizing/tagging ). > > Out of interest, how did you come up with the lists? For example, > java/net/URLClassLoader/closetest/GetResourceAsStream.java is in > needs_jdk. I presume because of a dependency on javac. The test could be > trivially changed to remove this dependency ( I don't expect you to have > the time to do this for all tests ). Maybe, over time, with some > socializing of these find of issues, enough tests can be changed/moved > to greatly reduce the number of specific tests explicitly listed in > these groups. I came up with the lists by starting with a division based around the profiles API and then running all the tests. I then had to examine all the failures and determine why they failed. Fortunately the bulk of these fell into two camps: - NoClassDefFoundError - exit code 1 The former are self-identifying with regards to the API dependency. The latter invariably meant a tool (javac, jps, jcmd etc) was being executed using the test-jdk. It was a laborious process. I think most of the incidental needs_jdk tests really just need to be changed to use tools from the compile-jdk. But that is certainly an issue for the component teams. > I resolved some of the ftp issues Alan referred to, a while back, and I > guess this helped reduce the need to have a few more specific tests > listed in needs_jdk. This really seems like a task for the actual > component teams, with higher level guidance. > > Once this gets in I'll take a look to see if it is possible to remove > some of the obvious networking tests. What is the recommended test cycle > to verify that all this is working well after making changes? That's part of the problem here. We don't build profiles as part of the promotion builds so there are no binaries for anyone to simply point to. I did my own profile builds, and added the minimal VM, to be able to test things. Using "javac -profile xxx" can be of use in determining an API dependency. Thanks, David > -Chris. > > On 09/03/2013 04:02 AM, David Holmes wrote: >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/8024140/webrev/ >> >> Similar to what was recently done on the hotspot side, this introduces >> profile-based test groups for the jdk regression tests. >> >> The primary groups are: >> - jdk >> - jre >> - compact3 >> - compact2 >> - compact2_minimal >> - compact1 >> - compact1_minimal >> >> The minimal VM is only supported on compact1 and compact2. >> >> The groups are defined hierarchically in two forms: >> - The need_xxx groups list all the tests that have a dependency on a >> specific profile. This is either because it tests a feature in that >> profile, or the test infrastructure uses a feature in that profile. >> - The primary groups are defined in terms of the other primary groups >> combined with the needs_xxx groups (including and excluding them as >> appropriate). For example the jre can run all tests from compact3, plus >> those from needs_jre, but excluding those from need_jdk. >> >> The bottom group defines all the actual tests to be considered, simply >> by listing the top-level test directories, and then excluding all the >> needs_xxx groups. >> >> To select a group of tests you use : >> >> Eg to run only those tests that can run on compact1 use: >> >> jtreg :compact1 >> >> Of course you still need to point jtreg at the right kind of runtime >> image (and give it a full JDK as the compile-jdk!); and if testing the >> minimal VM you need to tell jtreg to select it using >> -javaoptions:-minimal >> >> These top-level groups are not as useful standalone as they are for >> hotspot due to the fact that there are so many regression tests that are >> problematic in one way or another. In most cases what is desired is a >> way to run sub-set of tests for a given profile eg all jdk_core tests >> that can run on compact1. At present this would require a new group to >> be defined for each permutation and that is not scalable. I hope that in >> the near future jtreg will allow you to implicitly define such ad-hoc >> groups via the command-line, simply by listing groups to include and >> groups to exclude. >> >> The full jtreg group facility is only available in the most recent jtreg >> builds, so you will need to grab the latest nightly build, or latest >> sources. >> >> Note: once this is in place, anyone writing regression tests will need >> to be aware of whether that test is limited to certain profiles and >> update the group file accordingly. Sometimes it is not the item being >> tested that determines the minimum needed profile, but the test >> infrastructure eg if it uses XML. >> >> See TEST.groups for more information. >> >> Note: The initial group definitions proposed here are not complete. >> There are over 4000 tests of the "desktop" that can not be readily >> executed manually and it may be that a number of these tests will >> require a JDK rather than the full JRE. Our full test processes will >> discover this and update the lists as needed. (Or we fix the tests to >> not need full JDKs.) >> >> Thanks, >> David From Alan.Bateman at oracle.com Tue Sep 3 10:03:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 11:03:47 +0100 Subject: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\' In-Reply-To: <5225B0C0.1020301@oracle.com> References: <5225B0C0.1020301@oracle.com> Message-ID: <5225B403.3010801@oracle.com> On 03/09/2013 10:49, Se?n Coffey wrote: > Bug report not public at moment. (should appear shortly) > > Issue with wsimport tool. Use of jar files created from wsimport on > windows don't work on unix systems. Portability issue. > Simple fix. wsimport testcase to accompany it. > > http://cr.openjdk.java.net/~coffeys/webrev.8016271/ Does this need to go into an upstream project first? As I understand it, the JAX-WS folks have an industrial blender to mix the ingredients for the jaxws repository. At one point then I think there were about 10 upstream projects to pull code from. Maybe things have changed but I just wonder if changes/patches pushed to the jaxws repository will be wiped by a re-sync from upstream. I've cc'ed martin Grebac and Miroslav Kos to comment. -Alan. From miroslav.kos at oracle.com Tue Sep 3 10:11:14 2013 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 03 Sep 2013 12:11:14 +0200 Subject: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\' In-Reply-To: <5225B403.3010801@oracle.com> References: <5225B0C0.1020301@oracle.com> <5225B403.3010801@oracle.com> Message-ID: <5225B5C2.1000704@oracle.com> Hi Alan, good catch! Yes, we need to apply the fix on our side too, otherwise it would be reverted with a new integration JAX-WS > JDK. Miran On 09/03/2013 12:03 PM, Alan Bateman wrote: > On 03/09/2013 10:49, Se?n Coffey wrote: >> Bug report not public at moment. (should appear shortly) >> >> Issue with wsimport tool. Use of jar files created from wsimport on >> windows don't work on unix systems. Portability issue. >> Simple fix. wsimport testcase to accompany it. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8016271/ > Does this need to go into an upstream project first? As I understand > it, the JAX-WS folks have an industrial blender to mix the ingredients > for the jaxws repository. At one point then I think there were about > 10 upstream projects to pull code from. Maybe things have changed but > I just wonder if changes/patches pushed to the jaxws repository will > be wiped by a re-sync from upstream. I've cc'ed martin Grebac and > Miroslav Kos to comment. > > -Alan. From sean.coffey at oracle.com Tue Sep 3 10:18:17 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 03 Sep 2013 11:18:17 +0100 Subject: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\' In-Reply-To: <5225B5C2.1000704@oracle.com> References: <5225B0C0.1020301@oracle.com> <5225B403.3010801@oracle.com> <5225B5C2.1000704@oracle.com> Message-ID: <5225B769.1020302@oracle.com> Miran, can you clarify how we get this fix in then. Will you patch into JAX-WS and port to the jdk/jaxws repo or do can we push it to both repos independently? How often does JAX-WS team sync with openJDK ? I need to get this ported to jdk7u also. regards, Sean. On 03/09/2013 11:11, Miroslav Kos wrote: > Hi Alan, > good catch! Yes, we need to apply the fix on our side too, otherwise > it would be reverted with a new integration JAX-WS > JDK. > > Miran > > > > On 09/03/2013 12:03 PM, Alan Bateman wrote: >> On 03/09/2013 10:49, Se?n Coffey wrote: >>> Bug report not public at moment. (should appear shortly) >>> >>> Issue with wsimport tool. Use of jar files created from wsimport on >>> windows don't work on unix systems. Portability issue. >>> Simple fix. wsimport testcase to accompany it. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8016271/ >> Does this need to go into an upstream project first? As I understand >> it, the JAX-WS folks have an industrial blender to mix the >> ingredients for the jaxws repository. At one point then I think there >> were about 10 upstream projects to pull code from. Maybe things have >> changed but I just wonder if changes/patches pushed to the jaxws >> repository will be wiped by a re-sync from upstream. I've cc'ed >> martin Grebac and Miroslav Kos to comment. >> >> -Alan. > From sean.coffey at oracle.com Tue Sep 3 12:04:01 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 03 Sep 2013 13:04:01 +0100 Subject: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets Message-ID: <5225D031.80008@oracle.com> Sockets created by the com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be affected by firewalls if that connection is left idle for long periods of time. (closed out). A workaround for such an issue could be to have a simple corba thread send some simple ping traffic on the socket at scheduled intervals. That may not be possible for legacy applications. Proposed solution is to add an implementation specific system property flag which would have the keepAlive feature turned on for sockets returned by the CORBA DefaultSocketFactoryImpl class. The application is then in a better position to manage the keepAlive settings via the OS. This had been fixed in Java SE 6 and I'm looking to port the new property to jdk7u & jdk8. http://cr.openjdk.java.net/~coffeys/webrev.8017195/ regards, Sean. From nicholas+openjdk at nicholaswilliams.net Tue Sep 3 12:24:39 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Tue, 3 Sep 2013 07:24:39 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <5225A6D3.509@oracle.com> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> <522498F2.6050001@oracle.com> <5224A99D.2040708@univ-mlv.fr> <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> <5225A6D3.509@oracle.com> Message-ID: <100CD7AF-FE81-4439-BFE6-5B9FB650B2B7@nicholaswilliams.net> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: > On 02/09/2013 18:45, Nick Williams wrote: >> : >> >> I didn't decide to ignore the security concerns, I just don't see any security concerns. As has been /clearly/ established in the last three months, frameworks have been using getCallerClass for years, if not a decade. It has never caused a security problem. Ever. If I'm wrong, please point out to me a specific vulnerability that this has led to. > I am not allowed to discuss any details about vulnerabilities here. Well so much for being open. > However, as a general point then caller sensitive methods have been highly problematic in the JDK. If security issues aren't allowed to be discussed in the open then how can we, the community, help address them? You say my patch has security problems. I haven't seen any detailed yet. > As regards frameworks using sun.reflect.Reflection.getCallerClass directly then it's as I said previously, they are probably not run with a security manager very often (at least not unless the policy is configured to allow direct access to sun.*). I'd argue that Logback, Log4j, and Groovy, three of the most common Java framework around, are very likely used with security managers quite often. It doesn't cause any problems because we don't misuse the information we obtain from getCallerClass. >> >> I don't have the ability to go back and start from the beginning on something that I had the understanding was generally agreed upon before I started. > You've done good work and no one is suggesting you throw it again. However I don't recall any agreement on a solution, rather the discussion mostly fizzled out. We reached a point where a few people said the API looked good, and then someone said that hands were short and "patches are welcome." I was then given guidelines for submitting a patch. Doesn't sound like fizzling out to me. > In particular I do not recall any discussions about changing the goals of JEP 176 and make @CS a public API. Whatever about @CS methods being a bad there is also the issue of annotations changing runtime behavior. If applications want to change their behavior based on the caller, let them! Is it bad practice, bad design, and likely all kinds of dumb? Heck yea. But there are legitimate uses of this. Just because there are bad uses of this feature doesn't mean you must omit it. If that's the case, then we need to get rid of all input/output in Java--it could be used to write viruses to the file system! Oh, and we should remove Random, too, because applications might Randomly change their behavior! We must protect people from their own mistakes. One way the JVM uses getCallerClass, if I understand correctly, is to detect if the code executing a certain method is allowed to. Would you deny the same ability to applications written for the JVM? And, of course, logging frameworks are the obvious exception. Think of the performance improvements that could be had if, while determining the source of an event, loggers could get the exact one frame they needed (via StackTraceFrame#getCallerFrame, ~100ms per 1,000,000 calls) instead of having to generate an entire stack trace and loop through it to find the one frame (Thread#getStackTrace(), ~3,000ms per 1,000,000 calls). > I see Mandy has restarted the discussion on use-cases (thank you Mandy) Sounds like starting over to me. > and working through these and addressing a subset initially might be good way to move this forward. More so as this is your first patch/contribution to OpenJDK - a first patch does not have to solve world peace, starting out with smaller changes is good. > >> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. > I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API. As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should! Nick From miroslav.kos at oracle.com Tue Sep 3 12:32:24 2013 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 03 Sep 2013 14:32:24 +0200 Subject: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\' In-Reply-To: <5225B769.1020302@oracle.com> References: <5225B0C0.1020301@oracle.com> <5225B403.3010801@oracle.com> <5225B5C2.1000704@oracle.com> <5225B769.1020302@oracle.com> Message-ID: <5225D6D8.1020706@oracle.com> Hi Sean, up to now, integrations JAX-WS > JDK haven't been done on regular basis, just when bug fixes were required, for current JDK development version it was time to time - 2x or 3x during a year (?) ... For future, we would like make it on regular basis for development version JAX-WS trunk/Jdk8 - let's say once or twice (?) a month, for other jdk version it would be same as now, only up on request ... How to proceed with this issue depends on how critical is it - we can integrate that first on our side and later (one week delay) deliver jdk patch or, if it is something critical, we can push it simultaneously into both codebasis. We definitely prefer the first option. Miran On 09/03/2013 12:18 PM, Se?n Coffey wrote: > Miran, > > can you clarify how we get this fix in then. Will you patch into > JAX-WS and port to the jdk/jaxws repo or do can we push it to both > repos independently? How often does JAX-WS team sync with openJDK ? > > I need to get this ported to jdk7u also. > > regards, > Sean. > > On 03/09/2013 11:11, Miroslav Kos wrote: >> Hi Alan, >> good catch! Yes, we need to apply the fix on our side too, otherwise >> it would be reverted with a new integration JAX-WS > JDK. >> >> Miran >> >> >> >> On 09/03/2013 12:03 PM, Alan Bateman wrote: >>> On 03/09/2013 10:49, Se?n Coffey wrote: >>>> Bug report not public at moment. (should appear shortly) >>>> >>>> Issue with wsimport tool. Use of jar files created from wsimport on >>>> windows don't work on unix systems. Portability issue. >>>> Simple fix. wsimport testcase to accompany it. >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8016271/ >>> Does this need to go into an upstream project first? As I >>> understand it, the JAX-WS folks have an industrial blender to mix >>> the ingredients for the jaxws repository. At one point then I think >>> there were about 10 upstream projects to pull code from. Maybe >>> things have changed but I just wonder if changes/patches pushed to >>> the jaxws repository will be wiped by a re-sync from upstream. I've >>> cc'ed martin Grebac and Miroslav Kos to comment. >>> >>> -Alan. >> > From david.lloyd at redhat.com Tue Sep 3 12:46:22 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 03 Sep 2013 07:46:22 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <100CD7AF-FE81-4439-BFE6-5B9FB650B2B7@nicholaswilliams.net> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> <522498F2.6050001@oracle.com> <5224A99D.2040708@univ-mlv.fr> <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> <5225A6D3.509@oracle.com> <100CD7AF-FE81-4439-BFE6-5B9FB650B2B7@nicholaswilliams.net> Message-ID: <5225DA1E.2010202@redhat.com> It's simple enough to just create an accessor object and add a security check on creation. There does not need to be a significant jam-up over this issue afaict. On 09/03/2013 07:24 AM, Nick Williams wrote: > > On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: > >> On 02/09/2013 18:45, Nick Williams wrote: >>> : >>> >>> I didn't decide to ignore the security concerns, I just don't see any security concerns. As has been /clearly/ established in the last three months, frameworks have been using getCallerClass for years, if not a decade. It has never caused a security problem. Ever. If I'm wrong, please point out to me a specific vulnerability that this has led to. >> I am not allowed to discuss any details about vulnerabilities here. > > Well so much for being open. > >> However, as a general point then caller sensitive methods have been highly problematic in the JDK. > > If security issues aren't allowed to be discussed in the open then how can we, the community, help address them? You say my patch has security problems. I haven't seen any detailed yet. > >> As regards frameworks using sun.reflect.Reflection.getCallerClass directly then it's as I said previously, they are probably not run with a security manager very often (at least not unless the policy is configured to allow direct access to sun.*). > > I'd argue that Logback, Log4j, and Groovy, three of the most common Java framework around, are very likely used with security managers quite often. It doesn't cause any problems because we don't misuse the information we obtain from getCallerClass. > >>> >>> I don't have the ability to go back and start from the beginning on something that I had the understanding was generally agreed upon before I started. >> You've done good work and no one is suggesting you throw it again. However I don't recall any agreement on a solution, rather the discussion mostly fizzled out. > > We reached a point where a few people said the API looked good, and then someone said that hands were short and "patches are welcome." I was then given guidelines for submitting a patch. Doesn't sound like fizzling out to me. > >> In particular I do not recall any discussions about changing the goals of JEP 176 and make @CS a public API. Whatever about @CS methods being a bad there is also the issue of annotations changing runtime behavior. > > If applications want to change their behavior based on the caller, let them! Is it bad practice, bad design, and likely all kinds of dumb? Heck yea. But there are legitimate uses of this. Just because there are bad uses of this feature doesn't mean you must omit it. If that's the case, then we need to get rid of all input/output in Java--it could be used to write viruses to the file system! Oh, and we should remove Random, too, because applications might Randomly change their behavior! We must protect people from their own mistakes. > > One way the JVM uses getCallerClass, if I understand correctly, is to detect if the code executing a certain method is allowed to. Would you deny the same ability to applications written for the JVM? And, of course, logging frameworks are the obvious exception. Think of the performance improvements that could be had if, while determining the source of an event, loggers could get the exact one frame they needed (via StackTraceFrame#getCallerFrame, ~100ms per 1,000,000 calls) instead of having to generate an entire stack trace and loop through it to find the one frame (Thread#getStackTrace(), ~3,000ms per 1,000,000 calls). > >> I see Mandy has restarted the discussion on use-cases (thank you Mandy) > > Sounds like starting over to me. > >> and working through these and addressing a subset initially might be good way to move this forward. More so as this is your first patch/contribution to OpenJDK - a first patch does not have to solve world peace, starting out with smaller changes is good. >> >>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. >> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API. > > As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should! > > Nick > -- - DML From nicholas+openjdk at nicholaswilliams.net Tue Sep 3 12:52:04 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Tue, 3 Sep 2013 07:52:04 -0500 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <522551AE.7060000@oracle.com> References: <522551AE.7060000@oracle.com> Message-ID: On Sep 2, 2013, at 10:04 PM, Mandy Chung wrote: > Hi Nick, > > Thanks for the patch. > > JEP 176 [1] describes the caller-sensitive method and the need for a mechanical checking of caller-sensitive methods. Also Peter Levart in [2] explained the change in MethodHandles.Lookup related to @CS. I assume you understand the rationale behind and the potential security issues. In general defining caller-sensitive API is discouraged. Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check. I don't see or understand any vulnerabilities here. I'm going to need much more information in order to contribute to the discussion in an informed manner. As I told Alan in a separate thread (I wish we had kept this in one thread): > If applications want to change their behavior based on the caller, let them! Is it bad practice, bad design, and likely all kinds of dumb? Heck yea. But there are legitimate uses of this. Just because there are bad uses of this feature doesn't mean you must omit it. If that's the case, then we need to get rid of all input/output in Java--it could be used to write viruses to the file system! Oh, and we should remove Random, too, because applications might Randomly change their behavior! We must protect people from their own mistakes. My sarcasm aside, I hope the point is clear. There are also legitimate uses for things for which there are illegitimate uses. Farmers need diesel for their tractors and fertilizer for their fields, but mix them and you can create a bomb. A caller-sensitive API, discouraged as it may be, is sometimes 100% necessary, and logging frameworks are the prime example. I also said in the other thread: > Think of the performance improvements that could be had if, while determining the source of an event, loggers could get the exact one frame they needed (via StackTraceFrame#getCallerFrame, ~100ms per 1,000,000 calls) instead of having to generate an entire stack trace and loop through it to find the one frame (Thread#getStackTrace(), ~3,000ms per 1,000,000 calls). I hope this is all articulated well. We need a caller-sensitive API. That's just the whole of the story. Why should java.util.logging.Logger get to use getCallerClass and Log4j not get to use it!? That is neither open nor fair. > Defining a SE supported @CallerSensitive and also getCallerClass API poses the risk of "encouraging" developers to implement more @CS methods while not fully understand its implication. And that would be their mistake. Document the heck out of it! Put big red warnings on it. Whatever makes you feel that you have disclaimed the user enough, do it. Providing a file access API poses the risk of encouraging developers to read and write files while not fully understanding the potential security issues, too. I'm just going to point out something, again, that I pointed out twice in June. C#/.NET has the ability to A) get the caller Type (equiv. of our class) and B) get the stack trace as StackFrames (the equivalent of the StackTraceFrame I'm adding), which contain the Type. In fact, you can ONLY get the stack trace as StackFrames. There's no StackTraceElement equivalent in C#/.NET. Has the world blown up yet? > It was a non-goal of JEP 176 to provide @CallerSensitive as a public API and I would suggest not to define it as a public API in JDK 8. And, has been stated many, many times, this non-goal is incompatible with the community's needs. Now, there /is/ a way to avoid making @CallerSensitive public (which the community doesn't care about) while still making getCallerClass public (which is really what the community needs). In order to do so, you must remove the check that requires the method calling getCallerClass/getCallerFrame to be annotated with @CallerSensitive. Once you remove that check, you don't need @CallerSensitive to be public. To be clear, though, once you remove that check, you don't need @CallerSensitive /at all/. It can simply go away. > While I'll take the time to look at your patch, I would like to restart the discussion from the use cases (in which led to what you summarized the need of your proposed API [3]): > > 1. Groovy 1.x and 2.x use the sun.reflect.Reflection.getCallerClass(int depth) method to: > ? emulates the way ResourceBundle.getBundle(String, Locale) works. Groovy runtime introduces intermediary stack frame between a caller and the call to getBundle, these frames needs to be filtered out; when looking for the caller classloader. > ? support the annotation @Grab, @Grab allows to specify a dependency between a code and a module (using apache ivy under the hood). The resolution is done at runtime and require a specific Classloader (the GroovyClassLoader), getCallerClass is used to find the class loader of the caller, again filtering out the intermediary stack frame. > Groovy 3.x has a different implementation that doesn't need to do stack walk to filter its runtime frames and find the caller > While I'm sure you're probably correct, I don't have enough Groovy knowledge to know for sure. > 2. Log4j > > Log4j offers "extended stack trace" patterns that requires access to a Class object when exceptions or stack traces are logged to provide additional information for troubleshooting such as the implementation version of the Package, code source, etc. It currently uses the sun.reflect.Reflection.getCallerClass(int depth) method to find the Class object matching the StackTraceElement in a Throwable or stack trace. If the sun.reflect.Reflection.getCallerClass(int depth) method doesn't exist, it will use SecurityManager.getClassContext(). Correct, mostly. And if it can't use SecurityManager#getClassContext(), it must use Class#forName() on the array of StackTraceElements (slooooowwww). To be clear, though, there are three needs: 1) Get the class name and class loader for the method getting a Logger via getLogger. 2) Get the stack trace for a Throwable such that it contains Classes for obtaining the CodeSource information. 3) Get the class, method, file name, and line number of code calling a Logger method to determine the source of a log event. We solve 2) by resolving /most/ of the Throwable's stack trace elements to Classes returned by getCallerClass with increasingly incremented indexes. This isn't perfect, because the Throwable stack trace is never identical to the current back trace. We have to fill in the missing pieces still with Class#forName. This is why we need to get StackTraceFrame[]s for Throwables instead of StackTraceElement[]s. > This approach is not reliable since the HotSpot implementation of getCallerClass filters out the frames corresponding to reflection machinery (its intent is to find the true caller) whereas a stack trace contains all Java frames up to MaxJavaStackTraceDepth (default is 1024). This is correct, and another reason why getting StackTraceFrame[]s for Throwables would be preferable to us. > When there is no Class object matching a StackTraceElement, it will fall back and load the class (does Log4j know which class loader to use?) We do not know which class loader to use, so we can't always get the Class. We simply display no extra information for these frames. This is rarely a problem, though, because in our use case Throwable stack traces rarely have Classes that belong to sibling class loaders. They almost always belong to the current class loader, the parent class loader, or one of the children class loaders. > Log4j currently works in the absence of the sun.reflect.Reflection.getCallerClass(int depth) method but performance is a very major issue. Yep. > 3. APIs on behalf of the caller > > For example, locating a resource on behalf of the caller class to avoid explicit additional Class and/or ClassLoader parameters. Yep. Nick > Please correct/add if I miss anything. > > More will be discussed tomorrow. > > Mandy > [1] http://openjdk.java.net/jeps/176 > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019397.html > [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html > > On 9/1/2013 1:16 AM, Nick Williams wrote: >> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444 >> ). >> >> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. >> >> *Summary of Changes* >> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: >> >> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. >> >> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. >> >> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. >> >> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. >> >> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. >> >> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. >> >> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. >> >> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. >> >> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). >> >> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+! >> element >> s) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. >> >> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! >> >> *The Code Changes* >> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): >> >> >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch >> >> >> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. >> >> Thanks! >> >> Nick >> > From sean.coffey at oracle.com Tue Sep 3 12:53:06 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 03 Sep 2013 13:53:06 +0100 Subject: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\' In-Reply-To: <5225D6D8.1020706@oracle.com> References: <5225B0C0.1020301@oracle.com> <5225B403.3010801@oracle.com> <5225B5C2.1000704@oracle.com> <5225B769.1020302@oracle.com> <5225D6D8.1020706@oracle.com> Message-ID: <5225DBB2.6090503@oracle.com> First option sounds good to me too Miran. Sounds like we can expect this fix to be sync'ed into JDK8 from JAXWS team over next week or two then. Hopefully you can do the same for jdk7u-dev. regards, Sean. On 03/09/2013 13:32, Miroslav Kos wrote: > Hi Sean, > up to now, integrations JAX-WS > JDK haven't been done on regular > basis, just when bug fixes were required, for current JDK development > version it was time to time - 2x or 3x during a year (?) ... > > For future, we would like make it on regular basis for development > version JAX-WS trunk/Jdk8 - let's say once or twice (?) a month, for > other jdk version it would be same as now, only up on request ... > > How to proceed with this issue depends on how critical is it - we can > integrate that first on our side and later (one week delay) deliver > jdk patch or, if it is something critical, we can push it > simultaneously into both codebasis. We definitely prefer the first > option. > > Miran > > > On 09/03/2013 12:18 PM, Se?n Coffey wrote: >> Miran, >> >> can you clarify how we get this fix in then. Will you patch into >> JAX-WS and port to the jdk/jaxws repo or do can we push it to both >> repos independently? How often does JAX-WS team sync with openJDK ? >> >> I need to get this ported to jdk7u also. >> >> regards, >> Sean. >> >> On 03/09/2013 11:11, Miroslav Kos wrote: >>> Hi Alan, >>> good catch! Yes, we need to apply the fix on our side too, otherwise >>> it would be reverted with a new integration JAX-WS > JDK. >>> >>> Miran >>> >>> >>> >>> On 09/03/2013 12:03 PM, Alan Bateman wrote: >>>> On 03/09/2013 10:49, Se?n Coffey wrote: >>>>> Bug report not public at moment. (should appear shortly) >>>>> >>>>> Issue with wsimport tool. Use of jar files created from wsimport >>>>> on windows don't work on unix systems. Portability issue. >>>>> Simple fix. wsimport testcase to accompany it. >>>>> >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8016271/ >>>> Does this need to go into an upstream project first? As I >>>> understand it, the JAX-WS folks have an industrial blender to mix >>>> the ingredients for the jaxws repository. At one point then I think >>>> there were about 10 upstream projects to pull code from. Maybe >>>> things have changed but I just wonder if changes/patches pushed to >>>> the jaxws repository will be wiped by a re-sync from upstream. I've >>>> cc'ed martin Grebac and Miroslav Kos to comment. >>>> >>>> -Alan. >>> >> > From chris.hegarty at oracle.com Tue Sep 3 12:58:03 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 03 Sep 2013 13:58:03 +0100 Subject: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets In-Reply-To: <5225D031.80008@oracle.com> References: <5225D031.80008@oracle.com> Message-ID: <5225DCDB.7070606@oracle.com> Sean, I remember discussing this (offlist) with you a while back, and I agree with the proposed solution. The logic for checking the system property looks a little odd. But I will admit views differ on exactly what values should be accepted. So, trivially I would suggest making keepAlive final and always setting it in the static initializer. Otherwise, looks fine to me. -Chris. On 09/03/2013 01:04 PM, Se?n Coffey wrote: > Sockets created by the > com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be > affected by firewalls if that connection is left idle for long periods > of time. (closed out). A workaround for such an issue could be to have a > simple corba thread send some simple ping traffic on the socket at > scheduled intervals. That may not be possible for legacy applications. > > Proposed solution is to add an implementation specific system property > flag which would have the keepAlive feature turned on for sockets > returned by the CORBA DefaultSocketFactoryImpl class. The application is > then in a better position to manage the keepAlive settings via the OS. > This had been fixed in Java SE 6 and I'm looking to port the new > property to jdk7u & jdk8. > > http://cr.openjdk.java.net/~coffeys/webrev.8017195/ > > regards, > Sean. From chris.hegarty at oracle.com Tue Sep 3 13:00:19 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 03 Sep 2013 14:00:19 +0100 Subject: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\' In-Reply-To: <5225DBB2.6090503@oracle.com> References: <5225B0C0.1020301@oracle.com> <5225B403.3010801@oracle.com> <5225B5C2.1000704@oracle.com> <5225B769.1020302@oracle.com> <5225D6D8.1020706@oracle.com> <5225DBB2.6090503@oracle.com> Message-ID: <5225DD63.1090108@oracle.com> On 09/03/2013 01:53 PM, Se?n Coffey wrote: > First option sounds good to me too Miran. Sounds like we can expect this > fix to be sync'ed into JDK8 from JAXWS team over next week or two then. > Hopefully you can do the same for jdk7u-dev. Since this is destined for 7u too. I would suggest that the JAXWS team try to build a patch (just like Sean's) suitable for JDK with just this single fix. -Chris. > > regards, > Sean. > > On 03/09/2013 13:32, Miroslav Kos wrote: >> Hi Sean, >> up to now, integrations JAX-WS > JDK haven't been done on regular >> basis, just when bug fixes were required, for current JDK development >> version it was time to time - 2x or 3x during a year (?) ... >> >> For future, we would like make it on regular basis for development >> version JAX-WS trunk/Jdk8 - let's say once or twice (?) a month, for >> other jdk version it would be same as now, only up on request ... >> >> How to proceed with this issue depends on how critical is it - we can >> integrate that first on our side and later (one week delay) deliver >> jdk patch or, if it is something critical, we can push it >> simultaneously into both codebasis. We definitely prefer the first >> option. >> >> Miran >> >> >> On 09/03/2013 12:18 PM, Se?n Coffey wrote: >>> Miran, >>> >>> can you clarify how we get this fix in then. Will you patch into >>> JAX-WS and port to the jdk/jaxws repo or do can we push it to both >>> repos independently? How often does JAX-WS team sync with openJDK ? >>> >>> I need to get this ported to jdk7u also. >>> >>> regards, >>> Sean. >>> >>> On 03/09/2013 11:11, Miroslav Kos wrote: >>>> Hi Alan, >>>> good catch! Yes, we need to apply the fix on our side too, otherwise >>>> it would be reverted with a new integration JAX-WS > JDK. >>>> >>>> Miran >>>> >>>> >>>> >>>> On 09/03/2013 12:03 PM, Alan Bateman wrote: >>>>> On 03/09/2013 10:49, Se?n Coffey wrote: >>>>>> Bug report not public at moment. (should appear shortly) >>>>>> >>>>>> Issue with wsimport tool. Use of jar files created from wsimport >>>>>> on windows don't work on unix systems. Portability issue. >>>>>> Simple fix. wsimport testcase to accompany it. >>>>>> >>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8016271/ >>>>> Does this need to go into an upstream project first? As I >>>>> understand it, the JAX-WS folks have an industrial blender to mix >>>>> the ingredients for the jaxws repository. At one point then I think >>>>> there were about 10 upstream projects to pull code from. Maybe >>>>> things have changed but I just wonder if changes/patches pushed to >>>>> the jaxws repository will be wiped by a re-sync from upstream. I've >>>>> cc'ed martin Grebac and Miroslav Kos to comment. >>>>> >>>>> -Alan. >>>> >>> >> > From roger.riggs at oracle.com Tue Sep 3 13:12:14 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 03 Sep 2013 09:12:14 -0400 Subject: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo In-Reply-To: <52259D39.6090906@oracle.com> References: <52255162.9010907@oracle.com> <522595FF.3070709@oracle.com> <52259D39.6090906@oracle.com> Message-ID: <5225E02E.9060200@oracle.com> Hi, There are going to be some gaps in compact1 testing if TestNG tests are omitted. For example, all of java.time uses TestNg exclusively. The java.time tests do not use the XML input file configuration options so perhaps the dependency on XML can be broken. Roger On 9/3/2013 4:26 AM, David Holmes wrote: > > >> As regards the definitions then one observation is the TestNG tests that >> you've listed in needs_compact2 are actually compact1 tests. I wonder if >> this is a TestNG dependency on XML rather than dependencies in the test >> themselves. > > Yes. As noted in the file the dependencies are not only what is being > tested but what test infrastructure is being used. The testng tests > uses xml which restricts them to compact2. Some tests use jps/jcmd or > tools.jar which restricts them to a full jdk. From mark.sheppard at oracle.com Tue Sep 3 14:11:08 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 03 Sep 2013 15:11:08 +0100 Subject: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets In-Reply-To: <5225DCDB.7070606@oracle.com> References: <5225D031.80008@oracle.com> <5225DCDB.7070606@oracle.com> Message-ID: <5225EDFC.5010509@oracle.com> It appears to be negative logic. If it's not false then its true. As the default value is false, would it be less ambiguous if only a property value of true sets the keepAlive variable to true? if ((value != null) && ("true".equalsIgnoreCase(value)) keepAlive = true; WRT testing, should we be accessing impl classes from tests, keeping in mind the desire to restrict access to the corba.impl classes in future jdk releases? This then might force this to be a packet level test? regards Mark On 03/09/2013 13:58, Chris Hegarty wrote: > Sean, > > I remember discussing this (offlist) with you a while back, and I > agree with the proposed solution. > > The logic for checking the system property looks a little odd. But I > will admit views differ on exactly what values should be accepted. So, > trivially I would suggest making keepAlive final and always setting it > in the static initializer. > > Otherwise, looks fine to me. > > -Chris. > > On 09/03/2013 01:04 PM, Se?n Coffey wrote: >> Sockets created by the >> com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be >> affected by firewalls if that connection is left idle for long periods >> of time. (closed out). A workaround for such an issue could be to have a >> simple corba thread send some simple ping traffic on the socket at >> scheduled intervals. That may not be possible for legacy applications. >> >> Proposed solution is to add an implementation specific system property >> flag which would have the keepAlive feature turned on for sockets >> returned by the CORBA DefaultSocketFactoryImpl class. The application is >> then in a better position to manage the keepAlive settings via the OS. >> This had been fixed in Java SE 6 and I'm looking to port the new >> property to jdk7u & jdk8. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8017195/ >> >> regards, >> Sean. From sundararajan.athijegannathan at oracle.com Tue Sep 3 14:12:15 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 03 Sep 2013 19:42:15 +0530 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: References: <522551AE.7060000@oracle.com> Message-ID: <5225EE3F.6050707@oracle.com> I don't think it is possible to get every Class object in the system. Either you should have a reference to an object (in which case you can call Object.getClass method) or the classloader that loaded your class should be able to resolve the referred class. For example, Class.forName("sun.misc.Unsafe") will fail with AccessControlException (when running under security manager with default policy). Even Class c = sun.misc.Unsafe.class; will fail. If Groovy or any third-party framework gets away with that -- that is because you need to use modified security policy that gives those necessary permissions to groovy.jar or whatever third-party jar in question. -Sundar On Tuesday 03 September 2013 06:22 PM, Nick Williams wrote: > On Sep 2, 2013, at 10:04 PM, Mandy Chung wrote: > >> Hi Nick, >> >> Thanks for the patch. >> >> JEP 176 [1] describes the caller-sensitive method and the need for a mechanical checking of caller-sensitive methods. Also Peter Levart in [2] explained the change in MethodHandles.Lookup related to @CS. I assume you understand the rationale behind and the potential security issues. In general defining caller-sensitive API is discouraged. > Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check. I don't see or understand any vulnerabilities here. I'm going to need much more information in order to contribute to the discussion in an informed manner. > > As I told Alan in a separate thread (I wish we had kept this in one thread): > >> If applications want to change their behavior based on the caller, let them! Is it bad practice, bad design, and likely all kinds of dumb? Heck yea. But there are legitimate uses of this. Just because there are bad uses of this feature doesn't mean you must omit it. If that's the case, then we need to get rid of all input/output in Java--it could be used to write viruses to the file system! Oh, and we should remove Random, too, because applications might Randomly change their behavior! We must protect people from their own mistakes. > > My sarcasm aside, I hope the point is clear. There are also legitimate uses for things for which there are illegitimate uses. Farmers need diesel for their tractors and fertilizer for their fields, but mix them and you can create a bomb. A caller-sensitive API, discouraged as it may be, is sometimes 100% necessary, and logging frameworks are the prime example. I also said in the other thread: > >> Think of the performance improvements that could be had if, while determining the source of an event, loggers could get the exact one frame they needed (via StackTraceFrame#getCallerFrame, ~100ms per 1,000,000 calls) instead of having to generate an entire stack trace and loop through it to find the one frame (Thread#getStackTrace(), ~3,000ms per 1,000,000 calls). > I hope this is all articulated well. We need a caller-sensitive API. That's just the whole of the story. Why should java.util.logging.Logger get to use getCallerClass and Log4j not get to use it!? That is neither open nor fair. > >> Defining a SE supported @CallerSensitive and also getCallerClass API poses the risk of "encouraging" developers to implement more @CS methods while not fully understand its implication. > And that would be their mistake. Document the heck out of it! Put big red warnings on it. Whatever makes you feel that you have disclaimed the user enough, do it. Providing a file access API poses the risk of encouraging developers to read and write files while not fully understanding the potential security issues, too. > > I'm just going to point out something, again, that I pointed out twice in June. C#/.NET has the ability to A) get the caller Type (equiv. of our class) and B) get the stack trace as StackFrames (the equivalent of the StackTraceFrame I'm adding), which contain the Type. In fact, you can ONLY get the stack trace as StackFrames. There's no StackTraceElement equivalent in C#/.NET. Has the world blown up yet? > >> It was a non-goal of JEP 176 to provide @CallerSensitive as a public API and I would suggest not to define it as a public API in JDK 8. > And, has been stated many, many times, this non-goal is incompatible with the community's needs. Now, there /is/ a way to avoid making @CallerSensitive public (which the community doesn't care about) while still making getCallerClass public (which is really what the community needs). In order to do so, you must remove the check that requires the method calling getCallerClass/getCallerFrame to be annotated with @CallerSensitive. Once you remove that check, you don't need @CallerSensitive to be public. To be clear, though, once you remove that check, you don't need @CallerSensitive /at all/. It can simply go away. > >> While I'll take the time to look at your patch, I would like to restart the discussion from the use cases (in which led to what you summarized the need of your proposed API [3]): >> >> 1. Groovy 1.x and 2.x use the sun.reflect.Reflection.getCallerClass(int depth) method to: >> ? emulates the way ResourceBundle.getBundle(String, Locale) works. Groovy runtime introduces intermediary stack frame between a caller and the call to getBundle, these frames needs to be filtered out; when looking for the caller classloader. >> ? support the annotation @Grab, @Grab allows to specify a dependency between a code and a module (using apache ivy under the hood). The resolution is done at runtime and require a specific Classloader (the GroovyClassLoader), getCallerClass is used to find the class loader of the caller, again filtering out the intermediary stack frame. >> Groovy 3.x has a different implementation that doesn't need to do stack walk to filter its runtime frames and find the caller >> > While I'm sure you're probably correct, I don't have enough Groovy knowledge to know for sure. > >> 2. Log4j >> >> Log4j offers "extended stack trace" patterns that requires access to a Class object when exceptions or stack traces are logged to provide additional information for troubleshooting such as the implementation version of the Package, code source, etc. It currently uses the sun.reflect.Reflection.getCallerClass(int depth) method to find the Class object matching the StackTraceElement in a Throwable or stack trace. If the sun.reflect.Reflection.getCallerClass(int depth) method doesn't exist, it will use SecurityManager.getClassContext(). > Correct, mostly. And if it can't use SecurityManager#getClassContext(), it must use Class#forName() on the array of StackTraceElements (slooooowwww). To be clear, though, there are three needs: > > 1) Get the class name and class loader for the method getting a Logger via getLogger. > 2) Get the stack trace for a Throwable such that it contains Classes for obtaining the CodeSource information. > 3) Get the class, method, file name, and line number of code calling a Logger method to determine the source of a log event. > > We solve 2) by resolving /most/ of the Throwable's stack trace elements to Classes returned by getCallerClass with increasingly incremented indexes. This isn't perfect, because the Throwable stack trace is never identical to the current back trace. We have to fill in the missing pieces still with Class#forName. This is why we need to get StackTraceFrame[]s for Throwables instead of StackTraceElement[]s. > >> This approach is not reliable since the HotSpot implementation of getCallerClass filters out the frames corresponding to reflection machinery (its intent is to find the true caller) whereas a stack trace contains all Java frames up to MaxJavaStackTraceDepth (default is 1024). > This is correct, and another reason why getting StackTraceFrame[]s for Throwables would be preferable to us. > >> When there is no Class object matching a StackTraceElement, it will fall back and load the class (does Log4j know which class loader to use?) > We do not know which class loader to use, so we can't always get the Class. We simply display no extra information for these frames. This is rarely a problem, though, because in our use case Throwable stack traces rarely have Classes that belong to sibling class loaders. They almost always belong to the current class loader, the parent class loader, or one of the children class loaders. > >> Log4j currently works in the absence of the sun.reflect.Reflection.getCallerClass(int depth) method but performance is a very major issue. > Yep. > >> 3. APIs on behalf of the caller >> >> For example, locating a resource on behalf of the caller class to avoid explicit additional Class and/or ClassLoader parameters. > Yep. > > Nick > >> Please correct/add if I miss anything. >> >> More will be discussed tomorrow. >> >> Mandy >> [1] http://openjdk.java.net/jeps/176 >> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019397.html >> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html >> >> On 9/1/2013 1:16 AM, Nick Williams wrote: >>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444 >>> ). >>> >>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. >>> >>> *Summary of Changes* >>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: >>> >>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. >>> >>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. >>> >>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. >>> >>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. >>> >>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. >>> >>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. >>> >>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. >>> >>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. >>> >>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). >>> >>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+! >>> element >>> s) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. >>> >>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! >>> >>> *The Code Changes* >>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): >>> >>> >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch >>> >>> >>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. >>> >>> Thanks! >>> >>> Nick >>> From artem.ananiev at oracle.com Tue Sep 3 14:16:45 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 03 Sep 2013 18:16:45 +0400 Subject: RFR: 8019853 - Break logging and AWT circular dependency In-Reply-To: <52200E2A.9090509@oracle.com> References: <521FAB7F.7020704@oracle.com> <52200E2A.9090509@oracle.com> Message-ID: <5225EF4D.20305@oracle.com> Hi, Daniel, I only looked at AppContext.java changes, and they look fine. Line 870 looks redundant, indeed, on the other hand it shouldn't hurt as well. Leaving it up to you. Thanks, Artem On 8/30/2013 7:14 AM, Mandy Chung wrote: > Hi Daniel, > > Thanks for getting this fixed. The change looks good. The > JavaAWTContext.getAppletContext implementation looks good and clean > (thanks to your comments). It'd be good to get AWT team to review > AppContext.java change (cc'ing Artem). > > Mandy > > On 8/29/2013 1:13 PM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a changeset that will fix: >> >> 8019853 - Break logging and AWT circular dependency >> >> (which also duplicates >> 8023258 Logger.getLogger() after ImageIO.read() returns >> different logger instance) >> >> >> >> The new code makes sure that JavaAWTAccess.getAppletContext() returns >> null when the LogManager's default userContext should be used, thus >> solving 8023258 (Logger.getLogger() after ImageIO.read() returns >> different logger instance). >> Although LogManager still needs to get the applet context it will no >> longer trigger the creation of the 'mainAppContext' - thus breaking >> the circular dependency. >> >> best regards, >> >> -- daniel > From chris.hegarty at oracle.com Tue Sep 3 14:23:53 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 03 Sep 2013 15:23:53 +0100 Subject: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets In-Reply-To: <5225EDFC.5010509@oracle.com> References: <5225D031.80008@oracle.com> <5225DCDB.7070606@oracle.com> <5225EDFC.5010509@oracle.com> Message-ID: <5225F0F9.7010803@oracle.com> There is always debate over this, but I suspect, given the property name com.sun.CORBA.transport.enableTcpKeepAlive, that if it is set ( -Dcom.sun.CORBA.transport.enableTcpKeepAlive ) then Sean is proposing that keepAlive should be true. It if has a value, then it must not be false. -Chris. On 09/03/2013 03:11 PM, Mark Sheppard wrote: > > It appears to be negative logic. If it's not false then its true. > As the default value is false, would it be less ambiguous if only a > property value of true sets > the keepAlive variable to true? > > if ((value != null) && ("true".equalsIgnoreCase(value)) > keepAlive = true; > > > WRT testing, should we be accessing impl classes from tests, keeping in > mind the > desire to restrict access to the corba.impl classes in future jdk releases? > This then might force this to be a packet level test? > > regards > Mark > > > On 03/09/2013 13:58, Chris Hegarty wrote: >> Sean, >> >> I remember discussing this (offlist) with you a while back, and I >> agree with the proposed solution. >> >> The logic for checking the system property looks a little odd. But I >> will admit views differ on exactly what values should be accepted. So, >> trivially I would suggest making keepAlive final and always setting it >> in the static initializer. >> >> Otherwise, looks fine to me. >> >> -Chris. >> >> On 09/03/2013 01:04 PM, Se?n Coffey wrote: >>> Sockets created by the >>> com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be >>> affected by firewalls if that connection is left idle for long periods >>> of time. (closed out). A workaround for such an issue could be to have a >>> simple corba thread send some simple ping traffic on the socket at >>> scheduled intervals. That may not be possible for legacy applications. >>> >>> Proposed solution is to add an implementation specific system property >>> flag which would have the keepAlive feature turned on for sockets >>> returned by the CORBA DefaultSocketFactoryImpl class. The application is >>> then in a better position to manage the keepAlive settings via the OS. >>> This had been fixed in Java SE 6 and I'm looking to port the new >>> property to jdk7u & jdk8. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8017195/ >>> >>> regards, >>> Sean. > From mandy.chung at oracle.com Tue Sep 3 14:30:00 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Sep 2013 07:30:00 -0700 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: References: <522551AE.7060000@oracle.com> Message-ID: <5225F268.2000707@oracle.com> On 9/3/2013 5:52 AM, Nick Williams wrote: > Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check. I don't see or understand any vulnerabilities here. I'm going to need much more information in order to contribute to the discussion in an informed manner. The Java security guideline is a good starting point. http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4 > And, has been stated many, many times, this non-goal is incompatible with the community's needs. Now, there /is/ a way to avoid making @CallerSensitive public (which the community doesn't care about) while still making getCallerClass public (which is really what the community needs). In order to do so, you must remove the check that requires the method calling getCallerClass/getCallerFrame to be annotated with @CallerSensitive. Once you remove that check, you don't need @CallerSensitive to be public. To be clear, though, once you remove that check, you don't need @CallerSensitive /at all/. It can simply go away. Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive. I keep seeing you suggest this and it is unclear to me if you only mean to remove java.lang. at CallerSensitive in your proposal. Mandy From nicholas+openjdk at nicholaswilliams.net Tue Sep 3 14:39:12 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Tue, 3 Sep 2013 09:39:12 -0500 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5225F268.2000707@oracle.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> Message-ID: <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> On Sep 3, 2013, at 9:30 AM, Mandy Chung wrote: > > On 9/3/2013 5:52 AM, Nick Williams wrote: >> Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check. I don't see or understand any vulnerabilities here. I'm going to need much more information in order to contribute to the discussion in an informed manner. > > The Java security guideline is a good starting point. > http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4 >> And, has been stated many, many times, this non-goal is incompatible with the community's needs. Now, there /is/ a way to avoid making @CallerSensitive public (which the community doesn't care about) while still making getCallerClass public (which is really what the community needs). In order to do so, you must remove the check that requires the method calling getCallerClass/getCallerFrame to be annotated with @CallerSensitive. Once you remove that check, you don't need @CallerSensitive to be public. To be clear, though, once you remove that check, you don't need @CallerSensitive /at all/. It can simply go away. > > Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive. I keep seeing you suggest this and it is unclear to me if you only mean to remove java.lang. at CallerSensitive in your proposal. Yes, that's what I mean. If you carefully examine the (existing) native code that backs getCallerClass, you see that @CallerSensitive is /only/ used as an enforcement mechanism. When I first read about @CallerSensitive, I /thought/ you could take a call stack like this one: @CallerSensitive getCallerClass() @CallerSensitive someMethod1() @CallerSensitive someMethod2() @CallerSensitive someMethod3() @CallerSensitive someMethod4() actualCallerMethod() And calling getCallerClass would return the class for actualCallerMethod(). However, I was wrong. getCallerClass /always/ returns someMethod1(). @CallerSensitive is /not/ used to determine when to stop looking for the caller. It's just an enforcement mechanism to ensure that only built-in JVM classes can call getCallerClass. This is /not/ how I did it, this is how it already was. Because of this, you could delete the @CallerSensitive annotation completely and getCallerClass still be fully functional the way it is. It just wouldn't be restricted to annotated methods anymore. Note: Now, to be honest, being able to keep going down the chain until you find actualCallerMethod() would be nice, but that presents its own challenges (what if actualCallerMethod is @CallerSensitive for a completely different purpose, for example?), so I don't think that would work. Nick From david.lloyd at redhat.com Tue Sep 3 14:40:04 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 03 Sep 2013 09:40:04 -0500 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5225F268.2000707@oracle.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> Message-ID: <5225F4C4.1000107@redhat.com> On 09/03/2013 09:30 AM, Mandy Chung wrote: > > On 9/3/2013 5:52 AM, Nick Williams wrote: >> Do, I don't understand the rationale. Alan said the security issues >> couldn't be discussed openly. I can get a Class object MANY different >> ways without a security check. I don't see or understand any >> vulnerabilities here. I'm going to need much more information in order >> to contribute to the discussion in an informed manner. > > The Java security guideline is a good starting point. > http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4 Spelling this out for clarity. This document talks about using access modifiers to restrict class definitions, which I think everyone agrees is a reasonable security measure. It specifically does *not* address accessing java.lang.Class instances, which are not protected or guarded in any way as far as I can see, and are as easy to access as .getClass() on any Object instance. In other words, if you have an object, you have its Class instance as well. The document *does* cover the (existing) protection of requiring a runtime permission to access the class loader from a Class (or other ways). Again, the doc talks about protecting ClassLoader instances, *not* Class instances. If accessing Class instances is a security hole, then we already have a serious problem that has nothing to do with this. >> And, has been stated many, many times, this non-goal is incompatible >> with the community's needs. Now, there /is/ a way to avoid making >> @CallerSensitive public (which the community doesn't care about) while >> still making getCallerClass public (which is really what the community >> needs). In order to do so, you must remove the check that requires the >> method calling getCallerClass/getCallerFrame to be annotated with >> @CallerSensitive. Once you remove that check, you don't need >> @CallerSensitive to be public. To be clear, though, once you remove >> that check, you don't need @CallerSensitive /at all/. It can simply go >> away. > > Do you mean sun.reflect.CallerSensitive can go away? This is very > important part of the design that we need to detect which methods are > caller-sensitive. I keep seeing you suggest this and it is unclear to > me if you only mean to remove java.lang. at CallerSensitive in your proposal. > > Mandy -- - DML From nicholas+openjdk at nicholaswilliams.net Tue Sep 3 14:43:53 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Tue, 3 Sep 2013 09:43:53 -0500 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> Message-ID: On Sep 3, 2013, at 9:39 AM, Nick Williams wrote: > > On Sep 3, 2013, at 9:30 AM, Mandy Chung wrote: > >> >> On 9/3/2013 5:52 AM, Nick Williams wrote: >>> Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check. I don't see or understand any vulnerabilities here. I'm going to need much more information in order to contribute to the discussion in an informed manner. >> >> The Java security guideline is a good starting point. >> http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4 >>> And, has been stated many, many times, this non-goal is incompatible with the community's needs. Now, there /is/ a way to avoid making @CallerSensitive public (which the community doesn't care about) while still making getCallerClass public (which is really what the community needs). In order to do so, you must remove the check that requires the method calling getCallerClass/getCallerFrame to be annotated with @CallerSensitive. Once you remove that check, you don't need @CallerSensitive to be public. To be clear, though, once you remove that check, you don't need @CallerSensitive /at all/. It can simply go away. >> >> Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive. I keep seeing you suggest this and it is unclear to me if you only mean to remove java.lang. at CallerSensitive in your proposal. > > Yes, that's what I mean. If you carefully examine the (existing) native code that backs getCallerClass, you see that @CallerSensitive is /only/ used as an enforcement mechanism. When I first read about @CallerSensitive, I /thought/ you could take a call stack like this one: > > @CallerSensitive getCallerClass() > @CallerSensitive someMethod1() > @CallerSensitive someMethod2() > @CallerSensitive someMethod3() > @CallerSensitive someMethod4() > actualCallerMethod() > > And calling getCallerClass would return the class for actualCallerMethod(). However, I was wrong. getCallerClass /always/ returns someMethod1(). Sorry, typo. getCallerClass always returns someMethod2(). Not someMethod1(). > @CallerSensitive is /not/ used to determine when to stop looking for the caller. It's just an enforcement mechanism to ensure that only built-in JVM classes can call getCallerClass. This is /not/ how I did it, this is how it already was. Because of this, you could delete the @CallerSensitive annotation completely and getCallerClass still be fully functional the way it is. It just wouldn't be restricted to annotated methods anymore. > > Note: Now, to be honest, being able to keep going down the chain until you find actualCallerMethod() would be nice, but that presents its own challenges (what if actualCallerMethod is @CallerSensitive for a completely different purpose, for example?), so I don't think that would work. > > Nick From nicholas+openjdk at nicholaswilliams.net Tue Sep 3 14:44:53 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Tue, 3 Sep 2013 09:44:53 -0500 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5225F4C4.1000107@redhat.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <5225F4C4.1000107@redhat.com> Message-ID: On Sep 3, 2013, at 9:40 AM, David M. Lloyd wrote: > On 09/03/2013 09:30 AM, Mandy Chung wrote: >> >> On 9/3/2013 5:52 AM, Nick Williams wrote: >>> Do, I don't understand the rationale. Alan said the security issues >>> couldn't be discussed openly. I can get a Class object MANY different >>> ways without a security check. I don't see or understand any >>> vulnerabilities here. I'm going to need much more information in order >>> to contribute to the discussion in an informed manner. >> >> The Java security guideline is a good starting point. >> http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4 > > Spelling this out for clarity. This document talks about using access modifiers to restrict class definitions, which I think everyone agrees is a reasonable security measure. It specifically does *not* address accessing java.lang.Class instances, which are not protected or guarded in any way as far as I can see, and are as easy to access as .getClass() on any Object instance. In other words, if you have an object, you have its Class instance as well. > > The document *does* cover the (existing) protection of requiring a runtime permission to access the class loader from a Class (or other ways). > > Again, the doc talks about protecting ClassLoader instances, *not* Class instances. If accessing Class instances is a security hole, then we already have a serious problem that has nothing to do with this. Yes. Exactly. Thank you. >>> And, has been stated many, many times, this non-goal is incompatible >>> with the community's needs. Now, there /is/ a way to avoid making >>> @CallerSensitive public (which the community doesn't care about) while >>> still making getCallerClass public (which is really what the community >>> needs). In order to do so, you must remove the check that requires the >>> method calling getCallerClass/getCallerFrame to be annotated with >>> @CallerSensitive. Once you remove that check, you don't need >>> @CallerSensitive to be public. To be clear, though, once you remove >>> that check, you don't need @CallerSensitive /at all/. It can simply go >>> away. >> >> Do you mean sun.reflect.CallerSensitive can go away? This is very >> important part of the design that we need to detect which methods are >> caller-sensitive. I keep seeing you suggest this and it is unclear to >> me if you only mean to remove java.lang. at CallerSensitive in your proposal. >> >> Mandy > > > -- > - DML From sean.coffey at oracle.com Tue Sep 3 15:10:41 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 03 Sep 2013 16:10:41 +0100 Subject: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets In-Reply-To: <5225F0F9.7010803@oracle.com> References: <5225D031.80008@oracle.com> <5225DCDB.7070606@oracle.com> <5225EDFC.5010509@oracle.com> <5225F0F9.7010803@oracle.com> Message-ID: <5225FBF1.7030000@oracle.com> I'd like to keep the same property behaviour as that used in JDK 6. It's also the one agreed on for CCC request. I've seen the same pattern used in other parts of corelibs code. Taken Chris's feedback on board : http://cr.openjdk.java.net/~coffeys/webrev.8017195.2/webrev/ regards, Sean. On 03/09/2013 15:23, Chris Hegarty wrote: > There is always debate over this, but I suspect, given the property > name com.sun.CORBA.transport.enableTcpKeepAlive, that if it is set ( > -Dcom.sun.CORBA.transport.enableTcpKeepAlive ) then Sean is proposing > that keepAlive should be true. It if has a value, then it must not be > false. > > -Chris. > > On 09/03/2013 03:11 PM, Mark Sheppard wrote: >> >> It appears to be negative logic. If it's not false then its true. >> As the default value is false, would it be less ambiguous if only a >> property value of true sets >> the keepAlive variable to true? >> >> if ((value != null) && ("true".equalsIgnoreCase(value)) >> keepAlive = true; >> >> >> WRT testing, should we be accessing impl classes from tests, keeping in >> mind the >> desire to restrict access to the corba.impl classes in future jdk >> releases? >> This then might force this to be a packet level test? >> >> regards >> Mark >> >> >> On 03/09/2013 13:58, Chris Hegarty wrote: >>> Sean, >>> >>> I remember discussing this (offlist) with you a while back, and I >>> agree with the proposed solution. >>> >>> The logic for checking the system property looks a little odd. But I >>> will admit views differ on exactly what values should be accepted. So, >>> trivially I would suggest making keepAlive final and always setting it >>> in the static initializer. >>> >>> Otherwise, looks fine to me. >>> >>> -Chris. >>> >>> On 09/03/2013 01:04 PM, Se?n Coffey wrote: >>>> Sockets created by the >>>> com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory >>>> can be >>>> affected by firewalls if that connection is left idle for long periods >>>> of time. (closed out). A workaround for such an issue could be to >>>> have a >>>> simple corba thread send some simple ping traffic on the socket at >>>> scheduled intervals. That may not be possible for legacy applications. >>>> >>>> Proposed solution is to add an implementation specific system property >>>> flag which would have the keepAlive feature turned on for sockets >>>> returned by the CORBA DefaultSocketFactoryImpl class. The >>>> application is >>>> then in a better position to manage the keepAlive settings via the OS. >>>> This had been fixed in Java SE 6 and I'm looking to port the new >>>> property to jdk7u & jdk8. >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8017195/ >>>> >>>> regards, >>>> Sean. >> From chris.hegarty at oracle.com Tue Sep 3 15:30:00 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 Sep 2013 16:30:00 +0100 Subject: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets In-Reply-To: <5225FBF1.7030000@oracle.com> References: <5225D031.80008@oracle.com> <5225DCDB.7070606@oracle.com> <5225EDFC.5010509@oracle.com> <5225F0F9.7010803@oracle.com> <5225FBF1.7030000@oracle.com> Message-ID: On 3 Sep 2013, at 16:10, Se?n Coffey wrote: > I'd like to keep the same property behaviour as that used in JDK 6. It's also the one agreed on for CCC request. I've seen the same pattern used in other parts of corelibs code. > > Taken Chris's feedback on board : > http://cr.openjdk.java.net/~coffeys/webrev.8017195.2/webrev/ Looks good to me. -Chris. > > regards, > Sean. > > On 03/09/2013 15:23, Chris Hegarty wrote: >> There is always debate over this, but I suspect, given the property name com.sun.CORBA.transport.enableTcpKeepAlive, that if it is set ( -Dcom.sun.CORBA.transport.enableTcpKeepAlive ) then Sean is proposing that keepAlive should be true. It if has a value, then it must not be false. >> >> -Chris. >> >> On 09/03/2013 03:11 PM, Mark Sheppard wrote: >>> >>> It appears to be negative logic. If it's not false then its true. >>> As the default value is false, would it be less ambiguous if only a >>> property value of true sets >>> the keepAlive variable to true? >>> >>> if ((value != null) && ("true".equalsIgnoreCase(value)) >>> keepAlive = true; >>> >>> >>> WRT testing, should we be accessing impl classes from tests, keeping in >>> mind the >>> desire to restrict access to the corba.impl classes in future jdk releases? >>> This then might force this to be a packet level test? >>> >>> regards >>> Mark >>> >>> >>> On 03/09/2013 13:58, Chris Hegarty wrote: >>>> Sean, >>>> >>>> I remember discussing this (offlist) with you a while back, and I >>>> agree with the proposed solution. >>>> >>>> The logic for checking the system property looks a little odd. But I >>>> will admit views differ on exactly what values should be accepted. So, >>>> trivially I would suggest making keepAlive final and always setting it >>>> in the static initializer. >>>> >>>> Otherwise, looks fine to me. >>>> >>>> -Chris. >>>> >>>> On 09/03/2013 01:04 PM, Se?n Coffey wrote: >>>>> Sockets created by the >>>>> com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be >>>>> affected by firewalls if that connection is left idle for long periods >>>>> of time. (closed out). A workaround for such an issue could be to have a >>>>> simple corba thread send some simple ping traffic on the socket at >>>>> scheduled intervals. That may not be possible for legacy applications. >>>>> >>>>> Proposed solution is to add an implementation specific system property >>>>> flag which would have the keepAlive feature turned on for sockets >>>>> returned by the CORBA DefaultSocketFactoryImpl class. The application is >>>>> then in a better position to manage the keepAlive settings via the OS. >>>>> This had been fixed in Java SE 6 and I'm looking to port the new >>>>> property to jdk7u & jdk8. >>>>> >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8017195/ >>>>> >>>>> regards, >>>>> Sean. > From Alan.Bateman at oracle.com Tue Sep 3 15:57:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 16:57:34 +0100 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <100CD7AF-FE81-4439-BFE6-5B9FB650B2B7@nicholaswilliams.net> References: <52FF5720-4DAE-4A90-A385-1DAA7A786BDD@nicholaswilliams.net> <522375C9.8010005@mindspring.com> <402ED9CE-96E0-4428-97EA-58B46AD04DE4@nicholaswilliams.net> <52244D50.5080603@oracle.com> <522498F2.6050001@oracle.com> <5224A99D.2040708@univ-mlv.fr> <60304E16-C759-4290-89A4-A7C6451DD007@nicholaswilliams.net> <5225A6D3.509@oracle.com> <100CD7AF-FE81-4439-BFE6-5B9FB650B2B7@nicholaswilliams.net> Message-ID: <522606EE.2060407@oracle.com> On 03/09/2013 13:24, Nick Williams wrote: > : >> As regards frameworks using sun.reflect.Reflection.getCallerClass directly then it's as I said previously, they are probably not run with a security manager very often (at least not unless the policy is configured to allow direct access to sun.*). > I'd argue that Logback, Log4j, and Groovy, three of the most common Java framework around, are very likely used with security managers quite often. It doesn't cause any problems because we don't misuse the information we obtain from getCallerClass. When running with a security manager then access to sun.* is restricted. My point is that if they folks are using Log4J when running with a security manager then it can't use the existing sun.reflect.Reflection.getCallerClass unless permission has been granted. Once you open up access to sun.* then all bets are off of course. -Alan From ralph.goers at dslextreme.com Tue Sep 3 16:28:19 2013 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 3 Sep 2013 09:28:19 -0700 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: References: <522551AE.7060000@oracle.com> Message-ID: <23C8C6CE-4C69-4A63-AF47-62AF1944FA0A@dslextreme.com> I'd just like to add to this thread that Log4j is copying behavior that has been in Logback for years. The default behavior for both is to print a stack trace that includes the jar or directory where the class was located and its version. User's find this extremely helpful when diagnosing problems. In addition Log4j is using getCallerClass to determine the caller of LogManager.getLogger() so it can determine which LoggerContext to associate it with (based on the ClassLoader of the caller). This is to solve the issues raised at http://logback.qos.ch/manual/loggingSeparation.html#tamingStaticRefs. Ralph On Sep 3, 2013, at 5:52 AM, Nick Williams wrote: > > On Sep 2, 2013, at 10:04 PM, Mandy Chung wrote: > >> Hi Nick, >> >> Thanks for the patch. >> >> JEP 176 [1] describes the caller-sensitive method and the need for a mechanical checking of caller-sensitive methods. Also Peter Levart in [2] explained the change in MethodHandles.Lookup related to @CS. I assume you understand the rationale behind and the potential security issues. In general defining caller-sensitive API is discouraged. > > Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check. I don't see or understand any vulnerabilities here. I'm going to need much more information in order to contribute to the discussion in an informed manner. > > As I told Alan in a separate thread (I wish we had kept this in one thread): > >> If applications want to change their behavior based on the caller, let them! Is it bad practice, bad design, and likely all kinds of dumb? Heck yea. But there are legitimate uses of this. Just because there are bad uses of this feature doesn't mean you must omit it. If that's the case, then we need to get rid of all input/output in Java--it could be used to write viruses to the file system! Oh, and we should remove Random, too, because applications might Randomly change their behavior! We must protect people from their own mistakes. > > > My sarcasm aside, I hope the point is clear. There are also legitimate uses for things for which there are illegitimate uses. Farmers need diesel for their tractors and fertilizer for their fields, but mix them and you can create a bomb. A caller-sensitive API, discouraged as it may be, is sometimes 100% necessary, and logging frameworks are the prime example. I also said in the other thread: > >> Think of the performance improvements that could be had if, while determining the source of an event, loggers could get the exact one frame they needed (via StackTraceFrame#getCallerFrame, ~100ms per 1,000,000 calls) instead of having to generate an entire stack trace and loop through it to find the one frame (Thread#getStackTrace(), ~3,000ms per 1,000,000 calls). > > I hope this is all articulated well. We need a caller-sensitive API. That's just the whole of the story. Why should java.util.logging.Logger get to use getCallerClass and Log4j not get to use it!? That is neither open nor fair. > >> Defining a SE supported @CallerSensitive and also getCallerClass API poses the risk of "encouraging" developers to implement more @CS methods while not fully understand its implication. > > And that would be their mistake. Document the heck out of it! Put big red warnings on it. Whatever makes you feel that you have disclaimed the user enough, do it. Providing a file access API poses the risk of encouraging developers to read and write files while not fully understanding the potential security issues, too. > > I'm just going to point out something, again, that I pointed out twice in June. C#/.NET has the ability to A) get the caller Type (equiv. of our class) and B) get the stack trace as StackFrames (the equivalent of the StackTraceFrame I'm adding), which contain the Type. In fact, you can ONLY get the stack trace as StackFrames. There's no StackTraceElement equivalent in C#/.NET. Has the world blown up yet? > >> It was a non-goal of JEP 176 to provide @CallerSensitive as a public API and I would suggest not to define it as a public API in JDK 8. > > And, has been stated many, many times, this non-goal is incompatible with the community's needs. Now, there /is/ a way to avoid making @CallerSensitive public (which the community doesn't care about) while still making getCallerClass public (which is really what the community needs). In order to do so, you must remove the check that requires the method calling getCallerClass/getCallerFrame to be annotated with @CallerSensitive. Once you remove that check, you don't need @CallerSensitive to be public. To be clear, though, once you remove that check, you don't need @CallerSensitive /at all/. It can simply go away. > >> While I'll take the time to look at your patch, I would like to restart the discussion from the use cases (in which led to what you summarized the need of your proposed API [3]): >> >> 1. Groovy 1.x and 2.x use the sun.reflect.Reflection.getCallerClass(int depth) method to: >> ? emulates the way ResourceBundle.getBundle(String, Locale) works. Groovy runtime introduces intermediary stack frame between a caller and the call to getBundle, these frames needs to be filtered out; when looking for the caller classloader. >> ? support the annotation @Grab, @Grab allows to specify a dependency between a code and a module (using apache ivy under the hood). The resolution is done at runtime and require a specific Classloader (the GroovyClassLoader), getCallerClass is used to find the class loader of the caller, again filtering out the intermediary stack frame. >> Groovy 3.x has a different implementation that doesn't need to do stack walk to filter its runtime frames and find the caller >> > > While I'm sure you're probably correct, I don't have enough Groovy knowledge to know for sure. > >> 2. Log4j >> >> Log4j offers "extended stack trace" patterns that requires access to a Class object when exceptions or stack traces are logged to provide additional information for troubleshooting such as the implementation version of the Package, code source, etc. It currently uses the sun.reflect.Reflection.getCallerClass(int depth) method to find the Class object matching the StackTraceElement in a Throwable or stack trace. If the sun.reflect.Reflection.getCallerClass(int depth) method doesn't exist, it will use SecurityManager.getClassContext(). > > Correct, mostly. And if it can't use SecurityManager#getClassContext(), it must use Class#forName() on the array of StackTraceElements (slooooowwww). To be clear, though, there are three needs: > > 1) Get the class name and class loader for the method getting a Logger via getLogger. > 2) Get the stack trace for a Throwable such that it contains Classes for obtaining the CodeSource information. > 3) Get the class, method, file name, and line number of code calling a Logger method to determine the source of a log event. > > We solve 2) by resolving /most/ of the Throwable's stack trace elements to Classes returned by getCallerClass with increasingly incremented indexes. This isn't perfect, because the Throwable stack trace is never identical to the current back trace. We have to fill in the missing pieces still with Class#forName. This is why we need to get StackTraceFrame[]s for Throwables instead of StackTraceElement[]s. > >> This approach is not reliable since the HotSpot implementation of getCallerClass filters out the frames corresponding to reflection machinery (its intent is to find the true caller) whereas a stack trace contains all Java frames up to MaxJavaStackTraceDepth (default is 1024). > > This is correct, and another reason why getting StackTraceFrame[]s for Throwables would be preferable to us. > >> When there is no Class object matching a StackTraceElement, it will fall back and load the class (does Log4j know which class loader to use?) > > We do not know which class loader to use, so we can't always get the Class. We simply display no extra information for these frames. This is rarely a problem, though, because in our use case Throwable stack traces rarely have Classes that belong to sibling class loaders. They almost always belong to the current class loader, the parent class loader, or one of the children class loaders. > >> Log4j currently works in the absence of the sun.reflect.Reflection.getCallerClass(int depth) method but performance is a very major issue. > > Yep. > >> 3. APIs on behalf of the caller >> >> For example, locating a resource on behalf of the caller class to avoid explicit additional Class and/or ClassLoader parameters. > > Yep. > > Nick > >> Please correct/add if I miss anything. >> >> More will be discussed tomorrow. >> >> Mandy >> [1] http://openjdk.java.net/jeps/176 >> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019397.html >> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html >> >> On 9/1/2013 1:16 AM, Nick Williams wrote: >>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444 >>> ). >>> >>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. >>> >>> *Summary of Changes* >>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: >>> >>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. >>> >>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. >>> >>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. >>> >>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. >>> >>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. >>> >>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. >>> >>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. >>> >>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. >>> >>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). >>> >>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+! >>> element >>> s) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. >>> >>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! >>> >>> *The Code Changes* >>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): >>> >>> >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch >>> >>> >>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. >>> >>> Thanks! >>> >>> Nick >>> >> > From mandy.chung at oracle.com Tue Sep 3 16:30:09 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Sep 2013 09:30:09 -0700 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5225F4C4.1000107@redhat.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <5225F4C4.1000107@redhat.com> Message-ID: <52260E91.9020908@oracle.com> On 9/3/13 7:40 AM, David M. Lloyd wrote: > On 09/03/2013 09:30 AM, Mandy Chung wrote: >> >> On 9/3/2013 5:52 AM, Nick Williams wrote: >>> Do, I don't understand the rationale. Alan said the security issues >>> couldn't be discussed openly. I can get a Class object MANY different >>> ways without a security check. I don't see or understand any >>> vulnerabilities here. I'm going to need much more information in order >>> to contribute to the discussion in an informed manner. >> >> The Java security guideline is a good starting point. >> http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4 > > Spelling this out for clarity. This document talks about using access > modifiers to restrict class definitions, which I think everyone agrees > is a reasonable security measure. I didn't mean to refer specifically to section 4 (sorry for the incorrect URL - cut and paste issue) but instead the entire Java security guideline. Section 9 contains the information relevant to the immediate caller. > It specifically does *not* address accessing java.lang.Class > instances, which are not protected or guarded in any way as far as I > can see, and are as easy to access as .getClass() on any Object > instance. In other words, if you have an object, you have its Class > instance as well. > That's one problem - you don't always get a hold of an object of any sun.* classes for example. However, walking the stack will mean that you now can access to a sun.* Class even if you don't have access to any instance. I'm not making any conclusion whether we can or can't provide such API but just to point out that the security issue requires detailed thought-through. Mandy > The document *does* cover the (existing) protection of requiring a > runtime permission to access the class loader from a Class (or other > ways). > > Again, the doc talks about protecting ClassLoader instances, *not* > Class instances. If accessing Class instances is a security hole, > then we already have a serious problem that has nothing to do with this. > From paul.sandoz at oracle.com Tue Sep 3 16:33:56 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Sep 2013 18:33:56 +0200 Subject: RFR 8024182 test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes Message-ID: Hi, Due to recent compiler changes a test is failing to compile. The fix is already in lambda and needs to be pushed to tl: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9389 Paul. From peter.levart at gmail.com Tue Sep 3 17:16:47 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 03 Sep 2013 19:16:47 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> Message-ID: <5226197F.1050301@gmail.com> On 09/03/2013 04:39 PM, Nick Williams wrote: >> >Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive. I keep seeing you suggest this and it is unclear to me if you only mean to remove java.lang. at CallerSensitive in your proposal. > Yes, that's what I mean. If you carefully examine the (existing) native code that backs getCallerClass, you see that @CallerSensitive is/only/ used as an enforcement mechanism. When I first read about @CallerSensitive, I/thought/ you could take a call stack like this one: > > @CallerSensitive getCallerClass() > @CallerSensitive someMethod1() > @CallerSensitive someMethod2() > @CallerSensitive someMethod3() > @CallerSensitive someMethod4() > actualCallerMethod() > > And calling getCallerClass would return the class for actualCallerMethod(). However, I was wrong. getCallerClass/always/ returns someMethod1(). @CallerSensitive is/not/ used to determine when to stop looking for the caller. It's just an enforcement mechanism to ensure that only built-in JVM classes can call getCallerClass. *AND* that Reflection.getCallerClass() can only be called from within methods annotated with @CallerSensitive. Now for that part, the public API equivalent (StackTraceFrame.getCallerClass() or whatever it is called) need not be restricted to methods annotated with any annotation, but that means that this public API should not be used to implement security decisions since MethodHandles API allows caller to be spoofed unless looking-up a method annotated with @CallerSensitive... > This is/not/ how I did it, this is how it already was. Because of this, you could delete the @CallerSensitive annotation completely and getCallerClass still be fully functional the way it is. It just wouldn't be restricted to annotated methods anymore. For security unrelated things (like logging and similar) public API need not include any enabling annotation, but it needs to be documented that it should not be used for security decisions. *** Regarding ability to obtain j.l.Class instances for classes that client code would otherwise have no access to: What about a simple restriction on methods returning such instances that Class objects are only returned when they are resolvable from the ClassLoader of client code. If they are not resolvable, null is returned. For example, the equivalent of: public class StackTraceFrame { private final Class declaringClass; @CallerSensitive public Class getDeclaringClass() { try { return Class.forName(declaringClass.getName(), false, Reflection.getCallerClass().getClassLoader()) == declaringClass ? declaringClass : null; } } catch (ClassNotFoundException ignore) {} return null; } // the name can be exposed without fear... public String getDeclaringClassName() { return declaringClass.getName(); } This example could be implemented more efficiently then above code (using private Class/ClassLoader API). Regards, Peter From Alan.Bateman at oracle.com Tue Sep 3 17:19:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 18:19:29 +0100 Subject: RFR 8024182 test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes In-Reply-To: References: Message-ID: <52261A21.6090103@oracle.com> On 03/09/2013 17:33, Paul Sandoz wrote: > Hi, > > Due to recent compiler changes a test is failing to compile. > > The fix is already in lambda and needs to be pushed to tl: > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9389 > > Paul. > Looks good, thanks for sorting this out. The other thing that this compiler update brings new warnings, we may have to whack them too. -Alan. From blackdrag at gmx.org Tue Sep 3 17:21:12 2013 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 03 Sep 2013 19:21:12 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5225A607.7080909@univ-mlv.fr> References: <522551AE.7060000@oracle.com> <52259B13.8060100@gmx.org> <5225A607.7080909@univ-mlv.fr> Message-ID: <52261A88.6090605@gmx.org> Am 03.09.2013 11:04, schrieb Remi Forax: [...] > So there is a need for an API to get the caller classes which is not > getCallerClass (or any methods in a package sun.*) that will hide you > the method handle API impementation and allow you choose to filter > caller methods using a user defined API. not sure how filtering the caller methods would work (by annotation check?), but it is probably good enough for us, yes. In the end we need the class loader bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From nicholas+openjdk at nicholaswilliams.net Tue Sep 3 17:26:05 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Tue, 3 Sep 2013 12:26:05 -0500 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5226197F.1050301@gmail.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> Message-ID: <67CFDFA2-1DC6-4CFB-8148-C79398029B68@nicholaswilliams.net> On Sep 3, 2013, at 12:16 PM, Peter Levart wrote: > On 09/03/2013 04:39 PM, Nick Williams wrote: >>> > >>> Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive. I keep seeing you suggest this and it is unclear to me if you only mean to remove java.lang. at CallerSensitive in your proposal. >>> >> Yes, that's what I mean. If you carefully examine the (existing) native code that backs getCallerClass, you see that @CallerSensitive is /only/ used as an enforcement mechanism. When I first read about @CallerSensitive, I /thought/ >> you could take a call stack like this one: >> >> @CallerSensitive getCallerClass() >> @CallerSensitive someMethod1() >> @CallerSensitive someMethod2() >> @CallerSensitive someMethod3() >> @CallerSensitive someMethod4() >> actualCallerMethod() >> >> And calling getCallerClass would return the class for actualCallerMethod(). However, I was wrong. getCallerClass >> /always/ returns someMethod1(). @CallerSensitive is /not/ used to determine when to stop looking for the caller. It's just an enforcement mechanism to ensure that only built-in JVM classes can call getCallerClass. > > *AND* that Reflection.getCallerClass() can only be called from within methods annotated with @CallerSensitive. That's exactly what I said, just worded differently. > Now for that part, the public API equivalent (StackTraceFrame.getCallerClass() or whatever it is called) need not be restricted to methods annotated with any annotation, but that means that this public API should not be used to implement security decisions since MethodHandles API allows caller to be spoofed unless looking-up a method annotated with @CallerSensitive... > >> This is /not/ how I did it, this is how it already was. Because of this, you could delete the @CallerSensitive annotation completely and getCallerClass still be fully functional the way it is. It just wouldn't be restricted to annotated methods anymore. > > For security unrelated things (like logging and similar) public API need not include any enabling annotation, but it needs to be documented that it should not be used for security decisions. Now that's a change that makes sense and would certainly be more user-friendly. Keep @CallerSensitive private, but don't require it for StackTraceFrame#getCallerClass()/getCallerFrame(). Document that StackTraceFrame should not be used to make security decisions. Still require @CallerSensitive for Reflection#getCallerClass(). I like this idea. > > *** > > Regarding ability to obtain j.l.Class instances for classes that client code would otherwise have no access to: > > What about a simple restriction on methods returning such instances that Class objects are only returned when they are resolvable from the ClassLoader of client code. If they are not resolvable, null is returned. For example, the equivalent of: > > public class StackTraceFrame { > > private final Class declaringClass; > > @CallerSensitive > public Class getDeclaringClass() { > try { > return Class.forName(declaringClass.getName(), > false, > Reflection.getCallerClass().getClassLoader()) > == declaringClass ? declaringClass : null; > } > } catch (ClassNotFoundException ignore) {} > return null; > } > > // the name can be exposed without fear... > public String getDeclaringClassName() { > return declaringClass.getName(); > } > > > This example could be implemented more efficiently then above code (using private Class/ClassLoader API). Absolutely not. This would be orders of magnitude slower than what I've implemented, not to mention that it wouldn't even stop any security problem, if one exists. On can simply use reflection to get the declaringClass field value regardless of what getDeclaringClass returns. N > > Regards, Peter > From mike.duigou at oracle.com Tue Sep 3 17:33:19 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 3 Sep 2013 10:33:19 -0700 Subject: RFR 8024182 test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes In-Reply-To: References: Message-ID: Looks fine to me as well. Mike On Sep 3 2013, at 09:33 , Paul Sandoz wrote: > Hi, > > Due to recent compiler changes a test is failing to compile. > > The fix is already in lambda and needs to be pushed to tl: > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9389 > > Paul. > From blackdrag at gmx.org Tue Sep 3 17:33:54 2013 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 03 Sep 2013 19:33:54 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5225EE3F.6050707@oracle.com> References: <522551AE.7060000@oracle.com> <5225EE3F.6050707@oracle.com> Message-ID: <52261D82.8020308@gmx.org> Am 03.09.2013 16:12, schrieb A. Sundararajan: [...] > If Groovy or any third-party framework gets away with that -- that is > because you need to use modified security policy that gives those > necessary permissions to groovy.jar or whatever third-party jar in > question. just think of us needing to build a runtime structure "copying" what is in a normal class (plus some changes) available in terms of fields and methods. If you don't generate that information (and you cannot for unknown classes), then how can you get that without using reflection and things like getDeclaredMethods. (not to mention several properties and many other things). In other words: it is imho impossible to run even a single Groovy program without giving it some permissions. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From blackdrag at gmx.org Tue Sep 3 17:40:13 2013 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 03 Sep 2013 19:40:13 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5226197F.1050301@gmail.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> Message-ID: <52261EFD.5090801@gmx.org> Am 03.09.2013 19:16, schrieb Peter Levart: [...] > What about a simple restriction on methods returning such instances that > Class objects are only returned when they are resolvable from the > ClassLoader of client code. If they are not resolvable, null is > returned. For example, the equivalent of: > > public class StackTraceFrame { > > private final Class declaringClass; > > @CallerSensitive > public Class getDeclaringClass() { > try { > return Class.forName(declaringClass.getName(), > false, > Reflection.getCallerClass().getClassLoader()) > == declaringClass ? declaringClass : null; > } > } catch (ClassNotFoundException ignore) {} > return null; > } > > // the name can be exposed without fear... > public String getDeclaringClassName() { > return declaringClass.getName(); > } > > > This example could be implemented more efficiently then above code > (using private Class/ClassLoader API). for us it is the standard case, that the client code is not able to resolve the caller class. The code making the call to the method, that needs the information in the end is usually in a sub loader of the loader in which the declaring class of the method making use of the information is. Not always, but usually. Thus this would be useless to us bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From peter.levart at gmail.com Tue Sep 3 17:41:03 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 03 Sep 2013 19:41:03 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <67CFDFA2-1DC6-4CFB-8148-C79398029B68@nicholaswilliams.net> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> <67CFDFA2-1DC6-4CFB-8148-C79398029B68@nicholaswilliams.net> Message-ID: <52261F2F.6000302@gmail.com> On 09/03/2013 07:26 PM, Nick Williams wrote: > On Sep 3, 2013, at 12:16 PM, Peter Levart wrote: > >> On 09/03/2013 04:39 PM, Nick Williams wrote: >>>> Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive. I keep seeing you suggest this and it is unclear to me if you only mean to remove java.lang. at CallerSensitive in your proposal. >>>> >>> Yes, that's what I mean. If you carefully examine the (existing) native code that backs getCallerClass, you see that @CallerSensitive is /only/ used as an enforcement mechanism. When I first read about @CallerSensitive, I /thought/ >>> you could take a call stack like this one: >>> >>> @CallerSensitive getCallerClass() >>> @CallerSensitive someMethod1() >>> @CallerSensitive someMethod2() >>> @CallerSensitive someMethod3() >>> @CallerSensitive someMethod4() >>> actualCallerMethod() >>> >>> And calling getCallerClass would return the class for actualCallerMethod(). However, I was wrong. getCallerClass >>> /always/ returns someMethod1(). @CallerSensitive is /not/ used to determine when to stop looking for the caller. It's just an enforcement mechanism to ensure that only built-in JVM classes can call getCallerClass. >> *AND* that Reflection.getCallerClass() can only be called from within methods annotated with @CallerSensitive. > That's exactly what I said, just worded differently. > >> Now for that part, the public API equivalent (StackTraceFrame.getCallerClass() or whatever it is called) need not be restricted to methods annotated with any annotation, but that means that this public API should not be used to implement security decisions since MethodHandles API allows caller to be spoofed unless looking-up a method annotated with @CallerSensitive... >> >>> This is /not/ how I did it, this is how it already was. Because of this, you could delete the @CallerSensitive annotation completely and getCallerClass still be fully functional the way it is. It just wouldn't be restricted to annotated methods anymore. >> For security unrelated things (like logging and similar) public API need not include any enabling annotation, but it needs to be documented that it should not be used for security decisions. > Now that's a change that makes sense and would certainly be more user-friendly. Keep @CallerSensitive private, but don't require it for StackTraceFrame#getCallerClass()/getCallerFrame(). Document that StackTraceFrame should not be used to make security decisions. Still require @CallerSensitive for Reflection#getCallerClass(). I like this idea. > >> *** >> >> Regarding ability to obtain j.l.Class instances for classes that client code would otherwise have no access to: >> >> What about a simple restriction on methods returning such instances that Class objects are only returned when they are resolvable from the ClassLoader of client code. If they are not resolvable, null is returned. For example, the equivalent of: >> >> public class StackTraceFrame { >> >> private final Class declaringClass; >> >> @CallerSensitive >> public Class getDeclaringClass() { >> try { >> return Class.forName(declaringClass.getName(), >> false, >> Reflection.getCallerClass().getClassLoader()) >> == declaringClass ? declaringClass : null; >> } >> } catch (ClassNotFoundException ignore) {} >> return null; >> } >> >> // the name can be exposed without fear... >> public String getDeclaringClassName() { >> return declaringClass.getName(); >> } >> >> >> This example could be implemented more efficiently then above code (using private Class/ClassLoader API). > Absolutely not. This would be orders of magnitude slower than what I've implemented, Not necessarily. If using internal Class/ClassLoader API (accessible only to java.lang classes, but StackTraceFrame is java.lang class), this might be implemented without security manager checks. > not to mention that it wouldn't even stop any security problem, if one exists. On can simply use reflection to get the declaringClass field value regardless of what getDeclaringClass returns. One can simply use reflection to do practically anything if no security manager is installed. If it is, and security policy does not allow it, then you can not access private fields with reflection. Regards, Peter > > N > >> Regards, Peter >> From david.lloyd at redhat.com Tue Sep 3 17:41:14 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 03 Sep 2013 12:41:14 -0500 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <5226197F.1050301@gmail.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> Message-ID: <52261F3A.3010604@redhat.com> On 09/03/2013 12:16 PM, Peter Levart wrote: > On 09/03/2013 04:39 PM, Nick Williams wrote: >>> >Do you mean sun.reflect.CallerSensitive can go away? This is very >>> important part of the design that we need to detect which methods are >>> caller-sensitive. I keep seeing you suggest this and it is unclear >>> to me if you only mean to remove java.lang. at CallerSensitive in your >>> proposal. >> Yes, that's what I mean. If you carefully examine the (existing) >> native code that backs getCallerClass, you see that @CallerSensitive >> is/only/ used as an enforcement mechanism. When I first read about >> @CallerSensitive, I/thought/ you could take a call stack like this one: >> >> @CallerSensitive getCallerClass() >> @CallerSensitive someMethod1() >> @CallerSensitive someMethod2() >> @CallerSensitive someMethod3() >> @CallerSensitive someMethod4() >> actualCallerMethod() >> >> And calling getCallerClass would return the class for >> actualCallerMethod(). However, I was wrong. getCallerClass/always/ >> returns someMethod1(). @CallerSensitive is/not/ used to determine >> when to stop looking for the caller. It's just an enforcement >> mechanism to ensure that only built-in JVM classes can call >> getCallerClass. > > *AND* that Reflection.getCallerClass() can only be called from within > methods annotated with @CallerSensitive. > > Now for that part, the public API equivalent > (StackTraceFrame.getCallerClass() or whatever it is called) need not be > restricted to methods annotated with any annotation, but that means that > this public API should not be used to implement security decisions since > MethodHandles API allows caller to be spoofed unless looking-up a method > annotated with @CallerSensitive... Using an annotation for security decisions is pretty far off from the standard security model in any case. Why not use a regular permission check? If performance is a concern, the check need only be made one time when an instance is acquired that has these methods on it. >> This is/not/ how I did it, this is how it already was. Because of >> this, you could delete the @CallerSensitive annotation completely and >> getCallerClass still be fully functional the way it is. It just >> wouldn't be restricted to annotated methods anymore. > > For security unrelated things (like logging and similar) public API need > not include any enabling annotation, but it needs to be documented that > it should not be used for security decisions. s/need not/should not/, IMO > *** > > Regarding ability to obtain j.l.Class instances for classes that client > code would otherwise have no access to: > > What about a simple restriction on methods returning such instances that > Class objects are only returned when they are resolvable from the > ClassLoader of client code. If they are not resolvable, null is > returned. For example, the equivalent of: > > public class StackTraceFrame { > > private final Class declaringClass; > > @CallerSensitive > public Class getDeclaringClass() { > try { > return Class.forName(declaringClass.getName(), > false, > Reflection.getCallerClass().getClassLoader()) > == declaringClass ? declaringClass : null; > } > } catch (ClassNotFoundException ignore) {} > return null; > } > > // the name can be exposed without fear... > public String getDeclaringClassName() { > return declaringClass.getName(); > } > > > This example could be implemented more efficiently then above code > (using private Class/ClassLoader API). I don't think this will hold up. Why would (for example) a logging API have access to every class loader that might need to log something? In any system of appreciable size, there is typically at least *some* class loader isolation, often a lot of it. Utilities like logging or security code that need to do this kind of check do not typically have direct access to classes which are "higher on the stack", so to speak. -- - DML From peter.levart at gmail.com Tue Sep 3 18:11:45 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 03 Sep 2013 20:11:45 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <52261F3A.3010604@redhat.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> <52261F3A.3010604@redhat.com> Message-ID: <52262661.5000900@gmail.com> On 09/03/2013 07:41 PM, David M. Lloyd wrote: >> Now for that part, the public API equivalent >> (StackTraceFrame.getCallerClass() or whatever it is called) need not be >> restricted to methods annotated with any annotation, but that means that >> this public API should not be used to implement security decisions since >> MethodHandles API allows caller to be spoofed unless looking-up a method >> annotated with @CallerSensitive... > > Using an annotation for security decisions is pretty far off from the > standard security model in any case. Why not use a regular permission > check? If performance is a concern, the check need only be made one > time when an instance is acquired that has these methods on it. What permission check? @CallerSensitive methods are typically public methods in public classes. Anyone can call them, but no-one should be able to spoof the caller. On 09/03/2013 07:41 PM, David M. Lloyd wrote: >> What about a simple restriction on methods returning such instances that >> Class objects are only returned when they are resolvable from the >> ClassLoader of client code. If they are not resolvable, null is >> returned. For example, the equivalent of: >> > > I don't think this will hold up. Why would (for example) a logging > API have access to every class loader that might need to log > something? In any system of appreciable size, there is typically at > least *some* class loader isolation, often a lot of it. Utilities > like logging or security code that need to do this kind of check do > not typically have direct access to classes which are "higher on the > stack", so to speak. Ok, I understand. What about the other way around - would this be acceptable from security perspective (asking Mandy?): - If you can see me (by name), then you're exposed (I can get you): public class StackTraceFrame { private final Class declaringClass; @CallerSensitive public Class getDeclaringClass() { try { Class cc = Reflection.getCallerClass(); return Class.forName(cc.getName(), false, declaringClass.getClassLoader()) == cc ? declaringClass : null; } catch (ClassNotFoundException ignore) {} return null; } This would not present a problem for JDK system classes since they can not see client code. Regards, Peter From sean.coffey at oracle.com Tue Sep 3 18:15:35 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 03 Sep 2013 19:15:35 +0100 Subject: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets In-Reply-To: <5225EDFC.5010509@oracle.com> References: <5225D031.80008@oracle.com> <5225DCDB.7070606@oracle.com> <5225EDFC.5010509@oracle.com> Message-ID: <52262747.4020500@oracle.com> Mark, > WRT testing, should we be accessing impl classes from tests, keeping > in mind the > desire to restrict access to the corba.impl classes in future jdk > releases? > This then might force this to be a packet level test? Missed this comment. With respect to using the impl classes, I don't see a problem. The package access restriction is only enforced when security manager is present. I'll push ahead with latest proposed changes unless you shout! regards, Sean. On 03/09/2013 15:11, Mark Sheppard wrote: > > It appears to be negative logic. If it's not false then its true. > As the default value is false, would it be less ambiguous if only a > property value of true sets > the keepAlive variable to true? > > if ((value != null) && ("true".equalsIgnoreCase(value)) > keepAlive = true; > > > WRT testing, should we be accessing impl classes from tests, keeping > in mind the > desire to restrict access to the corba.impl classes in future jdk > releases? > This then might force this to be a packet level test? > > regards > Mark > > > On 03/09/2013 13:58, Chris Hegarty wrote: >> Sean, >> >> I remember discussing this (offlist) with you a while back, and I >> agree with the proposed solution. >> >> The logic for checking the system property looks a little odd. But I >> will admit views differ on exactly what values should be accepted. >> So, trivially I would suggest making keepAlive final and always >> setting it in the static initializer. >> >> Otherwise, looks fine to me. >> >> -Chris. >> >> On 09/03/2013 01:04 PM, Se?n Coffey wrote: >>> Sockets created by the >>> com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be >>> affected by firewalls if that connection is left idle for long periods >>> of time. (closed out). A workaround for such an issue could be to >>> have a >>> simple corba thread send some simple ping traffic on the socket at >>> scheduled intervals. That may not be possible for legacy applications. >>> >>> Proposed solution is to add an implementation specific system property >>> flag which would have the keepAlive feature turned on for sockets >>> returned by the CORBA DefaultSocketFactoryImpl class. The >>> application is >>> then in a better position to manage the keepAlive settings via the OS. >>> This had been fixed in Java SE 6 and I'm looking to port the new >>> property to jdk7u & jdk8. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8017195/ >>> >>> regards, >>> Sean. > From mike.duigou at oracle.com Tue Sep 3 18:30:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 3 Sep 2013 11:30:39 -0700 Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates In-Reply-To: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> Message-ID: <8F589CFE-912D-4C6D-8545-BC7EF7ED8A2A@oracle.com> FYI, I have pushed 8024015 but not 8024014. I will have an updated (cleaner) patch for 8024014 shortly. Mike On Aug 29 2013, at 17:13 , Mike Duigou wrote: > Hello all; > > This is a review for two changesets. The first change (JDK-8024014) splits up the jdk_util test group a bit by introducing three sub-groups, jdk_collections, jdk_stream and jdk_concurrent. The main advantage is that it's easier/quicker to test individual components. The intent is that the test groups are aligned with bug database sub-components. > > The second change moves some important lambda related tests from languishing in obscurity in the jdk_other group to the jdk_lang group to reflect their importance and relation to other tests. These tests are contained in the jdk/lambda directory. > > The combined webrev is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/ > > The effect of these changes won't be visible to most people until JDK-8015068 is integrated. > > Thanks, > > Mike From mike.duigou at oracle.com Tue Sep 3 18:29:51 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 03 Sep 2013 18:29:51 +0000 Subject: hg: jdk8/tl/jdk: 8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang Message-ID: <20130903183016.83E8F624D5@hg.openjdk.java.net> Changeset: 4bdbe25b1e04 Author: mduigou Date: 2013-09-03 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbe25b1e04 8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang Reviewed-by: alanb, mchung ! test/TEST.groups From henry.jen at oracle.com Tue Sep 3 18:38:26 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 03 Sep 2013 11:38:26 -0700 Subject: RFR: 8024718: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos Message-ID: <52262CA2.5030203@oracle.com> Hi, Please review a simple webrev at http://cr.openjdk.java.net/~henryjen/tl/8024178/0/webrev/ The reverted change was included as part of JDK-8015318 fix at late stage, after more thoughts, it is not needed. As a collector returns a R can be assigned to ? super R, so we don't really need part. Cheers, Henry From mike.duigou at oracle.com Tue Sep 3 18:41:36 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 3 Sep 2013 11:41:36 -0700 Subject: RFR: 8024718: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos In-Reply-To: <52262CA2.5030203@oracle.com> References: <52262CA2.5030203@oracle.com> Message-ID: <8291BC80-9710-4C59-A1AE-7C821AD5F34D@oracle.com> Looks fine. On Sep 3 2013, at 11:38 , Henry Jen wrote: > Hi, > > Please review a simple webrev at > > http://cr.openjdk.java.net/~henryjen/tl/8024178/0/webrev/ > > The reverted change was included as part of JDK-8015318 fix at late > stage, after more thoughts, it is not needed. > > As a collector returns a R can be assigned to ? super > R, so we don't really need part. > > Cheers, > Henry From henry.jen at oracle.com Tue Sep 3 18:42:39 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 03 Sep 2013 18:42:39 +0000 Subject: hg: jdk8/tl/jdk: 8022176: Weaken contract of java.lang.AutoCloseable Message-ID: <20130903184253.92577624D9@hg.openjdk.java.net> Changeset: 77a8c4ad516c Author: henryjen Date: 2013-08-28 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77a8c4ad516c 8022176: Weaken contract of java.lang.AutoCloseable Reviewed-by: alanb, martin, mduigou, psandoz Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/lang/AutoCloseable.java From henry.jen at oracle.com Tue Sep 3 18:45:02 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 03 Sep 2013 18:45:02 +0000 Subject: hg: jdk8/tl/jdk: 8024178: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos Message-ID: <20130903184516.0465F624DA@hg.openjdk.java.net> Changeset: 3db3ae4e0853 Author: henryjen Date: 2013-09-03 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3db3ae4e0853 8024178: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos Reviewed-by: mduigou ! src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java From david.lloyd at redhat.com Tue Sep 3 18:47:43 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 03 Sep 2013 13:47:43 -0500 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <52262661.5000900@gmail.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> <52261F3A.3010604@redhat.com> <52262661.5000900@gmail.com> Message-ID: <52262ECF.1080505@redhat.com> On 09/03/2013 01:11 PM, Peter Levart wrote: > On 09/03/2013 07:41 PM, David M. Lloyd wrote: >>> Now for that part, the public API equivalent >>> (StackTraceFrame.getCallerClass() or whatever it is called) need not be >>> restricted to methods annotated with any annotation, but that means that >>> this public API should not be used to implement security decisions since >>> MethodHandles API allows caller to be spoofed unless looking-up a method >>> annotated with @CallerSensitive... >> >> Using an annotation for security decisions is pretty far off from the >> standard security model in any case. Why not use a regular permission >> check? If performance is a concern, the check need only be made one >> time when an instance is acquired that has these methods on it. > > What permission check? @CallerSensitive methods are typically public > methods in public classes. Anyone can call them, but no-one should be > able to spoof the caller. Is there some place I can find more information about this (somewhat worrying) aspect of MethodHandles? If this problem applies to getCallerClass() then I'm guessing it applies to SecurityManager's getClassContext() as well, which definitely is used to make security decisions. And what about AccessControlContext and its interactions with the call stack? Same problem? > On 09/03/2013 07:41 PM, David M. Lloyd wrote: >>> What about a simple restriction on methods returning such instances that >>> Class objects are only returned when they are resolvable from the >>> ClassLoader of client code. If they are not resolvable, null is >>> returned. For example, the equivalent of: >>> >> >> I don't think this will hold up. Why would (for example) a logging >> API have access to every class loader that might need to log >> something? In any system of appreciable size, there is typically at >> least *some* class loader isolation, often a lot of it. Utilities >> like logging or security code that need to do this kind of check do >> not typically have direct access to classes which are "higher on the >> stack", so to speak. > > Ok, I understand. What about the other way around - would this be > acceptable from security perspective (asking Mandy?): > > - If you can see me (by name), then you're exposed (I can get you): > > public class StackTraceFrame { > > private final Class declaringClass; > > @CallerSensitive > public Class getDeclaringClass() { > try { > Class cc = Reflection.getCallerClass(); > return Class.forName(cc.getName(), > false, > declaringClass.getClassLoader()) > == cc ? declaringClass : null; > > } catch (ClassNotFoundException ignore) {} > return null; > } > > > This would not present a problem for JDK system classes since they can > not see client code. I'm not sure this solves any real use case either though. In the logging case, you may want to get (for example) the code source of everyone on the stack regardless of whether they can "see" your library. In the end I think there should be a way for a (privileged) caller to get all the information directly. -- - DML From sundararajan.athijegannathan at oracle.com Tue Sep 3 18:56:54 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 04 Sep 2013 00:26:54 +0530 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <52261D82.8020308@gmx.org> References: <522551AE.7060000@oracle.com> <5225EE3F.6050707@oracle.com> <52261D82.8020308@gmx.org> Message-ID: <522630F6.6030403@oracle.com> Agree. I was just pointing that there are 'sensitive' packages and access to sensitive package classes - both normal linking reference and reflective reference by Class.forName - is security access checked. (i.e., there are Class objects that are security access protected as well - not just ClassLoader instances). -Sundar On Tuesday 03 September 2013 11:03 PM, Jochen Theodorou wrote: > Am 03.09.2013 16:12, schrieb A. Sundararajan: > [...] >> If Groovy or any third-party framework gets away with that -- that is >> because you need to use modified security policy that gives those >> necessary permissions to groovy.jar or whatever third-party jar in >> question. > > just think of us needing to build a runtime structure "copying" what > is in a normal class (plus some changes) available in terms of fields > and methods. If you don't generate that information (and you cannot > for unknown classes), then how can you get that without using > reflection and things like getDeclaredMethods. (not to mention several > properties and many other things). > > In other words: it is imho impossible to run even a single Groovy > program without giving it some permissions. > > bye Jochen > From henry.jen at oracle.com Tue Sep 3 19:02:55 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 03 Sep 2013 12:02:55 -0700 Subject: RFR(2nd): 8017513: Support for closeable streams In-Reply-To: <521F1114.3070703@oracle.com> References: <521E6753.9020603@oracle.com> <521EF0F9.3000008@oracle.com> <521F1114.3070703@oracle.com> Message-ID: <5226325F.5000307@oracle.com> Updated webrev is at http://cr.openjdk.java.net/~henryjen/ccc/8017513/2/webrev/ Addressed comments from Alan and catch IOExpression when close on exception in Files method. Cheers, Henry On 08/29/2013 02:15 AM, Alan Bateman wrote: > On 29/08/2013 09:51, Paul Sandoz wrote: >> On Aug 29, 2013, at 8:58 AM, Alan Bateman >> wrote: >> >>> : >>> >>> I think I mentioned this previously but in the Files.list/walk/etc. >>> methods where you close the resource (on error|runtimeexception) then >>> it's probably best to catch the IOException and add it as a >>> suppressed exception. >>> >> Can TWR be used? >> >> try (DirectoryStream ds = Files.newDirectoryStream(dir) { >> ... >> } >> > It should be only closed for the error/exception case (as the Stream > will keep the directory open). > > Henry - Paul's comment reminds of that "one or more" doesn't need to the > javadoc for Files.lines as it only opens one directory. > > -Alan. From brian.burkhalter at oracle.com Tue Sep 3 19:06:23 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 3 Sep 2013 12:06:23 -0700 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> Message-ID: So it looks like there are two decisions to be made on this topic: On Sep 3, 2013, at 1:21 AM, Paul Sandoz wrote: >>> add the following method to BigInteger >>> public boolean isProbablePrime(int certainty, Random end) , >>> which allows primality testing with arbitrary Random objects. >>> In many cases, using a well seeded normal Random object will work >>> just fine, and this will give users the ability to provide their own >>> Random objects >> >> This sounds like a very good solution to me. That way someone can decide whether they want to take the hit with SecureRandom, or if Random is good enough. >> > > Yes. 1) Add BigInteger.isProbablePrime(int certainty, Random rnd) {} >> So offhand, I wouldn't commit to saying if SecureRandom is necessary or not, but it wouldn't surprise me. >> > > My intuition is that the new algorithm for TLR might be sufficient as input to this Monte-Carlo algorithm, but i don't have any hard empirical data. 2) Replace SR with TLR as the default Random in BigInteger.passesMillerRabin(int iterations, Random rnd) {}. Any further comments from those adept at this topic? Brian From mandy.chung at oracle.com Tue Sep 3 19:21:14 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Sep 2013 12:21:14 -0700 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <52262661.5000900@gmail.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> <52261F3A.3010604@redhat.com> <52262661.5000900@gmail.com> Message-ID: <522636AA.6000304@oracle.com> On 9/3/13 11:11 AM, Peter Levart wrote: > On 09/03/2013 07:41 PM, David M. Lloyd wrote: >>> What about a simple restriction on methods returning such instances >>> that >>> Class objects are only returned when they are resolvable from the >>> ClassLoader of client code. If they are not resolvable, null is >>> returned. For example, the equivalent of: >>> >> >> I don't think this will hold up. Why would (for example) a logging >> API have access to every class loader that might need to log >> something? In any system of appreciable size, there is typically at >> least *some* class loader isolation, often a lot of it. Utilities >> like logging or security code that need to do this kind of check do >> not typically have direct access to classes which are "higher on the >> stack", so to speak. > > Ok, I understand. What about the other way around - would this be > acceptable from security perspective (asking Mandy?): I don't think that works for log4j either. In general we should only allow a ClassLoader A to access classes loaded by a ClassLoader B only if B trusts A (i.e A is the same or an ancestor of B); otherwise some kind of permission check (e.g. package access) is required. Log4j wants to access all Class instances on the stack for diagnosibility purpose and unless Log4j is loaded by the bootstrap class loader (put -Xbootclasspath) it may not be able to get access to all classes via Class.forName call. This would probably need a coarse-grained permission than a fine-grained permission check on the indivdual stack frame subject to the ClassLoader/Class. Mandy > > - If you can see me (by name), then you're exposed (I can get you): > > public class StackTraceFrame { > > private final Class declaringClass; > > @CallerSensitive > public Class getDeclaringClass() { > try { > Class cc = Reflection.getCallerClass(); > return Class.forName(cc.getName(), > false, > declaringClass.getClassLoader()) > == cc ? declaringClass : null; > > } catch (ClassNotFoundException ignore) {} > return null; > } > > > This would not present a problem for JDK system classes since they can > not see client code. From henry.jen at oracle.com Tue Sep 3 19:20:56 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 03 Sep 2013 19:20:56 +0000 Subject: hg: jdk8/tl/jdk: 8017513: Support for closeable streams; ... Message-ID: <20130903192122.7985F624DB@hg.openjdk.java.net> Changeset: 2e8d51a5596b Author: henryjen Date: 2013-09-03 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e8d51a5596b 8017513: Support for closeable streams 8022237: j.u.s.BaseStream.onClose() has an issue in implementation or requires spec clarification 8022572: Same exception instances thrown from j.u.stream.Stream.onClose() handlers are not listed as suppressed Summary: BaseStream implements AutoCloseable; Remove CloseableStream and DelegatingStream Reviewed-by: alanb, mduigou, psandoz Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/BaseStream.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/nio/file/Files/StreamTest.java ! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamCloseTest.java From ralph.goers at dslextreme.com Tue Sep 3 19:45:13 2013 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 3 Sep 2013 12:45:13 -0700 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <522636AA.6000304@oracle.com> References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> <52261F3A.3010604@redhat.com> <52262661.5000900@gmail.com> <522636AA.6000304@oracle.com> Message-ID: In Log4j's case the information we want from each StackTraceFrame is: a) the class name, b) the jar or directory where the class resided. c) the version of the jar. d) the ClassLoader associated with the class. Having the actually Class object allows us to get all of this information but if it is deemed more secure to just include all the individual information instead that would be fine. Ralph On Sep 3, 2013, at 12:21 PM, Mandy Chung wrote: > On 9/3/13 11:11 AM, Peter Levart wrote: >> On 09/03/2013 07:41 PM, David M. Lloyd wrote: >>>> What about a simple restriction on methods returning such instances that >>>> Class objects are only returned when they are resolvable from the >>>> ClassLoader of client code. If they are not resolvable, null is >>>> returned. For example, the equivalent of: >>>> >>> >>> I don't think this will hold up. Why would (for example) a logging API have access to every class loader that might need to log something? In any system of appreciable size, there is typically at least *some* class loader isolation, often a lot of it. Utilities like logging or security code that need to do this kind of check do not typically have direct access to classes which are "higher on the stack", so to speak. >> >> Ok, I understand. What about the other way around - would this be acceptable from security perspective (asking Mandy?): > > I don't think that works for log4j either. In general we should only allow a ClassLoader A to access classes loaded by a ClassLoader B only if B trusts A (i.e A is the same or an ancestor of B); otherwise some kind of permission check (e.g. package access) is required. Log4j wants to access all Class instances on the stack for diagnosibility purpose and unless Log4j is loaded by the bootstrap class loader (put -Xbootclasspath) it may not be able to get access to all classes via Class.forName call. > > This would probably need a coarse-grained permission than a fine-grained permission check on the indivdual stack frame subject to the ClassLoader/Class. > > Mandy > >> >> - If you can see me (by name), then you're exposed (I can get you): >> >> public class StackTraceFrame { >> >> private final Class declaringClass; >> >> @CallerSensitive >> public Class getDeclaringClass() { >> try { >> Class cc = Reflection.getCallerClass(); >> return Class.forName(cc.getName(), >> false, >> declaringClass.getClassLoader()) >> == cc ? declaringClass : null; >> >> } catch (ClassNotFoundException ignore) {} >> return null; >> } >> >> >> This would not present a problem for JDK system classes since they can not see client code. > From naoto.sato at oracle.com Tue Sep 3 19:57:14 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 03 Sep 2013 12:57:14 -0700 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation In-Reply-To: <522492A7.2010408@oracle.com> References: <522492A7.2010408@oracle.com> Message-ID: <52263F1A.9000406@oracle.com> Hi Daniel, Just one comment. When you are retrieving the default locale, please use Locale.getDefault(Locale.Category.DISPLAY) which returns the default locale for displaying translatable names. Naoto On 9/2/13 6:29 AM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8016127: NLS: logging.properties translatability recommendation > > > > This fix corrects localized Level names in JDK 8. > > It updates the logging.properties resource bundles to follow > internationalization guidelines: all caps words are usually considered > as constant names that must not be translated - and the base > resource bundle logging.properties - will no longer contain > capitalized names. > > The changeset contains a test that will verify that > the logging.properties bundles are correct - which should > hopefully catch translation issues early int the process and avoid > last minutes fire-drills like we had in the past. > > To make the test pass, I had to replace the untranslated bundles > from JDK 8 by their translated version from JDK 7u-dev. > The fix also makes sure that the Level names will still be printed > in all caps, even if their translation isn't. > > As per Mandy's request I also took this opportunity to fix the > localized name caching mechanism which didn't take into account > possible changes of the default locale returned by > Locale.getDefault(). > > best regards, > > -- daniel From mark.sheppard at oracle.com Tue Sep 3 19:56:16 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 03 Sep 2013 20:56:16 +0100 Subject: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets In-Reply-To: <52262747.4020500@oracle.com> References: <5225D031.80008@oracle.com> <5225DCDB.7070606@oracle.com> <5225EDFC.5010509@oracle.com> <52262747.4020500@oracle.com> Message-ID: <52263EE0.9070007@oracle.com> Sean, yes, that's fine ... no mardy bum from me regards Mark On 03/09/2013 19:15, Se?n Coffey wrote: > Mark, > >> WRT testing, should we be accessing impl classes from tests, keeping >> in mind the >> desire to restrict access to the corba.impl classes in future jdk >> releases? >> This then might force this to be a packet level test? > Missed this comment. With respect to using the impl classes, I don't > see a problem. The package access restriction is only enforced when > security manager is present. I'll push ahead with latest proposed > changes unless you shout! > > regards, > Sean. > > On 03/09/2013 15:11, Mark Sheppard wrote: >> >> It appears to be negative logic. If it's not false then its true. >> As the default value is false, would it be less ambiguous if only a >> property value of true sets >> the keepAlive variable to true? >> >> if ((value != null) && ("true".equalsIgnoreCase(value)) >> keepAlive = true; >> >> >> WRT testing, should we be accessing impl classes from tests, keeping >> in mind the >> desire to restrict access to the corba.impl classes in future jdk >> releases? >> This then might force this to be a packet level test? >> >> regards >> Mark >> >> >> On 03/09/2013 13:58, Chris Hegarty wrote: >>> Sean, >>> >>> I remember discussing this (offlist) with you a while back, and I >>> agree with the proposed solution. >>> >>> The logic for checking the system property looks a little odd. But I >>> will admit views differ on exactly what values should be accepted. >>> So, trivially I would suggest making keepAlive final and always >>> setting it in the static initializer. >>> >>> Otherwise, looks fine to me. >>> >>> -Chris. >>> >>> On 09/03/2013 01:04 PM, Se?n Coffey wrote: >>>> Sockets created by the >>>> com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory >>>> can be >>>> affected by firewalls if that connection is left idle for long periods >>>> of time. (closed out). A workaround for such an issue could be to >>>> have a >>>> simple corba thread send some simple ping traffic on the socket at >>>> scheduled intervals. That may not be possible for legacy applications. >>>> >>>> Proposed solution is to add an implementation specific system property >>>> flag which would have the keepAlive feature turned on for sockets >>>> returned by the CORBA DefaultSocketFactoryImpl class. The >>>> application is >>>> then in a better position to manage the keepAlive settings via the OS. >>>> This had been fixed in Java SE 6 and I'm looking to port the new >>>> property to jdk7u & jdk8. >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8017195/ >>>> >>>> regards, >>>> Sean. >> > From mike.duigou at oracle.com Tue Sep 3 20:08:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 3 Sep 2013 13:08:35 -0700 Subject: RFR: 8021591 : (s) Additional explicit null checks In-Reply-To: <0FF66111-33CD-49C5-89BE-3C2F7F523410@oracle.com> References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> <74270D6C-72EE-4768-98CB-B74E79952C1F@oracle.com> <0FF66111-33CD-49C5-89BE-3C2F7F523410@oracle.com> Message-ID: <128180BB-B45E-46D3-AC85-E6D38FB099B8@oracle.com> On Sep 3 2013, at 02:03 , Paul Sandoz wrote: > > On Aug 28, 2013, at 12:56 AM, Mike Duigou wrote: > >> Hello all; >> >> Here's an updated version of the patch which incorporates feedback and improves the tests (the reason for delay): >> >> http://cr.openjdk.java.net/~mduigou/JDK-8021591/1/webrev/ >> >> The substance of the patch is largely to add missing checks that the collection provided to removeAll()/retainAll() is not null. The specification of these methods in the Collection interface has always indicated that an NPE should be thrown if the passed collection was null. Historically various implementations were inconsistent about whether they threw the NPE if a null collection was passed. Some collections would throw the NPE, some would not. The intent of this patch is to improve consistency and since there were examples of the NPE being correctly thrown the most prudent approach seems to have all implementations throw the NPE. If there had been no examples of the NPE being thrown then it would have been more prudent to amend the interface spec to remove the NPE notice. >> >> A few other inconsistencies around null handling were also resolved. Some unit tests issues were also cleaned up. >> > > Looks OK. > If you have the will I bet you could transform the following pattern repeated in many tests: Heh, all of the test refactoring was a distraction for this patch. I did want to keep going with changes like this but opted to wrap things up and move on with the primary focus of the changeset. Certainly this is a good suggestion though. Mike > > @Test > public void testForEach() throws Exception { > CollectionSupplier> supplier = new CollectionSupplier((Supplier>[]) TEST_CLASSES, SIZE); > for (final CollectionSupplier.TestCase> test : supplier.get()) { ... } > > to: > > @DataProvider(name="CollectionSupplier") > private static Iterator>> CollectionSupplierDataProvider() { > CollectionSupplier> supplier = new CollectionSupplier((Supplier>[]) TEST_CLASSES, SIZE); > return supplier.get(); > } > > @Test(dataProvider = "CollectionSupplier") > public void testForEach(CollectionSupplier.TestCase> test) throws Exception { > > Paul. From brian.burkhalter at oracle.com Tue Sep 3 20:29:11 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 3 Sep 2013 13:29:11 -0700 Subject: Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1 Message-ID: <76888C9E-BFA4-43A7-9DBB-29D47C953C55@oracle.com> JDK 8 Reviewers: Following up on this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/020421.html an approval from a JDK 8 Reviewer is still needed (assuming of course that the change is acceptable). Also, there is the stated question of CCC request necessity. Thanks, Brian From sean.coffey at oracle.com Tue Sep 3 21:38:37 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 03 Sep 2013 21:38:37 +0000 Subject: hg: jdk8/tl/jdk: 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Message-ID: <20130903213858.AB7C2624EB@hg.openjdk.java.net> Changeset: 5920155dd080 Author: coffeys Date: 2013-09-03 22:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5920155dd080 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar + test/com/sun/corba/transport/KeepAliveSockets.java From daniel.fuchs at oracle.com Tue Sep 3 21:59:20 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 03 Sep 2013 23:59:20 +0200 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation In-Reply-To: <52263F1A.9000406@oracle.com> References: <522492A7.2010408@oracle.com> <52263F1A.9000406@oracle.com> Message-ID: <52265BB8.50000@oracle.com> On 9/3/13 9:57 PM, Naoto Sato wrote: > Hi Daniel, > > Just one comment. When you are retrieving the default locale, please > use Locale.getDefault(Locale.Category.DISPLAY) which returns the > default locale for displaying translatable names. Hi Naoto - ResourceBundle.getBundle(String rbName) is documented as returning the same thing than: | getBundle(baseName, Locale.getDefault(), this.getClass().getClassLoader())|, So my changes which replaced ResourceBundle.getBundle(String rbName) with ResourceBundle.getBundle(String rbName, Locale.getDefault()) didn't change anything in that respect. I am curious about why I should be using Locale.getDefault(Locale.Category.DISPLAY) rather than plain |Locale.getDefault()| and perhaps more importantly - in which case I should be using the one rather than the other? best regards, and thanks for your insights! -- daniel > > Naoto > > On 9/2/13 6:29 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a fix for: >> >> 8016127: NLS: logging.properties translatability recommendation >> >> >> >> This fix corrects localized Level names in JDK 8. >> >> It updates the logging.properties resource bundles to follow >> internationalization guidelines: all caps words are usually considered >> as constant names that must not be translated - and the base >> resource bundle logging.properties - will no longer contain >> capitalized names. >> >> The changeset contains a test that will verify that >> the logging.properties bundles are correct - which should >> hopefully catch translation issues early int the process and avoid >> last minutes fire-drills like we had in the past. >> >> To make the test pass, I had to replace the untranslated bundles >> from JDK 8 by their translated version from JDK 7u-dev. >> The fix also makes sure that the Level names will still be printed >> in all caps, even if their translation isn't. >> >> As per Mandy's request I also took this opportunity to fix the >> localized name caching mechanism which didn't take into account >> possible changes of the default locale returned by >> Locale.getDefault(). >> >> best regards, >> >> -- daniel > From naoto.sato at oracle.com Tue Sep 3 22:27:58 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 03 Sep 2013 15:27:58 -0700 Subject: RFR: 8016127 - NLS: logging.properties translatability recommendation In-Reply-To: <52265BB8.50000@oracle.com> References: <522492A7.2010408@oracle.com> <52263F1A.9000406@oracle.com> <52265BB8.50000@oracle.com> Message-ID: <5226626E.1050102@oracle.com> Hi Daniel, Locale.Category was introduced in JDK7 where the user can set the default locales separately for UI display names and Formatting. In your case, the resource bundle seems to contain user visible localizable strings, so I suggested using getDefault() with Locale.Category.DISPLAY specifically. That way the user would see the string in the correct language even on any custom default locale environment. Naoto On 9/3/13 2:59 PM, Daniel Fuchs wrote: > On 9/3/13 9:57 PM, Naoto Sato wrote: >> Hi Daniel, >> >> Just one comment. When you are retrieving the default locale, please >> use Locale.getDefault(Locale.Category.DISPLAY) which returns the >> default locale for displaying translatable names. > Hi Naoto - ResourceBundle.getBundle(String rbName) is documented as > returning the > same thing than: > | getBundle(baseName, Locale.getDefault(), > this.getClass().getClassLoader())|, > So my changes which replaced ResourceBundle.getBundle(String rbName) with > ResourceBundle.getBundle(String rbName, Locale.getDefault()) didn't > change anything in > that respect. > > I am curious about why I should be using > Locale.getDefault(Locale.Category.DISPLAY) rather > than plain |Locale.getDefault()| and perhaps more importantly - in which > case I should > be using the one rather than the other? > > best regards, and thanks for your insights! > > -- daniel > >> >> Naoto >> >> On 9/2/13 6:29 AM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a fix for: >>> >>> 8016127: NLS: logging.properties translatability recommendation >>> >>> >>> >>> This fix corrects localized Level names in JDK 8. >>> >>> It updates the logging.properties resource bundles to follow >>> internationalization guidelines: all caps words are usually considered >>> as constant names that must not be translated - and the base >>> resource bundle logging.properties - will no longer contain >>> capitalized names. >>> >>> The changeset contains a test that will verify that >>> the logging.properties bundles are correct - which should >>> hopefully catch translation issues early int the process and avoid >>> last minutes fire-drills like we had in the past. >>> >>> To make the test pass, I had to replace the untranslated bundles >>> from JDK 8 by their translated version from JDK 7u-dev. >>> The fix also makes sure that the Level names will still be printed >>> in all caps, even if their translation isn't. >>> >>> As per Mandy's request I also took this opportunity to fix the >>> localized name caching mechanism which didn't take into account >>> possible changes of the default locale returned by >>> Locale.getDefault(). >>> >>> best regards, >>> >>> -- daniel >> > From naoto.sato at oracle.com Tue Sep 3 22:35:03 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 03 Sep 2013 15:35:03 -0700 Subject: RFR: JDK-7186632: NLS t13y issue on jar.properties file In-Reply-To: <521F90B2.9000608@oracle.com> References: <521F90B2.9000608@oracle.com> Message-ID: <52266417.2080006@oracle.com> Looks good to me. Naoto On 8/29/13 11:19 AM, Xueming Shen wrote: > Hi, > > Please help review the change for #7186632. > > http://cr.openjdk.java.net/~sherman/7186632/webrev > > The proposed change here is to remove the backslash before the word > "inflated:". While based on j.u.Properties spec it is absolutely legal and > harmless to have a backslash before a non-valid escape character in this > case (the backslash is silently dropped), it appears it may cause confusion > to the non-j.u.Properties-expert localization translator. Given this > backslash > brings no real benefit to the properties file, I decided to just remove it. > (fyi, the reason to insert space character(s) here for "created:" and > "inflated:" > is to keep the output of "created:", "extracted:" and "inflated:" > aligned on > a command line terminal, when "v" option is used, for example jar xvf > foo.jar) > > Thanks! > -Sherman From sean.coffey at oracle.com Tue Sep 3 21:38:13 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 03 Sep 2013 21:38:13 +0000 Subject: hg: jdk8/tl/corba: 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Message-ID: <20130903213814.6AB1C624E9@hg.openjdk.java.net> Changeset: af8e5bc3a150 Author: coffeys Date: 2013-09-03 22:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/af8e5bc3a150 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar ! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java From vicente.romero at oracle.com Tue Sep 3 22:32:39 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 03 Sep 2013 22:32:39 +0000 Subject: hg: jdk8/tl/langtools: 8023389: Javac fails to infer type for lambda used with intersection type and wildcards Message-ID: <20130903223245.6CEFF624F9@hg.openjdk.java.net> Changeset: fb5a846c4a49 Author: vromero Date: 2013-09-03 23:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fb5a846c4a49 8023389: Javac fails to infer type for lambda used with intersection type and wildcards Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/8023389/T8023389.java From mike.duigou at oracle.com Tue Sep 3 22:27:52 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 03 Sep 2013 22:27:52 +0000 Subject: hg: jdk8/tl: 8024200: handle hg wrapper with space after #! Message-ID: <20130903222753.16AF5624F7@hg.openjdk.java.net> Changeset: 6d7f27953da6 Author: mduigou Date: 2013-09-03 15:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6d7f27953da6 8024200: handle hg wrapper with space after #! Reviewed-by: tbell ! common/bin/hgforest.sh From vicente.romero at oracle.com Tue Sep 3 22:48:35 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 03 Sep 2013 22:48:35 +0000 Subject: hg: jdk8/tl/langtools: 8023545: Misleading error message when using diamond operator with private constructor Message-ID: <20130903224838.B0601624FC@hg.openjdk.java.net> Changeset: 9be0afbdf244 Author: vromero Date: 2013-09-03 23:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9be0afbdf244 8023545: Misleading error message when using diamond operator with private constructor Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T8023545/MisleadingErrorMsgDiamondPlusPrivateCtorTest.java + test/tools/javac/T8023545/MisleadingErrorMsgDiamondPlusPrivateCtorTest.out From vicente.romero at oracle.com Tue Sep 3 23:02:41 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 03 Sep 2013 23:02:41 +0000 Subject: hg: jdk8/tl/langtools: 8023549: Compiler emitting spurious errors when constructor reference type is inferred and explicit type arguments are supplied Message-ID: <20130903230245.08C30624FD@hg.openjdk.java.net> Changeset: 438547d895dc Author: vromero Date: 2013-09-04 00:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/438547d895dc 8023549: Compiler emitting spurious errors when constructor reference type is inferred and explicit type arguments are supplied Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/MrefInferAndExplicitParams.java + test/tools/javac/lambda/8023549/T8023549.java + test/tools/javac/lambda/8023549/T8023549.out From henry.jen at oracle.com Tue Sep 3 23:06:21 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 03 Sep 2013 23:06:21 +0000 Subject: hg: jdk8/tl/jdk: 8023997: j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect Message-ID: <20130903230634.D79CA624FE@hg.openjdk.java.net> Changeset: 06b01083ebd7 Author: henryjen Date: 2013-09-03 16:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06b01083ebd7 8023997: j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect Reviewed-by: alanb ! src/share/classes/java/lang/String.java From mike.duigou at oracle.com Tue Sep 3 23:23:14 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 3 Sep 2013 16:23:14 -0700 Subject: RFR: 8024014 : (xs) TEST.groups updates In-Reply-To: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> Message-ID: <7E2223FB-8B0B-4000-8CDD-EE25461E0DB7@oracle.com> Hello all; Here is an updated webrev of just 8024014: http://cr.openjdk.java.net/~mduigou/JDK-8024014/0/webrev/ The controversial item here is the definition of the jdk_collections group which, since collections isn't aligned to a directory, is defined by a list of sub-directories. Since the list of files is quite static and would not have changed since Java 6 (except for jdk_stream) I think we should be able to tolerate the not-too-long list of files for the jdk_collections category. Other opinions? Mike On Aug 29 2013, at 17:13 , Mike Duigou wrote: > Hello all; > > This is a review for two changesets. The first change (JDK-8024014) splits up the jdk_util test group a bit by introducing three sub-groups, jdk_collections, jdk_stream and jdk_concurrent. The main advantage is that it's easier/quicker to test individual components. The intent is that the test groups are aligned with bug database sub-components. > > The second change moves some important lambda related tests from languishing in obscurity in the jdk_other group to the jdk_lang group to reflect their importance and relation to other tests. These tests are contained in the jdk/lambda directory. > > The combined webrev is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/ > > The effect of these changes won't be visible to most people until JDK-8015068 is integrated. > > Thanks, > > Mike From henry.jen at oracle.com Tue Sep 3 23:26:24 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 03 Sep 2013 16:26:24 -0700 Subject: RFR: 8023997 : j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect In-Reply-To: <52204F72.90802@oracle.com> References: <52203F4A.102@oracle.com> <52204F72.90802@oracle.com> Message-ID: <52267020.2020705@oracle.com> On 08/30/2013 12:53 AM, Alan Bateman wrote: > On 30/08/2013 07:44, Henry Jen wrote: >> Hi, >> >> Please kindly review a simple webrev that just fixes a sample in the >> javadoc of String.join(). >> >> http://cr.openjdk.java.net/~henryjen/tl/8023997/0/webrev/ >> > This looks okay to me. > Thanks, I pushed it as is. > I note in the bug report that the example is considered normative but > that doesn't seem right (at least I've always thought of examples/code > fragments in the javadoc as just helpful, but non-normative, text). So > maybe the bug report is also looking for @apiNote to be added? > I tend to agree. I leave it for now because - Other methods in String have code examples documented the same way - In some sense, the example helps to clarify spec, and itself like test cases. If this matters much, should we file a bug to review code examples in String and decide what is proper for each example? In this case, I do feel it is redundant as there are two examples. Perhaps the second one should remain HashSet as a special note that Iterable sequence matters. Cheers, Henry From dl at cs.oswego.edu Tue Sep 3 23:46:10 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 03 Sep 2013 19:46:10 -0400 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> Message-ID: <522674C2.8050802@cs.oswego.edu> On 09/03/2013 03:06 PM, Brian Burkhalter wrote: > So it looks like there are two decisions to be made on this topic: > > On Sep 3, 2013, at 1:21 AM, Paul Sandoz wrote: > >>>> add the following method to BigInteger >>>> public boolean isProbablePrime(int certainty, Random end) , >>>> which allows primality testing with arbitrary Random objects. >>>> In many cases, using a well seeded normal Random object will work >>>> just fine, and this will give users the ability to provide their own >>>> Random objects >>> >>> This sounds like a very good solution to me. That way someone can decide whether they want to take the hit with SecureRandom, or if Random is good enough. >>> >> >> Yes. > > 1) Add BigInteger.isProbablePrime(int certainty, Random rnd) {} > >>> So offhand, I wouldn't commit to saying if SecureRandom is necessary or not, but it wouldn't surprise me. >>> >> >> My intuition is that the new algorithm for TLR might be sufficient as input to this Monte-Carlo algorithm, but i don't have any hard empirical data. > > 2) Replace SR with TLR as the default Random in BigInteger.passesMillerRabin(int iterations, Random rnd) {}. > > Any further comments from those adept at this topic? I assume you mean to change line 898: if (rnd == null) { rnd = ThreadLocalRandom.current();; // was: getSecureRandom(); } This seems fine in terms of sufficient RNG quality and better performance. Also in terns of being for sure thread-safe even though it uses no locks/sync: there are no possible async or parallel calls from entry into this method, so using thread-local one is fine. The new SplittableRandom class might be a better choice but can't be used here because it doesn't subclass Random. Oh well. -Doug From joe.darcy at oracle.com Tue Sep 3 23:48:01 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 03 Sep 2013 16:48:01 -0700 Subject: Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1 In-Reply-To: <76888C9E-BFA4-43A7-9DBB-29D47C953C55@oracle.com> References: <76888C9E-BFA4-43A7-9DBB-29D47C953C55@oracle.com> Message-ID: <52267531.6030801@oracle.com> Hi Brian, I'd appreciate some additional comments in the body of the code explaining what is attempted to be implemented. On the ccc front, since a behavioral change is presumably being made for a few values, a ccc is justified. Thanks, -Joe On 9/3/2013 1:29 PM, Brian Burkhalter wrote: > JDK 8 Reviewers: > > Following up on this thread > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/020421.html > > an approval from a JDK 8 Reviewer is still needed (assuming of course that the change is acceptable). > > Also, there is the stated question of CCC request necessity. > > Thanks, > > Brian From brian.burkhalter at oracle.com Tue Sep 3 23:52:04 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 3 Sep 2013 16:52:04 -0700 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: <522674C2.8050802@cs.oswego.edu> References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> <522674C2.8050802@cs.oswego.edu> Message-ID: On Sep 3, 2013, at 4:46 PM, Doug Lea wrote: > I assume you mean to change line 898: > > if (rnd == null) { > rnd = ThreadLocalRandom.current();; // was: getSecureRandom(); > } Yes. > This seems fine in terms of sufficient RNG quality and better > performance. Also in terns of being for sure thread-safe > even though it uses no locks/sync: there are no possible async > or parallel calls from entry into this method, so using > thread-local one is fine. Thanks for the comments. One question I have is whether this change would still be needed if public boolean isProbablePrime(int certainty, Random rnd) {} were added. Brian From brian.burkhalter at oracle.com Tue Sep 3 23:52:53 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 3 Sep 2013 16:52:53 -0700 Subject: Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1 In-Reply-To: <52267531.6030801@oracle.com> References: <76888C9E-BFA4-43A7-9DBB-29D47C953C55@oracle.com> <52267531.6030801@oracle.com> Message-ID: Hi Joe, I will proceed on these two points. Thanks, Brian On Sep 3, 2013, at 4:48 PM, Joe Darcy wrote: > I'd appreciate some additional comments in the body of the code explaining what is attempted to be implemented. > > On the ccc front, since a behavioral change is presumably being made for a few values, a ccc is justified. From mandy.chung at oracle.com Wed Sep 4 00:02:07 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Sep 2013 17:02:07 -0700 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: References: Message-ID: <5226787F.6060307@oracle.com> Nick, I skimmed through the changes. Congratulations for your first patch making changes in both hotspot and jdk code. In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class / loader to lookup resources. While the new APIs might be in the same class, I will discuss them individually and keep us focus one at a time. Ralph has pointed out [1] that Log4j also needs the ability to find an appropriate ClassLoader which is used for logging separation (thank you Ralph). That will be the caller-sensitivity (i.e. obtain caller's class/loader) discussion. There are a couple of RFEs: https://bugs.openjdk.java.net/browse/JDK-4942697 https://bugs.openjdk.java.net/browse/JDK-6349551 Performance is critical for Log4j to traverse the stack trace and obtain Class information. I like your patch to speed up the generation of StackTraceElement[] (and StackTraceFrame[] - essentially same code with different type). java.util.logging.LogRecord has workaround the performance overhead and go to a specific frame directly and avoid the cost of generating the entire array. JDK-6349551 requests to lazily instantiate the StackTraceElement object unless that frame is requested. Does Log4J always walk all frames and log all information? Do you just log only some max number of frames rather than the entire stack trace? Class getDeclaringClass() method is the key method you need to enhance the diagnosability. This method opens up a new way to access a Class instance that untrusted code wouldn't be able in the past. A permission check is needed as Alan points out early. Performance as well as logging framework can't access all class loaders are two factors to be considered when defining the permission check. I saw your other comment about permission check (cut-n-paste below). It seems to me that you don't agree a permission check is needed for the getDeclaringClass() method (regardless of which class it belongs to) and if that's the case, no point to continue. I want to make it very clear that I have agreed to take this on and provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases. It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time). The second comment on your patch is that there are lot of duplicated code in hotspot in order to support two similar but different types (StackTraceFrame and StackTraceElement). Serialization is the reason leading you to have a new StackTraceFrame class. Maybe some refactoring can help but this is the cost of having the VM directly creating the instance. One other option, as suggested in the previous thread, is to keep the declaring class in the StackTraceElement as a transient field. If we add the getDeclaringClass method in the StackTraceElement class, it would need to specify to be optional that it only returns the Class instance when it's available. There are currently three different ways to get a stack trace: 1. Throwable.getStackTrace() 2. Thread.getStackTrace() and Thread.getAllStackTraces() 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int maxDepth).getStackTrace() and multiple thread IDs version (a) local (b) remote Since it's a new StackTraceFrame class, you have to provide a new method replacing #1 and #2. I don't see any need to provide a new API equivalent to Thread.getAllStackTraces() and java.lang.management. The proposal I originally have last week was to keep declaring class as transient and add a method in StackTraceElement with a permission check at every call. Tom raises a good question about the cost of permission check. Would that be a concern to Log4j? Is log4j on bootclasspath or extension directory? I assume not. So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm? For example it calls sun.reflect.Reflection.getCallerClass method that will require RuntimePermission("accessClassInPackage.sun.reflect") permission. Calling Class.getProtectionDomain and Class.getClassLoader() requires RuntimePermission("getProtectionDomain") and RuntimePermission("getClassLoader") respectively. That gives me an impression that permission check on individual stack frame might be a non-issue? Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html On 9/3/13 5:24 AM, Nick Williams wrote: > On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: >>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. >> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API. > As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should! > > Nick On 9/1/13 1:16 AM, Nick Williams wrote: > I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). > > I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. > > *Summary of Changes* > Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: > > Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. > > Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. > > StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. > > StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. > > StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. > > StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. > > As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. > > I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. > > However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). > > Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. > > I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! > > *The Code Changes* > I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): > > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch > https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch > > I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. > > Thanks! > > Nick From dl at cs.oswego.edu Wed Sep 4 00:09:29 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 03 Sep 2013 20:09:29 -0400 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> <522674C2.8050802@cs.oswego.edu> Message-ID: <52267A39.6090807@cs.oswego.edu> On 09/03/2013 07:52 PM, Brian Burkhalter wrote: > On Sep 3, 2013, at 4:46 PM, Doug Lea wrote: > >> I assume you mean to change line 898: >> >> if (rnd == null) { >> rnd = ThreadLocalRandom.current();; // was: getSecureRandom(); >> } > > Yes. > >> This seems fine in terms of sufficient RNG quality and better >> performance. Also in terns of being for sure thread-safe >> even though it uses no locks/sync: there are no possible async >> or parallel calls from entry into this method, so using >> thread-local one is fine. > > Thanks for the comments. One question I have is whether this change would still > be needed if > > public boolean isProbablePrime(int certainty, Random rnd) {} > > were added. > It would not be necessary, since passesMillerRabin is only called from isProbablePrime, which would then use non-null argument. Only adding isProbablePrime seems to be an OK conservative move: no existing usages would be affected, but users would need to somehow be told that they could improve performance by changing their code to use the new method with ThreadLocalRandom.current() as argument. -Doug From brian.burkhalter at oracle.com Wed Sep 4 00:11:09 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 3 Sep 2013 17:11:09 -0700 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: <52267A39.6090807@cs.oswego.edu> References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> <522674C2.8050802@cs.oswego.edu> <52267A39.6090807@cs.oswego.edu> Message-ID: <3BBEBBC7-FE5B-47BE-9138-C1292404ABC1@oracle.com> On Sep 3, 2013, at 5:09 PM, Doug Lea wrote: > Only adding isProbablePrime seems to be an OK conservative > move: no existing usages would be affected, but users would > need to somehow be told that they could improve performance > by changing their code to use the new method with > ThreadLocalRandom.current() as argument. This is what I was thinking. Some verbiage update would be in order. Thanks, Brian From mandy.chung at oracle.com Wed Sep 4 00:33:18 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Sep 2013 17:33:18 -0700 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <52259B13.8060100@gmx.org> References: <522551AE.7060000@oracle.com> <52259B13.8060100@gmx.org> Message-ID: <52267FCE.70207@oracle.com> On 9/3/13 1:17 AM, Jochen Theodorou wrote: >> Defining a SE supported @CallerSensitive and also getCallerClass API >> poses the risk of "encouraging" developers to implement more @CS methods >> while not fully understand its implication. > > Again I am curious... what is such an implication? That your method > will behave different depending on from where it got called and, > depending on if that is from an expected or unexpected source, you may > get an expected or unexpected result here? *and* this could lead to surprises and hard-to-diagnose issue to any framework/library or even another API provided in the same library calling a caller-sensitive method that can't tell if they get the true caller or not. Caller-sensitivity is used in getting the right visibility (e.g. Resource.getBundle and Class.forName) and for security checks. The platform's caller-sensitive methods involve both visibility and security. For the former (visiability): the use cases of getCallerClass are mostly for gaining visibility to avoid having the client code to supply the appropriate ClassLoader or Class. Such convenience has led to the existing stack walking code to search for a ClassLoader that it can find what the client code is asking for - it's not impossible that it might find the wrong ClassLoader but that happens to find a resource with the same name. For the latter (security), caller sensitive methods have kept us having "so much fun" in the past CPU releases. Groovy/log4j and other existing framework has already dealt with such problem and written some non-trivial code to solve this problem. My point is more about the general app developers that need education and big warning in the documentation before they attempt learning this API to get the immediate caller. Couple months ago a few of us discussed some security issues we had fixed in the past and evaluated what we could do about them - one thing we want to do is to remove the caller sensitive-ness. This is certainly a big big change and high compatibility risk - some future work. Just to give you a sense how serious we are the security issue around caller-sensitive methods. I'm happy to know that you will build into Groovy 3.x the ability to transport the caller class from the Groovy class. I strongly believe this is the right thing to do and use the ResourceBundle.getBundle and Class.forName with the ClassLoader parameter. No filtering and no magic caller class API as you said. I have replied to Nick's patch with the focus on the ability to get Class instance from stack trace for diagnosability purpose. I will soon bring up the discussion on the ability to get caller's Class / ClassLoader use case. Until tomorrow. Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html From mandy.chung at oracle.com Wed Sep 4 01:47:01 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Sep 2013 18:47:01 -0700 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <5226787F.6060307@oracle.com> References: <5226787F.6060307@oracle.com> Message-ID: <52269115.3030802@oracle.com> Just realize that I missed a few words in a sentence that could mislead what I really mean.... correction below. On 9/3/2013 5:02 PM, Mandy Chung wrote: > Nick, > > I skimmed through the changes. Congratulations for your first patch > making changes in both hotspot and jdk code. > > In my mind, the Log4J use case accessing Class instance to obtain > additional information for diagnosability is different than the use > case of obtaining the caller's class / loader to lookup resources. > While the new APIs might be in the same class, I will discuss them > individually and keep us focus one at a time. > > Ralph has pointed out [1] that Log4j also needs the ability to find an > appropriate ClassLoader which is used for logging separation (thank > you Ralph). That will be the caller-sensitivity (i.e. obtain caller's > class/loader) discussion. > > There are a couple of RFEs: > https://bugs.openjdk.java.net/browse/JDK-4942697 > https://bugs.openjdk.java.net/browse/JDK-6349551 > > Performance is critical for Log4j to traverse the stack trace and > obtain Class information. I like your patch to speed up the > generation of StackTraceElement[] (and StackTraceFrame[] - essentially > same code with different type). java.util.logging.LogRecord has > workaround the performance overhead and go to a specific frame > directly and avoid the cost of generating the entire array. > JDK-6349551 requests to lazily instantiate the StackTraceElement > object unless that frame is requested. Does Log4J always walk all > frames and log all information? Do you just log only some max number > of frames rather than the entire stack trace? > > Class getDeclaringClass() method is the key method you need to > enhance the diagnosability. This method opens up a new way to access > a Class instance that untrusted code wouldn't be able in the past. A > permission check is needed as Alan points out early. Performance as > well as logging framework can't access all class loaders are two > factors to be considered when defining the permission check. > > I saw your other comment about permission check (cut-n-paste below). > It seems to me that you don't agree a permission check is needed for > the getDeclaringClass() method (regardless of which class it belongs > to) and if that's the case, no point to continue. > > I want to make it very clear that I have agreed to take this on and > provide a replacement of sun.reflect.Reflection.getCallerClass(int) in > JDK 8 to address the use cases. It will take time for the API and > security discussion and please be prepared for that (also I am working > on other things at the same time). > What I really meant is: I want to make it very clear that I have agreed to take this to come to a conclusion and ensure to provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases. It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time). Mandy > The second comment on your patch is that there are lot of duplicated > code in hotspot in order to support two similar but different types > (StackTraceFrame and StackTraceElement). Serialization is the reason > leading you to have a new StackTraceFrame class. Maybe some > refactoring can help but this is the cost of having the VM directly > creating the instance. One other option, as suggested in the previous > thread, is to keep the declaring class in the StackTraceElement as a > transient field. If we add the getDeclaringClass method in the > StackTraceElement class, it would need to specify to be optional that > it only returns the Class instance when it's available. > > There are currently three different ways to get a stack trace: > 1. Throwable.getStackTrace() > 2. Thread.getStackTrace() and Thread.getAllStackTraces() > 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int > maxDepth).getStackTrace() and multiple thread IDs version > (a) local (b) remote > > Since it's a new StackTraceFrame class, you have to provide a new > method replacing #1 and #2. I don't see any need to provide a new API > equivalent to Thread.getAllStackTraces() and java.lang.management. > > The proposal I originally have last week was to keep declaring class > as transient and add a method in StackTraceElement with a permission > check at every call. Tom raises a good question about the cost of > permission check. Would that be a concern to Log4j? Is log4j on > bootclasspath or extension directory? I assume not. So for log4j to > work with security manager installed, it would have torequire the > application to grant certain permissions - can you confirm? For > example it calls sun.reflect.Reflection.getCallerClass method that > will require RuntimePermission("accessClassInPackage.sun.reflect") > permission. Calling Class.getProtectionDomain and > Class.getClassLoader() requires > RuntimePermission("getProtectionDomain") and > RuntimePermission("getClassLoader") respectively. That gives me an > impression that permission check on individual stack frame might be a > non-issue? > > Mandy > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html > > On 9/3/13 5:24 AM, Nick Williams wrote: >> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: >>>> I'm not voicing any objection to any kind of security/permissions >>>> checks in these methods. Before I can pass judgement one way or >>>> another, I'd want to know 1) specifically what type of permissions >>>> check you are looking for, and 2) what you're looking to achieve >>>> with said permissions check. >>> I would say this is TBD and start by asking the question as to >>> whether there are concerns about leaking reference to Class objects >>> that untrusted code wouldn't normally be able to get a reference to. >>> Tom brings up the cost of the permission check and also whether any >>> API should be tied to class loader. There are clearly discussion >>> points here that could potentially influence the API. >> As I have said before, there are MANY ways to get a Class object that >> aren't security checked. It's when you try to USE that class object >> to impersonate it or invoke methods that security checks begin to >> happen. As they should! >> >> Nick > > > > On 9/1/13 1:16 AM, Nick Williams wrote: >> I have completed and am proposing a patch for replacing >> sun.reflect.Reflection#getCallerClass(...) with a public API in Java >> 8. I saw no point in duplicating an issue, even though it's over 10 >> years old, so I'm indicating that this is a patch for 4851444 >> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). >> >> I welcome and solicit support/+1s and a sponsor. Someone about a >> month ago had mentioned that they would be willing to be a sponsor if >> the patch looked good, but I can't remember who it was and I can't >> find the email. I want to say it was someone with RedHat, but my >> memory could be faulty, so please don't hold it against me if I'm wrong. >> >> *Summary of Changes* >> Added the new class java.lang.StackTraceFrame. It's a virtual mirror >> of StackTraceElement, except that it contains a Class >> declaringClass property instead of a String className property. Since >> the list members expressed reluctance to add methods to Thread and >> Throwable, StackTraceFrame also contains several static methods for >> retrieving Classes and StackTraceFrames from the stack. These methods >> are as follows: >> >> Class getCallerClass(): Retrieves the class of the caller of the >> method calling getCallerClass(). This is identical to the new >> Reflection#getCallerClass() added in Java 7u25/8. >> >> Class getCallerClass(int): Retrieves the class of the caller n >> frames down the stack. This is identical to the old >> Reflection#getCallerClass(int) that was deprecated in Java 7u25 and >> removed in Java 8. >> >> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of >> the line of code that called the method calling getCallerClass(). >> This is similar to the new Reflection#getCallerClass() added in Java >> 7u25/8, except that it returns a StackTraceFrame. >> >> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of >> the caller n frames down the stack. This is similar to the old >> Reflection#getCallerClass(int), except that it returns a >> StackTraceFrame. >> >> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to >> Thread#getStackTrace(), except that it returns an array of >> StackTraceFrames. >> >> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally >> equivalent to Throwable#getStackTrace(), except that it returns an >> array of StackTraceFrames. It uses the same save point (backtrace) >> created when the Throwable is created that Throwable#getStackTrace() >> uses when it's first called. It caches the array of StackTraceFrames >> in the Throwable just like the array of StackTraceElements are >> cached, so that multiple calls for the same Throwable are fast. >> >> As a result of this change, sun.reflect.CallerSensitive has been >> moved to java.lang.CallerSensitive. >> >> I spent considerable time reviewing, revising, considering, and >> testing these changes. I included several unit tests that establish >> the proper behavior. I also spent considerable time benchmarking the >> changes. While benchmarking, I noticed some things. First, >> getCallerClass() and getCallerClass(int) are as fast as their >> counterparts in sun.reflect.Reflection, and they easily inline when >> appropriate. Second, getCallerFrame() and getCallerFrame(int) are >> /almost/ as fast as the Class versions, but there is some additional >> overhead for the construction of the StackTraceFrame. This is >> minuscule (1,000,000 invocations consume around 500 ms total on my >> machine). At this point, all of the benchmarking was as expected. >> >> However, I then encountered a surprise. The getCurrentStackTrace() >> and getStackTrace(Throwable) methods executed (again, 1,000,000 >> times) in about 70% of the time that Thread#getStackTrace() and >> Throwable#getStackTrace() did, respectively. Theoretically, they >> should have executed in the same amount of time, not faster. After >> extensive analysis, I discovered (what I considered to be) a serious >> flaw in how the stack trace is filled in within Throwable (which also >> affects how Thread#getStackTrace() works). >> >> Instead of simply iterating over the entire save point and filling in >> the Throwable stack trace in native code (which is what I did when I >> implemented the StackTraceFrame methods), the Java code in Throwable >> first called a native method to figure out how deep the stack was, >> then called another native method once for every frame in the stack >> to retrieve each element individually. This native method that is >> called repeatedly iterates over the entire backtrace once for each >> call, stopping only when it finds the matching element (so it's O(1) >> for the first call, O(2) for the second call, O(3) for the third >> call, and so on). While my StackTraceFrame methods were iterating >> over the backtrace exactly 1 time (O(n)), the Throwable methods were >> iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but >> not as bad as O(n^2)). This problem would not have been extremely >> apparent over small stack traces (the 30% improvement was a stack >> trace of 6 elements), but over a large (200+ elements) stack traces >> the performance difference would be huge and noticeable. Seeing a >> room for improvement, I refactored the code that fills in the stack >> trace for Throwable, improving its performance accordingly to match >> the performance of the StackTraceFrame methods. >> >> I'm very pleased with how this turned out, and both the unit tests >> and my extensive functional testing show that the new class and its >> methods are working great. I just need someone willing to review and >> sponsor my patch! >> >> *The Code Changes* >> I couldn't get WebRev to run without all kinds of errors. So I ran >> `hg diff -g` on every repository in the forest with changes. Here are >> the four patch files for the four repositories that had changes (no >> other repositories had changes): >> >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch >> >> I believe I have followed all of the procedures as closely as >> possible. I await feedback and hope for some support on this, so that >> we can get a public replacement for this method in Java 8. Let me >> know if you have any questions. >> >> Thanks! >> >> Nick > > From david.holmes at oracle.com Wed Sep 4 02:20:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Sep 2013 12:20:36 +1000 Subject: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo In-Reply-To: <5225E02E.9060200@oracle.com> References: <52255162.9010907@oracle.com> <522595FF.3070709@oracle.com> <52259D39.6090906@oracle.com> <5225E02E.9060200@oracle.com> Message-ID: <522698F4.1000303@oracle.com> On 3/09/2013 11:12 PM, roger riggs wrote: > Hi, > > There are going to be some gaps in compact1 testing if TestNG tests > are omitted. For example, all of java.time uses TestNg exclusively. Yes I noticed. :( > The java.time tests do not use the XML input file configuration options > so perhaps the dependency on XML can be broken. If the java.time folk can do that that is great, but they are not alone as a lot of the new lambda related tests also use testng. David > Roger > > On 9/3/2013 4:26 AM, David Holmes wrote: >> >> >>> As regards the definitions then one observation is the TestNG tests that >>> you've listed in needs_compact2 are actually compact1 tests. I wonder if >>> this is a TestNG dependency on XML rather than dependencies in the test >>> themselves. >> >> Yes. As noted in the file the dependencies are not only what is being >> tested but what test infrastructure is being used. The testng tests >> uses xml which restricts them to compact2. Some tests use jps/jcmd or >> tools.jar which restricts them to a full jdk. > From david.holmes at oracle.com Wed Sep 4 03:46:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Sep 2013 13:46:24 +1000 Subject: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo In-Reply-To: <52255162.9010907@oracle.com> References: <52255162.9010907@oracle.com> Message-ID: <5226AD10.9020603@oracle.com> With thanks to Alan and Chris for their reviews I will push this initial set of group definitions. David On 3/09/2013 1:02 PM, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/8024140/webrev/ > > Similar to what was recently done on the hotspot side, this introduces > profile-based test groups for the jdk regression tests. > > The primary groups are: > - jdk > - jre > - compact3 > - compact2 > - compact2_minimal > - compact1 > - compact1_minimal > > The minimal VM is only supported on compact1 and compact2. > > The groups are defined hierarchically in two forms: > - The need_xxx groups list all the tests that have a dependency on a > specific profile. This is either because it tests a feature in that > profile, or the test infrastructure uses a feature in that profile. > - The primary groups are defined in terms of the other primary groups > combined with the needs_xxx groups (including and excluding them as > appropriate). For example the jre can run all tests from compact3, plus > those from needs_jre, but excluding those from need_jdk. > > The bottom group defines all the actual tests to be considered, simply > by listing the top-level test directories, and then excluding all the > needs_xxx groups. > > To select a group of tests you use : > > Eg to run only those tests that can run on compact1 use: > > jtreg :compact1 > > Of course you still need to point jtreg at the right kind of runtime > image (and give it a full JDK as the compile-jdk!); and if testing the > minimal VM you need to tell jtreg to select it using -javaoptions:-minimal > > These top-level groups are not as useful standalone as they are for > hotspot due to the fact that there are so many regression tests that are > problematic in one way or another. In most cases what is desired is a > way to run sub-set of tests for a given profile eg all jdk_core tests > that can run on compact1. At present this would require a new group to > be defined for each permutation and that is not scalable. I hope that in > the near future jtreg will allow you to implicitly define such ad-hoc > groups via the command-line, simply by listing groups to include and > groups to exclude. > > The full jtreg group facility is only available in the most recent jtreg > builds, so you will need to grab the latest nightly build, or latest > sources. > > Note: once this is in place, anyone writing regression tests will need > to be aware of whether that test is limited to certain profiles and > update the group file accordingly. Sometimes it is not the item being > tested that determines the minimum needed profile, but the test > infrastructure eg if it uses XML. > > See TEST.groups for more information. > > Note: The initial group definitions proposed here are not complete. > There are over 4000 tests of the "desktop" that can not be readily > executed manually and it may be that a number of these tests will > require a JDK rather than the full JRE. Our full test processes will > discover this and update the lists as needed. (Or we fix the tests to > not need full JDKs.) > > Thanks, > David From david.holmes at oracle.com Wed Sep 4 03:52:51 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 04 Sep 2013 03:52:51 +0000 Subject: hg: jdk8/tl/jdk: 8024140: [TESTBUG] Profile based regression test groups for jdk repo Message-ID: <20130904035308.EA4B662504@hg.openjdk.java.net> Changeset: 2cdd1078f45b Author: dholmes Date: 2013-09-03 23:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cdd1078f45b 8024140: [TESTBUG] Profile based regression test groups for jdk repo Reviewed-by: alanb, chegar ! test/TEST.groups From robert.field at oracle.com Wed Sep 4 04:44:02 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 04 Sep 2013 04:44:02 +0000 Subject: hg: jdk8/tl/jdk: 8008688: Make MethodHandleInfo public Message-ID: <20130904044413.E99EF62509@hg.openjdk.java.net> Changeset: 4bdbd1fabea4 Author: rfield Date: 2013-09-03 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbd1fabea4 8008688: Make MethodHandleInfo public Summary: A major overhaul to MethodHandleInfo and method handles in general. Reviewed-by: vlivanov, twisti Contributed-by: john.r.rose at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + src/share/classes/java/lang/invoke/InfoFromMemberName.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/SerializedLambda.java ! test/java/lang/invoke/7087570/Test7087570.java + test/java/lang/invoke/RevealDirectTest.java + test/java/lang/invoke/jtreg.security.policy From mandy.chung at oracle.com Wed Sep 4 05:45:53 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Sep 2013 22:45:53 -0700 Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues In-Reply-To: <52208720.90305@oracle.com> References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>, , <521F47DD.2020502@oracle.com> <521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com> <521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com> <521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com> <521FF518.7060803@oracle.com> <52203F81.8080903@oracle.com> <522047DC.4030502@oracle.com> <522059F3.7040408@oracle.com> <52208720.90305@oracle.com> Message-ID: <5226C911.40301@oracle.com> Daniel, On 8/30/2013 4:50 AM, Daniel Fuchs wrote: > Hi, > > Please find below an updated patch for solution (c) > > > I'm fine with (c) that is a reasonable fix for this bug. The change looks fine with me. Mandy > best regards, > > -- daniel > > >>> It seems we have 5 choices: > >>> > >>> a. Not fixing > >>> b. Using regular 'synchronized' pattern [1] > >>> c. Using volatiles, synchronize setters only [2] > >>> d. Using volatiles, only synchronize setters when obviously necessary > >>> e. other? (like introducing new private locks - but I don't think > >>> anybody would want that) > >>> > >>> [1] > >>> [2] > >>> > >>> My own preference would lean to either b) or c). > > > > On 8/30/13 10:38 AM, Daniel Fuchs wrote: >> On 8/30/13 9:21 AM, David Holmes wrote: >>> Hi Daniel, >>> >>> I'm fine with the approach in (c), just wanted to highlight the >>> performance considerations (volatile and synchronized need not be >>> equivalent in the uncontended case - biased-locking can mean there are >>> no barriers emitted.) >>> >>> A few specific comments on [2]: >>> >>> Handler.java: >>> >>> reportError doesn't need changing now that the field is volatile and >>> you >>> aren't doing sync. >> >> right. I will revert to original code. >> >>> MemoryHandler.java: >>> >>> pushLevel should/could be volatile and the sync removed from >>> getPushLevel. >> >> right. thanks - I missed that. >> >>> In setPushLevel this seems to be unused code: >>> >>> 262 LogManager manager = LogManager.getLogManager(); >>> >>> unless there is some obscure side-effect in calling getLogManager ?? >> >> Well - yes it triggers the initialization of the logging system. >> However the super class will already have called getLogManager() - >> so this call should have no effect. I will remove it. >> >>> setPushLevel might as well also be synchronized at the method level. >>> All >>> the Handler methods already include checkPermission inside the >>> sync-block. Though I'm actually more inclined to change all the >>> existing >>> code to use sync-blocks so that checkPermission is done outside the >>> lock >>> region. But a consistent approach either way would be preferable. >> >> Agreed. Once I have removed the call to LogManager then the method can >> be synchronized at method level. >> >>> StreamHandler.java >>> >>> writer doesn't need to be volatile - AFAICS it is only accessed within >>> synchronized methods. >> >> Ah - no - it's called in isLoggable() actually. The whole point of using >> volatiles instead of regular synchronization was to allow isLoggable() >> to be called concurrently with e.g. publish() - so I would think >> it's better to make writer volatile too. >> >> Thanks for the valuable comments! I will update the webrev and send out >> a new revision... >> >> best regards, >> >> -- daniel >> >>> >>> Thanks, >>> David >>> >>> On 30/08/2013 4:45 PM, Daniel Fuchs wrote: >>>> On 8/30/13 3:27 AM, David Holmes wrote: >>>>> Hi Daniel, >>>>> >>>>> As usual with these kinds of changes we start by trying to >>>>> complete an >>>>> incomplete/incorrect synchronization pattern and get diverted into >>>>> changing the synchronization pattern. :) The latter of course has >>>>> more >>>>> risk than the former. >>>>> >>>>> Making everything synchronized has the benefit that we don't need to >>>>> analyse the "real" methods to check what would happen if one of these >>>>> data values changed mid-method. Might be harmless, might not. >>>>> Atomicity makes things easy to reason about. >>>> Agreed. We can analyze the 'real methods' of Handler classes in the >>>> JDK. >>>> But I'm sure there are plenty of >>>> subclasses of handlers in applications out there that we don't know >>>> about. So we can't really be sure >>>> what the effect of changing synchronization might have on those >>>> subclasses. >>>> >>>>> Making the fields volatile and un-sync'ing the getters is a potential >>>>> optimization for readers. But are these fields that are read >>>>> frequently by multiple threads? >>>> >>>> At least three of them are accessed by isLoggable() which I believe is >>>> called very frequently by >>>> multiple threads (level, filter, and writer). >>>> >>>>> The downside of doing so is a negative performance impact inside the >>>>> "real" methods where every volatile field access requires >>>>> (platform-dependent) memory barriers. >>>> That - I think - should not be such an issue since the fields are >>>> private. >>>> I mean - we can see whether there are methods that do multiple >>>> access to >>>> the fields in the >>>> classes that define these fields - and fix that if necessary. >>>> For subclasses, they will have to call the getter, which will require >>>> synchronization anyway. >>>> I mean - for subclasses - isn't the fact that the getter accesses a >>>> volatile field or the fact that the >>>> getter is synchronized equivalent in terms of performance? >>>> >>>> JDK 8 is a major version of the JDK - so I think if we want to fix >>>> this >>>> bug it's >>>> probably better to do it now rather than in a minor update. >>>> >>>> It seems we have 5 choices: >>>> >>>> a. Not fixing >>>> b. Using regular 'synchronized' pattern [1] >>>> c. Using volatiles, synchronize setters only [2] >>>> d. Using volatiles, only synchronize setters when obviously necessary >>>> e. other? (like introducing new private locks - but I don't think >>>> anybody would want that) >>>> >>>> [1] >>>> [2] >>>> >>>> My own preference would lean to either b) or c). >>>> >>>> -- daniel >>>> >>>> >>>>> >>>>> David >>>>> >>>>> On 30/08/2013 5:54 AM, Daniel Fuchs wrote: >>>>>> On 8/29/13 9:45 PM, Mandy Chung wrote: >>>>>>> On 8/29/13 11:04 AM, Daniel Fuchs wrote: >>>>>>>> On 8/29/13 7:58 PM, Mandy Chung wrote: >>>>>>>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote: >>>>>>>>>> Here is the new webrev implementing Jason's suggestion. >>>>>>>>>> Compared to previous webrev only Handler.java & >>>>>>>>>> StreamHandler.java >>>>>>>>>> have changed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Looks good. I also agree that making those fields to be volatile >>>>>>>>> is a >>>>>>>>> good suggestion and only requires writer to acquire the lock. >>>>>>>>> >>>>>>>>> A minor comment: The setter methods in Handler class are >>>>>>>>> synchronized >>>>>>>>> at the method entry whereas StreamHandler.setPushLevel >>>>>>>>> synchronizes >>>>>>>>> after checkPermission() is called. checkPermission doesn't need >>>>>>>>> to be >>>>>>>>> synchronized. Either way is fine with me and it'd be good to >>>>>>>>> do it >>>>>>>>> consistently. >>>>>>>> >>>>>>>> Hi Mandy, >>>>>>>> >>>>>>>> Are you suggesting I should put checkPermission() within >>>>>>>> the synchronized block? It might be more consistent with >>>>>>>> what the other setters do. Although as you state it does >>>>>>>> not matter much. >>>>>>> >>>>>>> Having a second thought - do the setters really need to be >>>>>>> synchronized? My guess is that StreamHandler.publish is >>>>>>> synchronized >>>>>>> so as to ensure that the log messages are sequential and not >>>>>>> interpersed >>>>>>> when multiple threads are publishing. The spec is unclear. >>>>>>> Perhaps it >>>>>>> worths looking into this further? >>>>>> >>>>>> I believe at least setEncodings() needs synchronization. >>>>>> setLevel() had it - so are we going to cause subtle race conditions >>>>>> if we remove it? >>>>>> >>>>>> My own feeling is that keeping setters synchronized might be better. >>>>>> >>>>>> We could of course say that a subclass which needs to prevent >>>>>> e.g. setFormatter() from being called concurrently with publish() >>>>>> should override setFormatter just for the purpose of synchronizing >>>>>> it... >>>>>> >>>>>>> One more minor note: MemoryHandler.pushLevel can also be made >>>>>>> volatile. >>>>>>> L262: look like the log manager is not needed in the existing code. >>>>>> >>>>>> hmmm. Right. It's already called once in the super class so removing >>>>>> this call should have no effect. I will remove it. >>>>>> >>>>>> -- daniel >>>>>> >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>> >>>> >> > From Alan.Bateman at oracle.com Wed Sep 4 07:17:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Sep 2013 08:17:01 +0100 Subject: RFR(2nd): 8017513: Support for closeable streams In-Reply-To: <5226325F.5000307@oracle.com> References: <521E6753.9020603@oracle.com> <521EF0F9.3000008@oracle.com> <521F1114.3070703@oracle.com> <5226325F.5000307@oracle.com> Message-ID: <5226DE6D.9010008@oracle.com> On 03/09/2013 20:02, Henry Jen wrote: > Updated webrev is at > > http://cr.openjdk.java.net/~henryjen/ccc/8017513/2/webrev/ > > Addressed comments from Alan and catch IOExpression when close on > exception in Files method. > Thanks for sorting out the suppressed exception issue. I notice you've added code to catch Throwable if addSuppressed fails. Is this out of concern for OOME (I assume not IAE ias it can't happen here)? -Alan. From paul.sandoz at oracle.com Wed Sep 4 07:32:57 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 04 Sep 2013 07:32:57 +0000 Subject: hg: jdk8/tl/jdk: 8024182: test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes Message-ID: <20130904073331.52F5B6252A@hg.openjdk.java.net> Changeset: 462c5589bc1a Author: psandoz Date: 2013-08-12 12:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/462c5589bc1a 8024182: test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes Summary: Use explicit lambda due to javac simplfying rules for overload resolution with implicit lambdas Reviewed-by: alanb, mduigou ! test/java/util/Arrays/SetAllTest.java From henry.jen at oracle.com Wed Sep 4 07:38:36 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 04 Sep 2013 00:38:36 -0700 Subject: RFR(2nd): 8017513: Support for closeable streams In-Reply-To: <5226DE6D.9010008@oracle.com> References: <521E6753.9020603@oracle.com> <521EF0F9.3000008@oracle.com> <521F1114.3070703@oracle.com> <5226325F.5000307@oracle.com> <5226DE6D.9010008@oracle.com> Message-ID: <5226E37C.5050602@oracle.com> On 09/04/2013 12:17 AM, Alan Bateman wrote: > On 03/09/2013 20:02, Henry Jen wrote: >> Updated webrev is at >> >> http://cr.openjdk.java.net/~henryjen/ccc/8017513/2/webrev/ >> >> Addressed comments from Alan and catch IOExpression when close on >> exception in Files method. >> > Thanks for sorting out the suppressed exception issue. I notice you've > added code to catch Throwable if addSuppressed fails. Is this out of > concern for OOME (I assume not IAE ias it can't happen here)? > Just to be on the safe side to ensure the first exception is thrown without surprise. For Files case, I don't think IAE or NPE could happen. Similar pattern is implemented for Streams.composeXX method, where it is less certain. Cheers, Henry From paul.sandoz at oracle.com Wed Sep 4 07:55:19 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Sep 2013 09:55:19 +0200 Subject: RFR 8024182 test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes In-Reply-To: <52261A21.6090103@oracle.com> References: <52261A21.6090103@oracle.com> Message-ID: On Sep 3, 2013, at 7:19 PM, Alan Bateman wrote: > On 03/09/2013 17:33, Paul Sandoz wrote: >> Hi, >> >> Due to recent compiler changes a test is failing to compile. >> >> The fix is already in lambda and needs to be pushed to tl: >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9389 >> >> Paul. >> > Looks good, thanks for sorting this out. > Thanks, > The other thing that this compiler update brings new warnings, we may have to whack them too. > Oh yes, numerous override related warnings. Paul. From paul.sandoz at oracle.com Wed Sep 4 07:55:57 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Sep 2013 09:55:57 +0200 Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black) In-Reply-To: <5225A843.90807@oracle.com> References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com> <83BF5EA9-9D8C-48FC-B539-B6579DB7E12F@oracle.com> <09C37AD7-3D75-46DB-8258-B1B911ECDB8D@oracle.com> <5225A843.90807@oracle.com> Message-ID: <3F987260-ECD3-4D6E-8058-F093000A466B@oracle.com> On Sep 3, 2013, at 11:13 AM, Alan Bateman wrote: > On 02/09/2013 15:12, Paul Sandoz wrote: >> FYI: this has been soaking in the lambda repo for over a weak now. AFAICT there have been no issues. >> >> Paul. >> > If you can pull into a clone of jdk8/tl, run the tests to make sure that all is okay then I think we should just get it in. > JPRT results presented no surprises. Pushed. Paul. From paul.sandoz at oracle.com Wed Sep 4 07:54:04 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 04 Sep 2013 07:54:04 +0000 Subject: hg: jdk8/tl/jdk: 8023463: Improvements to HashMap/LinkedHashMap use of bins/buckets and trees (red/black); ... Message-ID: <20130904075421.EE3746252F@hg.openjdk.java.net> Changeset: d62c911aebbb Author: psandoz Date: 2013-09-04 09:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d62c911aebbb 8023463: Improvements to HashMap/LinkedHashMap use of bins/buckets and trees (red/black) 8012913: LinkedHashMap key/value/entry spliterators should report ORDERED Reviewed-by: mduigou, forax, bchristi, alanb Contributed-by: Doug Lea
, Paul Sandoz ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/LinkedHashMap.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/util/Map/CheckRandomHashSeed.java ! test/java/util/Map/InPlaceOpsCollisions.java + test/java/util/Map/MapBinToFromTreeTest.java - test/java/util/Map/TreeBinSplitBackToEntries.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java From peter.levart at gmail.com Wed Sep 4 10:35:05 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 04 Sep 2013 12:35:05 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <521CA2F0.1020701@gmail.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> <20130812105439.GC6420@jfranck-desktop.jrpg.bea.com> <5208D7A7.9070608@gmail.com> <5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com> <521CA2F0.1020701@gmail.com> Message-ID: <52270CD9.1070903@gmail.com> On 08/13/2013 09:52 AM, Joel Borggr?n-Franck wrote: > 1) We should really measure this. Hi Joel, Here're some measurements of memory usages for some typical situations: // no annotations public static class *Unannotated* { } // typical annotations (JPA-like) @Target(TYPE) @Retention(RUNTIME) public @interface Entity { String name() default ""; } @Target(TYPE) @Retention(RUNTIME) public @interface Table { String name() default ""; String catalog() default ""; String schema() default ""; UniqueConstraint[] uniqueConstraints() default {}; } @Target({}) @Retention(RUNTIME) public @interface UniqueConstraint { String[] columnNames(); } @Entity(name = "EntityName") @Table( name = "table_name", uniqueConstraints = { @UniqueConstraint(columnNames = {"code"}) } ) public static class *JpaEntity* { } // inherited annotations @Target(TYPE) @Retention(RUNTIME) public @interface PlainAnn { String value(); } @Target(TYPE) @Retention(RUNTIME) @Inherited public @interface IngeritableAnn { String value(); } @PlainAnn("super") @IngeritableAnn("super") public static class *AnnotatedSuper* { } @PlainAnn("sub") public static class *AnnotatedSub* { } I measured size of deep object graph starting with a j.l.Class object once on fresh j.j.Class instance and once after getAnnotations() has been called then both sizes were subtracted to get the size of annotations only. The deep object graph ignored: cached Integer, Long, Short, Byte, Character, Boolean, interned String, singletons such as Collections.emptyMap() and accounted for aliases so that each object instance was summed exactly once. The results are for 32 bit / 64 bit object pointers: Unannotated JpaEntity AnnotatedSuper AnnotatedSub ============== ============== ============== ============== Original 88 / 128 1600 / 2584 1192 / 1912 744 / 1216 Patched 24 / 40 1408 / 2272 1000 / 1600 584 / 952 ============== ============== ============== ============== diff -64 / -88 -192 / -312 -192 / -312 -160 / -264 As can be seen, the savings in memory are present in each of the measured situations. The Unannotated class space savings are important for example in applications that scan classes for annotations. Most of classes don't have annotations and overhead in such situations is substantially reduced. Regards, Peter On 08/27/2013 03:00 PM, Peter Levart wrote: > Hi Joel and others, > > Here's a 3rd revision of this proposed patch: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.03/ > > I used LinkedHashMap for annotations in this one. It means that now > even .getAnnotations() are reported in "declaration order": 1st > inherited (includes overridden) then declared (that are not > overriding). For example, using @Inherited annotations A1, A2, A3: > > @A1("C") > @A2("C") > class C {} > > @A1("D") > @A3("D") > class D extends C {} > > D.class.getAnnotations() now returns: { @A1("D"), @A2("C"), @A3("D") } > ... > > The LHM constructor uses the following expression to estimate the > initial capacity of the LHM: > > 3326 annotations = new LinkedHashMap<>((Math.max( > 3327 declaredAnnotations.size(), > 3328 Math.min(12, > declaredAnnotations.size() + superAnnotations.size()) > 3329 ) * 4 + 2) / 3 > 3330 ); > > > I think this strikes some balance between effectivity and accuracy of > estimation. I could pre-scan the superclass annotations and calculate > the exact final size of the annotations Map before constructing it > though. Tell me if this is worth the effort. > > I also created a test that tests 3 things: > - class annotation inheritance > - order of class annotations reported by .getAnnotations() and > .getDeclaredAnnotations() methods (although not specified, the order > is now stable and resembles declaration order) > - behaviour of class annotation caching when class is redefined > > > Regards, Peter > > On 08/13/2013 09:52 AM, Joel Borggr?n-Franck wrote: >> Hi, >> >> Comments inline, >> >> On 12 aug 2013, at 14:40, Peter Levart wrote: >>> On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote: >>> - annotation (@interface) declarations can themselves be redefined >>> (for example, defaults changed). Such redefinitions don't affect >>> already initialized annotations. Default values are cached in >>> AnnotationType which is not invalidated as a result of class >>> redefinition. Maybe it should be. And even if AnnotationType was >>> invalidated as a result of class redefinition, the defaults are >>> looked-up when particular annotations are initialized and then >>> combined with parsed values in a single values map inside each >>> annotation instance (proxy), so invalidating AnnotationType would >>> have no effect on those annotations. >>> >>>> 3326 if (annotations == null) { // lazy construction >>>> 3327 annotations = new HashMap<>(); >>>> 3328 } >>>> >>>> I think this should be a LinkedHashMap, so that iteration is >>>> predictable >>>> (I know it isn't in the current code). Also the size of the map is >>>> known >>>> so you can use a constructor with an explicit initial capacity. >>> Right, AnnotationParser does return LinkedHashMap, so at least >>> decalredAnnotations are in parse-order. I will change the code to >>> use LinkedHashMap for inherited/combined case too. >> Thanks. >> >>> The number of annotations that end-up in inherited/combined Map is >>> not known in advance. I could make a separate pre-scan for >>> superclass annotations that are @Inheritable and don't have the same >>> key as any of declared annotations and then sum this count with >>> declared annotations count, but I don't think this will be very >>> effective. I could allocate a large-enough Map to always fit (the >>> count of superclass annotations + the count of declared >>> annotations), but that could sometimes lead to much over-allocated >>> Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations >>> count + declared annotations count) as the initial capacity for the >>> Map. What do you think which of those 3 alternatives is the best? >> My bad. I was thinking of the case where every inherited annotation >> was overridden, in that case annotations.size() == >> declaredAnnotations.size(). That is of course not generally true. I'm >> fine with handling this as a follow up since the situation is no >> worse than today and the surrounding code is better. However, >> >> 1) We should really measure this. >> 2) My gut feeling is that the ratio of not overridden inherited >> annotations to declared annotations is small IE the expected nr of >> annotations is much closer to declare annotations than to declared + >> superclass annotations. >> 3) The default initial capacity is 16 and load factor is 0.75. I do >> think the mean nr of annotations is closer to 3 than to 12. We are >> probably wasting some space here. >> >> Perhaps use min(default cap, (total annotations/0.75 (+ 1?))) for now >> as that will make the situation no worse than today and often better? >> >>>> Since this is a fairly significant rewrite I think it might be good to >>>> make sure our tests exercise the new code. Can you run some kind of >>>> coverage report on this? >>> I successfully ran the jdk_lang jtreg tests which contain several >>> tests for annotations. >> I'm a bit worried these tests doesn't cover annotations + class >> redefine. But I might be persuaded to have more extensive testing as >> a follow up as well. >> >> cheers >> /Joel > From alan.bateman at oracle.com Wed Sep 4 10:43:16 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 04 Sep 2013 10:43:16 +0000 Subject: hg: jdk8/tl/jdk: 8008981: Deprecate SecurityManager checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess Message-ID: <20130904104408.A440B62545@hg.openjdk.java.net> Changeset: 336784cd60c3 Author: alanb Date: 2013-09-04 11:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336784cd60c3 8008981: Deprecate SecurityManager checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess Reviewed-by: anthony, art, mchung ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java + test/java/awt/security/Permissions.java From chris.hegarty at oracle.com Wed Sep 4 10:48:03 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 04 Sep 2013 11:48:03 +0100 Subject: RFR: 8024014 : (xs) TEST.groups updates In-Reply-To: <7E2223FB-8B0B-4000-8CDD-EE25461E0DB7@oracle.com> References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> <7E2223FB-8B0B-4000-8CDD-EE25461E0DB7@oracle.com> Message-ID: <52270FE3.3070406@oracle.com> On 04/09/2013 00:23, Mike Duigou wrote: > Hello all; > > Here is an updated webrev of just 8024014: > > http://cr.openjdk.java.net/~mduigou/JDK-8024014/0/webrev/ I'm ok with this, and as someone who runs these test frequently I am looking forward to being able to quickly run the different groups. > The controversial item here is the definition of the jdk_collections group which, since collections isn't aligned to a directory, is defined by a list of sub-directories. Since the list of files is quite static and would not have changed since Java 6 (except for jdk_stream) I think we should be able to tolerate the not-too-long list of files for the jdk_collections category. Not part of this change, but it would be nice to have a script (checked in ) that could parse the groups and report directories/tests that are not captured by any group, to easily identify future test additions. -Chris. > > Other opinions? > > Mike > > On Aug 29 2013, at 17:13 , Mike Duigou wrote: > >> Hello all; >> >> This is a review for two changesets. The first change (JDK-8024014) splits up the jdk_util test group a bit by introducing three sub-groups, jdk_collections, jdk_stream and jdk_concurrent. The main advantage is that it's easier/quicker to test individual components. The intent is that the test groups are aligned with bug database sub-components. >> >> The second change moves some important lambda related tests from languishing in obscurity in the jdk_other group to the jdk_lang group to reflect their importance and relation to other tests. These tests are contained in the jdk/lambda directory. >> >> The combined webrev is here: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/ >> >> The effect of these changes won't be visible to most people until JDK-8015068 is integrated. >> >> Thanks, >> >> Mike > From Alan.Bateman at oracle.com Wed Sep 4 11:00:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Sep 2013 12:00:55 +0100 Subject: RFR: 8024014 : (xs) TEST.groups updates In-Reply-To: <7E2223FB-8B0B-4000-8CDD-EE25461E0DB7@oracle.com> References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> <7E2223FB-8B0B-4000-8CDD-EE25461E0DB7@oracle.com> Message-ID: <522712E7.80404@oracle.com> On 04/09/2013 00:23, Mike Duigou wrote: > Hello all; > > Here is an updated webrev of just 8024014: > > http://cr.openjdk.java.net/~mduigou/JDK-8024014/0/webrev/ > > The controversial item here is the definition of the jdk_collections group which, since collections isn't aligned to a directory, is defined by a list of sub-directories. Since the list of files is quite static and would not have changed since Java 6 (except for jdk_stream) I think we should be able to tolerate the not-too-long list of files for the jdk_collections category. > > Other opinions? > > Mike > This is an improvement over the first proposal but I'm still not sure about groups at this level. I'm not objecting, it's more the concern that this will get complicated if personal play lists are added over time. I recall Jim Gish was looking to add make targets at one point for String-only and Process-only tests for example. In the context of test selection for profiles, David Holmes has been proposing extending the selection to allow exclusion of groups on the command line, something like: jtreg :jdk_util -:jdk_util_concurrent -:jdk_util_stream which would run the tests in the jdk_util group, minus the tests in the other groups. If something like this happens then do you think the need for a collections-only subset is reduced? -Alan. From vicente.romero at oracle.com Wed Sep 4 10:54:15 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 04 Sep 2013 10:54:15 +0000 Subject: hg: jdk8/tl/langtools: 8008275: javac.Main should be @Supported Message-ID: <20130904105427.AFBD862546@hg.openjdk.java.net> Changeset: b94824ddcbb6 Author: vromero Date: 2013-09-04 11:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b94824ddcbb6 8008275: javac.Main should be @Supported Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/Main.java From blackdrag at gmx.org Wed Sep 4 12:15:09 2013 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 04 Sep 2013 14:15:09 +0200 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: <52267FCE.70207@oracle.com> References: <522551AE.7060000@oracle.com> <52259B13.8060100@gmx.org> <52267FCE.70207@oracle.com> Message-ID: <5227244D.2040803@gmx.org> Am 04.09.2013 02:33, schrieb Mandy Chung: > On 9/3/13 1:17 AM, Jochen Theodorou wrote: >>> Defining a SE supported @CallerSensitive and also getCallerClass API >>> poses the risk of "encouraging" developers to implement more @CS methods >>> while not fully understand its implication. >> >> Again I am curious... what is such an implication? That your method >> will behave different depending on from where it got called and, >> depending on if that is from an expected or unexpected source, you may >> get an expected or unexpected result here? > > *and* this could lead to surprises and hard-to-diagnose issue to any > framework/library or even another API provided in the same library > calling a caller-sensitive method that can't tell if they get the true > caller or not. > > Caller-sensitivity is used in getting the right visibility (e.g. > Resource.getBundle and Class.forName) and for security checks. The > platform's caller-sensitive methods involve both visibility and > security. For the former (visiability): the use cases of getCallerClass > are mostly for gaining visibility to avoid having the client code to > supply the appropriate ClassLoader or Class. Such convenience has led to > the existing stack walking code to search for a ClassLoader that it can > find what the client code is asking for - it's not impossible that it > might find the wrong ClassLoader but that happens to find a resource > with the same name. For the latter (security), caller sensitive methods > have kept us having "so much fun" in the past CPU releases. If you want to avoid such surprises and hard-to-diagnose issues, then you have to deprecate the convinience versions of Resource.getBundle and Class.forName. The new @CS will not change a bit of that misleading behaviour. As for the security... the whole ProtectionDomain and permissions system is highly caller sensitive. Again, that will not be changed, unless you want a completely new security model. So what is it you want me to tell? That making a public API for this will make things even worse? Then we don't need this discussion here. Even if you for example did the following and let's say introduce an annotation to mark a method that it should appear when I call getCallerClass, and everything else will not. Even then you might not get the expected caller, since a framework may use that in between somehow or by accident. And even if you gave the annotation for example a class as kind of key and use that key for getCallerClass to return only the last frame with that annotation, that used the specified key... I guess that would ensure predictable behaviour, but is far from convenient... Anyway, if the key is known somehow, you can still gain access > Groovy/log4j and other existing framework has already dealt with such > problem and written some non-trivial code to solve this problem. My > point is more about the general app developers that need education and > big warning in the documentation before they attempt learning this API > to get the immediate caller. Sure, I am all for big warnings... > Couple months ago a few of us discussed > some security issues we had fixed in the past and evaluated what we > could do about them - one thing we want to do is to remove the caller > sensitive-ness. This is certainly a big big change and high > compatibility risk - some future work. Just to give you a sense how > serious we are the security issue around caller-sensitive methods. So Java will maybe get a new security model? > I'm happy to know that you will build into Groovy 3.x the ability to > transport the caller class from the Groovy class. I strongly believe > this is the right thing to do and use the ResourceBundle.getBundle and > Class.forName with the ClassLoader parameter. No filtering and no magic > caller class API as you said. Well, Groovy 3.x will be a breaking change - one we intended to do anyway. So we are free to incorporate a fix for this with our abilities and independent of the VM. We don't really like to depend on sun.* packages, but sometimes there is just no way around. And this is not about the big breaking change, it is about how an existing framework can release a new version of its framework, that is compatible to the old versions, but has the replacement for getCallerClass. Such existing usages constrain the solution space quite a lot. > I have replied to Nick's patch with the focus on the ability to get > Class instance from stack trace for diagnosability purpose. I will soon > bring up the discussion on the ability to get caller's Class / > ClassLoader use case. I am looking forward to that bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From joel.franck at oracle.com Wed Sep 4 13:25:01 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Wed, 4 Sep 2013 15:25:01 +0200 Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length In-Reply-To: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com> References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com> Message-ID: <20130904132501.GB21307@jfranck-desktop.jrpg.bea.com> Hi all, Thanks for the comments. New webrev here: http://cr.openjdk.java.net/~jfranck/5047859/webrev.03/ I have also created a specdiff to make it easier to visualize the doc change: http://cr.openjdk.java.net/~jfranck/5047859/specdiff/overview-summary.html I made some bigger changes this time to unify the doc of all four get{Declared}Field{s} methods. I also try to be consistent with the proposed doc change for getMethods and friends that I will post later today. General outline of the docs is roughly: I also updated the test to cover all four cases. cheers /Joel On 2013-08-26, Joel Borggren-Franck wrote: > Hi, > > Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859 > > http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/ > > This is a spec change to update the spec to match the long-standing implementation. > > There is also a clarification of getFields() javadoc without changing the > spec. > > cheers > /Joel From daniel.fuchs at oracle.com Wed Sep 4 13:34:23 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 04 Sep 2013 13:34:23 +0000 Subject: hg: jdk8/tl/jdk: 6823527: java.util.logging.Handler has thread safety issues Message-ID: <20130904133455.3B2146254E@hg.openjdk.java.net> Changeset: ac6e99af2056 Author: dfuchs Date: 2013-09-04 15:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac6e99af2056 6823527: java.util.logging.Handler has thread safety issues Reviewed-by: dholmes, mchung ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java From joel.franck at oracle.com Wed Sep 4 13:55:32 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Wed, 4 Sep 2013 15:55:32 +0200 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type Message-ID: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> Hi, Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ Specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html There are two issues here, - First a getInterfaces() call on an array Class instance does return Cloneable and Serializable. This is specified for getGenericInterfaces() but not specified in getInterface(). The fix is to update the spec to match the implementation, which also aligns it with getGenericInterfaces(). - Also even though JLS states that array types have an implementation of clone() overriding the Object method, it is not included in get{Declared}Method{s}. Again the fix is to note this in the spec. Me and Alex have also worked on the structure of the docs trying to unify them and have a better flow. Rough outline is: cheers /Joel From peter.levart at gmail.com Wed Sep 4 15:30:37 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 04 Sep 2013 17:30:37 +0200 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> Message-ID: <5227521D.2060300@gmail.com> On 09/04/2013 03:55 PM, Joel Borggren-Franck wrote: > Hi, > > Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 > > Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ > Specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html Hi Joel, At getDeclaredMethods() the 2nd paragraph says: "If this Class object represents a type that has multiple declared methods with the same name and parameter types, but different return types, then the returned array has a Method object for each such method." I know that reflection operates on runtime class file format not on Java source, but for an average Java programmer this statement is confusing. (S)He might wonder how it is even possible to declare two methods with same name and parameter types, but with different return type. Of course, reflection also returns synthetic bridge methods that are not declared in source but generated by javac. How to describe that fact in javadoc if it only refers to JLS which doesn't know about these terms (or barely mentions them not describing them in full)? So what about the following in 1st paragraph: "Returns an array containing |Method| objects reflecting all the declared methods of the class or interface represented by this |Class| object, including public, protected, default (package) access, and private methods*. This includes br**idge methods generated by compiler (see {@link #isBridge}),* but exclud*es* inherited methods." And 2nd: "If this Class object represents a type that has multiple declared *(including bridge)* methods with the same name and parameter types, but different return types, then the returned array has a Method object for each such method." ...and a possible pointer to (java compiler specification? http://docs.oracle.com/javase/tutorial/java/generics/bridgeMethods.html#bridgeMethods ?) And similar with getMethods()... Regards, Peter > > There are two issues here, > > - First a getInterfaces() call on an array Class instance does return > Cloneable and Serializable. This is specified for > getGenericInterfaces() but not specified in getInterface(). The fix is > to update the spec to match the implementation, which also aligns it > with getGenericInterfaces(). > > - Also even though JLS states that array types have an implementation of > clone() overriding the Object method, it is not included in > get{Declared}Method{s}. Again the fix is to note this in the spec. > > Me and Alex have also worked on the structure of the docs trying to > unify them and have a better flow. Rough outline is: > > > > > > > cheers > /Joel From sundararajan.athijegannathan at oracle.com Wed Sep 4 15:45:14 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 04 Sep 2013 15:45:14 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130904154517.75E7F6255F@hg.openjdk.java.net> Changeset: b5ff11e00050 Author: sundar Date: 2013-09-04 14:29 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b5ff11e00050 8024120: Setting __proto__ to null removes the __proto__ property Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! test/script/basic/JDK-8023368.js ! test/script/basic/JDK-8023368.js.EXPECTED + test/script/basic/JDK-8024120.js ! test/script/basic/circular_proto.js ! test/script/basic/nonextensible_proto_assign.js Changeset: e43ab4062636 Author: sundar Date: 2013-09-04 19:58 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e43ab4062636 8024174: Setting __proto__ property in Object literal should be supported Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8024174.js From daniel.fuchs at oracle.com Wed Sep 4 14:54:52 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 04 Sep 2013 14:54:52 +0000 Subject: hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency Message-ID: <20130904145522.D672D62558@hg.openjdk.java.net> Changeset: b3d6953b9829 Author: dfuchs Date: 2013-09-04 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829 8019853: Break logging and AWT circular dependency Summary: Break logging and AWT circular dependency, which was at the root cause for 8023258 - Logger.getLogger() after ImageIO.read() returns different logger instance Reviewed-by: mchung, art ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! test/java/util/logging/TestAppletLoggerContext.java + test/java/util/logging/TestLoggingWithMainAppContext.java From mike.duigou at oracle.com Wed Sep 4 17:12:37 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 4 Sep 2013 10:12:37 -0700 Subject: RFR: 8024014 : (xs) TEST.groups updates In-Reply-To: <522712E7.80404@oracle.com> References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> <7E2223FB-8B0B-4000-8CDD-EE25461E0DB7@oracle.com> <522712E7.80404@oracle.com> Message-ID: On Sep 4 2013, at 04:00 , Alan Bateman wrote: > On 04/09/2013 00:23, Mike Duigou wrote: >> Hello all; >> >> Here is an updated webrev of just 8024014: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024014/0/webrev/ >> >> The controversial item here is the definition of the jdk_collections group which, since collections isn't aligned to a directory, is defined by a list of sub-directories. Since the list of files is quite static and would not have changed since Java 6 (except for jdk_stream) I think we should be able to tolerate the not-too-long list of files for the jdk_collections category. >> >> Other opinions? >> >> Mike >> > This is an improvement over the first proposal but I'm still not sure about groups at this level. I'm not objecting, it's more the concern that this will get complicated if personal play lists are added over time. I recall Jim Gish was looking to add make targets at one point for String-only and Process-only tests for example. Understood. For now the sub-groups boundaries are the same as bug sub-component categories. I personally don't have any plans for the introducing groups which aren't aligned to component or sub-component boundaries. I think we are in agreement that adding such groups would be hard to manage. > In the context of test selection for profiles, David Holmes has been proposing extending the selection to allow exclusion of groups on the command line, something like: > > jtreg :jdk_util -:jdk_util_concurrent -:jdk_util_stream > > which would run the tests in the jdk_util group, minus the tests in the other groups. If something like this happens then do you think the need for a collections-only subset is reduced? Yes, though it does presume the existence of the sub-groups that can be "subtracted". Mike From alex.buckley at oracle.com Wed Sep 4 17:36:55 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 04 Sep 2013 10:36:55 -0700 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <5227521D.2060300@gmail.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> <5227521D.2060300@gmail.com> Message-ID: <52276FB7.5050306@oracle.com> On 9/4/2013 8:30 AM, Peter Levart wrote: > At getDeclaredMethods() the 2nd paragraph says: > > "If this Class object represents a type that has multiple declared > methods with the same name and parameter types, but different return > types, then the returned array has a Method object for each such method." > > I know that reflection operates on runtime class file format not on Java > source, but for an average Java programmer this statement is confusing. > (S)He might wonder how it is even possible to declare two methods with > same name and parameter types, but with different return type. Of > course, reflection also returns synthetic bridge methods that are not > declared in source but generated by javac. How to describe that fact in > javadoc if it only refers to JLS which doesn't know about these terms > (or barely mentions them not describing them in full)? Bridge methods are not widely known by Java programmers and to present them in this javadoc would bring confusion rather than clarity. The declarations in a class file exposed through Core Reflection occasionally diverge from the declarations in source, e.g. values() and valueOf() methods magically in a class file for an enum type. The right way to deal with this - if it is to be dealt with at all - is to specify the divergence centrally, such as in Class's top level javadoc. Sprinkling "(including ...)" and "(except for ...)" clauses throughout the individual method specs is a recipe for inconsistency and confusion. I am not actually proposing anything like this be done at this time. Alex From mike.duigou at oracle.com Wed Sep 4 18:44:47 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 4 Sep 2013 11:44:47 -0700 Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self referential is optional In-Reply-To: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com> References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com> Message-ID: <8811C5FD-389A-4FF8-9157-F1DEFD4C9A9F@oracle.com> Hello all; I have updated the proposed changeset for this issue. I have moved the note to the interface documentation for Collection and Map and made it more general: > Some collection operations which perform recursive traversal of the > collection may fail with an exception for self-referential instances where > the collection directly or indirectly contains itself. This includes the > {@code clone()}, {@code equals()}, {@code hashCode()} and {@code toString()} > methods. Implementations may optionally handle the self-referential scenario, > however most current implementations do not do so. The webrev is at: http://cr.openjdk.java.net/~mduigou/JDK-7057785/1/webrev/ Mike On Aug 27 2013, at 19:06 , Mike Duigou wrote: > Hello all; > > Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is: > >> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances. > > > http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/ > > Cheers, > > Mike From xueming.shen at oracle.com Wed Sep 4 19:31:47 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 04 Sep 2013 19:31:47 +0000 Subject: hg: jdk8/tl/jdk: 6341345: (spec) Console.reader() should make it clear that the reader requires line termination Message-ID: <20130904193159.060FA6256A@hg.openjdk.java.net> Changeset: 478afc30679b Author: sherman Date: 2013-09-04 12:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/478afc30679b 6341345: (spec) Console.reader() should make it clear that the reader requires line termination Summary: to clarify the spec Reviewed-by: alanb ! src/share/classes/java/io/Console.java From xueming.shen at oracle.com Wed Sep 4 19:33:50 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 04 Sep 2013 19:33:50 +0000 Subject: hg: jdk8/tl/jdk: 7186632: NLS t13y issue on jar.properties file Message-ID: <20130904193402.691896256B@hg.openjdk.java.net> Changeset: c6a4df06d57e Author: sherman Date: 2013-09-04 12:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6a4df06d57e 7186632: NLS t13y issue on jar.properties file Summary: to remove the redundant backslash Reviewed-by: naoto ! src/share/classes/sun/tools/jar/resources/jar.properties From daniel.fuchs at oracle.com Wed Sep 4 19:56:34 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 04 Sep 2013 21:56:34 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship Message-ID: <52279072.4070809@oracle.com> Hi, Please find below a changeset that will fix 8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship. LogManager class initialization is fragile: because Logger constructor calls LogManager.getLogManager, and because LogManager calls new Logger during LogManager class initialization, and because the global logger is instantiated during Logger class initialization, loading Logger.class or LogManager.class can lead to challenging hard to diagnose issues. This fix untangles the class initialization of Logger and LogManager, and also cleans up the relationship between LogManager, LoggerContext, and Logger. This should address Peter Levart's comment in << > Why is it necessary to add root and global loggers to > LogManager in it's static initializer? Global Logger could be created > and initialized lazily, when 1st requested (in static initialization > of Logger class), and the root Logger is always "ensured" lazily > before any other Logger is initialized. If the dependency on Logger > class was removed from LogManager static initialization, then Logger > static/lazy initialization could depend on LogManager (either just > LogManager.manager field when fully configured LogManager is not > needed/can't be requested or LogManager.getLogManager() for fully > configured LogManager) ... > > The initialization of LogManager, root & default Loggers is very > entangled currently and any change to such code can be fragile. >> Note that a consequence of this cleanup is that two intermittent test failures caused by race conditions / bad isolation will also get fixed: JDK-8019945 test/java/util/logging/LogManagerInstanceTest.java failing intermittently JDK-8021003 java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java fails intermmittently best regards, -- daniel From mike.duigou at oracle.com Wed Sep 4 21:08:49 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 4 Sep 2013 14:08:49 -0700 Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate) Message-ID: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> Hello all; The naming of the Collection.removeIf(Predicate) method has always been an uncertain choice. We've gone back and forth between naming it removeIf and overloading the existing removeAll(Collection) with a removeAll(Predicate). Now that all other library and language decisions seem to be settled it seems reasonable to make a final decision on this method naming. This patch proposes to use the removeAll(Predicate) overload. This choice is made to increase the discoverability of the method and to "reuse" the existing user understanding of the removeAll name. There is a minor source incompatibility induced by overloading the removeAll name--if explicit null is passed then a compiler cannot resolve which overload to use. Since null is not a legal value for either overload this source incompatibility is expected to only affect tests which check to see what response implementations return for null. The ambiguity can be resolved by providing a cast to either the Collection or Predicate types to select the appropriate overload. http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/ Thanks, Mike From david.lloyd at redhat.com Wed Sep 4 21:36:13 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 04 Sep 2013 16:36:13 -0500 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52279072.4070809@oracle.com> References: <52279072.4070809@oracle.com> Message-ID: <5227A7CD.9070302@redhat.com> On 09/04/2013 02:56 PM, Daniel Fuchs wrote: > Hi, > > Please find below a changeset that will fix > > 8023168: Cleanup LogManager class initialization and > LogManager/LoggerContext relationship. > > > > LogManager class initialization is fragile: because Logger > constructor calls LogManager.getLogManager, and because > LogManager calls new Logger during LogManager class initialization, > and because the global logger is instantiated during Logger class > initialization, loading Logger.class or LogManager.class can lead to > challenging hard to diagnose issues. As far as calling initialization ("ensureLogManagerInitialized()"), it's a shame that checking for a one-time action has to run through a synchronization block every time. Maybe a "lazy holder" class would be more appropriate here, especially given that the point seems to be to produce the RootLogger() instance which doubles as the indicator that initialization was done. There's a grammatical error in the comment at line 1547 of LogManager.java: "We do not the protected Logger <...>". -- - DML From jonathan.gibbons at oracle.com Wed Sep 4 21:45:25 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 04 Sep 2013 21:45:25 +0000 Subject: hg: jdk8/tl/langtools: 8024288: javadoc generated-by comment should always be present Message-ID: <20130904214528.81C7F6257C@hg.openjdk.java.net> Changeset: 044721d4d359 Author: jjg Date: 2013-09-04 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/044721d4d359 8024288: javadoc generated-by comment should always be present Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java From brian.burkhalter at oracle.com Wed Sep 4 22:16:14 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 Sep 2013 15:16:14 -0700 Subject: Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1 In-Reply-To: <52267531.6030801@oracle.com> References: <76888C9E-BFA4-43A7-9DBB-29D47C953C55@oracle.com> <52267531.6030801@oracle.com> Message-ID: <21897B5B-86D5-41AB-AFA3-9E18FD9B6324@oracle.com> Hi Joe, On Sep 3, 2013, at 4:48 PM, Joe Darcy wrote: > I'd appreciate some additional comments in the body of the code explaining what is attempted to be implemented. I've updated the webrev to this effect: http://cr.openjdk.java.net/~bpb/8010430/ There are also some new tests in RoundTests starting at line 130. Thanks, Brian From mandy.chung at oracle.com Wed Sep 4 23:23:28 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Sep 2013 16:23:28 -0700 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: References: Message-ID: <5227C0F0.5040108@oracle.com> On 9/1/2013 1:16 AM, Nick Williams wrote: > Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. > > Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. > The other part of this patch is about the ability to obtain the caller information. The use case includes Groovy 2.x and GUI app to look up resource bundles on behalf on the caller and Log4j for logging isolation depending on its caller (isolation on ClassLoader for the app). Such methods are caller-sensitive and must obtain the right caller; otherwise it might get surprises. The proposed getCallerClass() method, no-arg version, looks reasonable and it will return the immediate effective caller of the method calling the getCallerClass method. Use your example (I add the class for the discussion later). Let's ignore the @CallerSensitive annotation for now. getCallerClass(); Foo.someMethod1(); Bar.someMethod2(); Gee.someMethod3(); App.actualCallerMethod() The caller is Bar.someMethod2() and getCallerClass() method will return Bar. It will return the same result even if Foo is called via reflection (the VM already handles this and skips the reflection machinery). When security manager is installed, under what condition can Foo class access Bar class (any permission check)? What if Bar is in a restricted package? The standard way to determine if class A has access to class B is based on their class loaders and also it is a restricted class (configured in the package.access property in JRE/lib/security/java.security). Code has full access to its own class loader and any class loader that is a descendent. There are several methods in java.lang.Class that are performing this security check: * @throw SecurityException * If a security manager, s, is present and the caller's * class loader is not the same as or an ancestor of the class * loader for the returning Class object and invocation of {@link * SecurityManager#checkPackageAccess s.checkPackageAccess()} * denies access to the package of returning Class object I think the above security check should be applicable to the getCallerClass method. It means that Foo can access Bar if Foo's class loader is the same or an ancestor of Bar's class loader; otherwise, it will perform the package access check. BTW - including an example in the javadoc would be helpful since the term "caller" might be confusing. For the known use cases, they are interested in getting the caller's class loader. Class.getClassLoader method has the following security check: *

If a security manager is present, and the caller's class loader is * not null and the caller's class loader is not the same as or an ancestor of * the class loader for the class whose class loader is requested, then * this method calls the security manager's {@code checkPermission} * method with a {@code RuntimePermission("getClassLoader")} * permission to ensure it's ok to access the class loader for the class. I wonder if Class instance is really needed while I understand we can't anticipate all cases. Most of the caller-sensitive methods in the JDK only need to get caller's ClassLoader. There are very few cases that require the caller class (used in the reflection implementation that I have yet to understand deeper). Perhaps all you need is getCallerClassLoader method? In that case, you will be able to get the caller's class loader if you have the access. This is one thing I'd like to explore further (either one or both). Performance - I believe in common cases Foo's class loader should be the same or ancestor of Bar's clas loader. Bar calls Foo which should be visible to Bar's class loader. It'd be very useful if Groovy and Log4j can measure the performance overhead with security manager installed when it's available and see if it is a concern. About the proposed getCallerClass(int) method to find a frame at a specific depth is essentially putting back the sun.reflect.Reflection.getCallerClass(int depth) method. This method is very flexible but brittle. I still think it's more reliable that a caller-sensitive method should capture the caller and pass it to the runtime properly. Groovy 3.x doesn't do the stack walk. Groovy 2.x needs a temporary solution to filter out the intermediate frames of groovy runtime, would StackTraceFrame.getDeclaringClass be an adequate interim solution? More on @CallerSensitive and s.r.Reflection.getCallerClass(int): We had found severe bugs in the code to call s.r.Reflection.getCallerClass(int) when prototying the fix for JEP 176 but they were not noticed and no test uncovered them. e.g. wrong depth was used (easy to miscount the depth or the depth is modified due to refactoring but difficult to be caught during review). As a caller-sensitive method, it's important to find the right caller; otherwise unexpected behavior. In the first prototype, Chris Thalinger did implement JVM_GetCallerClass to walk past all @CS frames and find the immediate caller. All methods in the method chain invoked by the actual caller must be annotated by @CS which ends up something like the example you used earlier: @CallerSensitive getCallerClass(int) @CallerSensitive someMethod1() @CallerSensitive someMethod2() @CallerSensitive someMethod3() @CallerSensitive someMethod4() actualCallerMethod() With more analysis, we identified that there was no absolute need (in the JDK) to walk the stack but instead a more reliable way is to capture the caller at the entry point of the caller-sensitive methods. In the example above, someMethodxx() are internal implementation in the JDK case and thus we modified them to take the caller class parameter (instead of looking it up at its execution point). This greatly simplifies the VM enforcement to detect if the method calling JVM_GetCallerClass is a caller-sensitive method. My feedback is that the getCallerClass() method seems to be adequate for all use cases except Groovy 2.x. I would suggest traversing the stack trace (with the new getDeclaringClass method) be the alternative to adding getCallerClass(int) method. Jochen and others - what do you think? On the @CS subject, if we keep @CallerSensitive in sun.reflect in JDK8, the new getCallerClass() method is a caller-sensitive method and if it is called by the system classes, it will enforce that the caller must be annotated with @s.r.CS; if it called by non-system classes, the VM will return the caller and no check on the annotation. The implication is in the 292 method handles. The current behavior is that if a MethodHandle for a caller-sensitive method is requested, it will bind the method handle with the lookup class (i.e. as if it were called from an instruction contained in the lookup class). There is no change to the current behavior since the current implementation only allows JVM_GetCallerClass be called from system classes. If an app (e.g. Foo.m method) calls the new getCallerClass method, a MethodHandle for Foo.m will not bind with the lookup class. This will need to get John Rose and other 292 members' feedback on it. This is my thinking so far. Feedback and comments? Mandy From brian.burkhalter at oracle.com Wed Sep 4 23:26:11 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 Sep 2013 16:26:11 -0700 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: <3BBEBBC7-FE5B-47BE-9138-C1292404ABC1@oracle.com> References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> <522674C2.8050802@cs.oswego.edu> <52267A39.6090807@cs.oswego.edu> <3BBEBBC7-FE5B-47BE-9138-C1292404ABC1@oracle.com> Message-ID: On Sep 3, 2013, at 5:11 PM, Brian Burkhalter wrote: > On Sep 3, 2013, at 5:09 PM, Doug Lea wrote: > >> Only adding isProbablePrime seems to be an OK conservative >> move: no existing usages would be affected, but users would >> need to somehow be told that they could improve performance >> by changing their code to use the new method with >> ThreadLocalRandom.current() as argument. > > This is what I was thinking. Some verbiage update would be in order. I have updated the webrev http://cr.openjdk.java.net/~bpb/7189139/ to add the two-parameter version of isProbablePrime() which was discussed. Naturally a CCC request would be needed in the event this were to go forward. Comments welcome. Thanks, Brian From mandy.chung at oracle.com Thu Sep 5 00:46:47 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Sep 2013 17:46:47 -0700 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52279072.4070809@oracle.com> References: <52279072.4070809@oracle.com> Message-ID: <5227D477.9090402@oracle.com> On 9/4/2013 12:56 PM, Daniel Fuchs wrote: > Hi, > > Please find below a changeset that will fix > > 8023168: Cleanup LogManager class initialization and > LogManager/LoggerContext relationship. > > > It is good to see the LogManager/Logger initialization untangled. This helps in the long run. LogManager.java L342: thanks to adding the assert here. L340-341 can be removed. This will be helpful in debugging (rather than swallowing the exception). The initialization has been so fragile and swallowing the exception makes the problem even worse. With this cleanup, I think the initialization code will be more robust. The ensureLogManagerInitialized method does the rest of the initialization for the global log manager - it reads the configuration, instantiates and registers the root logger, and also register the global logger. The comment L289-292 about deadlock between two class initializers needs to be revise. I agree with David that it's worth exploring if lazy holder class idiom would help here - perhaps a holder class with a static rootLogger field. Since you touch these lines, it's good to switch to try-with-resource. 1205 final InputStream in = new FileInputStream(fname); 1206 final BufferedInputStream bin = new BufferedInputStream(in); 1207 try { 1208 readConfiguration(bin); 1209 } finally { 1210 in.close(); 1211 } Logger.java - getGlobal() method: would it help if the holder class has static Logger global field which is set during its class initialization. It should guarantee that global.manager is set and the log manager initialization completes?? I was wondering if this can be simplified. thanks Mandy From david.lloyd at redhat.com Thu Sep 5 01:02:05 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 04 Sep 2013 20:02:05 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <5227C0F0.5040108@oracle.com> References: <5227C0F0.5040108@oracle.com> Message-ID: <5227D80D.1010207@redhat.com> On 09/04/2013 06:23 PM, Mandy Chung wrote: > On 9/1/2013 1:16 AM, Nick Williams wrote: >> Class getCallerClass(): Retrieves the class of the caller of the >> method calling getCallerClass(). This is identical to the new >> Reflection#getCallerClass() added in Java 7u25/8. >> >> Class getCallerClass(int): Retrieves the class of the caller n >> frames down the stack. This is identical to the old >> Reflection#getCallerClass(int) that was deprecated in Java 7u25 and >> removed in Java 8. >> > > The other part of this patch is about the ability to obtain the caller > information. The use case includes Groovy 2.x and GUI app to look up > resource bundles on behalf on the caller and Log4j for logging isolation > depending on its caller (isolation on ClassLoader for the app). > > Such methods are caller-sensitive and must obtain the right caller; > otherwise it might get surprises. > > The proposed getCallerClass() method, no-arg version, looks reasonable > and it will return the immediate effective caller of the method calling > the getCallerClass method. Use your example (I add the class for the > discussion later). Let's ignore the @CallerSensitive annotation for now. > > getCallerClass(); > Foo.someMethod1(); > Bar.someMethod2(); > Gee.someMethod3(); > App.actualCallerMethod() > > The caller is Bar.someMethod2() and getCallerClass() method will return > Bar. It will return the same result even if Foo is called via > reflection (the VM already handles this and skips the reflection > machinery). > > When security manager is installed, under what condition can Foo class > access Bar class (any permission check)? What if Bar is in a restricted > package? > > The standard way to determine if class A has access to class B is based > on their class loaders and also it is a restricted class (configured in > the package.access property in JRE/lib/security/java.security). Code > has full access to its own class loader and any class loader that is a > descendent. There are several methods in java.lang.Class that are > performing this security check: > > * @throw SecurityException > * If a security manager, s, is present and the > caller's > * class loader is not the same as or an ancestor of the class > * loader for the returning Class object and invocation of > {@link > * SecurityManager#checkPackageAccess s.checkPackageAccess()} > * denies access to the package of returning Class object > > I think the above security check should be applicable to the > getCallerClass method. It means that > Foo can access Bar if Foo's class loader is the same or an ancestor of > Bar's class loader; otherwise, it will perform the package access check. > BTW - including an example in the javadoc would be helpful since the > term "caller" might be confusing. > > For the known use cases, they are interested in getting the caller's > class loader. Class.getClassLoader method has the following security > check: > > *

If a security manager is present, and the caller's class > loader is > * not null and the caller's class loader is not the same as or an > ancestor of > * the class loader for the class whose class loader is requested, > then > * this method calls the security manager's {@code checkPermission} > * method with a {@code RuntimePermission("getClassLoader")} > * permission to ensure it's ok to access the class loader for the > class. > > I wonder if Class instance is really needed while I understand we can't > anticipate all cases. Most of the caller-sensitive methods in the JDK > only need to get caller's ClassLoader. There are very few cases that > require the caller class (used in the reflection implementation that I > have yet to understand deeper). Perhaps all you need is > getCallerClassLoader method? In that case, you will be able to get the > caller's class loader if you have the access. This is one thing I'd > like to explore further (either one or both). > > Performance - I believe in common cases Foo's class loader should be the > same or ancestor of Bar's clas loader. Bar calls Foo which should be > visible to Bar's class loader. It'd be very useful if Groovy and Log4j > can measure the performance overhead with security manager installed > when it's available and see if it is a concern. > > About the proposed getCallerClass(int) method to find a frame at a > specific depth is essentially putting back the > sun.reflect.Reflection.getCallerClass(int depth) method. This method is > very flexible but brittle. I still think it's more reliable that a > caller-sensitive method should capture the caller and pass it to the > runtime properly. Groovy 3.x doesn't do the stack walk. Groovy 2.x needs > a temporary solution to filter out the intermediate frames of groovy > runtime, would StackTraceFrame.getDeclaringClass be an adequate interim > solution? > > More on @CallerSensitive and s.r.Reflection.getCallerClass(int): > > We had found severe bugs in the code to call > s.r.Reflection.getCallerClass(int) when prototying the fix for JEP 176 > but they were not noticed and no test uncovered them. e.g. wrong depth > was used (easy to miscount the depth or the depth is modified due to > refactoring but difficult to be caught during review). As a > caller-sensitive method, it's important to find the right caller; > otherwise unexpected behavior. > > In the first prototype, Chris Thalinger did implement JVM_GetCallerClass > to walk past all @CS frames and find the immediate caller. All methods > in the method chain invoked by the actual caller must be annotated by > @CS which ends up something like the example you used earlier: > > @CallerSensitive getCallerClass(int) > @CallerSensitive someMethod1() > @CallerSensitive someMethod2() > @CallerSensitive someMethod3() > @CallerSensitive someMethod4() > actualCallerMethod() > > With more analysis, we identified that there was no absolute need (in > the JDK) to walk the stack but instead a more reliable way is to capture > the caller at the entry point of the caller-sensitive methods. In the > example above, someMethodxx() are internal implementation in the JDK > case and thus we modified them to take the caller class parameter > (instead of looking it up at its execution point). This greatly > simplifies the VM enforcement to detect if the method calling > JVM_GetCallerClass is a caller-sensitive method. This seems reasonable on the surface but falls over once you capture the caller for more than one purpose. For example, say a logging framework captures the caller for the purpose of supplementing log information. But you call this logging framework from another framework which uses caller information for another purpose, for example locating resources. The intent here might be to show information from the second framework in the log, however with one universal @CallerSensitive annotation you cannot distinguish which "capture" you want to grab - the second framework, or the caller who called the second framework. However by traversing the stack to a fixed depth, you can do so very definitively (as long as you always know that your internal code does *not* directly call the sensitive method - an easy thing to design for in most frameworks). In fact you can usually traverse the stack to a fixed depth for this kind of thing, with one key exception that comes up in log frameworks. When you have one log API which forwards to another, you want to capture the "first" caller of any log API. Pursuant to this, most log frameworks have log method variants which accept the fully-qualified class name of that first logger. The moral equivalent to this scenario would likely be to provide an API variant which accepts a Class or ClassLoader (depending on the usage) and a variant which does not and uses a fixed-depth "reach" into the stack instead. This IMO blows a hole in the whole idea of a single *public* @CS annotation, and in fact in public framework code, a depth indicator seems to be adequate and more or less problem-free for any purpose I've run across. In private JDK code it's a different story because every caller-sensitive usage is in the same code base as the mechanism itself, so there is always a tight control and a guarantee that two different sensitive methods won't interfere at cross-purposes in this way. > My feedback is that the getCallerClass() method seems to be adequate for > all use cases except Groovy 2.x. I would suggest traversing the stack > trace (with the new getDeclaringClass method) be the alternative to > adding getCallerClass(int) method. Jochen and others - what do you think? > > On the @CS subject, if we keep @CallerSensitive in sun.reflect in JDK8, > the new getCallerClass() method is a caller-sensitive method and if it > is called by the system classes, it will enforce that the caller must be > annotated with @s.r.CS; if it called by non-system classes, the VM will > return the caller and no check on the annotation. The implication is in > the 292 method handles. The current behavior is that if a MethodHandle > for a caller-sensitive method is requested, it will bind the method > handle with the lookup class (i.e. as if it were called from an > instruction contained in the lookup class). There is no change to the > current behavior since the current implementation only allows > JVM_GetCallerClass be called from system classes. If an app (e.g. Foo.m > method) calls the new getCallerClass method, a MethodHandle for Foo.m > will not bind with the lookup class. This will need to get John Rose > and other 292 members' feedback on it. > > This is my thinking so far. Feedback and comments? > > Mandy -- - DML From robert.field at oracle.com Thu Sep 5 02:48:00 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 05 Sep 2013 02:48:00 +0000 Subject: hg: jdk8/tl/jdk: 8020816: Metafactory crashes on code with method reference; ... Message-ID: <20130905024824.0967D62583@hg.openjdk.java.net> Changeset: bd6fcc5eebb8 Author: rfield Date: 2013-09-04 19:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6fcc5eebb8 8020816: Metafactory crashes on code with method reference 8021050: MethodHandleInfo throws exception when method handle is to a method with @CallerSensitive Summary: Fixed by 8008688 - this is a test to confirm the above fixed Reviewed-by: vlivanov + test/jdk/lambda/MethodReferenceTestCallerSensitive.java From joe.darcy at oracle.com Thu Sep 5 03:17:21 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 04 Sep 2013 20:17:21 -0700 Subject: Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1 In-Reply-To: <21897B5B-86D5-41AB-AFA3-9E18FD9B6324@oracle.com> References: <76888C9E-BFA4-43A7-9DBB-29D47C953C55@oracle.com> <52267531.6030801@oracle.com> <21897B5B-86D5-41AB-AFA3-9E18FD9B6324@oracle.com> Message-ID: <5227F7C1.9090800@oracle.com> Hi Brian, Looks fine; approved to go back. Thanks, -Joe On 9/4/2013 3:16 PM, Brian Burkhalter wrote: > Hi Joe, > > On Sep 3, 2013, at 4:48 PM, Joe Darcy wrote: > >> I'd appreciate some additional comments in the body of the code >> explaining what is attempted to be implemented. > > I've updated the webrev to this effect: > > http://cr.openjdk.java.net/~bpb/8010430/ > > > There are also some new tests in RoundTests starting at line 130. > > Thanks, > > Brian From joe.darcy at oracle.com Thu Sep 5 03:42:11 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 04 Sep 2013 20:42:11 -0700 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> <522674C2.8050802@cs.oswego.edu> <52267A39.6090807@cs.oswego.edu> <3BBEBBC7-FE5B-47BE-9138-C1292404ABC1@oracle.com> Message-ID: <5227FD93.7070808@oracle.com> Hello, I don't think the specification of the new method is acceptable in its current form. At a minimum, some guidance should be provided on the properties the supplied random number generator should have to work with the primality tests that are being used. (Offhand, I don't know what those criteria are.) -Joe On 9/4/2013 4:26 PM, Brian Burkhalter wrote: > On Sep 3, 2013, at 5:11 PM, Brian Burkhalter wrote: > >> On Sep 3, 2013, at 5:09 PM, Doug Lea wrote: >> >>> Only adding isProbablePrime seems to be an OK conservative >>> move: no existing usages would be affected, but users would >>> need to somehow be told that they could improve performance >>> by changing their code to use the new method with >>> ThreadLocalRandom.current() as argument. >> This is what I was thinking. Some verbiage update would be in order. > I have updated the webrev > > http://cr.openjdk.java.net/~bpb/7189139/ > > to add the two-parameter version of isProbablePrime() which was discussed. Naturally a CCC request would be needed in the event this were to go forward. > > Comments welcome. > > Thanks, > > Brian From joe.darcy at oracle.com Thu Sep 5 03:47:42 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 04 Sep 2013 20:47:42 -0700 Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length In-Reply-To: <20130904132501.GB21307@jfranck-desktop.jrpg.bea.com> References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com> <20130904132501.GB21307@jfranck-desktop.jrpg.bea.com> Message-ID: <5227FEDE.1030803@oracle.com> Hi Joel, The spec changes look good in their current form. I'd prefer to see the test re-structure to have class code duplication, but it is acceptable in its present form. Cheers, -Joe On 9/4/2013 6:25 AM, Joel Borggren-Franck wrote: > Hi all, > > Thanks for the comments. New webrev here: > > http://cr.openjdk.java.net/~jfranck/5047859/webrev.03/ > > I have also created a specdiff to make it easier to visualize the doc > change: > > http://cr.openjdk.java.net/~jfranck/5047859/specdiff/overview-summary.html > > I made some bigger changes this time to unify the doc of all four > get{Declared}Field{s} methods. I also try to be consistent with the > proposed doc change for getMethods and friends that I will post later > today. > > General outline of the docs is roughly: > > > > > > > I also updated the test to cover all four cases. > > cheers > /Joel > > On 2013-08-26, Joel Borggren-Franck wrote: >> Hi, >> >> Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859 >> >> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/ >> >> This is a spec change to update the spec to match the long-standing implementation. >> >> There is also a clarification of getFields() javadoc without changing the >> spec. >> >> cheers >> /Joel From joe.darcy at oracle.com Thu Sep 5 03:57:03 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 04 Sep 2013 20:57:03 -0700 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> Message-ID: <5228010F.20108@oracle.com> Looks fine; thanks, -Joe On 9/4/2013 6:55 AM, Joel Borggren-Franck wrote: > Hi, > > Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 > > Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ > Specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html > > There are two issues here, > > - First a getInterfaces() call on an array Class instance does return > Cloneable and Serializable. This is specified for > getGenericInterfaces() but not specified in getInterface(). The fix is > to update the spec to match the implementation, which also aligns it > with getGenericInterfaces(). > > - Also even though JLS states that array types have an implementation of > clone() overriding the Object method, it is not included in > get{Declared}Method{s}. Again the fix is to note this in the spec. > > Me and Alex have also worked on the structure of the docs trying to > unify them and have a better flow. Rough outline is: > > > > > > > cheers > /Joel From brian.goetz at oracle.com Thu Sep 5 04:01:22 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 05 Sep 2013 00:01:22 -0400 Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate) In-Reply-To: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> References: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> Message-ID: <52280212.3090604@oracle.com> +1 from me. On 9/4/2013 5:08 PM, Mike Duigou wrote: > Hello all; > > The naming of the Collection.removeIf(Predicate) method has always been an uncertain choice. We've gone back and forth between naming it removeIf and overloading the existing removeAll(Collection) with a removeAll(Predicate). Now that all other library and language decisions seem to be settled it seems reasonable to make a final decision on this method naming. > > This patch proposes to use the removeAll(Predicate) overload. This choice is made to increase the discoverability of the method and to "reuse" the existing user understanding of the removeAll name. There is a minor source incompatibility induced by overloading the removeAll name--if explicit null is passed then a compiler cannot resolve which overload to use. Since null is not a legal value for either overload this source incompatibility is expected to only affect tests which check to see what response implementations return for null. The ambiguity can be resolved by providing a cast to either the Collection or Predicate types to select the appropriate overload. > > http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/ > > Thanks, > > Mike > From lordpixel at me.com Thu Sep 5 04:38:47 2013 From: lordpixel at me.com (Andrew Thompson) Date: Thu, 5 Sep 2013 00:38:47 -0400 Subject: Replacement of sun.reflect.Reflection#getCallerClass In-Reply-To: References: <522551AE.7060000@oracle.com> <5225F268.2000707@oracle.com> <7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net> <5226197F.1050301@gmail.com> <52261F3A.3010604@redhat.com> <52262661.5000900@gmail.com> <522636AA.6000304@oracle.com> Message-ID: <4015A83A-B3A8-44B1-BDE9-EE3E00363DB2@me.com> Indeed if giving access to arbitrary Class is going to introduce such headaches as exposing sun.* and trying to support arbitrary class loaders then Ralph has the right point. It's also an example of the advantages or mirrors that Gilad is talking about here:http://gbracha.blogspot.com/2010/03/through-looking-glass-darkly.html So how about replace Class getDeclaringClass() With DeclaringType getDeclaringType() Where DeclaringType is package java.lang.reflect( public interface DeclaringType extends Type { public ClassLoader getClassLoader() throws SecurityException; public String getName(); public ProtectionDomain getProductionDomain() throws SecurityException; public Package getPackage(); For convenience java.lang.Class could implement this interface but security sensitive contexts could return a much more limited type when appropriate. On Sep 3, 2013, at 3:45 PM, Ralph Goers wrote: > In Log4j's case the information we want from each StackTraceFrame is: > > a) the class name, > b) the jar or directory where the class resided. > c) the version of the jar. > d) the ClassLoader associated with the class. > > Having the actually Class object allows us to get all of this information but if it is deemed more secure to just include all the individual information instead that would be fine. > > Ralph > > On Sep 3, 2013, at 12:21 PM, Mandy Chung wrote: > >> On 9/3/13 11:11 AM, Peter Levart wrote: >>> On 09/03/2013 07:41 PM, David M. Lloyd wrote: >>>>> What about a simple restriction on methods returning such instances that >>>>> Class objects are only returned when they are resolvable from the >>>>> ClassLoader of client code. If they are not resolvable, null is >>>>> returned. For example, the equivalent of: >>>>> >>>> >>>> I don't think this will hold up. Why would (for example) a logging API have access to every class loader that might need to log something? In any system of appreciable size, there is typically at least *some* class loader isolation, often a lot of it. Utilities like logging or security code that need to do this kind of check do not typically have direct access to classes which are "higher on the stack", so to speak. >>> >>> Ok, I understand. What about the other way around - would this be acceptable from security perspective (asking Mandy?): >> >> I don't think that works for log4j either. In general we should only allow a ClassLoader A to access classes loaded by a ClassLoader B only if B trusts A (i.e A is the same or an ancestor of B); otherwise some kind of permission check (e.g. package access) is required. Log4j wants to access all Class instances on the stack for diagnosibility purpose and unless Log4j is loaded by the bootstrap class loader (put -Xbootclasspath) it may not be able to get access to all classes via Class.forName call. >> >> This would probably need a coarse-grained permission than a fine-grained permission check on the indivdual stack frame subject to the ClassLoader/Class. >> >> Mandy >> >>> >>> - If you can see me (by name), then you're exposed (I can get you): >>> >>> public class StackTraceFrame { >>> >>> private final Class declaringClass; >>> >>> @CallerSensitive >>> public Class getDeclaringClass() { >>> try { >>> Class cc = Reflection.getCallerClass(); >>> return Class.forName(cc.getName(), >>> false, >>> declaringClass.getClassLoader()) >>> == cc ? declaringClass : null; >>> >>> } catch (ClassNotFoundException ignore) {} >>> return null; >>> } >>> >>> >>> This would not present a problem for JDK system classes since they can not see client code. >> > From eliasen at mindspring.com Thu Sep 5 05:02:48 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Wed, 04 Sep 2013 23:02:48 -0600 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> <522674C2.8050802@cs.oswego.edu> <52267A39.6090807@cs.oswego.edu> <3BBEBBC7-FE5B-47BE-9138-C1292404ABC1@oracle.com> Message-ID: <52281078.4070003@mindspring.com> On 09/04/2013 05:26 PM, Brian Burkhalter wrote: > I have updated the webrev > > http://cr.openjdk.java.net/~bpb/7189139/ > > to add the two-parameter version of isProbablePrime() which was > discussed. Naturally a CCC request would be needed in the event this > were to go forward. The change to pass in the random number generator appears fine. There's probably no need for a strong random number generator in this case, though. Rabin-Miller is a robust algorithm and the probability of its failure can be easily made so that it's far more probable that the computer's hardware fails while running the test. (I wrote an article about this if you're interested.) The particular random numbers that it chooses are not terribly crucial as long as there's enough margin, and as long as random numbers aren't repeated pathologically. However, the primality tests could be made more efficient and more certain. For smallish numbers, the Rabin-Miller test performs a large number of random tests, with some low probability of failure. It's known, however, for numbers less than 341,550,071,728,321, (or larger, see references below,) that there are minimal sets of bases we need to test with a Rabin-Miller test to *prove* primality. (This would also allow us to eliminate generating random numbers entirely, in these cases, to perform a much smaller number of Rabin-Miller rounds, and let us skip the Lucas test entirely as well, and enable a *proof* of primality for numbers smaller than this.) For example, if the number n is less than 4,759,123,141 (this encompasses all ints) then you only need to test that n is a strong probable prime to bases 2,7, and 61 to *prove* primality. This would be much faster than the code now (which may do 50 rounds, and won't do *more* than 50 rounds, no matter what certainty you request, which is almost certainly a bug in the current code.) It would also be more correct than the current code, which admits a low probability of failure. There are references which show the exact bases to test for smaller numbers in a Rabin-Miller test to *prove* primality here: http://primes.utm.edu/prove/prove2_3.html#quick http://priv.ckp.pl/wizykowski/sprp.pdf http://math.crg4.com/primes.html http://www.gpgpgpu.com/gecco2009/6.pdf Further, to *prove* primality of everything that will fit into an unsigned long (2^64), you only need to test all prime bases <= 37. See: http://oeis.org/A014233 There could be a fast path to do the tests for smallish numbers in a long or an int. You'll want a modPow function. Here's one for ints: /** Compute x^y mod m. Assumes m >= 2. */ public static int modPow(int x, int y, int m) { long acc = 1; long z = x % m; while (y != 0) { if ((y & 1) != 0) acc = (acc * z) % m; z = (z * z) % m; y >>= 1; } return (int) acc; } -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From peter.levart at gmail.com Thu Sep 5 06:07:41 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 05 Sep 2013 08:07:41 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5227A7CD.9070302@redhat.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> Message-ID: <52281FAD.70506@gmail.com> On 09/04/2013 11:36 PM, David M. Lloyd wrote: > On 09/04/2013 02:56 PM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a changeset that will fix >> >> 8023168: Cleanup LogManager class initialization and >> LogManager/LoggerContext relationship. >> >> >> >> LogManager class initialization is fragile: because Logger >> constructor calls LogManager.getLogManager, and because >> LogManager calls new Logger during LogManager class initialization, >> and because the global logger is instantiated during Logger class >> initialization, loading Logger.class or LogManager.class can lead to >> challenging hard to diagnose issues. > > As far as calling initialization ("ensureLogManagerInitialized()"), > it's a shame that checking for a one-time action has to run through a > synchronization block every time. Maybe a "lazy holder" class would > be more appropriate here, especially given that the point seems to be > to produce the RootLogger() instance which doubles as the indicator > that initialization was done. > Or, without using yet another class, double-checked locking, like: private volatile boolean initializedCalled; final void ensureLogManagerInitialized() { if (initializedCalled) { return; } synchronized (this) { final LogManager owner = this; // re-check under lock if (initializedCalled || owner != manager) { // we don't want to do this twice, and we don't want to do // this on private manager instances. return; } try { AccessController.doPrivileged(....); } finally { initializedCalled = true; } } } ... the code in PrivilegedAction that does the initialization, that is, the following statements: owner.readPrimordialConfiguration(); * owner.rootLogger = owner.new RootLogger();* owner.addLogger(owner.rootLogger); final Logger global = Logger.global; owner.addLogger(global); ...almost all of them (except assignment to rootLogger) by themselves ensure that the state mutations they make are published to other threads, so if also *rootLogger* field was made volatile, such double-checked locking would presumably not be broken. One observation on method readPrimordialConfiguration() - this method performs similar double-checked locking initialization, but I think it sets the *readPrimordialConfiguration* flag to soon. I think it should do it in a final block of a try statement, like presented initialization above. Regards, Peter From daniel.fuchs at oracle.com Thu Sep 5 07:43:14 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 09:43:14 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5227A7CD.9070302@redhat.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> Message-ID: <52283612.6020908@oracle.com> Hi David, Thanks a lot for your feedback! On 9/4/13 11:36 PM, David M. Lloyd wrote: > As far as calling initialization ("ensureLogManagerInitialized()"), > it's a shame that checking for a one-time action has to run through a > synchronization block every time. Maybe a "lazy holder" class would > be more appropriate here, especially given that the point seems to be > to produce the RootLogger() instance which doubles as the indicator > that initialization was done. The point here is that we don't want a thread to be able to get at an half initialized LogManager, for instance, one in which the root logger would have been added but not the global logger. This could lead to all kind of race conditions. So I think RootLogger can't really be used as a marker here. I'll double check that however. You wouldn't believe all the exceptions that were raised when I started working naively on this issue ;-) I think I'd prefer to stay away from static initializers for this piece of code. I'd propose to use a volatile boolean to mark when initialization is truly finished. This way there would be no need to enter the synchronized block once LogManager has finished initializing. I'll send a new webrev. > > There's a grammatical error in the comment at line 1547 of > LogManager.java: "We do not the protected Logger <...>". Oh. Thanks for catching that! best regards, -- daniel From daniel.fuchs at oracle.com Thu Sep 5 07:45:02 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 09:45:02 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5227D477.9090402@oracle.com> References: <52279072.4070809@oracle.com> <5227D477.9090402@oracle.com> Message-ID: <5228367E.4090600@oracle.com> Hi Mandy, On 9/5/13 2:46 AM, Mandy Chung wrote: > > On 9/4/2013 12:56 PM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a changeset that will fix >> >> 8023168: Cleanup LogManager class initialization and >> LogManager/LoggerContext relationship. >> >> >> > > It is good to see the LogManager/Logger initialization untangled. This > helps in the long run. > > LogManager.java L342: thanks to adding the assert here. L340-341 can > be removed. > This will be helpful in debugging (rather than swallowing the > exception). The initialization has been so fragile and swallowing the > exception makes the problem even worse. With this cleanup, I think > the initialization code will be more robust. Will do. > > The ensureLogManagerInitialized method does the rest of the > initialization for the global log manager - it reads the > configuration, instantiates and registers the root logger, and also > register the global logger. The comment L289-292 about deadlock > between two class initializers needs to be revise. Will do. > > I agree with David that it's worth exploring if lazy holder class > idiom would help here - perhaps a holder class with a static > rootLogger field. Well, I am not too keen on using a lazy holder class idiom here. Though it is true that ensureLogManagerInitialized will do nothing if called before the 'manager' field is set, or if called from additional instances of LogManager, I'd prefer not to stick this code in yet another static initializer. If that's acceptable - I'd prefer to use a synchronized block within the method and an additional volatile boolean to mark when initialization is finished. This should make it possible to avoid entering the synchronized block once the LogManager is initialized. > > Since you touch these lines, it's good to switch to try-with-resource. > > 1205 final InputStream in = new FileInputStream(fname); > 1206 final BufferedInputStream bin = new BufferedInputStream(in); > 1207 try { > 1208 readConfiguration(bin); > 1209 } finally { > 1210 in.close(); > 1211 } > OK. > Logger.java - getGlobal() method: would it help if the holder class > has static Logger global field which is set during its class > initialization. It should guarantee that global.manager is set > and the log manager initialization completes?? Can't do. Logger.global is a public final field. -- daniel > > I was wondering if this can be simplified. > > thanks > Mandy > From daniel.fuchs at oracle.com Thu Sep 5 08:08:36 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 10:08:36 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52281FAD.70506@gmail.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> Message-ID: <52283C04.2000203@oracle.com> On 9/5/13 8:07 AM, Peter Levart wrote: > On 09/04/2013 11:36 PM, David M. Lloyd wrote: >> On 09/04/2013 02:56 PM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a changeset that will fix >>> >>> 8023168: Cleanup LogManager class initialization and >>> LogManager/LoggerContext relationship. >>> >>> >>> >>> LogManager class initialization is fragile: because Logger >>> constructor calls LogManager.getLogManager, and because >>> LogManager calls new Logger during LogManager class initialization, >>> and because the global logger is instantiated during Logger class >>> initialization, loading Logger.class or LogManager.class can lead to >>> challenging hard to diagnose issues. >> >> As far as calling initialization ("ensureLogManagerInitialized()"), >> it's a shame that checking for a one-time action has to run through a >> synchronization block every time. Maybe a "lazy holder" class would >> be more appropriate here, especially given that the point seems to be >> to produce the RootLogger() instance which doubles as the indicator >> that initialization was done. >> > > Or, without using yet another class, double-checked locking, like: > > private volatile boolean initializedCalled; > > final void ensureLogManagerInitialized() { > if (initializedCalled) { > return; > } > synchronized (this) { > final LogManager owner = this; > // re-check under lock > if (initializedCalled || owner != manager) { > // we don't want to do this twice, and we don't want to do > // this on private manager instances. > return; > } > try { > AccessController.doPrivileged(....); > } finally { > initializedCalled = true; > } > } > } Ah! Thanks for that comment Peter - that's exactly what I had in mind. > > > ... the code in PrivilegedAction that does the initialization, that > is, the following statements: > > owner.readPrimordialConfiguration(); > * owner.rootLogger = owner.new RootLogger();* > owner.addLogger(owner.rootLogger); > final Logger global = Logger.global; > owner.addLogger(global); > > > ...almost all of them (except assignment to rootLogger) by themselves > ensure that the state mutations they make are published to other > threads, so if also *rootLogger* field was made volatile, such > double-checked locking would presumably not be broken. Hmmm... By that I assume you mean the operations that access LogManager.rootLogger from LoggerContext. AFAIR all these operations are synchronized on LoggerContext, and will trigger a call to ensureLogManagerInitialized(). ensureLogManagerInitialized() is called for every add/get logger operation. If ensureLogManagerInitialized() is executing other threads will be blocked. When it finishes - threads that were waiting on the monitor will find the initializationCalled flag set to true and will simply return. Threads that call ensureLogManagerInitialized() after that will find the flag is true before entering the synchronized block and will return directly. I can make rootLogger volatile. I'm not 100% sure it is required - but I think it is more correct, and as such it will make the code more maintainable. Good point. It's probably something I would have overlooked. > One observation on method readPrimordialConfiguration() - this method > performs similar double-checked locking initialization, but I think it > sets the *readPrimordialConfiguration* flag to soon. I think it should > do it in a final block of a try statement, like presented > initialization above. Yes. I know this is broken - and I believe I have seen a defect that points that out. I'd prefer not to change that in this changeset though. best regards -- daniel > > > Regards, Peter > From Alan.Bateman at oracle.com Thu Sep 5 09:20:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Sep 2013 10:20:04 +0100 Subject: @Supported design issues In-Reply-To: <514911B2.30504@oracle.com> References: <51266B7C.3040804@oracle.com>, <5126D516.1040005@oracle.com>, , <5127C4D4.5090800@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net> <51293038.7090503@oracle.com> <5142055C.3060408@oracle.com> <514911B2.30504@oracle.com> Message-ID: <52284CC4.4030701@oracle.com> On 20/03/2013 01:32, Joseph Darcy wrote: > > Following up in the same thread, the JEP for this work is now > available for your reading pleasure at: > > JEP 179: Document JDK API Support and Stability > http://openjdk.java.net/jeps/179 Joe - do you want to reboot this discussion? With the deadline for API changes looming then it would be good to get agreement on whether we are going to do anything on this. I still have the patch to add this to the APIs that we generate javadoc for in the build - this is the same set of APIs that I understand to be stable APIs and okay for applications/libraries to make direct use of. Given the previous discussion then getting agreement on whether this is a boolean or something more seems important. Clearly there are corner cases (a few of these came up in the original discussion) but a simple label to convey that an API is stable seems a good start. The other problematic issue was the naming, clearly "Supported" results in too many questions, "by who?" in particular. Have you considered alternative names? I realize this is open to bikeshedding. Personally I wouldn't have a problem with jdk.Stable if appropriately defined. -Alan From Alan.Bateman at oracle.com Thu Sep 5 09:25:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Sep 2013 10:25:39 +0100 Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate) In-Reply-To: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> References: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> Message-ID: <52284E13.1040209@oracle.com> On 04/09/2013 22:08, Mike Duigou wrote: > Hello all; > > The naming of the Collection.removeIf(Predicate) method has always been an uncertain choice. We've gone back and forth between naming it removeIf and overloading the existing removeAll(Collection) with a removeAll(Predicate). Now that all other library and language decisions seem to be settled it seems reasonable to make a final decision on this method naming. > > This patch proposes to use the removeAll(Predicate) overload. This choice is made to increase the discoverability of the method and to "reuse" the existing user understanding of the removeAll name. There is a minor source incompatibility induced by overloading the removeAll name--if explicit null is passed then a compiler cannot resolve which overload to use. Since null is not a legal value for either overload this source incompatibility is expected to only affect tests which check to see what response implementations return for null. The ambiguity can be resolved by providing a cast to either the Collection or Predicate types to select the appropriate overload. > > http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/ > This looks okay to me too. -Alan. From Alan.Bateman at oracle.com Thu Sep 5 09:29:32 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Sep 2013 10:29:32 +0100 Subject: RFR: 8024014 : (xs) TEST.groups updates In-Reply-To: References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com> <7E2223FB-8B0B-4000-8CDD-EE25461E0DB7@oracle.com> <522712E7.80404@oracle.com> Message-ID: <52284EFC.8010900@oracle.com> On 04/09/2013 18:12, Mike Duigou wrote: > : > Understood. For now the sub-groups boundaries are the same as bug sub-component categories. I personally don't have any plans for the introducing groups which aren't aligned to component or sub-component boundaries. I think we are in agreement that adding such groups would be hard to manage. I'm okay with the current proposal although if we go down the route of aligning with JIRA subcomponents then it does make me wonder if it is time to just re-organize the java.util tests (Locale, Calendar and are other classes that are maintained on i18n-dev for example). -Alan. From joel.franck at oracle.com Thu Sep 5 09:37:19 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 05 Sep 2013 09:37:19 +0000 Subject: hg: jdk8/tl/langtools: 8023974: Drop 'implements Completer' and 'implements SourceCompleter' from ClassReader resp. JavaCompiler. Message-ID: <20130905093732.0493E62590@hg.openjdk.java.net> Changeset: a76c663a9cac Author: jfranck Date: 2013-09-05 11:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76c663a9cac 8023974: Drop 'implements Completer' and 'implements SourceCompleter' from ClassReader resp. JavaCompiler. Reviewed-by: jjg, jfranck Contributed-by: Andreas Lundblad ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java From dl at cs.oswego.edu Thu Sep 5 11:11:59 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 05 Sep 2013 07:11:59 -0400 Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate) In-Reply-To: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> References: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> Message-ID: <522866FF.9060806@cs.oswego.edu> On 09/04/2013 05:08 PM, Mike Duigou wrote: > Hello all; > > The naming of the Collection.removeIf(Predicate) method has always been an > uncertain choice. We've gone back and forth between naming it removeIf and > overloading the existing removeAll(Collection) with a removeAll(Predicate). > Now that all other library and language decisions seem to be settled it seems > reasonable to make a final decision on this method naming. > > This patch proposes to use the removeAll(Predicate) overload. This choice is > made to increase the discoverability of the method and to "reuse" the > existing user understanding of the removeAll name. There is a minor source > incompatibility induced by overloading the removeAll name--if explicit null > is passed then a compiler cannot resolve which overload to use. Since null is > not a legal value for either overload this source incompatibility is expected > to only affect tests which check to see what response implementations return > for null. The ambiguity can be resolved by providing a cast to either the > Collection or Predicate types to select the appropriate overload. > > http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/ > I'm still mildly opposed. One of the main consequences of how lambda matching rules panned out is that it is in general a bad idea to overload any method accepting a lambda. I imagine that most tutorials etc about designing with lambda will present this as the first rule of thumb. So breaking it here for less-than-compelling reasons sets a questionable example. The main uncompellingness is that removeIf is a more descriptive name than removeAll. As it is, people often refer to docs to check that the existing removeAll(Collection) is short for removeAllElementsContainedInCollection(c). I'm happy to accept majority vote on this though. -Doug From jaroslav.bachorik at oracle.com Thu Sep 5 11:15:55 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Thu, 05 Sep 2013 11:15:55 +0000 Subject: hg: jdk8/tl/jdk: 8023464: test/closed/sun/tracing/ProviderProxyTest.java failing Message-ID: <20130905111656.CB3466259A@hg.openjdk.java.net> Changeset: af1b08ff48ae Author: jbachorik Date: 2013-09-05 13:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af1b08ff48ae 8023464: test/closed/sun/tracing/ProviderProxyTest.java failing Summary: Don't rely on assertions when an Exception suits better Reviewed-by: alanb, dfuchs, sjiang ! src/share/classes/sun/tracing/ProviderSkeleton.java From fweimer at redhat.com Thu Sep 5 11:22:13 2013 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 05 Sep 2013 13:22:13 +0200 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> Message-ID: <52286965.7090807@redhat.com> On 09/04/2013 03:55 PM, Joel Borggren-Franck wrote: > Hi, > > Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 > > Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ This: + *

If this Class object represents an array type, then the returned array + * has a Method object for each of the public methods inherited by the + * array type from {@code Object}, except for clone(). should say "array type from {@code Object}. Although array types define a public {@code clone()} method, it is not included in the returned array." Object#clone() is protected (not public), and clone() should use @code markup. -- Florian Weimer / Red Hat Product Security Team From peter.levart at gmail.com Thu Sep 5 11:51:11 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 05 Sep 2013 13:51:11 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52283C04.2000203@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> Message-ID: <5228702F.8080806@gmail.com> On 09/05/2013 10:08 AM, Daniel Fuchs wrote: >> Or, without using yet another class, double-checked locking, like: >> >> private volatile boolean initializedCalled; >> >> final void ensureLogManagerInitialized() { >> if (initializedCalled) { >> return; >> } >> synchronized (this) { >> final LogManager owner = this; >> // re-check under lock >> if (initializedCalled || owner != manager) { >> // we don't want to do this twice, and we don't want to do >> // this on private manager instances. >> return; >> } >> try { >> AccessController.doPrivileged(....); >> } finally { >> initializedCalled = true; >> } >> } >> } > Ah! Thanks for that comment Peter - that's exactly what I had in mind. >> >> >> ... the code in PrivilegedAction that does the initialization, that >> is, the following statements: >> >> owner.readPrimordialConfiguration(); >> * owner.rootLogger = owner.new RootLogger();* >> owner.addLogger(owner.rootLogger); >> final Logger global = Logger.global; >> owner.addLogger(global); >> >> >> ...almost all of them (except assignment to rootLogger) by themselves >> ensure that the state mutations they make are published to other >> threads, so if also *rootLogger* field was made volatile, such >> double-checked locking would presumably not be broken. > Hmmm... By that I assume you mean the operations that access > LogManager.rootLogger > from LoggerContext. AFAIR all these operations are synchronized on > LoggerContext, The fact that they are synchronized on LoggerContext does not prevent publication of rootLogger to them without write-read edge, since writing to rootLogger field is performed without synchronization on the same LoggerContext (it is performed with synchronization on the LogManager instance)... > and will trigger a call to ensureLogManagerInitialized(). > ensureLogManagerInitialized() is called for every add/get logger > operation. > If ensureLogManagerInitialized() is executing other threads will be > blocked. > When it finishes - threads that were waiting on the monitor will find the > initializationCalled flag set to true and will simply return. Ok. > Threads that call ensureLogManagerInitialized() after that will find > the flag > is true before entering the synchronized block and will return directly. ...and such threads can see rootLogger field being either still null or not null but the Logger instance that is obtained via such data race can be half-initialized. > I can make rootLogger volatile. I'm not 100% sure it is required - but > I think > it is more correct, and as such it will make the code more maintainable. > Good point. It's probably something I would have overlooked. I think volatile rootLogger field is required for correct publication of RootLogger instances if double-checked locking is used... Regards, Peter From peter.levart at gmail.com Thu Sep 5 12:07:25 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 05 Sep 2013 14:07:25 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5228702F.8080806@gmail.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> Message-ID: <522873FD.5070607@gmail.com> On 09/05/2013 01:51 PM, Peter Levart wrote: >>> ...almost all of them (except assignment to rootLogger) by >>> themselves ensure that the state mutations they make are published >>> to other threads, so if also *rootLogger* field was made volatile, >>> such double-checked locking would presumably not be broken. >> Hmmm... By that I assume you mean the operations that access >> LogManager.rootLogger >> from LoggerContext. AFAIR all these operations are synchronized on >> LoggerContext, > > The fact that they are synchronized on LoggerContext does not prevent > publication of rootLogger to them without write-read edge, since > writing to rootLogger field is performed without synchronization on > the same LoggerContext (it is performed with synchronization on the > LogManager instance)... I should have been more precise: The fact that they are synchronized on LoggerContext does not prevent publication of rootLogger to them without write-read edge, since writing to rootLogger field *can be* performed without synchronization on the same LoggerContext (it *can* be performed with synchronization on *just* the LogManager instance)... Such path is entry via LogManager.getLogManager() method ... Peter From jaroslav.bachorik at oracle.com Thu Sep 5 12:35:01 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Thu, 05 Sep 2013 12:35:01 +0000 Subject: hg: jdk8/tl/jdk: 8004179: Few of test/java/lang/management/ThreadMXBean/* tests don't clean up the created threads Message-ID: <20130905123532.492126259C@hg.openjdk.java.net> Changeset: 9522b5e836d3 Author: jbachorik Date: 2013-09-05 14:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9522b5e836d3 8004179: Few of test/java/lang/management/ThreadMXBean/* tests don't clean up the created threads Summary: Just run those tests in "othervm" mode. Reviewed-by: alanb, dfuchs, sjiang ! test/java/lang/management/ThreadMXBean/LockedMonitors.java ! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java ! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java ! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java ! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java From daniel.fuchs at oracle.com Thu Sep 5 12:43:55 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 14:43:55 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5228702F.8080806@gmail.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> Message-ID: <52287C8B.4090109@oracle.com> On 9/5/13 1:51 PM, Peter Levart wrote: >> Threads that call ensureLogManagerInitialized() after that will find >> the flag >> is true before entering the synchronized block and will return directly. > > ...and such threads can see rootLogger field being either still null or > not null but the Logger instance that is obtained via such data race can > be half-initialized. I don't think so, because the flag isn't set to true until the initialization is finished. BTW - there was a reason for having both an initializationCalled *and* a synchronized at method level. The purpose of initializationCalled flag was to prevent infinite recursion in the same thread - because addLogger within ensureLogManagerInitialized will trigger a new call to ensureLogManagerInitialized that the synchronized won't block - since it's in the same thread. So I need in fact two flags: one initializationDone - which will be volatile - the other initializationCalled - which doesn't need to be since it will be always written/read from within the synchronized block. I toyed with the idea of using a single volatile three valued byte instead: initialization: 0 => uninitialized, 1 => initializing, 2 => initialized I opted for the two booleans - but the three valued byte might be more efficient: 1) volatile byte initialization = 0; ensureLogManagerInitialized() { if (initialization == 2) return; // already done synchronized(this) { if (initialization > 0) return; initialization = 1; // avoids recursion try { // do stuff which might recurse on // ensureLogManagerInitialized() } finally { initialization = 2; // mark as done } } } vs 2) volatile boolean initializationDone = false; boolean initializationCalled = false; ensureLogManagerInitialized() { if (initializationDone) return; // already done synchronized(this) { if (initializedCalled || initializationDone) return; initializedCalled = true; // avoids recursion try { // do stuff which might recurse on // ensureLogManagerInitialized() } finally { initializationDone = true; // mark as done. } } } Don't know if you have a preference for one or the other. My current impl (still under test) is 2) best regards, -- daniel > >> I can make rootLogger volatile. I'm not 100% sure it is required - but >> I think >> it is more correct, and as such it will make the code more maintainable. >> Good point. It's probably something I would have overlooked. > > > I think volatile rootLogger field is required for correct publication of > RootLogger instances if double-checked locking is used... > > > Regards, Peter > From joel.franck at oracle.com Thu Sep 5 14:04:30 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Thu, 5 Sep 2013 16:04:30 +0200 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <52286965.7090807@redhat.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> <52286965.7090807@redhat.com> Message-ID: <20130905140430.GJ11725@jfranck-desktop.jrpg.bea.com> Hi Florian, On 2013-09-05, Florian Weimer wrote: > On 09/04/2013 03:55 PM, Joel Borggren-Franck wrote: > >Hi, > > > >Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 > > > >Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ > > This: > > + *

If this Class object represents an array type, then the > returned array > + * has a Method object for each of the public methods inherited by the > + * array type from {@code Object}, except for clone(). > > should say > > "array type from {@code Object}. Although array types define a > public {@code clone()} method, it is not included in the returned > array." > > Object#clone() is protected (not public), and clone() should use > @code markup. > I agree clone() should be {@code clone()}. I don't think the JLS uses "define". Also I think it is actually ok since clone() isn't public. Perhaps change to: * has a Method object for each of the public methods inherited by the * array type from {@code Object}. It does not contain a Method object * for {@code clone()}. cheers /Joel From fweimer at redhat.com Thu Sep 5 14:14:28 2013 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 05 Sep 2013 16:14:28 +0200 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <20130905140430.GJ11725@jfranck-desktop.jrpg.bea.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> <52286965.7090807@redhat.com> <20130905140430.GJ11725@jfranck-desktop.jrpg.bea.com> Message-ID: <522891C4.5060907@redhat.com> On 09/05/2013 04:04 PM, Joel Borggren-Franck wrote: > I don't think the JLS uses "define". Also I think it is actually ok > since clone() isn't public. Perhaps change to: > > * has a Method object for each of the public methods inherited by the > * array type from {@code Object}. It does not contain a Method object > * for {@code clone()}. That looks fine to me, too. -- Florian Weimer / Red Hat Product Security Team From david.lloyd at redhat.com Thu Sep 5 14:18:03 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 05 Sep 2013 09:18:03 -0500 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5228367E.4090600@oracle.com> References: <52279072.4070809@oracle.com> <5227D477.9090402@oracle.com> <5228367E.4090600@oracle.com> Message-ID: <5228929B.2060906@redhat.com> On 09/05/2013 02:45 AM, Daniel Fuchs wrote: > Hi Mandy, > > On 9/5/13 2:46 AM, Mandy Chung wrote: >> >> On 9/4/2013 12:56 PM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a changeset that will fix >>> >>> 8023168: Cleanup LogManager class initialization and >>> LogManager/LoggerContext relationship. >>> >>> >>> >> >> It is good to see the LogManager/Logger initialization untangled. This >> helps in the long run. >> >> LogManager.java L342: thanks to adding the assert here. L340-341 can >> be removed. >> This will be helpful in debugging (rather than swallowing the >> exception). The initialization has been so fragile and swallowing the >> exception makes the problem even worse. With this cleanup, I think >> the initialization code will be more robust. > Will do. >> >> The ensureLogManagerInitialized method does the rest of the >> initialization for the global log manager - it reads the >> configuration, instantiates and registers the root logger, and also >> register the global logger. The comment L289-292 about deadlock >> between two class initializers needs to be revise. > Will do. >> >> I agree with David that it's worth exploring if lazy holder class >> idiom would help here - perhaps a holder class with a static >> rootLogger field. > Well, I am not too keen on using a lazy holder class idiom here. > Though it is true that ensureLogManagerInitialized will do nothing if > called before the 'manager' field > is set, or if called from additional instances of LogManager, I'd prefer > not to stick this code in yet > another static initializer. I do understand the sentiment - static initializers got us into this mess after all! - however I don't think it's a rational one. Lazy holder works well for this because it would only happen once and block progress until it is done. That said, using a volatile+second check under lock is also a reasonable approach (deliberately avoiding the poisonous "double-checked" phrase). However I don't think you need multiple flags; it seems to me that the lock would only be released once initialization was finished, so as long as you only set the flag at the end of processing you'd be sure to be consistent (unless you don't want second callers to block, which might be a reasonable requirement, but I didn't get that out of my reading of the code). > If that's acceptable - I'd prefer to use a > synchronized block within the > method and an additional volatile boolean to mark when initialization is > finished. > > This should make it possible to avoid entering the synchronized block > once the LogManager > is initialized. > >> >> Since you touch these lines, it's good to switch to try-with-resource. >> >> 1205 final InputStream in = new FileInputStream(fname); >> 1206 final BufferedInputStream bin = new BufferedInputStream(in); >> 1207 try { >> 1208 readConfiguration(bin); >> 1209 } finally { >> 1210 in.close(); >> 1211 } >> > OK. > >> Logger.java - getGlobal() method: would it help if the holder class >> has static Logger global field which is set during its class >> initialization. It should guarantee that global.manager is set >> and the log manager initialization completes?? > > Can't do. Logger.global is a public final field. > > -- daniel > >> >> I was wondering if this can be simplified. >> >> thanks >> Mandy >> > -- - DML From daniel.fuchs at oracle.com Thu Sep 5 14:43:41 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 16:43:41 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52287C8B.4090109@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> Message-ID: <5228989D.6060008@oracle.com> Hi, Here is the new patch. It uses an additional volatile flag to avoid synchronizing once the log manager is fully initialized. I have added some comments to spell out the purpose of the flags, as well as some assertion that should make it clear what is expected, what is possible, and what is not. I have also implemented the other remarks from David, Peter, and Mandy. Testing is still under way - but the results so far are looking good. I also ran the JCK for api/java_util - nothing jumped at my face. I have modified my NetBeans configuration to run NetBeans 7.3 over my private build - and I'm not seeing any troubles either so far. (I had done that with the previous patch too) best regards, -- daniel On 9/5/13 2:43 PM, Daniel Fuchs wrote: > On 9/5/13 1:51 PM, Peter Levart wrote: >>> Threads that call ensureLogManagerInitialized() after that will find >>> the flag >>> is true before entering the synchronized block and will return directly. >> >> ...and such threads can see rootLogger field being either still null or >> not null but the Logger instance that is obtained via such data race can >> be half-initialized. > > I don't think so, because the flag isn't set to true until > the initialization is finished. > > BTW - there was a reason for having both an initializationCalled > *and* a synchronized at method level. The purpose of > initializationCalled flag was to prevent infinite recursion in the > same thread - because addLogger within ensureLogManagerInitialized > will trigger a new call to ensureLogManagerInitialized that the > synchronized won't block - since it's in the same thread. > > So I need in fact two flags: one initializationDone - which will > be volatile - the other initializationCalled - which doesn't need > to be since it will be always written/read from within the > synchronized block. > > I toyed with the idea of using a single volatile three valued byte > instead: > > initialization: 0 => uninitialized, 1 => initializing, 2 => initialized > > I opted for the two booleans - but the three valued byte might be more > efficient: > > 1) > > volatile byte initialization = 0; > > ensureLogManagerInitialized() { > if (initialization == 2) return; // already done > synchronized(this) { > if (initialization > 0) return; > initialization = 1; // avoids recursion > try { > // do stuff which might recurse on > // ensureLogManagerInitialized() > } finally { > initialization = 2; // mark as done > } > } > } > > vs 2) > > volatile boolean initializationDone = false; > boolean initializationCalled = false; > > ensureLogManagerInitialized() { > if (initializationDone) return; // already done > synchronized(this) { > if (initializedCalled || initializationDone) return; > initializedCalled = true; // avoids recursion > try { > // do stuff which might recurse on > // ensureLogManagerInitialized() > } finally { > initializationDone = true; // mark as done. > } > } > } > > Don't know if you have a preference for one or the other. > My current impl (still under test) is 2) > > best regards, > > -- daniel > >> >>> I can make rootLogger volatile. I'm not 100% sure it is required - but >>> I think >>> it is more correct, and as such it will make the code more maintainable. >>> Good point. It's probably something I would have overlooked. >> >> >> I think volatile rootLogger field is required for correct publication of >> RootLogger instances if double-checked locking is used... >> >> >> Regards, Peter >> > From paul.sandoz at oracle.com Thu Sep 5 14:50:33 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 Sep 2013 16:50:33 +0200 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: <52281078.4070003@mindspring.com> References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> <522674C2.8050802@cs.oswego.edu> <52267A39.6090807@cs.oswego.edu> <3BBEBBC7-FE5B-47BE-9138-C1292404ABC1@oracle.com> <52281078.4070003@mindspring.com> Message-ID: On Sep 5, 2013, at 7:02 AM, Alan Eliasen wrote: > On 09/04/2013 05:26 PM, Brian Burkhalter wrote: >> I have updated the webrev >> >> http://cr.openjdk.java.net/~bpb/7189139/ >> >> to add the two-parameter version of isProbablePrime() which was >> discussed. Naturally a CCC request would be needed in the event this >> were to go forward. > > The change to pass in the random number generator appears fine. > There's probably no need for a strong random number generator in this > case, though. Rabin-Miller is a robust algorithm and the probability of > its failure can be easily made so that it's far more probable that the > computer's hardware fails while running the test. (I wrote an article > about this if you're interested.) The particular random numbers that it > chooses are not terribly crucial as long as there's enough margin, and > as long as random numbers aren't repeated pathologically. > If that is the case why not just leave the method as is and replace SecureRandom with ThreadLocalRandom? > However, the primality tests could be made more efficient and more > certain. For smallish numbers, the Rabin-Miller test performs a large > number of random tests, with some low probability of failure. > > It's known, however, for numbers less than 341,550,071,728,321, (or > larger, see references below,) that there are minimal sets of bases we > need to test with a Rabin-Miller test to *prove* primality. (This would > also allow us to eliminate generating random numbers entirely, in these > cases, to perform a much smaller number of Rabin-Miller rounds, and let > us skip the Lucas test entirely as well, and enable a *proof* of > primality for numbers smaller than this.) > > For example, if the number n is less than 4,759,123,141 (this > encompasses all ints) then you only need to test that n is a strong > probable prime to bases 2,7, and 61 to *prove* primality. This would be > much faster than the code now > (which may do 50 rounds, and won't do > *more* than 50 rounds, no matter what certainty you request, which is > almost certainly a bug in the current code.) Right, but IIUC 50 rounds will result in a probability of 1 - 1 / 4^50 that the number under test is a prime. If so is there any point in more rounds? we could just clarify the docs. Paul. > It would also be more > correct than the current code, which admits a low probability of failure. > > There are references which show the exact bases to test for smaller > numbers in a Rabin-Miller test to *prove* primality here: > > http://primes.utm.edu/prove/prove2_3.html#quick > http://priv.ckp.pl/wizykowski/sprp.pdf > http://math.crg4.com/primes.html > http://www.gpgpgpu.com/gecco2009/6.pdf > > Further, to *prove* primality of everything that will fit into an > unsigned long (2^64), you only need to test all prime bases <= 37. See: > http://oeis.org/A014233 > > There could be a fast path to do the tests for smallish numbers in a > long or an int. You'll want a modPow function. Here's one for ints: > > /** Compute x^y mod m. Assumes m >= 2. */ > public static int modPow(int x, int y, int m) > { > long acc = 1; > long z = x % m; > while (y != 0) > { > if ((y & 1) != 0) > acc = (acc * z) % m; > z = (z * z) % m; > y >>= 1; > } > return (int) acc; > } > > -- > Alan Eliasen > eliasen at mindspring.com > http://futureboy.us/ From bernd-2013 at eckenfels.net Wed Sep 4 19:34:13 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Wed, 04 Sep 2013 21:34:13 +0200 Subject: hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency In-Reply-To: <20130904145522.D672D62558@hg.openjdk.java.net> References: <20130904145522.D672D62558@hg.openjdk.java.net> Message-ID: Am 04.09.2013, 16:54 Uhr, schrieb : > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829 > 8019853: Break logging and AWT circular dependency This looks pretty strange: http://hg.openjdk.java.net/jdk8/tl/jdk/file/b3d6953b9829/src/share/classes/sun/misc/SharedSecrets.java 173 if (javaAWTAccess == null) { 174 return null; 175 } 176 return javaAWTAccess; Greetings Bernd From matthew at matthewadams.me Thu Sep 5 13:18:14 2013 From: matthew at matthewadams.me (Matthew Adams) Date: Thu, 5 Sep 2013 08:18:14 -0500 Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate) In-Reply-To: <52284E13.1040209@oracle.com> References: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> <52284E13.1040209@oracle.com> Message-ID: I know it's probably too late, but it occurred to me that "removeWhere(Predicate)" seems appropriate: coll.removeWhere(s -> s.size() > 3); On Thu, Sep 5, 2013 at 4:25 AM, Alan Bateman wrote: > On 04/09/2013 22:08, Mike Duigou wrote: > > Hello all; > > > > The naming of the Collection.removeIf(Predicate) method has always been > an uncertain choice. We've gone back and forth between naming it removeIf > and overloading the existing removeAll(Collection) with a > removeAll(Predicate). Now that all other library and language decisions > seem to be settled it seems reasonable to make a final decision on this > method naming. > > > > This patch proposes to use the removeAll(Predicate) overload. This > choice is made to increase the discoverability of the method and to "reuse" > the existing user understanding of the removeAll name. There is a minor > source incompatibility induced by overloading the removeAll name--if > explicit null is passed then a compiler cannot resolve which overload to > use. Since null is not a legal value for either overload this source > incompatibility is expected to only affect tests which check to see what > response implementations return for null. The ambiguity can be resolved by > providing a cast to either the Collection or Predicate types to select the > appropriate overload. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/ > > > This looks okay to me too. > > -Alan. > > -- mailto:matthew at matthewadams.me skype:matthewadams12 googletalk:matthew at matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams From brian.burkhalter at oracle.com Thu Sep 5 16:44:48 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 5 Sep 2013 09:44:48 -0700 Subject: Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1 In-Reply-To: <5227F7C1.9090800@oracle.com> References: <76888C9E-BFA4-43A7-9DBB-29D47C953C55@oracle.com> <52267531.6030801@oracle.com> <21897B5B-86D5-41AB-AFA3-9E18FD9B6324@oracle.com> <5227F7C1.9090800@oracle.com> Message-ID: <5CFF1750-0AB2-4FBD-8B04-8C44348B1A4E@oracle.com> Hi Joe, Thanks. I will push this myself once the Committer role is finalized for pushes. Brian On Sep 4, 2013, at 8:17 PM, Joe Darcy wrote: > Looks fine; approved to go back. From gnu.andrew at redhat.com Thu Sep 5 16:46:41 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 5 Sep 2013 12:46:41 -0400 (EDT) Subject: hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency In-Reply-To: References: <20130904145522.D672D62558@hg.openjdk.java.net> Message-ID: <505637298.7933271.1378399601029.JavaMail.root@redhat.com> ----- Original Message ----- > Am 04.09.2013, 16:54 Uhr, schrieb : > > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829 > > 8019853: Break logging and AWT circular dependency > > This looks pretty strange: > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/b3d6953b9829/src/share/classes/sun/misc/SharedSecrets.java > 173 if (javaAWTAccess == null) { > 174 return null; > 175 } > 176 return javaAWTAccess; > > Greetings > Bernd > Yes, it should now be just "return javaAWTAccess;" following the removal of the second part of the if clause. -- 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 martinrb at google.com Thu Sep 5 16:49:58 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 5 Sep 2013 09:49:58 -0700 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5228989D.6060008@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228989D.6060008@oracle.com> Message-ID: Random review comments: Let me cheerlead your efforts to clean up j.u.logging. It's not easy. Previous efforts (including by myself) have been incomplete because of failure to fully understand the big picture. I've thought that the right approach for write-mostly data structure like in j.u.logging (and in e.g. classloading) is to have mostly-immutable parts with volatile pointers that are updated using CAS. You have some typos: LogMnager initalization initializationCalled + * + **/ => */ On Thu, Sep 5, 2013 at 7:43 AM, Daniel Fuchs wrote: > Hi, > > Here is the new patch. It uses an additional volatile flag > to avoid synchronizing once the log manager is fully initialized. > I have added some comments to spell out the purpose of the flags, > as well as some assertion that should make it clear what is expected, > what is possible, and what is not. > > I have also implemented the other remarks from David, Peter, and Mandy. > > > > > > Testing is still under way - but the results so far are looking good. > I also ran the JCK for api/java_util - nothing jumped at my face. > > I have modified my NetBeans configuration to run NetBeans 7.3 over > my private build - and I'm not seeing any troubles either so far. > > (I had done that with the previous patch too) > > best regards, > > -- daniel > > > > On 9/5/13 2:43 PM, Daniel Fuchs wrote: > >> On 9/5/13 1:51 PM, Peter Levart wrote: >> >>> Threads that call ensureLogManagerInitialized() after that will find >>>> the flag >>>> is true before entering the synchronized block and will return directly. >>>> >>> >>> ...and such threads can see rootLogger field being either still null or >>> not null but the Logger instance that is obtained via such data race can >>> be half-initialized. >>> >> >> I don't think so, because the flag isn't set to true until >> the initialization is finished. >> >> BTW - there was a reason for having both an initializationCalled >> *and* a synchronized at method level. The purpose of >> initializationCalled flag was to prevent infinite recursion in the >> same thread - because addLogger within ensureLogManagerInitialized >> will trigger a new call to ensureLogManagerInitialized that the >> synchronized won't block - since it's in the same thread. >> >> So I need in fact two flags: one initializationDone - which will >> be volatile - the other initializationCalled - which doesn't need >> to be since it will be always written/read from within the >> synchronized block. >> >> I toyed with the idea of using a single volatile three valued byte >> instead: >> >> initialization: 0 => uninitialized, 1 => initializing, 2 => initialized >> >> I opted for the two booleans - but the three valued byte might be more >> efficient: >> >> 1) >> >> volatile byte initialization = 0; >> >> ensureLogManagerInitialized() { >> if (initialization == 2) return; // already done >> synchronized(this) { >> if (initialization > 0) return; >> initialization = 1; // avoids recursion >> try { >> // do stuff which might recurse on >> // ensureLogManagerInitialized() >> } finally { >> initialization = 2; // mark as done >> } >> } >> } >> >> vs 2) >> >> volatile boolean initializationDone = false; >> boolean initializationCalled = false; >> >> ensureLogManagerInitialized() { >> if (initializationDone) return; // already done >> synchronized(this) { >> if (initializedCalled || initializationDone) return; >> initializedCalled = true; // avoids recursion >> try { >> // do stuff which might recurse on >> // ensureLogManagerInitialized() >> } finally { >> initializationDone = true; // mark as done. >> } >> } >> } >> >> Don't know if you have a preference for one or the other. >> My current impl (still under test) is 2) >> >> best regards, >> >> -- daniel >> >> >>> I can make rootLogger volatile. I'm not 100% sure it is required - but >>>> I think >>>> it is more correct, and as such it will make the code more maintainable. >>>> Good point. It's probably something I would have overlooked. >>>> >>> >>> >>> I think volatile rootLogger field is required for correct publication of >>> RootLogger instances if double-checked locking is used... >>> >>> >>> Regards, Peter >>> >>> >> > From daniel.fuchs at oracle.com Thu Sep 5 16:50:17 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 18:50:17 +0200 Subject: hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency In-Reply-To: <505637298.7933271.1378399601029.JavaMail.root@redhat.com> References: <20130904145522.D672D62558@hg.openjdk.java.net> <505637298.7933271.1378399601029.JavaMail.root@redhat.com> Message-ID: <5228B649.3050709@oracle.com> Yes - I'd seen it and intended to fix it and then I forgot. Sorry for that. I will clean that up when I get the chance. -- daniel On 9/5/13 6:46 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Am 04.09.2013, 16:54 Uhr, schrieb : >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829 >>> 8019853: Break logging and AWT circular dependency >> >> This looks pretty strange: >> >> http://hg.openjdk.java.net/jdk8/tl/jdk/file/b3d6953b9829/src/share/classes/sun/misc/SharedSecrets.java >> 173 if (javaAWTAccess == null) { >> 174 return null; >> 175 } >> 176 return javaAWTAccess; >> >> Greetings >> Bernd >> > > Yes, it should now be just "return javaAWTAccess;" following the removal of the second part of the if clause. > From mike.duigou at oracle.com Thu Sep 5 16:58:29 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 5 Sep 2013 09:58:29 -0700 Subject: RFR: 8023340 : (xxs) Clarify that unmodifiable List.replaceAll() may not throw UOE if there are no items to be replaced. Message-ID: Hello all; A very small spec clarification for review. The spec clarification ensures that the behaviour of the default method can satisfy the needs of unmodifiable implementations. http://cr.openjdk.java.net/~mduigou/JDK-8023340/0/webrev/ Thanks, Mike From peter.levart at gmail.com Thu Sep 5 17:15:36 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 05 Sep 2013 19:15:36 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52287C8B.4090109@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> Message-ID: <5228BC38.1030405@gmail.com> On 09/05/2013 02:43 PM, Daniel Fuchs wrote: > On 9/5/13 1:51 PM, Peter Levart wrote: >>> Threads that call ensureLogManagerInitialized() after that will find >>> the flag >>> is true before entering the synchronized block and will return >>> directly. >> >> ...and such threads can see rootLogger field being either still null or >> not null but the Logger instance that is obtained via such data race can >> be half-initialized. > > I don't think so, because the flag isn't set to true until > the initialization is finished. > > BTW - there was a reason for having both an initializationCalled > *and* a synchronized at method level. The purpose of > initializationCalled flag was to prevent infinite recursion in the > same thread - because addLogger within ensureLogManagerInitialized > will trigger a new call to ensureLogManagerInitialized that the > synchronized won't block - since it's in the same thread. Oh, I see. The ensureLogManagerInitialized() is also called from requiresDefaultLoggers() which is called from addLocalLogger(Logger) which is called from addLogger(Logger) which is also called from ensureLogManagerInitialized(). I suspect that calling ensureLogManagerInitialized() from requiresDefaultLoggers() is not needed (any more). Why? - the ensureLogManagerInitialized() is only meant for the global LogManager (LogManager.manager). It has no effect on private LogManagers. - almost all accesses to the global LogManager are done via LogManager.getLogManager() which already calls ensureLogManagerInitialized() before returning the LogManager.manager instance. - the only other places where private LogManager.manager field is accessed directly are: - in the ensureLogManagerInitialized() method itself to skip initialization for private LogManagers - in the LoggerContext.requiresDefaultLoggers() to check if the owner is the global LogManager (an reference equality check) - in the Cleaner.run() to prevent premature GC of global LogManager All those direct LogManager.manager field usages do not call any methods on the so obtained global LogManager, so I conclude that any code that calls any instance method on global LogManager must have obtained it from the LogManager.getLogManager() method and this method already ensures that it is initialized. If you remove a call to ensureLogManagerInitialized() from LoggerContext.requiresDefaultLoggers() then there is one less possibility for recursion. The other is in Logger.getGlobal(). Is this needed? I think not: public static final Logger getGlobal() { if (global != null && global.manager == null) { global.manager = LogManager.getLogManager(); } if (global.manager != null) { global.manager.ensureLogManagerInitialized(); } return global; } Static initialization of Logger class now has no dependency on LogManager, so there should be no recursion in static initialization. The 1st call to Logger.getGlobal() should find global != null and global.manager == null and so LogManager.getLogManager() should be called but that call does not recurse because LogManager obtains the global Logger directly from the deprecated Logger.global field, so the global.manager should be assigned with the initialized global LogManager. No need to call global.manager.ensureLogManagerInitialized() later. The method could simply be: public static final Logger getGlobal() { if (global.manager == null) { global.manager = LogManager.getLogManager(); } return global; } Now that both recursive calls to ensureLogManagerInitialized() are removed, there's no need to check for recursive invocation in the ensureLogManagerInitialized() and initializationCalled flag can be removed. > > So I need in fact two flags: one initializationDone - which will > be volatile - the other initializationCalled - which doesn't need > to be since it will be always written/read from within the > synchronized block. > > I toyed with the idea of using a single volatile three valued byte > instead: > > initialization: 0 => uninitialized, 1 => initializing, 2 => initialized > > I opted for the two booleans - but the three valued byte might be more > efficient: > > 1) > > volatile byte initialization = 0; > > ensureLogManagerInitialized() { > if (initialization == 2) return; // already done > synchronized(this) { > if (initialization > 0) return; > initialization = 1; // avoids recursion > try { > // do stuff which might recurse on > // ensureLogManagerInitialized() > } finally { > initialization = 2; // mark as done > } > } > } > > vs 2) > > volatile boolean initializationDone = false; > boolean initializationCalled = false; > > ensureLogManagerInitialized() { > if (initializationDone) return; // already done > synchronized(this) { > if (initializedCalled || initializationDone) return; > initializedCalled = true; // avoids recursion > try { > // do stuff which might recurse on > // ensureLogManagerInitialized() > } finally { > initializationDone = true; // mark as done. > } > } > } > > Don't know if you have a preference for one or the other. > My current impl (still under test) is 2) After re-checking the JMM cookbook (http://gee.cs.oswego.edu/dl/jmm/cookbook.html), I see that you were right in the following: volatile boolean initializationDone; Logger rootLogger; Thread1: rootLogger = new RootLogger(); initializationDone = true; Thread2: if (initializationDone) { ... Logger logger = rootLogger; ...use logger... } A normal write followed by volatile write can not be reordered. A volatile read followed by normal read can not be reordered either. So if every read access of rootLogger field is performed via some call to LogManager instance method and an instance of global LogManager can only be obtained via LogManager.getLogManager() which calls ensureLogManagerInitialized(), the synchronization should be OK. Regards, Peter > best regards, > > -- daniel > >> >>> I can make rootLogger volatile. I'm not 100% sure it is required - but >>> I think >>> it is more correct, and as such it will make the code more >>> maintainable. >>> Good point. It's probably something I would have overlooked. >> >> >> I think volatile rootLogger field is required for correct publication of >> RootLogger instances if double-checked locking is used... >> >> >> Regards, Peter >> > From guy.steele at oracle.com Thu Sep 5 17:31:57 2013 From: guy.steele at oracle.com (Guy Steele) Date: Thu, 5 Sep 2013 13:31:57 -0400 Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate) In-Reply-To: References: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> <52284E13.1040209@oracle.com> Message-ID: <9ACBBF3B-EE20-46E9-A69D-83399393B262@oracle.com> Let me point out that the "xxxIf" form of name for this idea (removing elements of a list that satisfy a predicate, or otherwise operating on the elements of a list that satisfy a predicate) has a history tracing back to the year 1979. That's more than a third of a century. --Guy On Sep 5, 2013, at 9:18 AM, Matthew Adams wrote: > I know it's probably too late, but it occurred to me that > "removeWhere(Predicate)" seems appropriate: > > coll.removeWhere(s -> s.size() > 3); > > > On Thu, Sep 5, 2013 at 4:25 AM, Alan Bateman wrote: > >> On 04/09/2013 22:08, Mike Duigou wrote: >>> Hello all; >>> >>> The naming of the Collection.removeIf(Predicate) method has always been >> an uncertain choice. We've gone back and forth between naming it removeIf >> and overloading the existing removeAll(Collection) with a >> removeAll(Predicate). Now that all other library and language decisions >> seem to be settled it seems reasonable to make a final decision on this >> method naming. >>> >>> This patch proposes to use the removeAll(Predicate) overload. This >> choice is made to increase the discoverability of the method and to "reuse" >> the existing user understanding of the removeAll name. There is a minor >> source incompatibility induced by overloading the removeAll name--if >> explicit null is passed then a compiler cannot resolve which overload to >> use. Since null is not a legal value for either overload this source >> incompatibility is expected to only affect tests which check to see what >> response implementations return for null. The ambiguity can be resolved by >> providing a cast to either the Collection or Predicate types to select the >> appropriate overload. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/ >>> >> This looks okay to me too. >> >> -Alan. >> >> > > > -- > mailto:matthew at matthewadams.me > skype:matthewadams12 > googletalk:matthew at matthewadams.me > http://matthewadams.me > http://www.linkedin.com/in/matthewadams From naoto.sato at oracle.com Thu Sep 5 17:16:36 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 05 Sep 2013 17:16:36 +0000 Subject: hg: jdk8/tl/jdk: 8023943: Method description fix for String.toLower/UpperCase() methods Message-ID: <20130905171649.D9E73625AC@hg.openjdk.java.net> Changeset: 4c711ef41bfa Author: naoto Date: 2013-09-05 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c711ef41bfa 8023943: Method description fix for String.toLower/UpperCase() methods Reviewed-by: okutsu ! src/share/classes/java/lang/String.java From daniel.fuchs at oracle.com Thu Sep 5 18:16:08 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 20:16:08 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5228BC38.1030405@gmail.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228BC38.1030405@gmail.com> Message-ID: <5228CA68.7050407@oracle.com> Hi Peter, On 9/5/13 7:15 PM, Peter Levart wrote: > On 09/05/2013 02:43 PM, Daniel Fuchs wrote: >> On 9/5/13 1:51 PM, Peter Levart wrote: >>>> Threads that call ensureLogManagerInitialized() after that will find >>>> the flag >>>> is true before entering the synchronized block and will return >>>> directly. >>> >>> ...and such threads can see rootLogger field being either still null or >>> not null but the Logger instance that is obtained via such data race can >>> be half-initialized. >> >> I don't think so, because the flag isn't set to true until >> the initialization is finished. >> >> BTW - there was a reason for having both an initializationCalled >> *and* a synchronized at method level. The purpose of >> initializationCalled flag was to prevent infinite recursion in the >> same thread - because addLogger within ensureLogManagerInitialized >> will trigger a new call to ensureLogManagerInitialized that the >> synchronized won't block - since it's in the same thread. > > Oh, I see. The ensureLogManagerInitialized() is also called from > requiresDefaultLoggers() which is called from addLocalLogger(Logger) > which is called from addLogger(Logger) which is also called from > ensureLogManagerInitialized(). > > I suspect that calling ensureLogManagerInitialized() from > requiresDefaultLoggers() is not needed (any more). Why? Hmmmm... I think that's needed. I could try to take it off and see what breaks ;-) Will double check. An installed subclass of LogManager could potentially call methods on the default log manager without calling LogManager.getLogManager(). public MyLogManager extends LogManager { static volatile MyLogManager INSTANCE; static synchronized boolean singletonCheck() { if (INSTANCE != null) { throw new UnsupportedOperationException(); } return INSTANCE == null; } public MyLogManager() { this(checkSingleton()); } private MyLogManager(boolean first) { synchronized(MyLogManager.class) { if (INSTANCE == null) INSTANCE = this; } } public static getInstance() { return INSTANCE; } } Presumably if we have -Djava.util.logging.manager=MyLogManager then main() could do: main() { MyLogManager.getInstance().getLogger(""); } > - the ensureLogManagerInitialized() is only meant for the global > LogManager (LogManager.manager). It has no effect on private LogManagers. > - almost all accesses to the global LogManager are done via > LogManager.getLogManager() which already calls > ensureLogManagerInitialized() before returning the LogManager.manager > instance. > - the only other places where private LogManager.manager field is > accessed directly are: > - in the ensureLogManagerInitialized() method itself to skip > initialization for private LogManagers > - in the LoggerContext.requiresDefaultLoggers() to check if the > owner is the global LogManager (an reference equality check) > - in the Cleaner.run() to prevent premature GC of global LogManager > > All those direct LogManager.manager field usages do not call any methods > on the so obtained global LogManager, so I conclude that any code that > calls any instance method on global LogManager must have obtained it > from the LogManager.getLogManager() method and this method already > ensures that it is initialized. > > If you remove a call to ensureLogManagerInitialized() from > LoggerContext.requiresDefaultLoggers() then there is one less > possibility for recursion. The other is in Logger.getGlobal(). Is this > needed? I think not: hmmmm... you're almost convincing me... > > public static final Logger getGlobal() { > > if (global != null && global.manager == null) { > global.manager = LogManager.getLogManager(); > } > > if (global.manager != null) { > global.manager.ensureLogManagerInitialized(); > } > > return global; > } > > > Static initialization of Logger class now has no dependency on > LogManager, so there should be no recursion in static initialization. > The 1st call to Logger.getGlobal() should find global != null and > global.manager == null and so LogManager.getLogManager() should be > called but that call does not recurse because LogManager obtains the > global Logger directly from the deprecated Logger.global field, so the > global.manager should be assigned with the initialized global > LogManager. No need to call global.manager.ensureLogManagerInitialized() > later. So the only possible path would be that of the subclass as outlined above. hmmmm... does it deserve the additional complexity? On the other hand - LogManager can be subclassed - so a subclass could override any method in LogManager - for instance addLogger - and could legitimately want to call LogManager.getLogManager() within the overridden method. This would cause a recursion. So I think we need the recursion break - even if we manage to find a way to eliminate direct recursive calls from the standard classes. I believe I'd prefer to play it safe and keep the guards as well as the call to ensureLogManagerInitialized() from requiresDefaultLoggers(). However - I will need to reexamine the case of getGlobal(). As you can imagine I didn't write this in one step. It was a very iterative process. The changes I put in getGlobal() were required to fix an intermittent test failure in TestGetGlobalConcurrent - which happened when several threads called Logger.getGlobal() concurrently. What happened was that Thread #1 would see global.manager null and would call LogManager.getLogManager(). LogManager.getLogManager(), at some point will set global.manager - but this happens before LogManager.getLogManager() is finished (in fact the assignement global.manager = LogManager.getLogManager(); is redundant. It's here only for aesthetical reasons. So at this point Thread #2 could come - see that global.manager is not null, and return global. But global was not fully initialized yet. Actually - I wrote getGlobal() in this way because at the time I felt it made more sense - the reader would feel he understood what is happening. Now I realize it was a mistake because it causes the reader to make assumptions that are false. One way to simplify getGlobal() would be to implement it as follows: public static final Logger getGlobal() { LogManager.getLogManager() // has the side effect // of finishing to initialize global - or // wait until it is fully initialized if // it's beeing initialized by another thread. // Note that it is absolutely mandatory to call // LogManager.getLogManager() unconditionally // here in order to avoid race conditions and // obtain a fully initialized global logger. // here global will be fully initialized. return global; } That's what I should have done. I will do it. -- daniel > > The method could simply be: > > public static final Logger getGlobal() { > > if (global.manager == null) { > global.manager = LogManager.getLogManager(); > } > > return global; > } > > > Now that both recursive calls to ensureLogManagerInitialized() are > removed, there's no need to check for recursive invocation in the > ensureLogManagerInitialized() and initializationCalled flag can be removed. > > >> >> So I need in fact two flags: one initializationDone - which will >> be volatile - the other initializationCalled - which doesn't need >> to be since it will be always written/read from within the >> synchronized block. >> >> I toyed with the idea of using a single volatile three valued byte >> instead: >> >> initialization: 0 => uninitialized, 1 => initializing, 2 => initialized >> >> I opted for the two booleans - but the three valued byte might be more >> efficient: >> >> 1) >> >> volatile byte initialization = 0; >> >> ensureLogManagerInitialized() { >> if (initialization == 2) return; // already done >> synchronized(this) { >> if (initialization > 0) return; >> initialization = 1; // avoids recursion >> try { >> // do stuff which might recurse on >> // ensureLogManagerInitialized() >> } finally { >> initialization = 2; // mark as done >> } >> } >> } >> >> vs 2) >> >> volatile boolean initializationDone = false; >> boolean initializationCalled = false; >> >> ensureLogManagerInitialized() { >> if (initializationDone) return; // already done >> synchronized(this) { >> if (initializedCalled || initializationDone) return; >> initializedCalled = true; // avoids recursion >> try { >> // do stuff which might recurse on >> // ensureLogManagerInitialized() >> } finally { >> initializationDone = true; // mark as done. >> } >> } >> } >> >> Don't know if you have a preference for one or the other. >> My current impl (still under test) is 2) > > After re-checking the JMM cookbook > (http://gee.cs.oswego.edu/dl/jmm/cookbook.html), I see that you were > right in the following: > > volatile boolean initializationDone; > Logger rootLogger; > > Thread1: > > rootLogger = new RootLogger(); > initializationDone = true; > > Thread2: > > if (initializationDone) { > ... > Logger logger = rootLogger; > ...use logger... > } > > A normal write followed by volatile write can not be reordered. > A volatile read followed by normal read can not be reordered either. > > So if every read access of rootLogger field is performed via some call > to LogManager instance method and an instance of global LogManager can > only be obtained via LogManager.getLogManager() which calls > ensureLogManagerInitialized(), the synchronization should be OK. > > > Regards, Peter > >> best regards, >> >> -- daniel >> >>> >>>> I can make rootLogger volatile. I'm not 100% sure it is required - but >>>> I think >>>> it is more correct, and as such it will make the code more >>>> maintainable. >>>> Good point. It's probably something I would have overlooked. >>> >>> >>> I think volatile rootLogger field is required for correct publication of >>> RootLogger instances if double-checked locking is used... >>> >>> >>> Regards, Peter >>> >> > From daniel.fuchs at oracle.com Thu Sep 5 18:18:24 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 20:18:24 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228989D.6060008@oracle.com> Message-ID: <5228CAF0.9040807@oracle.com> Hi Martin, Thanks for the cheers! :-) I am incorporating your comments. Thanks for spotting these issues! best regards, -- daniel On 9/5/13 6:49 PM, Martin Buchholz wrote: > Random review comments: > > Let me cheerlead your efforts to clean up j.u.logging. It's not easy. > Previous efforts (including by myself) have been incomplete because of > failure to fully understand the big picture. > > I've thought that the right approach for write-mostly data structure > like in j.u.logging (and in e.g. classloading) is to have > mostly-immutable parts with volatile pointers that are updated using CAS. > > You have some typos: > LogMnager > initalization > initializationCalled > > + * > + **/ > > => > > */ > > > > On Thu, Sep 5, 2013 at 7:43 AM, Daniel Fuchs > wrote: > > Hi, > > Here is the new patch. It uses an additional volatile flag > to avoid synchronizing once the log manager is fully initialized. > I have added some comments to spell out the purpose of the flags, > as well as some assertion that should make it clear what is expected, > what is possible, and what is not. > > I have also implemented the other remarks from David, Peter, and Mandy. > > > > > Testing is still under way - but the results so far are looking good. > I also ran the JCK for api/java_util - nothing jumped at my face. > > I have modified my NetBeans configuration to run NetBeans 7.3 over > my private build - and I'm not seeing any troubles either so far. > > (I had done that with the previous patch too) > > best regards, > > -- daniel > > > > On 9/5/13 2:43 PM, Daniel Fuchs wrote: > > On 9/5/13 1:51 PM, Peter Levart wrote: > > Threads that call ensureLogManagerInitialized() after > that will find > the flag > is true before entering the synchronized block and will > return directly. > > > ...and such threads can see rootLogger field being either > still null or > not null but the Logger instance that is obtained via such > data race can > be half-initialized. > > > I don't think so, because the flag isn't set to true until > the initialization is finished. > > BTW - there was a reason for having both an initializationCalled > *and* a synchronized at method level. The purpose of > initializationCalled flag was to prevent infinite recursion in the > same thread - because addLogger within ensureLogManagerInitialized > will trigger a new call to ensureLogManagerInitialized that the > synchronized won't block - since it's in the same thread. > > So I need in fact two flags: one initializationDone - which will > be volatile - the other initializationCalled - which doesn't need > to be since it will be always written/read from within the > synchronized block. > > I toyed with the idea of using a single volatile three valued byte > instead: > > initialization: 0 => uninitialized, 1 => initializing, 2 => > initialized > > I opted for the two booleans - but the three valued byte might > be more > efficient: > > 1) > > volatile byte initialization = 0; > > ensureLogManagerInitialized() { > if (initialization == 2) return; // already done > synchronized(this) { > if (initialization > 0) return; > initialization = 1; // avoids recursion > try { > // do stuff which might recurse on > // ensureLogManagerInitialized() > } finally { > initialization = 2; // mark as done > } > } > } > > vs 2) > > volatile boolean initializationDone = false; > boolean initializationCalled = false; > > ensureLogManagerInitialized() { > if (initializationDone) return; // already done > synchronized(this) { > if (initializedCalled || initializationDone) return; > initializedCalled = true; // avoids recursion > try { > // do stuff which might recurse on > // ensureLogManagerInitialized() > } finally { > initializationDone = true; // mark as done. > } > } > } > > Don't know if you have a preference for one or the other. > My current impl (still under test) is 2) > > best regards, > > -- daniel > > > I can make rootLogger volatile. I'm not 100% sure it is > required - but > I think > it is more correct, and as such it will make the code > more maintainable. > Good point. It's probably something I would have > overlooked. > > > > I think volatile rootLogger field is required for correct > publication of > RootLogger instances if double-checked locking is used... > > > Regards, Peter > > > > From daniel.fuchs at oracle.com Thu Sep 5 18:51:10 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 20:51:10 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5228CA68.7050407@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228BC38.1030405@gmail.com> <5228CA68.7050407@oracle.com> Message-ID: <5228D29E.3040805@oracle.com> New webrev. Has Martin's comments + simplified Logger.getGlobal(). Rest left unchanged. Tests are running... cheers, -- daniel On 9/5/13 8:16 PM, Daniel Fuchs wrote: > Hi Peter, > > On 9/5/13 7:15 PM, Peter Levart wrote: >> On 09/05/2013 02:43 PM, Daniel Fuchs wrote: >>> On 9/5/13 1:51 PM, Peter Levart wrote: >>>>> Threads that call ensureLogManagerInitialized() after that will find >>>>> the flag >>>>> is true before entering the synchronized block and will return >>>>> directly. >>>> >>>> ...and such threads can see rootLogger field being either still null or >>>> not null but the Logger instance that is obtained via such data race >>>> can >>>> be half-initialized. >>> >>> I don't think so, because the flag isn't set to true until >>> the initialization is finished. >>> >>> BTW - there was a reason for having both an initializationCalled >>> *and* a synchronized at method level. The purpose of >>> initializationCalled flag was to prevent infinite recursion in the >>> same thread - because addLogger within ensureLogManagerInitialized >>> will trigger a new call to ensureLogManagerInitialized that the >>> synchronized won't block - since it's in the same thread. >> >> Oh, I see. The ensureLogManagerInitialized() is also called from >> requiresDefaultLoggers() which is called from addLocalLogger(Logger) >> which is called from addLogger(Logger) which is also called from >> ensureLogManagerInitialized(). >> >> I suspect that calling ensureLogManagerInitialized() from >> requiresDefaultLoggers() is not needed (any more). Why? > > Hmmmm... I think that's needed. I could try to take it off > and see what breaks ;-) > Will double check. An installed subclass of LogManager > could potentially call methods on the default log manager > without calling LogManager.getLogManager(). > > public MyLogManager extends LogManager { > > static volatile MyLogManager INSTANCE; > static synchronized boolean singletonCheck() { > if (INSTANCE != null) { > throw new UnsupportedOperationException(); > } > return INSTANCE == null; > } > public MyLogManager() { > this(checkSingleton()); > } > private MyLogManager(boolean first) { > synchronized(MyLogManager.class) { > if (INSTANCE == null) INSTANCE = this; > } > } > > public static getInstance() { > return INSTANCE; > } > } > > Presumably if we have -Djava.util.logging.manager=MyLogManager > then main() could do: > > main() { > MyLogManager.getInstance().getLogger(""); > } > > >> - the ensureLogManagerInitialized() is only meant for the global >> LogManager (LogManager.manager). It has no effect on private LogManagers. >> - almost all accesses to the global LogManager are done via >> LogManager.getLogManager() which already calls >> ensureLogManagerInitialized() before returning the LogManager.manager >> instance. >> - the only other places where private LogManager.manager field is >> accessed directly are: >> - in the ensureLogManagerInitialized() method itself to skip >> initialization for private LogManagers >> - in the LoggerContext.requiresDefaultLoggers() to check if the >> owner is the global LogManager (an reference equality check) >> - in the Cleaner.run() to prevent premature GC of global LogManager >> >> All those direct LogManager.manager field usages do not call any methods >> on the so obtained global LogManager, so I conclude that any code that >> calls any instance method on global LogManager must have obtained it >> from the LogManager.getLogManager() method and this method already >> ensures that it is initialized. >> >> If you remove a call to ensureLogManagerInitialized() from >> LoggerContext.requiresDefaultLoggers() then there is one less >> possibility for recursion. The other is in Logger.getGlobal(). Is this >> needed? I think not: > > hmmmm... you're almost convincing me... > >> >> public static final Logger getGlobal() { >> >> if (global != null && global.manager == null) { >> global.manager = LogManager.getLogManager(); > > >> } >> >> if (global.manager != null) { >> global.manager.ensureLogManagerInitialized(); >> } >> >> return global; >> } >> >> >> Static initialization of Logger class now has no dependency on >> LogManager, so there should be no recursion in static initialization. >> The 1st call to Logger.getGlobal() should find global != null and >> global.manager == null and so LogManager.getLogManager() should be >> called but that call does not recurse because LogManager obtains the >> global Logger directly from the deprecated Logger.global field, so the >> global.manager should be assigned with the initialized global >> LogManager. No need to call global.manager.ensureLogManagerInitialized() >> later. > > So the only possible path would be that of the subclass as outlined > above. hmmmm... does it deserve the additional complexity? > > On the other hand - LogManager can be subclassed - so a subclass could > override any method in LogManager - for instance addLogger - and > could legitimately want to call LogManager.getLogManager() within > the overridden method. > This would cause a recursion. > > So I think we need the recursion break - even if we manage to find a > way to eliminate direct recursive calls from the standard classes. > > I believe I'd prefer to play it safe and keep the guards as well as > the call to ensureLogManagerInitialized() from > requiresDefaultLoggers(). > > However - I will need to reexamine the case of getGlobal(). > As you can imagine I didn't write this in one step. > It was a very iterative process. > The changes I put in getGlobal() were required to fix an intermittent > test failure in TestGetGlobalConcurrent - which happened when > several threads called Logger.getGlobal() concurrently. > > What happened was that Thread #1 would see global.manager null > and would call LogManager.getLogManager(). LogManager.getLogManager(), > at some point will set global.manager - but this happens before > LogManager.getLogManager() is finished (in fact the assignement > global.manager = LogManager.getLogManager(); > is redundant. It's here only for aesthetical reasons. > > So at this point Thread #2 could come - see that global.manager is not > null, and return global. But global was not fully initialized yet. > > Actually - I wrote getGlobal() in this way because at the time I felt > it made more sense - the reader would feel he understood what is > happening. > Now I realize it was a mistake because it causes the reader to make > assumptions that are false. > > One way to simplify getGlobal() would be to implement it as follows: > > public static final Logger getGlobal() { > LogManager.getLogManager() // has the side effect > // of finishing to initialize global - or > // wait until it is fully initialized if > // it's beeing initialized by another thread. > // Note that it is absolutely mandatory to call > // LogManager.getLogManager() unconditionally > // here in order to avoid race conditions and > // obtain a fully initialized global logger. > > // here global will be fully initialized. > return global; > } > > That's what I should have done. I will do it. > > -- daniel > >> >> The method could simply be: >> >> public static final Logger getGlobal() { >> >> if (global.manager == null) { >> global.manager = LogManager.getLogManager(); >> } >> >> return global; >> } >> >> >> Now that both recursive calls to ensureLogManagerInitialized() are >> removed, there's no need to check for recursive invocation in the >> ensureLogManagerInitialized() and initializationCalled flag can be >> removed. >> >> >>> >>> So I need in fact two flags: one initializationDone - which will >>> be volatile - the other initializationCalled - which doesn't need >>> to be since it will be always written/read from within the >>> synchronized block. >>> >>> I toyed with the idea of using a single volatile three valued byte >>> instead: >>> >>> initialization: 0 => uninitialized, 1 => initializing, 2 => initialized >>> >>> I opted for the two booleans - but the three valued byte might be more >>> efficient: >>> >>> 1) >>> >>> volatile byte initialization = 0; >>> >>> ensureLogManagerInitialized() { >>> if (initialization == 2) return; // already done >>> synchronized(this) { >>> if (initialization > 0) return; >>> initialization = 1; // avoids recursion >>> try { >>> // do stuff which might recurse on >>> // ensureLogManagerInitialized() >>> } finally { >>> initialization = 2; // mark as done >>> } >>> } >>> } >>> >>> vs 2) >>> >>> volatile boolean initializationDone = false; >>> boolean initializationCalled = false; >>> >>> ensureLogManagerInitialized() { >>> if (initializationDone) return; // already done >>> synchronized(this) { >>> if (initializedCalled || initializationDone) return; >>> initializedCalled = true; // avoids recursion >>> try { >>> // do stuff which might recurse on >>> // ensureLogManagerInitialized() >>> } finally { >>> initializationDone = true; // mark as done. >>> } >>> } >>> } >>> >>> Don't know if you have a preference for one or the other. >>> My current impl (still under test) is 2) >> >> After re-checking the JMM cookbook >> (http://gee.cs.oswego.edu/dl/jmm/cookbook.html), I see that you were >> right in the following: >> >> volatile boolean initializationDone; >> Logger rootLogger; >> >> Thread1: >> >> rootLogger = new RootLogger(); >> initializationDone = true; >> >> Thread2: >> >> if (initializationDone) { >> ... >> Logger logger = rootLogger; >> ...use logger... >> } >> >> A normal write followed by volatile write can not be reordered. >> A volatile read followed by normal read can not be reordered either. >> >> So if every read access of rootLogger field is performed via some call >> to LogManager instance method and an instance of global LogManager can >> only be obtained via LogManager.getLogManager() which calls >> ensureLogManagerInitialized(), the synchronization should be OK. >> >> >> Regards, Peter >> >>> best regards, >>> >>> -- daniel >>> >>>> >>>>> I can make rootLogger volatile. I'm not 100% sure it is required - but >>>>> I think >>>>> it is more correct, and as such it will make the code more >>>>> maintainable. >>>>> Good point. It's probably something I would have overlooked. >>>> >>>> >>>> I think volatile rootLogger field is required for correct >>>> publication of >>>> RootLogger instances if double-checked locking is used... >>>> >>>> >>>> Regards, Peter >>>> >>> >> > From mandy.chung at oracle.com Thu Sep 5 19:34:11 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Sep 2013 12:34:11 -0700 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> Message-ID: <5228DCB3.1090404@oracle.com> On 9/4/13 6:55 AM, Joel Borggren-Franck wrote: > Hi, > > Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 > > Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ > Specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html > > ... > > Me and Alex have also worked on the structure of the docs trying to > unify them and have a better flow. Rough outline is: > This spec clarification and the uniform structure looks good. Might be nit-picking - you can consider to clean up either with this fix or in any future of your revision to the javadoc of java.lang.Class. Some in the javadoc refers "this Class object" as "this object" and either way will work Type names in javadoc are with {@code ....} tag as you have done in other places. s/this Class object/this {@code Class} object/ - there are several occurrences that should be fixed (in line 824, 1536, 1540, 1544, 1548, 1551, 1709, ... more). Similarly s/Method/{@code Method}/ in line 1538, 1542 L1554, 1892 - s/array returned/returned array/ I think that what you try to make consistent. Mandy From brian.burkhalter at oracle.com Thu Sep 5 19:38:13 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 5 Sep 2013 12:38:13 -0700 Subject: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks) In-Reply-To: References: <52257047.3090503@oracle.com> <1ACE92BA-FD96-4DC7-8152-CBB6F99A8D46@oracle.com> <522674C2.8050802@cs.oswego.edu> <52267A39.6090807@cs.oswego.edu> <3BBEBBC7-FE5B-47BE-9138-C1292404ABC1@oracle.com> <52281078.4070003@mindspring.com> Message-ID: <787F2E81-6BB2-401A-9FEE-1A2627CB5F3F@oracle.com> On Sep 5, 2013, at 7:50 AM, Paul Sandoz wrote: >> The change to pass in the random number generator appears fine. >> There's probably no need for a strong random number generator in this >> case, though. > If that is the case why not just leave the method as is and replace SecureRandom with ThreadLocalRandom? I can't speak to the details of the random number generation or primality testing, but from my viewpoint the objective of the proposal was to provide an alternative which solves the "bottleneck" problem described in the issue report while at the same time ensuring consistency with previous JDK versions. If simply replacing SecureRandom with ThreadLocalRandom were acceptable to the PRNG cognoscenti then that would be preferable to me as well. Brian From brent.christian at oracle.com Thu Sep 5 21:30:24 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 05 Sep 2013 14:30:24 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] Message-ID: <5228F7F0.8080605@oracle.com> Please review my changes for 7199674 (http://bugs.sun.com/view_bug.do?bug_id=7199674). This improves how Java .app bundles work when they've been signed for the Mac App Sandbox. Specifically, it changes how the user.home system property is set. For apps signed for the App Sandbox, user.home will point to an accessible location within the App's sandbox container. (If not signed for the App Sandbox, user.home still points to the user's home directory). This is in line with how Mac sandbox-ed apps are expected to work (they are not permitted access to a user's "real" home directory). For reference, an overview of the Mac App Sandbox is at [1], and this specific point comes from [2]: "If you are using a POSIX function such as getpwuid to obtain the path to the user?s actual home directory from directory services (rather than by using the HOME environment variable), consider instead using a Cocoa or Core Foundation symbol such as the NSHomeDirectory function. By using Cocoa or Core Foundation, you support the App Sandbox restriction against directly accessing the user?s home directory." I have confirmed that my change works as expected under the Mac App Sandbox. I bundled my test case a Mac .app, and signed it with the "com.apple.security.app-sandbox" entitlement. When the signed app is run, my usual home directory is reported as !File.canRead(), and the user.home property returns a path under ~/Library/Containers/, which is readable. I plan to label this as "noreg-hard" - signing an .app bundle requires Keychain setup for any machine running the test. Webrev is here: http://cr.openjdk.java.net/~bchristi/7199674/webrev.00/ (One note - the change to make/common/Defs-macosx.gmk is not, strictly speaking, part of this fix, but was necessary for the "old build" to finish on my OS X 10.8.4 system. I've left it in.) An automated build+test run shows no (new) problems. Thanks, -Brent [1] http://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html [2] https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html From robert.field at oracle.com Thu Sep 5 21:59:32 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 05 Sep 2013 21:59:32 +0000 Subject: hg: jdk8/tl/jdk: 8024283: 10 nashorn tests fail with similar stack trace InternalError with cause being NoClassDefFoundError Message-ID: <20130905220001.4BF14625E2@hg.openjdk.java.net> Changeset: 9cc74675a854 Author: rfield Date: 2013-09-05 14:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9cc74675a854 8024283: 10 nashorn tests fail with similar stack trace InternalError with cause being NoClassDefFoundError Summary: Fix pre-existing 292 bug tickled by combo of nashorn code and MethodHandleInfo changes Reviewed-by: jrose Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java From stuart.marks at oracle.com Thu Sep 5 22:46:23 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 05 Sep 2013 15:46:23 -0700 Subject: RFR: 8023447: change specification to allow RMI activation to be optional Message-ID: <522909BF.2090000@oracle.com> Hi all, Please review this specification-only change to allow RMI activation to be optional. RMI activation, unlike the rest of RMI, pretty much requires the ability to fork processes at will. This causes difficulties in certain situations, such as in small embedded configurations. Activation is typically unnecessary in such environments, hence it makes sense for it to be optional. Essentially the change is the addition of a small paragraph to the package doc for java.rmi.activation, and adding spec for throwing UnsupportedOperationException to a bunch of methods in this package. Bug report: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023447 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8023447/webrev.5/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/8023447/specdiff.5/overview-summary.html Thanks, s'marks From xueming.shen at oracle.com Thu Sep 5 23:16:43 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 05 Sep 2013 16:16:43 -0700 Subject: RFR: Faster ZipFile.getEntry()/entries() Message-ID: <522910DB.6060004@oracle.com> Hi, The change proposed here is to bring the zip entry handing code from the native level to the java level. This effectively solves the performance issues of ZipFile.getEntry and entries() that is caused by multiple jni invocation steps to generate one single ZipEntry (see ZipFile.getZipEntry()). A simple non-scientific benchmark test of simply iterating the ZipFile via the Enumeration from entries() on rt.jar/charsets.jar suggests a 50%+ speed boost. http://cr.openjdk.java.net/~sherman/zipfile_j/webrev Couple notes: (1) Ideally it might be desired to go further to bring all the native code of ZipFile to java level (which should help completely remove that mmap crash issue, have better file and memory management... ), but it is suggested that it might be better to limit the scope of the change at this late release circle. (2) JavaFile.read0() is the version that uses "getPrimitiveArrayCritical" to read file bits into the java array directly (instead of using a stack buffer and then copy into the java array), which appears to be 5% faster. But I can't make up my mind of which one would be better. Given (1) the trouble we had before in De/Infalter code (when the getPrimitiveArrayCritical is being heavily used), (2) FileInputStream uses the same "copy" approach, I'm staying with the "copy" appraoch, but option appreciated. (3) We will have to keep the native implementation (zip_util.c) for the vm directly access. Thanks! -Sherman From bhavesh.x.patel at oracle.com Thu Sep 5 23:36:37 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Thu, 05 Sep 2013 23:36:37 +0000 Subject: hg: jdk8/tl/langtools: 8023608: method grouping tabs folding issue Message-ID: <20130905233642.86159625E6@hg.openjdk.java.net> Changeset: e32a8a29643a Author: bpatel Date: 2013-09-05 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e32a8a29643a 8023608: method grouping tabs folding issue Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java From joe.darcy at oracle.com Fri Sep 6 02:13:12 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 05 Sep 2013 19:13:12 -0700 Subject: RFR: 8023447: change specification to allow RMI activation to be optional In-Reply-To: <522909BF.2090000@oracle.com> References: <522909BF.2090000@oracle.com> Message-ID: <52293A38.1060106@oracle.com> Looks fine; cheers, -Joe On 9/5/2013 3:46 PM, Stuart Marks wrote: > Hi all, > > Please review this specification-only change to allow RMI activation > to be optional. RMI activation, unlike the rest of RMI, pretty much > requires the ability to fork processes at will. This causes > difficulties in certain situations, such as in small embedded > configurations. Activation is typically unnecessary in such > environments, hence it makes sense for it to be optional. > > Essentially the change is the addition of a small paragraph to the > package doc for java.rmi.activation, and adding spec for throwing > UnsupportedOperationException to a bunch of methods in this package. > > > Bug report: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023447 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8023447/webrev.5/ > > Specdiff: > > http://cr.openjdk.java.net/~smarks/reviews/8023447/specdiff.5/overview-summary.html > > > Thanks, > > s'marks From joe.darcy at oracle.com Fri Sep 6 02:33:47 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 05 Sep 2013 19:33:47 -0700 Subject: @Supported design issues In-Reply-To: <52284CC4.4030701@oracle.com> References: <51266B7C.3040804@oracle.com>, <5126D516.1040005@oracle.com>, , <5127C4D4.5090800@oracle.com>, <20130222150427.1712@eggemoggin.niobe.net> <51293038.7090503@oracle.com> <5142055C.3060408@oracle.com> <514911B2.30504@oracle.com> <52284CC4.4030701@oracle.com> Message-ID: <52293F0B.9090804@oracle.com> On 9/5/2013 2:20 AM, Alan Bateman wrote: > On 20/03/2013 01:32, Joseph Darcy wrote: >> >> Following up in the same thread, the JEP for this work is now >> available for your reading pleasure at: >> >> JEP 179: Document JDK API Support and Stability >> http://openjdk.java.net/jeps/179 > Joe - do you want to reboot this discussion? With the deadline for API > changes looming then it would be good to get agreement on whether we > are going to do anything on this. I still have the patch to add this > to the APIs that we generate javadoc for in the build - this is the > same set of APIs that I understand to be stable APIs and okay for > applications/libraries to make direct use of. > > Given the previous discussion then getting agreement on whether this > is a boolean or something more seems important. Clearly there are > corner cases (a few of these came up in the original discussion) but a > simple label to convey that an API is stable seems a good start. The > other problematic issue was the naming, clearly "Supported" results in > too many questions, "by who?" in particular. Have you considered > alternative names? I realize this is open to bikeshedding. Personally > I wouldn't have a problem with jdk.Stable if appropriately defined. > IMO, the high order goal here should be getting the "is this API okay to use" information encoded into the source code and class files. Given that you've already compiled that information, I think there is great value in going forward with this effort for JDK 8 even given the relatively late point in the schedule. Perhaps instead of "Supported", the adjective "Sanctioned" better conveys what is intended: this API is explicitly part of the JDK's contract and fine to use. I'm open to other suggestions too. Cheers, -Joe From mandy.chung at oracle.com Fri Sep 6 02:28:18 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Sep 2013 19:28:18 -0700 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5228D29E.3040805@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228BC38.1030405@gmail.com> <5228CA68.7050407@oracle.com> <5228D29E.3040805@oracle.com> Message-ID: <52293DC2.1090903@oracle.com> On 9/5/2013 11:51 AM, Daniel Fuchs wrote: > > Logger.java - I like this and much cleaner fix. 251 // because global.manager will become not null somewhen during 252 // the initialization of LogManager. s/somewhen/somewhere/ The comment for the setLogManager method needs updated since it's called when a logger is registered to a log manager. 347 // It is called from the LogManager. to complete 348 // initialization of the global Logger. The checkPermission() method has this code to deal with null manager: if (manager == null) { // Complete initialization of the global Logger. manager = LogManager.getLogManager(); } I think it's still possible that checkPermission is called with null manager, right? e.g. calling Logger.global.setFilter Should this simply call LogManager.getLogManager() unconditionally as in getGlobal()? LogManager.java - the initialization is really tricky and the discussion on the ensureLogManagerInitialized is very useful. 159 private volatile Logger rootLogger; // non final field - make it volatile to 160 // make sure that other threads will see the new value once 161 // ensureLogManagerInitialized() has finished executing. suggest to move the comments above the declaration Maybe renaming "initializedCalled" to "recursiveInit" to make the 2 variables easy to tell. space missing around "=" in line 270, 271 310 // Read configuration. This was previously triggered 311 // by the new RootLogger() constructor - but no longer. Previously readPrimordialConfiguration() wascalled by LogManager.getLogManager that was triggered when instantiating the RootLogger - to be precise. It seems that leaving out the history might cause less confusion since it no longer calls it. 760 final LogManager owner = getOwner(); 761 logger.setLogManager(owner); Should this have an assert to ensure logger.manager == null or == owner? We don't expect a Logger to change its owner, do we? The behavior of multiple LogManager instances is not specified anyway. Reading the RootLogger - looks like it's potential for cleanup. Logger.global uses a private constructor that doesn't call LogManager.getLogManager to break the cyclic dependency. Perhaps RootLogger should do the same? It's fine to leave it for future if you prefer since you have well tested the bits you have. Mandy From mark.reinhold at oracle.com Fri Sep 6 03:23:14 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 Sep 2013 20:23:14 -0700 Subject: @Supported design issues In-Reply-To: <52293F0B.9090804@oracle.com> References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>, <52293F0B.9090804@oracle.com> Message-ID: <20130905202314.477145@eggemoggin.niobe.net> 2013/9/5 12:33 -0700, joe.darcy at oracle.com: > IMO, the high order goal here should be getting the "is this API okay to > use" information encoded into the source code and class files. Given > that you've already compiled that information, I think there is great > value in going forward with this effort for JDK 8 even given the > relatively late point in the schedule. Agreed. > Perhaps instead of "Supported", the adjective "Sanctioned" better > conveys what is intended: this API is explicitly part of the JDK's > contract and fine to use. @Sanctioned begs the same question as @Supported, i.e., by whom? > I'm open to other suggestions too. Well, looking ahead to when the platform will be composed of modules, those modules will declare that they "export" some API elements, but not others. An @Exported annotation would help get people used to the expected future terminology. Just one idea, I'm sure there are others. - Mark From david.holmes at oracle.com Fri Sep 6 04:49:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Sep 2013 14:49:42 +1000 Subject: RFR: 8023340 : (xxs) Clarify that unmodifiable List.replaceAll() may not throw UOE if there are no items to be replaced. In-Reply-To: References: Message-ID: <52295EE6.80706@oracle.com> Hi Mike, On 6/09/2013 2:58 AM, Mike Duigou wrote: > Hello all; > > A very small spec clarification for review. The spec clarification ensures that the behaviour of the default method can satisfy the needs of unmodifiable implementations. > > http://cr.openjdk.java.net/~mduigou/JDK-8023340/0/webrev/ I don't agree with the change. An Unmodifable list _should_ throw UOE. That aside I don't know how to interpret you change: "operation is not supported by this list for some element" What does "for some element" mean ??? David > Thanks, > > Mike > From daniel.fuchs at oracle.com Fri Sep 6 07:38:32 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 06 Sep 2013 09:38:32 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52293DC2.1090903@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228BC38.1030405@gmail.com> <5228CA68.7050407@oracle.com> <5228D29E.3040805@oracle.com> <52293DC2.1090903@oracle.com> Message-ID: <52298678.7090300@oracle.com> Hi Mandy, Thanks for the feedback! On 9/6/13 4:28 AM, Mandy Chung wrote: > > On 9/5/2013 11:51 AM, Daniel Fuchs wrote: >> >> > > Logger.java - I like this and much cleaner fix. > > 251 // because global.manager will become not null somewhen > during > 252 // the initialization of LogManager. > > s/somewhen/somewhere/ OK > > > The comment for the setLogManager method needs updated since it's > called when a logger is registered to a log manager. > > 347 // It is called from the LogManager. to complete > 348 // initialization of the global Logger. Ah. Right. > > The checkPermission() method has this code to deal with null manager: > if (manager == null) { > // Complete initialization of the global Logger. > manager = LogManager.getLogManager(); > } > > I think it's still possible that checkPermission is called with > null manager, right? e.g. calling Logger.global.setFilter > > Should this simply call LogManager.getLogManager() unconditionally as > in getGlobal()? I don't think this would be required. Maybe we could make checkPermission() static in LogManager? But we might still need to call LogManager.getLogManager() to avoid regression in code using Logger.global directly... > LogManager.java - the initialization is really tricky and the discussion > on the ensureLogManagerInitialized is very useful. > > 159 private volatile Logger rootLogger; // non final field - make > it volatile to > 160 // make sure that other threads will see the new > value once > 161 // ensureLogManagerInitialized() has finished executing. > > suggest to move the comments above the declaration OK > > Maybe renaming "initializedCalled" to "recursiveInit" to make the 2 > variables easy to tell. space missing around "=" in line 270, 271 > > 310 // Read configuration. This was > previously triggered > 311 // by the new RootLogger() constructor - > but no longer. > > Previously readPrimordialConfiguration() wascalled by > LogManager.getLogManager > that was triggered when instantiating the RootLogger - to be precise. > It seems that leaving out the history might cause less confusion > since it no longer calls it. OK > > 760 final LogManager owner = getOwner(); > 761 logger.setLogManager(owner); > > Should this have an assert to ensure logger.manager == null or == owner? > We don't expect a Logger to change its owner, do we? The behavior of > multiple > LogManager instances is not specified anyway. I am concerned it could introduce regressions in applications that use multiple instances of LogManager or subclasses of Logger. I agree this is not perfect. Unfortunately I don't see any ideal solution. > Reading the RootLogger - looks like it's potential for cleanup. > Logger.global uses a private constructor that doesn't call > LogManager.getLogManager to break the cyclic dependency. Perhaps > RootLogger should do the same? It's fine to leave it for future > if you prefer since you have well tested the bits you have. It does. I mean it no longer uses the two args constructor that calls LogManager.getLogManager(). > > Mandy > > From Alan.Bateman at oracle.com Fri Sep 6 07:44:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Sep 2013 08:44:58 +0100 Subject: RFR: 8023447: change specification to allow RMI activation to be optional In-Reply-To: <522909BF.2090000@oracle.com> References: <522909BF.2090000@oracle.com> Message-ID: <522987FA.9060202@oracle.com> On 05/09/2013 23:46, Stuart Marks wrote: > Hi all, > > Please review this specification-only change to allow RMI activation > to be optional. RMI activation, unlike the rest of RMI, pretty much > requires the ability to fork processes at will. This causes > difficulties in certain situations, such as in small embedded > configurations. Activation is typically unnecessary in such > environments, hence it makes sense for it to be optional. Just to put more context on this, this is a continuation (and updated proposal) to the issue/proposal that Steve Flores brought up here back in July [1]. Stuart's revised proposal looks okay. It initially feels like UOE is being allowed to be thrown from too many places (the ActiviationID and ActiviationGroupID constructors in particular) but once you get into the maze then they seem to be necessary. The proposal does mean there is a "porting effort" when you want to target a device that doesn't have the resources to fork new VMs but it shouldn't be too bad. -Alan. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018851.html From robert.field at oracle.com Fri Sep 6 07:44:06 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 06 Sep 2013 07:44:06 +0000 Subject: hg: jdk8/tl/jdk: 8024260: 10 closed/java/lang/invoke/* tests failing after overhaul to MethodHandleInfo Message-ID: <20130906074430.44542625F9@hg.openjdk.java.net> Changeset: f2487bb0c0d2 Author: rfield Date: 2013-09-06 00:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2487bb0c0d2 8024260: 10 closed/java/lang/invoke/* tests failing after overhaul to MethodHandleInfo Reviewed-by: vlivanov, briangoetz Contributed-by: john.r.rose at oracle.com ! src/share/classes/java/lang/invoke/MethodHandle.java From jaroslav.bachorik at oracle.com Fri Sep 6 08:05:26 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Fri, 06 Sep 2013 08:05:26 +0000 Subject: hg: jdk8/tl/jdk: 6815130: Intermittent ThreadMXBean/Locks.java test failure Message-ID: <20130906080549.C7D84625FB@hg.openjdk.java.net> Changeset: da9de6f5cd6f Author: jbachorik Date: 2013-09-06 10:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da9de6f5cd6f 6815130: Intermittent ThreadMXBean/Locks.java test failure Summary: Preventing stale reads from ThreadExecutionSynchronizer.waiting flag Reviewed-by: dholmes, mchung, dfuchs ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer.java From vicente.romero at oracle.com Fri Sep 6 08:54:15 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 06 Sep 2013 08:54:15 +0000 Subject: hg: jdk8/tl/langtools: 8024039: javac, previous solution for JDK-8022186 was incorrect Message-ID: <20130906085421.6D160625FC@hg.openjdk.java.net> Changeset: 7c7b4aea6d50 Author: vromero Date: 2013-09-06 09:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7c7b4aea6d50 8024039: javac, previous solution for JDK-8022186 was incorrect Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java From Alan.Bateman at oracle.com Fri Sep 6 09:27:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Sep 2013 10:27:04 +0100 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <5228F7F0.8080605@oracle.com> References: <5228F7F0.8080605@oracle.com> Message-ID: <52299FE7.2050702@oracle.com> On 05/09/2013 22:30, Brent Christian wrote: > : > > I plan to label this as "noreg-hard" - signing an .app bundle requires > Keychain setup for any machine running the test. > > Webrev is here: > http://cr.openjdk.java.net/~bchristi/7199674/webrev.00/ > > (One note - the change to > make/common/Defs-macosx.gmk > is not, strictly speaking, part of this fix, but was necessary for the > "old build" to finish on my OS X 10.8.4 system. I've left it in.) I don't know Cocoa memory management but from a quick look at the NSAutoreleasePool docs then what you seems to be right. Folks on macosx-port-dev would be better to comment on that. I see that createUTF8CString doesn't handle malloc failing and it's not clear how CFStringGetCString behaves when called with NULL. In any case, this is all early startup and if we have malloc failing this early then we aren't going to get very far. One comment on the error case (fallback to "?") as this is now duplicated. It might be better to have this fallback in one place (GetJavaProperties) as I'm pretty sure we'll need to re-examine it at some point (we periodically hear about environments where user.name/user.home end up as "?", it's been mis-configured systems in all cases that I've looked at but arguably we should fail rather than use "?"). The update to the old build is only interesting if this is back-ported to jdk7u. Hopefully Erik or someone in the build team will be allowed to set their phasers to kill soon. -Alan. From olivier.lagneau at oracle.com Fri Sep 6 09:38:28 2013 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 06 Sep 2013 11:38:28 +0200 Subject: RFR: 8023447: change specification to allow RMI activation to be optional In-Reply-To: <522909BF.2090000@oracle.com> References: <522909BF.2090000@oracle.com> Message-ID: <5229A294.2020103@oracle.com> Hi Stuart, I like this, and think this is the right approach for solving the problem. I see however that ActivationGroupDesc is not impacted by the change. In the case of an implementation that does not support activation, are we sure there will be no way for a developer to create an instance of any the other key activation classes (ActivationGroup, ActivationDesc, ActivationGroupId, ActivationID), using an "Activatable" object (one that does not subclass Activatable) and an ActivationGroupDesc instance, through any "default" behaviour described in the spec ? If that has been checked, that looks fine. Olivier. Stuart Marks said on date 9/6/2013 12:46 AM: > Hi all, > > Please review this specification-only change to allow RMI activation > to be optional. RMI activation, unlike the rest of RMI, pretty much > requires the ability to fork processes at will. This causes > difficulties in certain situations, such as in small embedded > configurations. Activation is typically unnecessary in such > environments, hence it makes sense for it to be optional. > > Essentially the change is the addition of a small paragraph to the > package doc for java.rmi.activation, and adding spec for throwing > UnsupportedOperationException to a bunch of methods in this package. > > > Bug report: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023447 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8023447/webrev.5/ > > Specdiff: > > http://cr.openjdk.java.net/~smarks/reviews/8023447/specdiff.5/overview-summary.html > > > Thanks, > > s'marks From daniel.fuchs at oracle.com Fri Sep 6 10:53:46 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 06 Sep 2013 12:53:46 +0200 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52293DC2.1090903@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228BC38.1030405@gmail.com> <5228CA68.7050407@oracle.com> <5228D29E.3040805@oracle.com> <52293DC2.1090903@oracle.com> Message-ID: <5229B43A.2050401@oracle.com> Hi, Here is a new webrev: It incorporates Mandy comments in the following way: 1. somewhen => somewhere 2. setLogManager method comment updated 3. checkPermission left unchanged (nothing done - as it is unclear that changing it wouldn't cause regressions). 4. rootLogger comment moved above declaration 5. initializationCalled not renamed - but new local variable named isRecursiveInitialization declared at time of use in ensureLogManagerInitialized(). Comments slightly refactored too. 6. comment explaining the history of readPrimordialConfiguration() call removed. 7. Logger.setParent left unchanged (nothing done - as it is unclear that changing it wouldn't cause regressions). best regards, -- daniel From paul.sandoz at oracle.com Fri Sep 6 11:08:54 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Sep 2013 13:08:54 +0200 Subject: RFR 8010293 Re: Potential issue with CHM.toArray In-Reply-To: <3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com> References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com> <521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu> <3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com> Message-ID: <05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com> On Sep 2, 2013, at 3:24 PM, Paul Sandoz wrote: > > On Sep 2, 2013, at 1:18 PM, Doug Lea

wrote: > >> On 08/28/2013 09:13 AM, Peter Levart wrote: >>> On 08/28/2013 12:10 PM, Paul Sandoz wrote: >>>> Hi, >>>> >>>> Intermittent failures were reported with the CHM toArray test in the JDK. >>>> >>>> I updated the tests to increase the number of runs and the number of workers >>>> and i can reliably reproduce on my laptop, see below. >>>> >>>> The test presumes the size should always increase but fails when it observes a >>>> new new size less than the previously observed size. >>>> >>>> Is that a valid assumption? >>> >>> I guess it should be a valid assumption. >> >> Thanks to Peter for a good suggestion for preserving this >> assumption without needing to block (or messily avoid blocking) >> on traversal, and to Paul for helping to re-test. An update is >> now in our CVS and in lambda, so can also now move to tl. >> > > Here is the fix in the lambda repo which can be applied to tl: > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b73937e96ae0 > http://hg.openjdk.java.net/lambda/lambda/jdk/raw-rev/b73937e96ae0 > Anyone up for reviewing this? Thanks, Paul. From joel.franck at oracle.com Fri Sep 6 13:18:20 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Fri, 06 Sep 2013 13:18:20 +0000 Subject: hg: jdk8/tl/jdk: 5047859: (reflect) Class.getField can't find String[].length Message-ID: <20130906131923.F3C7B62604@hg.openjdk.java.net> Changeset: 2064b2077a62 Author: jfranck Date: 2013-09-06 14:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2064b2077a62 5047859: (reflect) Class.getField can't find String[].length Reviewed-by: darcy, mchung ! src/share/classes/java/lang/Class.java + test/java/lang/Class/getField/ArrayLength.java From Alan.Bateman at oracle.com Fri Sep 6 13:38:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Sep 2013 14:38:47 +0100 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> Message-ID: <5229DAE7.80307@oracle.com> On 06/09/2013 11:24, Nicholas Rahn wrote: > As someone with a Java app in the Mac App Store (MAS), I would like to > vote against this change. > > It is still important to know the user's actual home directory > (/Users/) even if the app is running in the sandbox. Using > the entitlement, com.apple.security.files.user-selected.read-write, we > can still write to user selected directories (such as ~/Documents). > So changing the user.home property to point to somewhere in the app's > Container would make it more difficult to get the actual home > directory and thus, other directories that the end-user is familiar > with. I also think this change would lead to more developer confusion > and make application code more complicated. > > I don't know all what the user.home property is used for in the JDK > itself, but concerns about the MAS sandbox would be, IMHO, better > handled using special Mac/MAS only properties, such as those setup by > infinitekind's Appbundler fork on bitbucket: > https://bitbucket.org/infinitekind/appbundler > > Nick I'm sure Brent wants to do the right thing here and maybe this needs some input from the Apple or other Mac-savvy folks as to whether sandboxed apps are really supposed to know about the actual user's home directory. FWIW, the original recommendaiton to switch to NSHomeDirectory came from Scott Kovatch when he was working on Application Bundler. It's very possible that things have changed since then. -Alan. From david.r.chase at oracle.com Fri Sep 6 14:18:00 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 6 Sep 2013 10:18:00 -0400 Subject: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError Message-ID: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com> webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ bug: The bug report is not correct, but there is nonetheless a related underlying bug where IllegalAccessError fails to be thrown. Question #1, is this a corelibs bug? It was filed against compiler, but the fix is in the jdk classes, but it is MethodHandle code. Question #2, what's the best way to write a jtreg test suite that requires incompatible class files, that could not result from a single javac compilation? Question #3, the message(s) attached to the exception are not the same in all cases: a. IllegalAccessError's been caught java.lang.IllegalAccessError: member is private: MethodSupplier.m()void/invokeVirtual, from MethodInvoker b. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker c. IllegalAccessError's been caught java.lang.IllegalAccessError: d. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker The difference between a. and c. above (and these are the two that change under this fix, the code the execution definitely intersects at the fix) is: a = Class.forName("MethodInvoker").getMethod("invoke").invoke(null); c = MethodInvoker.invoke(); yet one has the message copied from the underlying IllegalAccessException (not IAError) and the other does not. David From mandy.chung at oracle.com Fri Sep 6 14:27:45 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 06 Sep 2013 07:27:45 -0700 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <52298678.7090300@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228BC38.1030405@gmail.com> <5228CA68.7050407@oracle.com> <5228D29E.3040805@oracle.com> <52293DC2.1090903@oracle.com> <52298678.7090300@oracle.com> Message-ID: <5229E661.70404@oracle.com> On 9/6/2013 12:38 AM, Daniel Fuchs wrote: > Should this simply call LogManager.getLogManager() unconditionally as > in getGlobal()? > > I don't think this would be required. > Maybe we could make checkPermission() static in LogManager? That's not a bad idea. > But we might still need to call LogManager.getLogManager() to avoid > regression > in code using Logger.global directly... Yup >> 760 final LogManager owner = getOwner(); >> 761 logger.setLogManager(owner); >> >> Should this have an assert to ensure logger.manager == null or == owner? >> We don't expect a Logger to change its owner, do we? The behavior of >> multiple >> LogManager instances is not specified anyway. > I am concerned it could introduce regressions in applications that > use multiple instances of LogManager or subclasses of Logger. > I agree this is not perfect. Unfortunately I don't see any ideal > solution. Are you concerned even if it's an assert? Mandy From chris.hegarty at oracle.com Fri Sep 6 14:43:23 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 06 Sep 2013 15:43:23 +0100 Subject: RFR 8010293 Re: Potential issue with CHM.toArray In-Reply-To: <05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com> References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com> <521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu> <3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com> <05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com> Message-ID: <5229EA0B.7080505@oracle.com> On 06/09/2013 12:08, Paul Sandoz wrote: > > .... >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b73937e96ae0 >> http://hg.openjdk.java.net/lambda/lambda/jdk/raw-rev/b73937e96ae0 >> > > Anyone up for reviewing this? I skimmed the patch and nothing jumps out at me. There does appear to be some code duplication for: void pushState(Node[] t, int i, int n) { void recoverState(int n) { , but it may not be easily refactored. I'm fine to be listed as reviewer, if you need one. -Chris. > > Thanks, > Paul. From Alan.Bateman at oracle.com Fri Sep 6 14:56:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Sep 2013 15:56:14 +0100 Subject: RFR 8010293 Re: Potential issue with CHM.toArray In-Reply-To: <05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com> References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com> <521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu> <3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com> <05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com> Message-ID: <5229ED0E.8010100@oracle.com> On 06/09/2013 12:08, Paul Sandoz wrote: > On Sep 2, 2013, at 3:24 PM, Paul Sandoz wrote: > > : > >> Here is the fix in the lambda repo which can be applied to tl: >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b73937e96ae0 >> http://hg.openjdk.java.net/lambda/lambda/jdk/raw-rev/b73937e96ae0 >> > Anyone up for reviewing this? > The comments are very educational as the resizing is difficult to completely grok without going through examples on a whiteboard. Anyway, I don't see anything obviously wrong after going through it. The test case is useful although creating the list of threads is quite a mouth full to take in. -Alan. From joel.franck at oracle.com Fri Sep 6 15:07:24 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 6 Sep 2013 17:07:24 +0200 Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length In-Reply-To: <20130904132501.GB21307@jfranck-desktop.jrpg.bea.com> References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com> <20130904132501.GB21307@jfranck-desktop.jrpg.bea.com> Message-ID: <7B7DF08F-9459-4D1A-858F-B9332E6CF42B@oracle.com> Thanks for the reviews everyone! cheers /Joel On Sep 4, 2013, at 3:25 PM, Joel Borggren-Franck wrote: > Hi all, > > Thanks for the comments. New webrev here: > > http://cr.openjdk.java.net/~jfranck/5047859/webrev.03/ > > I have also created a specdiff to make it easier to visualize the doc > change: > > http://cr.openjdk.java.net/~jfranck/5047859/specdiff/overview-summary.html > > I made some bigger changes this time to unify the doc of all four > get{Declared}Field{s} methods. I also try to be consistent with the > proposed doc change for getMethods and friends that I will post later > today. > > General outline of the docs is roughly: > > > > > > > I also updated the test to cover all four cases. > > cheers > /Joel > > On 2013-08-26, Joel Borggren-Franck wrote: >> Hi, >> >> Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859 >> >> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/ >> >> This is a spec change to update the spec to match the long-standing implementation. >> >> There is also a clarification of getFields() javadoc without changing the >> spec. >> >> cheers >> /Joel From mandy.chung at oracle.com Fri Sep 6 15:13:20 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 06 Sep 2013 08:13:20 -0700 Subject: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship In-Reply-To: <5229B43A.2050401@oracle.com> References: <52279072.4070809@oracle.com> <5227A7CD.9070302@redhat.com> <52281FAD.70506@gmail.com> <52283C04.2000203@oracle.com> <5228702F.8080806@gmail.com> <52287C8B.4090109@oracle.com> <5228BC38.1030405@gmail.com> <5228CA68.7050407@oracle.com> <5228D29E.3040805@oracle.com> <52293DC2.1090903@oracle.com> <5229B43A.2050401@oracle.com> Message-ID: <5229F110.8030808@oracle.com> On 9/6/2013 3:53 AM, Daniel Fuchs wrote: > Hi, > > Here is a new webrev: > > thanks for the update. Thumbs up. Mandy From Alan.Bateman at oracle.com Fri Sep 6 15:28:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Sep 2013 16:28:56 +0100 Subject: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError In-Reply-To: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com> References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com> Message-ID: <5229F4B8.9000506@oracle.com> On 06/09/2013 15:18, David Chase wrote: > webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ > > bug: The bug report is not correct, but there is nonetheless a related underlying bug where IllegalAccessError fails to be thrown. > > Question #1, is this a corelibs bug? It was filed against compiler, but the fix is in the jdk classes, but it is MethodHandle code. component=core-libs, subcomonent=java.lang.invoke is probably what you are looking for. I think most of the discussion on method handles is on mlvm-dev although it pop up here periodically too. > > Question #2, what's the best way to write a jtreg test suite that requires incompatible class files, that could not result from a single javac compilation? Can you coerce ASM into creating it? Alternatively it is something that you can create off-line and include in a class as a byte array (to load via your own URLClassLoader)? > > Question #3, the message(s) attached to the exception are not the same in all cases: > > a. IllegalAccessError's been caught java.lang.IllegalAccessError: member is private: MethodSupplier.m()void/invokeVirtual, from MethodInvoker > > b. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker > > c. IllegalAccessError's been caught java.lang.IllegalAccessError: > > d. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker > > The difference between a. and c. above (and these are the two that change under this fix, the code the execution definitely intersects at the fix) is: > > a = Class.forName("MethodInvoker").getMethod("invoke").invoke(null); > c = MethodInvoker.invoke(); > > yet one has the message copied from the underlying IllegalAccessException (not IAError) and the other does not. Do you mean you want the messages to be consistent? (I don't think I quite get the question). -Alan From martinrb at google.com Fri Sep 6 15:35:27 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Sep 2013 08:35:27 -0700 Subject: RFR: 8023340 : (xxs) Clarify that unmodifiable List.replaceAll() may not throw UOE if there are no items to be replaced. In-Reply-To: References: Message-ID: ListIterator.set is specified to throw these exceptions: * @throws UnsupportedOperationException if the {@code set} operation * is not supported by this list iterator * @throws ClassCastException if the class of the specified element * prevents it from being added to this list * @throws IllegalArgumentException if some aspect of the specified * element prevents it from being added to this list * @throws IllegalStateException if neither {@code next} nor * {@code previous} have been called, or {@code remove} or * {@code add} have been called after the last call to * {@code next} or {@code previous} List.replaceAll invokes set (conceptually), so it needs to specify the same exceptions, no? Many years ago I made an effort to make these sorts of exception specs more consistent and accurate - a good outlet for my inner pedant. Perhaps that needs to be done once more? Hmmmmmmm..... I notice the above list is missing NullPointerException; that looks like a bug... (my bad, I think) Like David, I don't see the point of this change. UOE is not supposed to be at the element level. If a List or ListIterator doesn't like a particular element, it should be throwing one of the above exceptions (plus NPE). On Thu, Sep 5, 2013 at 9:58 AM, Mike Duigou wrote: > Hello all; > > A very small spec clarification for review. The spec clarification ensures > that the behaviour of the default method can satisfy the needs of > unmodifiable implementations. > > http://cr.openjdk.java.net/~mduigou/JDK-8023340/0/webrev/ > > Thanks, > > Mike From david.r.chase at oracle.com Fri Sep 6 15:49:08 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 6 Sep 2013 11:49:08 -0400 Subject: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError In-Reply-To: <5229F4B8.9000506@oracle.com> References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com> <5229F4B8.9000506@oracle.com> Message-ID: <64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com> On 2013-09-06, at 11:28 AM, Alan Bateman wrote: > On 06/09/2013 15:18, David Chase wrote: >> webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ >> >> bug: The bug report is not correct, but there is nonetheless a related underlying bug where IllegalAccessError fails to be thrown. >> >> Question #1, is this a corelibs bug? It was filed against compiler, but the fix is in the jdk classes, but it is MethodHandle code. > component=core-libs, subcomonent=java.lang.invoke is probably what you are looking for. I think most of the discussion on method handles is on mlvm-dev although it pop up here periodically too. > >> >> Question #2, what's the best way to write a jtreg test suite that requires incompatible class files, that could not result from a single javac compilation? > Can you coerce ASM into creating it? Alternatively it is something that you can create off-line and include in a class as a byte array (to load via your own URLClassLoader)? > >> >> Question #3, the message(s) attached to the exception are not the same in all cases: >> >> a. IllegalAccessError's been caught java.lang.IllegalAccessError: member is private: MethodSupplier.m()void/invokeVirtual, from MethodInvoker >> >> b. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker >> >> c. IllegalAccessError's been caught java.lang.IllegalAccessError: >> >> d. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker >> >> The difference between a. and c. above (and these are the two that change under this fix, the code the execution definitely intersects at the fix) is: >> >> a = Class.forName("MethodInvoker").getMethod("invoke").invoke(null); >> c = MethodInvoker.invoke(); >> >> yet one has the message copied from the underlying IllegalAccessException (not IAError) and the other does not. > Do you mean you want the messages to be consistent? (I don't think I quite get the question). Since all four messages all refer to the same underlying fault, there is some reason to think that they should be consistent. However, the spec is not that detailed, nor am I that determined, and I think the one that is empty is being stripped through some other mechanism that I don't yet understand. I was hoping I would not need to reactivate all the classloader-hacking neurons, but it looks like that will be necessary. I had hope to avoid that complication; the simpler the test, the better. David From david.dehaven at oracle.com Fri Sep 6 16:18:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 6 Sep 2013 09:18:31 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <5229DAE7.80307@oracle.com> References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> Message-ID: >> As someone with a Java app in the Mac App Store (MAS), I would like to vote against this change. >> >> It is still important to know the user's actual home directory (/Users/) even if the app is running in the sandbox. Using the entitlement, com.apple.security.files.user-selected.read-write, we can still write to user selected directories (such as ~/Documents). So changing the user.home property to point to somewhere in the app's Container would make it more difficult to get the actual home directory and thus, other directories that the end-user is familiar with. I also think this change would lead to more developer confusion and make application code more complicated. >> >> I don't know all what the user.home property is used for in the JDK itself, but concerns about the MAS sandbox would be, IMHO, better handled using special Mac/MAS only properties, such as those setup by infinitekind's Appbundler fork on bitbucket: https://bitbucket.org/infinitekind/appbundler >> >> Nick > I'm sure Brent wants to do the right thing here and maybe this needs some input from the Apple or other Mac-savvy folks as to whether sandboxed apps are really supposed to know about the actual user's home directory. > > FWIW, the original recommendaiton to switch to NSHomeDirectory came from Scott Kovatch when he was working on Application Bundler. It's very possible that things have changed since then. I haven't had a chance to look at the changes yet, so this may be a bit premature... Using NSHomeDirectory is the CORRECT behavior, whether the app is sandboxed or not (that extends to ALL apps, not just Java based). If the application needs to access Documents, Music, Movies, etc then those entitlements need to be added. Additionally, even if sandboxed an application can open documents in any folder the user has access to as long as the standard file chooser is used (which I believe we already do), the app will be granted (indirect) access to the selected file(s). -DrD- From sean.mullan at oracle.com Fri Sep 6 16:18:33 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 06 Sep 2013 16:18:33 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130906161859.057FC6260C@hg.openjdk.java.net> Changeset: 0aba8b6232af Author: mullan Date: 2013-09-06 12:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0aba8b6232af 8023362: Don't allow soft-fail behavior if OCSP responder returns "unauthorized" Reviewed-by: vinnie, xuelei ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java + test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java Changeset: f23a84a1cf8e Author: mullan Date: 2013-09-06 12:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f23a84a1cf8e Merge - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh From forax at univ-mlv.fr Fri Sep 6 16:35:46 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 06 Sep 2013 18:35:46 +0200 Subject: RFR 8010293 Re: Potential issue with CHM.toArray In-Reply-To: <5229ED0E.8010100@oracle.com> References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com> <521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu> <3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com> <05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com> <5229ED0E.8010100@oracle.com> Message-ID: <522A0462.3090803@univ-mlv.fr> On 09/06/2013 04:56 PM, Alan Bateman wrote: > On 06/09/2013 12:08, Paul Sandoz wrote: >> On Sep 2, 2013, at 3:24 PM, Paul Sandoz wrote: >> >> : >> >>> Here is the fix in the lambda repo which can be applied to tl: >>> >>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b73937e96ae0 >>> http://hg.openjdk.java.net/lambda/lambda/jdk/raw-rev/b73937e96ae0 >>> >> Anyone up for reviewing this? >> > The comments are very educational as the resizing is difficult to > completely grok without going through examples on a whiteboard. > Anyway, I don't see anything obviously wrong after going through it. > The test case is useful although creating the list of threads is quite > a mouth full to take in. > > -Alan. I agree with Alan, that the test case can be rewritten to be simpler. List workers = IntStream.range(0, nWorkers). .map(w -> w * sizePerWorker) .mapToObj(w -> (Runnable) () -> workFunction.accept(w, w + sizePerWorker)) .map(Thread::new).collect(toList()); the first call to map is the functional way to introduce a local variable, it's a little too much for Java, the cast to Runnable is useless if the creation of the thread is done at the same time, so List workers = IntStream.range(0, nWorkers). .map(w -> { int begin = w * sizePerWorker; int end = begin + sizePerWorker; return new Thread(() -> workFunction.accept(begin, end)); } .collect(toList()); or in an imperative way: ArrayList workers = new ArrayList<>(); for(int i=0; i workFunction.accept(begin, end))); } which is not that bad :) Also workers.stream().forEach(Thread::start); (and respectively workers.stream().forEach(toArray::join); ) should be replaced by workers.forEach(Thread::start); which is more efficient. BTW the whole code can also be written using only the fluent API: IntStream.range(0, nWorkers). .map(w -> w * sizePerWorker) .mapToObj(begin -> new Thread(() -> workFunction.accept(begin, begin + sizePerWorker))) .tee(Thread::start) .collect(toList()) .forEach(toArray::join); sometimes I feel like Pandora. cheers, R?mi From kumar.x.srinivasan at oracle.com Fri Sep 6 16:47:14 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 06 Sep 2013 09:47:14 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 Message-ID: <522A0712.90702@oracle.com> Hello, Please review the changes to remove Solaris 32-bit binaries from JDK8 distros, at this time the dual mode support in the launcher is being disabled. Message regarding this: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html The jdk changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ The top forest changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ Thanks Kumar From nick at transparentech.com Fri Sep 6 10:24:21 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Fri, 6 Sep 2013 12:24:21 +0200 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <52299FE7.2050702@oracle.com> References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> Message-ID: As someone with a Java app in the Mac App Store (MAS), I would like to vote against this change. It is still important to know the user's actual home directory (/Users/) even if the app is running in the sandbox. Using the entitlement, com.apple.security.files.user-selected.read-write, we can still write to user selected directories (such as ~/Documents). So changing the user.home property to point to somewhere in the app's Container would make it more difficult to get the actual home directory and thus, other directories that the end-user is familiar with. I also think this change would lead to more developer confusion and make application code more complicated. I don't know all what the user.home property is used for in the JDK itself, but concerns about the MAS sandbox would be, IMHO, better handled using special Mac/MAS only properties, such as those setup by infinitekind's Appbundler fork on bitbucket: https://bitbucket.org/infinitekind/appbundler Nick On Fri, Sep 6, 2013 at 11:27 AM, Alan Bateman wrote: > On 05/09/2013 22:30, Brent Christian wrote: > >> : >> >> I plan to label this as "noreg-hard" - signing an .app bundle requires >> Keychain setup for any machine running the test. >> >> Webrev is here: >> http://cr.openjdk.java.net/~**bchristi/7199674/webrev.00/ >> >> (One note - the change to >> make/common/Defs-macosx.gmk >> is not, strictly speaking, part of this fix, but was necessary for the >> "old build" to finish on my OS X 10.8.4 system. I've left it in.) >> > I don't know Cocoa memory management but from a quick look at the > NSAutoreleasePool docs then what you seems to be right. Folks on > macosx-port-dev would be better to comment on that. > > I see that createUTF8CString doesn't handle malloc failing and it's not > clear how CFStringGetCString behaves when called with NULL. In any case, > this is all early startup and if we have malloc failing this early then we > aren't going to get very far. > > One comment on the error case (fallback to "?") as this is now duplicated. > It might be better to have this fallback in one place (GetJavaProperties) > as I'm pretty sure we'll need to re-examine it at some point (we > periodically hear about environments where user.name/user.home end up as > "?", it's been mis-configured systems in all cases that I've looked at but > arguably we should fail rather than use "?"). > > The update to the old build is only interesting if this is back-ported to > jdk7u. Hopefully Erik or someone in the build team will be allowed to set > their phasers to kill soon. > > -Alan. > From martinrb at google.com Fri Sep 6 17:20:15 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Sep 2013 10:20:15 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522A0712.90702@oracle.com> References: <522A0712.90702@oracle.com> Message-ID: Google is interested in using DUAL_MODE on Linux and would prefer that at least the code to support DUAL_MODE is not removed. I see that you are not removing DUAL_MODE, just disabling it for Solaris. I would prefer to see DUAL_MODE semi-supported with all OSes, and make support for DUAL_MODE a deployment time decision. If you don't create the 32-bit/64-bit overlays, then the -d32 and -d64 flags simply won't find the alternate set of binaries. Does anyone else in openjdk-land like the ability to use -d32 and -d64? --- I would like to see DUAL_MODE defined as follows, independent of OS: #if defined(LIBARCH32NAME) && defined(LIBARCH64NAME) # define DUAL_MODE #endif --- I'm unhappy that below you are undefing DUAL_MODE even if a user went out of their way to define it. You could more simply remove #define DUAL_MODE #ifdef __solaris__-# define DUAL_MODE+# ifdef DUAL_MODE+# undef DUAL_MODE+# endif On Fri, Sep 6, 2013 at 9:47 AM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > Hello, > > Please review the changes to remove Solaris 32-bit binaries from JDK8 > distros, > at this time the dual mode support in the launcher is being disabled. > > Message regarding this: > http://mail.openjdk.java.net/**pipermail/jdk8-dev/2013-** > September/003159.html > > The jdk changes are here: > http://cr.openjdk.java.net/~**ksrini/8020552/webrev.jdk.0/ > > The top forest changes are here: > http://cr.openjdk.java.net/~**ksrini/8020552/webrev.jdk8.0/ > > > Thanks > Kumar > > > From david.lloyd at redhat.com Fri Sep 6 17:23:48 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 06 Sep 2013 12:23:48 -0500 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: References: <522A0712.90702@oracle.com> Message-ID: <522A0FA4.80708@redhat.com> Another thing to consider is that there may be more "modes" than just 32/64 as time goes on (x32 on Intel springs to mind). Whether that's an argument for keeping dual mode, or dropping it even faster, I'm not sure. On 09/06/2013 12:20 PM, Martin Buchholz wrote: > Google is interested in using DUAL_MODE on Linux and would prefer that at > least the code to support DUAL_MODE is not removed. I see that you are not > removing DUAL_MODE, just disabling it for Solaris. > > I would prefer to see DUAL_MODE semi-supported with all OSes, and make > support for DUAL_MODE a deployment time decision. If you don't create the > 32-bit/64-bit overlays, then the -d32 and -d64 flags simply won't find the > alternate set of binaries. Does anyone else in openjdk-land like the > ability to use -d32 and -d64? > > --- > > I would like to see DUAL_MODE defined as follows, independent of OS: > > #if defined(LIBARCH32NAME) && defined(LIBARCH64NAME) > # define DUAL_MODE > #endif > > --- > > I'm unhappy that below you are undefing DUAL_MODE even if a user went out > of their way to define it. You could more simply remove > #define DUAL_MODE > > #ifdef __solaris__-# define DUAL_MODE+# ifdef DUAL_MODE+# undef > DUAL_MODE+# endif > > > > > On Fri, Sep 6, 2013 at 9:47 AM, Kumar Srinivasan < > kumar.x.srinivasan at oracle.com> wrote: > >> Hello, >> >> Please review the changes to remove Solaris 32-bit binaries from JDK8 >> distros, >> at this time the dual mode support in the launcher is being disabled. >> >> Message regarding this: >> http://mail.openjdk.java.net/**pipermail/jdk8-dev/2013-** >> September/003159.html >> >> The jdk changes are here: >> http://cr.openjdk.java.net/~**ksrini/8020552/webrev.jdk.0/ >> >> The top forest changes are here: >> http://cr.openjdk.java.net/~**ksrini/8020552/webrev.jdk8.0/ >> >> >> Thanks >> Kumar >> >> >> -- - DML From joe.darcy at oracle.com Fri Sep 6 17:31:15 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 06 Sep 2013 10:31:15 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522A0712.90702@oracle.com> References: <522A0712.90702@oracle.com> Message-ID: <522A1163.40103@oracle.com> Hi Kumar, The changes to the launcher itself and the launcher tests look good. Thanks, -Joe On 9/6/2013 9:47 AM, Kumar Srinivasan wrote: > Hello, > > Please review the changes to remove Solaris 32-bit binaries from JDK8 > distros, > at this time the dual mode support in the launcher is being disabled. > > Message regarding this: > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html > > > The jdk changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ > > The top forest changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ > > > Thanks > Kumar > > From roger.riggs at oracle.com Fri Sep 6 17:58:49 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 06 Sep 2013 13:58:49 -0400 Subject: Please review two corrections for java.time Message-ID: <522A17D9.4090103@oracle.com> Please review for two corrections: - The java/time/tck/java/time/TCKLocalTime test failed on a slow machine; the test should be more lenient. The test is not appropriate for a conformance test and is moved to java/time/test/java/time/TestLocalTime. - The javadoc for the JapaneseEra.MEIJI era should indicate the start date is 1868-01-01 to be consistent with java.util.Calendar. Note that java.time does not permit dates before Meiji 6 to be created since the calendar is not clearly defined until then. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ Thanks, Roger From joel.franck at oracle.com Fri Sep 6 18:14:26 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 6 Sep 2013 20:14:26 +0200 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <5228DCB3.1090404@oracle.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> <5228DCB3.1090404@oracle.com> Message-ID: <0F93D1B9-2A10-4D85-B8DA-444D84DBF4E0@oracle.com> Hi Mandy, On Sep 5, 2013, at 9:34 PM, Mandy Chung wrote: > On 9/4/13 6:55 AM, Joel Borggren-Franck wrote: >> Hi, >> >> Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 >> >> Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ >> Specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html >> >> ... >> >> Me and Alex have also worked on the structure of the docs trying to >> unify them and have a better flow. Rough outline is: >> > This spec clarification and the uniform structure looks good. > > Might be nit-picking - you can consider to clean up either with this fix or in any future of your revision to the javadoc of java.lang.Class. > > Some in the javadoc refers "this Class object" as "this object" and either way will work Type names in javadoc are with {@code ....} tag as you have done in other places. s/this Class object/this {@code Class} object/ - there are several occurrences that should be fixed (in line 824, 1536, 1540, 1544, 1548, 1551, 1709, ... more). Similarly s/Method/{@code Method}/ in line 1538, 1542 > > L1554, 1892 - s/array returned/returned array/ > I think that what you try to make consistent. > I noticed this myself when looking at Florian's suggestion. Will fix. cheers /Joel From joel.franck at oracle.com Fri Sep 6 18:19:09 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 6 Sep 2013 20:19:09 +0200 Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type In-Reply-To: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com> Message-ID: Hi Again, Thanks for the comments. New webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.02/ New specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff.02/ I have added {@code } around class names. Also fixed "array returned" to "returned array" including in two places in get{Declared}Fields() for consistency. Also rewrote the clone() clause for getMethods(). please review cheers /Joel On Sep 4, 2013, at 3:55 PM, Joel Borggren-Franck wrote: > Hi, > > Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 > > Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ > Specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html > > There are two issues here, > > - First a getInterfaces() call on an array Class instance does return > Cloneable and Serializable. This is specified for > getGenericInterfaces() but not specified in getInterface(). The fix is > to update the spec to match the implementation, which also aligns it > with getGenericInterfaces(). > > - Also even though JLS states that array types have an implementation of > clone() overriding the Object method, it is not included in > get{Declared}Method{s}. Again the fix is to note this in the spec. > > Me and Alex have also worked on the structure of the docs trying to > unify them and have a better flow. Rough outline is: > > > > > > > cheers > /Joel From roger.riggs at oracle.com Fri Sep 6 19:06:55 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 06 Sep 2013 15:06:55 -0400 Subject: Please review clarification of java.time serialized form Message-ID: <522A27CF.3060607@oracle.com> The specification of the serialized-form[1] of the java.time classes has been improved in response to issue 8024164: JSR310 serialization should be described in detail - Add descriptions in the Ser classes of the mapping between the type bytes and corresponding serialized classes. - Add missing specification of the serial data to writeReplace methods - Add missing readResolve methods that prevent deserialization from improperly formatted streams. - The Era that are Enum's do not need customized serialization; remove unused writeReplace, writeExternal, and readExternal methods, remove unused java.time.chrono.Ser type codes for *Eras and renumber. [1]: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/serialized-form.html Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-8024164/ Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/ Please review and comment. Thanks, Roger From Alan.Bateman at oracle.com Fri Sep 6 19:21:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Sep 2013 20:21:03 +0100 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522A0712.90702@oracle.com> References: <522A0712.90702@oracle.com> Message-ID: <522A2B1F.7010803@oracle.com> On 06/09/2013 17:47, Kumar Srinivasan wrote: > Hello, > > Please review the changes to remove Solaris 32-bit binaries from JDK8 > distros, > at this time the dual mode support in the launcher is being disabled. > > Message regarding this: > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html > > > The jdk changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ > > The top forest changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ I haven't studied the changes yet but I see you've updated test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh. I don't think you need the changes at L42-48, instead you can just "hg rm" the 32-bit libraries that are in test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib. You might want to bring the changes to serviceability-dev because of the change to the JDI launching connector and the JDI tests. -Alan. From kumar.x.srinivasan at oracle.com Fri Sep 6 19:25:45 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 06 Sep 2013 12:25:45 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: References: <522A0712.90702@oracle.com> Message-ID: <522A2C39.8080905@oracle.com> On 9/6/2013 10:20 AM, Martin Buchholz wrote: > Google is interested in using DUAL_MODE on Linux and would prefer that > at least the code to support DUAL_MODE is not removed. I see that you > are not removing DUAL_MODE, just disabling it for Solaris. correct, jdk8 will have the dual mode support. > > I would prefer to see DUAL_MODE semi-supported with all OSes, and make > support for DUAL_MODE a deployment time decision. If you don't create > the 32-bit/64-bit overlays, then the -d32 and -d64 flags simply won't > find the alternate set of binaries. Does anyone else in openjdk-land > like the ability to use -d32 and -d64? Right these flags would be ineffective without dual-mode support, as it was specifically designed to support dual-mode. > > I would like to see DUAL_MODE defined as follows, independent of OS: > > #if defined(LIBARCH32NAME) && defined(LIBARCH64NAME) > # define DUAL_MODE > #endif > Why do you need this implicit logic ? you can always define DUAL_MODE, as a make define. > --- > > I'm unhappy that below you are undefing DUAL_MODE even if a user went > out of their way to define it. You could more simply remove > #define DUAL_MODE Why are you unhappy ? this is specific to solaris you are free to have something else that suits your purposes. > #ifdef __solaris__ > -# define DUAL_MODE > +# ifdef DUAL_MODE > +# undef DUAL_MODE > +# endif > Kumar > > > On Fri, Sep 6, 2013 at 9:47 AM, Kumar Srinivasan > > > wrote: > > Hello, > > Please review the changes to remove Solaris 32-bit binaries from > JDK8 distros, > at this time the dual mode support in the launcher is being disabled. > > Message regarding this: > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html > > The jdk changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ > > > The top forest changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ > > > > Thanks > Kumar > > > From kumar.x.srinivasan at oracle.com Fri Sep 6 20:17:55 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 06 Sep 2013 13:17:55 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522A2B1F.7010803@oracle.com> References: <522A0712.90702@oracle.com> <522A2B1F.7010803@oracle.com> Message-ID: <522A3873.1090309@oracle.com> On 9/6/2013 12:21 PM, Alan Bateman wrote: > On 06/09/2013 17:47, Kumar Srinivasan wrote: >> Hello, >> >> Please review the changes to remove Solaris 32-bit binaries from JDK8 >> distros, >> at this time the dual mode support in the launcher is being disabled. >> >> Message regarding this: >> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html >> >> >> The jdk changes are here: >> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ >> >> The top forest changes are here: >> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ > I haven't studied the changes yet but I see you've updated > test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh. > I don't think you need the changes at L42-48, instead you can just "hg > rm" the 32-bit libraries that are in > test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib. Will do, I was wondering about those libraries. > > You might want to bring the changes to serviceability-dev because of > the change to the JDI launching connector and the JDI tests. cc'ed. Thanks Kumar > > -Alan. > > From joe.darcy at oracle.com Fri Sep 6 20:59:26 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 06 Sep 2013 13:59:26 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: References: <522A0712.90702@oracle.com> Message-ID: <522A422E.1010906@oracle.com> Hello, On 9/6/2013 10:20 AM, Martin Buchholz wrote: > Google is interested in using DUAL_MODE on Linux and would prefer that at > least the code to support DUAL_MODE is not removed. I see that you are not > removing DUAL_MODE, just disabling it for Solaris. > > I would prefer to see DUAL_MODE semi-supported with all OSes, and make > support for DUAL_MODE a deployment time decision. If you don't create the > 32-bit/64-bit overlays, then the -d32 and -d64 flags simply won't find the > alternate set of binaries. Does anyone else in openjdk-land like the > ability to use -d32 and -d64? As the engineer who added DUAL_MODE support way back in JDK 5, I can say with authority that DUAL_MODE is an ugly hack that makes the launcher non-trivially harder to maintain. My preferred path for JDK 8 (which we are not taking) is to fully purge all the DUAL_MODE code from the launcher. However, IMO that purging would be a fine change early in 9. I understand that Google internally maintains a patch-set on top of the upstream OpenJDK sources. If DUAL_MODE is removed from the upstream JDK, it is technically possible for other parties to resurrect and maintain the functionality themselves. Cheers, -Joe > > --- > > I would like to see DUAL_MODE defined as follows, independent of OS: > > #if defined(LIBARCH32NAME) && defined(LIBARCH64NAME) > # define DUAL_MODE > #endif > > --- > > I'm unhappy that below you are undefing DUAL_MODE even if a user went out > of their way to define it. You could more simply remove > #define DUAL_MODE > > #ifdef __solaris__-# define DUAL_MODE+# ifdef DUAL_MODE+# undef > DUAL_MODE+# endif > > > > > On Fri, Sep 6, 2013 at 9:47 AM, Kumar Srinivasan < > kumar.x.srinivasan at oracle.com> wrote: > >> Hello, >> >> Please review the changes to remove Solaris 32-bit binaries from JDK8 >> distros, >> at this time the dual mode support in the launcher is being disabled. >> >> Message regarding this: >> http://mail.openjdk.java.net/**pipermail/jdk8-dev/2013-** >> September/003159.html >> >> The jdk changes are here: >> http://cr.openjdk.java.net/~**ksrini/8020552/webrev.jdk.0/ >> >> The top forest changes are here: >> http://cr.openjdk.java.net/~**ksrini/8020552/webrev.jdk8.0/ >> >> >> Thanks >> Kumar >> >> >> From jonathan.gibbons at oracle.com Fri Sep 6 22:32:11 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 06 Sep 2013 22:32:11 +0000 Subject: hg: jdk8/tl/langtools: 8024434: problem running javadoc tests in samevm mode on Windows Message-ID: <20130906223218.3827162619@hg.openjdk.java.net> Changeset: 64328fe5e4a6 Author: jjg Date: 2013-09-06 15:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64328fe5e4a6 8024434: problem running javadoc tests in samevm mode on Windows Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! test/tools/javadoc/api/basic/APITest.java ! test/tools/javadoc/api/basic/GetTask_FileManagerTest.java From mike.duigou at oracle.com Fri Sep 6 23:09:40 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 6 Sep 2013 16:09:40 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <5228F7F0.8080605@oracle.com> References: <5228F7F0.8080605@oracle.com> Message-ID: <36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com> The non-MacOS parts look fine to me. I can't comment on the Objective C or MacOS code but the test you describe seems sufficient to confirm it is correct. I am surprised that strdup isn't needed for the constant "?" string but java_props_md.c seems to include other constant strings in sprops so I will assume it is just never deallocated in the lifetime of the JVM. Mike On Sep 5 2013, at 14:30 , Brent Christian wrote: > Please review my changes for 7199674 > (http://bugs.sun.com/view_bug.do?bug_id=7199674). > > This improves how Java .app bundles work when they've been signed for the Mac App Sandbox. Specifically, it changes how the user.home system property is set. > > For apps signed for the App Sandbox, user.home will point to an accessible location within the App's sandbox container. (If not signed for the App Sandbox, user.home still points to the user's home directory). > > This is in line with how Mac sandbox-ed apps are expected to work (they are not permitted access to a user's "real" home directory). For reference, an overview of the Mac App Sandbox is at [1], and this specific point comes from [2]: > > "If you are using a POSIX function such as getpwuid to obtain the path to the user?s actual home directory from directory services (rather than by using the HOME environment variable), consider instead using a Cocoa or Core Foundation symbol such as the NSHomeDirectory function. By using Cocoa or Core Foundation, you support the App Sandbox restriction against directly accessing the user?s home directory." > > > I have confirmed that my change works as expected under the Mac App Sandbox. I bundled my test case a Mac .app, and signed it with the "com.apple.security.app-sandbox" entitlement. When the signed app is run, my usual home directory is reported as !File.canRead(), and the user.home property returns a path under ~/Library/Containers/, which is readable. > > I plan to label this as "noreg-hard" - signing an .app bundle requires Keychain setup for any machine running the test. > > Webrev is here: > http://cr.openjdk.java.net/~bchristi/7199674/webrev.00/ > > (One note - the change to > make/common/Defs-macosx.gmk > is not, strictly speaking, part of this fix, but was necessary for the "old build" to finish on my OS X 10.8.4 system. I've left it in.) > > An automated build+test run shows no (new) problems. > > Thanks, > -Brent > > [1] http://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html > [2] https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html From david.r.chase at oracle.com Fri Sep 6 23:59:01 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 6 Sep 2013 19:59:01 -0400 Subject: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError In-Reply-To: <64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com> References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com> <5229F4B8.9000506@oracle.com> <64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com> Message-ID: new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/ Same small changes to the sources, plus a test. bug: wrong exception was thrown in call of methodhandle to private method fix: detect special case of IllegalAccessException, convert to IllegalAccessError testing: verified that the test would pass with modified library verified that the test would fail with old library verified that the test would fail if the class substitution (for some reason) did not occur jtreg of jdk/test/java/lang/invoke -- note that the new exception thrown is a subtype of the old one, so this is unlikely to create a new surprise From stuart.marks at oracle.com Sat Sep 7 00:04:04 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 06 Sep 2013 17:04:04 -0700 Subject: RFR: 8023447: change specification to allow RMI activation to be optional In-Reply-To: <522987FA.9060202@oracle.com> References: <522909BF.2090000@oracle.com> <522987FA.9060202@oracle.com> Message-ID: <522A6D74.2010008@oracle.com> On 9/6/13 12:44 AM, Alan Bateman wrote: > On 05/09/2013 23:46, Stuart Marks wrote: >> Please review this specification-only change to allow RMI activation >> to be optional. RMI activation, unlike the rest of RMI, pretty much >> requires the ability to fork processes at will. This causes >> difficulties in certain situations, such as in small embedded >> configurations. Activation is typically unnecessary in such >> environments, hence it makes sense for it to be optional. > Just to put more context on this, this is a continuation (and updated > proposal) to the issue/proposal that Steve Flores brought up here back > in July [1]. > > Stuart's revised proposal looks okay. It initially feels like UOE is > being allowed to be thrown from too many places (the ActiviationID and > ActiviationGroupID constructors in particular) but once you get into the > maze then they seem to be necessary. The proposal does mean there is a > "porting effort" when you want to target a device that doesn't have the > resources to fork new VMs but it shouldn't be too bad. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018851.html Hi Alan, Thanks for linking this back to the earlier discussion. Yes, I had thought there were too many UOEs thrown, and I spent a bunch of time trying to minimize them, and I wasn't able to. Then Alan and I spent a bunch more time going over it again and we still weren't able to minimize it. It's a bit tedious to have UOE in so many places, but oh well. s'marks From brent.christian at oracle.com Sat Sep 7 00:08:56 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 06 Sep 2013 17:08:56 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> Message-ID: <522A6E98.1060101@oracle.com> Hi, Nick. Thanks for your feedback. I'm glad to hear from someone who has experience with App Store deployment. On 9/6/13 2:17 PM, Nicholas Rahn wrote: > If you're saying that NSHomeDirectory is the correct behaviour for the Java > user.home property, then I have to disagree. On every other platform, > including non-sandboxed Mac, user.home is the actual user's home directory > (i.e. /home/ or /Users/ or C:\Users\). NSHomeDirectory still returns /Users/ on non-sandboxed Mac. From my testing today, it seems the native Mac file dialog (which underlies java.awt.FileDialog) does understand the "sandboxed" NSHomeDirectory path. If you FileDialog.setDirectory() to it, the dialog comes up showing /Users/. This also works directories contained in ~, such as ~/Documents. (All this requires com.apple.security.files.user-selected.[read-only|read-write], of course). So that's a bit surprising, though it does mean that: String userHomePath = System.getProperty("user.home"); myFileDialog.setDirectory(userHomePath + "/Documents"); will give you a FileDialog pointing to ~/Documents whether or not you're running in the sandbox. My understanding is that, when sandboxed, the *only* way to access files within the User's "real" home directory is by selecting them in the native file browser. And of course at that point, you can get the path from the selected file. The difference, then, is how user.home can be used outside the context of a FileDialog. Currently, I think the answer when running in the sandbox is "it can't" (unless there are other Entitlements that would make the path to ~ accessible). So the thinking here is that there is more value in having user.home reflect an accessible location. > Setting user.home > to the *application's* home directory (which is what NSHomeDirectory > returns in a sandboxed environment) would seem to me to break the > definition of the user.home property. > > On a mac, in a sandboxed and non-sandboxed environment, I would expect > user.home to be NSHomeDirectoryForUser.> I can look into NSHomeDirectoryForUser. NSHomeDirectory was used because it's what is mentioned in the Apple documentation I've seen regarding the App Sandbox. > A sandboxed Java app definitely > needs to know about the app's Container directory (and even whether it's > actually being run sandboxed or not), but redefining user.home doesn't seem > like the right solution. Having AppBundler (or even the JRE) provide that > information via special properties feels better from my developer's > perspective. Adding an additional special property may or may not fly, but I can look into it. Thanks, -Brent > On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven wrote: > >> >>>> As someone with a Java app in the Mac App Store (MAS), I would like to >> vote against this change. >>>> >>>> It is still important to know the user's actual home directory >> (/Users/) even if the app is running in the sandbox. Using the >> entitlement, com.apple.security.files.user-selected.read-write, we can >> still write to user selected directories (such as ~/Documents). So >> changing the user.home property to point to somewhere in the app's >> Container would make it more difficult to get the actual home directory and >> thus, other directories that the end-user is familiar with. I also think >> this change would lead to more developer confusion and make application >> code more complicated. >>>> >>>> I don't know all what the user.home property is used for in the JDK >> itself, but concerns about the MAS sandbox would be, IMHO, better handled >> using special Mac/MAS only properties, such as those setup by >> infinitekind's Appbundler fork on bitbucket: >> https://bitbucket.org/infinitekind/appbundler >>>> >>>> Nick >>> I'm sure Brent wants to do the right thing here and maybe this needs >> some input from the Apple or other Mac-savvy folks as to whether sandboxed >> apps are really supposed to know about the actual user's home directory. >>> >>> FWIW, the original recommendaiton to switch to NSHomeDirectory came from >> Scott Kovatch when he was working on Application Bundler. It's very >> possible that things have changed since then. >> >> >> I haven't had a chance to look at the changes yet, so this may be a bit >> premature... >> >> >> Using NSHomeDirectory is the CORRECT behavior, whether the app is >> sandboxed or not (that extends to ALL apps, not just Java based). >> >> If the application needs to access Documents, Music, Movies, etc then >> those entitlements need to be added. Additionally, even if sandboxed an >> application can open documents in any folder the user has access to as long >> as the standard file chooser is used (which I believe we already do), the >> app will be granted (indirect) access to the selected file(s). >> >> -DrD- >> >> From lana.steuck at oracle.com Sat Sep 7 00:10:57 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 07 Sep 2013 00:10:57 +0000 Subject: hg: jdk8/tl: 11 new changesets Message-ID: <20130907001059.37A9262620@hg.openjdk.java.net> Changeset: f8405a0fa69c Author: erikj Date: 2013-08-26 13:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f8405a0fa69c 8023216: Feedback on README-builds.html Reviewed-by: anthony, robilad, tbell ! README-builds.html Changeset: 5166118c5917 Author: katleman Date: 2013-08-26 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5166118c5917 Merge Changeset: 246cdbaa6c62 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/246cdbaa6c62 Added tag jdk8-b105 for changeset 5166118c5917 ! .hgtags Changeset: 4ac867c44467 Author: lana Date: 2013-08-29 16:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4ac867c44467 Merge Changeset: 21198f51bc7e Author: erikj Date: 2013-08-29 15:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/21198f51bc7e 8003162: build-infra: Improve suggestions for missing packages on linux Reviewed-by: tbell, omajid ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/libraries.m4 Changeset: 92facce22941 Author: erikj Date: 2013-08-30 10:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/92facce22941 8023957: Lock down version of autoconf Reviewed-by: chegar, dsamersoff, tbell, dholmes ! README-builds.html ! common/autoconf/autogen.sh ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh Changeset: 2aacc7080d36 Author: katleman Date: 2013-09-03 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2aacc7080d36 Merge Changeset: 0f6dde6231bd Author: ihse Date: 2013-09-04 10:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0f6dde6231bd 8024155: Fix 'make CONF= ' Reviewed-by: erikj, tbell ! NewMakefile.gmk ! common/makefiles/Main.gmk Changeset: 8e7b4d9fb00f Author: erikj Date: 2013-09-04 10:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8e7b4d9fb00f Merge ! NewMakefile.gmk ! common/makefiles/Main.gmk Changeset: 58f1b6f32b47 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/58f1b6f32b47 Added tag jdk8-b106 for changeset 8e7b4d9fb00f ! .hgtags Changeset: 73355c4c1bc8 Author: lana Date: 2013-09-06 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/73355c4c1bc8 Merge From lana.steuck at oracle.com Sat Sep 7 00:11:00 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 07 Sep 2013 00:11:00 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20130907001105.D617E62622@hg.openjdk.java.net> Changeset: 824d33e678f2 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/824d33e678f2 Added tag jdk8-b105 for changeset f484bfb624dd ! .hgtags Changeset: bf70cbd2c836 Author: lana Date: 2013-08-29 16:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bf70cbd2c836 Merge Changeset: f35e1255024b Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f35e1255024b Added tag jdk8-b106 for changeset bf70cbd2c836 ! .hgtags Changeset: 9e4acaa1bb7e Author: lana Date: 2013-09-06 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9e4acaa1bb7e Merge From lana.steuck at oracle.com Sat Sep 7 00:10:52 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 07 Sep 2013 00:10:52 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20130907001055.A93A06261F@hg.openjdk.java.net> Changeset: 2e3a056c84a7 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2e3a056c84a7 Added tag jdk8-b105 for changeset 4e38de7c767e ! .hgtags Changeset: 23fc34133152 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/23fc34133152 Added tag jdk8-b106 for changeset 2e3a056c84a7 ! .hgtags Changeset: 4853dc082c7d Author: lana Date: 2013-09-06 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4853dc082c7d Merge From lana.steuck at oracle.com Sat Sep 7 00:10:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 07 Sep 2013 00:10:56 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130907001105.3F75662621@hg.openjdk.java.net> Changeset: d3be8e3b429d Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d3be8e3b429d Added tag jdk8-b105 for changeset 09a46ec11f88 ! .hgtags Changeset: d6a32e3831aa Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d6a32e3831aa Added tag jdk8-b106 for changeset d3be8e3b429d ! .hgtags From lana.steuck at oracle.com Sat Sep 7 00:10:57 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 07 Sep 2013 00:10:57 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20130907001110.5846962623@hg.openjdk.java.net> Changeset: 01be6f93d0a4 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/01be6f93d0a4 Added tag jdk8-b105 for changeset 88390df7ed2c ! .hgtags Changeset: 6908370afe83 Author: lana Date: 2013-08-29 16:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6908370afe83 Merge Changeset: e3c9328f7563 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e3c9328f7563 Added tag jdk8-b106 for changeset 6908370afe83 ! .hgtags From lana.steuck at oracle.com Sat Sep 7 00:11:04 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 07 Sep 2013 00:11:04 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130907001122.B4D5962624@hg.openjdk.java.net> Changeset: e431c9bfb171 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e431c9bfb171 Added tag jdk8-b105 for changeset 375834b5cf08 ! .hgtags Changeset: fcd768844b99 Author: lana Date: 2013-08-29 16:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fcd768844b99 Merge - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java - test/tools/javac/8015701/AnonymousParameters.java Changeset: 3f274927ec18 Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3f274927ec18 Added tag jdk8-b106 for changeset fcd768844b99 ! .hgtags Changeset: c9d6f4749f87 Author: lana Date: 2013-09-06 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c9d6f4749f87 Merge Changeset: e84587462a47 Author: lana Date: 2013-09-06 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e84587462a47 Merge From lana.steuck at oracle.com Sat Sep 7 00:11:30 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 07 Sep 2013 00:11:30 +0000 Subject: hg: jdk8/tl/hotspot: 70 new changesets Message-ID: <20130907001401.11CA962625@hg.openjdk.java.net> Changeset: 37165c3618a3 Author: amurillo Date: 2013-08-16 04:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37165c3618a3 8023152: new hotspot build - hs25-b47 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d96f52012aaa Author: rdurbin Date: 2013-08-14 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d96f52012aaa 8005073: [TESTBUG] remove crufty '_g' support from HS tests Summary: remove crufty '_g' support from HS tests Reviewed-by: dcubed, sla ! test/Makefile Changeset: 740e263c80c6 Author: hseigel Date: 2013-08-15 20:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/740e263c80c6 8003424: Enable Class Data Sharing for CompressedOops 8016729: ObjectAlignmentInBytes=16 now forces the use of heap based compressed oops 8005933: The -Xshare:auto option is ignored for -server Summary: Move klass metaspace above the heap and support CDS with compressed klass ptrs. Reviewed-by: coleenp, kvn, mgerdin, tschatzl, stefank ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java + test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java + test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java Changeset: e5003079dfa5 Author: dcubed Date: 2013-08-16 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5003079dfa5 Merge ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b1fd869e7df0 Author: minqi Date: 2013-08-19 09:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b1fd869e7df0 8023188: Unsafe volatile double store on bsd is broken Reviewed-by: dcubed, dholmes Contributed-by: yumin.qi at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp Changeset: 1a8fb39bdbc4 Author: ehelin Date: 2013-08-07 16:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a8fb39bdbc4 8014659: NPG: performance counters for compressed klass space Reviewed-by: mgerdin, coleenp, hseigel, jmasa, ctornqvi ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/universe.cpp + test/gc/metaspace/TestMetaspacePerfCounters.java + test/testlibrary/AssertsTest.java + test/testlibrary/com/oracle/java/testlibrary/Asserts.java + test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java + test/testlibrary/com/oracle/java/testlibrary/InMemoryJavaCompiler.java + test/testlibrary/com/oracle/java/testlibrary/InputArguments.java + test/testlibrary/com/oracle/java/testlibrary/PerfCounter.java + test/testlibrary/com/oracle/java/testlibrary/PerfCounters.java Changeset: 878bb0b7e799 Author: ehelin Date: 2013-08-19 17:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/878bb0b7e799 Merge Changeset: 10c59b8021ec Author: kevinw Date: 2013-08-19 14:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10c59b8021ec 8022655: ClassDump ignored jarStream setting Reviewed-by: minqi, sla ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! test/compiler/ciReplay/common.sh Changeset: 9011aa6843ce Author: kevinw Date: 2013-08-19 22:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9011aa6843ce Merge Changeset: e22ee8e7ae62 Author: jiangli Date: 2013-08-19 14:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e22ee8e7ae62 8021948: Change InstanceKlass::_source_file_name and _generic_signature from Symbol* to constant pool indexes. Summary: Change InstanceKlass::_source_file_name and _generic_signature to u2 fields. Reviewed-by: coleenp, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: aeebffb56606 Author: jiangli Date: 2013-08-20 00:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aeebffb56606 Merge Changeset: 9d6c9b0a8f15 Author: dcubed Date: 2013-08-20 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d6c9b0a8f15 8023287: HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3" Summary: Recognize 0x5120 as "Sun Studio 12u3". Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/vm_version.cpp Changeset: afbe18ae0905 Author: bharadwaj Date: 2013-08-15 11:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/afbe18ae0905 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases Summary: Corrected details Reviewed-by: kvn, twisti, rbackman Contributed-by: david.r.chase at oracle.com ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: adb9a7d94cb5 Author: adlertz Date: 2013-08-16 10:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/adb9a7d94cb5 8023003: Cleanup the public interface to PhaseCFG Summary: public methods that don't need to be public should be private. Reviewed-by: kvn, twisti ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6c72125a2f40 Author: iignatyev Date: 2013-08-16 17:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c72125a2f40 8016456: ciReplay test assumes TIERED compilation is available Reviewed-by: vlivanov, kvn, dholmes ! test/compiler/ciReplay/common.sh Changeset: f99558245e5c Author: iignatyev Date: 2013-08-14 23:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f99558245e5c 8022832: Add WB APIs for OSR compilation Reviewed-by: kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: d18b10b1fd09 Author: iignatyev Date: 2013-08-16 13:39 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d18b10b1fd09 Merge Changeset: 4b2838704fd5 Author: kvn Date: 2013-08-16 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b2838704fd5 8021898: Broken JIT compiler optimization for loop unswitching Summary: fix method clone_projs() to clone all related MachProj nodes. Reviewed-by: roland, adlertz ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 6725044c5725 Author: rbackman Date: 2013-08-19 09:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6725044c5725 Merge ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/method.cpp Changeset: e16282db4946 Author: twisti Date: 2013-08-20 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e16282db4946 8022956: Clang: enable return type warnings on BSD Reviewed-by: coleenp, sla ! make/bsd/makefiles/gcc.make ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp Changeset: acedd49a1bce Author: rbackman Date: 2013-08-08 03:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acedd49a1bce 8022675: Redundant class init check Reviewed-by: kvn, twisti ! src/share/vm/opto/library_call.cpp Changeset: 4dece0730c50 Author: rbackman Date: 2013-08-22 18:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4dece0730c50 Merge ! src/share/vm/runtime/vmStructs.cpp ! test/compiler/ciReplay/common.sh Changeset: 5888334c9c24 Author: johnc Date: 2013-08-15 10:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5888334c9c24 7145569: G1: optimize nmethods scanning Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead. Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! 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 ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: 8088d93a63e6 Author: brutisso Date: 2013-08-15 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8088d93a63e6 Merge Changeset: 9720d338b1d5 Author: brutisso Date: 2013-08-16 11:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9720d338b1d5 8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0 Reviewed-by: stefank, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: d0afbee540e0 Author: stefank Date: 2013-08-19 13:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0afbee540e0 8023227: Enhance layout_helper_log2_element_size assert Reviewed-by: mgerdin, jmasa ! src/share/vm/oops/klass.hpp Changeset: 422920730903 Author: ehelin Date: 2013-08-19 18:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/422920730903 8023219: NPG: MetaspaceMemoryPool should report statistics for all of metaspace Reviewed-by: stefank, sjohanss ! src/share/vm/services/memoryPool.cpp Changeset: 57600c4aeabe Author: jmasa Date: 2013-08-19 08:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57600c4aeabe Merge - 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_sparc/vm/solaris_sparc.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 Changeset: 31f220c1f789 Author: jmasa Date: 2013-08-20 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31f220c1f789 Merge Changeset: 61521bd65100 Author: tschatzl Date: 2013-08-21 10:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/61521bd65100 8022784: TaskQueue misses minimal documentation and references for analysis Summary: Add appropriate documentation and references to publication to allow easier analysis of the TaskQueue implementation. Reviewed-by: dholmes, ehelin ! src/share/vm/utilities/taskqueue.hpp Changeset: cb9da55b1990 Author: jmasa Date: 2013-08-14 19:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb9da55b1990 8021809: Partitioning based on eden sampling during allocation not reset correctly Reviewed-by: ysr, hiroshi ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: b51aee2dd8bb Author: jmasa Date: 2013-08-22 11:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b51aee2dd8bb Merge ! src/share/vm/oops/klass.hpp Changeset: 8009adb44523 Author: jmasa Date: 2013-08-22 14:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8009adb44523 Merge Changeset: c1604d5885a6 Author: amurillo Date: 2013-08-23 03:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1604d5885a6 Merge Changeset: acac3bde66b2 Author: amurillo Date: 2013-08-23 03:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acac3bde66b2 Added tag hs25-b47 for changeset c1604d5885a6 ! .hgtags Changeset: b649cfa58604 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b649cfa58604 Added tag jdk8-b105 for changeset acac3bde66b2 ! .hgtags Changeset: 73921c720b94 Author: amurillo Date: 2013-08-23 03:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73921c720b94 8023635: new hotspot build - hs25-b48 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c6ec0a97b30a Author: sla Date: 2013-08-21 13:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c6ec0a97b30a 8022808: Kitchensink hangs on macos Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources Reviewed-by: dholmes, rbackman ! src/os/bsd/vm/os_bsd.cpp Changeset: 3a57fa7a4cd0 Author: hseigel Date: 2013-08-22 11:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a57fa7a4cd0 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh fails on 64bit solaris 8023393: Need to suppress info message if -Xcheck:jni used with libjsig.dylab on Mac OSX Summary: Rewrite 7051189 test in Java, port Linux fix for 7051189 to Mac OSX. Reviewed-by: coleenp, dholmes, mseledtsov, ccheung ! src/os/bsd/vm/os_bsd.cpp - test/runtime/7051189/Xchecksig.sh + test/runtime/XCheckJniJsig/XCheckJSig.java Changeset: e37ab280bbce Author: allwin Date: 2013-07-23 14:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e37ab280bbce 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" Reviewed-by: sla, sundar, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js Changeset: 669d9a235486 Author: sla Date: 2013-08-22 14:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/669d9a235486 Merge Changeset: c062a6e1fa33 Author: iklam Date: 2013-08-22 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c062a6e1fa33 8023406: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1 Summary: Avoid dumping C++ vtable when BUILD_WIN_SA != 1 Reviewed-by: dcubed, sla, tbell ! make/windows/build_vm_def.sh ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make Changeset: 811aea34d5e7 Author: iklam Date: 2013-08-22 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/811aea34d5e7 Merge Changeset: ff2520b97b00 Author: jiangli Date: 2013-08-22 19:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff2520b97b00 8023547: com/sun/jdi/RedefineMulti.sh fails with IllegalArgumentException after JDK-8021948 . Summary: Need to check if the constant pool mapping returns 0. Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 887db75613f8 Author: jiangli Date: 2013-08-22 17:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/887db75613f8 Merge Changeset: a70566600baf Author: poonam Date: 2013-08-21 22:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a70566600baf 8020530: Non heap memory size calculated incorrectly Reviewed-by: coleenp, sla Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/services/management.cpp Changeset: 730210728146 Author: poonam Date: 2013-08-22 18:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/730210728146 Merge - test/runtime/7051189/Xchecksig.sh Changeset: 817e46dd5864 Author: poonam Date: 2013-08-22 21:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/817e46dd5864 Merge Changeset: 739c309fd729 Author: mgronlun Date: 2013-08-23 10:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/739c309fd729 8023457: Event based tracing framework needs a mutex for thread groups Reviewed-by: acorn, sla ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: cacc421f39d7 Author: dcubed Date: 2013-08-23 10:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cacc421f39d7 Merge - test/runtime/7051189/Xchecksig.sh Changeset: badf4244ceae Author: hseigel Date: 2013-08-25 21:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/badf4244ceae 8022183: GCC 4.6 change sdefault setting for omit-frame-pointer which breaks hotspot stack walking Summary: Explicitly specify -fno-omit-frame-pointer. Reviewed-by: coleenp, dholmes, dcubed ! make/linux/makefiles/amd64.make ! make/linux/makefiles/gcc.make Changeset: faf2631b9334 Author: dsimms Date: 2013-08-26 09:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/faf2631b9334 8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM Summary: Return NULL on OOM from GetStringChars, GetStringUTFChars and GetArrayElements family of functions. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/jni.cpp Changeset: 4c84d351cca9 Author: stefank Date: 2013-08-16 13:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c84d351cca9 8007074: SIGSEGV at ParMarkBitMap::verify_clear() Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages. Reviewed-by: tschatzl, dcubed, brutisso ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 21ffbaa691b5 Author: stefank Date: 2013-08-26 07:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/21ffbaa691b5 Merge ! src/share/vm/prims/jni.cpp Changeset: 1bb10d3170fa Author: jmasa Date: 2013-08-16 06:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1bb10d3170fa 8022817: CMS should not shrink if compaction was not done Reviewed-by: ysr, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: f7d3b4387a16 Author: brutisso Date: 2013-08-21 22:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7d3b4387a16 8022872: G1: Use correct GC cause for young GC triggered by humongous allocations Reviewed-by: tonyp, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c31eb8c86a50 Author: brutisso Date: 2013-08-22 04:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c31eb8c86a50 Merge Changeset: ec145d04eda8 Author: jmasa Date: 2013-08-23 15:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec145d04eda8 Merge Changeset: 1624a68007bd Author: jmasa Date: 2013-08-27 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1624a68007bd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: f92b82d454fa Author: bpittore Date: 2013-08-23 20:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f92b82d454fa 8014135: The JVMTI specification does not conform to recent changes in JNI specification Summary: Added support for statically linked agents Reviewed-by: sspitsyn, bobv, coleenp ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5fd8e2fbafd4 Author: cjplummer Date: 2013-08-23 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5fd8e2fbafd4 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported Summary: Make tests query a new WhiteBox API to see if NMT detail is supported, and behave properly if it is not supported. Reviewed-by: dholmes, coleenp ! src/share/vm/prims/whitebox.cpp ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 7aa0c1fb6fdb Author: dholmes Date: 2013-08-27 22:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7aa0c1fb6fdb 8006164: [TESTBUG] compact profile hotspot test issues Summary: Define profile-based test groups. Reviewed-by: dcubed, mchung ! test/TEST.ROOT + test/TEST.groups Changeset: 1fedf3c7f923 Author: bpittore Date: 2013-08-28 14:44 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1fedf3c7f923 8023580: Add jtreg test for 8004051 and 8005722 Summary: Tests checks an assertion dealing with the number of args passed in registers Reviewed-by: mseledtsov, kvn + test/compiler/8004051/Test8004051.java Changeset: b1fb293d92c4 Author: jiangli Date: 2013-08-28 12:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b1fb293d92c4 Merge Changeset: 2b113b65a051 Author: dholmes Date: 2013-08-28 19:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b113b65a051 8023900: [TESTBUG] Initial compact profile test groups need adjusting Reviewed-by: dcubed, mchung, hseigel ! test/TEST.groups Changeset: 54dfd798deaf Author: dholmes Date: 2013-08-28 21:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54dfd798deaf Merge Changeset: 62f527c674d2 Author: dholmes Date: 2013-08-29 00:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62f527c674d2 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 18b4798adbc4 Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18b4798adbc4 Merge - test/runtime/7051189/Xchecksig.sh Changeset: aed585cafc0d Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aed585cafc0d Added tag hs25-b48 for changeset 18b4798adbc4 ! .hgtags Changeset: 3f4392035ec7 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f4392035ec7 Added tag jdk8-b106 for changeset aed585cafc0d ! .hgtags From lana.steuck at oracle.com Sat Sep 7 00:11:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 07 Sep 2013 00:11:27 +0000 Subject: hg: jdk8/tl/jdk: 6 new changesets Message-ID: <20130907001405.323CF62626@hg.openjdk.java.net> Changeset: 0417358184a1 Author: omajid Date: 2013-08-22 16:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0417358184a1 8023480: Create a jvm.cfg for zero on 32 bit architectures Reviewed-by: dholmes, erikj ! makefiles/CopyFiles.gmk Changeset: 1fe211ae3d2b Author: katleman Date: 2013-08-26 17:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fe211ae3d2b Merge Changeset: 1a2a8d143583 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a2a8d143583 Added tag jdk8-b105 for changeset 1fe211ae3d2b ! .hgtags Changeset: c817276bd870 Author: lana Date: 2013-08-29 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c817276bd870 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: aafc0f332658 Author: cl Date: 2013-09-05 02:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aafc0f332658 Added tag jdk8-b106 for changeset c817276bd870 ! .hgtags Changeset: 257de3e3a278 Author: lana Date: 2013-09-06 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/257de3e3a278 Merge From stuart.marks at oracle.com Sat Sep 7 00:31:00 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 06 Sep 2013 17:31:00 -0700 Subject: RFR: 8023447: change specification to allow RMI activation to be optional In-Reply-To: <5229A294.2020103@oracle.com> References: <522909BF.2090000@oracle.com> <5229A294.2020103@oracle.com> Message-ID: <522A73C4.6040307@oracle.com> Hi Olivier, Thanks for looking at this. Part of the minimization effort (see my reply to Alan) showed that ActivationGroupDesc needn't have the throws-UOE specs added to it. This is pretty easy to see by going to the "Use" tab of the ActivationGroupDesc javadoc. ActivationGroupDesc instances are returned and consumed by several instance methods of ActivationSystem; this OK since we prevent the application from ever getting any ActivationSystem instances, by specifying UOE wherever they're returned. ActivationGroupDesc is also consumed by a static method ActivationGroup.createGroup(). That has UOE on it, so we're covered. The intuition behind this makes sense. If you look at ActivationGroupDesc, it's just a "data class" -- it merely contains Strings, MarshalledObjects, and Properties. Well, it has a CommandEnvironment, but that's just a data class too. As such, ActivationGroupDesc is just a bag of data that's used by the other activation classes. (Note also that it doesn't throw any activation exceptions anywhere.) Anyway, there's no harm in allowing apps to create ActivationGroupDesc instances, so we didn't add UOE there. I tried similar analysis on some of the other objects and was unsuccessful at convincing myself they didn't need UOEs added to them, so that's how we ended up with so many cases where throwing UOE is necessary. s'marks On 9/6/13 2:38 AM, Olivier Lagneau wrote: > Hi Stuart, > > I like this, and think this is the right approach for solving the > problem. > > I see however that ActivationGroupDesc is not impacted by the change. > In the case of an implementation that does not support activation, > are we sure there will be no way for a developer to create an instance > of any the other key activation classes > (ActivationGroup, ActivationDesc, ActivationGroupId, ActivationID), > using an "Activatable" object (one that does not subclass > Activatable) and an ActivationGroupDesc instance, through any > "default" behaviour described in the spec ? > > If that has been checked, that looks fine. > > Olivier. > > > Stuart Marks said on date 9/6/2013 12:46 AM: >> Hi all, >> >> Please review this specification-only change to allow RMI activation >> to be optional. RMI activation, unlike the rest of RMI, pretty much >> requires the ability to fork processes at will. This causes >> difficulties in certain situations, such as in small embedded >> configurations. Activation is typically unnecessary in such >> environments, hence it makes sense for it to be optional. >> >> Essentially the change is the addition of a small paragraph to the >> package doc for java.rmi.activation, and adding spec for throwing >> UnsupportedOperationException to a bunch of methods in this package. >> >> >> Bug report: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023447 >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/8023447/webrev.5/ >> >> Specdiff: >> >> http://cr.openjdk.java.net/~smarks/reviews/8023447/specdiff.5/overview-summary.html >> >> >> Thanks, >> >> s'marks > From henry.jen at oracle.com Sat Sep 7 06:18:47 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 06 Sep 2013 23:18:47 -0700 Subject: RFR: 8011916: Spec update for java.util.stream + 8024339: j.u.s.Stream.reduce(BinaryOperator) throws unexpected NPE Message-ID: <522AC547.5000007@oracle.com> Hi, Please kindly review webrev at http://cr.openjdk.java.net/~henryjen/ccc/8011916/0/webrev/ The webrev brings over the latest javadoc overhaul occurred in lambda repo. The specdiff can be found at http://cr.openjdk.java.net/~henryjen/ccc/8011916/0/specdiff/overview-summary.html There is also some minor cleanup for code, variable renaming, add @Override etc. Bug 8024339 is resolved with spec updated to clarify NPE could be thrown if reduce operation got a null as result. Cheers, Henry From staffan.larsen at oracle.com Sat Sep 7 10:50:38 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sat, 7 Sep 2013 12:50:38 +0200 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522A3873.1090309@oracle.com> References: <522A0712.90702@oracle.com> <522A2B1F.7010803@oracle.com> <522A3873.1090309@oracle.com> Message-ID: This is a welcome change. I've looked at the serviceability test and the changes look good except: test/demo/jvmti/DemoRun.java test/sun/tools/jhat/HatRun.java - Looks like there are still some -d64 remnants that I wasn't expecting. Thanks, /Staffan On 6 sep 2013, at 22:17, Kumar Srinivasan wrote: > On 9/6/2013 12:21 PM, Alan Bateman wrote: >> On 06/09/2013 17:47, Kumar Srinivasan wrote: >>> Hello, >>> >>> Please review the changes to remove Solaris 32-bit binaries from JDK8 distros, >>> at this time the dual mode support in the launcher is being disabled. >>> >>> Message regarding this: >>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html >>> >>> The jdk changes are here: >>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ >>> >>> The top forest changes are here: >>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ >> I haven't studied the changes yet but I see you've updated test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh. I don't think you need the changes at L42-48, instead you can just "hg rm" the 32-bit libraries that are in test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib. > > Will do, I was wondering about those libraries. > >> >> You might want to bring the changes to serviceability-dev because of the change to the JDI launching connector and the JDI tests. > > cc'ed. > > Thanks > > Kumar > >> >> -Alan. >> >> > From brian.goetz at oracle.com Sat Sep 7 22:11:11 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 07 Sep 2013 18:11:11 -0400 Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate) In-Reply-To: <522866FF.9060806@cs.oswego.edu> References: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com> <522866FF.9060806@cs.oswego.edu> Message-ID: <522BA47F.2000409@oracle.com> > One of the main consequences of how lambda matching rules > panned out is that it is in general a bad idea to overload any > method accepting a lambda. It is only a bad idea to overload methods that take same-arity lambdas in the same position. removeAll(Collection) vs removeAll(Predicate) are fine (in part because null is an invalid value for both.) > I imagine that most tutorials etc > about designing with lambda will present this as the first > rule of thumb. Dan has some rules about what constitutes valid and invalid overloadings, that have gone through a few rounds of simplification and are finally (especially with the recent overloading simplifications in the spec) that should be pretty easy to internalize. From joe.darcy at oracle.com Sat Sep 7 22:45:50 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 07 Sep 2013 15:45:50 -0700 Subject: @Supported design issues In-Reply-To: <20130905202314.477145@eggemoggin.niobe.net> References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>, <52293F0B.9090804@oracle.com> <20130905202314.477145@eggemoggin.niobe.net> Message-ID: <522BAC9E.9030906@oracle.com> On 9/5/2013 8:23 PM, mark.reinhold at oracle.com wrote: > 2013/9/5 12:33 -0700, joe.darcy at oracle.com: >> IMO, the high order goal here should be getting the "is this API okay to >> use" information encoded into the source code and class files. Given >> that you've already compiled that information, I think there is great >> value in going forward with this effort for JDK 8 even given the >> relatively late point in the schedule. > Agreed. > >> Perhaps instead of "Supported", the adjective "Sanctioned" better >> conveys what is intended: this API is explicitly part of the JDK's >> contract and fine to use. > @Sanctioned begs the same question as @Supported, i.e., by whom? I don't think the answers here are that vexing; in analogy with @Deprecated, the party providing the type is the party providing information about the intended use of that type. > >> I'm open to other suggestions too. > Well, looking ahead to when the platform will be composed of modules, > those modules will declare that they "export" some API elements, but > not others. An @Exported annotation would help get people used to > the expected future terminology. > > Just one idea, I'm sure there are others. > Thanks for the suggestion, -Joe From xuelei.fan at oracle.com Sun Sep 8 00:06:45 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sun, 08 Sep 2013 00:06:45 +0000 Subject: hg: jdk8/tl/jdk: 7188657: There should be a way to reorder the JSSE ciphers Message-ID: <20130908000711.8577962660@hg.openjdk.java.net> Changeset: 0f47f9f622d9 Author: xuelei Date: 2013-09-07 17:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f47f9f622d9 7188657: There should be a way to reorder the JSSE ciphers Reviewed-by: weijun, wetmore ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java + test/sun/security/ssl/javax/net/ssl/SSLParameters/UseCipherSuitesOrder.java From vicente.romero at oracle.com Sun Sep 8 10:55:38 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 08 Sep 2013 10:55:38 +0000 Subject: hg: jdk8/tl/langtools: 8024398: javac, compiler crashes with try with empty body Message-ID: <20130908105552.66ADD62668@hg.openjdk.java.net> Changeset: 2de3750d65a5 Author: vromero Date: 2013-09-08 11:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2de3750d65a5 8024398: javac, compiler crashes with try with empty body Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T8024398/NPETryTest.java From tim.bell at oracle.com Sun Sep 8 18:53:23 2013 From: tim.bell at oracle.com (Tim Bell) Date: Sun, 08 Sep 2013 11:53:23 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: References: <522A0712.90702@oracle.com> <522A2B1F.7010803@oracle.com> <522A3873.1090309@oracle.com> Message-ID: <522CC7A3.3020303@oracle.com> Kumar - the makefile changes look good to me. Tim On 09/ 7/13 03:50 AM, Staffan Larsen wrote: > This is a welcome change. I've looked at the serviceability test and the changes look good except: > > test/demo/jvmti/DemoRun.java > test/sun/tools/jhat/HatRun.java > - Looks like there are still some -d64 remnants that I wasn't expecting. > > Thanks, > /Staffan > > On 6 sep 2013, at 22:17, Kumar Srinivasan wrote: > >> On 9/6/2013 12:21 PM, Alan Bateman wrote: >>> On 06/09/2013 17:47, Kumar Srinivasan wrote: >>>> Hello, >>>> >>>> Please review the changes to remove Solaris 32-bit binaries from JDK8 distros, >>>> at this time the dual mode support in the launcher is being disabled. >>>> >>>> Message regarding this: >>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html >>>> >>>> The jdk changes are here: >>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ >>>> >>>> The top forest changes are here: >>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ >>> I haven't studied the changes yet but I see you've updated test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh. I don't think you need the changes at L42-48, instead you can just "hg rm" the 32-bit libraries that are in test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib. >> Will do, I was wondering about those libraries. >> >>> You might want to bring the changes to serviceability-dev because of the change to the JDI launching connector and the JDI tests. >> cc'ed. >> >> Thanks >> >> Kumar >> >>> -Alan. >>> >>> From david.holmes at oracle.com Mon Sep 9 02:18:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Sep 2013 12:18:08 +1000 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522A0712.90702@oracle.com> References: <522A0712.90702@oracle.com> Message-ID: <522D2FE0.6030105@oracle.com> Hi Kumar, A few minor comments ... src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java Seems to me this is all dead now: 199 /* 200 * A wrinkle in the environment: 201 * 64-bit executables are stored under $JAVA_HOME/bin/os_arch 202 * 32-bit executables are stored under $JAVA_HOME/bin 203 */ 204 String os_arch = System.getProperty("os.arch"); os_arch is no longer used and the comment no longer applicable. --- src/solaris/bin/java_md_solinux.c This seems to force DUAL_MODE off regardless of what the user may set it to: #ifdef __solaris__ ! # ifdef DUAL_MODE ! # undef DUAL_MODE ! # endif why doesn't it just not define DUAL_MODE? --- test/demo/jvmti/DemoRun.java test/sun/tools/jhat/HatRun.java It isn't clear to me why you need to retain the d64 variable at all. --- test/tools/launcher/ExecutionEnvironment.java typo: appopriate Thanks, David ---- On 7/09/2013 2:47 AM, Kumar Srinivasan wrote: > Hello, > > Please review the changes to remove Solaris 32-bit binaries from JDK8 > distros, > at this time the dual mode support in the launcher is being disabled. > > Message regarding this: > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html > > The jdk changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ > > The top forest changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ > > > Thanks > Kumar > > From mandy.chung at oracle.com Mon Sep 9 02:34:04 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 08 Sep 2013 19:34:04 -0700 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <5227D80D.1010207@redhat.com> References: <5227C0F0.5040108@oracle.com> <5227D80D.1010207@redhat.com> Message-ID: <522D339C.9010200@oracle.com> On 9/4/2013 6:02 PM, David M. Lloyd wrote: > > This seems reasonable on the surface but falls over once you capture > the caller for more than one purpose. For example, say a logging > framework captures the caller for the purpose of supplementing log > information. But you call this logging framework from another > framework which uses caller information for another purpose, for > example locating resources. The intent here might be to show > information from the second framework in the log, however with one > universal @CallerSensitive annotation you cannot distinguish which > "capture" you want to grab - the second framework, or the caller who > called the second framework. However by traversing the stack to a > fixed depth, you can do so very definitively (as long as you always > know that your internal code does *not* directly call the sensitive > method - an easy thing to design for in most frameworks). > It would need to detect if the intermediate frames don't call any "sensitive" method. @sun.reflect.CallerSensitive is primarily defined for the security issue and specifically for JEP 176. As you said, the current form of @CS doesn't satisfy other purposes. > In fact you can usually traverse the stack to a fixed depth for this > kind of thing, with one key exception that comes up in log frameworks. > When you have one log API which forwards to another, you want to > capture the "first" caller of any log API. Pursuant to this, most log > frameworks have log method variants which accept the fully-qualified > class name of that first logger. The moral equivalent to this > scenario would likely be to provide an API variant which accepts a > Class or ClassLoader (depending on the usage) and a variant which does > not and uses a fixed-depth "reach" into the stack instead. > This IMO blows a hole in the whole idea of a single *public* @CS > annotation, and in fact in public framework code, a depth indicator > seems to be adequate and more or less problem-free for any purpose > I've run across. I'm not sure if we can be very certainabout the depth in a runtime environment (non-debugging) unless it requires all VM implementation to support a reliable way to return a frame at a given depth. The stack trace is not guaranteed to contain all stack frames. E.g. in the spec of Throwable.getStackTrace(): Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this throwable is permitted to return a zero-length array from this method. Mandy From david.holmes at oracle.com Mon Sep 9 02:39:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Sep 2013 12:39:29 +1000 Subject: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError In-Reply-To: <5229F4B8.9000506@oracle.com> References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com> <5229F4B8.9000506@oracle.com> Message-ID: <522D34E1.8090102@oracle.com> On 7/09/2013 1:28 AM, Alan Bateman wrote: > On 06/09/2013 15:18, David Chase wrote: >> webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ >> >> Question #2, what's the best way to write a jtreg test suite that >> requires incompatible class files, that could not result from a single >> javac compilation? > Can you coerce ASM into creating it? Alternatively it is something that > you can create off-line and include in a class as a byte array (to load > via your own URLClassLoader)? Multiple @compile tags in the main test? David ----- >> >> Question #3, the message(s) attached to the exception are not the same >> in all cases: >> >> a. IllegalAccessError's been caught java.lang.IllegalAccessError: >> member is private: MethodSupplier.m()void/invokeVirtual, from >> MethodInvoker >> >> b. IllegalAccessError's been caught java.lang.IllegalAccessError: >> tried to access method MethodSupplier.m()V from class MethodInvoker >> >> c. IllegalAccessError's been caught java.lang.IllegalAccessError: >> >> d. IllegalAccessError's been caught java.lang.IllegalAccessError: >> tried to access method MethodSupplier.m()V from class MethodInvoker >> >> The difference between a. and c. above (and these are the two that >> change under this fix, the code the execution definitely intersects at >> the fix) is: >> >> a = Class.forName("MethodInvoker").getMethod("invoke").invoke(null); >> c = MethodInvoker.invoke(); >> >> yet one has the message copied from the underlying >> IllegalAccessException (not IAError) and the other does not. > Do you mean you want the messages to be consistent? (I don't think I > quite get the question). > > -Alan > > > From david.holmes at oracle.com Mon Sep 9 02:43:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Sep 2013 12:43:52 +1000 Subject: Please review two corrections for java.time In-Reply-To: <522A17D9.4090103@oracle.com> References: <522A17D9.4090103@oracle.com> Message-ID: <522D35E8.4010206@oracle.com> Hi Roger, On 7/09/2013 3:58 AM, roger riggs wrote: > Please review for two corrections: > > - The java/time/tck/java/time/TCKLocalTime test failed on a slow machine; > the test should be more lenient. The test is not appropriate for > a conformance test > and is moved to java/time/test/java/time/TestLocalTime. As per the bug report the issue is not slow machines per-se but the use of Xcomp when running the test. I don't think the jck should ever be run with Xcomp. It will be interesting to see if the change from 100ms to 500ms cures the problem on all machines. Thanks, David > - The javadoc for the JapaneseEra.MEIJI era should indicate the start > date is 1868-01-01 > to be consistent with java.util.Calendar. Note that java.time does > not permit dates before Meiji 6 > to be created since the calendar is not clearly defined until then. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ > > Thanks, Roger > > From weijun.wang at oracle.com Mon Sep 9 03:07:32 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 09 Sep 2013 03:07:32 +0000 Subject: hg: jdk8/tl/jdk: 8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc* Message-ID: <20130909030758.71F4E62673@hg.openjdk.java.net> Changeset: 6bfabb71ae1e Author: weijun Date: 2013-09-09 11:08 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bfabb71ae1e 8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc* Reviewed-by: xuelei ! test/sun/security/krb5/runNameEquals.sh From kumar.x.srinivasan at oracle.com Mon Sep 9 03:09:57 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sun, 08 Sep 2013 20:09:57 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522D2FE0.6030105@oracle.com> References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com> Message-ID: <522D3C05.2000403@oracle.com> Hi David, Staffan, Alan, I have addressed all the issues pointed and some more I found while jprt testing. The updated webrev for jdk is here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/ and the delta webrev since the last review webrev is here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html Thanks Kumar > Hi Kumar, > > A few minor comments ... > > src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java > > Seems to me this is all dead now: > > 199 /* > 200 * A wrinkle in the environment: > 201 * 64-bit executables are stored under > $JAVA_HOME/bin/os_arch > 202 * 32-bit executables are stored under > $JAVA_HOME/bin > 203 */ > 204 String os_arch = System.getProperty("os.arch"); > > os_arch is no longer used and the comment no longer applicable. > > --- > > src/solaris/bin/java_md_solinux.c > > This seems to force DUAL_MODE off regardless of what the user may set > it to: > > #ifdef __solaris__ > ! # ifdef DUAL_MODE > ! # undef DUAL_MODE > ! # endif > > why doesn't it just not define DUAL_MODE? > > --- > > test/demo/jvmti/DemoRun.java > test/sun/tools/jhat/HatRun.java > > It isn't clear to me why you need to retain the d64 variable at all. > > --- > > test/tools/launcher/ExecutionEnvironment.java > > typo: appopriate > > > Thanks, > David > ---- > > > > On 7/09/2013 2:47 AM, Kumar Srinivasan wrote: >> Hello, >> >> Please review the changes to remove Solaris 32-bit binaries from JDK8 >> distros, >> at this time the dual mode support in the launcher is being disabled. >> >> Message regarding this: >> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html >> >> >> The jdk changes are here: >> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ >> >> The top forest changes are here: >> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ >> >> >> Thanks >> Kumar >> >> From david.holmes at oracle.com Mon Sep 9 03:28:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Sep 2013 13:28:36 +1000 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522D3C05.2000403@oracle.com> References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com> <522D3C05.2000403@oracle.com> Message-ID: <522D4064.70703@oracle.com> Hi Kumar, This is still dead code in src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java String os_arch = System.getProperty("os.arch"); Also: test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so I know this already exist but I thought binaries were disallowed in the open repo? Davud On 9/09/2013 1:09 PM, Kumar Srinivasan wrote: > Hi David, Staffan, Alan, > > I have addressed all the issues pointed and some more I found while jprt > testing. > > The updated webrev for jdk is here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/ > > and the delta webrev since the last review webrev is here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html > > > Thanks > Kumar > > >> Hi Kumar, >> >> A few minor comments ... >> >> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java >> >> Seems to me this is all dead now: >> >> 199 /* >> 200 * A wrinkle in the environment: >> 201 * 64-bit executables are stored under >> $JAVA_HOME/bin/os_arch >> 202 * 32-bit executables are stored under >> $JAVA_HOME/bin >> 203 */ >> 204 String os_arch = System.getProperty("os.arch"); >> >> os_arch is no longer used and the comment no longer applicable. >> >> --- >> >> src/solaris/bin/java_md_solinux.c >> >> This seems to force DUAL_MODE off regardless of what the user may set >> it to: >> >> #ifdef __solaris__ >> ! # ifdef DUAL_MODE >> ! # undef DUAL_MODE >> ! # endif >> >> why doesn't it just not define DUAL_MODE? >> >> --- >> >> test/demo/jvmti/DemoRun.java >> test/sun/tools/jhat/HatRun.java >> >> It isn't clear to me why you need to retain the d64 variable at all. >> >> --- >> >> test/tools/launcher/ExecutionEnvironment.java >> >> typo: appopriate >> >> >> Thanks, >> David >> ---- >> >> >> >> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote: >>> Hello, >>> >>> Please review the changes to remove Solaris 32-bit binaries from JDK8 >>> distros, >>> at this time the dual mode support in the launcher is being disabled. >>> >>> Message regarding this: >>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html >>> >>> >>> The jdk changes are here: >>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ >>> >>> The top forest changes are here: >>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ >>> >>> >>> Thanks >>> Kumar >>> >>> > From peter.levart at gmail.com Mon Sep 9 06:14:47 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 09 Sep 2013 08:14:47 +0200 Subject: Please review two corrections for java.time In-Reply-To: <522A17D9.4090103@oracle.com> References: <522A17D9.4090103@oracle.com> Message-ID: <522D6757.8020100@gmail.com> On 09/06/2013 07:58 PM, roger riggs wrote: > Please review for two corrections: > > - The java/time/tck/java/time/TCKLocalTime test failed on a slow > machine; > the test should be more lenient. The test is not appropriate for > a conformance test > and is moved to java/time/test/java/time/TestLocalTime. > > - The javadoc for the JapaneseEra.MEIJI era should indicate the start > date is 1868-01-01 > to be consistent with java.util.Calendar. Note that java.time does > not permit dates before Meiji 6 > to be created since the calendar is not clearly defined until then. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ > > Thanks, Roger > > Hi Roger, Although very in-probable, the test can fail when 'expected' is sampled before and 'test' is sampled after midnight. I'm guessing the test is trying to prove that LocalTime.now() is equivalent to LocalTime.now(Clock.systemDefaultZone()), right? In that case, what about the following: public void now() { LocalTime before, test, after; do { before = LocalTime.now(Clock.systemDefaultZone()); test = LocalTime.now(); after = LocalTime.now(Clock.systemDefaultZone()); // retry in case the samples were obtained around midnight } while (before.compareTo(after) > 0); assertTrue(before.compareTo(test) <= 0 && test.compareTo(after) <= 0); } Regards, Peter From joel.franck at oracle.com Mon Sep 9 08:00:15 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Mon, 09 Sep 2013 08:00:15 +0000 Subject: hg: jdk8/tl/langtools: 8022260: Rename javac.code.Annotations to javac.code.SymbolMetadata Message-ID: <20130909080019.DF01F62678@hg.openjdk.java.net> Changeset: 6cffcd15a17e Author: jfranck Date: 2013-09-09 09:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6cffcd15a17e 8022260: Rename javac.code.Annotations to javac.code.SymbolMetadata Reviewed-by: jfranck, jjg Contributed-by: Andreas Lundblad - src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java + src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! test/tools/javac/lib/DPrinter.java From Alan.Bateman at oracle.com Mon Sep 9 08:26:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 09 Sep 2013 09:26:28 +0100 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522D4064.70703@oracle.com> References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com> <522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com> Message-ID: <522D8634.9090202@oracle.com> On 09/09/2013 04:28, David Holmes wrote: > : > > Also: > > test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so > > > I know this already exist but I thought binaries were disallowed in > the open repo? Right, we don't want binary files checked in. The test needs to exercise System.inheritedChannel and so requires launching the VM with stdin/stdout/stderr connected to various types of networking sockets (to emulate launching from inetd/xnetd). That's an awkward scenario to setup so the test uses a custom launcher. We originally checked it in because we couldn't assume there would be compilers installed on all machines running the test. There's a bug open (JDK-6930061) to look at alternatives. It's not blocker to Kumar's changes of course. -Alan From magnus.ihse.bursie at oracle.com Mon Sep 9 08:38:30 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 09 Sep 2013 10:38:30 +0200 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522A0712.90702@oracle.com> References: <522A0712.90702@oracle.com> Message-ID: <522D8906.1070006@oracle.com> On 2013-09-06 18:47, Kumar Srinivasan wrote: > Hello, > > Please review the changes to remove Solaris 32-bit binaries from JDK8 > distros, > at this time the dual mode support in the launcher is being disabled. > > Message regarding this: > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html > > > The jdk changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ > > The top forest changes are here: > http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ In Jprt.gmk, the if and else clauses at the test for solaris-64 are identical, so you can remove the whole test and just keep the SRC_J*_IMAGE_DIR assignment. Apart from that, the build system changes looks fine. /Magnus From daniel.fuchs at oracle.com Mon Sep 9 12:23:17 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 09 Sep 2013 12:23:17 +0000 Subject: hg: jdk8/tl/jdk: 8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship; ... Message-ID: <20130909122409.BD02C6267B@hg.openjdk.java.net> Changeset: 4afdf10de648 Author: dfuchs Date: 2013-09-09 13:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4afdf10de648 8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship 8021003: java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java fails intermittently 8019945: test/java/util/logging/LogManagerInstanceTest.java failing intermittently Summary: This fix untangles the class initialization of Logger and LogManager, and also cleans up the relationship between LogManager, LoggerContext, and Logger, which were at the root cause of some intermittent test failures. Reviewed-by: mchung, martin, plevart ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobal.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java ! test/java/util/logging/Logger/getGlobal/policy ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/TestAppletLoggerContext.java From chris.hegarty at oracle.com Mon Sep 9 12:45:17 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 09 Sep 2013 12:45:17 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130909124541.538C16267D@hg.openjdk.java.net> Changeset: 02064634bc88 Author: msheppar Date: 2013-09-06 15:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02064634bc88 8023326: [TESTBUG] java/net/CookieHandler/LocalHostCookie.java misplaced try/finally Summary: amended test to be more robust to set of potential exceptions thrown Reviewed-by: chegar, khazra ! test/java/net/CookieHandler/LocalHostCookie.java Changeset: 4fd7abaf0a5f Author: msheppar Date: 2013-09-09 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fd7abaf0a5f 8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address Summary: amended src/windows/native/java/net/NetworkInterface_winXP.c to "properly" handle Ipv6IfIndex Reviewed-by: chegar, dsamersoff ! src/windows/native/java/net/NetworkInterface_winXP.c + test/java/net/NetworkInterface/UniqueMacAddressesTest.java From roger.riggs at oracle.com Mon Sep 9 12:48:13 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 09 Sep 2013 08:48:13 -0400 Subject: Please review two corrections for java.time In-Reply-To: <522D35E8.4010206@oracle.com> References: <522A17D9.4090103@oracle.com> <522D35E8.4010206@oracle.com> Message-ID: <522DC38D.6000302@oracle.com> Hi David, I found even on my VirturalBox machine it frequently came close to the .1ms target and failed in one case. Raising the time was to reduce/prevent intermittent failures. Are other timing tests also sensitive to the Xcomp, how should tests be written to be insensitive to that JVM option? Are you otherwise ok with the changes? Thanks, Roger On 9/8/2013 10:43 PM, David Holmes wrote: > Hi Roger, > > On 7/09/2013 3:58 AM, roger riggs wrote: >> Please review for two corrections: >> >> - The java/time/tck/java/time/TCKLocalTime test failed on a slow >> machine; >> the test should be more lenient. The test is not appropriate for >> a conformance test >> and is moved to java/time/test/java/time/TestLocalTime. > > As per the bug report the issue is not slow machines per-se but the > use of Xcomp when running the test. I don't think the jck should ever > be run with Xcomp. It will be interesting to see if the change from > 100ms to 500ms cures the problem on all machines. > > Thanks, > David > >> - The javadoc for the JapaneseEra.MEIJI era should indicate the start >> date is 1868-01-01 >> to be consistent with java.util.Calendar. Note that java.time does >> not permit dates before Meiji 6 >> to be created since the calendar is not clearly defined until then. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ >> >> Thanks, Roger >> >> From roger.riggs at oracle.com Mon Sep 9 13:12:21 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 09 Sep 2013 09:12:21 -0400 Subject: Please review two corrections for java.time In-Reply-To: <522D6757.8020100@gmail.com> References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com> Message-ID: <522DC935.4080809@oracle.com> Hi Peter, The possible wrap-around caused by crossing midnight is handled by Math.max so a retry is not needed. Math.abs(test.toNanoOfDay() - expected.toNanoOfDay()) Thanks, Roger On 9/9/2013 2:14 AM, Peter Levart wrote: > On 09/06/2013 07:58 PM, roger riggs wrote: >> Please review for two corrections: >> >> - The java/time/tck/java/time/TCKLocalTime test failed on a slow >> machine; >> the test should be more lenient. The test is not appropriate >> for a conformance test >> and is moved to java/time/test/java/time/TestLocalTime. >> >> - The javadoc for the JapaneseEra.MEIJI era should indicate the start >> date is 1868-01-01 >> to be consistent with java.util.Calendar. Note that java.time does >> not permit dates before Meiji 6 >> to be created since the calendar is not clearly defined until then. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ >> >> Thanks, Roger >> >> > Hi Roger, > > Although very in-probable, the test can fail when 'expected' is > sampled before and 'test' is sampled after midnight. I'm guessing the > test is trying to prove that LocalTime.now() is equivalent to > LocalTime.now(Clock.systemDefaultZone()), right? > > In that case, what about the following: > > public void now() { > LocalTime before, test, after; > do { > before = LocalTime.now(Clock.systemDefaultZone()); > test = LocalTime.now(); > after = LocalTime.now(Clock.systemDefaultZone()); > // retry in case the samples were obtained around midnight > } while (before.compareTo(after) > 0); > > assertTrue(before.compareTo(test) <= 0 && > test.compareTo(after) <= 0); > } > > > Regards, Peter > From paul.sandoz at oracle.com Mon Sep 9 13:35:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Sep 2013 15:35:14 +0200 Subject: RFR 8010293 Re: Potential issue with CHM.toArray In-Reply-To: <5229ED0E.8010100@oracle.com> References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com> <521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu> <3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com> <05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com> <5229ED0E.8010100@oracle.com> Message-ID: On Sep 6, 2013, at 4:56 PM, Alan Bateman wrote: > On 06/09/2013 12:08, Paul Sandoz wrote: >> On Sep 2, 2013, at 3:24 PM, Paul Sandoz wrote: >> >> : >> >>> Here is the fix in the lambda repo which can be applied to tl: >>> >>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b73937e96ae0 >>> http://hg.openjdk.java.net/lambda/lambda/jdk/raw-rev/b73937e96ae0 >>> >> Anyone up for reviewing this? >> > The comments are very educational as the resizing is difficult to completely grok without going through examples on a whiteboard. Anyway, I don't see anything obviously wrong after going through it. The test case is useful although creating the list of threads is quite a mouth full to take in. > Yeah, i left that in a convoluted intermediate state and wanted to use CountedCompleter instead, see below for a revised and preferred version. Paul. import java.util.concurrent.CompletableFuture; import java.util.concurrent.ConcurrentHashMap; import java.util.stream.IntStream; public class toArray { public static void main(String[] args) throws Throwable { // Execute a number of times to increase the probability of // failure if there is an issue for (int i = 0; i < 16; i++) { executeTest(); } } static void executeTest() throws Throwable { final Throwable throwable[] = new Throwable[1]; final ConcurrentHashMap m = new ConcurrentHashMap<>(); // Number of workers equal to the number of processors final int nWorkers = Runtime.getRuntime().availableProcessors(); final int sizePerWorker = 1024; final int maxSize = nWorkers * sizePerWorker; // The foreman keeps checking that the size of the arrays // obtained from the key and value sets is never less than the // previously observed size and is never greater than the maximum size // NOTE: these size constraints are not specific to toArray and are // applicable to any form of traversal of the collection views CompletableFuture foreman = CompletableFuture.runAsync(new Runnable() { private int prevSize = 0; private boolean checkProgress(Object[] a) { int size = a.length; if (size < prevSize) throw new RuntimeException("WRONG WAY"); if (size > maxSize) throw new RuntimeException("OVERSHOOT"); if (size == maxSize) return true; prevSize = size; return false; } @Override public void run() { try { Integer[] empty = new Integer[0]; while (true) { if (checkProgress(m.values().toArray())) return; if (checkProgress(m.keySet().toArray())) return; if (checkProgress(m.values().toArray(empty))) return; if (checkProgress(m.keySet().toArray(empty))) return; } } catch (Throwable t) { throwable[0] = t; } } }); // Create workers // Each worker will put globally unique keys into the map CompletableFuture[] workers = IntStream.range(0, nWorkers). mapToObj(w -> CompletableFuture.runAsync(() -> { for (int i = 0, o = w * sizePerWorker; i < sizePerWorker; i++) m.put(o + i, i); })). toArray(CompletableFuture[]::new); // Wait for workers and then foreman to complete CompletableFuture.allOf(workers).join(); foreman.join(); if (throwable[0] != null) throw throwable[0]; } } From david.r.chase at oracle.com Mon Sep 9 13:54:37 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 9 Sep 2013 09:54:37 -0400 Subject: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError In-Reply-To: <522D34E1.8090102@oracle.com> References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com> <5229F4B8.9000506@oracle.com> <522D34E1.8090102@oracle.com> Message-ID: <49B26C87-6617-465A-A470-7451692A52E4@oracle.com> On 2013-09-08, at 10:39 PM, David Holmes wrote: > On 7/09/2013 1:28 AM, Alan Bateman wrote: >> On 06/09/2013 15:18, David Chase wrote: >>> webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ >>> >>> Question #2, what's the best way to write a jtreg test suite that >>> requires incompatible class files, that could not result from a single >>> javac compilation? >> Can you coerce ASM into creating it? Alternatively it is something that >> you can create off-line and include in a class as a byte array (to load >> via your own URLClassLoader)? > > Multiple @compile tags in the main test? I did it with a hacked classloader instead, see the message with RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError (webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/ ) I figured it could not be "small" if it included multiple files in the test. David From joel.franck at oracle.com Mon Sep 9 14:25:38 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 9 Sep 2013 16:25:38 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <521CA2F0.1020701@gmail.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> <20130812105439.GC6420@jfranck-desktop.jrpg.bea.com> <5208D7A7.9070608@gmail.com> <5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com> <521CA2F0.1020701@gmail.com> Message-ID: <2A6CD10E-FA3B-4BC9-AD22-AAA79C866731@oracle.com> Hi Peter, Thanks for this, please add a "@bug 8011940" tag to your test. IMO you don't need a re-review for that. Otherwise looks good. We still need a Reviewer, Chris, you reviewed a previous version, can you look at this one too? cheers /Joel On 27 aug 2013, at 15:00, Peter Levart wrote: > Hi Joel and others, > > Here's a 3rd revision of this proposed patch: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.03/ > > I used LinkedHashMap for annotations in this one. It means that now even .getAnnotations() are reported in "declaration order": 1st inherited (includes overridden) then declared (that are not overriding). For example, using @Inherited annotations A1, A2, A3: > > @A1("C") > @A2("C") > class C {} > > @A1("D") > @A3("D") > class D extends C {} > > D.class.getAnnotations() now returns: { @A1("D"), @A2("C"), @A3("D") } ... > > The LHM constructor uses the following expression to estimate the initial capacity of the LHM: > > 3326 annotations = new LinkedHashMap<>((Math.max( > 3327 declaredAnnotations.size(), > 3328 Math.min(12, declaredAnnotations.size() + superAnnotations.size()) > 3329 ) * 4 + 2) / 3 > 3330 ); > > > I think this strikes some balance between effectivity and accuracy of estimation. I could pre-scan the superclass annotations and calculate the exact final size of the annotations Map before constructing it though. Tell me if this is worth the effort. > > I also created a test that tests 3 things: > - class annotation inheritance > - order of class annotations reported by .getAnnotations() and .getDeclaredAnnotations() methods (although not specified, the order is now stable and resembles declaration order) > - behaviour of class annotation caching when class is redefined > > > Regards, Peter > > On 08/13/2013 09:52 AM, Joel Borggr?n-Franck wrote: >> Hi, >> >> Comments inline, >> >> On 12 aug 2013, at 14:40, Peter Levart wrote: >>> On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote: >>> - annotation (@interface) declarations can themselves be redefined (for example, defaults changed). Such redefinitions don't affect already initialized annotations. Default values are cached in AnnotationType which is not invalidated as a result of class redefinition. Maybe it should be. And even if AnnotationType was invalidated as a result of class redefinition, the defaults are looked-up when particular annotations are initialized and then combined with parsed values in a single values map inside each annotation instance (proxy), so invalidating AnnotationType would have no effect on those annotations. >>> >>>> 3326 if (annotations == null) { // lazy construction >>>> 3327 annotations = new HashMap<>(); >>>> 3328 } >>>> >>>> I think this should be a LinkedHashMap, so that iteration is predictable >>>> (I know it isn't in the current code). Also the size of the map is known >>>> so you can use a constructor with an explicit initial capacity. >>> Right, AnnotationParser does return LinkedHashMap, so at least decalredAnnotations are in parse-order. I will change the code to use LinkedHashMap for inherited/combined case too. >> Thanks. >> >>> The number of annotations that end-up in inherited/combined Map is not known in advance. I could make a separate pre-scan for superclass annotations that are @Inheritable and don't have the same key as any of declared annotations and then sum this count with declared annotations count, but I don't think this will be very effective. I could allocate a large-enough Map to always fit (the count of superclass annotations + the count of declared annotations), but that could sometimes lead to much over-allocated Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations count + declared annotations count) as the initial capacity for the Map. What do you think which of those 3 alternatives is the best? >> My bad. I was thinking of the case where every inherited annotation was overridden, in that case annotations.size() == declaredAnnotations.size(). That is of course not generally true. I'm fine with handling this as a follow up since the situation is no worse than today and the surrounding code is better. However, >> >> 1) We should really measure this. >> 2) My gut feeling is that the ratio of not overridden inherited annotations to declared annotations is small IE the expected nr of annotations is much closer to declare annotations than to declared + superclass annotations. >> 3) The default initial capacity is 16 and load factor is 0.75. I do think the mean nr of annotations is closer to 3 than to 12. We are probably wasting some space here. >> >> Perhaps use min(default cap, (total annotations/0.75 (+ 1?))) for now as that will make the situation no worse than today and often better? >> >>>> Since this is a fairly significant rewrite I think it might be good to >>>> make sure our tests exercise the new code. Can you run some kind of >>>> coverage report on this? >>> I successfully ran the jdk_lang jtreg tests which contain several tests for annotations. >> I'm a bit worried these tests doesn't cover annotations + class redefine. But I might be persuaded to have more extensive testing as a follow up as well. >> >> cheers >> /Joel > From paul.sandoz at oracle.com Mon Sep 9 14:42:34 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Sep 2013 16:42:34 +0200 Subject: RFR 8010293 Re: Potential issue with CHM.toArray In-Reply-To: References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com> <521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu> <3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com> <05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com> <5229ED0E.8010100@oracle.com> Message-ID: <75DDA99F-04CF-4CDC-8CA7-71636DB48C5B@oracle.com> On Sep 9, 2013, at 3:35 PM, Paul Sandoz wrote: > > On Sep 6, 2013, at 4:56 PM, Alan Bateman wrote: > >> On 06/09/2013 12:08, Paul Sandoz wrote: >>> On Sep 2, 2013, at 3:24 PM, Paul Sandoz wrote: >>> >>> : >>> >>>> Here is the fix in the lambda repo which can be applied to tl: >>>> >>>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b73937e96ae0 >>>> http://hg.openjdk.java.net/lambda/lambda/jdk/raw-rev/b73937e96ae0 >>>> >>> Anyone up for reviewing this? >>> >> The comments are very educational as the resizing is difficult to completely grok without going through examples on a whiteboard. Anyway, I don't see anything obviously wrong after going through it. The test case is useful although creating the list of threads is quite a mouth full to take in. >> > > Yeah, i left that in a convoluted intermediate state and wanted to use CountedCompleter instead, see below for a revised and preferred version. > s/CountedCompleter/CompletableFuture Sigh F/J on the brain... Paul. From mandy.chung at oracle.com Mon Sep 9 14:54:10 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 09 Sep 2013 07:54:10 -0700 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <5226787F.6060307@oracle.com> References: <5226787F.6060307@oracle.com> Message-ID: <522DE112.4090905@oracle.com> Nick, Do you have any information to some of the questions I asked below that can help the API discussion? We need to decide on the permission check and also the hotspot change has to be integrated and the jdk change will need to wait until it shows in a promoted build. Schedule-wise, to make JDK 8, we should finalize the API this week so that you can update the patch soon. Mandy On 9/3/2013 5:02 PM, Mandy Chung wrote: > Nick, > > I skimmed through the changes. Congratulations for your first patch > making changes in both hotspot and jdk code. > > In my mind, the Log4J use case accessing Class instance to obtain > additional information for diagnosability is different than the use > case of obtaining the caller's class / loader to lookup resources. > While the new APIs might be in the same class, I will discuss them > individually and keep us focus one at a time. > > Ralph has pointed out [1] that Log4j also needs the ability to find an > appropriate ClassLoader which is used for logging separation (thank > you Ralph). That will be the caller-sensitivity (i.e. obtain caller's > class/loader) discussion. > > There are a couple of RFEs: > https://bugs.openjdk.java.net/browse/JDK-4942697 > https://bugs.openjdk.java.net/browse/JDK-6349551 > > Performance is critical for Log4j to traverse the stack trace and > obtain Class information. I like your patch to speed up the > generation of StackTraceElement[] (and StackTraceFrame[] - essentially > same code with different type). java.util.logging.LogRecord has > workaround the performance overhead and go to a specific frame > directly and avoid the cost of generating the entire array. > JDK-6349551 requests to lazily instantiate the StackTraceElement > object unless that frame is requested. Does Log4J always walk all > frames and log all information? Do you just log only some max number > of frames rather than the entire stack trace? > > Class getDeclaringClass() method is the key method you need to > enhance the diagnosability. This method opens up a new way to access > a Class instance that untrusted code wouldn't be able in the past. A > permission check is needed as Alan points out early. Performance as > well as logging framework can't access all class loaders are two > factors to be considered when defining the permission check. > > I saw your other comment about permission check (cut-n-paste below). > It seems to me that you don't agree a permission check is needed for > the getDeclaringClass() method (regardless of which class it belongs > to) and if that's the case, no point to continue. > > I want to make it very clear that I have agreed to take this on and > provide a replacement of sun.reflect.Reflection.getCallerClass(int) in > JDK 8 to address the use cases. It will take time for the API and > security discussion and please be prepared for that (also I am working > on other things at the same time). > > The second comment on your patch is that there are lot of duplicated > code in hotspot in order to support two similar but different types > (StackTraceFrame and StackTraceElement). Serialization is the reason > leading you to have a new StackTraceFrame class. Maybe some > refactoring can help but this is the cost of having the VM directly > creating the instance. One other option, as suggested in the previous > thread, is to keep the declaring class in the StackTraceElement as a > transient field. If we add the getDeclaringClass method in the > StackTraceElement class, it would need to specify to be optional that > it only returns the Class instance when it's available. > > There are currently three different ways to get a stack trace: > 1. Throwable.getStackTrace() > 2. Thread.getStackTrace() and Thread.getAllStackTraces() > 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int > maxDepth).getStackTrace() and multiple thread IDs version > (a) local (b) remote > > Since it's a new StackTraceFrame class, you have to provide a new > method replacing #1 and #2. I don't see any need to provide a new API > equivalent to Thread.getAllStackTraces() and java.lang.management. > > The proposal I originally have last week was to keep declaring class > as transient and add a method in StackTraceElement with a permission > check at every call. Tom raises a good question about the cost of > permission check. Would that be a concern to Log4j? Is log4j on > bootclasspath or extension directory? I assume not. So for log4j to > work with security manager installed, it would have torequire the > application to grant certain permissions - can you confirm? For > example it calls sun.reflect.Reflection.getCallerClass method that > will require RuntimePermission("accessClassInPackage.sun.reflect") > permission. Calling Class.getProtectionDomain and > Class.getClassLoader() requires > RuntimePermission("getProtectionDomain") and > RuntimePermission("getClassLoader") respectively. That gives me an > impression that permission check on individual stack frame might be a > non-issue? > > Mandy > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html > > On 9/3/13 5:24 AM, Nick Williams wrote: >> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: >>>> I'm not voicing any objection to any kind of security/permissions >>>> checks in these methods. Before I can pass judgement one way or >>>> another, I'd want to know 1) specifically what type of permissions >>>> check you are looking for, and 2) what you're looking to achieve >>>> with said permissions check. >>> I would say this is TBD and start by asking the question as to >>> whether there are concerns about leaking reference to Class objects >>> that untrusted code wouldn't normally be able to get a reference to. >>> Tom brings up the cost of the permission check and also whether any >>> API should be tied to class loader. There are clearly discussion >>> points here that could potentially influence the API. >> As I have said before, there are MANY ways to get a Class object that >> aren't security checked. It's when you try to USE that class object >> to impersonate it or invoke methods that security checks begin to >> happen. As they should! >> >> Nick > > > > On 9/1/13 1:16 AM, Nick Williams wrote: >> I have completed and am proposing a patch for replacing >> sun.reflect.Reflection#getCallerClass(...) with a public API in Java >> 8. I saw no point in duplicating an issue, even though it's over 10 >> years old, so I'm indicating that this is a patch for 4851444 >> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). >> >> I welcome and solicit support/+1s and a sponsor. Someone about a >> month ago had mentioned that they would be willing to be a sponsor if >> the patch looked good, but I can't remember who it was and I can't >> find the email. I want to say it was someone with RedHat, but my >> memory could be faulty, so please don't hold it against me if I'm wrong. >> >> *Summary of Changes* >> Added the new class java.lang.StackTraceFrame. It's a virtual mirror >> of StackTraceElement, except that it contains a Class >> declaringClass property instead of a String className property. Since >> the list members expressed reluctance to add methods to Thread and >> Throwable, StackTraceFrame also contains several static methods for >> retrieving Classes and StackTraceFrames from the stack. These methods >> are as follows: >> >> Class getCallerClass(): Retrieves the class of the caller of the >> method calling getCallerClass(). This is identical to the new >> Reflection#getCallerClass() added in Java 7u25/8. >> >> Class getCallerClass(int): Retrieves the class of the caller n >> frames down the stack. This is identical to the old >> Reflection#getCallerClass(int) that was deprecated in Java 7u25 and >> removed in Java 8. >> >> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of >> the line of code that called the method calling getCallerClass(). >> This is similar to the new Reflection#getCallerClass() added in Java >> 7u25/8, except that it returns a StackTraceFrame. >> >> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of >> the caller n frames down the stack. This is similar to the old >> Reflection#getCallerClass(int), except that it returns a >> StackTraceFrame. >> >> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to >> Thread#getStackTrace(), except that it returns an array of >> StackTraceFrames. >> >> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally >> equivalent to Throwable#getStackTrace(), except that it returns an >> array of StackTraceFrames. It uses the same save point (backtrace) >> created when the Throwable is created that Throwable#getStackTrace() >> uses when it's first called. It caches the array of StackTraceFrames >> in the Throwable just like the array of StackTraceElements are >> cached, so that multiple calls for the same Throwable are fast. >> >> As a result of this change, sun.reflect.CallerSensitive has been >> moved to java.lang.CallerSensitive. >> >> I spent considerable time reviewing, revising, considering, and >> testing these changes. I included several unit tests that establish >> the proper behavior. I also spent considerable time benchmarking the >> changes. While benchmarking, I noticed some things. First, >> getCallerClass() and getCallerClass(int) are as fast as their >> counterparts in sun.reflect.Reflection, and they easily inline when >> appropriate. Second, getCallerFrame() and getCallerFrame(int) are >> /almost/ as fast as the Class versions, but there is some additional >> overhead for the construction of the StackTraceFrame. This is >> minuscule (1,000,000 invocations consume around 500 ms total on my >> machine). At this point, all of the benchmarking was as expected. >> >> However, I then encountered a surprise. The getCurrentStackTrace() >> and getStackTrace(Throwable) methods executed (again, 1,000,000 >> times) in about 70% of the time that Thread#getStackTrace() and >> Throwable#getStackTrace() did, respectively. Theoretically, they >> should have executed in the same amount of time, not faster. After >> extensive analysis, I discovered (what I considered to be) a serious >> flaw in how the stack trace is filled in within Throwable (which also >> affects how Thread#getStackTrace() works). >> >> Instead of simply iterating over the entire save point and filling in >> the Throwable stack trace in native code (which is what I did when I >> implemented the StackTraceFrame methods), the Java code in Throwable >> first called a native method to figure out how deep the stack was, >> then called another native method once for every frame in the stack >> to retrieve each element individually. This native method that is >> called repeatedly iterates over the entire backtrace once for each >> call, stopping only when it finds the matching element (so it's O(1) >> for the first call, O(2) for the second call, O(3) for the third >> call, and so on). While my StackTraceFrame methods were iterating >> over the backtrace exactly 1 time (O(n)), the Throwable methods were >> iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but >> not as bad as O(n^2)). This problem would not have been extremely >> apparent over small stack traces (the 30% improvement was a stack >> trace of 6 elements), but over a large (200+ elements) stack traces >> the performance difference would be huge and noticeable. Seeing a >> room for improvement, I refactored the code that fills in the stack >> trace for Throwable, improving its performance accordingly to match >> the performance of the StackTraceFrame methods. >> >> I'm very pleased with how this turned out, and both the unit tests >> and my extensive functional testing show that the new class and its >> methods are working great. I just need someone willing to review and >> sponsor my patch! >> >> *The Code Changes* >> I couldn't get WebRev to run without all kinds of errors. So I ran >> `hg diff -g` on every repository in the forest with changes. Here are >> the four patch files for the four repositories that had changes (no >> other repositories had changes): >> >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch >> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch >> >> I believe I have followed all of the procedures as closely as >> possible. I await feedback and hope for some support on this, so that >> we can get a public replacement for this method in Java 8. Let me >> know if you have any questions. >> >> Thanks! >> >> Nick > > From olivier.lagneau at oracle.com Mon Sep 9 15:02:52 2013 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Mon, 09 Sep 2013 17:02:52 +0200 Subject: RFR: 8023447: change specification to allow RMI activation to be optional In-Reply-To: <522A73C4.6040307@oracle.com> References: <522909BF.2090000@oracle.com> <5229A294.2020103@oracle.com> <522A73C4.6040307@oracle.com> Message-ID: <522DE31C.8040803@oracle.com> Stuart, Thanks for clarifying. I agree with minimization effort and your statements below. So the this looks all fine ! Olivier Stuart Marks said on date 9/7/2013 2:31 AM: > Hi Olivier, > > Thanks for looking at this. Part of the minimization effort (see my > reply to Alan) showed that ActivationGroupDesc needn't have the > throws-UOE specs added to it. This is pretty easy to see by going to > the "Use" tab of the ActivationGroupDesc javadoc. ActivationGroupDesc > instances are returned and consumed by several instance methods of > ActivationSystem; this OK since we prevent the application from ever > getting any ActivationSystem instances, by specifying UOE wherever > they're returned. ActivationGroupDesc is also consumed by a static > method ActivationGroup.createGroup(). That has UOE on it, so we're > covered. > > The intuition behind this makes sense. If you look at > ActivationGroupDesc, it's just a "data class" -- it merely contains > Strings, MarshalledObjects, and Properties. Well, it has a > CommandEnvironment, but that's just a data class too. As such, > ActivationGroupDesc is just a bag of data that's used by the other > activation classes. (Note also that it doesn't throw any activation > exceptions anywhere.) > > Anyway, there's no harm in allowing apps to create ActivationGroupDesc > instances, so we didn't add UOE there. I tried similar analysis on > some of the other objects and was unsuccessful at convincing myself > they didn't need UOEs added to them, so that's how we ended up with so > many cases where throwing UOE is necessary. > > s'marks > > On 9/6/13 2:38 AM, Olivier Lagneau wrote: >> Hi Stuart, >> >> I like this, and think this is the right approach for solving the >> problem. >> >> I see however that ActivationGroupDesc is not impacted by the change. >> In the case of an implementation that does not support activation, >> are we sure there will be no way for a developer to create an >> instance of any the other key activation classes >> (ActivationGroup, ActivationDesc, ActivationGroupId, ActivationID), >> using an "Activatable" object (one that does not subclass >> Activatable) and an ActivationGroupDesc instance, through any >> "default" behaviour described in the spec ? >> >> If that has been checked, that looks fine. >> >> Olivier. >> >> >> Stuart Marks said on date 9/6/2013 12:46 AM: >>> Hi all, >>> >>> Please review this specification-only change to allow RMI activation >>> to be optional. RMI activation, unlike the rest of RMI, pretty much >>> requires the ability to fork processes at will. This causes >>> difficulties in certain situations, such as in small embedded >>> configurations. Activation is typically unnecessary in such >>> environments, hence it makes sense for it to be optional. >>> >>> Essentially the change is the addition of a small paragraph to the >>> package doc for java.rmi.activation, and adding spec for throwing >>> UnsupportedOperationException to a bunch of methods in this package. >>> >>> >>> Bug report: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023447 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8023447/webrev.5/ >>> >>> Specdiff: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8023447/specdiff.5/overview-summary.html >>> >>> >>> Thanks, >>> >>> s'marks >> > From kumar.x.srinivasan at oracle.com Mon Sep 9 15:12:58 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 09 Sep 2013 08:12:58 -0700 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522D4064.70703@oracle.com> References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com> <522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com> Message-ID: <522DE57A.1030907@oracle.com> Hi David, > Hi Kumar, > > This is still dead code in > src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java > > String os_arch = System.getProperty("os.arch"); Ah, I will take care of it. Thanks for spotting this. > > Also: > > test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so > > > I know this already exist but I thought binaries were disallowed in > the open repo? Alan, are the nio changes acceptable? Let me know if you need more time to go over all the changes. Kumar > > Davud > > On 9/09/2013 1:09 PM, Kumar Srinivasan wrote: >> Hi David, Staffan, Alan, >> >> I have addressed all the issues pointed and some more I found while jprt >> testing. >> >> The updated webrev for jdk is here: >> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/ >> >> and the delta webrev since the last review webrev is here: >> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html >> >> >> >> Thanks >> Kumar >> >> >>> Hi Kumar, >>> >>> A few minor comments ... >>> >>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java >>> >>> Seems to me this is all dead now: >>> >>> 199 /* >>> 200 * A wrinkle in the environment: >>> 201 * 64-bit executables are stored under >>> $JAVA_HOME/bin/os_arch >>> 202 * 32-bit executables are stored under >>> $JAVA_HOME/bin >>> 203 */ >>> 204 String os_arch = System.getProperty("os.arch"); >>> >>> os_arch is no longer used and the comment no longer applicable. >>> >>> --- >>> >>> src/solaris/bin/java_md_solinux.c >>> >>> This seems to force DUAL_MODE off regardless of what the user may set >>> it to: >>> >>> #ifdef __solaris__ >>> ! # ifdef DUAL_MODE >>> ! # undef DUAL_MODE >>> ! # endif >>> >>> why doesn't it just not define DUAL_MODE? >>> >>> --- >>> >>> test/demo/jvmti/DemoRun.java >>> test/sun/tools/jhat/HatRun.java >>> >>> It isn't clear to me why you need to retain the d64 variable at all. >>> >>> --- >>> >>> test/tools/launcher/ExecutionEnvironment.java >>> >>> typo: appopriate >>> >>> >>> Thanks, >>> David >>> ---- >>> >>> >>> >>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote: >>>> Hello, >>>> >>>> Please review the changes to remove Solaris 32-bit binaries from JDK8 >>>> distros, >>>> at this time the dual mode support in the launcher is being disabled. >>>> >>>> Message regarding this: >>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html >>>> >>>> >>>> >>>> The jdk changes are here: >>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ >>>> >>>> The top forest changes are here: >>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ >>>> >>>> >>>> Thanks >>>> Kumar >>>> >>>> >> From peter.levart at gmail.com Mon Sep 9 15:14:50 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 09 Sep 2013 17:14:50 +0200 Subject: Please review two corrections for java.time In-Reply-To: <522DC935.4080809@oracle.com> References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com> <522DC935.4080809@oracle.com> Message-ID: <522DE5EA.3070805@gmail.com> On 09/09/2013 03:12 PM, roger riggs wrote: > Hi Peter, > > The possible wrap-around caused by crossing midnight is handled by > Math.max > so a retry is not needed. > > Math.abs(test.toNanoOfDay() - expected.toNanoOfDay()) Hi Roger, In case there is a wrap-around, the 'diff' is much more than 500,000,000 ns (about 24*60*60*1,000,000,000 ns - delay), which fails the test. But what do you think about testing before <= test <= after ? It should not be timing dependent, like it is now. Does it test the same thing? Regards, Peter > > Thanks, Roger > > > > > On 9/9/2013 2:14 AM, Peter Levart wrote: >> On 09/06/2013 07:58 PM, roger riggs wrote: >>> Please review for two corrections: >>> >>> - The java/time/tck/java/time/TCKLocalTime test failed on a slow >>> machine; >>> the test should be more lenient. The test is not appropriate >>> for a conformance test >>> and is moved to java/time/test/java/time/TestLocalTime. >>> >>> - The javadoc for the JapaneseEra.MEIJI era should indicate the >>> start date is 1868-01-01 >>> to be consistent with java.util.Calendar. Note that java.time >>> does not permit dates before Meiji 6 >>> to be created since the calendar is not clearly defined until then. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ >>> >>> Thanks, Roger >>> >>> >> Hi Roger, >> >> Although very in-probable, the test can fail when 'expected' is >> sampled before and 'test' is sampled after midnight. I'm guessing the >> test is trying to prove that LocalTime.now() is equivalent to >> LocalTime.now(Clock.systemDefaultZone()), right? >> >> In that case, what about the following: >> >> public void now() { >> LocalTime before, test, after; >> do { >> before = LocalTime.now(Clock.systemDefaultZone()); >> test = LocalTime.now(); >> after = LocalTime.now(Clock.systemDefaultZone()); >> // retry in case the samples were obtained around midnight >> } while (before.compareTo(after) > 0); >> >> assertTrue(before.compareTo(test) <= 0 && >> test.compareTo(after) <= 0); >> } >> >> >> Regards, Peter >> > From Alan.Bateman at oracle.com Mon Sep 9 15:20:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 09 Sep 2013 16:20:13 +0100 Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8 In-Reply-To: <522DE57A.1030907@oracle.com> References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com> <522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com> <522DE57A.1030907@oracle.com> Message-ID: <522DE72D.3040605@oracle.com> On 09/09/2013 16:12, Kumar Srinivasan wrote: > > Alan, are the nio changes acceptable? Let me know if you need more > time to go over all > the changes. > It looks fine (sorry I should have made that clearer). I skimmed over the other tests too (the launcher tests in particular) and don't see any other issues. -Alan. From peter.levart at gmail.com Mon Sep 9 15:22:33 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 09 Sep 2013 17:22:33 +0200 Subject: Please review two corrections for java.time In-Reply-To: <522DE5EA.3070805@gmail.com> References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com> <522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com> Message-ID: <522DE7B9.1030903@gmail.com> On 09/09/2013 05:14 PM, Peter Levart wrote: > > On 09/09/2013 03:12 PM, roger riggs wrote: >> Hi Peter, >> >> The possible wrap-around caused by crossing midnight is handled by >> Math.max >> so a retry is not needed. >> >> Math.abs(test.toNanoOfDay() - expected.toNanoOfDay()) > > Hi Roger, > > In case there is a wrap-around, the 'diff' is much more than > 500,000,000 ns (about 24*60*60*1,000,000,000 ns - delay), which fails > the test. > > But what do you think about testing before <= test <= after ? It > should not be timing dependent, like it is now. Does it test the same > thing? > > Regards, Peter One other possibility (admittedly even less probable) is when LocalTime jumps back (when Daylight Savings Time rules instruct so). Re-trying and making sure before/after samples are in increasing order also catches this situation. Regards, Peter > >> >> Thanks, Roger >> >> >> >> >> On 9/9/2013 2:14 AM, Peter Levart wrote: >>> On 09/06/2013 07:58 PM, roger riggs wrote: >>>> Please review for two corrections: >>>> >>>> - The java/time/tck/java/time/TCKLocalTime test failed on a slow >>>> machine; >>>> the test should be more lenient. The test is not appropriate >>>> for a conformance test >>>> and is moved to java/time/test/java/time/TestLocalTime. >>>> >>>> - The javadoc for the JapaneseEra.MEIJI era should indicate the >>>> start date is 1868-01-01 >>>> to be consistent with java.util.Calendar. Note that java.time >>>> does not permit dates before Meiji 6 >>>> to be created since the calendar is not clearly defined until then. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ >>>> >>>> Thanks, Roger >>>> >>>> >>> Hi Roger, >>> >>> Although very in-probable, the test can fail when 'expected' is >>> sampled before and 'test' is sampled after midnight. I'm guessing >>> the test is trying to prove that LocalTime.now() is equivalent to >>> LocalTime.now(Clock.systemDefaultZone()), right? >>> >>> In that case, what about the following: >>> >>> public void now() { >>> LocalTime before, test, after; >>> do { >>> before = LocalTime.now(Clock.systemDefaultZone()); >>> test = LocalTime.now(); >>> after = LocalTime.now(Clock.systemDefaultZone()); >>> // retry in case the samples were obtained around midnight >>> } while (before.compareTo(after) > 0); >>> >>> assertTrue(before.compareTo(test) <= 0 && >>> test.compareTo(after) <= 0); >>> } >>> >>> >>> Regards, Peter >>> >> > From vicente.romero at oracle.com Mon Sep 9 15:32:43 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 09 Sep 2013 15:32:43 +0000 Subject: hg: jdk8/tl/langtools: 8024154: Fix for 8016177: structural most specific and stuckness breaks 6 langtools tests Message-ID: <20130909153246.7040062685@hg.openjdk.java.net> Changeset: a4b9a8859e58 Author: vromero Date: 2013-09-09 16:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a4b9a8859e58 8024154: Fix for 8016177: structural most specific and stuckness breaks 6 langtools tests Reviewed-by: jjg, jfranck ! test/tools/javac/lambda/MethodReference41.java ! test/tools/javac/lambda/MethodReference41.out ! test/tools/javac/lambda/MethodReference42.java ! test/tools/javac/lambda/MethodReference42.out ! test/tools/javac/lambda/MethodReference43.java ! test/tools/javac/lambda/MethodReference43.out ! test/tools/javac/lambda/MethodReference44.java ! test/tools/javac/lambda/MethodReference44.out ! test/tools/javac/lambda/MethodReference46.java ! test/tools/javac/lambda/MethodReference46.out ! test/tools/javac/lambda/MethodReference48.java ! test/tools/javac/lambda/MethodReference48.out From peter.levart at gmail.com Mon Sep 9 16:57:44 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 09 Sep 2013 18:57:44 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <2A6CD10E-FA3B-4BC9-AD22-AAA79C866731@oracle.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> <20130812105439.GC6420@jfranck-desktop.jrpg.bea.com> <5208D7A7.9070608@gmail.com> <5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com> <521CA2F0.1020701@gmail.com> <2A6CD10E-FA3B-4BC9-AD22-AAA79C866731@oracle.com> Message-ID: <522DFE08.5060604@gmail.com> Hi Joel, Thanks for reviewing. On 09/09/2013 04:25 PM, Joel Borggr?n-Franck wrote: > Hi Peter, > > Thanks for this, please add a "@bug 8011940" tag to your test. IMO you don't need a re-review for that. Otherwise looks good. I'll do that. I just didn't know whether tagging with bug-ID is meant for all tests that arise from fixing a particular bug or just those that test the presence/fixture of the bug. The 8011940 bug is about scalability and the test is not testing scalability (it has been demonstrated by a micro-benchmark, but that is not included in the test). The test is just covering the logic that has been re-factored and has not had any tests before. Regards, Peter > We still need a Reviewer, Chris, you reviewed a previous version, can you look at this one too? > cheers > /Joel > > On 27 aug 2013, at 15:00, Peter Levart wrote: > >> Hi Joel and others, >> >> Here's a 3rd revision of this proposed patch: >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.03/ >> >> I used LinkedHashMap for annotations in this one. It means that now even .getAnnotations() are reported in "declaration order": 1st inherited (includes overridden) then declared (that are not overriding). For example, using @Inherited annotations A1, A2, A3: >> >> @A1("C") >> @A2("C") >> class C {} >> >> @A1("D") >> @A3("D") >> class D extends C {} >> >> D.class.getAnnotations() now returns: { @A1("D"), @A2("C"), @A3("D") } ... >> >> The LHM constructor uses the following expression to estimate the initial capacity of the LHM: >> >> 3326 annotations = new LinkedHashMap<>((Math.max( >> 3327 declaredAnnotations.size(), >> 3328 Math.min(12, declaredAnnotations.size() + superAnnotations.size()) >> 3329 ) * 4 + 2) / 3 >> 3330 ); >> >> >> I think this strikes some balance between effectivity and accuracy of estimation. I could pre-scan the superclass annotations and calculate the exact final size of the annotations Map before constructing it though. Tell me if this is worth the effort. >> >> I also created a test that tests 3 things: >> - class annotation inheritance >> - order of class annotations reported by .getAnnotations() and .getDeclaredAnnotations() methods (although not specified, the order is now stable and resembles declaration order) >> - behaviour of class annotation caching when class is redefined >> >> >> Regards, Peter >> >> On 08/13/2013 09:52 AM, Joel Borggr?n-Franck wrote: >>> Hi, >>> >>> Comments inline, >>> >>> On 12 aug 2013, at 14:40, Peter Levart wrote: >>>> On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote: >>>> - annotation (@interface) declarations can themselves be redefined (for example, defaults changed). Such redefinitions don't affect already initialized annotations. Default values are cached in AnnotationType which is not invalidated as a result of class redefinition. Maybe it should be. And even if AnnotationType was invalidated as a result of class redefinition, the defaults are looked-up when particular annotations are initialized and then combined with parsed values in a single values map inside each annotation instance (proxy), so invalidating AnnotationType would have no effect on those annotations. >>>> >>>>> 3326 if (annotations == null) { // lazy construction >>>>> 3327 annotations = new HashMap<>(); >>>>> 3328 } >>>>> >>>>> I think this should be a LinkedHashMap, so that iteration is predictable >>>>> (I know it isn't in the current code). Also the size of the map is known >>>>> so you can use a constructor with an explicit initial capacity. >>>> Right, AnnotationParser does return LinkedHashMap, so at least decalredAnnotations are in parse-order. I will change the code to use LinkedHashMap for inherited/combined case too. >>> Thanks. >>> >>>> The number of annotations that end-up in inherited/combined Map is not known in advance. I could make a separate pre-scan for superclass annotations that are @Inheritable and don't have the same key as any of declared annotations and then sum this count with declared annotations count, but I don't think this will be very effective. I could allocate a large-enough Map to always fit (the count of superclass annotations + the count of declared annotations), but that could sometimes lead to much over-allocated Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations count + declared annotations count) as the initial capacity for the Map. What do you think which of those 3 alternatives is the best? >>> My bad. I was thinking of the case where every inherited annotation was overridden, in that case annotations.size() == declaredAnnotations.size(). That is of course not generally true. I'm fine with handling this as a follow up since the situation is no worse than today and the surrounding code is better. However, >>> >>> 1) We should really measure this. >>> 2) My gut feeling is that the ratio of not overridden inherited annotations to declared annotations is small IE the expected nr of annotations is much closer to declare annotations than to declared + superclass annotations. >>> 3) The default initial capacity is 16 and load factor is 0.75. I do think the mean nr of annotations is closer to 3 than to 12. We are probably wasting some space here. >>> >>> Perhaps use min(default cap, (total annotations/0.75 (+ 1?))) for now as that will make the situation no worse than today and often better? >>> >>>>> Since this is a fairly significant rewrite I think it might be good to >>>>> make sure our tests exercise the new code. Can you run some kind of >>>>> coverage report on this? >>>> I successfully ran the jdk_lang jtreg tests which contain several tests for annotations. >>> I'm a bit worried these tests doesn't cover annotations + class redefine. But I might be persuaded to have more extensive testing as a follow up as well. >>> >>> cheers >>> /Joel From joel.franck at oracle.com Mon Sep 9 17:00:32 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 9 Sep 2013 19:00:32 +0200 Subject: RFR: 8009411 : getMethods should not inherit static methods from interfaces Message-ID: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com> Hi Pleaser review fix for 8009411 : getMethods should not inherit static methods from interfaces The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). Webrev is based on the clarification to getMethods and friends out for review on this list. Webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.00/ Bug is here: http://bugs.sun.com/view_bug.do?bug_id=8009411 For oracle reviewers, ccc is approved. cheers /Joel From david.lloyd at redhat.com Mon Sep 9 17:01:25 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 09 Sep 2013 12:01:25 -0500 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <522D339C.9010200@oracle.com> References: <5227C0F0.5040108@oracle.com> <5227D80D.1010207@redhat.com> <522D339C.9010200@oracle.com> Message-ID: <522DFEE5.3010102@redhat.com> On 09/08/2013 09:34 PM, Mandy Chung wrote: > > On 9/4/2013 6:02 PM, David M. Lloyd wrote: >> >> This seems reasonable on the surface but falls over once you capture >> the caller for more than one purpose. For example, say a logging >> framework captures the caller for the purpose of supplementing log >> information. But you call this logging framework from another >> framework which uses caller information for another purpose, for >> example locating resources. The intent here might be to show >> information from the second framework in the log, however with one >> universal @CallerSensitive annotation you cannot distinguish which >> "capture" you want to grab - the second framework, or the caller who >> called the second framework. However by traversing the stack to a >> fixed depth, you can do so very definitively (as long as you always >> know that your internal code does *not* directly call the sensitive >> method - an easy thing to design for in most frameworks). >> > > > It would need to detect if the intermediate frames don't call any > "sensitive" method. > > @sun.reflect.CallerSensitive is primarily defined for the security issue > and specifically for JEP 176. As you said, the current form of @CS > doesn't satisfy other purposes. > >> In fact you can usually traverse the stack to a fixed depth for this >> kind of thing, with one key exception that comes up in log frameworks. >> When you have one log API which forwards to another, you want to >> capture the "first" caller of any log API. Pursuant to this, most log >> frameworks have log method variants which accept the fully-qualified >> class name of that first logger. The moral equivalent to this >> scenario would likely be to provide an API variant which accepts a >> Class or ClassLoader (depending on the usage) and a variant which does >> not and uses a fixed-depth "reach" into the stack instead. >> This IMO blows a hole in the whole idea of a single *public* @CS >> annotation, and in fact in public framework code, a depth indicator >> seems to be adequate and more or less problem-free for any purpose >> I've run across. > > > I'm not sure if we can be very certain about the depth in a runtime > environment (non-debugging) unless it requires all VM implementation to > support a reliable way to return a frame at a given depth. > > The stack trace is not guaranteed to contain all stack frames. E.g. in > the spec of Throwable.getStackTrace(): > > Some virtual machines may, under some circumstances, omit one or more > stack frames from the stack trace. In the extreme case, a virtual > machine > that has no stack trace information concerning this throwable is > permitted to return a zero-length array from this method. This is interesting. Presumably this would tie into tail-call optimizations and that sort of thing? How does AccessControlContext deal with this possibility? -- - DML From david.r.chase at oracle.com Mon Sep 9 17:02:17 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 9 Sep 2013 13:02:17 -0400 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <522DE112.4090905@oracle.com> References: <5226787F.6060307@oracle.com> <522DE112.4090905@oracle.com> Message-ID: Take this lightly informed suggestion with a grain of salt, but why not, for purposes of performance and security, change the logging-specific getCallerClass methods so that their "class" references are instead wrapped in some sort of proxy object that only forwards certain operations quickly without a security check? For example, equals, hashcode, and toString are probably not security-sensitive. i.e. class SafeClass { private final Class clazz; public SafeClass(Class clazz) { this.clazz = class; } public String toString() { return clazz.toString(); } public int hashCode() { return clazz.hashCode(); } public boolean equals(Object o) { return clazz.equals(o); } public Class maybeWeLetYouLookAtTheRealClass() { ... a bunch of security checks ... } } If necessary, do the same for classloaders. And them, no security checks needed, as long as the "safe" methods are enough to get the job done. David On 2013-09-09, at 10:54 AM, Mandy Chung wrote: > Nick, > > Do you have any information to some of the questions I asked below that can help the API discussion? > > We need to decide on the permission check and also the hotspot change has to be integrated and the jdk change will need to wait until it shows in a promoted build. Schedule-wise, to make JDK 8, we should finalize the API this week so that you can update the patch soon. > > Mandy > > On 9/3/2013 5:02 PM, Mandy Chung wrote: >> Nick, >> >> I skimmed through the changes. Congratulations for your first patch making changes in both hotspot and jdk code. >> >> In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class / loader to lookup resources. While the new APIs might be in the same class, I will discuss them individually and keep us focus one at a time. >> >> Ralph has pointed out [1] that Log4j also needs the ability to find an appropriate ClassLoader which is used for logging separation (thank you Ralph). That will be the caller-sensitivity (i.e. obtain caller's class/loader) discussion. >> >> There are a couple of RFEs: >> https://bugs.openjdk.java.net/browse/JDK-4942697 >> https://bugs.openjdk.java.net/browse/JDK-6349551 >> >> Performance is critical for Log4j to traverse the stack trace and obtain Class information. I like your patch to speed up the generation of StackTraceElement[] (and StackTraceFrame[] - essentially same code with different type). java.util.logging.LogRecord has workaround the performance overhead and go to a specific frame directly and avoid the cost of generating the entire array. JDK-6349551 requests to lazily instantiate the StackTraceElement object unless that frame is requested. Does Log4J always walk all frames and log all information? Do you just log only some max number of frames rather than the entire stack trace? >> >> Class getDeclaringClass() method is the key method you need to enhance the diagnosability. This method opens up a new way to access a Class instance that untrusted code wouldn't be able in the past. A permission check is needed as Alan points out early. Performance as well as logging framework can't access all class loaders are two factors to be considered when defining the permission check. >> >> I saw your other comment about permission check (cut-n-paste below). It seems to me that you don't agree a permission check is needed for the getDeclaringClass() method (regardless of which class it belongs to) and if that's the case, no point to continue. >> >> I want to make it very clear that I have agreed to take this on and provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases. It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time). >> >> The second comment on your patch is that there are lot of duplicated code in hotspot in order to support two similar but different types (StackTraceFrame and StackTraceElement). Serialization is the reason leading you to have a new StackTraceFrame class. Maybe some refactoring can help but this is the cost of having the VM directly creating the instance. One other option, as suggested in the previous thread, is to keep the declaring class in the StackTraceElement as a transient field. If we add the getDeclaringClass method in the StackTraceElement class, it would need to specify to be optional that it only returns the Class instance when it's available. >> >> There are currently three different ways to get a stack trace: >> 1. Throwable.getStackTrace() >> 2. Thread.getStackTrace() and Thread.getAllStackTraces() >> 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int maxDepth).getStackTrace() and multiple thread IDs version >> (a) local (b) remote >> >> Since it's a new StackTraceFrame class, you have to provide a new method replacing #1 and #2. I don't see any need to provide a new API equivalent to Thread.getAllStackTraces() and java.lang.management. >> >> The proposal I originally have last week was to keep declaring class as transient and add a method in StackTraceElement with a permission check at every call. Tom raises a good question about the cost of permission check. Would that be a concern to Log4j? Is log4j on bootclasspath or extension directory? I assume not. So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm? For example it calls sun.reflect.Reflection.getCallerClass method that will require RuntimePermission("accessClassInPackage.sun.reflect") permission. Calling Class.getProtectionDomain and Class.getClassLoader() requires RuntimePermission("getProtectionDomain") and >> RuntimePermission("getClassLoader") respectively. That gives me an impression that permission check on individual stack frame might be a non-issue? >> >> Mandy >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html >> >> On 9/3/13 5:24 AM, Nick Williams wrote: >>> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: >>>>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. >>>> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API. >>> As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should! >>> >>> Nick >> >> >> >> On 9/1/13 1:16 AM, Nick Williams wrote: >>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). >>> >>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. >>> >>> *Summary of Changes* >>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: >>> >>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. >>> >>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. >>> >>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. >>> >>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. >>> >>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. >>> >>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. >>> >>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. >>> >>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. >>> >>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). >>> >>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. >>> >>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! >>> >>> *The Code Changes* >>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): >>> >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch >>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch >>> >>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. >>> >>> Thanks! >>> >>> Nick >> >> > From peter.levart at gmail.com Mon Sep 9 17:24:16 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 09 Sep 2013 19:24:16 +0200 Subject: RFR: 8009411 : getMethods should not inherit static methods from interfaces In-Reply-To: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com> References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com> Message-ID: <522E0440.2040505@gmail.com> Hi Joel, The fix is ok for getMethods(), but I think the getMethod(String name, Class... parameterTypes) should also be fixed. Currently the following code: public class StaticInterfaceMethodTest { public interface A { static void m() {} } public interface B extends A { } public static void main(String[] args) throws Exception { B.class.getMethod("m"); } } ...succeeds, but should throw NoSuchMethodException, I think. Regards, Peter On 09/09/2013 07:00 PM, Joel Borggr?n-Franck wrote: > Hi > > Pleaser review fix for 8009411 : getMethods should not inherit static methods from interfaces > > The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). Webrev is based on the clarification to getMethods and friends out for review on this list. > > Webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.00/ > Bug is here: http://bugs.sun.com/view_bug.do?bug_id=8009411 > > For oracle reviewers, ccc is approved. > > cheers > /Joel From joel.franck at oracle.com Mon Sep 9 17:27:10 2013 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 9 Sep 2013 19:27:10 +0200 Subject: RFR: 8009411 : getMethods should not inherit static methods from interfaces In-Reply-To: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com> References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com> Message-ID: On 9 sep 2013, at 19:00, Joel Borggr?n-Franck wrote: > The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). Correcting myself, I added a note to getMethods() and getMethod(String name ?) getDeclaredMethod{s} shouldn't need a note. cheers /Joel From joel.franck at oracle.com Mon Sep 9 17:36:21 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 9 Sep 2013 19:36:21 +0200 Subject: RFR: 8009411 : getMethods should not inherit static methods from interfaces In-Reply-To: <522E0440.2040505@gmail.com> References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com> <522E0440.2040505@gmail.com> Message-ID: Hi Peter, You are correct, thanks for noticing this. Also after reading your mail I looked through the test in test/java/lang/refledt/DefaultStaticTest/ and just realized the tests doesn't cover getMethod() at all. So this change needs more tests as well. I'll post a new webrev later this week. cheers /Joel On 9 sep 2013, at 19:24, Peter Levart wrote: > Hi Joel, > > The fix is ok for getMethods(), but I think the getMethod(String name, Class... parameterTypes) should also be fixed. Currently the following code: > > public class StaticInterfaceMethodTest { > public interface A { > static void m() {} > } > > public interface B extends A { > } > > public static void main(String[] args) throws Exception { > B.class.getMethod("m"); > } > } > > > ...succeeds, but should throw NoSuchMethodException, I think. > > > Regards, Peter > > On 09/09/2013 07:00 PM, Joel Borggr?n-Franck wrote: >> Hi >> >> Pleaser review fix for 8009411 : getMethods should not inherit static methods from interfaces >> >> The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). Webrev is based on the clarification to getMethods and friends out for review on this list. >> >> Webrev: >> http://cr.openjdk.java.net/~jfranck/8009411/webrev.00/ >> >> Bug is here: >> http://bugs.sun.com/view_bug.do?bug_id=8009411 >> >> >> For oracle reviewers, ccc is approved. >> >> cheers >> /Joel >> > From jason.uh at oracle.com Mon Sep 9 17:53:39 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Mon, 09 Sep 2013 17:53:39 +0000 Subject: hg: jdk8/tl/jdk: 8024432: Fix doclint issues in java.security Message-ID: <20130909175352.2A1E76268B@hg.openjdk.java.net> Changeset: be0bcd6a904e Author: juh Date: 2013-09-09 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be0bcd6a904e 8024432: Fix doclint issues in java.security Reviewed-by: darcy, mullan ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/AlgorithmParametersSpi.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyFactorySpi.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Principal.java ! src/share/classes/java/security/cert/CertPathBuilderSpi.java ! src/share/classes/java/security/cert/CertPathValidatorSpi.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java ! src/share/classes/java/security/interfaces/RSAPrivateCrtKey.java ! src/share/classes/java/security/interfaces/RSAPrivateKey.java ! src/share/classes/java/security/interfaces/RSAPublicKey.java From peter.levart at gmail.com Mon Sep 9 17:57:11 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 09 Sep 2013 19:57:11 +0200 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: References: <5226787F.6060307@oracle.com> <522DE112.4090905@oracle.com> Message-ID: <522E0BF7.7060403@gmail.com> On 09/09/2013 07:02 PM, David Chase wrote: > Take this lightly informed suggestion with a grain of salt, but why not, for purposes of performance and security, > change the logging-specific getCallerClass methods so that their "class" references are instead wrapped in some sort of proxy object that only forwards certain operations quickly without a security check? For example, equals, hashcode, and toString are probably not security-sensitive. > > i.e. > class SafeClass { > private final Class clazz; > public SafeClass(Class clazz) { this.clazz = class; } > public String toString() { return clazz.toString(); } > public int hashCode() { return clazz.hashCode(); } > public boolean equals(Object o) { return clazz.equals(o); } > public Class maybeWeLetYouLookAtTheRealClass() { ... a bunch of security checks ... } > } > > If necessary, do the same for classloaders. > And them, no security checks needed, as long as the "safe" methods are enough to get the job done. Hi, This is a good idea. It got me thinking that there are a bunch of methods in j.l.Class that are not security-sensitive. So instead of proxy-ing those in a wrapper SafeClass, let's just identify "unsafe" methods 1st. If the security checks that are planned for obtaining j.l.Class instances from call-stack are transferred to those unsafe methods instead, then holding a reference to a j.l.Class instance becomes a security-nonissue. Just a quick example - presumably the "unsafe" methods of j.l.Class are: get(Declared)Method(s), get(Declared)Field(s) and get(Declared)Constructor(s), because they enable you to call/access public methods/fields/constructors of a class represented by j.l.Class object. If this class is from a restricted package (say sun.misc) then you could get access to restricted methods/fields/instances. Now if the security checks for obtaining reflective object would include checking the "class visibility/restrictability", then j.l.Class object of say sun.misc.Unsafe class would not represent any security issue. It's just about delaying the security check. What do you think? Are there any other security-sensitive j.l.Class methods? Are there any public methods in JDK that take j.l.Class instances and delegate to internal logic assuming that the caller can only pass-in security-pre-checked j.l.Class instances? Regards, Peter > David > > On 2013-09-09, at 10:54 AM, Mandy Chung wrote: > >> Nick, >> >> Do you have any information to some of the questions I asked below that can help the API discussion? >> >> We need to decide on the permission check and also the hotspot change has to be integrated and the jdk change will need to wait until it shows in a promoted build. Schedule-wise, to make JDK 8, we should finalize the API this week so that you can update the patch soon. >> >> Mandy >> >> On 9/3/2013 5:02 PM, Mandy Chung wrote: >>> Nick, >>> >>> I skimmed through the changes. Congratulations for your first patch making changes in both hotspot and jdk code. >>> >>> In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class / loader to lookup resources. While the new APIs might be in the same class, I will discuss them individually and keep us focus one at a time. >>> >>> Ralph has pointed out [1] that Log4j also needs the ability to find an appropriate ClassLoader which is used for logging separation (thank you Ralph). That will be the caller-sensitivity (i.e. obtain caller's class/loader) discussion. >>> >>> There are a couple of RFEs: >>> https://bugs.openjdk.java.net/browse/JDK-4942697 >>> https://bugs.openjdk.java.net/browse/JDK-6349551 >>> >>> Performance is critical for Log4j to traverse the stack trace and obtain Class information. I like your patch to speed up the generation of StackTraceElement[] (and StackTraceFrame[] - essentially same code with different type). java.util.logging.LogRecord has workaround the performance overhead and go to a specific frame directly and avoid the cost of generating the entire array. JDK-6349551 requests to lazily instantiate the StackTraceElement object unless that frame is requested. Does Log4J always walk all frames and log all information? Do you just log only some max number of frames rather than the entire stack trace? >>> >>> Class getDeclaringClass() method is the key method you need to enhance the diagnosability. This method opens up a new way to access a Class instance that untrusted code wouldn't be able in the past. A permission check is needed as Alan points out early. Performance as well as logging framework can't access all class loaders are two factors to be considered when defining the permission check. >>> >>> I saw your other comment about permission check (cut-n-paste below). It seems to me that you don't agree a permission check is needed for the getDeclaringClass() method (regardless of which class it belongs to) and if that's the case, no point to continue. >>> >>> I want to make it very clear that I have agreed to take this on and provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases. It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time). >>> >>> The second comment on your patch is that there are lot of duplicated code in hotspot in order to support two similar but different types (StackTraceFrame and StackTraceElement). Serialization is the reason leading you to have a new StackTraceFrame class. Maybe some refactoring can help but this is the cost of having the VM directly creating the instance. One other option, as suggested in the previous thread, is to keep the declaring class in the StackTraceElement as a transient field. If we add the getDeclaringClass method in the StackTraceElement class, it would need to specify to be optional that it only returns the Class instance when it's available. >>> >>> There are currently three different ways to get a stack trace: >>> 1. Throwable.getStackTrace() >>> 2. Thread.getStackTrace() and Thread.getAllStackTraces() >>> 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int maxDepth).getStackTrace() and multiple thread IDs version >>> (a) local (b) remote >>> >>> Since it's a new StackTraceFrame class, you have to provide a new method replacing #1 and #2. I don't see any need to provide a new API equivalent to Thread.getAllStackTraces() and java.lang.management. >>> >>> The proposal I originally have last week was to keep declaring class as transient and add a method in StackTraceElement with a permission check at every call. Tom raises a good question about the cost of permission check. Would that be a concern to Log4j? Is log4j on bootclasspath or extension directory? I assume not. So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm? For example it calls sun.reflect.Reflection.getCallerClass method that will require RuntimePermission("accessClassInPackage.sun.reflect") permission. Calling Class.getProtectionDomain and Class.getClassLoader() requires RuntimePermission("getProtectionDomain") and >>> RuntimePermission("getClassLoader") respectively. That gives me an impression that permission check on individual stack frame might be a non-issue? >>> >>> Mandy >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html >>> >>> On 9/3/13 5:24 AM, Nick Williams wrote: >>>> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: >>>>>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. >>>>> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API. >>>> As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should! >>>> >>>> Nick >>> On 9/1/13 1:16 AM, Nick Williams wrote: >>>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). >>>> >>>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. >>>> >>>> *Summary of Changes* >>>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: >>>> >>>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. >>>> >>>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. >>>> >>>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. >>>> >>>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. >>>> >>>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. >>>> >>>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. >>>> >>>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. >>>> >>>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. >>>> >>>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). >>>> >>>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. >>>> >>>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! >>>> >>>> *The Code Changes* >>>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): >>>> >>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch >>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch >>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch >>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch >>>> >>>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. >>>> >>>> Thanks! >>>> >>>> Nick From sundararajan.athijegannathan at oracle.com Mon Sep 9 18:07:34 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 09 Sep 2013 18:07:34 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130909180738.014156268C@hg.openjdk.java.net> Changeset: 7ae169639485 Author: sundar Date: 2013-09-05 21:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7ae169639485 8024255: When a keyword is used as object property name, the property can not be deleted Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8024255.js Changeset: c3b6ce7b74bf Author: sundar Date: 2013-09-09 20:10 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c3b6ce7b74bf 8024180: Incorrect handling of expression and parent scope in 'with' statements Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/8024180/global_var_delete.js + test/script/basic/8024180/global_var_delete.js.EXPECTED + test/script/basic/8024180/global_var_shadow.js + test/script/basic/8024180/global_var_shadow.js.EXPECTED + test/script/basic/8024180/scope_no_such_prop.js + test/script/basic/8024180/scope_no_such_prop.js.EXPECTED + test/script/basic/8024180/with_expr_prop_add.js + test/script/basic/8024180/with_expr_prop_add.js.EXPECTED + test/script/basic/8024180/with_expr_proto_prop_add.js + test/script/basic/8024180/with_expr_proto_prop_add.js.EXPECTED + test/script/basic/8024180/with_java_object.js + test/script/basic/8024180/with_java_object.js.EXPECTED ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: 1eca380a221f Author: sundar Date: 2013-09-09 20:16 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1eca380a221f Merge From peter.levart at gmail.com Mon Sep 9 18:10:32 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 09 Sep 2013 20:10:32 +0200 Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8 In-Reply-To: <522E0BF7.7060403@gmail.com> References: <5226787F.6060307@oracle.com> <522DE112.4090905@oracle.com> <522E0BF7.7060403@gmail.com> Message-ID: <522E0F18.3050404@gmail.com> After some thought the below idea seems not good. Currently j.l.Class objects can be used to "transfer" privilige from code that can obtain them to code that can't (like MHs for example). So doing what I proposed would disable this ability. Regards, Peter > > Hi, > > This is a good idea. It got me thinking that there are a bunch of > methods in j.l.Class that are not security-sensitive. So instead of > proxy-ing those in a wrapper SafeClass, let's just identify "unsafe" > methods 1st. If the security checks that are planned for obtaining > j.l.Class instances from call-stack are transferred to those unsafe > methods instead, then holding a reference to a j.l.Class instance > becomes a security-nonissue. > > Just a quick example - presumably the "unsafe" methods of j.l.Class > are: get(Declared)Method(s), get(Declared)Field(s) and > get(Declared)Constructor(s), because they enable you to call/access > public methods/fields/constructors of a class represented by j.l.Class > object. If this class is from a restricted package (say sun.misc) then > you could get access to restricted methods/fields/instances. Now if > the security checks for obtaining reflective object would include > checking the "class visibility/restrictability", then j.l.Class object > of say sun.misc.Unsafe class would not represent any security issue. > It's just about delaying the security check. What do you think? Are > there any other security-sensitive j.l.Class methods? Are there any > public methods in JDK that take j.l.Class instances and delegate to > internal logic assuming that the caller can only pass-in > security-pre-checked j.l.Class instances? > > Regards, Peter > >> David >> >> On 2013-09-09, at 10:54 AM, Mandy Chung wrote: >> >>> Nick, >>> >>> Do you have any information to some of the questions I asked below that can help the API discussion? >>> >>> We need to decide on the permission check and also the hotspot change has to be integrated and the jdk change will need to wait until it shows in a promoted build. Schedule-wise, to make JDK 8, we should finalize the API this week so that you can update the patch soon. >>> >>> Mandy >>> >>> On 9/3/2013 5:02 PM, Mandy Chung wrote: >>>> Nick, >>>> >>>> I skimmed through the changes. Congratulations for your first patch making changes in both hotspot and jdk code. >>>> >>>> In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class / loader to lookup resources. While the new APIs might be in the same class, I will discuss them individually and keep us focus one at a time. >>>> >>>> Ralph has pointed out [1] that Log4j also needs the ability to find an appropriate ClassLoader which is used for logging separation (thank you Ralph). That will be the caller-sensitivity (i.e. obtain caller's class/loader) discussion. >>>> >>>> There are a couple of RFEs: >>>> https://bugs.openjdk.java.net/browse/JDK-4942697 >>>> https://bugs.openjdk.java.net/browse/JDK-6349551 >>>> >>>> Performance is critical for Log4j to traverse the stack trace and obtain Class information. I like your patch to speed up the generation of StackTraceElement[] (and StackTraceFrame[] - essentially same code with different type). java.util.logging.LogRecord has workaround the performance overhead and go to a specific frame directly and avoid the cost of generating the entire array. JDK-6349551 requests to lazily instantiate the StackTraceElement object unless that frame is requested. Does Log4J always walk all frames and log all information? Do you just log only some max number of frames rather than the entire stack trace? >>>> >>>> Class getDeclaringClass() method is the key method you need to enhance the diagnosability. This method opens up a new way to access a Class instance that untrusted code wouldn't be able in the past. A permission check is needed as Alan points out early. Performance as well as logging framework can't access all class loaders are two factors to be considered when defining the permission check. >>>> >>>> I saw your other comment about permission check (cut-n-paste below). It seems to me that you don't agree a permission check is needed for the getDeclaringClass() method (regardless of which class it belongs to) and if that's the case, no point to continue. >>>> >>>> I want to make it very clear that I have agreed to take this on and provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases. It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time). >>>> >>>> The second comment on your patch is that there are lot of duplicated code in hotspot in order to support two similar but different types (StackTraceFrame and StackTraceElement). Serialization is the reason leading you to have a new StackTraceFrame class. Maybe some refactoring can help but this is the cost of having the VM directly creating the instance. One other option, as suggested in the previous thread, is to keep the declaring class in the StackTraceElement as a transient field. If we add the getDeclaringClass method in the StackTraceElement class, it would need to specify to be optional that it only returns the Class instance when it's available. >>>> >>>> There are currently three different ways to get a stack trace: >>>> 1. Throwable.getStackTrace() >>>> 2. Thread.getStackTrace() and Thread.getAllStackTraces() >>>> 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int maxDepth).getStackTrace() and multiple thread IDs version >>>> (a) local (b) remote >>>> >>>> Since it's a new StackTraceFrame class, you have to provide a new method replacing #1 and #2. I don't see any need to provide a new API equivalent to Thread.getAllStackTraces() and java.lang.management. >>>> >>>> The proposal I originally have last week was to keep declaring class as transient and add a method in StackTraceElement with a permission check at every call. Tom raises a good question about the cost of permission check. Would that be a concern to Log4j? Is log4j on bootclasspath or extension directory? I assume not. So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm? For example it calls sun.reflect.Reflection.getCallerClass method that will require RuntimePermission("accessClassInPackage.sun.reflect") permission. Calling Class.getProtectionDomain and Class.getClassLoader() requires RuntimePermission("getProtectionDomain") and >>>> RuntimePermission("getClassLoader") respectively. That gives me an impression that permission check on individual stack frame might be a non-issue? >>>> >>>> Mandy >>>> [1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html >>>> >>>> On 9/3/13 5:24 AM, Nick Williams wrote: >>>>> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: >>>>>>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check. >>>>>> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API. >>>>> As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should! >>>>> >>>>> Nick >>>> On 9/1/13 1:16 AM, Nick Williams wrote: >>>>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). >>>>> >>>>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong. >>>>> >>>>> *Summary of Changes* >>>>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows: >>>>> >>>>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8. >>>>> >>>>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8. >>>>> >>>>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame. >>>>> >>>>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame. >>>>> >>>>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames. >>>>> >>>>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast. >>>>> >>>>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive. >>>>> >>>>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected. >>>>> >>>>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works). >>>>> >>>>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) >>>>> stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods. >>>>> >>>>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch! >>>>> >>>>> *The Code Changes* >>>>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes): >>>>> >>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch >>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch >>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch >>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch >>>>> >>>>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions. >>>>> >>>>> Thanks! >>>>> >>>>> Nick > From roger.riggs at oracle.com Mon Sep 9 19:42:59 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 09 Sep 2013 15:42:59 -0400 Subject: Please review two corrections for java.time In-Reply-To: <522DE5EA.3070805@gmail.com> References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com> <522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com> Message-ID: <522E24C3.8040607@oracle.com> Hi Peter, Right, max doesn't solve the issue but I'm not keen on a test that retries until it gets a better answer. Adding nanosPerDay if the difference comes out negative would adjust for the crossing of midnight and not require looping on a more complex test condition. The longish delay in the now() method is due to first-time initialization that reads the timezone data file. Introducing the loop it would change the test condition so that it is not testing the 'cold' startup. However, the purpose of the test in not to measure the initialization overhead so adding an extra sampling of now(Clock) before the test will remove the first time initialization. Updated webrev at: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ Thanks, Roger On 9/9/2013 11:14 AM, Peter Levart wrote: > > On 09/09/2013 03:12 PM, roger riggs wrote: >> Hi Peter, >> >> The possible wrap-around caused by crossing midnight is handled by >> Math.max >> so a retry is not needed. >> >> Math.abs(test.toNanoOfDay() - expected.toNanoOfDay()) > > Hi Roger, > > In case there is a wrap-around, the 'diff' is much more than > 500,000,000 ns (about 24*60*60*1,000,000,000 ns - delay), which fails > the test. > > But what do you think about testing before <= test <= after ? It > should not be timing dependent, like it is now. Does it test the same > thing? > > Regards, Peter > >> >> Thanks, Roger >> >> >> >> >> On 9/9/2013 2:14 AM, Peter Levart wrote: >>> On 09/06/2013 07:58 PM, roger riggs wrote: >>>> Please review for two corrections: >>>> >>>> - The java/time/tck/java/time/TCKLocalTime test failed on a slow >>>> machine; >>>> the test should be more lenient. The test is not appropriate >>>> for a conformance test >>>> and is moved to java/time/test/java/time/TestLocalTime. >>>> >>>> - The javadoc for the JapaneseEra.MEIJI era should indicate the >>>> start date is 1868-01-01 >>>> to be consistent with java.util.Calendar. Note that java.time >>>> does not permit dates before Meiji 6 >>>> to be created since the calendar is not clearly defined until then. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ >>>> >>>> Thanks, Roger >>>> >>>> >>> Hi Roger, >>> >>> Although very in-probable, the test can fail when 'expected' is >>> sampled before and 'test' is sampled after midnight. I'm guessing >>> the test is trying to prove that LocalTime.now() is equivalent to >>> LocalTime.now(Clock.systemDefaultZone()), right? >>> >>> In that case, what about the following: >>> >>> public void now() { >>> LocalTime before, test, after; >>> do { >>> before = LocalTime.now(Clock.systemDefaultZone()); >>> test = LocalTime.now(); >>> after = LocalTime.now(Clock.systemDefaultZone()); >>> // retry in case the samples were obtained around midnight >>> } while (before.compareTo(after) > 0); >>> >>> assertTrue(before.compareTo(test) <= 0 && >>> test.compareTo(after) <= 0); >>> } >>> >>> >>> Regards, Peter >>> >> > From eric.mccorkle at oracle.com Mon Sep 9 20:28:22 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Mon, 09 Sep 2013 20:28:22 +0000 Subject: hg: jdk8/tl/langtools: 8022322: Reject default and static methods in annotation Message-ID: <20130909202825.ACA2762691@hg.openjdk.java.net> Changeset: f4efd6ef6e80 Author: emc Date: 2013-09-09 16:26 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4efd6ef6e80 8022322: Reject default and static methods in annotation Summary: Causes javac to reject static and default method declarations inside an annotation Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/neg/NoDefault.java + test/tools/javac/annotations/neg/NoDefault.out + test/tools/javac/annotations/neg/NoDefaultAbstract.java + test/tools/javac/annotations/neg/NoDefaultAbstract.out + test/tools/javac/annotations/neg/NoStatic.java + test/tools/javac/annotations/neg/NoStatic.out + test/tools/javac/annotations/neg/NoStaticAbstract.java + test/tools/javac/annotations/neg/NoStaticAbstract.out From forax at univ-mlv.fr Mon Sep 9 20:46:24 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 09 Sep 2013 22:46:24 +0200 Subject: RFR: 8009411 : getMethods should not inherit static methods from interfaces In-Reply-To: References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com> Message-ID: <522E33A0.9050206@univ-mlv.fr> On 09/09/2013 07:27 PM, Joel Borggr?n-Franck wrote: > On 9 sep 2013, at 19:00, Joel Borggr?n-Franck wrote: > >> The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). > Correcting myself, I added a note to getMethods() and getMethod(String name ?) > > getDeclaredMethod{s} shouldn't need a note. > > cheers > /Joel also Joel you can use for-each and avoid to load ma[i] twice (even if the JIT will certainly avoid the double load in this specific case). void addAllNonStatic(Method[] methodArray) { for (Method method:methodArray) { if (!Modifier.isStatic(method.getModifiers())) { add(method); } } } cheers, R?mi From mike.duigou at oracle.com Mon Sep 9 21:10:15 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 9 Sep 2013 14:10:15 -0700 Subject: RFR: 8011916: Spec update for java.util.stream + 8024339: j.u.s.Stream.reduce(BinaryOperator) throws unexpected NPE In-Reply-To: <522AC547.5000007@oracle.com> References: <522AC547.5000007@oracle.com> Message-ID: Looks like good changes all around. I didn't see any "breaking" changes. Some of the javadoc examples (
 blocks) are wrapped at 80 columns. I have been allowing them to go wider (110 columns roughly) so that they don't end up being very narrow in the HTML output. 

Mike

On Sep 6 2013, at 23:18 , Henry Jen wrote:

> Hi,
> 
> Please kindly review webrev at
> http://cr.openjdk.java.net/~henryjen/ccc/8011916/0/webrev/
> 
> The webrev brings over the latest javadoc overhaul occurred in lambda
> repo. The specdiff can be found at
> 
> http://cr.openjdk.java.net/~henryjen/ccc/8011916/0/specdiff/overview-summary.html
> 
> There is also some minor cleanup for code, variable renaming, add
> @Override etc.
> 
> Bug 8024339 is resolved with spec updated to clarify NPE could be thrown
> if reduce operation got a null as result.
> 
> Cheers,
> Henry
> 



From eric.mccorkle at oracle.com  Mon Sep  9 21:12:18 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Mon, 09 Sep 2013 21:12:18 +0000
Subject: hg: jdk8/tl/langtools: 8015322: Javac template test framework
Message-ID: <20130909211221.965C962696@hg.openjdk.java.net>

Changeset: 67c5110c60fe
Author:    emc
Date:      2013-09-09 17:11 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67c5110c60fe

8015322: Javac template test framework
Summary: Putback of the javac template test framework from the Lambda repository
Reviewed-by: jjg
Contributed-by: brian.goetz at oracle.com

! README
+ test/lib/combo/TEST.properties
+ test/lib/combo/tools/javac/combo/Diagnostics.java
+ test/lib/combo/tools/javac/combo/JavacTemplateTestBase.java
+ test/lib/combo/tools/javac/combo/Template.java
+ test/lib/combo/tools/javac/combo/TemplateTest.java
+ test/tools/javac/lambda/bridge/template_tests/BridgeMethodTestCase.java
+ test/tools/javac/lambda/bridge/template_tests/BridgeMethodsTemplateTest.java
+ test/tools/javac/lambda/bridge/template_tests/TEST.properties



From eric.mccorkle at oracle.com  Mon Sep  9 21:41:04 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Mon, 09 Sep 2013 17:41:04 -0400
Subject: JDK-6962494: Update documentation on
	Executable.getParameterAnnotations()
Message-ID: <522E4070.6060502@oracle.com>

Hello,

Please review this patch which updates the javadoc comments for
java.lang.reflect.Executable.getParameterAnnotations().  The patch
corrects the javadocs to describe the actual behavior of this method.
It also refers users to the new java.lang.reflect.Parameter API.

See comments on the bug report for more details:
https://bugs.openjdk.java.net/browse/JDK-6962494

The webrev is here:
http://cr.openjdk.java.net/~emc/6962494/

This is also under review in crucible.  The review link is here:
http://sthinfra10.se.oracle.com:8060/cru/CR-JDK8TL-171

Thanks,
Eric

From mandy.chung at oracle.com  Mon Sep  9 21:41:46 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 09 Sep 2013 14:41:46 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: 
References: 
	<5226787F.6060307@oracle.com> <522DE112.4090905@oracle.com>
	
Message-ID: <522E409A.6000502@oracle.com>

On 9/9/13 10:02 AM, David Chase wrote:
> Take this lightly informed suggestion with a grain of salt, but why not, for purposes of performance and security,
> change the logging-specific getCallerClass methods so that their "class" references are instead wrapped in some sort of proxy object that only forwards certain operations quickly without a security check?  For example, equals, hashcode, and toString are probably not security-sensitive.

Most of the information obtained from a class the use cases are 
interested in are security-sensitive information (e.g. protection 
domain, code source, class loader).

Mandy

> i.e.
> class SafeClass {
>   private final Class clazz;
>   public SafeClass(Class clazz) { this.clazz = class; }
>   public String toString() { return clazz.toString(); }
>   public int hashCode() { return clazz.hashCode(); }
>   public boolean equals(Object o) { return clazz.equals(o); }
>   public Class maybeWeLetYouLookAtTheRealClass() { ... a bunch of security checks ... }
> }
>
> If necessary, do the same for classloaders.
> And them, no security checks needed, as long as the "safe" methods are enough to get the job done.
>
> David
>
> On 2013-09-09, at 10:54 AM, Mandy Chung  wrote:
>
>> Nick,
>>
>> Do you have any information to some of the questions I asked below that can help the API discussion?
>>
>> We need to decide on the permission check and also the hotspot change has to be integrated and the jdk change will need to wait until it shows in a promoted build.  Schedule-wise, to make JDK 8, we should finalize the API this week so that you can update the patch soon.
>>
>> Mandy
>>
>> On 9/3/2013 5:02 PM, Mandy Chung wrote:
>>> Nick,
>>>
>>> I skimmed through the changes.  Congratulations for your first patch making changes in both hotspot and jdk code.
>>>
>>> In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class / loader to lookup resources.  While the new APIs might be in the same class, I will discuss them individually and keep us focus one at a time.
>>>
>>> Ralph has pointed out [1] that Log4j also needs the ability to find an appropriate ClassLoader which is used for logging separation (thank you Ralph). That will be the caller-sensitivity (i.e. obtain caller's class/loader) discussion.
>>>
>>> There are a couple of RFEs:
>>> https://bugs.openjdk.java.net/browse/JDK-4942697
>>> https://bugs.openjdk.java.net/browse/JDK-6349551
>>>
>>> Performance is critical for Log4j to traverse the stack trace and obtain Class information.  I like your patch to speed up the generation of StackTraceElement[] (and StackTraceFrame[] - essentially same code with different type). java.util.logging.LogRecord has workaround the performance overhead and go to a specific frame directly and avoid the cost of generating the entire array. JDK-6349551 requests to lazily instantiate the StackTraceElement object unless that frame is requested.  Does Log4J always walk all frames and log all information?  Do you just log only some max number of frames rather than the entire stack trace?
>>>
>>> Class getDeclaringClass() method is the key method you need to enhance the diagnosability.  This method opens up a new way to access a Class instance that untrusted code wouldn't be able in the past.  A permission check is needed as Alan points out early.  Performance as well as logging framework can't access all class loaders are two factors to be considered when defining the permission check.
>>>
>>> I saw your other comment about permission check (cut-n-paste below).  It seems to me that you don't agree a permission check is needed for the getDeclaringClass() method (regardless of which class it belongs to) and if that's the case, no point to continue.
>>>
>>> I want to make it very clear that I have agreed to take this on and provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases.  It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time).
>>>
>>> The second comment on your patch is that there are lot of duplicated code in hotspot in order to support two similar but different types (StackTraceFrame and StackTraceElement). Serialization is the reason leading you to have a new StackTraceFrame class.  Maybe some refactoring can help but this is the cost of having the VM directly creating the instance.  One other option, as suggested in the previous thread, is to keep the declaring class in the StackTraceElement as a transient field.  If we add the getDeclaringClass method in the StackTraceElement class, it would need to specify to be optional that it only returns the Class instance when it's available.
>>>
>>> There are currently three different ways to get a stack trace:
>>> 1. Throwable.getStackTrace()
>>> 2. Thread.getStackTrace() and Thread.getAllStackTraces()
>>> 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int maxDepth).getStackTrace() and multiple thread IDs version
>>> (a) local (b) remote
>>>
>>> Since it's a new StackTraceFrame class, you have to provide a new method replacing #1 and #2.  I don't see any need to provide a new API equivalent to Thread.getAllStackTraces() and java.lang.management.
>>>
>>> The proposal I originally have last week was to keep declaring class as transient and add a method in StackTraceElement with a permission check at every call. Tom raises a good question about the cost of permission check.  Would that be a concern to Log4j? Is log4j on bootclasspath or extension directory?  I assume not. So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm?  For example it calls sun.reflect.Reflection.getCallerClass method that will require RuntimePermission("accessClassInPackage.sun.reflect") permission. Calling Class.getProtectionDomain and Class.getClassLoader() requires RuntimePermission("getProtectionDomain") and
>>> RuntimePermission("getClassLoader") respectively.  That gives me an impression that permission check on individual stack frame might be a non-issue?
>>>
>>> Mandy
>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html
>>>
>>> On 9/3/13 5:24 AM, Nick Williams wrote:
>>>> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
>>>>>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check.
>>>>> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API.
>>>> As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should!
>>>>
>>>> Nick
>>>
>>>
>>> On 9/1/13 1:16 AM, Nick Williams wrote:
>>>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444).
>>>>
>>>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong.
>>>>
>>>> *Summary of Changes*
>>>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows:
>>>>
>>>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8.
>>>>
>>>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8.
>>>>
>>>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame.
>>>>
>>>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame.
>>>>
>>>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames.
>>>>
>>>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast.
>>>>
>>>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive.
>>>>
>>>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected.
>>>>
>>>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works).
>>>>
>>>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods.
>>>>
>>>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch!
>>>>
>>>> *The Code Changes*
>>>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes):
>>>>
>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch
>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch
>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch
>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch
>>>>
>>>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions.
>>>>
>>>> Thanks!
>>>>
>>>> Nick
>>>




From mandy.chung at oracle.com  Mon Sep  9 21:56:42 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 09 Sep 2013 14:56:42 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <522DFEE5.3010102@redhat.com>
References: 
	<5227C0F0.5040108@oracle.com> <5227D80D.1010207@redhat.com>
	<522D339C.9010200@oracle.com> <522DFEE5.3010102@redhat.com>
Message-ID: <522E441A.1040208@oracle.com>

On 9/9/13 10:01 AM, David M. Lloyd wrote:
>> I'm not sure if we can be very certain about the depth in a runtime
>> environment (non-debugging) unless it requires all VM implementation to
>> support a reliable way to return a frame at a given depth.
>>
>> The stack trace is not guaranteed to contain all stack frames. E.g. in
>> the spec of Throwable.getStackTrace():
>>
>>     Some virtual machines may, under some circumstances, omit one or 
>> more
>>     stack frames from the stack trace. In the extreme case, a virtual
>> machine
>>     that has no stack trace information concerning this throwable is
>>     permitted to return a zero-length array from this method.
>
> This is interesting.  Presumably this would tie into tail-call 
> optimizations and that sort of thing?
>
> How does AccessControlContext deal with this possibility?

Will need the VM team to answer the details.

ACC only needs protection domains that allow the VM to do some ACC 
optimization, for example, the comment in JVM_GetStackAccessControlContext

   // count the protection domains on the execution stack. We collapse
   // duplicate consecutive protection domains into a single one, as
   // well as stopping when we hit a privileged frame.

Also classes on bootclasspath have null protection domain in the VM 
itself that it can bypass permission check on those frames.

Mandy


From stuart.marks at oracle.com  Mon Sep  9 22:29:50 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Mon, 09 Sep 2013 22:29:50 +0000
Subject: hg: jdk8/tl/jdk: 8023447: change specification to allow RMI
	activation to be optional
Message-ID: <20130909223015.4CD136269F@hg.openjdk.java.net>

Changeset: 6731ea9123f2
Author:    smarks
Date:      2013-09-09 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6731ea9123f2

8023447: change specification to allow RMI activation to be optional
Reviewed-by: darcy, alanb, olagneau

! src/share/classes/java/rmi/activation/Activatable.java
! src/share/classes/java/rmi/activation/ActivationDesc.java
! src/share/classes/java/rmi/activation/ActivationGroup.java
! src/share/classes/java/rmi/activation/ActivationGroupID.java
! src/share/classes/java/rmi/activation/ActivationID.java
! src/share/classes/java/rmi/activation/package.html



From david.lloyd at redhat.com  Mon Sep  9 22:45:10 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 09 Sep 2013 17:45:10 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <522E441A.1040208@oracle.com>
References: 
	<5227C0F0.5040108@oracle.com> <5227D80D.1010207@redhat.com>
	<522D339C.9010200@oracle.com> <522DFEE5.3010102@redhat.com>
	<522E441A.1040208@oracle.com>
Message-ID: <522E4F76.4080909@redhat.com>

On 09/09/2013 04:56 PM, Mandy Chung wrote:
> On 9/9/13 10:01 AM, David M. Lloyd wrote:
>>> I'm not sure if we can be very certain about the depth in a runtime
>>> environment (non-debugging) unless it requires all VM implementation to
>>> support a reliable way to return a frame at a given depth.
>>>
>>> The stack trace is not guaranteed to contain all stack frames. E.g. in
>>> the spec of Throwable.getStackTrace():
>>>
>>>     Some virtual machines may, under some circumstances, omit one or
>>> more
>>>     stack frames from the stack trace. In the extreme case, a virtual
>>> machine
>>>     that has no stack trace information concerning this throwable is
>>>     permitted to return a zero-length array from this method.
>>
>> This is interesting.  Presumably this would tie into tail-call
>> optimizations and that sort of thing?
>>
>> How does AccessControlContext deal with this possibility?
>
> Will need the VM team to answer the details.
>
> ACC only needs protection domains that allow the VM to do some ACC
> optimization, for example, the comment in JVM_GetStackAccessControlContext
>
>    // count the protection domains on the execution stack. We collapse
>    // duplicate consecutive protection domains into a single one, as
>    // well as stopping when we hit a privileged frame.
>
> Also classes on bootclasspath have null protection domain in the VM
> itself that it can bypass permission check on those frames.

Leaving the bootclasspath stuff aside, it would be very useful for (at 
least) security managers to be able to acquire *just* their immediate 
caller's ProtectionDomain without having to worry about spoofing or 
anything like that.  This would definitely solve my security manager use 
case at the very least - it would allow writing privileged versions of 
methods which would not require a slow doPrivileged() call; instead I 
could just check against the immediate caller's permission set.

-- 
- DML


From mike.duigou at oracle.com  Mon Sep  9 23:10:07 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 9 Sep 2013 16:10:07 -0700
Subject: RFR: 8023340 : (xxs) Clarify that unmodifiable List.replaceAll()
	may not throw UOE if there are no items to be replaced.
In-Reply-To: 
References: 
	
Message-ID: 

Responding to both of your messages at once.....

On Sep 5 2013, at 21:49 , David Holmes wrote:

> Hi Mike,
> 
> On 6/09/2013 2:58 AM, Mike Duigou wrote:
>> Hello all;
>> 
>> A very small spec clarification for review. The spec clarification ensures that the behaviour of the default method can satisfy the needs of unmodifiable implementations.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8023340/0/webrev/
> 
> I don't agree with the change. An Unmodifable list _should_ throw UOE.
> 
> That aside I don't know how to interpret you change:
> 
> "operation is not supported by this list for some element"
> 
> What does "for some element" mean ???
> 
> David
> 
>> Thanks,
>> 
>> Mike
>> 

On Sep 6 2013, at 08:35 , Martin Buchholz wrote:

> ListIterator.set is specified to throw these exceptions:
> 
>      * @throws UnsupportedOperationException if the {@code set} operation
>      *         is not supported by this list iterator
>      * @throws ClassCastException if the class of the specified element
>      *         prevents it from being added to this list
>      * @throws IllegalArgumentException if some aspect of the specified
>      *         element prevents it from being added to this list
>      * @throws IllegalStateException if neither {@code next} nor
>      *         {@code previous} have been called, or {@code remove} or
>      *         {@code add} have been called after the last call to
>      *         {@code next} or {@code previous}
> 
> List.replaceAll invokes set (conceptually), so it needs to specify the same exceptions, no?  Many years ago I made an effort to make these sorts of exception specs more consistent and accurate - a good outlet for my inner pedant.  Perhaps that needs to be done once more?  Hmmmmmmm..... I notice the above list is missing NullPointerException; that looks like a bug... (my bad, I think)
> 
> Like David, I don't see the point of this change.

The goal is to allow Collections.emptyList(), Collections.singletonList() and possibly other implementations to use the default List.replaceAll implementation. I want to avoid having to override the default implementation in order to throw UOE. In the case of emptyList() I justify this this by saying "the list is empty, so replaceAll matches nothing, no need to throw UOE". For singletonList() my goal is to allow the ListIterator.set() to throw the UOE exception rather than having to write a UOE throwing replaceAll() method for Collections.singletonList().

I significant motivation is that I want to ensure that the specification for the defaulted method is written such that the default can satisfy situations such as empty or unmodifiable collection--I could "fix" Collections.singletonList() but I can't fix every possible unmodifiable list and the default implementation can't a priori know that calling the ListIterator.set() will or won't throw UOE.

> UOE is not supposed to be at the element level.  If a List or ListIterator doesn't like a particular element, it should be throwing one of the above exceptions (plus NPE).

Yeah, probably a mistake on my part. I will try again at a definition for replaceAll() that avoids having to write override and is still coherent.

Thanks,

Mike

> 
> 
> 
> On Thu, Sep 5, 2013 at 9:58 AM, Mike Duigou  wrote:
> Hello all;
> 
> A very small spec clarification for review. The spec clarification ensures that the behaviour of the default method can satisfy the needs of unmodifiable implementations.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8023340/0/webrev/
> 
> Thanks,
> 
> Mike
> 



From jonathan.gibbons at oracle.com  Tue Sep 10 00:44:09 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 10 Sep 2013 00:44:09 +0000
Subject: hg: jdk8/tl/langtools: 8019521: Enhanced rethrow disabled in lambdas
Message-ID: <20130910004412.7EC8C626A6@hg.openjdk.java.net>

Changeset: 77d395862700
Author:    jlahoda
Date:      2013-09-09 23:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/77d395862700

8019521: Enhanced rethrow disabled in lambdas
Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas
Reviewed-by: mcimadamore, jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/lambda/EffectivelyFinalThrows.java



From david.holmes at oracle.com  Tue Sep 10 01:06:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Sep 2013 11:06:38 +1000
Subject: Please review two corrections for java.time
In-Reply-To: <522DC38D.6000302@oracle.com>
References: <522A17D9.4090103@oracle.com> <522D35E8.4010206@oracle.com>
	<522DC38D.6000302@oracle.com>
Message-ID: <522E709E.4010007@oracle.com>

Hi Roger,

On 9/09/2013 10:48 PM, roger riggs wrote:
> Hi David,
>
> I found even on my VirturalBox machine it frequently came close to the
> .1ms target
> and failed in one case.  Raising the time was to reduce/prevent
> intermittent failures.
>
> Are other timing tests also sensitive to the Xcomp, how should tests be
> written to be insensitive to that JVM option?

Xcomp can be very detrimental to timing. What _should_ happen with 
timeout/delay factors in tests (if they are unavoidable) is that a base 
delay should be chosen and it should be multiplied by a scaling factor 
that can be passed in via the test harness based on the execution 
environment (slow machine, use of Xcomp etc). This is rarely done 
however. :( I'm not sure what the JCK mechanism would be for that.

> Are you otherwise ok with the changes?

I can only comment on the timeout change.

David

> Thanks, Roger
>
>
>
> On 9/8/2013 10:43 PM, David Holmes wrote:
>> Hi Roger,
>>
>> On 7/09/2013 3:58 AM, roger riggs wrote:
>>> Please review for two corrections:
>>>
>>> -  The java/time/tck/java/time/TCKLocalTime test failed on a slow
>>> machine;
>>>      the test should be more lenient.   The test is not appropriate for
>>> a conformance test
>>>      and is moved to java/time/test/java/time/TestLocalTime.
>>
>> As per the bug report the issue is not slow machines per-se but the
>> use of Xcomp when running the test. I don't think the jck should ever
>> be run with Xcomp. It will be interesting to see if the change from
>> 100ms to 500ms cures the problem on all machines.
>>
>> Thanks,
>> David
>>
>>> - The javadoc for the JapaneseEra.MEIJI era should indicate the start
>>> date is 1868-01-01
>>>    to be consistent with java.util.Calendar.  Note that java.time does
>>> not permit dates before Meiji 6
>>>    to be created since the calendar is not clearly defined until then.
>>>
>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>
>>> Thanks, Roger
>>>
>>>
>


From jonathan.gibbons at oracle.com  Tue Sep 10 00:37:03 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 10 Sep 2013 00:37:03 +0000
Subject: hg: jdk8/tl/langtools: 8006972: jtreg test fails:
	test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
Message-ID: <20130910003707.22141626A2@hg.openjdk.java.net>

Changeset: 7439356a7dc5
Author:    jjg
Date:      2013-09-09 17:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7439356a7dc5

8006972: jtreg test fails: test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
Reviewed-by: darcy

! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref



From xuelei.fan at oracle.com  Tue Sep 10 02:08:04 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 10 Sep 2013 02:08:04 +0000
Subject: hg: jdk8/tl/jdk: 8024444: Change to use othervm mode of tests in
	SSLEngineImpl
Message-ID: <20130910020831.9BF82626AA@hg.openjdk.java.net>

Changeset: f80b8af9c218
Author:    xuelei
Date:      2013-09-09 19:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f80b8af9c218

8024444: Change to use othervm mode of tests in SSLEngineImpl
Reviewed-by: mullan

! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java



From david.holmes at oracle.com  Tue Sep 10 02:22:55 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Sep 2013 12:22:55 +1000
Subject: Please review two corrections for java.time
In-Reply-To: <522E24C3.8040607@oracle.com>
References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com>
	<522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com>
	<522E24C3.8040607@oracle.com>
Message-ID: <522E827F.1070002@oracle.com>

Typo:

+         assertTrue(diff < 100000000);  // less than 0.5 secs

David

On 10/09/2013 5:42 AM, roger riggs wrote:
> Hi Peter,
>
> Right, max doesn't solve the issue but I'm not keen on a test that retries
> until it gets a better answer.
>
> Adding nanosPerDay if the difference comes out negative would adjust
> for the crossing of midnight and not require looping on a more complex
> test condition.
>
> The longish delay in the now() method is due to first-time initialization
> that reads the timezone data file.  Introducing the loop it would change
> the test condition so that it is not testing the 'cold' startup.
> However, the purpose of the test in not to measure the initialization
> overhead
> so  adding an extra sampling of now(Clock) before the test will remove
> the first time
> initialization.
>
> Updated webrev at:
>      http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>
> Thanks, Roger
>
>
> On 9/9/2013 11:14 AM, Peter Levart wrote:
>>
>> On 09/09/2013 03:12 PM, roger riggs wrote:
>>> Hi Peter,
>>>
>>> The possible wrap-around caused by crossing midnight is handled by
>>> Math.max
>>> so a retry is not needed.
>>>
>>> Math.abs(test.toNanoOfDay() - expected.toNanoOfDay())
>>
>> Hi Roger,
>>
>> In case there is a wrap-around, the 'diff' is much more than
>> 500,000,000 ns (about 24*60*60*1,000,000,000 ns - delay), which fails
>> the test.
>>
>> But what do you think about testing before <= test <= after ? It
>> should not be timing dependent, like it is now. Does it test the same
>> thing?
>>
>> Regards, Peter
>>
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>> On 9/9/2013 2:14 AM, Peter Levart wrote:
>>>> On 09/06/2013 07:58 PM, roger riggs wrote:
>>>>> Please review for two corrections:
>>>>>
>>>>> -  The java/time/tck/java/time/TCKLocalTime test failed on a slow
>>>>> machine;
>>>>>     the test should be more lenient.   The test is not appropriate
>>>>> for a conformance test
>>>>>     and is moved to java/time/test/java/time/TestLocalTime.
>>>>>
>>>>> - The javadoc for the JapaneseEra.MEIJI era should indicate the
>>>>> start date is 1868-01-01
>>>>>   to be consistent with java.util.Calendar.  Note that java.time
>>>>> does not permit dates before Meiji 6
>>>>>   to be created since the calendar is not clearly defined until then.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>> Hi Roger,
>>>>
>>>> Although very in-probable, the test can fail when 'expected' is
>>>> sampled before and 'test' is sampled after midnight. I'm guessing
>>>> the test is trying to prove that LocalTime.now() is equivalent to
>>>> LocalTime.now(Clock.systemDefaultZone()), right?
>>>>
>>>> In that case, what about the following:
>>>>
>>>>     public void now() {
>>>>         LocalTime before, test, after;
>>>>         do {
>>>>             before = LocalTime.now(Clock.systemDefaultZone());
>>>>             test = LocalTime.now();
>>>>             after = LocalTime.now(Clock.systemDefaultZone());
>>>>           // retry in case the samples were obtained around midnight
>>>>         } while (before.compareTo(after) > 0);
>>>>
>>>>         assertTrue(before.compareTo(test) <= 0 &&
>>>> test.compareTo(after) <= 0);
>>>>     }
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>
>>
>


From peter.levart at gmail.com  Tue Sep 10 06:43:53 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Sep 2013 08:43:53 +0200
Subject: Please review two corrections for java.time
In-Reply-To: <522E24C3.8040607@oracle.com>
References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com>
	<522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com>
	<522E24C3.8040607@oracle.com>
Message-ID: <522EBFA9.6070703@gmail.com>

On 09/09/2013 09:42 PM, roger riggs wrote:
> Hi Peter,
>
> Right, max doesn't solve the issue but I'm not keen on a test that 
> retries
> until it gets a better answer.

Hi Roger,

If java.time logic is correct, it should only ever retry once when 
roll-over or DST jump-back happens, so the test could be made to fail if 
it tries to retry the 2nd time, indicating unexpected behaviour. The 
"jumps" in LocalTime should be very far-apart so the test should only 
encounter one of them, if any.

>
> Adding nanosPerDay if the difference comes out negative would adjust
> for the crossing of midnight and not require looping on a more complex
> test condition.

That's ok for midnight roll-over, but what about DST jumps? They only 
happen two times a year, so you expect the test will never encounter them?

Regards, Peter

>
> The longish delay in the now() method is due to first-time initialization
> that reads the timezone data file.  Introducing the loop it would change
> the test condition so that it is not testing the 'cold' startup.
> However, the purpose of the test in not to measure the initialization 
> overhead
> so  adding an extra sampling of now(Clock) before the test will remove 
> the first time
> initialization.
>
> Updated webrev at:
> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>
> Thanks, Roger
>
>
> On 9/9/2013 11:14 AM, Peter Levart wrote:
>>
>> On 09/09/2013 03:12 PM, roger riggs wrote:
>>> Hi Peter,
>>>
>>> The possible wrap-around caused by crossing midnight is handled by 
>>> Math.max
>>> so a retry is not needed.
>>>
>>> Math.abs(test.toNanoOfDay() - expected.toNanoOfDay())
>>
>> Hi Roger,
>>
>> In case there is a wrap-around, the 'diff' is much more than 
>> 500,000,000 ns (about 24*60*60*1,000,000,000 ns - delay), which fails 
>> the test.
>>
>> But what do you think about testing before <= test <= after ? It 
>> should not be timing dependent, like it is now. Does it test the same 
>> thing?
>>
>> Regards, Peter
>>
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>> On 9/9/2013 2:14 AM, Peter Levart wrote:
>>>> On 09/06/2013 07:58 PM, roger riggs wrote:
>>>>> Please review for two corrections:
>>>>>
>>>>> -  The java/time/tck/java/time/TCKLocalTime test failed on a slow 
>>>>> machine;
>>>>>     the test should be more lenient.   The test is not appropriate 
>>>>> for a conformance test
>>>>>     and is moved to java/time/test/java/time/TestLocalTime.
>>>>>
>>>>> - The javadoc for the JapaneseEra.MEIJI era should indicate the 
>>>>> start date is 1868-01-01
>>>>>   to be consistent with java.util.Calendar.  Note that java.time 
>>>>> does not permit dates before Meiji 6
>>>>>   to be created since the calendar is not clearly defined until then.
>>>>>
>>>>> Webrev: 
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>> Hi Roger,
>>>>
>>>> Although very in-probable, the test can fail when 'expected' is 
>>>> sampled before and 'test' is sampled after midnight. I'm guessing 
>>>> the test is trying to prove that LocalTime.now() is equivalent to 
>>>> LocalTime.now(Clock.systemDefaultZone()), right?
>>>>
>>>> In that case, what about the following:
>>>>
>>>>     public void now() {
>>>>         LocalTime before, test, after;
>>>>         do {
>>>>             before = LocalTime.now(Clock.systemDefaultZone());
>>>>             test = LocalTime.now();
>>>>             after = LocalTime.now(Clock.systemDefaultZone());
>>>>           // retry in case the samples were obtained around midnight
>>>>         } while (before.compareTo(after) > 0);
>>>>
>>>>         assertTrue(before.compareTo(test) <= 0 && 
>>>> test.compareTo(after) <= 0);
>>>>     }
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>
>>
>



From alan.bateman at oracle.com  Tue Sep 10 09:46:21 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 10 Sep 2013 09:46:21 +0000
Subject: hg: jdk8/tl/jdk: 8023878: (fs) TEST_BUG
	java/nio/file/WatchService/SensitivityModifier.java fails
	intermittently
Message-ID: <20130910094719.96C3E626B3@hg.openjdk.java.net>

Changeset: 909aced59bef
Author:    alanb
Date:      2013-09-10 10:42 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/909aced59bef

8023878: (fs) TEST_BUG java/nio/file/WatchService/SensitivityModifier.java fails intermittently
Reviewed-by: alanb
Contributed-by: yiming.wang at oracle.com

! test/java/nio/file/WatchService/SensitivityModifier.java



From staffan.larsen at oracle.com  Tue Sep 10 11:03:07 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 10 Sep 2013 14:03:07 +0300
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522DE57A.1030907@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
	<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
	<522DE57A.1030907@oracle.com>
Message-ID: <9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>

In SunCommandLineLauncher.java:

 198             if (home.length() > 0) {
 199                 String os_arch = System.getProperty("os.arch");
 200                 if ("SunOS".equals(System.getProperty("os.name"))) {
 201                     exePath = home + File.separator + "bin" + File.separator + exe;
 202                 }
 203             } else {
 204                 exePath = exe;
 205             }

I think this should be:

 198             if (home.length() > 0) {
 201                 exePath = home + File.separator + "bin" + File.separator + exe;
 203             } else {
 204                 exePath = exe;
 205             }


Thanks,
/Staffan


On 9 sep 2013, at 18:12, Kumar Srinivasan  wrote:

> Hi David,
> 
>> Hi Kumar,
>> 
>> This is still dead code in src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>> 
>> String os_arch = System.getProperty("os.arch");
> 
> Ah, I will take care of it. Thanks for spotting this.
>> 
>> Also:
>> 
>> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so 
>> 
>> I know this already exist but I thought binaries were disallowed in the open repo?
> 
> Alan, are the nio changes acceptable? Let me know if you need more time to go over all
> the changes.
> 
> Kumar
> 
>> 
>> Davud
>> 
>> On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
>>> Hi David, Staffan, Alan,
>>> 
>>> I have addressed all the issues pointed and some more I found while jprt
>>> testing.
>>> 
>>> The updated webrev for jdk is here:
>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
>>> 
>>> and the delta webrev since the last review webrev is here:
>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html 
>>> 
>>> 
>>> Thanks
>>> Kumar
>>> 
>>> 
>>>> Hi Kumar,
>>>> 
>>>> A few minor comments ...
>>>> 
>>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>> 
>>>> Seems to me this is all dead now:
>>>> 
>>>> 199                 /*
>>>> 200                  * A wrinkle in the environment:
>>>> 201                  * 64-bit executables are stored under
>>>> $JAVA_HOME/bin/os_arch
>>>> 202                  * 32-bit executables are stored under
>>>> $JAVA_HOME/bin
>>>> 203                  */
>>>> 204                 String os_arch = System.getProperty("os.arch");
>>>> 
>>>> os_arch is no longer used and the comment no longer applicable.
>>>> 
>>>> ---
>>>> 
>>>> src/solaris/bin/java_md_solinux.c
>>>> 
>>>> This seems to force DUAL_MODE off regardless of what the user may set
>>>> it to:
>>>> 
>>>>  #ifdef __solaris__
>>>> ! #  ifdef DUAL_MODE
>>>> ! #    undef DUAL_MODE
>>>> ! #  endif
>>>> 
>>>> why doesn't it just not define DUAL_MODE?
>>>> 
>>>> ---
>>>> 
>>>> test/demo/jvmti/DemoRun.java
>>>> test/sun/tools/jhat/HatRun.java
>>>> 
>>>> It isn't clear to me why you need to retain the d64 variable at all.
>>>> 
>>>> ---
>>>> 
>>>> test/tools/launcher/ExecutionEnvironment.java
>>>> 
>>>> typo: appopriate
>>>> 
>>>> 
>>>> Thanks,
>>>> David
>>>> ----
>>>> 
>>>> 
>>>> 
>>>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>>>>> Hello,
>>>>> 
>>>>> Please review the changes to remove Solaris 32-bit binaries from JDK8
>>>>> distros,
>>>>> at this time the dual mode support in the launcher is being disabled.
>>>>> 
>>>>> Message regarding this:
>>>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html 
>>>>> 
>>>>> 
>>>>> The jdk changes are here:
>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>>> 
>>>>> The top forest changes are here:
>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>>>> 
>>>>> 
>>>>> Thanks
>>>>> Kumar
>>>>> 
>>>>> 
>>> 
> 



From joel.franck at oracle.com  Tue Sep 10 11:55:22 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Tue, 10 Sep 2013 11:55:22 +0000
Subject: hg: jdk8/tl/langtools: 8005222: Fixed bugs should have tests with
	bugid in @bug tag
Message-ID: <20130910115526.1BEE4626B8@hg.openjdk.java.net>

Changeset: bb7271e64ef6
Author:    jfranck
Date:      2013-09-10 13:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb7271e64ef6

8005222: Fixed bugs should have tests with bugid in @bug tag
Reviewed-by: jfranck, jjg
Contributed-by: Andreas Lundblad 

! test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java
! test/tools/javac/defaultMethods/Neg01.java
! test/tools/javac/defaultMethods/Neg02.java
! test/tools/javac/defaultMethods/Neg03.java
! test/tools/javac/defaultMethods/Neg04.java
! test/tools/javac/defaultMethods/Neg05.java
! test/tools/javac/defaultMethods/Neg06.java
! test/tools/javac/defaultMethods/Neg07.java
! test/tools/javac/defaultMethods/Neg08.java
! test/tools/javac/defaultMethods/Neg09.java
! test/tools/javac/defaultMethods/Neg10.java
! test/tools/javac/defaultMethods/Neg11.java
! test/tools/javac/defaultMethods/Neg12.java
! test/tools/javac/defaultMethods/Neg13.java
! test/tools/javac/defaultMethods/Neg14.java
! test/tools/javac/defaultMethods/Neg15.java
! test/tools/javac/defaultMethods/Neg16.java
! test/tools/javac/defaultMethods/Pos01.java
! test/tools/javac/defaultMethods/Pos02.java
! test/tools/javac/defaultMethods/Pos04.java
! test/tools/javac/defaultMethods/Pos05.java
! test/tools/javac/defaultMethods/Pos06.java
! test/tools/javac/defaultMethods/Pos07.java
! test/tools/javac/defaultMethods/Pos08.java
! test/tools/javac/defaultMethods/Pos10.java
! test/tools/javac/defaultMethods/Pos11.java
! test/tools/javac/defaultMethods/Pos12.java
! test/tools/javac/defaultMethods/Pos13.java
! test/tools/javac/defaultMethods/Pos14.java
! test/tools/javac/defaultMethods/Pos15.java
! test/tools/javac/defaultMethods/Pos16.java
! test/tools/javac/defaultMethods/TestDefaultBody.java
! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java
! test/tools/javac/defaultMethods/crossCompile/CrossCompile.java
! test/tools/javac/defaultMethods/separate/Separate.java
! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java
! test/tools/javac/lambda/EffectivelyFinalTest.java



From Alan.Bateman at oracle.com  Tue Sep 10 13:28:05 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Sep 2013 14:28:05 +0100
Subject: @Supported design issues
In-Reply-To: <20130905202314.477145@eggemoggin.niobe.net>
References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>,
	<52293F0B.9090804@oracle.com>
	<20130905202314.477145@eggemoggin.niobe.net>
Message-ID: <522F1E65.3080503@oracle.com>

On 06/09/2013 04:23, mark.reinhold at oracle.com wrote:
> :
> Well, looking ahead to when the platform will be composed of modules,
> those modules will declare that they "export" some API elements, but
> not others.  An @Exported annotation would help get people used to
> the expected future terminology.
>
@Exported is quite good, and consistent with where this is likely going.

Joe - what would you think of just running with this? I'm anxious that 
we decide on this soon so that we don't run out of time in jdk8.

-Alan.


From eric.mccorkle at oracle.com  Tue Sep 10 13:28:46 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 10 Sep 2013 09:28:46 -0400
Subject: JDK-6962494: Update documentation on
	Executable.getParameterAnnotations()
In-Reply-To: <522E4070.6060502@oracle.com>
References: <522E4070.6060502@oracle.com>
Message-ID: <522F1E8E.8030504@oracle.com>

A new webrev has been posted, with some improvements to the comment.

On 09/09/13 17:41, Eric McCorkle wrote:
> Hello,
> 
> Please review this patch which updates the javadoc comments for
> java.lang.reflect.Executable.getParameterAnnotations().  The patch
> corrects the javadocs to describe the actual behavior of this method.
> It also refers users to the new java.lang.reflect.Parameter API.
> 
> See comments on the bug report for more details:
> https://bugs.openjdk.java.net/browse/JDK-6962494
> 
> The webrev is here:
> http://cr.openjdk.java.net/~emc/6962494/
> 
> This is also under review in crucible.  The review link is here:
> http://sthinfra10.se.oracle.com:8060/cru/CR-JDK8TL-171
> 
> Thanks,
> Eric
> 

From roger.riggs at oracle.com  Tue Sep 10 14:08:01 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 10 Sep 2013 10:08:01 -0400
Subject: Please review two corrections for java.time
In-Reply-To: <522EBFA9.6070703@gmail.com>
References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com>
	<522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com>
	<522E24C3.8040607@oracle.com> <522EBFA9.6070703@gmail.com>
Message-ID: <522F27C1.5010703@oracle.com>

Hi Peter,

Point taken about the edge cases, I'm not sure it will occur in practice
but I updated the test to retry if the time changes by more than 15 minutes.
There are likely to be other existing tests that do not taken into account
DST changes but it is not a high priority now to find and fix them.

http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/

Thanks, Roger

On 9/10/2013 2:43 AM, Peter Levart wrote:
> On 09/09/2013 09:42 PM, roger riggs wrote:
>> Hi Peter,
>>
>> Right, max doesn't solve the issue but I'm not keen on a test that 
>> retries
>> until it gets a better answer.
>
> Hi Roger,
>
> If java.time logic is correct, it should only ever retry once when 
> roll-over or DST jump-back happens, so the test could be made to fail 
> if it tries to retry the 2nd time, indicating unexpected behaviour. 
> The "jumps" in LocalTime should be very far-apart so the test should 
> only encounter one of them, if any.
>
>>
>> Adding nanosPerDay if the difference comes out negative would adjust
>> for the crossing of midnight and not require looping on a more complex
>> test condition.
>
> That's ok for midnight roll-over, but what about DST jumps? They only 
> happen two times a year, so you expect the test will never encounter them?
>
> Regards, Peter
>
>>
>> The longish delay in the now() method is due to first-time initialization
>> that reads the timezone data file.  Introducing the loop it would change
>> the test condition so that it is not testing the 'cold' startup.
>> However, the purpose of the test in not to measure the initialization 
>> overhead
>> so  adding an extra sampling of now(Clock) before the test will 
>> remove the first time
>> initialization.
>>
>> Updated webrev at:
>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>
>> Thanks, Roger
>>
>>
>> On 9/9/2013 11:14 AM, Peter Levart wrote:
>>>
>>> On 09/09/2013 03:12 PM, roger riggs wrote:
>>>> Hi Peter,
>>>>
>>>> The possible wrap-around caused by crossing midnight is handled by 
>>>> Math.max
>>>> so a retry is not needed.
>>>>
>>>> Math.abs(test.toNanoOfDay() - expected.toNanoOfDay())
>>>
>>> Hi Roger,
>>>
>>> In case there is a wrap-around, the 'diff' is much more than 
>>> 500,000,000 ns (about 24*60*60*1,000,000,000 ns - delay), which 
>>> fails the test.
>>>
>>> But what do you think about testing before <= test <= after ? It 
>>> should not be timing dependent, like it is now. Does it test the 
>>> same thing?
>>>
>>> Regards, Peter
>>>
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 9/9/2013 2:14 AM, Peter Levart wrote:
>>>>> On 09/06/2013 07:58 PM, roger riggs wrote:
>>>>>> Please review for two corrections:
>>>>>>
>>>>>> -  The java/time/tck/java/time/TCKLocalTime test failed on a slow 
>>>>>> machine;
>>>>>>     the test should be more lenient.   The test is not 
>>>>>> appropriate for a conformance test
>>>>>>     and is moved to java/time/test/java/time/TestLocalTime.
>>>>>>
>>>>>> - The javadoc for the JapaneseEra.MEIJI era should indicate the 
>>>>>> start date is 1868-01-01
>>>>>>   to be consistent with java.util.Calendar.  Note that java.time 
>>>>>> does not permit dates before Meiji 6
>>>>>>   to be created since the calendar is not clearly defined until 
>>>>>> then.
>>>>>>
>>>>>> Webrev: 
>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>>>>
>>>>> Hi Roger,
>>>>>
>>>>> Although very in-probable, the test can fail when 'expected' is 
>>>>> sampled before and 'test' is sampled after midnight. I'm guessing 
>>>>> the test is trying to prove that LocalTime.now() is equivalent to 
>>>>> LocalTime.now(Clock.systemDefaultZone()), right?
>>>>>
>>>>> In that case, what about the following:
>>>>>
>>>>>     public void now() {
>>>>>         LocalTime before, test, after;
>>>>>         do {
>>>>>             before = LocalTime.now(Clock.systemDefaultZone());
>>>>>             test = LocalTime.now();
>>>>>             after = LocalTime.now(Clock.systemDefaultZone());
>>>>>           // retry in case the samples were obtained around midnight
>>>>>         } while (before.compareTo(after) > 0);
>>>>>
>>>>>         assertTrue(before.compareTo(test) <= 0 && 
>>>>> test.compareTo(after) <= 0);
>>>>>     }
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>
>>>
>>
>



From Alan.Bateman at oracle.com  Tue Sep 10 14:34:47 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Sep 2013 15:34:47 +0100
Subject: RFR 8010293  Re: Potential issue with CHM.toArray
In-Reply-To: 
References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>
	<521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu>
	<3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com>
	<05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com>
	<5229ED0E.8010100@oracle.com>
	
Message-ID: <522F2E07.1080900@oracle.com>

On 09/09/2013 14:35, Paul Sandoz wrote:
> On Sep 6, 2013, at 4:56 PM, Alan Bateman  wrote:
>
>> :
>> The comments are very educational as the resizing is difficult to completely grok without going through examples on a whiteboard. Anyway, I don't see anything obviously wrong after going through it. The test case is useful although creating the list of threads is quite a mouth full to take in.
>>
> Yeah, i left that in a convoluted intermediate state and wanted to use CountedCompleter instead, see below for a revised and preferred version.
>
> Paul.
Thanks, the "preferred version" looks good to me. In passing I wonder if 
it should be renamed to ToArray.java while you're there.

-Alan.



From erik.helin at oracle.com  Tue Sep 10 15:56:57 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 10 Sep 2013 17:56:57 +0200
Subject: RFR: 8014659: NPG: performance counters for compressed klass space
Message-ID: <20130910155657.GA12910@ehelin-thinkpad>

Hi all,

this is the JDK part of the fix for 8014659 [0]. I've added the output
of the compressed class space performance counters next to the metaspace
output. I've also updated the jstat and jstatd tests to take the new
output into account.

Webrev:
http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/

Testing:
- jdk/test/sun/tools/jstat
- jdk/test/sun/tools/jstatd

Thanks,
Erik

[0]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659


From peter.levart at gmail.com  Tue Sep 10 16:18:44 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Sep 2013 18:18:44 +0200
Subject: Please review two corrections for java.time
In-Reply-To: <522F27C1.5010703@oracle.com>
References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com>
	<522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com>
	<522E24C3.8040607@oracle.com> <522EBFA9.6070703@gmail.com>
	<522F27C1.5010703@oracle.com>
Message-ID: <522F4664.7040104@gmail.com>

Hi Roger,

Sorry to be persistent, but if the LocalTime.now() returns local time 
for a time zone that is not the default time zone (which is an error in 
java.time implementation that I assume the test is trying to catch) then 
the diff can be a constant > 15 minutes and the loop will roll forever.

I still don't quite get what the test is trying to test, but if it is 
testing whether LocalTime.now() is returning the local time for default 
time zone and to prove that, it compares the result with 
LocalTime.now(Clock.systemDefaultZone()), then the trick to get the 
right behaviour is as follows:

When taking the following three consecutive samples (on a preloaded time 
zone data):

before = LocalTime.now(Clock.systemDefaultZone());
test = LocalTime.now();
after = LocalTime.now(Clock.systemDefaultZone());

It can happen that a local time jump occurs between samples 'before' and 
'test' or between samples 'test' and 'after' or never, but it can not 
occur at both times. So if you take:

Math.min(
     Math.abs(before.toNanoOfDay() - test.toNanoOfDay()),
     Math.abs(test.toNanoOfDay() - after.toNanoOfDay())
)

... it should be < 0.1 s always if LocalTime.now() is returning local 
time for default time zone

What do you think?

Regards, Peter

On 09/10/2013 04:08 PM, roger riggs wrote:
> Hi Peter,
>
> Point taken about the edge cases, I'm not sure it will occur in practice
> but I updated the test to retry if the time changes by more than 15 
> minutes.
> There are likely to be other existing tests that do not taken into account
> DST changes but it is not a high priority now to find and fix them.
>
> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>
> Thanks, Roger
>
> On 9/10/2013 2:43 AM, Peter Levart wrote:
>> On 09/09/2013 09:42 PM, roger riggs wrote:
>>> Hi Peter,
>>>
>>> Right, max doesn't solve the issue but I'm not keen on a test that 
>>> retries
>>> until it gets a better answer.
>>
>> Hi Roger,
>>
>> If java.time logic is correct, it should only ever retry once when 
>> roll-over or DST jump-back happens, so the test could be made to fail 
>> if it tries to retry the 2nd time, indicating unexpected behaviour. 
>> The "jumps" in LocalTime should be very far-apart so the test should 
>> only encounter one of them, if any.
>>
>>>
>>> Adding nanosPerDay if the difference comes out negative would adjust
>>> for the crossing of midnight and not require looping on a more complex
>>> test condition.
>>
>> That's ok for midnight roll-over, but what about DST jumps? They only 
>> happen two times a year, so you expect the test will never encounter 
>> them?
>>
>> Regards, Peter
>>
>>>
>>> The longish delay in the now() method is due to first-time 
>>> initialization
>>> that reads the timezone data file.  Introducing the loop it would change
>>> the test condition so that it is not testing the 'cold' startup.
>>> However, the purpose of the test in not to measure the 
>>> initialization overhead
>>> so  adding an extra sampling of now(Clock) before the test will 
>>> remove the first time
>>> initialization.
>>>
>>> Updated webrev at:
>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 9/9/2013 11:14 AM, Peter Levart wrote:
>>>>
>>>> On 09/09/2013 03:12 PM, roger riggs wrote:
>>>>> Hi Peter,
>>>>>
>>>>> The possible wrap-around caused by crossing midnight is handled by 
>>>>> Math.max
>>>>> so a retry is not needed.
>>>>>
>>>>> Math.abs(test.toNanoOfDay() - expected.toNanoOfDay())
>>>>
>>>> Hi Roger,
>>>>
>>>> In case there is a wrap-around, the 'diff' is much more than 
>>>> 500,000,000 ns (about 24*60*60*1,000,000,000 ns - delay), which 
>>>> fails the test.
>>>>
>>>> But what do you think about testing before <= test <= after ? It 
>>>> should not be timing dependent, like it is now. Does it test the 
>>>> same thing?
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 9/9/2013 2:14 AM, Peter Levart wrote:
>>>>>> On 09/06/2013 07:58 PM, roger riggs wrote:
>>>>>>> Please review for two corrections:
>>>>>>>
>>>>>>> -  The java/time/tck/java/time/TCKLocalTime test failed on a 
>>>>>>> slow machine;
>>>>>>>     the test should be more lenient.   The test is not 
>>>>>>> appropriate for a conformance test
>>>>>>>     and is moved to java/time/test/java/time/TestLocalTime.
>>>>>>>
>>>>>>> - The javadoc for the JapaneseEra.MEIJI era should indicate the 
>>>>>>> start date is 1868-01-01
>>>>>>>   to be consistent with java.util.Calendar.  Note that java.time 
>>>>>>> does not permit dates before Meiji 6
>>>>>>>   to be created since the calendar is not clearly defined until 
>>>>>>> then.
>>>>>>>
>>>>>>> Webrev: 
>>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>>>>>
>>>>>>> Thanks, Roger
>>>>>>>
>>>>>>>
>>>>>> Hi Roger,
>>>>>>
>>>>>> Although very in-probable, the test can fail when 'expected' is 
>>>>>> sampled before and 'test' is sampled after midnight. I'm guessing 
>>>>>> the test is trying to prove that LocalTime.now() is equivalent to 
>>>>>> LocalTime.now(Clock.systemDefaultZone()), right?
>>>>>>
>>>>>> In that case, what about the following:
>>>>>>
>>>>>>     public void now() {
>>>>>>         LocalTime before, test, after;
>>>>>>         do {
>>>>>>             before = LocalTime.now(Clock.systemDefaultZone());
>>>>>>             test = LocalTime.now();
>>>>>>             after = LocalTime.now(Clock.systemDefaultZone());
>>>>>>           // retry in case the samples were obtained around midnight
>>>>>>         } while (before.compareTo(after) > 0);
>>>>>>
>>>>>>         assertTrue(before.compareTo(test) <= 0 && 
>>>>>> test.compareTo(after) <= 0);
>>>>>>     }
>>>>>>
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>
>>>>
>>>
>>
>



From vicente.romero at oracle.com  Tue Sep 10 15:58:48 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 10 Sep 2013 15:58:48 +0000
Subject: hg: jdk8/tl/langtools: 8024414: javac,
	should facilitate the use of the bootstrap compiler for debugging
Message-ID: <20130910155851.CE352626C5@hg.openjdk.java.net>

Changeset: d87f017ec217
Author:    mcimadamore
Date:      2013-09-10 16:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d87f017ec217

8024414: javac, should facilitate the use of the bootstrap compiler for debugging
Reviewed-by: jjg

! make/netbeans/langtools/build.xml
! make/tools/anttasks/SelectToolTask.java



From joe.darcy at oracle.com  Tue Sep 10 16:47:14 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 10 Sep 2013 09:47:14 -0700
Subject: @Supported design issues
In-Reply-To: <522F1E65.3080503@oracle.com>
References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>,
	<52293F0B.9090804@oracle.com>
	<20130905202314.477145@eggemoggin.niobe.net>
	<522F1E65.3080503@oracle.com>
Message-ID: <522F4D12.40802@oracle.com>


On 9/10/2013 6:28 AM, Alan Bateman wrote:
> On 06/09/2013 04:23, mark.reinhold at oracle.com wrote:
>> :
>> Well, looking ahead to when the platform will be composed of modules,
>> those modules will declare that they "export" some API elements, but
>> not others.  An @Exported annotation would help get people used to
>> the expected future terminology.
>>
> @Exported is quite good, and consistent with where this is likely going.
>
> Joe - what would you think of just running with this? I'm anxious that 
> we decide on this soon so that we don't run out of time in jdk8.
>

I don't object to using @Exported.

Cheers,

-Joe



From mandy.chung at oracle.com  Tue Sep 10 16:54:29 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Sep 2013 09:54:29 -0700
Subject: @Supported design issues
In-Reply-To: <522F4D12.40802@oracle.com>
References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>,
	<52293F0B.9090804@oracle.com>
	<20130905202314.477145@eggemoggin.niobe.net>
	<522F1E65.3080503@oracle.com> <522F4D12.40802@oracle.com>
Message-ID: <522F4EC5.1050000@oracle.com>

On 9/10/13 9:47 AM, Joe Darcy wrote:
>
> On 9/10/2013 6:28 AM, Alan Bateman wrote:
>> On 06/09/2013 04:23, mark.reinhold at oracle.com wrote:
>>> :
>>> Well, looking ahead to when the platform will be composed of modules,
>>> those modules will declare that they "export" some API elements, but
>>> not others.  An @Exported annotation would help get people used to
>>> the expected future terminology.
>>>
>> @Exported is quite good, and consistent with where this is likely going.
>>
>> Joe - what would you think of just running with this? I'm anxious 
>> that we decide on this soon so that we don't run out of time in jdk8.
>>
>
> I don't object to using @Exported.

I like @Exported as well.

Mandy


From david.lloyd at redhat.com  Tue Sep 10 17:08:07 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 10 Sep 2013 12:08:07 -0500
Subject: @Supported design issues
In-Reply-To: <522F4EC5.1050000@oracle.com>
References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>,
	<52293F0B.9090804@oracle.com>
	<20130905202314.477145@eggemoggin.niobe.net>
	<522F1E65.3080503@oracle.com> <522F4D12.40802@oracle.com>
	<522F4EC5.1050000@oracle.com>
Message-ID: <522F51F7.1040204@redhat.com>

On 09/10/2013 11:54 AM, Mandy Chung wrote:
> On 9/10/13 9:47 AM, Joe Darcy wrote:
>>
>> On 9/10/2013 6:28 AM, Alan Bateman wrote:
>>> On 06/09/2013 04:23, mark.reinhold at oracle.com wrote:
>>>> :
>>>> Well, looking ahead to when the platform will be composed of modules,
>>>> those modules will declare that they "export" some API elements, but
>>>> not others.  An @Exported annotation would help get people used to
>>>> the expected future terminology.
>>>>
>>> @Exported is quite good, and consistent with where this is likely going.
>>>
>>> Joe - what would you think of just running with this? I'm anxious
>>> that we decide on this soon so that we don't run out of time in jdk8.
>>>
>>
>> I don't object to using @Exported.
>
> I like @Exported as well.

If we're framing it in terms of modules, I think it would make more 
sense to have exporting be default and "hidden" be opt-in.

And, while we're at it, "hidden" really ought to apply at a package 
level, not a class level.

In other words: don't make this about modularity.
-- 
- DML


From brian.goetz at oracle.com  Tue Sep 10 18:55:23 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 10 Sep 2013 14:55:23 -0400
Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to
	removeAll(Predicate)
In-Reply-To: <522866FF.9060806@cs.oswego.edu>
References: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com>
	<522866FF.9060806@cs.oswego.edu>
Message-ID: <522F6B1B.20800@oracle.com>

>> http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/
>>
>
> I'm still mildly opposed.
> The main uncompellingness
> is that removeIf is a more descriptive name than removeAll.

The method currently called removeIf is like an atom with one valence 
electron, searching for a pattern to bond with; right now it is floating 
free.  It currently has found a bond with the removeAll atom, but if the 
methods like Map.replaceAllIf(Predicate, BiFunction) existed as 
originally planned (they basically fell off the side of the card), it 
would form a stronger bond with the other xxxIf methods.

Which argues to leave it is as is, since I suspect eventually we'll 
discover that the existing Map.replaceAll is pretty weak.


From roger.riggs at oracle.com  Tue Sep 10 20:06:44 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 10 Sep 2013 16:06:44 -0400
Subject: Please review two corrections for java.time
In-Reply-To: <522F4664.7040104@gmail.com>
References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com>
	<522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com>
	<522E24C3.8040607@oracle.com> <522EBFA9.6070703@gmail.com>
	<522F27C1.5010703@oracle.com> <522F4664.7040104@gmail.com>
Message-ID: <522F7BD4.8060006@oracle.com>

Hi Peter,

Love those pathological edge cases...

On 9/10/2013 12:18 PM, Peter Levart wrote:
> Hi Roger,
>
> Sorry to be persistent, but if the LocalTime.now() returns local time 
> for a time zone that is not the default time zone (which is an error 
> in java.time implementation that I assume the test is trying to catch) 
> then the diff can be a constant > 15 minutes and the loop will roll 
> forever.
Forever is a long time but the framework will timeout and fail the test 
before then.
>
> I still don't quite get what the test is trying to test, but if it is 
> testing whether LocalTime.now() is returning the local time for 
> default time zone and to prove that, it compares the result with 
> LocalTime.now(Clock.systemDefaultZone()), then the trick to get the 
> right behaviour is as follows:
>
> When taking the following three consecutive samples (on a preloaded 
> time zone data):
>
> before = LocalTime.now(Clock.systemDefaultZone());
> test = LocalTime.now();
> after = LocalTime.now(Clock.systemDefaultZone());
>
> It can happen that a local time jump occurs between samples 'before' 
> and 'test' or between samples 'test' and 'after' or never, but it can 
> not occur at both times. So if you take:
If we are really pathological then the time can jump more than once in a 
short period of time.
Who knows what NTP will provide; it has been known to be wrong/faulty.
>
> Math.min(
>     Math.abs(before.toNanoOfDay() - test.toNanoOfDay()),
>     Math.abs(test.toNanoOfDay() - after.toNanoOfDay())
> )
>
> ... it should be < 0.1 s always if LocalTime.now() is returning local 
> time for default time zone
>
> What do you think?
Compact but it discards some perfectly good measurement
because it is inconvenient to compute (the wrap at midnight cases).
And it is inefficient because it tests the function twice even if it 
does not need to.

I updated the test to retry once if it failed the success criteria.
This should work in the case of a single clock change within the test 
window.

Thanks, Roger


>
> Regards, Peter
>
> On 09/10/2013 04:08 PM, roger riggs wrote:
>> Hi Peter,
>>
>> Point taken about the edge cases, I'm not sure it will occur in practice
>> but I updated the test to retry if the time changes by more than 15 
>> minutes.
>> There are likely to be other existing tests that do not taken into 
>> account
>> DST changes but it is not a high priority now to find and fix them.
>>
>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>
>> Thanks, Roger
>>
>> On 9/10/2013 2:43 AM, Peter Levart wrote:
>>> On 09/09/2013 09:42 PM, roger riggs wrote:
>>>> Hi Peter,
>>>>
>>>> Right, max doesn't solve the issue but I'm not keen on a test that 
>>>> retries
>>>> until it gets a better answer.
>>>
>>> Hi Roger,
>>>
>>> If java.time logic is correct, it should only ever retry once when 
>>> roll-over or DST jump-back happens, so the test could be made to 
>>> fail if it tries to retry the 2nd time, indicating unexpected 
>>> behaviour. The "jumps" in LocalTime should be very far-apart so the 
>>> test should only encounter one of them, if any.
>>>
>>>>
>>>> Adding nanosPerDay if the difference comes out negative would adjust
>>>> for the crossing of midnight and not require looping on a more complex
>>>> test condition.
>>>
>>> That's ok for midnight roll-over, but what about DST jumps? They 
>>> only happen two times a year, so you expect the test will never 
>>> encounter them?
>>>
>>> Regards, Peter
>>>
>>>>
>>>> The longish delay in the now() method is due to first-time 
>>>> initialization
>>>> that reads the timezone data file.  Introducing the loop it would 
>>>> change
>>>> the test condition so that it is not testing the 'cold' startup.
>>>> However, the purpose of the test in not to measure the 
>>>> initialization overhead
>>>> so  adding an extra sampling of now(Clock) before the test will 
>>>> remove the first time
>>>> initialization.
>>>>
>>>> Updated webrev at:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>> On 9/9/2013 11:14 AM, Peter Levart wrote:
>>>>>
>>>>> On 09/09/2013 03:12 PM, roger riggs wrote:
>>>>>> Hi Peter,
>>>>>>
>>>>>> The possible wrap-around caused by crossing midnight is handled 
>>>>>> by Math.max
>>>>>> so a retry is not needed.
>>>>>>
>>>>>> Math.abs(test.toNanoOfDay() - expected.toNanoOfDay())
>>>>>
>>>>> Hi Roger,
>>>>>
>>>>> In case there is a wrap-around, the 'diff' is much more than 
>>>>> 500,000,000 ns (about 24*60*60*1,000,000,000 ns - delay), which 
>>>>> fails the test.
>>>>>
>>>>> But what do you think about testing before <= test <= after ? It 
>>>>> should not be timing dependent, like it is now. Does it test the 
>>>>> same thing?
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/9/2013 2:14 AM, Peter Levart wrote:
>>>>>>> On 09/06/2013 07:58 PM, roger riggs wrote:
>>>>>>>> Please review for two corrections:
>>>>>>>>
>>>>>>>> -  The java/time/tck/java/time/TCKLocalTime test failed on a 
>>>>>>>> slow machine;
>>>>>>>>     the test should be more lenient.   The test is not 
>>>>>>>> appropriate for a conformance test
>>>>>>>>     and is moved to java/time/test/java/time/TestLocalTime.
>>>>>>>>
>>>>>>>> - The javadoc for the JapaneseEra.MEIJI era should indicate the 
>>>>>>>> start date is 1868-01-01
>>>>>>>>   to be consistent with java.util.Calendar.  Note that 
>>>>>>>> java.time does not permit dates before Meiji 6
>>>>>>>>   to be created since the calendar is not clearly defined until 
>>>>>>>> then.
>>>>>>>>
>>>>>>>> Webrev: 
>>>>>>>> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>>>>>>
>>>>>>>> Thanks, Roger
>>>>>>>>
>>>>>>>>
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> Although very in-probable, the test can fail when 'expected' is 
>>>>>>> sampled before and 'test' is sampled after midnight. I'm 
>>>>>>> guessing the test is trying to prove that LocalTime.now() is 
>>>>>>> equivalent to LocalTime.now(Clock.systemDefaultZone()), right?
>>>>>>>
>>>>>>> In that case, what about the following:
>>>>>>>
>>>>>>>     public void now() {
>>>>>>>         LocalTime before, test, after;
>>>>>>>         do {
>>>>>>>             before = LocalTime.now(Clock.systemDefaultZone());
>>>>>>>             test = LocalTime.now();
>>>>>>>             after = LocalTime.now(Clock.systemDefaultZone());
>>>>>>>           // retry in case the samples were obtained around 
>>>>>>> midnight
>>>>>>>         } while (before.compareTo(after) > 0);
>>>>>>>
>>>>>>>         assertTrue(before.compareTo(test) <= 0 && 
>>>>>>> test.compareTo(after) <= 0);
>>>>>>>     }
>>>>>>>
>>>>>>>
>>>>>>> Regards, Peter
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From david.dehaven at oracle.com  Tue Sep 10 20:06:52 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 10 Sep 2013 13:06:52 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
Message-ID: 


This isn't every other platform, this is Mac OS X and all the baggage that goes along with it! :)

What do you actually need access to user.home for? Do you have empirical evidence that this will break your application?

The whole point of sandboxing is you no longer have direct access to the entire system. The app must play inside it's sandbox, period, end of story. Gone are the days of unrestricted access to the filesystem, that's the whole point of sandboxing! This is all pretty well outlined in the "Sandboxing Your App" documentation on ADC.

Powerbox is there to solve your problem of opening user documents (with the right entitlements) and there are mechanisms in place to allow opening related files (with the users permission of course). Even a sandboxed application can show the user the contents of his various folders in a file open dialog. This all happens regardless of whether NSHomeDirectory returns /Users/JoeBob or /Users/JoeBob/Library/Containers/com.blah.someapp

-DrD-

> If you're saying that NSHomeDirectory is the correct behaviour for the Java user.home property, then I have to disagree. On every other platform, including non-sandboxed Mac, user.home is the actual user's home directory (i.e. /home/ or /Users/ or C:\Users\). Setting user.home to the *application's* home directory (which is what NSHomeDirectory returns in a sandboxed environment) would seem to me to break the definition of the user.home property.
> 
> On a mac, in a sandboxed and non-sandboxed environment, I would expect user.home to be NSHomeDirectoryForUser. A sandboxed Java app definitely needs to know about the app's Container directory (and even whether it's actually being run sandboxed or not), but redefining user.home doesn't seem like the right solution. Having AppBundler (or even the JRE) provide that information via special properties feels better from my developer's perspective.
> 
> Nick
> 
> 
> 
> On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven  wrote:
> 
> >> As someone with a Java app in the Mac App Store (MAS), I would like to vote against this change.
> >>
> >> It is still important to know the user's actual home directory (/Users/) even if the app is running in the sandbox.  Using the entitlement, com.apple.security.files.user-selected.read-write, we can still write to user selected directories (such as ~/Documents).  So changing the user.home property to point to somewhere in the app's Container would make it more difficult to get the actual home directory and thus, other directories that the end-user is familiar with. I also think this change would lead to more developer confusion and make application code more complicated.
> >>
> >> I don't know all what the user.home property is used for in the JDK itself, but concerns about the MAS sandbox would be, IMHO, better handled using special Mac/MAS only properties, such as those setup by infinitekind's Appbundler fork on bitbucket: https://bitbucket.org/infinitekind/appbundler
> >>
> >> Nick
> > I'm sure Brent wants to do the right thing here and maybe this needs some input from the Apple or other Mac-savvy folks as to whether sandboxed apps are really supposed to know about the actual user's home directory.
> >
> > FWIW, the original recommendaiton to switch to NSHomeDirectory came from Scott Kovatch when he was working on Application Bundler. It's very possible that things have changed since then.
> 
> 
> I haven't had a chance to look at the changes yet, so this may be a bit premature...
> 
> 
> Using NSHomeDirectory is the CORRECT behavior, whether the app is sandboxed or not (that extends to ALL apps, not just Java based).
> 
> If the application needs to access Documents, Music, Movies, etc then those entitlements need to be added. Additionally, even if sandboxed an application can open documents in any folder the user has access to as long as the standard file chooser is used (which I believe we already do), the app will be granted (indirect) access to the selected file(s).
> 
> -DrD-
> 
> 



From david.dehaven at oracle.com  Tue Sep 10 20:32:05 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 10 Sep 2013 13:32:05 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
Message-ID: <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>


> This isn't every other platform, this is Mac OS X and all the baggage that goes along with it! :)
> 
> What do you actually need access to user.home for? Do you have empirical evidence that this will break your application?
> 
> The whole point of sandboxing is you no longer have direct access to the entire system. The app must play inside it's sandbox, period, end of story. Gone are the days of unrestricted access to the filesystem, that's the whole point of sandboxing! This is all pretty well outlined in the "Sandboxing Your App" documentation on ADC.
> 
> Powerbox is there to solve your problem of opening user documents (with the right entitlements) and there are mechanisms in place to allow opening related files (with the users permission of course). Even a sandboxed application can show the user the contents of his various folders in a file open dialog. This all happens regardless of whether NSHomeDirectory returns /Users/JoeBob or /Users/JoeBob/Library/Containers/com.blah.someapp


That should have been:
/Users/JoeBob/Library/Containers/com.blah.someapp/Data

Which, btw, is a shadow of the users home directory... including symlinks to various folders contained therein.

-DrD-




From brian.burkhalter at oracle.com  Tue Sep 10 20:58:54 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 10 Sep 2013 13:58:54 -0700
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for
	long Strings
Message-ID: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>

Please review at your convenience.

Issue:		http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024356
Webrev:		http://cr.openjdk.java.net/~bpb/8024356/

Thanks,

Brian


From joe.darcy at oracle.com  Tue Sep 10 21:31:24 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 10 Sep 2013 14:31:24 -0700
Subject: JDK-6962494: Update documentation on
	Executable.getParameterAnnotations()
In-Reply-To: <522F1E8E.8030504@oracle.com>
References: <522E4070.6060502@oracle.com> <522F1E8E.8030504@oracle.com>
Message-ID: <522F8FAC.8060006@oracle.com>

Hi Eric,

Looks good, modulo some typos:

  434      * this object.  Synthetic and mandated parameters (see
  435      * explanation below), such as the inner this parameter to an

Inner class constructors have an *outer* this parameter.

  437      * array.  If the executable has no parameters (including
  438      * synthetic and mandated parameters), ...

For extra clarity, I would rephrase this as "... (including no synthetic 
and no mandated parameters) ..."

Thanks,

-Joe

On 9/10/2013 6:28 AM, Eric McCorkle wrote:
> A new webrev has been posted, with some improvements to the comment.
>
> On 09/09/13 17:41, Eric McCorkle wrote:
>> Hello,
>>
>> Please review this patch which updates the javadoc comments for
>> java.lang.reflect.Executable.getParameterAnnotations().  The patch
>> corrects the javadocs to describe the actual behavior of this method.
>> It also refers users to the new java.lang.reflect.Parameter API.
>>
>> See comments on the bug report for more details:
>> https://bugs.openjdk.java.net/browse/JDK-6962494
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~emc/6962494/
>>
>> This is also under review in crucible.  The review link is here:
>> http://sthinfra10.se.oracle.com:8060/cru/CR-JDK8TL-171
>>
>> Thanks,
>> Eric
>>



From kumar.x.srinivasan at oracle.com  Tue Sep 10 22:00:41 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 10 Sep 2013 15:00:41 -0700
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
	<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
	<522DE57A.1030907@oracle.com>
	<9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>
Message-ID: <522F9689.4090809@oracle.com>

Here are the updated changes:

The build changes are here:
   http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/
the delta changes since last reviewed:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/webrev.delta/index.html

The jdk changes are here:
   http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/
The delta changes since last reviewed:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/webrev.delta/index.html


Thanks
Kumar



> In SunCommandLineLauncher.java:
>
>   198             if (home.length() > 0) {
>   199                 String os_arch = System.getProperty("os.arch");
>   200                 if ("SunOS".equals(System.getProperty("os.name"))) {
>   201                     exePath = home + File.separator + "bin" + File.separator + exe;
>   202                 }
>   203             } else {
>   204                 exePath = exe;
>   205             }
>
> I think this should be:
>
>   198             if (home.length() > 0) {
>   201                 exePath = home + File.separator + "bin" + File.separator + exe;
>   203             } else {
>   204                 exePath = exe;
>   205             }
>
>
> Thanks,
> /Staffan
>
>
> On 9 sep 2013, at 18:12, Kumar Srinivasan  wrote:
>
>> Hi David,
>>
>>> Hi Kumar,
>>>
>>> This is still dead code in src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>
>>> String os_arch = System.getProperty("os.arch");
>> Ah, I will take care of it. Thanks for spotting this.
>>> Also:
>>>
>>> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
>>>
>>> I know this already exist but I thought binaries were disallowed in the open repo?
>> Alan, are the nio changes acceptable? Let me know if you need more time to go over all
>> the changes.
>>
>> Kumar
>>
>>> Davud
>>>
>>> On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
>>>> Hi David, Staffan, Alan,
>>>>
>>>> I have addressed all the issues pointed and some more I found while jprt
>>>> testing.
>>>>
>>>> The updated webrev for jdk is here:
>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
>>>>
>>>> and the delta webrev since the last review webrev is here:
>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html
>>>>
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>
>>>>> Hi Kumar,
>>>>>
>>>>> A few minor comments ...
>>>>>
>>>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>>>
>>>>> Seems to me this is all dead now:
>>>>>
>>>>> 199                 /*
>>>>> 200                  * A wrinkle in the environment:
>>>>> 201                  * 64-bit executables are stored under
>>>>> $JAVA_HOME/bin/os_arch
>>>>> 202                  * 32-bit executables are stored under
>>>>> $JAVA_HOME/bin
>>>>> 203                  */
>>>>> 204                 String os_arch = System.getProperty("os.arch");
>>>>>
>>>>> os_arch is no longer used and the comment no longer applicable.
>>>>>
>>>>> ---
>>>>>
>>>>> src/solaris/bin/java_md_solinux.c
>>>>>
>>>>> This seems to force DUAL_MODE off regardless of what the user may set
>>>>> it to:
>>>>>
>>>>>   #ifdef __solaris__
>>>>> ! #  ifdef DUAL_MODE
>>>>> ! #    undef DUAL_MODE
>>>>> ! #  endif
>>>>>
>>>>> why doesn't it just not define DUAL_MODE?
>>>>>
>>>>> ---
>>>>>
>>>>> test/demo/jvmti/DemoRun.java
>>>>> test/sun/tools/jhat/HatRun.java
>>>>>
>>>>> It isn't clear to me why you need to retain the d64 variable at all.
>>>>>
>>>>> ---
>>>>>
>>>>> test/tools/launcher/ExecutionEnvironment.java
>>>>>
>>>>> typo: appopriate
>>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> ----
>>>>>
>>>>>
>>>>>
>>>>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the changes to remove Solaris 32-bit binaries from JDK8
>>>>>> distros,
>>>>>> at this time the dual mode support in the launcher is being disabled.
>>>>>>
>>>>>> Message regarding this:
>>>>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>>>>
>>>>>>
>>>>>> The jdk changes are here:
>>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>>>>
>>>>>> The top forest changes are here:
>>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Kumar
>>>>>>
>>>>>>



From david.dehaven at oracle.com  Tue Sep 10 22:36:32 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 10 Sep 2013 15:36:32 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
Message-ID: 


> I use user.home to do things like:
> 
> String userHomePath = System.getProperty("user.home");
> myFileDialog.setDirectory(userHomePath + "/Documents");

This will continue to work fine. Like I said, user.home is the Data directory inside the app container which is a shadow of the users home folder, complete with symlinks to common user directories (such as Documents, Movies, Music, etc..). Sandboxd and powerbox manage all the translations behind the scene.


> In my app, the user selects where he wants to export individual files, such as CSVs and PDFs. These are files he'll use outside of my app.
> 
> If user.home points to the app's sandbox Container, it will break this usage.  Opening a file dialog to /Users/Bob/Library/Containers/my.app/Data/Documents will definitely confuse the user and if they save a file there, they will never be able to find it later from outside of my app.

The user won't know the difference, all they'll see is ~/Documents as provided by powerbox.

Fun fact: The reason powerbox isn't hackable is it runs in a separate process...


> Yes, I understand the whole sandboxing concept. I'm not asking for unrestricted access to the file system. I use the "com.apple.security.files.user-selected.read-write" entitlement so that the user can select where he wants to save files, and I want to present him with a standard, well-known, default location for that (like ~/Documents). 
> 
> If user.home doesn't point to the user's actual home folder (i.e. NSHomeDirectoryForUser), it makes creating a standard, well-known location path (like ~/Documents) much more difficult.  (And IMHO, it breaks the definition of the user.home property: "User home directory", not "App home directory".)

Powerbox solves exactly that problem... and yes, yes it is users home folder, from the perspective of a sandboxed application!



Here's some code to prove it actually works since you don't seem to believe me:
{
    @autorelease {
        NSOpenPanel *panel = [NSOpenPanel openPanel];
        panel.allowsMultipleSelection = NO;
        panel.canChooseDirectories = NO;

        NSString *home = NSHomeDirectory();
        NSString *docs = [home stringByAppendingPathComponent:@"Downloads"];
        NSLog(@"home: %@", home);
        NSLog(@"docs: %@", docs);

        [panel setDirectoryURL:[NSURL fileURLWithPath:docs]];
        [panel beginWithCompletionHandler:^(NSInteger result) {
            NSLog(@"panel result: %ld", result);
            if (result == NSFileHandlingPanelOKButton) {
                NSLog(@"panel selected file: %@", [[panel URLs] objectAtIndex:0]);
            }
        }];
    }
}

Example run:
2013-09-10 15:30:52.630 BlahText[11480:303] home: /Users/daved/Library/Containers/com.blah.SomeApp/Data
2013-09-10 15:30:52.631 BlahText[11480:303] docs: /Users/daved/Library/Containers/com.blah.SomeApp/Data/Documents
2013-09-10 15:30:59.180 BlahText[11480:303] panel result: 1
2013-09-10 15:30:59.180 BlahText[11480:303] panel selected file: file://localhost/Users/daved/Documents/Some%20Document.txt

And the open panel opens displaying the contents of my Documents folder, the user will never see the app container path unless you explicitly report it to them.

-DrD-



From joe.darcy at oracle.com  Tue Sep 10 23:26:48 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Tue, 10 Sep 2013 16:26:48 -0700
Subject: @Supported design issues
In-Reply-To: <522F51F7.1040204@redhat.com>
References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>,
	<52293F0B.9090804@oracle.com>
	<20130905202314.477145@eggemoggin.niobe.net>
	<522F1E65.3080503@oracle.com> <522F4D12.40802@oracle.com>
	<522F4EC5.1050000@oracle.com> <522F51F7.1040204@redhat.com>
Message-ID: <522FAAB8.7020404@oracle.com>

On 9/10/2013 10:08 AM, David M. Lloyd wrote:
> On 09/10/2013 11:54 AM, Mandy Chung wrote:
>> On 9/10/13 9:47 AM, Joe Darcy wrote:
>>>
>>> On 9/10/2013 6:28 AM, Alan Bateman wrote:
>>>> On 06/09/2013 04:23, mark.reinhold at oracle.com wrote:
>>>>> :
>>>>> Well, looking ahead to when the platform will be composed of modules,
>>>>> those modules will declare that they "export" some API elements, but
>>>>> not others.  An @Exported annotation would help get people used to
>>>>> the expected future terminology.
>>>>>
>>>> @Exported is quite good, and consistent with where this is likely 
>>>> going.
>>>>
>>>> Joe - what would you think of just running with this? I'm anxious
>>>> that we decide on this soon so that we don't run out of time in jdk8.
>>>>
>>>
>>> I don't object to using @Exported.
>>
>> I like @Exported as well.
>
> If we're framing it in terms of modules, I think it would make more 
> sense to have exporting be default and "hidden" be opt-in.
>
> And, while we're at it, "hidden" really ought to apply at a package 
> level, not a class level.
>
> In other words: don't make this about modularity.

To bring in some of the initial context, this feature is about 
documenting and formalizing the historically unclear 
exported-ness/supported-ness of types in the com.sun.* packages. Some 
com.sun.* types are intended to be used outside of the JDK while others 
are not.

To bring clarity to this situation, I'd like to see each type and 
package in com.sun.* either have an explicit @Exported(true) XOR 
@Exported(false) annotation applied to it. This make a clear statement 
around the intentions of the type and will allow better tooling to be 
written.

-Joe



From joe.darcy at oracle.com  Wed Sep 11 00:12:05 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Tue, 10 Sep 2013 17:12:05 -0700
Subject: java.lang.reflect.Parameter comments
In-Reply-To: 
References: 
Message-ID: <522FB555.9040009@oracle.com>

Hello,

Sending along some responses to these questions from Alex:

On 8/25/2013 7:03 AM, Kasper Nielsen wrote:
> Hi,
>
> just 2 short questions/commons on java.lang.reflect.Parameter
>
> 1)
> I was wondering if there is any reason for java.lang.reflect.Parameter not
> to expose the index field?

"Not sure what you mean by the "index field", but if you mean the 
name_index item in the MethodParameters attribute, then it is possible 
to know whether it's zero by calling Parameter#isNamePresent."

>
> 2)
> Also, while Parameter.getParameterizedType() might be a better name than
> getGenericType().
> I find it kind of annoying that it is called Field.getGenericType() but
> Parameter.getParameterizedType(). Lets just have the same name for
> practically the same functionality?
>

"Yes and no. First, the historic use of getGenericXXX in 
java.lang.reflect is wrong (it should be getParameterizedXXX) but it 
can't be changed now. The Language Model API in javax.lang.model.** is 
much better with terminology. Second, when we add methods to existing 
java.lang.reflect types, we hold our noses and use "Generic" for 
consistency, e.g., the new AnnotatedArrayType interface for type 
annotations has a method getAnnotatedGenericComponentType that is 
consistent with the getGenericComponentType method in GenericArrayType. 
Third, when we add new types to java.lang.reflect, we use the correct 
terminology, hence Parameter#getParameterizedType."

HTH,

-Joe



From brent.christian at oracle.com  Wed Sep 11 00:27:18 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 10 Sep 2013 17:27:18 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
	
Message-ID: <522FB8E6.4020209@oracle.com>

Adding a little to what Dave said, based on my understanding...

On 9/10/13 3:36 PM, David DeHaven wrote:
 > Nicholas Rahn wrote:
>
>> In my app, the user selects where he wants to export individual
>> files, such as CSVs and PDFs. These are files he'll use outside of
>> my app.
>>
>> If user.home points to the app's sandbox Container, it will break
>> this usage.  Opening a file dialog to
>> /Users/Bob/Library/Containers/my.app/Data/Documents will definitely
>> confuse the user and if they save a file there, they will never be
>> able to find it later from outside of my app.
>
> The user won't know the difference, all they'll see is ~/Documents as
> provided by powerbox.

Note that PowerBox+NSOpenPanel recognize the Container path, and 
automagically take the user to their *actual* $HOME, Documents, etc 
directories.

With this change, then, telling a native FileDialog to open user.home 
(or user.home/Documents, etc), will (still) show the user their real 
$HOME (or $HOME/Documents, etc) directory, whether sandboxed (user.home 
is the app Container, redirected by PowerBox to $HOME) or not 
(user.home=$HOME).

The selected file returned from the FileDialog will point to a location 
within $HOME, and because of the *.files.user-selected.* entitlement, 
the app will now have access to it.

>> Yes, I understand the whole sandboxing concept. I'm not asking for
>> unrestricted access to the file system. I use the
>> "com.apple.security.files.user-selected.read-write" entitlement so
>> that the user can select where he wants to save files, and I want
>> to present him with a standard, well-known, default location for
>> that (like ~/Documents).
>>
>> If user.home doesn't point to the user's actual home folder (i.e.
>> NSHomeDirectoryForUser), it makes creating a standard, well-known
>> location path (like ~/Documents) much more difficult.

BTW, NSHomeDirectoryForUser() for the current user returns the same 
sandboxed value as NSHomeDirectory().

Without this change, user.home is obtained using the POSIX getpwuid() 
call - really not the Apple-recommended way for dealing with the sandbox.

> Powerbox solves exactly that problem... and yes, yes it is users home
> folder, from the perspective of a sandboxed application!
 >
 > ...
 >
>the user will never see the app container path unless you
> explicitly report it to them.

...though it's really not mean to be presented to the user (and I 
haven't been able to convince FileDialog to take me to it).  The 
Container directory is meant only for files used by the app itself. 
 From [1]:

"The container is in a hidden location, and so users do not interact 
with it directly. Specifically, the container is not for user documents. 
It is for files that your app uses, along with databases, caches, and 
other app-specific data"


The suggested change to the value of user.home means that it can be used 
by apps to write their own private data files AND (thanks to the 
PowerBox magic) point a user to their $HOME within a native file dialog, 
AND it will work inside or outside the App Sandbox.

As it is now, apps needing to write app-specific data would need to 
special-case for the App Sandbox and go find the Container directory, 
since $HOME is not accessible (and only becomes accessible if the user 
interacts with a FileDialog).

Thanks,
-Brent

[1] 
https://developer.apple.com/library/mac/documentation/security/conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW15


From david.holmes at oracle.com  Wed Sep 11 01:26:01 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2013 11:26:01 +1000
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522F9689.4090809@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
	<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
	<522DE57A.1030907@oracle.com>
	<9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>
	<522F9689.4090809@oracle.com>
Message-ID: <522FC6A9.2070203@oracle.com>

On 11/09/2013 8:00 AM, Kumar Srinivasan wrote:
> Here are the updated changes:

Looks okay to me.

David

> The build changes are here:
>    http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/
> the delta changes since last reviewed:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/webrev.delta/index.html
>
>
> The jdk changes are here:
>    http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/
> The delta changes since last reviewed:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/webrev.delta/index.html
>
>
>
> Thanks
> Kumar
>
>
>
>> In SunCommandLineLauncher.java:
>>
>>   198             if (home.length() > 0) {
>>   199                 String os_arch = System.getProperty("os.arch");
>>   200                 if
>> ("SunOS".equals(System.getProperty("os.name"))) {
>>   201                     exePath = home + File.separator + "bin" +
>> File.separator + exe;
>>   202                 }
>>   203             } else {
>>   204                 exePath = exe;
>>   205             }
>>
>> I think this should be:
>>
>>   198             if (home.length() > 0) {
>>   201                 exePath = home + File.separator + "bin" +
>> File.separator + exe;
>>   203             } else {
>>   204                 exePath = exe;
>>   205             }
>>
>>
>> Thanks,
>> /Staffan
>>
>>
>> On 9 sep 2013, at 18:12, Kumar Srinivasan
>>  wrote:
>>
>>> Hi David,
>>>
>>>> Hi Kumar,
>>>>
>>>> This is still dead code in
>>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>>
>>>> String os_arch = System.getProperty("os.arch");
>>> Ah, I will take care of it. Thanks for spotting this.
>>>> Also:
>>>>
>>>> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
>>>>
>>>>
>>>> I know this already exist but I thought binaries were disallowed in
>>>> the open repo?
>>> Alan, are the nio changes acceptable? Let me know if you need more
>>> time to go over all
>>> the changes.
>>>
>>> Kumar
>>>
>>>> Davud
>>>>
>>>> On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
>>>>> Hi David, Staffan, Alan,
>>>>>
>>>>> I have addressed all the issues pointed and some more I found while
>>>>> jprt
>>>>> testing.
>>>>>
>>>>> The updated webrev for jdk is here:
>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
>>>>>
>>>>> and the delta webrev since the last review webrev is here:
>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>>
>>>>>> Hi Kumar,
>>>>>>
>>>>>> A few minor comments ...
>>>>>>
>>>>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>>>>
>>>>>> Seems to me this is all dead now:
>>>>>>
>>>>>> 199                 /*
>>>>>> 200                  * A wrinkle in the environment:
>>>>>> 201                  * 64-bit executables are stored under
>>>>>> $JAVA_HOME/bin/os_arch
>>>>>> 202                  * 32-bit executables are stored under
>>>>>> $JAVA_HOME/bin
>>>>>> 203                  */
>>>>>> 204                 String os_arch = System.getProperty("os.arch");
>>>>>>
>>>>>> os_arch is no longer used and the comment no longer applicable.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/solaris/bin/java_md_solinux.c
>>>>>>
>>>>>> This seems to force DUAL_MODE off regardless of what the user may set
>>>>>> it to:
>>>>>>
>>>>>>   #ifdef __solaris__
>>>>>> ! #  ifdef DUAL_MODE
>>>>>> ! #    undef DUAL_MODE
>>>>>> ! #  endif
>>>>>>
>>>>>> why doesn't it just not define DUAL_MODE?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> test/demo/jvmti/DemoRun.java
>>>>>> test/sun/tools/jhat/HatRun.java
>>>>>>
>>>>>> It isn't clear to me why you need to retain the d64 variable at all.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> test/tools/launcher/ExecutionEnvironment.java
>>>>>>
>>>>>> typo: appopriate
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> ----
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the changes to remove Solaris 32-bit binaries from
>>>>>>> JDK8
>>>>>>> distros,
>>>>>>> at this time the dual mode support in the launcher is being
>>>>>>> disabled.
>>>>>>>
>>>>>>> Message regarding this:
>>>>>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The jdk changes are here:
>>>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>>>>>
>>>>>>> The top forest changes are here:
>>>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Kumar
>>>>>>>
>>>>>>>
>


From david.lloyd at redhat.com  Wed Sep 11 02:50:13 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 10 Sep 2013 21:50:13 -0500
Subject: @Supported design issues
In-Reply-To: <522FAAB8.7020404@oracle.com>
References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>,
	<52293F0B.9090804@oracle.com>
	<20130905202314.477145@eggemoggin.niobe.net>
	<522F1E65.3080503@oracle.com> <522F4D12.40802@oracle.com>
	<522F4EC5.1050000@oracle.com> <522F51F7.1040204@redhat.com>
	<522FAAB8.7020404@oracle.com>
Message-ID: <522FDA65.1010403@redhat.com>

On 09/10/2013 06:26 PM, Joseph Darcy wrote:
> On 9/10/2013 10:08 AM, David M. Lloyd wrote:
>> On 09/10/2013 11:54 AM, Mandy Chung wrote:
>>> On 9/10/13 9:47 AM, Joe Darcy wrote:
>>>>
>>>> On 9/10/2013 6:28 AM, Alan Bateman wrote:
>>>>> On 06/09/2013 04:23, mark.reinhold at oracle.com wrote:
>>>>>> :
>>>>>> Well, looking ahead to when the platform will be composed of modules,
>>>>>> those modules will declare that they "export" some API elements, but
>>>>>> not others.  An @Exported annotation would help get people used to
>>>>>> the expected future terminology.
>>>>>>
>>>>> @Exported is quite good, and consistent with where this is likely
>>>>> going.
>>>>>
>>>>> Joe - what would you think of just running with this? I'm anxious
>>>>> that we decide on this soon so that we don't run out of time in jdk8.
>>>>>
>>>>
>>>> I don't object to using @Exported.
>>>
>>> I like @Exported as well.
>>
>> If we're framing it in terms of modules, I think it would make more
>> sense to have exporting be default and "hidden" be opt-in.
>>
>> And, while we're at it, "hidden" really ought to apply at a package
>> level, not a class level.
>>
>> In other words: don't make this about modularity.
>
> To bring in some of the initial context, this feature is about
> documenting and formalizing the historically unclear
> exported-ness/supported-ness of types in the com.sun.* packages. Some
> com.sun.* types are intended to be used outside of the JDK while others
> are not.

I'm aware of that; however I guarantee you that if you try to munge this 
functionality up with the concept of exported classes or packages before 
the module system is realized, it's going to end up wrong and we'll have 
yet more dead cruft in the API.

> To bring clarity to this situation, I'd like to see each type and
> package in com.sun.* either have an explicit @Exported(true) XOR
> @Exported(false) annotation applied to it. This make a clear statement
> around the intentions of the type and will allow better tooling to be
> written.

"Plus one" for this, modulo a request to not use the term "Exported" 
and/or not make this annotation part of the public API.
-- 
- DML


From henry.jen at oracle.com  Wed Sep 11 03:47:58 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 10 Sep 2013 20:47:58 -0700
Subject: RFR: 8024500: Missing API coverage for java.util.function.BiFunction
	andThen
Message-ID: <522FE7EE.902@oracle.com>

Hi,

Please review a simple webrev that adds two tests, one for

java.util.function.BiFunction.andThen() another to cover
java.util.Collections.SingletonIterator.

Cheers,
Henry


From xuelei.fan at oracle.com  Wed Sep 11 04:44:45 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 11 Sep 2013 04:44:45 +0000
Subject: hg: jdk8/tl/jdk: 8024501: sun.security.mscapi.Key has no definition
	of serialVersionUID
Message-ID: <20130911044514.DF6A6626E9@hg.openjdk.java.net>

Changeset: c9083205e6eb
Author:    xuelei
Date:      2013-09-10 21:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9083205e6eb

8024501: sun.security.mscapi.Key has no definition of serialVersionUID
Reviewed-by: weijun

! src/windows/classes/sun/security/mscapi/Key.java



From henry.jen at oracle.com  Wed Sep 11 05:03:50 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 10 Sep 2013 22:03:50 -0700
Subject: RFR: 8024500: Missing API coverage for
	java.util.function.BiFunction andThen
In-Reply-To: <522FE7EE.902@oracle.com>
References: <522FE7EE.902@oracle.com>
Message-ID: 

Sorry I forgot it again. Copied but not pasted. :(

http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/

Thanks for reviewing.

Cheers,
Henry

On Sep 10, 2013, at 8:47 PM, Henry Jen  wrote:

> Hi,
> 
> Please review a simple webrev that adds two tests, one for
> 
> java.util.function.BiFunction.andThen() another to cover
> java.util.Collections.SingletonIterator.
> 
> Cheers,
> Henry



From mike.duigou at oracle.com  Wed Sep 11 05:19:30 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 10 Sep 2013 22:19:30 -0700
Subject: RFR: 8024500: Missing API coverage for
	java.util.function.BiFunction andThen
In-Reply-To: 
References: <522FE7EE.902@oracle.com>
	
Message-ID: <6332204A-0851-4E65-A042-22C2796E23A5@oracle.com>

Tests look fine. 

In the BiFunction test the unknown word "delieve" is used. I am not sure what word was intended.

Mike

On Sep 10 2013, at 22:03 , Henry Jen wrote:

> Sorry I forgot it again. Copied but not pasted. :(
> 
> http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/
> 
> Thanks for reviewing.
> 
> Cheers,
> Henry
> 
> On Sep 10, 2013, at 8:47 PM, Henry Jen  wrote:
> 
>> Hi,
>> 
>> Please review a simple webrev that adds two tests, one for
>> 
>> java.util.function.BiFunction.andThen() another to cover
>> java.util.Collections.SingletonIterator.
>> 
>> Cheers,
>> Henry
> 



From masayoshi.okutsu at oracle.com  Wed Sep 11 06:30:34 2013
From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com)
Date: Wed, 11 Sep 2013 06:30:34 +0000
Subject: hg: jdk8/tl/jdk: 8024141: Unexpected timezone display name
Message-ID: <20130911063111.3DFBC626EE@hg.openjdk.java.net>

Changeset: 13ee370ee8b3
Author:    okutsu
Date:      2013-09-11 15:29 +0900
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ee370ee8b3

8024141: Unexpected timezone display name
Reviewed-by: peytoia

! src/share/classes/sun/util/locale/provider/LocaleResources.java
+ test/sun/util/locale/provider/Bug8024141.java



From joel.franck at oracle.com  Wed Sep 11 09:02:30 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Wed, 11 Sep 2013 09:02:30 +0000
Subject: hg: jdk8/tl/jdk: 4987375: (reflect) Class.get{Declared}Method{s} does
	not return clone() for array types
Message-ID: <20130911090255.16560626F4@hg.openjdk.java.net>

Changeset: b271ea30f440
Author:    jfranck
Date:      2013-09-11 09:45 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b271ea30f440

4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array types
Summary: Update spec to match long standing behavior
Reviewed-by: darcy, mchung

! src/share/classes/java/lang/Class.java
+ test/java/lang/Class/ArrayMethods.java



From joel.franck at oracle.com  Wed Sep 11 09:25:38 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Wed, 11 Sep 2013 11:25:38 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: <522E33A0.9050206@univ-mlv.fr>
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
	
	<522E33A0.9050206@univ-mlv.fr>
Message-ID: <20130911092538.GQ11725@jfranck-desktop.jrpg.bea.com>

On 2013-09-09, Remi Forax wrote:
> On 09/09/2013 07:27 PM, Joel Borggr?n-Franck wrote:
> >On 9 sep 2013, at 19:00, Joel Borggr?n-Franck  wrote:
> >
> >>The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS).
> >Correcting myself, I added a note to getMethods() and getMethod(String name ?)
> >
> >getDeclaredMethod{s} shouldn't need a note.
> >
> >cheers
> >/Joel
> 
> also Joel you can use for-each and avoid to load ma[i] twice
> (even if the JIT will certainly avoid the double load in this
> specific case).
> 
> void addAllNonStatic(Method[] methodArray) {
>     for (Method method:methodArray) {
>         if (!Modifier.isStatic(method.getModifiers())) {
>             add(method);
>         }
>     }
> }
> 

I should use foreach if possible in any case, looks much cleaner.

cheres
/Joel


From chris.hegarty at oracle.com  Wed Sep 11 10:05:06 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 11 Sep 2013 10:05:06 +0000
Subject: hg: jdk8/tl/jdk: 8024508: Fix doclint issues in com.sun.nio.sctp
Message-ID: <20130911100541.0C8DA626F7@hg.openjdk.java.net>

Changeset: 517c5e99fb2f
Author:    chegar
Date:      2013-09-11 11:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/517c5e99fb2f

8024508: Fix doclint issues in com.sun.nio.sctp
Reviewed-by: alanb

! src/share/classes/com/sun/nio/sctp/Association.java
! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java
! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java
! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java
! src/share/classes/com/sun/nio/sctp/MessageInfo.java
! src/share/classes/com/sun/nio/sctp/Notification.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



From Alan.Bateman at oracle.com  Wed Sep 11 10:21:08 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Sep 2013 11:21:08 +0100
Subject: @Supported design issues
In-Reply-To: <522FDA65.1010403@redhat.com>
References: <51266B7C.3040804@oracle.com>, <52284CC4.4030701@oracle.com>,
	<52293F0B.9090804@oracle.com>
	<20130905202314.477145@eggemoggin.niobe.net>
	<522F1E65.3080503@oracle.com> <522F4D12.40802@oracle.com>
	<522F4EC5.1050000@oracle.com> <522F51F7.1040204@redhat.com>
	<522FAAB8.7020404@oracle.com> <522FDA65.1010403@redhat.com>
Message-ID: <52304414.5090106@oracle.com>

On 11/09/2013 03:50, David M. Lloyd wrote:
>
> I'm aware of that; however I guarantee you that if you try to munge 
> this functionality up with the concept of exported classes or packages 
> before the module system is realized, it's going to end up wrong and 
> we'll have yet more dead cruft in the API.
There isn't any real functionality here, it's simply an effort to make 
it clear which com.sun.** APIs are okay for developers to depend on. 
This is useful for JDK maintainers too.

If/when we move to a modular JDK then it would be reasonable to expect 
that the @Exported APIs would be APIs that applications can continue to 
depend on. It may be that some of the non- at Exported JDK-specific APIs 
are completely hidden from applications, in which case having @Exported 
now is a good thing as it helps developers and tooling be aware that 
they may be directly using JDK internal APIs, perhaps unknowingly. We 
also include rudimentary tooling (jdeps) to help in the effort to 
understand dependencies. It may be that jdeps should be extended to also 
look at the @Exported annotation.

As I mention non- at Exported APIs then I don't think (and Joe can confirm) 
that there is any intention to add @Exported(false) to thousands of 
JDK-internal classes (and their package-info.java if it exists). Rather, 
if @Exported is not present then the default answer has to be that it is 
ambiguous and so not safe to depend on. Assuming I have this right then 
it means that @jdk.Exported (or whatever the final name is) will only be 
added to the small number of JDK-specific APIs that are long term 
stable/supported/documented APIs. This is consistent with the patches 
that have been discussed to date [1][2].

-Alan

[1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/011cf7e0a148
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014691.html


From chris.hegarty at oracle.com  Wed Sep 11 10:33:20 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 11 Sep 2013 10:33:20 +0000
Subject: hg: jdk8/tl/jdk: 8023090: Additional debug info for
	java/net/NetworkInterface/Equals.java
Message-ID: <20130911103406.0A0C7626FB@hg.openjdk.java.net>

Changeset: d389dedd1ccb
Author:    chegar
Date:      2013-09-11 11:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d389dedd1ccb

8023090: Additional debug info for java/net/NetworkInterface/Equals.java
Reviewed-by: alanb

! test/java/net/NetworkInterface/Equals.java



From magnus.ihse.bursie at oracle.com  Wed Sep 11 11:47:48 2013
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 11 Sep 2013 13:47:48 +0200
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522F9689.4090809@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
	<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
	<522DE57A.1030907@oracle.com>
	<9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>
	<522F9689.4090809@oracle.com>
Message-ID: <52305864.7010503@oracle.com>

On 2013-09-11 00:00, Kumar Srinivasan wrote:
> Here are the updated changes:
>
> The build changes are here:
>   http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/
> the delta changes since last reviewed:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/webrev.delta/index.html 
>
>
> The jdk changes are here:
>   http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/
> The delta changes since last reviewed:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/webrev.delta/index.html 
>

Looks good!

/Magnus



From eric.mccorkle at oracle.com  Wed Sep 11 12:31:30 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Wed, 11 Sep 2013 12:31:30 +0000
Subject: hg: jdk8/tl/langtools: 8024510:
	lib/combo/tools/javac/combo/TemplateTest.java fails
Message-ID: <20130911123135.C7961626FD@hg.openjdk.java.net>

Changeset: 65c218b25b61
Author:    emc
Date:      2013-09-11 08:30 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/65c218b25b61

8024510: lib/combo/tools/javac/combo/TemplateTest.java fails
Summary: Edit regex in Template to allow "MAJOR." pattern.
Reviewed-by: briangoetz

! test/lib/combo/tools/javac/combo/Template.java



From eric.mccorkle at oracle.com  Wed Sep 11 12:37:01 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 11 Sep 2013 08:37:01 -0400
Subject: JDK-6962494: Update documentation on
	Executable.getParameterAnnotations()
In-Reply-To: <522F8FAC.8060006@oracle.com>
References: <522E4070.6060502@oracle.com> <522F1E8E.8030504@oracle.com>
	<522F8FAC.8060006@oracle.com>
Message-ID: <523063ED.4070500@oracle.com>

Thanks for the review.

On 09/10/13 17:31, Joe Darcy wrote:
> Hi Eric,
> 
> Looks good, modulo some typos:
> 
>  434      * this object.  Synthetic and mandated parameters (see
>  435      * explanation below), such as the inner this parameter to an
> 
> Inner class constructors have an *outer* this parameter.

Argh!  Fixed.

> 
>  437      * array.  If the executable has no parameters (including
>  438      * synthetic and mandated parameters), ...
> 
> For extra clarity, I would rephrase this as "... (including no synthetic
> and no mandated parameters) ..."
> 

I worded this as "If the executable has no parameters (meaning no
formal, no synthetic, and no mandated...)"

> Thanks,
> 
> -Joe
> 
> On 9/10/2013 6:28 AM, Eric McCorkle wrote:
>> A new webrev has been posted, with some improvements to the comment.
>>
>> On 09/09/13 17:41, Eric McCorkle wrote:
>>> Hello,
>>>
>>> Please review this patch which updates the javadoc comments for
>>> java.lang.reflect.Executable.getParameterAnnotations().  The patch
>>> corrects the javadocs to describe the actual behavior of this method.
>>> It also refers users to the new java.lang.reflect.Parameter API.
>>>
>>> See comments on the bug report for more details:
>>> https://bugs.openjdk.java.net/browse/JDK-6962494
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~emc/6962494/
>>>
>>> This is also under review in crucible.  The review link is here:
>>> http://sthinfra10.se.oracle.com:8060/cru/CR-JDK8TL-171
>>>
>>> Thanks,
>>> Eric
>>>
> 

From naoto.sato at oracle.com  Wed Sep 11 12:40:34 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 11 Sep 2013 12:40:34 +0000
Subject: hg: jdk8/tl/jdk: 8024332: sun/util/resources/en split between rt.jar
	and localedata.jar
Message-ID: <20130911124112.88013626FE@hg.openjdk.java.net>

Changeset: 7bfe3da4fad6
Author:    naoto
Date:      2013-09-11 05:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bfe3da4fad6

8024332: sun/util/resources/en split between rt.jar and localedata.jar
Reviewed-by: alanb, erikj

! make/java/java/genlocales.gmk
! make/java/java/localegen.sh
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/java/util/FILES_properties.gmk
! make/sun/text/FILES_java.gmk
! make/sun/text/FILES_properties.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template



From eric.mccorkle at oracle.com  Wed Sep 11 13:25:06 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Wed, 11 Sep 2013 13:25:06 +0000
Subject: hg: jdk8/tl/jdk: 6962494: Update documentation on
	Executable.getParameterAnnotations()
Message-ID: <20130911132547.5191962701@hg.openjdk.java.net>

Changeset: c3ef78cd9081
Author:    emc
Date:      2013-09-11 09:24 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3ef78cd9081

6962494: Update documentation on Executable.getParameterAnnotations()
Summary: Update javadoc comments on getParameterAnnotations to correctly describe its behavior
Reviewed-by: darcy, jfranck

! src/share/classes/java/lang/reflect/Executable.java



From david.r.chase at oracle.com  Wed Sep 11 13:57:36 2013
From: david.r.chase at oracle.com (David Chase)
Date: Wed, 11 Sep 2013 09:57:36 -0400
Subject: RFR(S + new test) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: <64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
Message-ID: <09DC47D6-DBF4-40B9-9985-6EBEE96301D9@oracle.com>

[repeat]
new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
Same small changes to the sources, plus a test.

bug: wrong exception was thrown in call of methodhandle to private method

fix: detect special case of IllegalAccessException, convert to IllegalAccessError

testing:
verified that the test would pass with modified library
verified that the test would fail with old library
verified that the test would fail if the class substitution (for some reason) did not occur
jtreg of jdk/test/java/lang/invoke -- note that the new exception thrown is a subtype of the old one, so this is unlikely to create a new surprise




From Alan.Bateman at oracle.com  Wed Sep 11 14:05:51 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Sep 2013 15:05:51 +0100
Subject: Please review clarification of java.time serialized form
In-Reply-To: <522A27CF.3060607@oracle.com>
References: <522A27CF.3060607@oracle.com>
Message-ID: <523078BF.9050401@oracle.com>

On 06/09/2013 20:06, roger riggs wrote:
> :
>
> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-8024164/
> Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/
>
I looked through the webrev and sampled a few cases in the serialized 
form and it looks okay to me.

-Alan.


From michael.x.mcmahon at oracle.com  Wed Sep 11 14:03:41 2013
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Wed, 11 Sep 2013 14:03:41 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130911140529.8038862703@hg.openjdk.java.net>

Changeset: 1ec241501e60
Author:    michaelm
Date:      2013-09-11 15:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ec241501e60

8024601: Windows networking code prevents use of -Xlint:auxiliaryclass in jdk build
Reviewed-by: chegar

! src/share/classes/java/net/AbstractPlainSocketImpl.java
+ src/share/classes/java/net/InetAddressContainer.java

Changeset: 7dcb9d944910
Author:    michaelm
Date:      2013-09-11 15:02 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dcb9d944910

Merge




From Alan.Bateman at oracle.com  Wed Sep 11 14:36:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Sep 2013 15:36:16 +0100
Subject: RFR: 8024500: Missing API coverage for
	java.util.function.BiFunction andThen
In-Reply-To: 
References: <522FE7EE.902@oracle.com>
	
Message-ID: <52307FE0.4000604@oracle.com>

On 11/09/2013 06:03, Henry Jen wrote:
> Sorry I forgot it again. Copied but not pasted. :(
>
> http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/
>
> Thanks for reviewing.
>
A minor comment but you might want to double check 
SingletonIterator.java as it looks a bit misaligned (might be tabs, 
might be webrev).

-Alan.


From roger.riggs at oracle.com  Wed Sep 11 14:41:31 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Wed, 11 Sep 2013 14:41:31 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130911144215.1F3506270D@hg.openjdk.java.net>

Changeset: 292d93f32aa1
Author:    rriggs
Date:      2013-09-11 10:16 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/292d93f32aa1

8024164: JSR310 serialization should be described in details
Summary: The serialized-form.html should specify the stream format for interoperability
Reviewed-by: alanb

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Ser.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/HijrahEra.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/MinguoEra.java
! src/share/classes/java/time/chrono/Ser.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
! src/share/classes/java/time/zone/Ser.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRules.java
! test/java/time/tck/java/time/chrono/TCKChronologySerialization.java

Changeset: 8b4aef582087
Author:    rriggs
Date:      2013-09-11 10:35 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b4aef582087

Merge




From henry.jen at oracle.com  Wed Sep 11 15:31:03 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 11 Sep 2013 08:31:03 -0700
Subject: RFR: 8024500: Missing API coverage for
	java.util.function.BiFunction andThen
In-Reply-To: <6332204A-0851-4E65-A042-22C2796E23A5@oracle.com>
References: <522FE7EE.902@oracle.com>
	
	<6332204A-0851-4E65-A042-22C2796E23A5@oracle.com>
Message-ID: <75147FAF-B761-44A9-B013-03B07E4F07FE@oracle.com>

Thanks, it should be deliver. I'll fix before push it.

Cheers,
Henry

On Sep 10, 2013, at 10:19 PM, Mike Duigou  wrote:

> Tests look fine. 
> 
> In the BiFunction test the unknown word "delieve" is used. I am not sure what word was intended.
> 
> Mike
> 
> On Sep 10 2013, at 22:03 , Henry Jen wrote:
> 
>> Sorry I forgot it again. Copied but not pasted. :(
>> 
>> http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/
>> 
>> Thanks for reviewing.
>> 
>> Cheers,
>> Henry
>> 
>> On Sep 10, 2013, at 8:47 PM, Henry Jen  wrote:
>> 
>>> Hi,
>>> 
>>> Please review a simple webrev that adds two tests, one for
>>> 
>>> java.util.function.BiFunction.andThen() another to cover
>>> java.util.Collections.SingletonIterator.
>>> 
>>> Cheers,
>>> Henry
>> 
> 



From henry.jen at oracle.com  Wed Sep 11 15:31:50 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 11 Sep 2013 08:31:50 -0700
Subject: RFR: 8024500: Missing API coverage for
	java.util.function.BiFunction andThen
In-Reply-To: <52307FE0.4000604@oracle.com>
References: <522FE7EE.902@oracle.com>
	
	<52307FE0.4000604@oracle.com>
Message-ID: <484B2AED-7DBA-41C7-9AAF-65AF78B1DFE6@oracle.com>

Yes, the alignment is off, will fix.

Cheers,
Henry


On Sep 11, 2013, at 7:36 AM, Alan Bateman  wrote:

> On 11/09/2013 06:03, Henry Jen wrote:
>> Sorry I forgot it again. Copied but not pasted. :(
>> 
>> http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/
>> 
>> Thanks for reviewing.
>> 
> A minor comment but you might want to double check SingletonIterator.java as it looks a bit misaligned (might be tabs, might be webrev).
> 
> -Alan.



From sergey.kuksenko at oracle.com  Wed Sep 11 16:23:11 2013
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Wed, 11 Sep 2013 20:23:11 +0400
Subject: RFR: Direct LambdaMetaFactory invocation from CallSite significantly
	improves lambda linkage performance
Message-ID: <523098EF.1090508@oracle.com>

Please review the webrev at:

http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/

LambdaMetafactory is is a quite frequent bootstrap method for
invokedynamic in JDK8.
We can do direct method (LambdaMetafactory) invocation as fastpath when
proved that bootstrap MethodHandle points to LambdaMetafactory.
The modification gives +10% - +35% to lambda linkage performance
(depends on amount of lambdas).

-- 
Best regards,
Sergey Kuksenko


From sergey.kuksenko at oracle.com  Wed Sep 11 16:23:14 2013
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Wed, 11 Sep 2013 20:23:14 +0400
Subject: RFR: Caching MethodType's descriptor string improves lambda linkage
	performance
Message-ID: <523098F2.7010307@oracle.com>

Please review the webrev at:

http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/

MethodType.toMethodDescriptorString() is frequently invoked when
generating lambda classes from InnerClassLambdaMetafactory.
Caching resulting string into the field of MethodType  gives +5% - +10%
to lambda linkage performance.

Minor performance improvement: private method "checkPtype" was inlined
and eliminated. "checkRtype" and "checkPtypes" were refactored for
better perfomance in HotSpot interpreter (important for lambda linkage).
overall result +1%.


-- 
Best regards,
Sergey Kuksenko


From david.dehaven at oracle.com  Wed Sep 11 16:39:34 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 11 Sep 2013 09:39:34 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
	
	<522FB8E6.4020209@oracle.com>
	
Message-ID: 



> In my app, I have an export dialog where the user can select the file to export as well as choose some other export options. In that dialog, after the user has selected the file to export (via the file selection dialog), I display the full path to the file that was returned from the file selection Dialog. 
> 
> So, if I understand you correctly (sorry, I haven't had time to verify this myself), with this change, passing in "user.home/Documents" to the file dialog, the user will see "~/Documents" in the file dialog, but the full Container path will be returned as the selected file. So in my export dialog, the user would see the full Container path, even though the file selection dialog had shown a normal ~/Documents path?

If you're using FileDialog (or some variant that eventually boils down to NSSavePanel) then your app will continue to function properly. If you're using a custom dialog then you'll need to switch to FileDialog (or variant...) since NSSavePanel is what triggers powerbox to do it's thing, if NSSavePanel is not invoked to choose the exported file then your app will never be granted permission to write to the file (unless you incant some other, more complicated, voodoo magic).

The bottom line is, if what you have now allows you to write to ~/Documents and you're sandboxed then this change should not affect your application at all, except maybe in the UI if you're displaying that path to the user. The user won't notice the difference otherwise.


> Additionally what's not clear is (again, sorry, I haven't had time to verify this myself), if I do export the file to the Documents directory under the Container path, where does the file actually get saved? In /Users/nick/Documents or in /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the Container's Documents folder, for other applications (Finder, Excel, Preview, etc) will it be visible in /Users/nick/Documents ?

If you look in the app container you'll see that the Data directory returned by NSHomeDirectory() is set up with symlinks back to the users home directory, so when you access files in those directories you're accessing the correct files. IOW, ~/Library/Containers/com.blah.someapp/Data/Documents is the same as ~/Documents, the system does all this for you when the app container is created.


> @Brent - you wrote:
> "As it is now, apps needing to write app-specific data would need to special-case for the App Sandbox and go find the Container directory, since $HOME is not accessible (and only becomes accessible if the user interacts with a FileDialog)."
> 
> Well, I already had to special case where I write app-specific data for each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that is really cross-platform is going to have some platform specific code and platform specific jvm-launching/packaging, if they want to do things the recommended way for that platform. A sandboxed Mac version was just another special case.  For that, I use the AppBundler fork to launch the JVM and set some MAS specific properties so that I know that I'm running in the Mac sandbox and where the Container directory is. Then the right platform-specific initialization code in my app can be used to build the app-specific data in the right place.  

That's the unfortunately truth of modern (secure) applications, each platform has it's own way of doing things. Have you tried Windows 8 yet?

Changes like what Brent is proposing is helping to keep Java consistent with the ever evolving app model, which is ultimately a good thing.

-DrD-



From aleksey.shipilev at oracle.com  Wed Sep 11 16:39:36 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 11 Sep 2013 20:39:36 +0400
Subject: RFR: Direct LambdaMetaFactory invocation from CallSite
	significantly improves lambda linkage performance
In-Reply-To: <523098EF.1090508@oracle.com>
References: <523098EF.1090508@oracle.com>
Message-ID: <52309CC8.70805@oracle.com>

Seems like a good trick.

On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/

* webrev metadata: "invokation" -> "invocation"

* Why $caller is MethodHandles.Lookup now? Is it known to have that type?

* I would put the entire LMF.metafactory call inside the new method.
That way, instanceof checks are right before the (otherwise potentially
unsafe) casts.

> The modification gives +10% - +35% to lambda linkage performance
> (depends on amount of lambdas).

Any JSR292/Nashorn benchmarks to prove it does not degrade the "usual"
bootstrap scenarios? I understand most of the performance is dominated
by already-linked sites, but still.

-Aleksey.




From sergey.kuksenko at oracle.com  Wed Sep 11 16:53:56 2013
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Wed, 11 Sep 2013 20:53:56 +0400
Subject: RFR: Direct LambdaMetaFactory invocation from CallSite
	significantly improves lambda linkage performance
In-Reply-To: <52309CC8.70805@oracle.com>
References: <523098EF.1090508@oracle.com> <52309CC8.70805@oracle.com>
Message-ID: <5230A024.8080607@oracle.com>

> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
> 
> * webrev metadata: "invokation" -> "invocation"

misprint. Should I fix it right now, or may it be done later?

> * Why $caller is MethodHandles.Lookup now? Is it known to have that type?
Yes.
MethodHandles.Lookup is return type of IMPL_LOOKUP.in()


> * I would put the entire LMF.metafactory call inside the new method.
> That way, instanceof checks are right before the (otherwise potentially
> unsafe) casts.

At that case the single method should return two values: boolean flag
success/failure and CallSite.

>> The modification gives +10% - +35% to lambda linkage performance
>> (depends on amount of lambdas).
> 
> Any JSR292/Nashorn benchmarks to prove it does not degrade the "usual"
> bootstrap scenarios? I understand most of the performance is dominated
> by already-linked sites, but still.

I check it on octane - no perf difference. But I need somebody to
recheck my measurements.

-- 
Best regards,
Sergey Kuksenko


From aleksey.shipilev at oracle.com  Wed Sep 11 17:01:27 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 11 Sep 2013 21:01:27 +0400
Subject: RFR: Caching MethodType's descriptor string improves lambda
	linkage performance
In-Reply-To: <523098F2.7010307@oracle.com>
References: <523098F2.7010307@oracle.com>
Message-ID: <5230A1E7.7080703@oracle.com>

On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/

As much as I hate to see the hand code tweaking instead of relying on
compiler to do it's job, I understand this is about interpreter. Seems
good then.

* Formatting: "if(...)" should be "if (...")

* Formatting: "//NPE" should be "// null check"

* Formatting: "desc =  " should be "desc = "

* Formatting: this one should not use braces (for consistency with other
usages)?
 364         if(nptype == null) { //NPE
 365             throw new NullPointerException();
 366         }

* Explicit null-checks: implicits via .getClass and .equals always
bothered me in j.l.i.*; the idea was seemingly to piggyback on the
compiler intrinsics. Any idea what's the cost of using
Objects.requireNonNull there?

-Aleksey.


From aleksey.shipilev at oracle.com  Wed Sep 11 17:05:12 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 11 Sep 2013 21:05:12 +0400
Subject: RFR: Direct LambdaMetaFactory invocation from CallSite
	significantly improves lambda linkage performance
In-Reply-To: <5230A024.8080607@oracle.com>
References: <523098EF.1090508@oracle.com> <52309CC8.70805@oracle.com>
	<5230A024.8080607@oracle.com>
Message-ID: <5230A2C8.405@oracle.com>

On 09/11/2013 08:53 PM, Sergey Kuksenko wrote:
>> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
>>
>> * webrev metadata: "invokation" -> "invocation"
> misprint. Should I fix it right now, or may it be done later?

I think later is good. Don't propagate that typo into the final
changset, that what I meant.

>> * Why $caller is MethodHandles.Lookup now? Is it known to have that type?
> Yes.
> MethodHandles.Lookup is return type of IMPL_LOOKUP.in()

I see, OK then.

>> * I would put the entire LMF.metafactory call inside the new method.
>> That way, instanceof checks are right before the (otherwise potentially
>> unsafe) casts.
> 
> At that case the single method should return two values: boolean flag
> success/failure and CallSite.

Is "null" already reserved as the return value for metafactory? What
bothers me is that I need to scroll down to figure out the arguments are
indeed checked before you do the casts.

>>> The modification gives +10% - +35% to lambda linkage performance
>>> (depends on amount of lambdas).
>>
>> Any JSR292/Nashorn benchmarks to prove it does not degrade the "usual"
>> bootstrap scenarios? I understand most of the performance is dominated
>> by already-linked sites, but still.
> 
> I check it on octane - no perf difference. But I need somebody to
> recheck my measurements.

Good. That is good enough for me.

-Aleksey.




From xueming.shen at oracle.com  Wed Sep 11 17:30:00 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 11 Sep 2013 10:30:00 -0700
Subject: RFR: 8024338: Constant fields introduced by JDK-4759491 fix in b94
	are exposed as public fields in public API
Message-ID: <5230A898.80109@oracle.com>

Hi,

The background of this bug is the anti-pattern of defining constants in interfaces. In this case all the
constants defined in package private interface ZipConstants are being exposed as public fields of the
classes that implements it. This is JDK 1.0 era design/implementation, something we can't reverse any
more for compatibility concern. However it appears reasonable to not further add more new constants
into this interface class while it might be a logical place for them. The proposed change here is to move
these constants (all added in jdk8) to ZipConstants64.java, with comment add for why they are there,
so these constants will be kept as an implementation details.

http://cr.openjdk.java.net/~sherman/8024338/webrev

Thanks,
-Sherman


From martinrb at google.com  Wed Sep 11 17:37:21 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Sep 2013 10:37:21 -0700
Subject: RFR: 8024338: Constant fields introduced by JDK-4759491 fix in
	b94 are exposed as public fields in public API
In-Reply-To: <5230A898.80109@oracle.com>
References: <5230A898.80109@oracle.com>
Message-ID: 

Looks good to me!


On Wed, Sep 11, 2013 at 10:30 AM, Xueming Shen wrote:

> Hi,
>
> The background of this bug is the anti-pattern of defining constants in
> interfaces. In this case all the
> constants defined in package private interface ZipConstants are being
> exposed as public fields of the
> classes that implements it. This is JDK 1.0 era design/implementation,
> something we can't reverse any
> more for compatibility concern. However it appears reasonable to not
> further add more new constants
> into this interface class while it might be a logical place for them. The
> proposed change here is to move
> these constants (all added in jdk8) to ZipConstants64.java, with comment
> add for why they are there,
> so these constants will be kept as an implementation details.
>
> http://cr.openjdk.java.net/~**sherman/8024338/webrev
>
> Thanks,
> -Sherman
>


From aleksey.shipilev at oracle.com  Wed Sep 11 17:48:44 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 11 Sep 2013 21:48:44 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
Message-ID: <5230ACFC.9040801@oracle.com>

On 09/11/2013 12:58 AM, Brian Burkhalter wrote:
> Please review at your convenience.
> 
> Issue:		http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024356
> Webrev:		http://cr.openjdk.java.net/~bpb/8024356/

"MAX_NDIGITS = 1100"
 Stupid question. Why exactly this magic number?

-Aleksey.


From daniel.fuchs at oracle.com  Wed Sep 11 17:59:55 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 11 Sep 2013 19:59:55 +0200
Subject: RFR: 8024525 - Make Logger log methods call isLoggable()
Message-ID: <5230AF9B.2040404@oracle.com>

Hi,

Please find below a changeset for a small logging RFE:

8024525 - Make Logger log methods call isLoggable()



This change makes the various Logger logging method call isLoggable()
instead of simply inlining the checks.
This should make the life easier for subclasses of Logger which
want to control when messages should be logged.

The test is a bit obscure but it calls all the methods
that have been modified and checks that they log when isLoggable()
is true and don't log when isLoggable() is false.

best regards,

-- daniel


From sundararajan.athijegannathan at oracle.com  Wed Sep 11 18:05:42 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Wed, 11 Sep 2013 18:05:42 +0000
Subject: hg: jdk8/tl/nashorn: 6 new changesets
Message-ID: <20130911180549.ACF6962728@hg.openjdk.java.net>

Changeset: b6c7cd8b962b
Author:    jlaskey
Date:      2013-09-09 13:35 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b6c7cd8b962b

8024397: Nashorn FX Libraries need to be finalized.
Reviewed-by: sundar, hannesw, lagergren
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/resources/fx/base.js
! src/jdk/nashorn/internal/runtime/resources/fx/fxml.js
! src/jdk/nashorn/internal/runtime/resources/fx/graphics.js
! src/jdk/nashorn/internal/runtime/resources/fx/media.js
! src/jdk/nashorn/internal/runtime/resources/fx/swing.js
! src/jdk/nashorn/internal/runtime/resources/fx/swt.js
! src/jdk/nashorn/internal/runtime/resources/fx/web.js

Changeset: 483b42e56da4
Author:    jlaskey
Date:      2013-09-10 14:21 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/483b42e56da4

8024539: FX Libraries update missing file
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/resources/fx/controls.js

Changeset: badf750dda21
Author:    attila
Date:      2013-09-11 10:27 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/badf750dda21

8024130: We no longer need slots for temporaries in self-assign indices
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/codegen/Attr.java

Changeset: 2d4c8fa8a5f4
Author:    sundar
Date:      2013-09-11 20:49 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2d4c8fa8a5f4

8024615: Refactor ScriptObjectMirror and JSObject to support external JSObject implementations
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeFunction.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java
+ src/jdk/nashorn/internal/runtime/arrays/JSObjectIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJSObjectIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
+ test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java
! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java

Changeset: 66db7354e7e2
Author:    sundar
Date:      2013-09-11 22:51 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/66db7354e7e2

8024644: PluggableJSObject.iteratingJSObjectTest fails with jdk8-tl build
Reviewed-by: jlaskey, hannesw

! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java

Changeset: aa86166c6770
Author:    sundar
Date:      2013-09-11 22:53 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa86166c6770

Merge

- src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java



From joel.franck at oracle.com  Wed Sep 11 18:13:45 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Wed, 11 Sep 2013 20:13:45 +0200
Subject: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not
	return clone() for array type
In-Reply-To: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com>
References: <20130904135532.GC21307@jfranck-desktop.jrpg.bea.com>
Message-ID: <36573082-0D33-442D-9404-19691E36FF9E@oracle.com>

Thanks everyone for the reviews and suggestions for improvements.

cheers
/Joel

On Sep 4, 2013, at 3:55 PM, Joel Borggren-Franck  wrote:

> Hi,
> 
> Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375
> 
> Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/
> Specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html
> 
> There are two issues here,
> 
> - First a getInterfaces() call on an array Class instance does return
>  Cloneable and Serializable. This is specified for
>  getGenericInterfaces() but not specified in getInterface(). The fix is
>  to update the spec to match the implementation, which also aligns it
>  with getGenericInterfaces().
> 
> - Also even though JLS states that array types have an implementation of
>  clone() overriding the Object method, it is not included in
>  get{Declared}Method{s}. Again the fix is to note this in the spec.
> 
> Me and Alex have also worked on the structure of the docs trying to
> unify them and have a better flow. Rough outline is:
> 
> 
> 
> 
> 
> 
> cheers
> /Joel



From nick at transparentech.com  Fri Sep  6 21:17:16 2013
From: nick at transparentech.com (Nicholas Rahn)
Date: Fri, 6 Sep 2013 23:17:16 +0200
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
Message-ID: 

If you're saying that NSHomeDirectory is the correct behaviour for the Java
user.home property, then I have to disagree. On every other platform,
including non-sandboxed Mac, user.home is the actual user's home directory
(i.e. /home/ or /Users/ or C:\Users\). Setting user.home
to the *application's* home directory (which is what NSHomeDirectory
returns in a sandboxed environment) would seem to me to break the
definition of the user.home property.

On a mac, in a sandboxed and non-sandboxed environment, I would expect
user.home to be NSHomeDirectoryForUser. A sandboxed Java app definitely
needs to know about the app's Container directory (and even whether it's
actually being run sandboxed or not), but redefining user.home doesn't seem
like the right solution. Having AppBundler (or even the JRE) provide that
information via special properties feels better from my developer's
perspective.

Nick



On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven wrote:

>
> >> As someone with a Java app in the Mac App Store (MAS), I would like to
> vote against this change.
> >>
> >> It is still important to know the user's actual home directory
> (/Users/) even if the app is running in the sandbox.  Using the
> entitlement, com.apple.security.files.user-selected.read-write, we can
> still write to user selected directories (such as ~/Documents).  So
> changing the user.home property to point to somewhere in the app's
> Container would make it more difficult to get the actual home directory and
> thus, other directories that the end-user is familiar with. I also think
> this change would lead to more developer confusion and make application
> code more complicated.
> >>
> >> I don't know all what the user.home property is used for in the JDK
> itself, but concerns about the MAS sandbox would be, IMHO, better handled
> using special Mac/MAS only properties, such as those setup by
> infinitekind's Appbundler fork on bitbucket:
> https://bitbucket.org/infinitekind/appbundler
> >>
> >> Nick
> > I'm sure Brent wants to do the right thing here and maybe this needs
> some input from the Apple or other Mac-savvy folks as to whether sandboxed
> apps are really supposed to know about the actual user's home directory.
> >
> > FWIW, the original recommendaiton to switch to NSHomeDirectory came from
> Scott Kovatch when he was working on Application Bundler. It's very
> possible that things have changed since then.
>
>
> I haven't had a chance to look at the changes yet, so this may be a bit
> premature...
>
>
> Using NSHomeDirectory is the CORRECT behavior, whether the app is
> sandboxed or not (that extends to ALL apps, not just Java based).
>
> If the application needs to access Documents, Music, Movies, etc then
> those entitlements need to be added. Additionally, even if sandboxed an
> application can open documents in any folder the user has access to as long
> as the standard file chooser is used (which I believe we already do), the
> app will be granted (indirect) access to the selected file(s).
>
> -DrD-
>
>


From nick at transparentech.com  Tue Sep 10 21:21:36 2013
From: nick at transparentech.com (Nicholas Rahn)
Date: Tue, 10 Sep 2013 23:21:36 +0200
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
Message-ID: 

I use user.home to do things like:

String userHomePath = System.getProperty("user.home"**);
myFileDialog.setDirectory(**userHomePath + "/Documents");

In my app, the user selects where he wants to export individual files, such
as CSVs and PDFs. These are files he'll use outside of my app.

If user.home points to the app's sandbox Container, it will break this
usage.  Opening a file dialog to
/Users/Bob/Library/Containers/my.app/Data/Documents will definitely confuse
the user and if they save a file there, they will never be able to find it
later from outside of my app.

Yes, I understand the whole sandboxing concept. I'm not asking for
unrestricted access to the file system. I use the "com.apple.
security.files.user-selected.read-write" entitlement so that the user can
select where he wants to save files, and I want to present him with a
standard, well-known, default location for that (like ~/Documents).

If user.home doesn't point to the user's actual home folder (i.e.
NSHomeDirectoryForUser), it makes creating a standard, well-known location
path (like ~/Documents) much more difficult.  (And IMHO, it breaks the
definition of the user.home property: "User home directory", not "App home
directory".)

Nick



On Tue, Sep 10, 2013 at 10:32 PM, David DeHaven wrote:

>
> > This isn't every other platform, this is Mac OS X and all the baggage
> that goes along with it! :)
> >
> > What do you actually need access to user.home for? Do you have empirical
> evidence that this will break your application?
> >
> > The whole point of sandboxing is you no longer have direct access to the
> entire system. The app must play inside it's sandbox, period, end of story.
> Gone are the days of unrestricted access to the filesystem, that's the
> whole point of sandboxing! This is all pretty well outlined in the
> "Sandboxing Your App" documentation on ADC.
> >
> > Powerbox is there to solve your problem of opening user documents (with
> the right entitlements) and there are mechanisms in place to allow opening
> related files (with the users permission of course). Even a sandboxed
> application can show the user the contents of his various folders in a file
> open dialog. This all happens regardless of whether NSHomeDirectory returns
> /Users/JoeBob or /Users/JoeBob/Library/Containers/com.blah.someapp
>
>
> That should have been:
> /Users/JoeBob/Library/Containers/com.blah.someapp/Data
>
> Which, btw, is a shadow of the users home directory... including symlinks
> to various folders contained therein.
>
> -DrD-
>
>
>


From nick at transparentech.com  Wed Sep 11 13:50:08 2013
From: nick at transparentech.com (Nicholas Rahn)
Date: Wed, 11 Sep 2013 15:50:08 +0200
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: <522FB8E6.4020209@oracle.com>
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
	
	<522FB8E6.4020209@oracle.com>
Message-ID: 

In my app, I have an export dialog where the user can select the file to
export as well as choose some other export options. In that dialog, after
the user has selected the file to export (via the file selection dialog), I
display the full path to the file that was returned from the file selection
Dialog.

So, if I understand you correctly (sorry, I haven't had time to verify this
myself), with this change, passing in "user.home/Documents" to the file
dialog, the user will see "~/Documents" in the file dialog, but the full
Container path will be returned as the selected file. So in my export
dialog, the user would see the full Container path, even though the file
selection dialog had shown a normal ~/Documents path?

Additionally what's not clear is (again, sorry, I haven't had time to
verify this myself), if I do export the file to the Documents directory
under the Container path, where does the file actually get saved? In
/Users/nick/Documents or in
/Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the
Container's Documents folder, for other applications (Finder, Excel,
Preview, etc) will it be visible in /Users/nick/Documents ?

@Brent - you wrote:
"As it is now, apps needing to write app-specific data would need to
special-case for the App Sandbox and go find the Container directory, since
$HOME is not accessible (and only becomes accessible if the user interacts
with a FileDialog)."

Well, I already had to special case where I write app-specific data for
each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that
is really cross-platform is going to have some platform specific code and
platform specific jvm-launching/packaging, if they want to do things the
recommended way for that platform. A sandboxed Mac version was just another
special case.  For that, I use the AppBundler fork to launch the JVM and
set some MAS specific properties so that I know that I'm running in the Mac
sandbox and where the Container directory is. Then the right
platform-specific initialization code in my app can be used to build the
app-specific data in the right place.

Thanks,
Nick

On Wed, Sep 11, 2013 at 2:27 AM, Brent Christian  wrote:

> Adding a little to what Dave said, based on my understanding...
>
> On 9/10/13 3:36 PM, David DeHaven wrote:
>
> > Nicholas Rahn wrote:
>
>>
>>  In my app, the user selects where he wants to export individual
>>> files, such as CSVs and PDFs. These are files he'll use outside of
>>> my app.
>>>
>>> If user.home points to the app's sandbox Container, it will break
>>> this usage.  Opening a file dialog to
>>> /Users/Bob/Library/Containers/**my.app/Data/Documents will definitely
>>> confuse the user and if they save a file there, they will never be
>>> able to find it later from outside of my app.
>>>
>>
>> The user won't know the difference, all they'll see is ~/Documents as
>> provided by powerbox.
>>
>
> Note that PowerBox+NSOpenPanel recognize the Container path, and
> automagically take the user to their *actual* $HOME, Documents, etc
> directories.
>
> With this change, then, telling a native FileDialog to open user.home (or
> user.home/Documents, etc), will (still) show the user their real $HOME (or
> $HOME/Documents, etc) directory, whether sandboxed (user.home is the app
> Container, redirected by PowerBox to $HOME) or not (user.home=$HOME).
>
> The selected file returned from the FileDialog will point to a location
> within $HOME, and because of the *.files.user-selected.* entitlement, the
> app will now have access to it.
>
>
>  Yes, I understand the whole sandboxing concept. I'm not asking for
>>> unrestricted access to the file system. I use the
>>> "com.apple.security.files.**user-selected.read-write" entitlement so
>>> that the user can select where he wants to save files, and I want
>>> to present him with a standard, well-known, default location for
>>> that (like ~/Documents).
>>>
>>> If user.home doesn't point to the user's actual home folder (i.e.
>>> NSHomeDirectoryForUser), it makes creating a standard, well-known
>>> location path (like ~/Documents) much more difficult.
>>>
>>
> BTW, NSHomeDirectoryForUser() for the current user returns the same
> sandboxed value as NSHomeDirectory().
>
> Without this change, user.home is obtained using the POSIX getpwuid() call
> - really not the Apple-recommended way for dealing with the sandbox.
>
>
>  Powerbox solves exactly that problem... and yes, yes it is users home
>> folder, from the perspective of a sandboxed application!
>>
> >
> > ...
>
> >
>
>> the user will never see the app container path unless you
>> explicitly report it to them.
>>
>
> ...though it's really not mean to be presented to the user (and I haven't
> been able to convince FileDialog to take me to it).  The Container
> directory is meant only for files used by the app itself. From [1]:
>
> "The container is in a hidden location, and so users do not interact with
> it directly. Specifically, the container is not for user documents. It is
> for files that your app uses, along with databases, caches, and other
> app-specific data"
>
>
> The suggested change to the value of user.home means that it can be used
> by apps to write their own private data files AND (thanks to the PowerBox
> magic) point a user to their $HOME within a native file dialog, AND it will
> work inside or outside the App Sandbox.
>
> As it is now, apps needing to write app-specific data would need to
> special-case for the App Sandbox and go find the Container directory, since
> $HOME is not accessible (and only becomes accessible if the user interacts
> with a FileDialog).
>
> Thanks,
> -Brent
>
> [1] https://developer.apple.com/**library/mac/documentation/**
> security/conceptual/**AppSandboxDesignGuide/**AppSandboxInDepth/**
> AppSandboxInDepth.html#//**apple_ref/doc/uid/TP40011183-**CH3-SW15
>


From nick at transparentech.com  Wed Sep 11 18:09:56 2013
From: nick at transparentech.com (Nicholas Rahn)
Date: Wed, 11 Sep 2013 20:09:56 +0200
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
	
	<522FB8E6.4020209@oracle.com>
	
	
Message-ID: 

> > In my app, I have an export dialog where the user can select the file to
> export as well as choose some other export options. In that dialog, after
> the user has selected the file to export (via the file selection dialog), I
> display the full path to the file that was returned from the file selection
> Dialog.
> >
> > So, if I understand you correctly (sorry, I haven't had time to verify
> this myself), with this change, passing in "user.home/Documents" to the
> file dialog, the user will see "~/Documents" in the file dialog, but the
> full Container path will be returned as the selected file. So in my export
> dialog, the user would see the full Container path, even though the file
> selection dialog had shown a normal ~/Documents path?
>
> If you're using FileDialog (or some variant that eventually boils down to
> NSSavePanel) then your app will continue to function properly. If you're
> using a custom dialog then you'll need to switch to FileDialog (or
> variant...) since NSSavePanel is what triggers powerbox to do it's thing,
> if NSSavePanel is not invoked to choose the exported file then your app
> will never be granted permission to write to the file (unless you incant
> some other, more complicated, voodoo magic).
>
> The bottom line is, if what you have now allows you to write to
> ~/Documents and you're sandboxed then this change should not affect your
> application at all, except maybe in the UI if you're displaying that path
> to the user. The user won't notice the difference otherwise.
>
>
My users *will* notice because I display this path in the export dialog,
along with the other export options they can use.

Side note: I'm using SWT and it boils down to the NSOpenPanel and
NSSavePanel.


> > Additionally what's not clear is (again, sorry, I haven't had time to
> verify this myself), if I do export the file to the Documents directory
> under the Container path, where does the file actually get saved? In
> /Users/nick/Documents or in
> /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the
> Container's Documents folder, for other applications (Finder, Excel,
> Preview, etc) will it be visible in /Users/nick/Documents ?
>
> If you look in the app container you'll see that the Data directory
> returned by NSHomeDirectory() is set up with symlinks back to the users
> home directory, so when you access files in those directories you're
> accessing the correct files. IOW,
> ~/Library/Containers/com.blah.someapp/Data/Documents is the same as
> ~/Documents, the system does all this for you when the app container is
> created.
>
>
Actually, the Documents directory in the Container is NOT a symlink. It is
an actual directory.  So the 2 key questions are:

1. Is there a way to convert from
/Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to
~/Documents/somefile.csv to display in the UI for the user?

2. If the file gets saved to
/Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can
other applications (such as Excel) access the file from
~/Documents/somefile.csv ?


> > @Brent - you wrote:
> > "As it is now, apps needing to write app-specific data would need to
> special-case for the App Sandbox and go find the Container directory, since
> $HOME is not accessible (and only becomes accessible if the user interacts
> with a FileDialog)."
> >
> > Well, I already had to special case where I write app-specific data for
> each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that
> is really cross-platform is going to have some platform specific code and
> platform specific jvm-launching/packaging, if they want to do things the
> recommended way for that platform. A sandboxed Mac version was just another
> special case.  For that, I use the AppBundler fork to launch the JVM and
> set some MAS specific properties so that I know that I'm running in the Mac
> sandbox and where the Container directory is. Then the right
> platform-specific initialization code in my app can be used to build the
> app-specific data in the right place.
>
> That's the unfortunately truth of modern (secure) applications, each
> platform has it's own way of doing things. Have you tried Windows 8 yet?
>
> Changes like what Brent is proposing is helping to keep Java consistent
> with the ever evolving app model, which is ultimately a good thing.
>
>
Platform specific code for any Java desktop app is inevitable. What bothers
me about this proposed change is that you're taking away a useful property
(the user's $HOME) and replacing it with something that, to me, is best
done in an app's platform specific code, not in the JDK's. And I still need
to know the user's $HOME, since the answers to my 2 questions above are
probably 'no', so I'll have to add more to my app's Mac sandbox-specific
code to get it.

Windows 8: I do have a few people using my software on W8, but I have not
done anything specific for it. That is to say, I do the same platform
specific stuff as I do on W7.

Nick


From john.r.rose at oracle.com  Wed Sep 11 18:18:32 2013
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 11 Sep 2013 11:18:32 -0700
Subject: RFR: Direct LambdaMetaFactory invocation from CallSite
	significantly improves lambda linkage performance
In-Reply-To: <523098EF.1090508@oracle.com>
References: <523098EF.1090508@oracle.com>
Message-ID: 

Yes, this is a good tactic, but as written it is too much of a point hack for lambdas (important though they are).

I have an alternate solution I would like you to measure.  It provides a fast path for other BSM lookups like Nashorn's, so (if it works well for lambda) it is preferable.

I will attach a patch to the bug report.

? John

On Sep 11, 2013, at 9:23 AM, Sergey Kuksenko  wrote:

> Please review the webrev at:
> 
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
> 
> LambdaMetafactory is is a quite frequent bootstrap method for
> invokedynamic in JDK8.
> We can do direct method (LambdaMetafactory) invocation as fastpath when
> proved that bootstrap MethodHandle points to LambdaMetafactory.
> The modification gives +10% - +35% to lambda linkage performance
> (depends on amount of lambdas).
> 
> -- 
> Best regards,
> Sergey Kuksenko



From xueming.shen at oracle.com  Wed Sep 11 18:29:05 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 11 Sep 2013 18:29:05 +0000
Subject: hg: jdk8/tl/jdk: 8024338: Constant fields introduced by JDK-4759491
	fix in b94 are exposed as public fields in public API
Message-ID: <20130911182930.33DE56272A@hg.openjdk.java.net>

Changeset: 60b4cbdb446d
Author:    sherman
Date:      2013-09-11 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60b4cbdb446d

8024338: Constant fields introduced by JDK-4759491 fix in b94 are exposed as public fields in public API
Summary: to move the new constants out of ZipConstants.java
Reviewed-by: martin

! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipConstants64.java
! src/share/classes/java/util/zip/ZipEntry.java



From henry.jen at oracle.com  Wed Sep 11 18:46:32 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 11 Sep 2013 18:46:32 +0000
Subject: hg: jdk8/tl/jdk: 8024500: Missing API coverage for
	java.util.function.BiFunction andThen
Message-ID: <20130911184656.8E3266272B@hg.openjdk.java.net>

Changeset: 70aab3db56de
Author:    henryjen
Date:      2013-09-11 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70aab3db56de

8024500: Missing API coverage for java.util.function.BiFunction andThen
Reviewed-by: mduigou, alanb

+ test/java/util/Collections/SingletonIterator.java
+ test/java/util/function/BiFunction/BiFunctionTest.java



From sergey.kuksenko at oracle.com  Wed Sep 11 19:03:07 2013
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Wed, 11 Sep 2013 23:03:07 +0400
Subject: RFR: Caching MethodType's descriptor string improves lambda
	linkage performance
In-Reply-To: <5230A1E7.7080703@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
Message-ID: <5230BE6B.6090104@oracle.com>

On 09/11/2013 09:01 PM, Aleksey Shipilev wrote:
> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/
> 
> As much as I hate to see the hand code tweaking instead of relying on
> compiler to do it's job, I understand this is about interpreter. Seems
> good then.
> 
> * Formatting: "if(...)" should be "if (...")
Will do
> 
> * Formatting: "//NPE" should be "// null check"
I just preserve exiting comments.
Decided don't modify original code which is not important to required
functionality.

> 
> * Formatting: "desc =  " should be "desc = "
> 
> * Formatting: this one should not use braces (for consistency with other
> usages)?
>  364         if(nptype == null) { //NPE
>  365             throw new NullPointerException();
>  366         }
Let ask code owner.
> 
> * Explicit null-checks: implicits via .getClass and .equals always
> bothered me in j.l.i.*; the idea was seemingly to piggyback on the
> compiler intrinsics. 
anyway it is doesn't matter after C1/C2

> Any idea what's the cost of using
> Objects.requireNonNull there?
If we are running under the interpreter Objects.requireNonNull costs
enough to eliminate benefits from this fine tuning.

-- 
Best regards,
Sergey Kuksenko


From bhavesh.x.patel at oracle.com  Wed Sep 11 21:50:54 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Wed, 11 Sep 2013 21:50:54 +0000
Subject: hg: jdk8/tl/langtools: 8015496: Information that package is
	deprecated is missing in profiles view
Message-ID: <20130911215105.B8C1B62734@hg.openjdk.java.net>

Changeset: cf37c3775397
Author:    bpatel
Date:      2013-09-11 14:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf37c3775397

8015496: Information that package is deprecated is missing in profiles view
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java
+ test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt



From brent.christian at oracle.com  Wed Sep 11 22:07:17 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 11 Sep 2013 15:07:17 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
	
	<522FB8E6.4020209@oracle.com>
	
	
	
Message-ID: <5230E995.3090609@oracle.com>

On 9/11/13 11:09 AM, Nicholas Rahn wrote:
> On David DeHaven wrote:
 >
>> In my app, I have an export dialog where the user can select the
>> file to export as well as choose some other export options. In
>> that dialog, after the user has selected the file to export (via
>> the file selection dialog), I display the full path to the file
>> that was returned from the file selection Dialog.
>>
>> So, if I understand you correctly (sorry, I haven't had time to
>> verify this myself), with this change, passing in
>> "user.home/Documents" to the file dialog, the user will see
>> "~/Documents" in the file dialog, but the full Container path will
>> be returned as the selected file.

The user will see ~/Documents, and a selected file in ~/Documents will 
have a full path into ~/Documents.

The user is not meant to know anything about the sandbox container, and 
the file dialog enforces that.  If you point it to the Container path, 
it takes you to ~ instead, and from then on you're working within ~.

>> The bottom line is, if what you have now allows you to write to
>> ~/Documents and you're sandboxed then this change should not
>> affect your application at all, except maybe in the UI if you're
>> displaying that path to the user. The user won't notice the
>> difference otherwise.
>
> My users *will* notice because I display this path in the export dialog,
> along with the other export options they can use.

If the path displayed is coming from the selected file, then it will 
continue to show the correct path.

> Side note: I'm using SWT and it boils down to the NSOpenPanel and
> NSSavePanel.

Yep, that should work fine.

> Additionally what's not clear is (again, sorry, I haven't had time to
> verify this myself), if I do export the file to the Documents
> directory under the Container path, where does the file actually get
> saved? In /Users/nick/Documents or in
> /Users/nick/Library/Container/my.app/Data/Documents?

A path selected by the user using a file dialog will not point into the 
Container; you'd have to go out of your way to do this.

But if you did, say, write a file into
   /Users/nick/Library/Container/my.app/Data/Documents/
that's where it would get written.

> If it saves it to the Container's Documents folder, for other
> applications (Finder, Excel, Preview, etc) will it be visible in
> /Users/nick/Documents ?

No - as you point out, there's no symlink for Documents - they're 
different directories.

> The Documents directory in the Container is NOT a symlink. It
> is an actual directory.  So the 2 key questions are:
>
> 1. Is there a way to convert from
> /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to
> ~/Documents/somefile.csv to display in the UI for the user?

I haven't heard of anything special to help do that.  I don't imagine 
that's something that is expected to be needed.

> 2. If the file gets saved to
> /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can
> other applications (such as Excel) access the file from
> ~/Documents/somefile.csv ?

No, the container directory is hidden.  It would not be visible to the 
Finder or most other apps without some extra work on the part of the user.

Again, this is why files meant for user consumption shouldn't go into 
the container.

> What bothers me about this proposed change is that you're taking away
> a useful property (the user's $HOME) and replacing it with something
> that, to me, is best done in an app's platform specific code, not in
> the JDK's. And I still need to know the user's $HOME, since the
> answers to my 2 questions above are probably 'no', so I'll have to
> add more to my app's Mac sandbox-specific code to get it.

$HOME is not accessible to a sandboxed app, except through a file 
dialog, and the file dialog will still take you $HOME with the updated 
value of user.home.

Given how it all works, the usefulness of $HOME within the sandbox seems 
pretty low (reflected by the fact that Apple returns the Container path 
instead of $HOME when NSHomeDirectory is called within the sandbox).

Our aim here, of course, is to require *less* platform-specific code to 
do the right thing, in particular to minimize extra code needed to move 
an app to the App Sandbox by following Apple's recommendations re: 
NSHomeDirectory vs getpwuid().

Thanks,
-Brent


From david.dehaven at oracle.com  Wed Sep 11 22:11:51 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 11 Sep 2013 15:11:51 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: <5230E995.3090609@oracle.com>
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
	
	<522FB8E6.4020209@oracle.com>
	
	
	
	<5230E995.3090609@oracle.com>
Message-ID: <05F4A4A9-E77B-4D26-961F-BB972F44E95C@oracle.com>


>>> The bottom line is, if what you have now allows you to write to
>>> ~/Documents and you're sandboxed then this change should not
>>> affect your application at all, except maybe in the UI if you're
>>> displaying that path to the user. The user won't notice the
>>> difference otherwise.
>> 
>> My users *will* notice because I display this path in the export dialog,
>> along with the other export options they can use.
> 
> If the path displayed is coming from the selected file, then it will continue to show the correct path.

I don't think I was clear on that comment... if you're building the path from say System.getProperty("user.home") + "/Documents/blah" and showing it to the user, then that's a problem. If you're showing paths returned by the open/save panels then you're fine, the user will never see the container path.

-DrD-



From brent.christian at oracle.com  Thu Sep 12 00:13:54 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 11 Sep 2013 17:13:54 -0700
Subject: RFR: 8024009 : Remove jdk.map.useRandomSeed system property
Message-ID: <52310742.9070003@oracle.com>

Please review my fix to remove the jdk.map.useRandomSeed system property 
added earlier in jdk8.

Some history is in the bug report,
http://bugs.sun.com/view_bug.do?bug_id=8024009

HashMap and LinkedHashMap stopped using the random hash seed as of
8023463.  This change removes the code to read the jdk.map.useRandomSeed 
property and setup the hashSeed in Hashtable and WeakHashMap.

Hashtable got a couple extra things cleaned up:
* hash() calls were converted back to key.hashCode(), returning the code 
to its state prior to 7126277 (alternative String hashing).

* With the hashSeed gone, the 8000955 change [1] should no longer be 
necessary, and we can go back to using the key's hash value stored in 
Entry.hash instead of re-calculating it.

I also removed tests (or test @runs) which are now obsolete.

Automated build and test runs look good.


Webrev:
http://cr.openjdk.java.net/~bchristi/8024009/webrev.00/

Thanks,
-Brent

[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/5eed4a92ca8c


From mike.duigou at oracle.com  Thu Sep 12 00:33:55 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 11 Sep 2013 17:33:55 -0700
Subject: RFR: 8024009 : Remove jdk.map.useRandomSeed system property
In-Reply-To: <52310742.9070003@oracle.com>
References: <52310742.9070003@oracle.com>
Message-ID: <9878E41C-E06C-46AA-AE8A-D18141C5462F@oracle.com>

Hi Brent;

Thanks for cleaning this up. The changes look fine.

(A simplifying change in Collections, how unexpected!)

Mike

On Sep 11 2013, at 17:13 , Brent Christian wrote:

> Please review my fix to remove the jdk.map.useRandomSeed system property added earlier in jdk8.
> 
> Some history is in the bug report,
> http://bugs.sun.com/view_bug.do?bug_id=8024009
> 
> HashMap and LinkedHashMap stopped using the random hash seed as of
> 8023463.  This change removes the code to read the jdk.map.useRandomSeed property and setup the hashSeed in Hashtable and WeakHashMap.
> 
> Hashtable got a couple extra things cleaned up:
> * hash() calls were converted back to key.hashCode(), returning the code to its state prior to 7126277 (alternative String hashing).
> 
> * With the hashSeed gone, the 8000955 change [1] should no longer be necessary, and we can go back to using the key's hash value stored in Entry.hash instead of re-calculating it.
> 
> I also removed tests (or test @runs) which are now obsolete.
> 
> Automated build and test runs look good.
> 
> 
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8024009/webrev.00/
> 
> Thanks,
> -Brent
> 
> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/5eed4a92ca8c



From scolebourne at joda.org  Thu Sep 12 00:56:37 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 12 Sep 2013 01:56:37 +0100
Subject: Please review clarification of java.time serialized form
In-Reply-To: <522A27CF.3060607@oracle.com>
References: <522A27CF.3060607@oracle.com>
Message-ID: 

HijrahChronology mixes "final transient"  and "transient final". They
should be consistently one way or the other files should be checked,
and I think there is an official coding standard for this).

Some classes have had transient added, while others haven't. For
example LocalDate doesn't use transient. Since the instance fields are
never directly serialized, but do appear in the serialized form,
perhaps they should be marked as transient?

The byte code numbers for MinguoDate and ThaiBuddhistDate are now out
of line as you removed the ERA constants in Ser.

Otherwise looks like a good improvement.
Stephen



On 6 September 2013 20:06, roger riggs  wrote:
> The specification of the serialized-form[1] of the java.time classes has
> been
> improved in response to issue 8024164: JSR310 serialization should be
> described in detail
>
>  - Add descriptions in the Ser classes of the mapping between the type bytes
> and
>    corresponding serialized classes.
>  - Add missing specification of the serial data to writeReplace methods
>  - Add missing readResolve methods that prevent deserialization from
> improperly formatted streams.
>  - The Era that are Enum's do not need customized serialization;
>    remove unused writeReplace, writeExternal, and readExternal methods,
>    remove unused java.time.chrono.Ser type codes for *Eras and renumber.
>
> [1]:
> http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/serialized-form.html
>
> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-8024164/
> Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/
>
> Please review and comment.
> Thanks, Roger
>
>
>
>


From mike.duigou at oracle.com  Thu Sep 12 01:21:00 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 11 Sep 2013 18:21:00 -0700
Subject: Please review clarification of java.time serialized form
In-Reply-To: 
References: <522A27CF.3060607@oracle.com>
	
Message-ID: 


On Sep 11 2013, at 17:56 , Stephen Colebourne wrote:

> HijrahChronology mixes "final transient"  and "transient final". They
> should be consistently one way or the other files should be checked,
> and I think there is an official coding standard for this).

The resource I have been quoted for the "blessed modifier ordering" is:

http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Modifier.html#toString%28int%29

I know it's what Doug uses for JSR166 and there's been a general effort to make other usage consistent with this.

Mike



From mandy.chung at oracle.com  Thu Sep 12 05:06:17 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Sep 2013 22:06:17 -0700
Subject: RFR: 8024525 - Make Logger log methods call isLoggable()
In-Reply-To: <5230AF9B.2040404@oracle.com>
References: <5230AF9B.2040404@oracle.com>
Message-ID: <52314BC9.6020304@oracle.com>

On 9/11/2013 10:59 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a changeset for a small logging RFE:
>
> 8024525 - Make Logger log methods call isLoggable()
>
> 
>

Looks good.

> ...
> The test is a bit obscure but it calls all the methods
> that have been modified and checks that they log when isLoggable()
> is true and don't log when isLoggable() is false.
>

I only skimmed on the test which looks okay.

thanks
Mandy



From dmitry.nadezhin at gmail.com  Thu Sep 12 05:17:00 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Thu, 12 Sep 2013 09:17:00 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <5230ACFC.9040801@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
Message-ID: 

The short answer: because it is a backport to JDK 7 of part of this JDK 8
change:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017958.html

The long answer is the theory behind the change.
Java conversion from decimal string to double is specified as if it happens
in two steps:
1) Convert decimal string to mathematical real number exactly;
2) Round the real number to nearest Java double number. If real number is
in the middle between
   two adjacent Java double numbers then round to double with zero last bit.
The step between adjacent real numbers is called ULP (unit in the last
place or unit of least precision).
Each ULP segment between adjacent real numbers can be split in two half-ULP
segements.
All reals in each half-ULP segment are rounded to same Java double number.
So we can safely patch a long decimal string
when we sure that the real value of patched string lies in the same
half-ulp segment as the real value of the original string.

The above patch keeps first MAX_NDIGIT of long decimal string, discards
tail and repalces it by a single non-zero decimal digit ('1').
It is correct when the half of binary ULP of double number is a multiple of
the decimal ULP of truncated decimal string with MAX_NDIGITS kept.

When I prepared the patch I didn't try to find the optimal MAX_NDIGITS, but
I was sure that MAX_NDIGITS = 1100 is enough.
Here is an expanation:
1) If value of decimal string is larger than pow(10,309) then it is
converted to positive infinity before the test of nDigits;
2) If value of decimal string is smaller than pow(10,309) and larger than
pow(2,53) then it rounds to Java double with ulp >= 2.
   Half-ulp >= 1.
   The patch is correct when decimal ULP of kept digits is 1 or less. It is
true beacuse MAX_NDIGITS = 1100 > 309;
3) If value of decimal string is smaller than pow(2,53) but larger than
0.5*Doulle.MIN_VALUE = pow(2,-1022-52-1), than
   binary ULP is a multiple of pow(2,-1074).
   Half-ULP is a multiple of pow(2,-1075).
   The patch is correct when decimal ULP of kept digits is pow(10,-1075) of
less.
   pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100 > 1075 + 17 .
4) If value of decimal string is smaller than 0.5*Double.MIN_VALUE then it
is converted to zero before the test of nDigits.


You can treat replacement of 1075 + 17 by 1100 as my paranoia.
It still was interesting for me what is the optimal truncation of decimal
string.
I made an explration after the change was accepted to JDK 8, but I want to
postpone this refinement to JDK 9.

The exploration was accompanied by a formal proof.
I used ACL2 - both a programming language and a proof tool.
http://www.cs.utexas.edu/~moore/acl2/
It's language is Lisp-like.
Here you can find definitions and the proof:
http://cr.openjdk.java.net/~bpb/nDigits/acl2/
The snipped portion of this:
<<<<

; This function returns such "e" that all decimal digits below "e" can be
; be safely ignnored.
; Informally, 10^e must divide binary half-ulp

(defun find-exp (dec-exponent p q)
   (declare (xargs :guard (and (integerp dec-exponent)
                               (integerp p) (> p 1)
                               (integerp q) (> q 0))))
   (let* ((m (expt 10 (- dec-exponent 1)))
          (e (expo m)))
        (if (>= e p) 0 (- (ulp-e m p q) 1)))
)

<>

; Final theorem. All numbers in ( m*h, (m+1)*h ) rounds to the same
floating-point number
; if h = 10^(find-exp decexponent)

(defthmd ulp-rnd-rat-near-eq
  (implies (and (integerp p) (> p 1)
                (integerp q) (> q 0)
                (rationalp h) (> h 0)
                (integerp dec-exponent)
                (rationalp x)
                (<= (expt 10 (- dec-exponent 1)) x)
                (rationalp y)
                (<= (expt 10 (- dec-exponent 1)) y)
                (= h (expt 10 (find-exp dec-exponent p q)))
                (not (integerp (/ x h)))
                (not (integerp (/ y h)))
		(= (fl (/ x h)) (fl (/ y h))))
     (= (rnd-rat x 'near p q)
        (rnd-rat y 'near p q)))
  :hints (
    ("Goal" :in-theory (disable rnd-rat find-exp ulp))
    ("Goal'" :use (:instance ulp-rnd-rat-near+-h-find-exp (x x)))
    ("Goal''" :use (:instance ulp-rnd-rat-near+-h-find-exp (x y)))
   )
)

>>>>

A function find-exp is defined above in the snipplet.
It has three arguments:
find-exp(dec-exponent,p,q) .
p and q are parameters of floating-point format.
p is number of bits in significand, q is number of bits in exponent.
Java double: p = 53, q = 11 .
Java float: p = 24, q = 8.
dec-exponent specifies a range of real numbers with the same decimal
exponent:
pow(10,dec-exponent-1) <= x < pow(10,dec-exponent)
The function returns the position of lowest decimal digit to be kept.
The algorithm is "take m - minimal value of the range, and return binary
exponent of minimum of its binary half-ulp and 1".

The theorem says that
for any binary floating-point format with parameters p and q.
for any dec-exponent
for step h=pow(10, find-exp(dec-exponent,p,q))
for any pair of rational x and y withing dec-exponent range
and such that x and y are in the same open segment ( m*h, (m+1)*h )
we can state that x and y are rounded-to-nearest to the same floating-point
number.
The are also hint to the theorem prover how to search the proof.

We might want to explore find-exp graphicaly.
The plot of sufficient nDigits as function of dec-exponent is here:
http://cr.openjdk.java.net/~bpb/nDigits/java/double.pdf
and here:
http://cr.openjdk.java.net/~bpb/nDigits/java/float.pdf
You can see that 1100 for double is conservative but not optimal.
The optimal constant for double conversion could be 768 ,
the optimal constant for float conversion could be 142,
but I leave this optimization to JDK 9.








On Wed, Sep 11, 2013 at 9:48 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 09/11/2013 12:58 AM, Brian Burkhalter wrote:
> > Please review at your convenience.
> >
> > Issue:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024356
> > Webrev:               http://cr.openjdk.java.net/~bpb/8024356/
>
> "MAX_NDIGITS = 1100"
>  Stupid question. Why exactly this magic number?
>
> -Aleksey.
>


From ivan.gerasimov at oracle.com  Thu Sep 12 05:59:52 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 12 Sep 2013 09:59:52 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: 
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
Message-ID: <52315858.3050006@oracle.com>

Hello Alan, Martin, everyone!

Some update on the issue.
When trying to integrate my test into Basic.java, I found that it 
already contains exactly the same.
I have just overlooked it before.

Additional investigation showed that inheritIO() doesn't always fail on 
Windows.
If the scenario is like following:
- java application creates a child java process (no IO inheritance, 
redirecting IO through pipes by default),
- child process creates a grandchild which inherits the child's 
stdin/out/err,
everything works as expected.

However, if the java app (started from a console) creates an immediate 
child that inherits its parent stdin/out/err, it fails.

That's why this bug hasn't been caught by Basic.java before - because it 
uses the first testing scenario.
And that's why I had to introduce a new shell script test - because the 
problem couldn't be reproduced otherwise.

Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ 


The proposed fix remained the same.
I only created a new shell script that reuses Basic.java functionality.
I also made a minor change to Basic.java to include testing of 
ProcessBuilder#redirectXXX(Redirect.INHERIT) method calls.

I manually tested the fixed jdk to check that we haven't reintroduced 
4244515 bug with this fix.
As Martin said, unfortunately there is no automated test for windowed 
apps behavior.

Sincerely yours,
Ivan Gerasimov


On 26.08.2013 3:31, Martin Buchholz wrote:
> Historical notes:
>
> I maintained this code for a while, but I've never been a "Windows" 
> guy, and I rarely sat at an actual Windows machine console.  I don't 
> know of any test infrastructure for windowed apps.
>
>
> On Fri, Aug 23, 2013 at 9:11 AM, Ivan Gerasimov 
> > wrote:
>
>     Thank you Alan!
>
>
>     On 23.08.2013 14:28, Alan Bateman wrote:
>
>         On 23/08/2013 04:07, Ivan Gerasimov wrote:
>
>             Hello everybody!
>
>             The method ProcessBuilder#inheritIO() is reported to not
>             have any effect on Windows platform.
>             The same story is with
>             redirectOutput/Input/Error(Redirect.INHERIT) methods.
>             As the result, standard in/out/err aren't inherited.
>
>             It turn out that the culprit is the CREATE_NO_WINDOW flag
>             passed to CreateProcessW().
>             MS doc says about this flag: "The process is a console
>             application that is being run without a console window."
>
>             CREATE_NO_WINDOW flag was added with the fix for
>             http://bugs.sun.com/view_bug.do?bug_id=4244515 to suppress
>             a console window on a newly created process, when it is
>             created from a program launched with javaw.exe.
>             Thus, I left this flag only for cases when the program
>             doesn't have a console associated with it.
>
>             Would you please help review a fix for this problem?
>
>             BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8023130
>             WEBREV:
>             http://cr.openjdk.java.net/~igerasim/8023130/0/webrev/
>             
>
>         Good sleuthing!
>
>         Just so I understand, if we have a console (DOS command window
>         for example) then will dropping CREATE_NO_WINDOW result in a
>         new window or not?
>
>     No new console for a console application without CREATE_NO_WINDOW
>     flag.
>     I used a sample program to confirm that:
>     ---------------
>     class InheritIO {
>         public static void main(String[] args) throws Exception {
>             int err = new
>     ProcessBuilder(args).inheritIO().redirectErrorStream(true).start().waitFor();
>             System.err.println("Exit value: " + err);
>         }
>     }
>     ---------------
>     With the proposed fix running it as '> java InheritIO cmd /?'
>     copies the output of the command to the existing console.
>     No new console is created.
>
>
>         One thing that it does highlight is that the coverage for
>         inherit in ProcessBuilder/Basic.java was not sufficient as
>         this should have been caught a long time ago. My preference
>         would be to add to this test rather than introduce a new one
>         (ProcessBuilder.java is Martin's original mother-of-all tests
>         for ProcessBuilder).
>
>     Yes, I agree. It would be better to integrate this test into
>     Basic.java.
>
>     Sincerely yours,
>     Ivan
>
>         -Alan.
>
>
>
>



From Alan.Bateman at oracle.com  Thu Sep 12 08:09:26 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Sep 2013 09:09:26 +0100
Subject: RFR: 8024009 : Remove jdk.map.useRandomSeed system property
In-Reply-To: <52310742.9070003@oracle.com>
References: <52310742.9070003@oracle.com>
Message-ID: <523176B6.1020001@oracle.com>

On 12/09/2013 01:13, Brent Christian wrote:
> Please review my fix to remove the jdk.map.useRandomSeed system 
> property added earlier in jdk8.
It's good to see this going away, the changes (and clean-up) look good 
to me too.

-Alan


From shanliang.jiang at oracle.com  Thu Sep 12 07:41:56 2013
From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com)
Date: Thu, 12 Sep 2013 07:41:56 +0000
Subject: hg: jdk8/tl/jdk: 8023529: OpenMBeanInfoSupport.equals/hashCode throw
	NPE
Message-ID: <20130912074211.8C4CB62746@hg.openjdk.java.net>

Changeset: e407df8093dc
Author:    sjiang
Date:      2013-09-12 09:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e407df8093dc

8023529: OpenMBeanInfoSupport.equals/hashCode throw NPE
Reviewed-by: dholmes, dfuchs

! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java
+ test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
+ test/javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java



From Alan.Bateman at oracle.com  Thu Sep 12 08:40:39 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Sep 2013 09:40:39 +0100
Subject: RFR: 8024525 - Make Logger log methods call isLoggable()
In-Reply-To: <5230AF9B.2040404@oracle.com>
References: <5230AF9B.2040404@oracle.com>
Message-ID: <52317E07.2040201@oracle.com>

On 11/09/2013 18:59, Daniel Fuchs wrote:
> Hi,
>
> Please find below a changeset for a small logging RFE:
>
> 8024525 - Make Logger log methods call isLoggable()
>
> 
>
> This change makes the various Logger logging method call isLoggable()
> instead of simply inlining the checks.
> This should make the life easier for subclasses of Logger which
> want to control when messages should be logged.
>
> The test is a bit obscure but it calls all the methods
> that have been modified and checks that they log when isLoggable()
> is true and don't log when isLoggable() is false.
The update to Logger looks okay to me.

I think the test could benefit from a comment to more fully explain why 
it checks that isLoggable has been called (as you say, the test is a bit 
obscure). A minor comment is that "levels" should probably be in 
uppercase. Also I assume the commented-out debug message in publish 
isn't needed.

-Alan.


From joe.darcy at oracle.com  Thu Sep 12 08:47:32 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 12 Sep 2013 08:47:32 +0000
Subject: hg: jdk8/tl/jdk: 8024643: Turn on javac lint checking in building the
	jdk repo
Message-ID: <20130912084746.1C41C6274A@hg.openjdk.java.net>

Changeset: 262a625809fd
Author:    darcy
Date:      2013-09-12 01:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/262a625809fd

8024643: Turn on javac lint checking in building the jdk repo
Reviewed-by: erikj, ihse, smarks

! makefiles/Setup.gmk



From david.r.chase at oracle.com  Thu Sep 12 11:57:27 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 07:57:27 -0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
Message-ID: <88234218-0F9C-4FD9-9151-613D28BCEF24@oracle.com>

This explanation seems to combine numbers of binary digits (1075)
and numbers of decimal digits (17), and therefore makes me a little
nervous, though I think 1100 is a conservative choice that, even if not
100% correct, will be 99.(over 700 9s)% correct.

David

On 2013-09-12, at 1:17 AM, Dmitry Nadezhin  wrote:
> When I prepared the patch I didn't try to find the optimal MAX_NDIGITS, but
> I was sure that MAX_NDIGITS = 1100 is enough.
> Here is an expanation:
> 1) If value of decimal string is larger than pow(10,309) then it is
> converted to positive infinity before the test of nDigits;
> 2) If value of decimal string is smaller than pow(10,309) and larger than
> pow(2,53) then it rounds to Java double with ulp >= 2.
>   Half-ulp >= 1.
>   The patch is correct when decimal ULP of kept digits is 1 or less. It is
> true beacuse MAX_NDIGITS = 1100 > 309;
> 3) If value of decimal string is smaller than pow(2,53) but larger than
> 0.5*Doulle.MIN_VALUE = pow(2,-1022-52-1), than
>   binary ULP is a multiple of pow(2,-1074).
>   Half-ULP is a multiple of pow(2,-1075).
>   The patch is correct when decimal ULP of kept digits is pow(10,-1075) of
> less.
>   pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100 > 1075 + 17 .
> 4) If value of decimal string is smaller than 0.5*Double.MIN_VALUE then it
> is converted to zero before the test of nDigits.
> 
> 
> You can treat replacement of 1075 + 17 by 1100 as my paranoia.
> It still was interesting for me what is the optimal truncation of decimal
> string.

From dmitry.nadezhin at gmail.com  Thu Sep 12 12:18:06 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Thu, 12 Sep 2013 16:18:06 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <88234218-0F9C-4FD9-9151-613D28BCEF24@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	<88234218-0F9C-4FD9-9151-613D28BCEF24@oracle.com>
Message-ID: 

The reason while binary and decimal digits are mixed can be ullustrated by
such example.
It is necessary 3 decimal fraction digits to represent exactly pbinary
power pow(2,-3) :
pow(2,-3)=1/8=0.125


On Thu, Sep 12, 2013 at 3:57 PM, David Chase wrote:

> This explanation seems to combine numbers of binary digits (1075)
> and numbers of decimal digits (17), and therefore makes me a little
> nervous, though I think 1100 is a conservative choice that, even if not
> 100% correct, will be 99.(over 700 9s)% correct.
>
> David
>
> On 2013-09-12, at 1:17 AM, Dmitry Nadezhin 
> wrote:
> > When I prepared the patch I didn't try to find the optimal MAX_NDIGITS,
> but
> > I was sure that MAX_NDIGITS = 1100 is enough.
> > Here is an expanation:
> > 1) If value of decimal string is larger than pow(10,309) then it is
> > converted to positive infinity before the test of nDigits;
> > 2) If value of decimal string is smaller than pow(10,309) and larger than
> > pow(2,53) then it rounds to Java double with ulp >= 2.
> >   Half-ulp >= 1.
> >   The patch is correct when decimal ULP of kept digits is 1 or less. It
> is
> > true beacuse MAX_NDIGITS = 1100 > 309;
> > 3) If value of decimal string is smaller than pow(2,53) but larger than
> > 0.5*Doulle.MIN_VALUE = pow(2,-1022-52-1), than
> >   binary ULP is a multiple of pow(2,-1074).
> >   Half-ULP is a multiple of pow(2,-1075).
> >   The patch is correct when decimal ULP of kept digits is pow(10,-1075)
> of
> > less.
> >   pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100 > 1075 +
> 17 .
> > 4) If value of decimal string is smaller than 0.5*Double.MIN_VALUE then
> it
> > is converted to zero before the test of nDigits.
> >
> >
> > You can treat replacement of 1075 + 17 by 1100 as my paranoia.
> > It still was interesting for me what is the optimal truncation of decimal
> > string.
>


From daniel.fuchs at oracle.com  Thu Sep 12 13:36:26 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 12 Sep 2013 15:36:26 +0200
Subject: RFR: 8024525 - Make Logger log methods call isLoggable()
In-Reply-To: <52317E07.2040201@oracle.com>
References: <5230AF9B.2040404@oracle.com> <52317E07.2040201@oracle.com>
Message-ID: <5231C35A.1030405@oracle.com>

Hi,

New changeset incorporating Alan's feedback:



How/why the test works should now appear more clearly :-)

-- daniel



On 9/12/13 10:40 AM, Alan Bateman wrote:
> On 11/09/2013 18:59, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a changeset for a small logging RFE:
>>
>> 8024525 - Make Logger log methods call isLoggable()
>>
>> 
>>
>> This change makes the various Logger logging method call isLoggable()
>> instead of simply inlining the checks.
>> This should make the life easier for subclasses of Logger which
>> want to control when messages should be logged.
>>
>> The test is a bit obscure but it calls all the methods
>> that have been modified and checks that they log when isLoggable()
>> is true and don't log when isLoggable() is false.
> The update to Logger looks okay to me.
>
> I think the test could benefit from a comment to more fully explain why
> it checks that isLoggable has been called (as you say, the test is a bit
> obscure). A minor comment is that "levels" should probably be in
> uppercase. Also I assume the commented-out debug message in publish
> isn't needed.
>
> -Alan.



From joel.franck at oracle.com  Thu Sep 12 13:37:17 2013
From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=)
Date: Thu, 12 Sep 2013 15:37:17 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
Message-ID: <20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>

Hi again,

New webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.01/

Thanks to Remi and Peter for the quick feedback, I've updated the code
to use for-each as well as fixing getMethod(...).

Andreas Lundblad also added ~100 testcases for getMethod(), both
positive and negative.

Please review

cheers
/Joel

On 2013-09-09, Joel Borggr?n-Franck wrote:
> Hi
> 
> Pleaser review fix for 8009411 : getMethods should not inherit static methods from interfaces 
> 
> The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). Webrev is based on the clarification to getMethods and friends out for review on this list.
> 
> Webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.00/
> Bug is here: http://bugs.sun.com/view_bug.do?bug_id=8009411
> 
> For oracle reviewers, ccc is approved.
> 
> cheers
> /Joel


From roger.riggs at oracle.com  Thu Sep 12 13:49:30 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 12 Sep 2013 09:49:30 -0400
Subject: Please review clarification of java.time serialized form
In-Reply-To: 
References: <522A27CF.3060607@oracle.com>
	
Message-ID: <5231C66A.3070204@oracle.com>

Hi Stephen,

On 9/11/2013 8:56 PM, Stephen Colebourne wrote:
> HijrahChronology mixes "final transient"  and "transient final". They
> should be consistently one way or the other files should be checked,
> and I think there is an official coding standard for this).
Yes, will fix in a future update.
>
> Some classes have had transient added, while others haven't. For
> example LocalDate doesn't use transient. Since the instance fields are
> never directly serialized, but do appear in the serialized form,
> perhaps they should be marked as transient?
Marking as transient will make them disappear from the serialized form.
The comments on the individual fields seemed useful to document the data
in the stream and they were kept when the writeReplace method documented
writing them to the stream.    In other cases the writeReplace method refers
to the  method that returned the value instead of a field.

>
> The byte code numbers for MinguoDate and ThaiBuddhistDate are now out
> of line as you removed the ERA constants in Ser.
How should that be fixed, restore the gaps or re-order?

Thanks, Roger

> Otherwise looks like a good improvement.
> Stephen
>
>
>
> On 6 September 2013 20:06, roger riggs  wrote:
>> The specification of the serialized-form[1] of the java.time classes has
>> been
>> improved in response to issue 8024164: JSR310 serialization should be
>> described in detail
>>
>>   - Add descriptions in the Ser classes of the mapping between the type bytes
>> and
>>     corresponding serialized classes.
>>   - Add missing specification of the serial data to writeReplace methods
>>   - Add missing readResolve methods that prevent deserialization from
>> improperly formatted streams.
>>   - The Era that are Enum's do not need customized serialization;
>>     remove unused writeReplace, writeExternal, and readExternal methods,
>>     remove unused java.time.chrono.Ser type codes for *Eras and renumber.
>>
>> [1]:
>> http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/serialized-form.html
>>
>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-8024164/
>> Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/
>>
>> Please review and comment.
>> Thanks, Roger
>>
>>
>>
>>



From Alan.Bateman at oracle.com  Thu Sep 12 13:55:03 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Sep 2013 14:55:03 +0100
Subject: RFR: 8024525 - Make Logger log methods call isLoggable()
In-Reply-To: <5231C35A.1030405@oracle.com>
References: <5230AF9B.2040404@oracle.com> <52317E07.2040201@oracle.com>
	<5231C35A.1030405@oracle.com>
Message-ID: <5231C7B7.3020107@oracle.com>

On 12/09/2013 14:36, Daniel Fuchs wrote:
> Hi,
>
> New changeset incorporating Alan's feedback:
>
> 
>
> How/why the test works should now appear more clearly :-)
>
> -- daniel
Thanks for that. I guess I would have used javadoc comments for some of 
these but it's otherwise okay with me.

-Alan


From roger.riggs at oracle.com  Thu Sep 12 14:14:18 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 12 Sep 2013 10:14:18 -0400
Subject: Please review: fix for java.time Issues with French locale on
	compact1, 2
Message-ID: <5231CC3A.1010805@oracle.com>

Hi,

Testing of java.time has found a problematic test on compact 1 and 2.
The test relies on localization data for the French locale that is not 
present.
Changing the tests to the US locale would be sufficient but then are 
redundant
with other tests.  The tests are unnecessary and are removed.

Please review:
    http://cr.openjdk.java.net/~rriggs/webrev-nofrench-8024618/

Thanks, Roger



From scolebourne at joda.org  Thu Sep 12 14:16:49 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 12 Sep 2013 15:16:49 +0100
Subject: Please review clarification of java.time serialized form
In-Reply-To: <5231C66A.3070204@oracle.com>
References: <522A27CF.3060607@oracle.com>
	
	<5231C66A.3070204@oracle.com>
Message-ID: 

On 12 September 2013 14:49, roger riggs  wrote:
>> Some classes have had transient added, while others haven't. For
>> example LocalDate doesn't use transient. Since the instance fields are
>> never directly serialized, but do appear in the serialized form,
>> perhaps they should be marked as transient?
>
> Marking as transient will make them disappear from the serialized form.
> The comments on the individual fields seemed useful to document the data
> in the stream and they were kept when the writeReplace method documented
> writing them to the stream.    In other cases the writeReplace method refers
> to the  method that returned the value instead of a field.

Most consistent would be to always refer to the get method. The
comment is useful as is, but sometimes you get a byte in one place and
a short in another for example (LocalDate) which might be confusing.


>> The byte code numbers for MinguoDate and ThaiBuddhistDate are now out
>> of line as you removed the ERA constants in Ser.
>
> How should that be fixed, restore the gaps or re-order?

At this stage, the docs should be updated and the Ser constants kept packed.

Stephen


From scolebourne at joda.org  Thu Sep 12 14:17:51 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 12 Sep 2013 15:17:51 +0100
Subject: Please review: fix for java.time Issues with French locale on
	compact1, 2
In-Reply-To: <5231CC3A.1010805@oracle.com>
References: <5231CC3A.1010805@oracle.com>
Message-ID: 

I'd be more comfortable with them moving to the non-TCK area. But if
they have to be deleted, so be it.
Stephen

On 12 September 2013 15:14, roger riggs  wrote:
> Hi,
>
> Testing of java.time has found a problematic test on compact 1 and 2.
> The test relies on localization data for the French locale that is not
> present.
> Changing the tests to the US locale would be sufficient but then are
> redundant
> with other tests.  The tests are unnecessary and are removed.
>
> Please review:
>    http://cr.openjdk.java.net/~rriggs/webrev-nofrench-8024618/
>
> Thanks, Roger
>


From Alan.Bateman at oracle.com  Thu Sep 12 14:32:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Sep 2013 15:32:36 +0100
Subject: Please review: fix for java.time Issues with French locale on
	compact1, 2
In-Reply-To: <5231CC3A.1010805@oracle.com>
References: <5231CC3A.1010805@oracle.com>
Message-ID: <5231D084.8000807@oracle.com>

On 12/09/2013 15:14, roger riggs wrote:
> Hi,
>
> Testing of java.time has found a problematic test on compact 1 and 2.
> The test relies on localization data for the French locale that is not 
> present.
> Changing the tests to the US locale would be sufficient but then are 
> redundant
> with other tests.  The tests are unnecessary and are removed.
>
> Please review:
>    http://cr.openjdk.java.net/~rriggs/webrev-nofrench-8024618/
>
> Thanks, Roger
TCK tests can't depend on optional locales so the change looks okay to me.

In general however, there are several tests that uses FR and other 
locales. I wasn't aware that we are testing without localedata.jar being 
present. I hope not as it would require more yucky lists in TEST.groups.

-Alan


From aleksey.shipilev at oracle.com  Thu Sep 12 14:32:46 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 12 Sep 2013 18:32:46 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
Message-ID: <5231D08E.3040309@oracle.com>

On 09/12/2013 09:17 AM, Dmitry Nadezhin wrote:
> The patch is correct when decimal ULP of kept digits is pow(10,-1075)
> of less. pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100
> > 1075 + 17 .

OK. That makes more sense. Can we please add the short comment in the
code (maybe next time around)?

I expected to see something like "The value below is chosen as the
conservative threshold. We can demonstrate () that decimal ulp
should be less than 10^(-1075) to guarantee correctness; we also
compensate for binary mantissa which takes 53 binary digits, or 17
decimal ones. Hence, 1075+17 =~ 1100."

-Aleksey.


From david.r.chase at oracle.com  Thu Sep 12 14:37:46 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 10:37:46 -0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	<88234218-0F9C-4FD9-9151-613D28BCEF24@oracle.com>
	
Message-ID: <009028AD-FCE8-4D7B-830D-99BA80D2B83F@oracle.com>


On 2013-09-12, at 8:18 AM, Dmitry Nadezhin  wrote:

> The reason while binary and decimal digits are mixed can be ullustrated by
> such example.
> It is necessary 3 decimal fraction digits to represent exactly pbinary
> power pow(2,-3) :
> pow(2,-3)=1/8=0.125
> 
> 
> On Thu, Sep 12, 2013 at 3:57 PM, David Chase wrote:
> 
>> This explanation seems to combine numbers of binary digits (1075)
>> and numbers of decimal digits (17), and therefore makes me a little
>> nervous, though I think 1100 is a conservative choice that, even if not
>> 100% correct, will be 99.(over 700 9s)% correct.
>> 
>> David

Yes, but you are adding them.  It is as if you took two lengths, 1075 feet and 17 yards, added them, rounded up, and said that 1100 yards will be adequate (which is entirely true, though perhaps overconservative).  Overconservative is okay.

2^-1075 is the binary ulp, give or take a fencepost, not the decimal ulp.

David


From Lance.Andersen at oracle.com  Thu Sep 12 14:45:20 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 12 Sep 2013 10:45:20 -0400
Subject: Review request for 8014967: Clarify NPE thrown by
	DriverManager.registerDriver when driver is null
Message-ID: 

Looking for a reviewer for this trivial change to clarify the long outstanding behavior of registererDriver:


$ hg diff DriverManager.java 
diff -r 262a625809fd src/share/classes/java/sql/DriverManager.java
--- a/src/share/classes/java/sql/DriverManager.java	Thu Sep 12 01:47:05 2013 -0700
+++ b/src/share/classes/java/sql/DriverManager.java	Thu Sep 12 10:35:48 2013 -0400
@@ -326,6 +326,7 @@
      * @param driver the new JDBC Driver that is to be registered with the
      *               {@code DriverManager}
      * @exception SQLException if a database access error occurs
+     * @exception NullPointerException if {@code driver} is null
      */
     public static synchronized void registerDriver(java.sql.Driver driver)
         throws SQLException {
@@ -345,6 +346,7 @@
      * @param da     the {@code DriverAction} implementation to be used when
      *               {@code DriverManager#deregisterDriver} is called
      * @exception SQLException if a database access error occurs
+     * @exception NullPointerException if {@code driver} is null
      */
     public static synchronized void registerDriver(java.sql.Driver driver,
             DriverAction da)


registerDriver has thrown this NPE since the early days of DriverManager (1997) so it was requested that we clarify this.

Alan,  could you please confirm whether I need a CCC given this behavior has been there since JDBC 1.0 and this just adds the @exception and there is no behavior change.

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From roger.riggs at oracle.com  Thu Sep 12 14:57:59 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 12 Sep 2013 10:57:59 -0400
Subject: Please review: fix for java.time Issues with French locale on
	compact1, 2
In-Reply-To: <5231D084.8000807@oracle.com>
References: <5231CC3A.1010805@oracle.com> <5231D084.8000807@oracle.com>
Message-ID: <5231D677.1010109@oracle.com>

Hi Alan,

For conformance tests, the configurations are more limited  (Only the US 
locale).
The other java.time tests that refer to specific locales don't rely on 
the locale data
only the identity of the locale or depend on the fallback to the US locale.
Otherwise a wider refactoring would be needed and still the configurations
needed for unit testing would need to be more fine grained.

Thanks, Roger

On 9/12/2013 10:32 AM, Alan Bateman wrote:
> On 12/09/2013 15:14, roger riggs wrote:
>> Hi,
>>
>> Testing of java.time has found a problematic test on compact 1 and 2.
>> The test relies on localization data for the French locale that is 
>> not present.
>> Changing the tests to the US locale would be sufficient but then are 
>> redundant
>> with other tests.  The tests are unnecessary and are removed.
>>
>> Please review:
>>    http://cr.openjdk.java.net/~rriggs/webrev-nofrench-8024618/
>>
>> Thanks, Roger
> TCK tests can't depend on optional locales so the change looks okay to 
> me.
>
> In general however, there are several tests that uses FR and other 
> locales. I wasn't aware that we are testing without localedata.jar 
> being present. I hope not as it would require more yucky lists in 
> TEST.groups.
>
> -Alan



From peter.levart at gmail.com  Thu Sep 12 14:59:21 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Sep 2013 16:59:21 +0200
Subject: static vs. default interface methods and inheritance VM/javac issues
Message-ID: <5231D6C9.806@gmail.com>

Hi,

While testing behavior of reflection on default and static interface 
methods, using self-built JDK from latest tip of jdk8/tl, I found:

The following program:

public class DefaultVsStaticInterfaceMethodTest {
     public interface A {
         default void m() {
             System.out.println("A.m() called");
         }
     }

     public interface B {
         static void m() {
             System.out.println("B.m() called");
         }
     }

     public interface C extends A, B {
     }

     public static void main(String[] args) throws Exception {
         C c = new C() {};
         c.m();
     }
}


...compiles, but gives a runtime error:

Exception in thread "main" java.lang.AbstractMethodError: Conflicting 
default methods: DefaultVsStaticInterfaceMethodTest$A.m 
DefaultVsStaticInterfaceMethodTest$B.m
     at 
DefaultVsStaticInterfaceMethodTest$1.m(DefaultVsStaticInterfaceMethodTest.java)
     at 
DefaultVsStaticInterfaceMethodTest.main(DefaultVsStaticInterfaceMethodTest.java:28)


A slightly modified program: "C extends A, B" replaced with "C extends 
B, A":

http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/DefaultVsStaticInterfaceMethodTest.java

...also compiles, but crashes the VM when run:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fd4d5020bf9, pid=9964, tid=140552419804928
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 
1.8.0-internal-peter_2013_09_12_16_29-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b48 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# j  DefaultVsStaticInterfaceMethodTest.main([Ljava/lang/String;)V+9
#
# Failed to write core dump. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/peter/work/git/jdk8-tl/out/production/test/hs_err_pid9964.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
Aborted (core dumped)


Here's the hs_err_pid file:

http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/hs_err_pid9964.log



Regards, Peter



From Alan.Bateman at oracle.com  Thu Sep 12 15:21:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Sep 2013 16:21:50 +0100
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <52315858.3050006@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com>
Message-ID: <5231DC0E.4080106@oracle.com>

On 12/09/2013 06:59, Ivan Gerasimov wrote:
> Hello Alan, Martin, everyone!
>
> Some update on the issue.
> When trying to integrate my test into Basic.java, I found that it 
> already contains exactly the same.
> I have just overlooked it before.
>
> Additional investigation showed that inheritIO() doesn't always fail 
> on Windows.
> If the scenario is like following:
> - java application creates a child java process (no IO inheritance, 
> redirecting IO through pipes by default),
> - child process creates a grandchild which inherits the child's 
> stdin/out/err,
> everything works as expected.
>
> However, if the java app (started from a console) creates an immediate 
> child that inherits its parent stdin/out/err, it fails.
>
> That's why this bug hasn't been caught by Basic.java before - because 
> it uses the first testing scenario.
> And that's why I had to introduce a new shell script test - because 
> the problem couldn't be reproduced otherwise.
>
> Would you please review the updated webrev?
> http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ 
> 
>
>
Based on the previous mails then the update to ProcessImpl_md.c seems 
right. It's probably best to give this one some bake time in jdk8 before 
you backport it to jdk7u-dev. The reason is that the Process code likes 
to bite back when it is changed.

On the tests then you probably know we don't like shell tests because 
they are usually slower and statistically more troublesome. Given the 
scenario that you are trying to test (and it's useful that you've got to 
the bottom of the issue) there they may not be other options here. One 
small concern with the shell test as it stands is that it looks like it 
is depend on the exact output. This makes me wonder about how it will 
behave with a debug or fastdebug build that might have additional 
output. Also a minor point but it might be more readable if the body of 
the for statement was indented.

-Alan.


From Lance.Andersen at oracle.com  Thu Sep 12 15:21:56 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 12 Sep 2013 11:21:56 -0400
Subject: review request: 8015340:  remove erroneous @since tag
Message-ID: <6A997C98-ADE1-48C0-8A1F-B57EA91B212D@oracle.com>

Looking for a reviewer for this trivial fix:


 hg diff PreparedStatement.java 
diff -r 262a625809fd src/share/classes/java/sql/PreparedStatement.java
--- a/src/share/classes/java/sql/PreparedStatement.java	Thu Sep 12 01:47:05 2013 -0700
+++ b/src/share/classes/java/sql/PreparedStatement.java	Thu Sep 12 11:18:13 2013 -0400
@@ -954,7 +954,6 @@
      * the JDBC driver does not support this data type
      * @see Types
      *
-     * @since 1.6
      */
     void setObject(int parameterIndex, Object x, int targetSqlType, int scaleOrLength)
             throws SQLException;



This method dates back to JDBC 1.0.  Looks like when the javadocs were updated for JDBC 4.0, the IEC team accidentally added the @since 1.6. 

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From Alan.Bateman at oracle.com  Thu Sep 12 15:32:14 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Sep 2013 16:32:14 +0100
Subject: Review request for 8014967: Clarify NPE thrown by
	DriverManager.registerDriver when driver is null
In-Reply-To: 
References: 
Message-ID: <5231DE7E.6010005@oracle.com>

On 12/09/2013 15:45, Lance Andersen - Oracle wrote:
> :
>
>
> registerDriver has thrown this NPE since the early days of DriverManager (1997) so it was requested that we clarify this.
>
> Alan,  could you please confirm whether I need a CCC given this behavior has been there since JDBC 1.0 and this just adds the @exception and there is no behavior change.
>
The changes looks okay to me and just specifying long standing behavior. 
As it's adding an assertion to the spec then I think it should be tracked.

-Alan


From daniel.fuchs at oracle.com  Thu Sep 12 15:31:00 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Thu, 12 Sep 2013 15:31:00 +0000
Subject: hg: jdk8/tl/jdk: 8024525: Make Logger log methods call isLoggable()
Message-ID: <20130912153131.4636262769@hg.openjdk.java.net>

Changeset: 631c8dcd91f4
Author:    dfuchs
Date:      2013-09-12 17:01 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/631c8dcd91f4

8024525: Make Logger log methods call isLoggable()
Summary: This changeset makes the various Logger logging method call isLoggable() instead of inlining the level checks.
Reviewed-by: mchung, alanb

! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/Logger/isLoggable/TestIsLoggable.java



From joe.darcy at oracle.com  Thu Sep 12 16:10:49 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 12 Sep 2013 09:10:49 -0700
Subject: review request: 8015340:  remove erroneous @since tag
In-Reply-To: <6A997C98-ADE1-48C0-8A1F-B57EA91B212D@oracle.com>
References: <6A997C98-ADE1-48C0-8A1F-B57EA91B212D@oracle.com>
Message-ID: <5231E789.2070302@oracle.com>

Look fine Lance; cheers,

-Joe

On 09/12/2013 08:21 AM, Lance Andersen - Oracle wrote:
> Looking for a reviewer for this trivial fix:
>
>
>   hg diff PreparedStatement.java
> diff -r 262a625809fd src/share/classes/java/sql/PreparedStatement.java
> --- a/src/share/classes/java/sql/PreparedStatement.java	Thu Sep 12 01:47:05 2013 -0700
> +++ b/src/share/classes/java/sql/PreparedStatement.java	Thu Sep 12 11:18:13 2013 -0400
> @@ -954,7 +954,6 @@
>        * the JDBC driver does not support this data type
>        * @see Types
>        *
> -     * @since 1.6
>        */
>       void setObject(int parameterIndex, Object x, int targetSqlType, int scaleOrLength)
>               throws SQLException;
>
>
>
> This method dates back to JDBC 1.0.  Looks like when the javadocs were updated for JDBC 4.0, the IEC team accidentally added the @since 1.6.
>
> Best
> Lance
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From roger.riggs at oracle.com  Thu Sep 12 16:19:46 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Thu, 12 Sep 2013 16:19:46 +0000
Subject: hg: jdk8/tl/jdk: 8024618: Issues with French locale on compact1,
	2: expected: but was:
Message-ID: <20130912162020.78E956276C@hg.openjdk.java.net>

Changeset: 672f349fbad7
Author:    rriggs
Date:      2013-09-12 10:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/672f349fbad7

8024618: Issues with French locale on compact1,2: expected: but was:
Summary: Tests against the data of the French locale are not valid as conformance tests and are redundant with testing of the US Locale above
Reviewed-by: alanb

! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java



From david.r.chase at oracle.com  Thu Sep 12 16:32:17 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 12:32:17 -0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <009028AD-FCE8-4D7B-830D-99BA80D2B83F@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	<88234218-0F9C-4FD9-9151-613D28BCEF24@oracle.com>
	
	<009028AD-FCE8-4D7B-830D-99BA80D2B83F@oracle.com>
Message-ID: <9886A7E1-559B-4F96-AE0D-CC108BC9AD58@oracle.com>

I think the reason you use 1075 digits is because it takes 1075 decimal digits behind the decimal point to exactly represent 2^-1075,
and that is 1/2 ulp.  When you discard the tail, if it happens to be all zeroes, I hope you replace it with a zero, not a one, because otherwise you can round incorrectly if the answer is otherwise equal to EVEN + 1/2 ULP.  EVEN + 1/2 ULP rounds to EVEN, EVEN + 1/2 ULP + "1" rounds to EVEN + 1.

Whoops, no, you don't do that.  But I'd call that another bug, and not one worth getting terribly excited about.  Strictly speaking, if your input is decimal_rep_of_half_ulp + a billion zeroes + "1", then the answer is 1 ulp (2^-1074), if the trailing one is missing, then the answer is zero (which is even in the mantissa).

David

On 2013-09-12, at 10:37 AM, David Chase  wrote:
> On 2013-09-12, at 8:18 AM, Dmitry Nadezhin  wrote:
> 
>> The reason while binary and decimal digits are mixed can be ullustrated by
>> such example.
>> It is necessary 3 decimal fraction digits to represent exactly pbinary
>> power pow(2,-3) :
>> pow(2,-3)=1/8=0.125
>> 
>> 
>> On Thu, Sep 12, 2013 at 3:57 PM, David Chase wrote:
>> 
>>> This explanation seems to combine numbers of binary digits (1075)
>>> and numbers of decimal digits (17), and therefore makes me a little
>>> nervous, though I think 1100 is a conservative choice that, even if not
>>> 100% correct, will be 99.(over 700 9s)% correct.
>>> 
>>> David
> 
> Yes, but you are adding them.  It is as if you took two lengths, 1075 feet and 17 yards, added them, rounded up, and said that 1100 yards will be adequate (which is entirely true, though perhaps overconservative).  Overconservative is okay.
> 
> 2^-1075 is the binary ulp, give or take a fencepost, not the decimal ulp.
> 
> David
> 


From david.r.chase at oracle.com  Thu Sep 12 16:50:58 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 12:50:58 -0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <9886A7E1-559B-4F96-AE0D-CC108BC9AD58@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	<88234218-0F9C-4FD9-9151-613D28BCEF24@oracle.com>
	
	<009028AD-FCE8-4D7B-830D-99BA80D2B83F@oracle.com>
	<9886A7E1-559B-4F96-AE0D-CC108BC9AD58@oracle.com>
Message-ID: 

Never mind, this is in the context of FloatingDecimal and any trailing zeroes are properly discarded.
Carry on, this code looks correct, despite my misunderstanding the explanation.

David

On 2013-09-12, at 12:32 PM, David Chase  wrote:

> I think the reason you use 1075 digits is because it takes 1075 decimal digits behind the decimal point to exactly represent 2^-1075,
> and that is 1/2 ulp.  When you discard the tail, if it happens to be all zeroes, I hope you replace it with a zero, not a one, because otherwise you can round incorrectly if the answer is otherwise equal to EVEN + 1/2 ULP.  EVEN + 1/2 ULP rounds to EVEN, EVEN + 1/2 ULP + "1" rounds to EVEN + 1.
> 
> Whoops, no, you don't do that.  But I'd call that another bug, and not one worth getting terribly excited about.  Strictly speaking, if your input is decimal_rep_of_half_ulp + a billion zeroes + "1", then the answer is 1 ulp (2^-1074), if the trailing one is missing, then the answer is zero (which is even in the mantissa).
> 
> David
> 
> On 2013-09-12, at 10:37 AM, David Chase  wrote:
>> On 2013-09-12, at 8:18 AM, Dmitry Nadezhin  wrote:
>> 
>>> The reason while binary and decimal digits are mixed can be ullustrated by
>>> such example.
>>> It is necessary 3 decimal fraction digits to represent exactly pbinary
>>> power pow(2,-3) :
>>> pow(2,-3)=1/8=0.125
>>> 
>>> 
>>> On Thu, Sep 12, 2013 at 3:57 PM, David Chase wrote:
>>> 
>>>> This explanation seems to combine numbers of binary digits (1075)
>>>> and numbers of decimal digits (17), and therefore makes me a little
>>>> nervous, though I think 1100 is a conservative choice that, even if not
>>>> 100% correct, will be 99.(over 700 9s)% correct.
>>>> 
>>>> David
>> 
>> Yes, but you are adding them.  It is as if you took two lengths, 1075 feet and 17 yards, added them, rounded up, and said that 1100 yards will be adequate (which is entirely true, though perhaps overconservative).  Overconservative is okay.
>> 
>> 2^-1075 is the binary ulp, give or take a fencepost, not the decimal ulp.
>> 
>> David
>> 
> 



From lance.andersen at oracle.com  Thu Sep 12 17:21:06 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Thu, 12 Sep 2013 17:21:06 +0000
Subject: hg: jdk8/tl/jdk: 8015340: remove erroneous @since tag
Message-ID: <20130912172120.2783962773@hg.openjdk.java.net>

Changeset: 60d6f60416ca
Author:    lancea
Date:      2013-09-12 13:20 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60d6f60416ca

8015340: remove erroneous @since tag
Reviewed-by: darcy

! src/share/classes/java/sql/PreparedStatement.java



From christian.thalinger at oracle.com  Thu Sep 12 17:24:16 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 12 Sep 2013 10:24:16 -0700
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
Message-ID: 

+             // err.initCause(ex);

Why is this commented?

-- Chris

On Sep 6, 2013, at 4:59 PM, David Chase  wrote:

> new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
> Same small changes to the sources, plus a test.
> 
> bug: wrong exception was thrown in call of methodhandle to private method
> 
> fix: detect special case of IllegalAccessException, convert to IllegalAccessError
> 
> testing:
> verified that the test would pass with modified library
> verified that the test would fail with old library
> verified that the test would fail if the class substitution (for some reason) did not occur
> jtreg of jdk/test/java/lang/invoke -- note that the new exception thrown is a subtype of the old one, so this is unlikely to create a new surprise
> 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From david.r.chase at oracle.com  Thu Sep 12 17:53:11 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 13:53:11 -0400
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
Message-ID: <49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>

I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).

On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:

> +             // err.initCause(ex);
> 
> Why is this commented?
> 
> -- Chris
> 
> On Sep 6, 2013, at 4:59 PM, David Chase  wrote:
> 
>> new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
>> Same small changes to the sources, plus a test.
>> 
>> bug: wrong exception was thrown in call of methodhandle to private method
>> 
>> fix: detect special case of IllegalAccessException, convert to IllegalAccessError
>> 
>> testing:
>> verified that the test would pass with modified library
>> verified that the test would fail with old library
>> verified that the test would fail if the class substitution (for some reason) did not occur
>> jtreg of jdk/test/java/lang/invoke -- note that the new exception thrown is a subtype of the old one, so this is unlikely to create a new surprise
>> 
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 



From dmitry.nadezhin at gmail.com  Thu Sep 12 18:10:35 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Thu, 12 Sep 2013 22:10:35 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <5231D08E.3040309@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	<5231D08E.3040309@oracle.com>
Message-ID: 

Aleksey, I like your wording of the comment. Thank you very much.

I would reformulate a little:
<<<
We can demonstrate () that decimal ulp should be less than 10^(-1075)
to guarantee correctness
===
We can demonstrate () that decimal ulp less than 10^(-1075) is enough
to guarantee correctness.
>>
because decimal ulp may be larger than 10^(-1075) for some inputs.
For example, for decimal string
"1.1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111"

binary half-ulp is 2^(-53)
and decimal ulp 10^(-53) is enough .



On Thu, Sep 12, 2013 at 6:32 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 09/12/2013 09:17 AM, Dmitry Nadezhin wrote:
> > The patch is correct when decimal ULP of kept digits is pow(10,-1075)
> > of less. pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100
> > > 1075 + 17 .
>
> OK. That makes more sense. Can we please add the short comment in the
> code (maybe next time around)?
>
> I expected to see something like "The value below is chosen as the
> conservative threshold. We can demonstrate () that decimal ulp
> should be less than 10^(-1075) to guarantee correctness; we also
> compensate for binary mantissa which takes 53 binary digits, or 17
> decimal ones. Hence, 1075+17 =~ 1100."
>
> -Aleksey.
>


From karen.kinnear at oracle.com  Thu Sep 12 18:23:22 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 12 Sep 2013 14:23:22 -0400
Subject: static vs. default interface methods and inheritance VM/javac
	issues
In-Reply-To: <5231D6C9.806@gmail.com>
References: <5231D6C9.806@gmail.com>
Message-ID: <7B094410-1F13-488C-A8B9-3B4321F31A0B@oracle.com>

Thank you, we really appreciate all testing.

I have a fix in a prototype in the vm for this. Let me know if you want an early patch. 
Or you can just file a bug and that way you'll know when the fix is officially in the tree.

thanks,
Karen

On Sep 12, 2013, at 10:59 AM, Peter Levart wrote:

> Hi,
> 
> While testing behavior of reflection on default and static interface methods, using self-built JDK from latest tip of jdk8/tl, I found:
> 
> The following program:
> 
> public class DefaultVsStaticInterfaceMethodTest {
>     public interface A {
>         default void m() {
>             System.out.println("A.m() called");
>         }
>     }
> 
>     public interface B {
>         static void m() {
>             System.out.println("B.m() called");
>         }
>     }
> 
>     public interface C extends A, B {
>     }
> 
>     public static void main(String[] args) throws Exception {
>         C c = new C() {};
>         c.m();
>     }
> }
> 
> 
> ...compiles, but gives a runtime error:
> 
> Exception in thread "main" java.lang.AbstractMethodError: Conflicting default methods: DefaultVsStaticInterfaceMethodTest$A.m DefaultVsStaticInterfaceMethodTest$B.m
>     at DefaultVsStaticInterfaceMethodTest$1.m(DefaultVsStaticInterfaceMethodTest.java)
>     at DefaultVsStaticInterfaceMethodTest.main(DefaultVsStaticInterfaceMethodTest.java:28)
> 
> 
> A slightly modified program: "C extends A, B" replaced with "C extends B, A":
> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/DefaultVsStaticInterfaceMethodTest.java
> 
> ...also compiles, but crashes the VM when run:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007fd4d5020bf9, pid=9964, tid=140552419804928
> #
> # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-peter_2013_09_12_16_29-b00)
> # Java VM: OpenJDK 64-Bit Server VM (25.0-b48 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # j  DefaultVsStaticInterfaceMethodTest.main([Ljava/lang/String;)V+9
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /home/peter/work/git/jdk8-tl/out/production/test/hs_err_pid9964.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.sun.com/bugreport/crash.jsp
> #
> Aborted (core dumped)
> 
> 
> Here's the hs_err_pid file:
> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/hs_err_pid9964.log
>  
> 
> 
> Regards, Peter
> 



From david.r.chase at oracle.com  Thu Sep 12 18:28:38 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 14:28:38 -0400
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: <49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
Message-ID: <2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>

New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/

On 2013-09-12, at 1:53 PM, David Chase  wrote:

> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
> 
> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
> 
>> +             // err.initCause(ex);
>> 
>> Why is this commented?
>> 
>> -- Chris


From staffan.larsen at oracle.com  Thu Sep 12 18:30:42 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 12 Sep 2013 21:30:42 +0300
Subject: RFR: 8014659: NPG: performance counters for compressed klass space
In-Reply-To: <20130910155657.GA12910@ehelin-thinkpad>
References: <20130910155657.GA12910@ehelin-thinkpad>
Message-ID: 

Looks good (I'll take your word that the nasty awk scripts are correct...).

I think you should have included serviceability-dev on this review request.

/Staffan


On 10 sep 2013, at 18:56, Erik Helin  wrote:

> Hi all,
> 
> this is the JDK part of the fix for 8014659 [0]. I've added the output
> of the compressed class space performance counters next to the metaspace
> output. I've also updated the jstat and jstatd tests to take the new
> output into account.
> 
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> 
> Testing:
> - jdk/test/sun/tools/jstat
> - jdk/test/sun/tools/jstatd
> 
> Thanks,
> Erik
> 
> [0]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659



From brian.burkhalter at oracle.com  Thu Sep 12 18:32:55 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Sep 2013 11:32:55 -0700
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	<5231D08E.3040309@oracle.com>
	
Message-ID: 

What should be put in for ?

Thanks,

Brian

On Sep 12, 2013, at 11:10 AM, Dmitry Nadezhin wrote:

> Aleksey, I like your wording of the comment. Thank you very much.
> 
> I would reformulate a little:
> <<<
> We can demonstrate () that decimal ulp should be less than 10^(-1075)
> to guarantee correctness
> ===
> We can demonstrate () that decimal ulp less than 10^(-1075) is enough
> to guarantee correctness.
>>> 
> because decimal ulp may be larger than 10^(-1075) for some inputs.
> For example, for decimal string
> "1.1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111"
> 
> binary half-ulp is 2^(-53)
> and decimal ulp 10^(-53) is enough .



From christian.thalinger at oracle.com  Thu Sep 12 18:34:12 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 12 Sep 2013 11:34:12 -0700
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: <2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
Message-ID: <6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>


On Sep 12, 2013, at 11:28 AM, David Chase  wrote:

> New webrev, commented line removed:
> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/

I think the change is good given that the tests work now.  Is your test derived from the test in the bug report?

And it would be good if John could also have a quick look (just be to be sure).

-- Chris

> 
> On 2013-09-12, at 1:53 PM, David Chase  wrote:
> 
>> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
>> 
>> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
>> 
>>> +             // err.initCause(ex);
>>> 
>>> Why is this commented?
>>> 
>>> -- Chris
> 



From eric.mccorkle at oracle.com  Thu Sep 12 18:53:25 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 12 Sep 2013 18:53:25 +0000
Subject: hg: jdk8/tl/langtools: 8013846: javac fails to reject semantically
	equivalent generic method declarations
Message-ID: <20130912185328.60D716277E@hg.openjdk.java.net>

Changeset: 5d2d484a1216
Author:    emc
Date:      2013-09-12 14:52 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5d2d484a1216

8013846: javac fails to reject semantically equivalent generic method declarations
Summary: Cause javac to consider intersection types with the same elements to be equal regardless of order.
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/neg/OrderedIntersections.java
+ test/tools/javac/generics/neg/OrderedIntersections.out



From dmitry.nadezhin at gmail.com  Thu Sep 12 18:57:55 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Thu, 12 Sep 2013 22:57:55 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	<5231D08E.3040309@oracle.com>
	
	
Message-ID: 

JDK repository constains sources and tests now.
Where should proofs live ?
And also where should benchmarks live ?


On Thu, Sep 12, 2013 at 10:32 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> What should be put in for ?
>
> Thanks,
>
> Brian
>
> On Sep 12, 2013, at 11:10 AM, Dmitry Nadezhin wrote:
>
> Aleksey, I like your wording of the comment. Thank you very much.
>
> I would reformulate a little:
> <<<
> We can demonstrate () that decimal ulp should be less than 10^(-1075)
> to guarantee correctness
> ===
> We can demonstrate () that decimal ulp less than 10^(-1075) is enough
> to guarantee correctness.
>
>
> because decimal ulp may be larger than 10^(-1075) for some inputs.
> For example, for decimal string
>
> "1.1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111"
>
> binary half-ulp is 2^(-53)
> and decimal ulp 10^(-53) is enough .
>
>
>


From david.r.chase at oracle.com  Thu Sep 12 19:17:24 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 15:17:24 -0400
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: <6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
Message-ID: 

The test is adapted from the test in the bug report.
The headline on the bug report is wrong -- because it uses reflection in the test to do the invocation,
the thrown exception is wrapped with InvocationTargetException, which is completely correct.
HOWEVER, the exception inside the wrapper is the wrong one.

The new test checks the exception in both the reflective-invocation and plain-invocation cases,
and also checks both a method handle call (which threw the wrong exception) and a plain
call (which threw, and throws, the right exception).

The test also uses a tweaked classloader to substitute the borked bytecodes necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.

On 2013-09-12, at 2:34 PM, Christian Thalinger  wrote:

> 
> On Sep 12, 2013, at 11:28 AM, David Chase  wrote:
> 
>> New webrev, commented line removed:
>> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
> 
> I think the change is good given that the tests work now.  Is your test derived from the test in the bug report?
> 
> And it would be good if John could also have a quick look (just be to be sure).
> 
> -- Chris
> 
>> 
>> On 2013-09-12, at 1:53 PM, David Chase  wrote:
>> 
>>> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
>>> 
>>> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
>>> 
>>>> +             // err.initCause(ex);
>>>> 
>>>> Why is this commented?
>>>> 
>>>> -- Chris
>> 
> 


From brent.christian at oracle.com  Thu Sep 12 19:48:58 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 12 Sep 2013 12:48:58 -0700
Subject: RFR: 8024009 : Remove jdk.map.useRandomSeed system property
In-Reply-To: <523176B6.1020001@oracle.com>
References: <52310742.9070003@oracle.com> <523176B6.1020001@oracle.com>
Message-ID: <52321AAA.9030205@oracle.com>

On 9/12/13 1:09 AM, Alan Bateman wrote:
> On 12/09/2013 01:13, Brent Christian wrote:
>> Please review my fix to remove the jdk.map.useRandomSeed system
>> property added earlier in jdk8.
> It's good to see this going away, the changes (and clean-up) look good
> to me too.

Thanks guys.
Can someone push this for me?  I can send you a changeset...

-Brent



From david.r.chase at oracle.com  Thu Sep 12 20:00:34 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 16:00:34 -0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
Message-ID: 

On 2013-09-12, at 1:17 AM, Dmitry Nadezhin  wrote:
> The optimal constant for double conversion could be 768 ,
> the optimal constant for float conversion could be 142,
> but I leave this optimization to JDK 9.

It would be helpful to mention in the proof/comment, that 768 refers to the
decimal representation that has had leading zeroes between decimal point
and mantissa trimmed.

An exact case is the decimal representation of the sum of
2^-1022 + 2^-1075
This has a decimal point, then 307 zeroes, non-zeroes at 308 (2) and 1075 (5) 
(and usually non-zeroes between) for a span of 768 decimal digits between
the leading and trailing zeroes.  (There are other screw cases.  Here, 2^-1022
is the minimum normalized-rep double, and 2^-1075 is 1/2 ulp for doubles
with binary exponent -1022, which is represented as 1 in IEEE format.)

Appending any trailing non-zero on this decimal representation rounds up; nothing trailing rounds down.
If the final digit 5 is instead a 6, it always rounds up, if it is a 4 it always rounds down no matter what is appended.

There are other screw cases, but they always involve 2^-1075 because that requires
the maximum number of decimal digits for its representation.

David



From eric.mccorkle at oracle.com  Thu Sep 12 20:02:16 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 12 Sep 2013 16:02:16 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw
	correct exceptions
Message-ID: <52321DC8.9060203@oracle.com>

Hello,

Please review this patch, which implements correct behavior for the
Parameter Reflection API in the case of malformed class files.

The bug report is here:
https://bugs.openjdk.java.net/browse/JDK-8020981

The webrev is here:
http://cr.openjdk.java.net/~emc/8020981/

This review is also on crucible.  The ID is CR-JDK8TL-182.

Thanks,
Eric

From henry.jen at oracle.com  Thu Sep 12 19:36:16 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Thu, 12 Sep 2013 19:36:16 +0000
Subject: hg: jdk8/tl/jdk: 8011916: Spec update for java.util.stream; ...
Message-ID: <20130912193642.118F762781@hg.openjdk.java.net>

Changeset: be6f5f027bc2
Author:    henryjen
Date:      2013-09-06 22:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be6f5f027bc2

8011916: Spec update for java.util.stream
8024339: j.u.s.Stream.reduce(BinaryOperator) throws unexpected NPE
Reviewed-by: mduigou
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/function/package-info.java
! src/share/classes/java/util/stream/BaseStream.java
! src/share/classes/java/util/stream/Collector.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/java/util/stream/StreamSupport.java
! src/share/classes/java/util/stream/package-info.java



From brian.burkhalter at oracle.com  Thu Sep 12 20:23:13 2013
From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com)
Date: Thu, 12 Sep 2013 20:23:13 +0000
Subject: hg: jdk8/tl/jdk: 8010430: Math.round has surprising behavior for odd
	values of ulp 1
Message-ID: <20130912202325.8037E62783@hg.openjdk.java.net>

Changeset: 917fffe971c8
Author:    bpb
Date:      2013-09-11 17:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/917fffe971c8

8010430: Math.round has surprising behavior for odd values of ulp 1
Summary: If the effective floating point exponent is zero return the significand including the implicit 1-bit.
Reviewed-by: bpb, darcy, gls
Contributed-by: Dmitry Nadezhin 

! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java
! test/java/lang/Math/RoundTests.java



From brian.burkhalter at oracle.com  Thu Sep 12 20:49:06 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Sep 2013 13:49:06 -0700
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
Message-ID: <952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>

On Sep 12, 2013, at 1:00 PM, David Chase wrote:

> On 2013-09-12, at 1:17 AM, Dmitry Nadezhin  wrote:
>> The optimal constant for double conversion could be 768 ,
>> the optimal constant for float conversion could be 142,
>> but I leave this optimization to JDK 9.
> 
> It would be helpful to mention in the proof/comment, that 768 refers to the
> decimal representation that has had leading zeroes between decimal point
> and mantissa trimmed.


I updated the webrev to include a comment for MAX_NDIGITS sans both hyperlink and the foregoing verbiage:

http://cr.openjdk.java.net/~bpb/8024356/

If there is any more tweaking of comments which needs to be effected prior to an approval request being posted to 7u-dev, please let me know.

Thanks,

Brian

From david.dehaven at oracle.com  Thu Sep 12 20:50:54 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 12 Sep 2013 13:50:54 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
	
	<522FB8E6.4020209@oracle.com>
	
	
	
	<5230E995.3090609@oracle.com>
	<05F4A4A9-E77B-4D26-961F-BB972F44E95C@oracle.com>
	
Message-ID: <99A7C5C4-0D05-41A6-A4F9-0F50B49B8416@oracle.com>


No problems :)

It's certainly worth knowing if there will be an issue or not.

-DrD-

> Ok, I've tried this out with my app in the sandbox. I can confirm that opening a file dialog (NSSavePanel underneath), with a directory pointing to the Container's Documents directory (/Users/nick/Library/Containers/my.app/Data/Documents), will show the standard Mac file selection dialog with the standard ~/Documents directory selected. If you then select a file there, say 'selected-file.txt', click OK, the dialog will return the path ~/Documents/selected-file.txt.  Since I have the com.apple.security.files.user-selected.read-write entitlement in my application, I can subsequently write to this path, and the file is written in ~/Documents/selected-file.txt, not in the Container's Documents directory.
> 
> So this clears up my questions about this patch. Thanks for helping me through it.
> 
> Cheers,
> Nick
> 
> 
> 
> On Thu, Sep 12, 2013 at 12:11 AM, David DeHaven  wrote:
> 
> >>> The bottom line is, if what you have now allows you to write to
> >>> ~/Documents and you're sandboxed then this change should not
> >>> affect your application at all, except maybe in the UI if you're
> >>> displaying that path to the user. The user won't notice the
> >>> difference otherwise.
> >>
> >> My users *will* notice because I display this path in the export dialog,
> >> along with the other export options they can use.
> >
> > If the path displayed is coming from the selected file, then it will continue to show the correct path.
> 
> I don't think I was clear on that comment... if you're building the path from say System.getProperty("user.home") + "/Documents/blah" and showing it to the user, then that's a problem. If you're showing paths returned by the open/save panels then you're fine, the user will never see the container path.
> 
> -DrD-
> 
> 



From aleksey.shipilev at oracle.com  Thu Sep 12 20:53:38 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 13 Sep 2013 00:53:38 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
Message-ID: <604BEA76-252F-4874-A06F-87C454242044@oracle.com>

On 13.09.2013, at 0:49, Brian Burkhalter  wrote:

> I updated the webrev to include a comment for MAX_NDIGITS sans both hyperlink and the foregoing verbiage:
> 
> http://cr.openjdk.java.net/~bpb/8024356/

Thumbs up.

-Aleksey


From david.r.chase at oracle.com  Thu Sep 12 20:57:35 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 16:57:35 -0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
Message-ID: <63576D3C-14A3-4A86-8428-E7C9E4D0FDDD@oracle.com>

Careful, I don't think I'm a Reviewer.
I merely had the misfortune to care a whole lot about this stuff once long long ago.

David

On 2013-09-12, at 4:49 PM, Brian Burkhalter  wrote:

> On Sep 12, 2013, at 1:00 PM, David Chase wrote:
> 
>> On 2013-09-12, at 1:17 AM, Dmitry Nadezhin  wrote:
>>> The optimal constant for double conversion could be 768 ,
>>> the optimal constant for float conversion could be 142,
>>> but I leave this optimization to JDK 9.
>> 
>> It would be helpful to mention in the proof/comment, that 768 refers to the
>> decimal representation that has had leading zeroes between decimal point
>> and mantissa trimmed.
> 
> I updated the webrev to include a comment for MAX_NDIGITS sans both hyperlink and the foregoing verbiage:
> 
> http://cr.openjdk.java.net/~bpb/8024356/
> 
> If there is any more tweaking of comments which needs to be effected prior to an approval request being posted to 7u-dev, please let me know.
> 
> Thanks,
> 
> Brian



From brian.burkhalter at oracle.com  Thu Sep 12 21:00:54 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Sep 2013 14:00:54 -0700
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <63576D3C-14A3-4A86-8428-E7C9E4D0FDDD@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
	<63576D3C-14A3-4A86-8428-E7C9E4D0FDDD@oracle.com>
Message-ID: <08CACC8B-83D8-4B00-AE63-DEEF47FF0B6D@oracle.com>

I know, I checked the census. The "Reviewed-by" header field can include any OpenJDK member AFAIK. The approval for pushing is a separate story and has to be handled via e-mail on the 7u-dev list (and a 7u-dev committer will be needed eventually).

Thanks,

Brian

On Sep 12, 2013, at 1:57 PM, David Chase wrote:

> Careful, I don't think I'm a Reviewer.
> I merely had the misfortune to care a whole lot about this stuff once long long ago.



From john.r.rose at oracle.com  Thu Sep 12 21:35:46 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Sep 2013 14:35:46 -0700
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
Message-ID: <31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>

It looks good.  I have three requests.

Regarding this comment:
+     * See MethodSupplier.java to see how to produce these bytes.
+     * They encode that class, except that method m is private, not public.

The recipe is incomplete, since it does not say which bits to tweak to make m private.  Please add that step to the comments more explicitly, or if possible to the code (so bogusMethodSupplier is a clean copy of the od output).  I suppose you could ask sed to change the byte for you.  That will make this test a better example for future tests, and make it easier to maintain if javac output changes.  The high road to use would be asm, although for a single byte tweak od works OK.

Also, this bug has two twins.  The same thing will happen with NoSuchMethodE* and NoSuchFieldE*.  Can you please make fixes for those guys also?

FTR, see MemberName.makeAccessException() for logic which maps the other way, from *Error to *Exception.  I don't see a direct way to avoid the double mapping (Error=>Exception=>Error) when it occurs.

For the initCause bit we should do this:

        } catch (IllegalAccessException ex) {
            Error err = new IllegalAccessError(ex.getMessage());
            err.initCause(ex.getCause());  // reuse underlying cause of ex
            throw err;
        } ... and for NSME and NSFE...

That way users can avoid the duplicate exception but can see any underlying causes that the JVM may include.

Thanks for untangling this!

? John

On Sep 12, 2013, at 12:17 PM, David Chase  wrote:

> The test is adapted from the test in the bug report.
> The headline on the bug report is wrong -- because it uses reflection in the test to do the invocation,
> the thrown exception is wrapped with InvocationTargetException, which is completely correct.
> HOWEVER, the exception inside the wrapper is the wrong one.
> 
> The new test checks the exception in both the reflective-invocation and plain-invocation cases,
> and also checks both a method handle call (which threw the wrong exception) and a plain
> call (which threw, and throws, the right exception).
> 
> The test also uses a tweaked classloader to substitute the borked bytecodes necessary to get
> the error, so it is not only shell-free, it can also be run outside jtreg.
> 
> On 2013-09-12, at 2:34 PM, Christian Thalinger  wrote:
> 
>> 
>> On Sep 12, 2013, at 11:28 AM, David Chase  wrote:
>> 
>>> New webrev, commented line removed:
>>> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
>> 
>> I think the change is good given that the tests work now.  Is your test derived from the test in the bug report?
>> 
>> And it would be good if John could also have a quick look (just be to be sure).
>> 
>> -- Chris
>> 
>>> 
>>> On 2013-09-12, at 1:53 PM, David Chase  wrote:
>>> 
>>>> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
>>>> 
>>>> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
>>>> 
>>>>> +             // err.initCause(ex);
>>>>> 
>>>>> Why is this commented?
>>>>> 
>>>>> -- Chris
>>> 
>> 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From vicente.romero at oracle.com  Thu Sep 12 21:41:43 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 12 Sep 2013 21:41:43 +0000
Subject: hg: jdk8/tl/langtools: 8023558: Javac creates invalid bootstrap
	methods for complex lambda/methodref case
Message-ID: <20130912214149.3271F6278A@hg.openjdk.java.net>

Changeset: 3ae1814f7c59
Author:    vromero
Date:      2013-09-12 22:40 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ae1814f7c59

8023558: Javac creates invalid bootstrap methods for complex lambda/methodref case
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com, vicente.romero at oracle.com

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/8023558/T8023558a.java
+ test/tools/javac/lambda/8023558/T8023558b.java
+ test/tools/javac/lambda/8023558/T8023558c.java



From john.r.rose at oracle.com  Thu Sep 12 23:34:40 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Sep 2013 16:34:40 -0700
Subject: RFR (S) 8019417: JSR 292 javadoc should clarify method handle arity
	limits
Message-ID: <0CEEB903-FBA5-41FE-B881-E79DD26947D3@oracle.com>

Please review this change for a change to the JSR 292 implementation:

http://cr.openjdk.java.net/~jrose/8019417/webrev.00

The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.

Since the RI is already correct, there are no implementation code changes.

Thanks,
? John

From christian.thalinger at oracle.com  Fri Sep 13 00:17:22 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 12 Sep 2013 17:17:22 -0700
Subject: RFR (S) 8019417: JSR 292 javadoc should clarify method handle
	arity limits
In-Reply-To: <0CEEB903-FBA5-41FE-B881-E79DD26947D3@oracle.com>
References: <0CEEB903-FBA5-41FE-B881-E79DD26947D3@oracle.com>
Message-ID: 


On Sep 12, 2013, at 4:34 PM, John Rose  wrote:

> Please review this change for a change to the JSR 292 implementation:
> 
> http://cr.openjdk.java.net/~jrose/8019417/webrev.00
> 
> The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
> 
> Since the RI is already correct, there are no implementation code changes.

This looks good.  The only thing that sounds odd is "very large arity":

+     * very large arity,

-- Chris

> 
> Thanks,
> ? John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From david.r.chase at oracle.com  Fri Sep 13 00:44:19 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 12 Sep 2013 20:44:19 -0400
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: <31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
Message-ID: 

Do these sibling bugs have numbers?

And I take it you would like to see

1) a test enhanced with ASM to do all 3 variants of this
2) DO attach the underlying cause

David

On 2013-09-12, at 5:35 PM, John Rose  wrote:

> It looks good.  I have three requests.
> 
> Regarding this comment:
> +     * See MethodSupplier.java to see how to produce these bytes.
> +     * They encode that class, except that method m is private, not public.
> 
> The recipe is incomplete, since it does not say which bits to tweak to make m private.  Please add that step to the comments more explicitly, or if possible to the code (so bogusMethodSupplier is a clean copy of the od output).  I suppose you could ask sed to change the byte for you.  That will make this test a better example for future tests, and make it easier to maintain if javac output changes.  The high road to use would be asm, although for a single byte tweak od works OK.
> 
> Also, this bug has two twins.  The same thing will happen with NoSuchMethodE* and NoSuchFieldE*.  Can you please make fixes for those guys also?
> 
> FTR, see MemberName.makeAccessException() for logic which maps the other way, from *Error to *Exception.  I don't see a direct way to avoid the double mapping (Error=>Exception=>Error) when it occurs.
> 
> For the initCause bit we should do this:
> 
>        } catch (IllegalAccessException ex) {
>            Error err = new IllegalAccessError(ex.getMessage());
>            err.initCause(ex.getCause());  // reuse underlying cause of ex
>            throw err;
>        } ... and for NSME and NSFE...
> 
> That way users can avoid the duplicate exception but can see any underlying causes that the JVM may include.
> 
> Thanks for untangling this!
> 
> ? John
> 
> On Sep 12, 2013, at 12:17 PM, David Chase  wrote:
> 
>> The test is adapted from the test in the bug report.
>> The headline on the bug report is wrong -- because it uses reflection in the test to do the invocation,
>> the thrown exception is wrapped with InvocationTargetException, which is completely correct.
>> HOWEVER, the exception inside the wrapper is the wrong one.
>> 
>> The new test checks the exception in both the reflective-invocation and plain-invocation cases,
>> and also checks both a method handle call (which threw the wrong exception) and a plain
>> call (which threw, and throws, the right exception).
>> 
>> The test also uses a tweaked classloader to substitute the borked bytecodes necessary to get
>> the error, so it is not only shell-free, it can also be run outside jtreg.
>> 
>> On 2013-09-12, at 2:34 PM, Christian Thalinger  wrote:
>> 
>>> 
>>> On Sep 12, 2013, at 11:28 AM, David Chase  wrote:
>>> 
>>>> New webrev, commented line removed:
>>>> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
>>> 
>>> I think the change is good given that the tests work now.  Is your test derived from the test in the bug report?
>>> 
>>> And it would be good if John could also have a quick look (just be to be sure).
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> On 2013-09-12, at 1:53 PM, David Chase  wrote:
>>>> 
>>>>> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
>>>>> 
>>>>> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
>>>>> 
>>>>>> +             // err.initCause(ex);
>>>>>> 
>>>>>> Why is this commented?
>>>>>> 
>>>>>> -- Chris
>>>> 
>>> 
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 



From john.r.rose at oracle.com  Fri Sep 13 01:02:10 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Sep 2013 18:02:10 -0700
Subject: RFR (S) 8001109: arity mismatch on a call to spreader method handle
	should elicit IllegalArgumentException
Message-ID: <74280088-19F3-4B0B-AC62-3332E9AED63A@oracle.com>

Please review this change for a change to the JSR 292 implementation:

http://cr.openjdk.java.net/~jrose/8001109/webrev.00/

The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.

In the RI, the exception-raising code is simplified to throw just IAE.

Thanks,
? John

From john.r.rose at oracle.com  Fri Sep 13 01:47:18 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Sep 2013 18:47:18 -0700
Subject: RFR (S) 8001108: an attempt to use "" as a method name should
	elicit NoSuchMethodException
Message-ID: <6FAC275C-6374-41F5-BAB7-CA1AC729EF9F@oracle.com>

Please review this change for a change to the JSR 292 implementation:

http://cr.openjdk.java.net/~jrose/8001108/webrev.00

Summary: add an explicit check for leading "<", upgrade the unit tests

The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.

In the RI, there is an explicit error check.

Thanks,
? John

P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.

From john.r.rose at oracle.com  Fri Sep 13 02:24:04 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Sep 2013 19:24:04 -0700
Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect
	initialization rules for static members
Message-ID: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>

Please review this change for a change to the JSR 292 implementation:

http://cr.openjdk.java.net/~jrose/8024599/webrev.00/

Summary: Align MH semantic with bytecode behavior of constructor and static member accesses, regarding  invocation.

The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.

Bug Description:  When using lookupStatic to create a direct method handle for a static method, class initialization needs to be specified to align with the underly bytecode behavior of the invokestatic instruction. 

The JDK8 and 7u40 implementations do this, but the specification claims that the call to lookupStatic itself performs class initialization. Although this may have been the behavior of early versions of JDK 7, it is an error. 

Detail: 

The javadoc headers to Lookup and MethodHandle state that method handles emulate bytecode behaviors. The most precise specification of this emulation is in the JVMS, 5.4.3.5: 

> Calling this method handle on a valid set of arguments has exactly the same effect and returns the same result (if any) as the corresponding bytecode behavior. 

Also the doc for the "invokevirtual" instruction says: 

> ...if the method handle to be invoked has bytecode behavior, the Java Virtual Machine invokes the method handle as if by execution of the bytecode behavior associated with the method handle's kind. 

And the doc for the "invokestatic" instruction describes the placement of the lazy class initialization: 

> On successful resolution of the method, the class that declared the resolved method is initialized (?5.5) if that class has not already been initialized. 

This puts the class initialization action near the border between resolution (link time) and execution (run time). The JDK 7 behavior acts as if the initialization action were part of resolution (link time), in that it claims to perform class initialization before the method handle is returned from findStatic (etc.). 

But on a closer reading of the JVMS, that is wrong. Note that errors (and presumably side effects) from class initialization are classified as runtime effects, not linktime effects: 

> Run-time Exceptions Otherwise, if execution of this invokestatic instruction causes initialization of the referenced class, invokestatic may throw an Error as detailed in ?5.5. 

In other words, the original JDK 7 specification of eager initalization poorly aligns with (poorly emulates) the bytecode behavior, contrary to the overall pronouncements of the JSR 292 specification. 

Compatibility risk for better alignment is small, since most users of JSR 292 create method handles lazily during BSM (i.e., invokedynamic bootstrap method) execution. It will not matter to them (except to reduce surprise due to semantic mislignment) if the initialization action is moved from the BSM to the first execution of the MH produced by the BSM. 

It appears that the at least one other implementation, the "JSR 292 Backport", performs static member class initialization on first execution of bytecode behavior, because it uses reflection and weaving of "*static" instructions. This is no accident: The coherence and usefulness of JSR 292 relies on close alignment of member access semantics among the various modes, direct bytecode execution and various old and new reflective APIs. 

Besides spec. coherence, a key problem with the "eager" class initialization (in findStatic) is usability. Eager class initialization is impossible to undo. It is also difficult to predict and avoid. Users who want it and don't have it can call Class.forName with an argument of 'true'. Users who don't want it and get it (in early JDK 7 and perhaps other systems) are out of luck.

Thanks,
? John

P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.

From john.r.rose at oracle.com  Fri Sep 13 02:55:48 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Sep 2013 19:55:48 -0700
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
Message-ID: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>

Please review this change for a change to the JSR 292 implementation:

http://cr.openjdk.java.net/~jrose/8001110/webrev.00/

Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types

The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.

Bug Description:  Currently, a method handle can be transformed so that multiple arguments are collected and passed to the original method handle. However, the two routes to doing this are both limited to special purposes. 

(They are asCollector, which collects only trailing arguments, and only into an array; and foldArguments, which collects only leading arguments into filter function, and passes both the filtered result *and* the original arguments to the original.)

MethodHandles.collectArguments(mh, pos, collector) should produce a method handle which acts like lambda(a*, b*, c*) { x = collector(b*); return mh(a*, x, c*) }, where the span of arguments b* is located by pos and the arity of the collector.

There is internal machinery in any JSR 292 implementation to do this. It should be made available to users.

This is a missing part of the JSR 292 spec.

Thanks,
? John

P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.

From dmitry.nadezhin at gmail.com  Fri Sep 13 03:13:44 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Fri, 13 Sep 2013 07:13:44 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
Message-ID: 

Should we change conservative constant 1100 to optimal constant 768 ?
My opinion is no (in JDK7), because the constant 1100 has lower cost of
review.
I mean that chances that a reviewer approves 1100 are higher than chances
that [s]he approves 768.



On Fri, Sep 13, 2013 at 12:49 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> On Sep 12, 2013, at 1:00 PM, David Chase wrote:
>
> On 2013-09-12, at 1:17 AM, Dmitry Nadezhin 
> wrote:
>
> The optimal constant for double conversion could be 768 ,
>
> the optimal constant for float conversion could be 142,
>
> but I leave this optimization to JDK 9.
>
>
> It would be helpful to mention in the proof/comment, that 768 refers to the
> decimal representation that has had leading zeroes between decimal point
> and mantissa trimmed.
>
>
> I updated the webrev to include a comment for MAX_NDIGITS sans both
> hyperlink and the foregoing verbiage:
>
> http://cr.openjdk.java.net/~bpb/8024356/
>
> If there is any more tweaking of comments which needs to be effected prior
> to an approval request being posted to 7u-dev, please let me know.
>
> Thanks,
>
> Brian
>


From david.lloyd at redhat.com  Fri Sep 13 03:45:57 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 12 Sep 2013 22:45:57 -0500
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
	
Message-ID: <52328A75.8030208@redhat.com>

If that's the only consideration then just use 0x300 instead, which is 
easier to read *and* makes more sense anyway, in the context of the test.

On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote:
> Should we change conservative constant 1100 to optimal constant 768 ?
> My opinion is no (in JDK7), because the constant 1100 has lower cost of
> review.
> I mean that chances that a reviewer approves 1100 are higher than chances
> that [s]he approves 768.
>
>
>
> On Fri, Sep 13, 2013 at 12:49 AM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
>
>> On Sep 12, 2013, at 1:00 PM, David Chase wrote:
>>
>> On 2013-09-12, at 1:17 AM, Dmitry Nadezhin 
>> wrote:
>>
>> The optimal constant for double conversion could be 768 ,
>>
>> the optimal constant for float conversion could be 142,
>>
>> but I leave this optimization to JDK 9.
>>
>>
>> It would be helpful to mention in the proof/comment, that 768 refers to the
>> decimal representation that has had leading zeroes between decimal point
>> and mantissa trimmed.
>>
>>
>> I updated the webrev to include a comment for MAX_NDIGITS sans both
>> hyperlink and the foregoing verbiage:
>>
>> http://cr.openjdk.java.net/~bpb/8024356/
>>
>> If there is any more tweaking of comments which needs to be effected prior
>> to an approval request being posted to 7u-dev, please let me know.
>>
>> Thanks,
>>
>> Brian
>>


-- 
- DML


From john.r.rose at oracle.com  Fri Sep 13 04:02:41 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Sep 2013 21:02:41 -0700
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
	
Message-ID: <9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>

On Sep 12, 2013, at 5:44 PM, David Chase  wrote:

> Do these sibling bugs have numbers?

Yes, 8022701.  I just updated the bug to explain their common genesis.

> And I take it you would like to see
> 
> 1) a test enhanced with ASM to do all 3 variants of this

Yes, please.  The case of "no such field" does not have a direct cause from lambda expressions AFAIK, but it can occur with "raw" CONSTANT_MethodHandles.  (It would be reasonable for javac to emit CONSTANT_MH's for fields in some very limited circumstances, but I'll bet it doesn't.)

> 2) DO attach the underlying cause

Yes.  Read the javadoc for ExceptionInInitializerError for an example of why users want the underlying cause for linkage errors.

(Golly, I wonder what happens if resolution of a CONSTANT_MethodHandle tries to touch a class with a booby-trapped .  I hope it's the case that the ExceptionInInitializerError just passes straight up the stack.  But if it were to get wrapped in a ROE of some sort, it would probably bubble up as an IAE.  Could be a charming exploration.  Actually, no, I don't want to go in there.  Getting all possible linkage errors correct is fine, but we have more important things to do.)

? John

> David
> 
> On 2013-09-12, at 5:35 PM, John Rose  wrote:
> 
>> It looks good.  I have three requests.
>> 
>> Regarding this comment:
>> +     * See MethodSupplier.java to see how to produce these bytes.
>> +     * They encode that class, except that method m is private, not public.
>> 
>> The recipe is incomplete, since it does not say which bits to tweak to make m private.  Please add that step to the comments more explicitly, or if possible to the code (so bogusMethodSupplier is a clean copy of the od output).  I suppose you could ask sed to change the byte for you.  That will make this test a better example for future tests, and make it easier to maintain if javac output changes.  The high road to use would be asm, although for a single byte tweak od works OK.
>> 
>> Also, this bug has two twins.  The same thing will happen with NoSuchMethodE* and NoSuchFieldE*.  Can you please make fixes for those guys also?
>> 
>> FTR, see MemberName.makeAccessException() for logic which maps the other way, from *Error to *Exception.  I don't see a direct way to avoid the double mapping (Error=>Exception=>Error) when it occurs.
>> 
>> For the initCause bit we should do this:
>> 
>>       } catch (IllegalAccessException ex) {
>>           Error err = new IllegalAccessError(ex.getMessage());
>>           err.initCause(ex.getCause());  // reuse underlying cause of ex
>>           throw err;
>>       } ... and for NSME and NSFE...
>> 
>> That way users can avoid the duplicate exception but can see any underlying causes that the JVM may include.
>> 
>> Thanks for untangling this!
>> 
>> ? John
>> 
>> On Sep 12, 2013, at 12:17 PM, David Chase  wrote:
>> 
>>> The test is adapted from the test in the bug report.
>>> The headline on the bug report is wrong -- because it uses reflection in the test to do the invocation,
>>> the thrown exception is wrapped with InvocationTargetException, which is completely correct.
>>> HOWEVER, the exception inside the wrapper is the wrong one.
>>> 
>>> The new test checks the exception in both the reflective-invocation and plain-invocation cases,
>>> and also checks both a method handle call (which threw the wrong exception) and a plain
>>> call (which threw, and throws, the right exception).
>>> 
>>> The test also uses a tweaked classloader to substitute the borked bytecodes necessary to get
>>> the error, so it is not only shell-free, it can also be run outside jtreg.
>>> 
>>> On 2013-09-12, at 2:34 PM, Christian Thalinger  wrote:
>>> 
>>>> 
>>>> On Sep 12, 2013, at 11:28 AM, David Chase  wrote:
>>>> 
>>>>> New webrev, commented line removed:
>>>>> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
>>>> 
>>>> I think the change is good given that the tests work now.  Is your test derived from the test in the bug report?
>>>> 
>>>> And it would be good if John could also have a quick look (just be to be sure).
>>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> On 2013-09-12, at 1:53 PM, David Chase  wrote:
>>>>> 
>>>>>> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
>>>>>> 
>>>>>> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
>>>>>> 
>>>>>>> +             // err.initCause(ex);
>>>>>>> 
>>>>>>> Why is this commented?
>>>>>>> 
>>>>>>> -- Chris
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
> 



From dmitry.nadezhin at gmail.com  Fri Sep 13 04:25:59 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Fri, 13 Sep 2013 08:25:59 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: <52328A75.8030208@redhat.com>
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
	
	<52328A75.8030208@redhat.com>
Message-ID: 

For me, it is the only consideration.
I'm sure in 768 because I proved it formally using ACL2 tool.


On Fri, Sep 13, 2013 at 7:45 AM, David M. Lloyd wrote:

> If that's the only consideration then just use 0x300 instead, which is
> easier to read *and* makes more sense anyway, in the context of the test.
>
>
> On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote:
>
>> Should we change conservative constant 1100 to optimal constant 768 ?
>> My opinion is no (in JDK7), because the constant 1100 has lower cost of
>> review.
>> I mean that chances that a reviewer approves 1100 are higher than chances
>> that [s]he approves 768.
>>
>>
>>
>> On Fri, Sep 13, 2013 at 12:49 AM, Brian Burkhalter <
>> brian.burkhalter at oracle.com> wrote:
>>
>>  On Sep 12, 2013, at 1:00 PM, David Chase wrote:
>>>
>>> On 2013-09-12, at 1:17 AM, Dmitry Nadezhin 
>>> wrote:
>>>
>>> The optimal constant for double conversion could be 768 ,
>>>
>>> the optimal constant for float conversion could be 142,
>>>
>>> but I leave this optimization to JDK 9.
>>>
>>>
>>> It would be helpful to mention in the proof/comment, that 768 refers to
>>> the
>>> decimal representation that has had leading zeroes between decimal point
>>> and mantissa trimmed.
>>>
>>>
>>> I updated the webrev to include a comment for MAX_NDIGITS sans both
>>> hyperlink and the foregoing verbiage:
>>>
>>> http://cr.openjdk.java.net/~**bpb/8024356/
>>>
>>> If there is any more tweaking of comments which needs to be effected
>>> prior
>>> to an approval request being posted to 7u-dev, please let me know.
>>>
>>> Thanks,
>>>
>>> Brian
>>>
>>>
>
> --
> - DML
>


From john.r.rose at oracle.com  Fri Sep 13 05:06:50 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Sep 2013 22:06:50 -0700
Subject: additional JSR 292 review resources
Message-ID: 

P.S.  To see the proposed JSR 292 spec changes only (no code, rendered javadoc), see:

http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/1-specdiff-meth-info-8008688
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/2-specdiff-meth-arity-8019417
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/3-specdiff-meth-spr-8001109
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/4-specdiff-meth-nsme-8001108
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/5-specdiff-meth-clinit-8024599
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/6-specdiff-meth-coll-8001110
http://cr.openjdk.java.net/~jrose/pres/201309-jsr292/7-specdiff-meth-mr-8024438

(The code changes for the last one, 8024438, are not yet ready to review.)



From joel.franck at oracle.com  Fri Sep 13 09:05:34 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 13 Sep 2013 11:05:34 +0200
Subject: static vs. default interface methods and inheritance VM/javac
	issues
In-Reply-To: <7B094410-1F13-488C-A8B9-3B4321F31A0B@oracle.com>
References: <5231D6C9.806@gmail.com>
	<7B094410-1F13-488C-A8B9-3B4321F31A0B@oracle.com>
Message-ID: <1B928A74-E33B-4B42-9639-623621B70036@oracle.com>

Hi,

Thanks Karen and Peter.

FWIW my interpretation is that javac is doing the right thing. The bytecode generated is an "invokeinterface DefaultStaticMethodTest$C.m()". This looks consistent with the other bytecodes generated for calls to methods of anonymous classes implementing an interface. There should be no ambiguity in the program since static interface methods are not inherited, so javac is right in accepting it.

cheers
/Joel

On Sep 12, 2013, at 8:23 PM, Karen Kinnear  wrote:

> Thank you, we really appreciate all testing.
> 
> I have a fix in a prototype in the vm for this. Let me know if you want an early patch. 
> Or you can just file a bug and that way you'll know when the fix is officially in the tree.
> 
> thanks,
> Karen
> 
> On Sep 12, 2013, at 10:59 AM, Peter Levart wrote:
> 
>> Hi,
>> 
>> While testing behavior of reflection on default and static interface methods, using self-built JDK from latest tip of jdk8/tl, I found:
>> 
>> The following program:
>> 
>> public class DefaultVsStaticInterfaceMethodTest {
>>     public interface A {
>>         default void m() {
>>             System.out.println("A.m() called");
>>         }
>>     }
>> 
>>     public interface B {
>>         static void m() {
>>             System.out.println("B.m() called");
>>         }
>>     }
>> 
>>     public interface C extends A, B {
>>     }
>> 
>>     public static void main(String[] args) throws Exception {
>>         C c = new C() {};
>>         c.m();
>>     }
>> }
>> 
>> 
>> ...compiles, but gives a runtime error:
>> 
>> Exception in thread "main" java.lang.AbstractMethodError: Conflicting default methods: DefaultVsStaticInterfaceMethodTest$A.m DefaultVsStaticInterfaceMethodTest$B.m
>>     at DefaultVsStaticInterfaceMethodTest$1.m(DefaultVsStaticInterfaceMethodTest.java)
>>     at DefaultVsStaticInterfaceMethodTest.main(DefaultVsStaticInterfaceMethodTest.java:28)
>> 
>> 
>> A slightly modified program: "C extends A, B" replaced with "C extends B, A":
>> 
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/DefaultVsStaticInterfaceMethodTest.java
>> 
>> ...also compiles, but crashes the VM when run:
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007fd4d5020bf9, pid=9964, tid=140552419804928
>> #
>> # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-peter_2013_09_12_16_29-b00)
>> # Java VM: OpenJDK 64-Bit Server VM (25.0-b48 mixed mode linux-amd64 compressed oops)
>> # Problematic frame:
>> # j  DefaultVsStaticInterfaceMethodTest.main([Ljava/lang/String;)V+9
>> #
>> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # An error report file with more information is saved as:
>> # /home/peter/work/git/jdk8-tl/out/production/test/hs_err_pid9964.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://bugreport.sun.com/bugreport/crash.jsp
>> #
>> Aborted (core dumped)
>> 
>> 
>> Here's the hs_err_pid file:
>> 
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/hs_err_pid9964.log
>>  
>> 
>> 
>> Regards, Peter
>> 
> 



From peter.levart at gmail.com  Fri Sep 13 09:37:01 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Sep 2013 11:37:01 +0200
Subject: static vs. default interface methods and inheritance VM/javac
	issues
In-Reply-To: <1B928A74-E33B-4B42-9639-623621B70036@oracle.com>
References: <5231D6C9.806@gmail.com>
	<7B094410-1F13-488C-A8B9-3B4321F31A0B@oracle.com>
	<1B928A74-E33B-4B42-9639-623621B70036@oracle.com>
Message-ID: <5232DCBD.1070105@gmail.com>

On 09/13/2013 11:05 AM, Joel Borggr?n-Franck wrote:
> Hi,
>
> Thanks Karen and Peter.
>
> FWIW my interpretation is that javac is doing the right thing. The bytecode generated is an "invokeinterface DefaultStaticMethodTest$C.m()". This looks consistent with the other bytecodes generated for calls to methods of anonymous classes implementing an interface. There should be no ambiguity in the program since static interface methods are not inherited, so javac is right in accepting it.

I think that too. In that case even the AbstractMethodError is incorrect 
VM behaviour. And the order of "C extends B, A" vs. "C extends A, B" 
should not effect the behaviour.

Karen, I filed a bug, but don't have the bug ID yet. Will let you know 
when I get it.

Regards, Peter

cheers /Joel
On Sep 12, 2013, at 8:23 PM, Karen Kinnear  
wrote:
>> Thank you, we really appreciate all testing.
>>
>> I have a fix in a prototype in the vm for this. Let me know if you want an early patch.
>> Or you can just file a bug and that way you'll know when the fix is officially in the tree.
>>
>> thanks,
>> Karen
>>
>> On Sep 12, 2013, at 10:59 AM, Peter Levart wrote:
>>
>>> Hi,
>>>
>>> While testing behavior of reflection on default and static interface methods, using self-built JDK from latest tip of jdk8/tl, I found:
>>>
>>> The following program:
>>>
>>> public class DefaultVsStaticInterfaceMethodTest {
>>>      public interface A {
>>>          default void m() {
>>>              System.out.println("A.m() called");
>>>          }
>>>      }
>>>
>>>      public interface B {
>>>          static void m() {
>>>              System.out.println("B.m() called");
>>>          }
>>>      }
>>>
>>>      public interface C extends A, B {
>>>      }
>>>
>>>      public static void main(String[] args) throws Exception {
>>>          C c = new C() {};
>>>          c.m();
>>>      }
>>> }
>>>
>>>
>>> ...compiles, but gives a runtime error:
>>>
>>> Exception in thread "main" java.lang.AbstractMethodError: Conflicting default methods: DefaultVsStaticInterfaceMethodTest$A.m DefaultVsStaticInterfaceMethodTest$B.m
>>>      at DefaultVsStaticInterfaceMethodTest$1.m(DefaultVsStaticInterfaceMethodTest.java)
>>>      at DefaultVsStaticInterfaceMethodTest.main(DefaultVsStaticInterfaceMethodTest.java:28)
>>>
>>>
>>> A slightly modified program: "C extends A, B" replaced with "C extends B, A":
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/DefaultVsStaticInterfaceMethodTest.java
>>>
>>> ...also compiles, but crashes the VM when run:
>>>
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGSEGV (0xb) at pc=0x00007fd4d5020bf9, pid=9964, tid=140552419804928
>>> #
>>> # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-peter_2013_09_12_16_29-b00)
>>> # Java VM: OpenJDK 64-Bit Server VM (25.0-b48 mixed mode linux-amd64 compressed oops)
>>> # Problematic frame:
>>> # j  DefaultVsStaticInterfaceMethodTest.main([Ljava/lang/String;)V+9
>>> #
>>> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>>> #
>>> # An error report file with more information is saved as:
>>> # /home/peter/work/git/jdk8-tl/out/production/test/hs_err_pid9964.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> #   http://bugreport.sun.com/bugreport/crash.jsp
>>> #
>>> Aborted (core dumped)
>>>
>>>
>>> Here's the hs_err_pid file:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/hs_err_pid9964.log
>>>   
>>>
>>>
>>> Regards, Peter
>>>



From shanliang.jiang at oracle.com  Fri Sep 13 08:48:45 2013
From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com)
Date: Fri, 13 Sep 2013 08:48:45 +0000
Subject: hg: jdk8/tl/jdk: 8023669: MBean*Info.hashCode : NPE
Message-ID: <20130913084942.465AD627C9@hg.openjdk.java.net>

Changeset: ba0b95f310c8
Author:    sjiang
Date:      2013-09-13 10:48 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba0b95f310c8

8023669: MBean*Info.hashCode : NPE
Reviewed-by: dholmes, dfuchs, jbachorik

! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
! src/share/classes/javax/management/MBeanParameterInfo.java
+ test/javax/management/MBeanInfo/MBeanInfoHashCodeNPETest.java



From peter.levart at gmail.com  Fri Sep 13 10:18:18 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Sep 2013 12:18:18 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: <20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
	<20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
Message-ID: <5232E66A.1020606@gmail.com>

On 09/12/2013 03:37 PM, Joel Borggr?n-Franck wrote:
> Hi again,
>
> New webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.01/
>
> Thanks to Remi and Peter for the quick feedback, I've updated the code
> to use for-each as well as fixing getMethod(...).
>
> Andreas Lundblad also added ~100 testcases for getMethod(), both
> positive and negative.
>
> Please review
>
> cheers
> /Joel

Hi Joel,

This looks correct now. I just wonder about the following corner case. 
Suppose you have:

public interface A {
     default void m() {
     }
}

public interface B extends A {
     static void m() {
     }
}

public interface C extends B {
}

This does not actually compile, and I think this is correct:

/home/peter/work/local/DefaultVsStaticInterfaceMethodCrash/src/B.java
     Error:Error:line (2)java: m() in B clashes with m() in A
   overriding method is static


But if interface A at first does not have method m(), it compiles. If 
later default method m() is added to interface A and A is compiled 
separately, then what happens?

The C.class.getMethods() returns a 1 element array containing A.m(), but 
C.class.getMethod("m") throws NoSuchMethodException.

This seems inconsistent, but it's a corner case that can only happen 
with separate compilation.


Regards, Peter

>
> On 2013-09-09, Joel Borggr?n-Franck wrote:
>> Hi
>>
>> Pleaser review fix for 8009411 : getMethods should not inherit static methods from interfaces
>>
>> The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). Webrev is based on the clarification to getMethods and friends out for review on this list.
>>
>> Webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.00/
>> Bug is here: http://bugs.sun.com/view_bug.do?bug_id=8009411
>>
>> For oracle reviewers, ccc is approved.
>>
>> cheers
>> /Joel



From peter.levart at gmail.com  Fri Sep 13 11:15:32 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Sep 2013 13:15:32 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: <5232E66A.1020606@gmail.com>
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
	<20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
	<5232E66A.1020606@gmail.com>
Message-ID: <5232F3D4.6030405@gmail.com>

On 09/13/2013 12:18 PM, Peter Levart wrote:
> The C.class.getMethods() returns a 1 element array containing A.m(), 
> but C.class.getMethod("m") throws NoSuchMethodException.
>
> This seems inconsistent, but it's a corner case that can only happen 
> with separate compilation. 

Sorry Joel, I must have tested the unpatched code for 
C.class.getMethods(). In is in fact consistent with 
C.calss.getMethod("m"). Both calls don't return the A.m() method. in 
getMethod("m") case the recursion is stoped when B.m() static method is 
encountered and in getMethods() case the inherited method A.m() is 
removed from inheritedMethods array by the following in 
privateGetPublicMethods():

         // Filter out all local methods from inherited ones
         for (int i = 0; i < methods.length(); i++) {
             Method m = methods.get(i);
             inheritedMethods.removeByNameAndSignature(m);
         }

...when collecting B's methods...

But the question remains whether A.m() should be seen by invokeinterface 
C.m() in spite of the fact that there is static B.m() in between and 
whether reflection should follow that.


Regards, Peter


From alan.bateman at oracle.com  Fri Sep 13 11:59:40 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 13 Sep 2013 11:59:40 +0000
Subject: hg: jdk8/tl/jdk: 8024009: Remove jdk.map.useRandomSeed system property
Message-ID: <20130913120014.A543F627D2@hg.openjdk.java.net>

Changeset: cc2bae7f8fbb
Author:    bchristi
Date:      2013-09-12 14:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc2bae7f8fbb

8024009: Remove jdk.map.useRandomSeed system property
Summary: Removed usage of hashSeed in Hashtable & WeakHashMap, and removed tests
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/WeakHashMap.java
- test/java/util/Map/CheckRandomHashSeed.java
! test/java/util/Map/Collisions.java



From chris.hegarty at oracle.com  Fri Sep 13 12:14:50 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 13 Sep 2013 12:14:50 +0000
Subject: hg: jdk8/tl/jdk: 8024675:
	java/net/NetworkInterface/UniqueMacAddressesTest.java fails on Windows
Message-ID: <20130913121513.9BD47627D3@hg.openjdk.java.net>

Changeset: c53411f89b4c
Author:    msheppar
Date:      2013-09-13 12:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c53411f89b4c

8024675: java/net/NetworkInterface/UniqueMacAddressesTest.java fails on Windows
Summary: amended test to add active, i.e. isUp(), NetworkInterfaces to test list
Reviewed-by: alanb, chegar

! test/java/net/NetworkInterface/UniqueMacAddressesTest.java



From sundararajan.athijegannathan at oracle.com  Fri Sep 13 12:39:17 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Fri, 13 Sep 2013 12:39:17 +0000
Subject: hg: jdk8/tl/nashorn: 5 new changesets
Message-ID: <20130913123923.3CA8C627D5@hg.openjdk.java.net>

Changeset: e60f6add90d7
Author:    hannesw
Date:      2013-09-12 14:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e60f6add90d7

8024476: Octane regression on Richards
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/runtime/JSType.java

Changeset: 572a2e50ba9e
Author:    hannesw
Date:      2013-09-12 17:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/572a2e50ba9e

8024512: Regex /[^\[]/ doesn't match
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8024512.js
+ test/script/basic/JDK-8024512.js.EXPECTED

Changeset: 917b16e509bd
Author:    sundar
Date:      2013-09-12 22:16 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/917b16e509bd

8024693: Various minor issues with JSONWriter used by script parser API
Reviewed-by: jlaskey, hannesw

! make/build.xml
! src/jdk/nashorn/internal/ir/debug/JSONWriter.java
! test/script/basic/NASHORN-737.js
! test/script/basic/NASHORN-737.js.EXPECTED
+ test/script/basic/parser/assignmentExpr.js
+ test/script/basic/parser/assignmentExpr.js.EXPECTED
+ test/script/basic/parser/binaryExpr.js
+ test/script/basic/parser/binaryExpr.js.EXPECTED
+ test/script/basic/parser/breakStat.js
+ test/script/basic/parser/breakStat.js.EXPECTED
+ test/script/basic/parser/condExpr.js
+ test/script/basic/parser/condExpr.js.EXPECTED
+ test/script/basic/parser/continueStat.js
+ test/script/basic/parser/continueStat.js.EXPECTED
+ test/script/basic/parser/debuggerStat.js
+ test/script/basic/parser/debuggerStat.js.EXPECTED
+ test/script/basic/parser/functions.js
+ test/script/basic/parser/functions.js.EXPECTED
+ test/script/basic/parser/ifStat.js
+ test/script/basic/parser/ifStat.js.EXPECTED
+ test/script/basic/parser/labelledStat.js
+ test/script/basic/parser/labelledStat.js.EXPECTED
+ test/script/basic/parser/lhsExpr.js
+ test/script/basic/parser/lhsExpr.js.EXPECTED
+ test/script/basic/parser/loopStat.js
+ test/script/basic/parser/loopStat.js.EXPECTED
+ test/script/basic/parser/objectLitExpr.js
+ test/script/basic/parser/objectLitExpr.js.EXPECTED
+ test/script/basic/parser/parenExpr.js
+ test/script/basic/parser/parenExpr.js.EXPECTED
+ test/script/basic/parser/primaryExpr.js
+ test/script/basic/parser/primaryExpr.js.EXPECTED
+ test/script/basic/parser/returnStat.js
+ test/script/basic/parser/returnStat.js.EXPECTED
+ test/script/basic/parser/switchStat.js
+ test/script/basic/parser/switchStat.js.EXPECTED
+ test/script/basic/parser/throwStat.js
+ test/script/basic/parser/throwStat.js.EXPECTED
+ test/script/basic/parser/tryCatchStat.js
+ test/script/basic/parser/tryCatchStat.js.EXPECTED
+ test/script/basic/parser/unaryExpr.js
+ test/script/basic/parser/unaryExpr.js.EXPECTED
+ test/script/basic/parser/useStrict.js
+ test/script/basic/parser/useStrict.js.EXPECTED
+ test/script/basic/parser/util.js
+ test/script/basic/parser/varDecl.js
+ test/script/basic/parser/varDecl.js.EXPECTED
+ test/script/basic/parser/withStat.js
+ test/script/basic/parser/withStat.js.EXPECTED

Changeset: 8b0914b25430
Author:    sundar
Date:      2013-09-13 16:45 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8b0914b25430

8024619: JDBC java.sql.DriverManager is not usable from JS script
Reviewed-by: jlaskey, lagergren, attila

! make/build.xml
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/NashornLoader.java
! src/jdk/nashorn/internal/runtime/ScriptLoader.java
! src/jdk/nashorn/internal/runtime/StructureLoader.java
+ test/script/basic/JDK-8024619.js
+ test/src/META-INF/services/java.sql.Driver
+ test/src/jdk/nashorn/api/NashornSQLDriver.java

Changeset: 5683eca2967a
Author:    sundar
Date:      2013-09-13 17:50 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5683eca2967a

Merge




From joel.franck at oracle.com  Fri Sep 13 12:55:30 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 13 Sep 2013 14:55:30 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: <5232F3D4.6030405@gmail.com>
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
	<20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
	<5232E66A.1020606@gmail.com> <5232F3D4.6030405@gmail.com>
Message-ID: <3991193F-7656-4075-AA3F-4B1665C6140B@oracle.com>

Hi Peter,

Interesting case, thanks for the testing.

On Sep 13, 2013, at 1:15 PM, Peter Levart  wrote:

> On 09/13/2013 12:18 PM, Peter Levart wrote:
>> The C.class.getMethods() returns a 1 element array containing A.m(), but C.class.getMethod("m") throws NoSuchMethodException.
>> 
>> This seems inconsistent, but it's a corner case that can only happen with separate compilation. 
> 
> Sorry Joel, I must have tested the unpatched code for C.class.getMethods(). In is in fact consistent with C.calss.getMethod("m"). Both calls don't return the A.m() method. in getMethod("m") case the recursion is stoped when B.m() static method is encountered and in getMethods() case the inherited method A.m() is removed from inheritedMethods array by the following in privateGetPublicMethods():
> 
>        // Filter out all local methods from inherited ones
>        for (int i = 0; i < methods.length(); i++) {
>            Method m = methods.get(i);
>            inheritedMethods.removeByNameAndSignature(m);
>        }
> 
> ...when collecting B's methods...
> 
> But the question remains whether A.m() should be seen by invokeinterface C.m() in spite of the fact that there is static B.m() in between and whether reflection should follow that.

I can't see any reason why an invokeinterface C.m() should not find a default method just because there is a static method with the same name and sig "in between". However the separate compilation setup required to arrange this is non-trivial in itself :)

I also believe that reflection should accommodate separate compilation to the best extent possible. In this case I would prefer if A.m() were found and I think the fix in both reasonably small and without compatibility concerns since this is new territory.

cheers
/Joel

From peter.levart at gmail.com  Fri Sep 13 13:18:57 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Sep 2013 15:18:57 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: <3991193F-7656-4075-AA3F-4B1665C6140B@oracle.com>
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
	<20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
	<5232E66A.1020606@gmail.com> <5232F3D4.6030405@gmail.com>
	<3991193F-7656-4075-AA3F-4B1665C6140B@oracle.com>
Message-ID: <523310C1.1020304@gmail.com>

On 09/13/2013 02:55 PM, Joel Borggr?n-Franck wrote:
> Hi Peter,
>
> Interesting case, thanks for the testing.
>
> On Sep 13, 2013, at 1:15 PM, Peter Levart  wrote:
>
>> On 09/13/2013 12:18 PM, Peter Levart wrote:
>>> The C.class.getMethods() returns a 1 element array containing A.m(), but C.class.getMethod("m") throws NoSuchMethodException.
>>>
>>> This seems inconsistent, but it's a corner case that can only happen with separate compilation.
>> Sorry Joel, I must have tested the unpatched code for C.class.getMethods(). In is in fact consistent with C.calss.getMethod("m"). Both calls don't return the A.m() method. in getMethod("m") case the recursion is stoped when B.m() static method is encountered and in getMethods() case the inherited method A.m() is removed from inheritedMethods array by the following in privateGetPublicMethods():
>>
>>         // Filter out all local methods from inherited ones
>>         for (int i = 0; i < methods.length(); i++) {
>>             Method m = methods.get(i);
>>             inheritedMethods.removeByNameAndSignature(m);
>>         }
>>
>> ...when collecting B's methods...
>>
>> But the question remains whether A.m() should be seen by invokeinterface C.m() in spite of the fact that there is static B.m() in between and whether reflection should follow that.
> I can't see any reason why an invokeinterface C.m() should not find a default method just because there is a static method with the same name and sig "in between". However the separate compilation setup required to arrange this is non-trivial in itself :)

It is non-trivial to arrange in a unit test. See the following for one 
possible trick:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/test/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java.html

It's expectable that such situations will arise in practice. interface A 
can be a part of a vendor X library that's adding default methods in a 
new release, for example, and B & C can be part of a vendor Y app that 
is using the library...

Regards, Peter

>
> I also believe that reflection should accommodate separate compilation to the best extent possible. In this case I would prefer if A.m() were found and I think the fix in both reasonably small and without compatibility concerns since this is new territory.
>
> cheers
> /Joel



From joel.franck at oracle.com  Fri Sep 13 13:38:30 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 13 Sep 2013 15:38:30 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: <523310C1.1020304@gmail.com>
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
	<20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
	<5232E66A.1020606@gmail.com> <5232F3D4.6030405@gmail.com>
	<3991193F-7656-4075-AA3F-4B1665C6140B@oracle.com>
	<523310C1.1020304@gmail.com>
Message-ID: 

On Sep 13, 2013, at 3:18 PM, Peter Levart  wrote:

> On 09/13/2013 02:55 PM, Joel Borggr?n-Franck wrote:
>> Hi Peter,
>> 
>> Interesting case, thanks for the testing.
>> 
>> On Sep 13, 2013, at 1:15 PM, Peter Levart  wrote:
>> 
>>> On 09/13/2013 12:18 PM, Peter Levart wrote:
>>>> The C.class.getMethods() returns a 1 element array containing A.m(), but C.class.getMethod("m") throws NoSuchMethodException.
>>>> 
>>>> This seems inconsistent, but it's a corner case that can only happen with separate compilation.
>>> Sorry Joel, I must have tested the unpatched code for C.class.getMethods(). In is in fact consistent with C.calss.getMethod("m"). Both calls don't return the A.m() method. in getMethod("m") case the recursion is stoped when B.m() static method is encountered and in getMethods() case the inherited method A.m() is removed from inheritedMethods array by the following in privateGetPublicMethods():
>>> 
>>>        // Filter out all local methods from inherited ones
>>>        for (int i = 0; i < methods.length(); i++) {
>>>            Method m = methods.get(i);
>>>            inheritedMethods.removeByNameAndSignature(m);
>>>        }
>>> 
>>> ...when collecting B's methods...
>>> 
>>> But the question remains whether A.m() should be seen by invokeinterface C.m() in spite of the fact that there is static B.m() in between and whether reflection should follow that.
>> I can't see any reason why an invokeinterface C.m() should not find a default method just because there is a static method with the same name and sig "in between". However the separate compilation setup required to arrange this is non-trivial in itself :)
> 
> It is non-trivial to arrange in a unit test. See the following for one possible trick:
> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/test/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java.html
> 
> It's expectable that such situations will arise in practice. interface A can be a part of a vendor X library that's adding default methods in a new release, for example, and B & C can be part of a vendor Y app that is using the library...

I fully agree this will most probably occur in practice. But the situation is more complicated for an invoke, since there must have been a A.m() present when C was compiled in order to have an invokeinterface to be there in the first place. Just adding a default to A won't trigger this since there won't be an invokeinterface C.m().

Something like this might do:

Compile A { void m(); }, B {} and C {} together.
Compile A { } B { static m()} together
Compile A { default m(); }

Do you have a preference for how we should do this?

cheers
/Joel

From eric.mccorkle at oracle.com  Fri Sep 13 13:40:00 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 13 Sep 2013 09:40:00 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <52321DC8.9060203@oracle.com>
References: <52321DC8.9060203@oracle.com>
Message-ID: <523315B0.2040407@oracle.com>

A new webrev is posted (and crucible updated), which actually validates
parameter names correctly.  Apologies for the last one.

On 09/12/13 16:02, Eric McCorkle wrote:
> Hello,
> 
> Please review this patch, which implements correct behavior for the
> Parameter Reflection API in the case of malformed class files.
> 
> The bug report is here:
> https://bugs.openjdk.java.net/browse/JDK-8020981
> 
> The webrev is here:
> http://cr.openjdk.java.net/~emc/8020981/
> 
> This review is also on crucible.  The ID is CR-JDK8TL-182.
> 
> Thanks,
> Eric
> 

From pbenedict at apache.org  Fri Sep 13 13:53:01 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 13 Sep 2013 08:53:01 -0500
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw
	correct exceptions
Message-ID: 

MalformedParametersException should receive a @since tag.

Additionally, the javadoc doesn't describe what it means for a parameter to
be malformed. The answer doesn't need to be exhaustive, but I think some
examples would help developers if they catch one and need to dig into class
files. Or if there's a reference point to the JLS, that would be good too.

Here's a good sample from Eric:
http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-August/000242.html

PS: I think the consistent exception hierarchy for reflective operations
should remain in tact. Although it's annoying checked exceptions exist, my
preference would be to extend from ReflectiveOperationException rather than
RuntimeException.

-- 
Cheers,
Paul


From joel.franck at oracle.com  Fri Sep 13 13:55:31 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 13 Sep 2013 15:55:31 +0200
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <523315B0.2040407@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
Message-ID: <51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>

Hi Eric,

IIRC we don't check in classfiles into the repo.

I'm not sure how we handle testing of broken class-files in jdk, but ASM might be an option, or storing the class file as an embedded byte array in the test.

cheers
/Joel

On Sep 13, 2013, at 3:40 PM, Eric McCorkle  wrote:

> A new webrev is posted (and crucible updated), which actually validates
> parameter names correctly.  Apologies for the last one.
> 
> On 09/12/13 16:02, Eric McCorkle wrote:
>> Hello,
>> 
>> Please review this patch, which implements correct behavior for the
>> Parameter Reflection API in the case of malformed class files.
>> 
>> The bug report is here:
>> https://bugs.openjdk.java.net/browse/JDK-8020981
>> 
>> The webrev is here:
>> http://cr.openjdk.java.net/~emc/8020981/
>> 
>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>> 
>> Thanks,
>> Eric
>> 



From eric.mccorkle at oracle.com  Fri Sep 13 14:49:48 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 13 Sep 2013 10:49:48 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
Message-ID: <5233260C.3010607@oracle.com>

There is no simple means of generating bad class files for testing.
This is a huge deficiency in our testing abilities.

If these class files shouldn't go in, then I'm left with no choice but
to check in no test for this patch.

However, anyone can run the test I've provided with the class files and
see that it works.

On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
> Hi Eric,
> 
> IIRC we don't check in classfiles into the repo.
> 
> I'm not sure how we handle testing of broken class-files in jdk, but ASM might be an option, or storing the class file as an embedded byte array in the test.
> 
> cheers
> /Joel
> 
> On Sep 13, 2013, at 3:40 PM, Eric McCorkle  wrote:
> 
>> A new webrev is posted (and crucible updated), which actually validates
>> parameter names correctly.  Apologies for the last one.
>>
>> On 09/12/13 16:02, Eric McCorkle wrote:
>>> Hello,
>>>
>>> Please review this patch, which implements correct behavior for the
>>> Parameter Reflection API in the case of malformed class files.
>>>
>>> The bug report is here:
>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~emc/8020981/
>>>
>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>
>>> Thanks,
>>> Eric
>>>
> 

From joel.franck at oracle.com  Fri Sep 13 14:55:08 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 13 Sep 2013 16:55:08 +0200
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <5233260C.3010607@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
Message-ID: <6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>

I think the right thing to do is to include the original compiling source in a comment, together with a comment on how you modify them, and then the result as a byte array.

IIRC I have seen test of that kind before somewhere in our repo.

cheers
/Joel

On Sep 13, 2013, at 4:49 PM, Eric McCorkle  wrote:

> There is no simple means of generating bad class files for testing.
> This is a huge deficiency in our testing abilities.
> 
> If these class files shouldn't go in, then I'm left with no choice but
> to check in no test for this patch.
> 
> However, anyone can run the test I've provided with the class files and
> see that it works.
> 
> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>> Hi Eric,
>> 
>> IIRC we don't check in classfiles into the repo.
>> 
>> I'm not sure how we handle testing of broken class-files in jdk, but ASM might be an option, or storing the class file as an embedded byte array in the test.
>> 
>> cheers
>> /Joel
>> 
>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle  wrote:
>> 
>>> A new webrev is posted (and crucible updated), which actually validates
>>> parameter names correctly.  Apologies for the last one.
>>> 
>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>> Hello,
>>>> 
>>>> Please review this patch, which implements correct behavior for the
>>>> Parameter Reflection API in the case of malformed class files.
>>>> 
>>>> The bug report is here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>> 
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>> 
>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>> 
>>>> Thanks,
>>>> Eric
>>>> 
>> 
> 



From alexander.zuev at oracle.com  Fri Sep 13 16:25:58 2013
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Fri, 13 Sep 2013 20:25:58 +0400
Subject: RFR 8017248: Compiler Diacritics Issue
Message-ID: <52333C96.3040209@oracle.com>

I need a review for this simple change.

   The problem here is that on Mac the file names with composite letters 
(like letters with diacritic symbols)
are being kept in the Normalized Form Decomposed, so if file contains 
class with the Composed name the
command-line utility or badly configured IDE may provide to the java 
command the incorrectly created class name
(derived from what the OS says the .class file name is) hence we got 
ClassNotFound for the main class.

   The solution would be to catch the ClassNotFoundException during 
initialization of the main class
and try it again with "properly" normalized name and only if it fails 
for the second time to issue an error.
I don't think this approach may cause any regressions but i have tried 
all the related tests and seems
there are no new failures with this change.

   Since i haven't found a way of writing a regression test that is 
stable on different locales even on Mac OS
(not speaking about other OS'es) there will be no regression test for 
this issue.

   Webrev can be found at: 
http://cr.openjdk.java.net/~kizune/8017248/webrev.00

   Bug description is: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017248

/Alex


From brent.christian at oracle.com  Fri Sep 13 17:20:14 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 13 Sep 2013 10:20:14 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: <36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com>
References: <5228F7F0.8080605@oracle.com>
	<36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com>
Message-ID: <5233494E.3000309@oracle.com>

Replying to Alan and Mike...

On 9/6/13 2:27 AM, Alan Bateman wrote:
> On 05/09/2013 22:30, Brent Christian wrote:
 >
> I don't know Cocoa memory management but from a quick look at the
> NSAutoreleasePool docs then what you seems to be right. Folks on
> macosx-port-dev would be better to comment on that.

Perhaps Dave could comment?

> I see that createUTF8CString doesn't handle malloc failing and it's
> not clear how CFStringGetCString behaves when called with NULL. In
> any case, this is all early startup and if we have malloc failing
> this early then we aren't going to get very far.

Right.

> One comment on the error case (fallback to "?") as this is now
> duplicated. It might be better to have this fallback in one place
> (GetJavaProperties) as I'm pretty sure we'll need to re-examine it
> at some point

Done, new webrev is here:

http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/


On 9/6/13 4:09 PM, Mike Duigou wrote:
>
> I am surprised that strdup isn't needed for the constant "?" string
> but java_props_md.c seems to include other constant strings in sprops
> so I will assume it is just never deallocated in the lifetime of the
> JVM.

My understanding is that C string literals go into static storage, and 
live for the life of the program.


Thanks,
-Brent


From peter.levart at gmail.com  Fri Sep 13 17:30:40 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Sep 2013 19:30:40 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: 
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
	<20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
	<5232E66A.1020606@gmail.com> <5232F3D4.6030405@gmail.com>
	<3991193F-7656-4075-AA3F-4B1665C6140B@oracle.com>
	<523310C1.1020304@gmail.com>
	
Message-ID: <52334BC0.9050300@gmail.com>


On 09/13/2013 03:38 PM, Joel Borggr?n-Franck wrote:
> I fully agree this will most probably occur in practice. But the situation is more complicated for an invoke, since there must have been a A.m() present when C was compiled in order to have an invokeinterface to be there in the first place. Just adding a default to A won't trigger this since there won't be an invokeinterface C.m().
>
> Something like this might do:
>
> Compile A { void m(); }, B {} and C {} together.
> Compile A { } B { static m()} together
> Compile A { default m(); }
>
> Do you have a preference for how we should do this?
>
> cheers
> /Joel

Something like that, yes:

http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/StaticInterfaceMethodInWayOfDefault.java


It shows that VM throws IncompatibleClassChangeError if at invoke time 
the search for method encounters a static method in it's path. Is this 
correct behavior? Should reflection also throw a similar exception? This 
could only be done when requesting a specific method (getMethod(name, 
parameterTypes)), but what to do with getMethods() then?

Running using _v1 classes:
C.m() called
Running using _v2 classes:
Exception in thread "main" java.lang.IncompatibleClassChangeError: 
Expecting non-static method StaticInterfaceMethodInWayOfDefault$B.m()V
     at 
StaticInterfaceMethodInWayOfDefault$TestTask$1.m(StaticInterfaceMethodInWayOfDefault.java)
     at 
StaticInterfaceMethodInWayOfDefault$TestTask.run(StaticInterfaceMethodInWayOfDefault.java:36)
     at 
StaticInterfaceMethodInWayOfDefault.main(StaticInterfaceMethodInWayOfDefault.java:55)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
     at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.lang.reflect.Method.invoke(Method.java:491)
     at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)



Regards, Peter



From eric.mccorkle at oracle.com  Fri Sep 13 17:35:41 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 13 Sep 2013 13:35:41 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
Message-ID: <52334CED.1030900@oracle.com>

Ugh.  Byte arrays of class file data is really a horrible solution.

I have already filed a task for test development post ZBB to develop a
solution for generating bad class files.  I'd prefer to file a follow-up
to this to add the bad class file tests when that's done.

On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
> I think the right thing to do is to include the original compiling source in a comment, together with a comment on how you modify them, and then the result as a byte array.
> 
> IIRC I have seen test of that kind before somewhere in our repo.
> 
> cheers
> /Joel
> 
> On Sep 13, 2013, at 4:49 PM, Eric McCorkle  wrote:
> 
>> There is no simple means of generating bad class files for testing.
>> This is a huge deficiency in our testing abilities.
>>
>> If these class files shouldn't go in, then I'm left with no choice but
>> to check in no test for this patch.
>>
>> However, anyone can run the test I've provided with the class files and
>> see that it works.
>>
>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>> Hi Eric,
>>>
>>> IIRC we don't check in classfiles into the repo.
>>>
>>> I'm not sure how we handle testing of broken class-files in jdk, but ASM might be an option, or storing the class file as an embedded byte array in the test.
>>>
>>> cheers
>>> /Joel
>>>
>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle  wrote:
>>>
>>>> A new webrev is posted (and crucible updated), which actually validates
>>>> parameter names correctly.  Apologies for the last one.
>>>>
>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this patch, which implements correct behavior for the
>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>
>>>>> The bug report is here:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>
>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>
>> 
> 

From david.dehaven at oracle.com  Fri Sep 13 17:36:20 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 13 Sep 2013 10:36:20 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: <5233494E.3000309@oracle.com>
References: <5228F7F0.8080605@oracle.com>
	<36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com>
	<5233494E.3000309@oracle.com>
Message-ID: 


>> I don't know Cocoa memory management but from a quick look at the
>> NSAutoreleasePool docs then what you seems to be right. Folks on
>> macosx-port-dev would be better to comment on that.
> 
> Perhaps Dave could comment?

The use of NSAutoreleasePool is fine in this case.


>> I see that createUTF8CString doesn't handle malloc failing and it's
>> not clear how CFStringGetCString behaves when called with NULL. In
>> any case, this is all early startup and if we have malloc failing
>> this early then we aren't going to get very far.
> 
> Right.

CFStringGetCString does not handle NULL CFString, it will seg fault. We do a NULL check before calling it though so we're safe.


>> One comment on the error case (fallback to "?") as this is now
>> duplicated. It might be better to have this fallback in one place
>> (GetJavaProperties) as I'm pretty sure we'll need to re-examine it
>> at some point
> 
> Done, new webrev is here:
> 
> http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/

Everything looks fine to me.



>> I am surprised that strdup isn't needed for the constant "?" string
>> but java_props_md.c seems to include other constant strings in sprops
>> so I will assume it is just never deallocated in the lifetime of the
>> JVM.
> 
> My understanding is that C string literals go into static storage, and live for the life of the program.

Yes, they end up in a read-only TEXT section of the executable, they cannot be deallocated without unloading the entire binary.

-DrD-



From mike.duigou at oracle.com  Fri Sep 13 17:43:31 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Sep 2013 10:43:31 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: <5233494E.3000309@oracle.com>
References: <5228F7F0.8080605@oracle.com>
	<36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com>
	<5233494E.3000309@oracle.com>
Message-ID: 


On Sep 13 2013, at 10:20 , Brent Christian wrote:

>> Done, new webrev is here:
> 
> http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/
> 
> 
> On 9/6/13 4:09 PM, Mike Duigou wrote:
>> 
>> I am surprised that strdup isn't needed for the constant "?" string
>> but java_props_md.c seems to include other constant strings in sprops
>> so I will assume it is just never deallocated in the lifetime of the
>> JVM.
> 
> My understanding is that C string literals go into static storage, and live for the life of the program.

My concern was mostly that nobody ever attempts to call free(sprops.user_home) which does't seem to happen.

Mike

From david.dehaven at oracle.com  Fri Sep 13 17:54:19 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 13 Sep 2013 10:54:19 -0700
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: 
References: <5228F7F0.8080605@oracle.com>
	<36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com>
	<5233494E.3000309@oracle.com>
	
Message-ID: <942FA6A0-C30F-4BB2-8509-4ECFB63F79A3@oracle.com>


>>> Done, new webrev is here:
>> 
>> http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/
>> 
>> 
>> On 9/6/13 4:09 PM, Mike Duigou wrote:
>>> 
>>> I am surprised that strdup isn't needed for the constant "?" string
>>> but java_props_md.c seems to include other constant strings in sprops
>>> so I will assume it is just never deallocated in the lifetime of the
>>> JVM.
>> 
>> My understanding is that C string literals go into static storage, and live for the life of the program.
> 
> My concern was mostly that nobody ever attempts to call free(sprops.user_home) which does't seem to happen.

Does it happen for the other strdup'ed fields? I didn't look at the code deeply enough to answer it myself... at first glance it doesn't introduce any leaks that weren't already there.

-DrD-



From peter.levart at gmail.com  Fri Sep 13 17:54:30 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Sep 2013 19:54:30 +0200
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <52334CED.1030900@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com>
Message-ID: <52335156.3050308@gmail.com>

Hi Eric,

How did you create those class files? By hand using a HEX editor? Did 
you create a program that patched the original class file? If the later 
is the case, you could pack that patching logic inside a custom 
ClassLoader...

To hacky? Dependent on future changes of javac? At least the "bad name" 
patching could be performed trivially and reliably, I think: search and 
replace with same-length string.

Regards, Peter

On 09/13/2013 07:35 PM, Eric McCorkle wrote:
> Ugh.  Byte arrays of class file data is really a horrible solution.
>
> I have already filed a task for test development post ZBB to develop a
> solution for generating bad class files.  I'd prefer to file a follow-up
> to this to add the bad class file tests when that's done.
>
> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>> I think the right thing to do is to include the original compiling source in a comment, together with a comment on how you modify them, and then the result as a byte array.
>>
>> IIRC I have seen test of that kind before somewhere in our repo.
>>
>> cheers
>> /Joel
>>
>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle  wrote:
>>
>>> There is no simple means of generating bad class files for testing.
>>> This is a huge deficiency in our testing abilities.
>>>
>>> If these class files shouldn't go in, then I'm left with no choice but
>>> to check in no test for this patch.
>>>
>>> However, anyone can run the test I've provided with the class files and
>>> see that it works.
>>>
>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>> Hi Eric,
>>>>
>>>> IIRC we don't check in classfiles into the repo.
>>>>
>>>> I'm not sure how we handle testing of broken class-files in jdk, but ASM might be an option, or storing the class file as an embedded byte array in the test.
>>>>
>>>> cheers
>>>> /Joel
>>>>
>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle  wrote:
>>>>
>>>>> A new webrev is posted (and crucible updated), which actually validates
>>>>> parameter names correctly.  Apologies for the last one.
>>>>>
>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review this patch, which implements correct behavior for the
>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>
>>>>>> The bug report is here:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>
>>>>>> The webrev is here:
>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>
>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>
>>>>>> Thanks,
>>>>>> Eric
>>>>>>
>>> 



From eric.mccorkle at oracle.com  Fri Sep 13 18:54:26 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 13 Sep 2013 14:54:26 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <52335156.3050308@gmail.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
Message-ID: <52335F62.1040305@oracle.com>

I did it by hand with emacs.

I would really rather tackle the bad class files for testing issue once
and for all, the Right Way (tm).  But with ZBB looming, now is not the
time to do it.

Hence, I have created this task
https://bugs.openjdk.java.net/browse/JDK-8024674

I also just created this one:
https://bugs.openjdk.java.net/browse/JDK-8024812

On 09/13/13 13:54, Peter Levart wrote:
> Hi Eric,
> 
> How did you create those class files? By hand using a HEX editor? Did
> you create a program that patched the original class file? If the later
> is the case, you could pack that patching logic inside a custom
> ClassLoader...
> 
> To hacky? Dependent on future changes of javac? At least the "bad name"
> patching could be performed trivially and reliably, I think: search and
> replace with same-length string.
> 
> Regards, Peter
> 
> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>
>> I have already filed a task for test development post ZBB to develop a
>> solution for generating bad class files.  I'd prefer to file a follow-up
>> to this to add the bad class file tests when that's done.
>>
>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>>> I think the right thing to do is to include the original compiling source in a comment, together with a comment on how you modify them, and then the result as a byte array.
>>>
>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>
>>> cheers
>>> /Joel
>>>
>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle  wrote:
>>>
>>>> There is no simple means of generating bad class files for testing.
>>>> This is a huge deficiency in our testing abilities.
>>>>
>>>> If these class files shouldn't go in, then I'm left with no choice but
>>>> to check in no test for this patch.
>>>>
>>>> However, anyone can run the test I've provided with the class files and
>>>> see that it works.
>>>>
>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>>> Hi Eric,
>>>>>
>>>>> IIRC we don't check in classfiles into the repo.
>>>>>
>>>>> I'm not sure how we handle testing of broken class-files in jdk, but ASM might be an option, or storing the class file as an embedded byte array in the test.
>>>>>
>>>>> cheers
>>>>> /Joel
>>>>>
>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle  wrote:
>>>>>
>>>>>> A new webrev is posted (and crucible updated), which actually validates
>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>
>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review this patch, which implements correct behavior for the
>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>
>>>>>>> The bug report is here:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>
>>>>>>> The webrev is here:
>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>
>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Eric
>>>>>>>
>>>> 
> 

From mike.duigou at oracle.com  Fri Sep 13 19:02:30 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 13 Sep 2013 19:02:30 +0000
Subject: hg: jdk8/tl/jdk: 3 new changesets
Message-ID: <20130913190310.4344162806@hg.openjdk.java.net>

Changeset: c65848f2b6a1
Author:    mduigou
Date:      2013-09-13 11:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c65848f2b6a1

8021591: Additional explicit null checks
Reviewed-by: psandoz, alanb

! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/javax/security/auth/Subject.java
! test/java/util/Collection/CollectionDefaults.java
- test/java/util/Collection/ListDefaults.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collection/testlibrary/CollectionAsserts.java
! test/java/util/Collection/testlibrary/CollectionSupplier.java
+ test/java/util/Collection/testlibrary/ExtendsAbstractCollection.java
+ test/java/util/Collection/testlibrary/ExtendsAbstractList.java
+ test/java/util/Collection/testlibrary/ExtendsAbstractSet.java
+ test/java/util/List/ListDefaults.java
! test/java/util/Map/Defaults.java

Changeset: 973fdd9506b2
Author:    mduigou
Date:      2013-09-13 11:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/973fdd9506b2

8024014: TEST.groups - split sub-groups for jdk_collections, jdk_stream, jdk_concurrent, jdk_util_other from jdk_util
Reviewed-by: mchung, dholmes, alanb

! test/TEST.groups

Changeset: 5f81a12fed4d
Author:    bchristi
Date:      2013-09-13 11:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f81a12fed4d

7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]
Summary: On MacOS X set user.home to value of NSHomeDirectory()
Reviewed-by: alanb, ddehaven, mduigou

! make/common/Defs-macosx.gmk
! make/java/java/Makefile
! makefiles/CompileNativeLibraries.gmk
! src/solaris/native/java/lang/java_props_macosx.c
! src/solaris/native/java/lang/java_props_macosx.h
! src/solaris/native/java/lang/java_props_md.c



From roger.riggs at oracle.com  Fri Sep 13 19:07:17 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 13 Sep 2013 15:07:17 -0400
Subject: Please review two corrections for java.time
In-Reply-To: <522F7BD4.8060006@oracle.com>
References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com>
	<522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com>
	<522E24C3.8040607@oracle.com> <522EBFA9.6070703@gmail.com>
	<522F27C1.5010703@oracle.com> <522F4664.7040104@gmail.com>
	<522F7BD4.8060006@oracle.com>
Message-ID: <52336265.7090607@oracle.com>

Ping, Reviewer needed for these minor updates, the test is now more 
robust thanks to Peter's nudging.

http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/

Please review for two corrections:

-  The java/time/tck/java/time/TCKLocalTime test failed on a slow 
runtime due to -Xcomp;
     the test should be more lenient.   The test is not appropriate for 
a conformance test
     and is moved to java/time/test/java/time/TestLocalTime and is 
updated to be
     more robust in the face of DST changes.

- The javadoc for the JapaneseEra.MEIJI era should indicate the start 
date is 1868-01-01
   to be consistent with java.util.Calendar.  Note that java.time does 
not permit dates before Meiji 6
   to be created since the calendar is not clearly defined until then.

Thanks, Roger







From mike.duigou at oracle.com  Fri Sep 13 19:07:28 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 13 Sep 2013 19:07:28 +0000
Subject: hg: jdk8/tl: 8024201: Update bugdatabase url
Message-ID: <20130913190729.46E1562807@hg.openjdk.java.net>

Changeset: 67f64101616e
Author:    mduigou
Date:      2013-09-13 12:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/67f64101616e

8024201: Update bugdatabase url
Reviewed-by: wetmore

! make/scripts/webrev.ksh



From mike.duigou at oracle.com  Fri Sep 13 19:17:28 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Sep 2013 12:17:28 -0700
Subject: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to
	removeAll(Predicate)
In-Reply-To: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com>
References: <453DE051-0814-453F-A71A-27EE9E574514@oracle.com>
Message-ID: <8E26211C-A60E-479D-884D-860549F88130@oracle.com>

Based upon feedback we've decided to withdraw this change. It will remain removeIf()

Mike

On Sep 4 2013, at 14:08 , Mike Duigou wrote:

> Hello all;
> 
> The naming of the Collection.removeIf(Predicate) method has always been an uncertain choice. We've gone back and forth between naming it removeIf and overloading the existing removeAll(Collection) with a removeAll(Predicate). Now that all other library and language decisions seem to be settled it seems reasonable to make a final decision on this method naming. 
> 
> This patch proposes to use the removeAll(Predicate) overload. This choice is made to increase the discoverability of the method and to "reuse" the existing user understanding of the removeAll name. There is a minor source incompatibility induced by overloading the removeAll name--if explicit null is passed then a compiler cannot resolve which overload to use. Since null is not a legal value for either overload this source incompatibility is expected to only affect tests which check to see what response implementations return for null. The ambiguity can be resolved by providing a cast to either the Collection or Predicate types to select the appropriate overload.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/
> 
> Thanks,
> 
> Mike



From eric.mccorkle at oracle.com  Fri Sep 13 19:28:57 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 13 Sep 2013 15:28:57 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: 
References: 
Message-ID: <52336779.3000407@oracle.com>

On 09/13/13 09:53, Paul Benedict wrote:
> MalformedParametersException should receive a @since tag.
> 
> Additionally, the javadoc doesn't describe what it means for a parameter to
> be malformed. The answer doesn't need to be exhaustive, but I think some
> examples would help developers if they catch one and need to dig into class
> files. Or if there's a reference point to the JLS, that would be good too.
> 
> Here's a good sample from Eric:
> http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-August/000242.html

I updated the javadoc comments with a list taken from my earlier email
you referenced, and I added more comments to MalformedParametersException.

> 
> PS: I think the consistent exception hierarchy for reflective operations
> should remain in tact. Although it's annoying checked exceptions exist, my
> preference would be to extend from ReflectiveOperationException rather than
> RuntimeException.

If you have spec issues, please take them up on
enhanced-metadata-discuss.  I am not the spec owner.

From xueming.shen at oracle.com  Fri Sep 13 19:44:18 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 13 Sep 2013 12:44:18 -0700
Subject: RFR: 8920687: Deflater.setLevel does not work as expected
Message-ID: <52336B12.3040106@oracle.com>

Hi,

This is change to clarify the java doc to match the existing behavior.

If there is a "pending" level/strategy change (via setLevel/Stragety()) when
deflate(...) is invoked, the implementation goes down to zlib's 
deflateParams()
for deflating operation, which clearly specifies its behavior in zlib.h as

----------------------------------------------------------------
    Dynamically update the compression level and compression strategy.  The
    interpretation of level and strategy is as in deflateInit2.  This can be
    used to switch between compression and straight copy of the input 
data, or
    to switch to a different kind of input data requiring a different 
strategy.
    If the compression level is changed, the input available so far is
    compressed with the old level (and may be flushed); the new level 
will take
    effect only at the next call of deflate().
-----------------------------------------------------------------

and its corresponding implementation does exactly that.

Note, the zlib.h doc does not explicitly mention the "strategy", but 
it's implementation
treat the strategy and level the same way. The code looks like

-----------------------------------------------------------------
int ZEXPORT deflateParams(strm, level, strategy)
     z_streamp strm;
     int level;
     int strategy;
{
     deflate_state *s;
     compress_func func;
     int err = Z_OK;

     if (strm == Z_NULL || strm->state == Z_NULL) return Z_STREAM_ERROR;
     s = strm->state;

#ifdef FASTEST
     if (level != 0) level = 1;
#else
     if (level == Z_DEFAULT_COMPRESSION) level = 6;
#endif
     if (level < 0 || level > 9 || strategy < 0 || strategy > Z_FIXED) {
         return Z_STREAM_ERROR;
     }
     func = configuration_table[s->level].func;

     if ((strategy != s->strategy || func != 
configuration_table[level].func) &&
         strm->total_in != 0) {
         /* Flush the last buffer: */
         err = deflate(strm, Z_BLOCK);
     }
     if (s->level != level) {
         s->level = level;
         s->max_lazy_match   = configuration_table[level].max_lazy;
         s->good_match       = configuration_table[level].good_length;
         s->nice_match       = configuration_table[level].nice_length;
         s->max_chain_length = configuration_table[level].max_chain;
     }
     s->strategy = strategy;
     return err;
}
-------------------------------------------------------------------

The proposed change here is to add some words to clarify the expected 
behavior,
in which the next deflate() invocation after the setLevel/Strategy() 
will just finish
any left input (and may flush the buffer out). The new level/strategy 
will take
effect after that.

http://cr.openjdk.java.net/~sherman/8020687/webrev/

Thanks,
-Sherman




From Lance.Andersen at oracle.com  Fri Sep 13 20:40:21 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 13 Sep 2013 16:40:21 -0400
Subject: review request 7097386:  Correct error in Predicate javadoc example
Message-ID: <506F739C-C68A-4F54-9777-0048CBB29968@oracle.com>

Hi Everyone,

Looking for a reviewer for this trivial fix to correct the sample example in the Predicate javadoc for the evaluate method()


------------------
!hg
hg diff Predicate.java 
diff -r 60d6f60416ca src/share/classes/javax/sql/rowset/Predicate.java
--- a/src/share/classes/javax/sql/rowset/Predicate.java	Thu Sep 12 13:20:26 2013 -0400
+++ b/src/share/classes/javax/sql/rowset/Predicate.java	Fri Sep 13 16:30:07 2013 -0400
@@ -56,44 +56,42 @@
  * 
{@code
  *    public class Range implements Predicate {
  *
- *       private Object lo[];
- *       private Object hi[];
+ *       private int lo[];
+ *       private int hi[];
  *       private int idx[];
  *
- *       public Range(Object[] lo, Object[] hi, int[] idx) {
+ *       public Range(int[] lo, int[] hi, int[] idx) {
  *          this.lo = lo;
  *          this.hi = hi;
  *          this.idx = idx;
  *       }
  *
  *      public boolean evaluate(RowSet rs) {
- *          CachedRowSet crs = (CachedRowSet)rs;
- *          boolean bool1,bool2;
  *
  *          // Check the present row determine if it lies
  *          // within the filtering criteria.
  *
  *          for (int i = 0; i < idx.length; i++) {
+ *             int value = 0;
+ *             try {
+ *                 value = (Integer) rs.getObject(idx[i]);
+ *             } catch (SQLException ex) {
+ *                 Logger.getLogger(Range.class.getName()).log(Level.SEVERE, null, ex);
+ *             }
  *
- *              if ((rs.getObject(idx[i]) >= lo[i]) &&
- *                  (rs.getObject(idx[i]) >= hi[i]) {
- *                  bool1 = true; // within filter constraints
- *              } else {
- *                  bool2 = true; // outside of filter constraints
- *              }
- *          }
- *
- *          if (bool2) {
- *             return false;
- *          } else {
- *             return true;
- *          }
+ *             if (value < lo[i] && value > hi[i]) {
+ *                 // outside of filter constraints
+ *                 return false; 
+ *             }
+ *         }
+ *         // Within filter constraints
+ *        return true;
  *      }
- *  }
+ *   }
  * }

  * 

  * The example above implements a simple range predicate. Note, that
- * implementations should but are not required to provider String
+ * implementations should but are not required to provide String
  * and integer index based constructors to provide for JDBC RowSet Implementation
  * applications that use both column identification conventions.
  *


-----------------

Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From mike.duigou at oracle.com  Fri Sep 13 21:52:33 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Sep 2013 14:52:33 -0700
Subject: RFR: 8023339: (xs) Refine UOE conditions for removeIf()
Message-ID: 

Hello all;

A very small patch that refines the declared conditions under which the Collection.removeIf() method will throw UOE. The intent of this patch is to allow the default implementation to be used for immutable collections. It's important that the default implementations provided and the specifications of the methods allow for the behaviour which results from using the default method implementation on any reasonable implementation including immutable implementations. In this case there was a bug originally written against j.u.Arrays.asList() The bug asserted that it's removeIf() implementation was "lazy" and only throws UOE when an element is to be removed. One possible solution was to add a non-default implementation of removeIf() to the Arrays.asList()-List. Since the default method definition must also satisfy other potential immutable implementations we decided to enhance the UOE conditions rather than paper over the problem by adding a default.

(There are a couple of other similar issues which will have similar solutions)

http://cr.openjdk.java.net/~mduigou/JDK-8023339/1/

Mike

From joe.darcy at oracle.com  Fri Sep 13 23:52:09 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 13 Sep 2013 16:52:09 -0700
Subject: Please review two corrections for java.time
In-Reply-To: <52336265.7090607@oracle.com>
References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com>
	<522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com>
	<522E24C3.8040607@oracle.com> <522EBFA9.6070703@gmail.com>
	<522F27C1.5010703@oracle.com> <522F4664.7040104@gmail.com>
	<522F7BD4.8060006@oracle.com> <52336265.7090607@oracle.com>
Message-ID: <5233A529.7000003@oracle.com>

Looks fine; cheers,

-Joe

On 9/13/2013 12:07 PM, roger riggs wrote:
> Ping, Reviewer needed for these minor updates, the test is now more 
> robust thanks to Peter's nudging.
>
> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>
> Please review for two corrections:
>
> -  The java/time/tck/java/time/TCKLocalTime test failed on a slow 
> runtime due to -Xcomp;
>     the test should be more lenient.   The test is not appropriate for 
> a conformance test
>     and is moved to java/time/test/java/time/TestLocalTime and is 
> updated to be
>     more robust in the face of DST changes.
>
> - The javadoc for the JapaneseEra.MEIJI era should indicate the start 
> date is 1868-01-01
>   to be consistent with java.util.Calendar.  Note that java.time does 
> not permit dates before Meiji 6
>   to be created since the calendar is not clearly defined until then.
>
> Thanks, Roger
>
>
>
>
>



From lance.andersen at oracle.com  Fri Sep 13 23:10:58 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Fri, 13 Sep 2013 23:10:58 +0000
Subject: hg: jdk8/tl/jdk: 8014967: EBehavior of
	DriverManager.registerDriver(dr) is unspecified if driver is null
Message-ID: <20130913231124.2D25B6280E@hg.openjdk.java.net>

Changeset: 5c7690923663
Author:    lancea
Date:      2013-09-13 19:10 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c7690923663

8014967: EBehavior of DriverManager.registerDriver(dr) is unspecified if driver is null
Reviewed-by: alanb

! src/share/classes/java/sql/DriverManager.java



From henry.jen at oracle.com  Sat Sep 14 00:22:35 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 13 Sep 2013 17:22:35 -0700
Subject: RFR: 8024825: Some fixes are missing from java.util.stream spec update
Message-ID: <5233AC4B.7070704@oracle.com>

Hi,

Please kindly review webrev at
http://cr.openjdk.java.net/~henryjen/tl/8024825/0/webrev/

This webrev is a typo fix + the cleanup made in lambda repo in following
changeset.
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a4babe938c8c

Summary of the changeset,
- Typo fix, Short-circuting should be Short-circuiting
- Javadoc format fix, {@code parallelStream()} cause a space
character in front of parallemStream(), use ... instead.
- remove not needed @SuppressWarnings
- formatting cleanup

Cheers,
Henry



From xueming.shen at oracle.com  Sat Sep 14 00:37:24 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 13 Sep 2013 17:37:24 -0700
Subject: Please review two corrections for java.time
In-Reply-To: <52336265.7090607@oracle.com>
References: <522A17D9.4090103@oracle.com> <522D6757.8020100@gmail.com>
	<522DC935.4080809@oracle.com> <522DE5EA.3070805@gmail.com>
	<522E24C3.8040607@oracle.com> <522EBFA9.6070703@gmail.com>
	<522F27C1.5010703@oracle.com> <522F4664.7040104@gmail.com>
	<522F7BD4.8060006@oracle.com> <52336265.7090607@oracle.com>
Message-ID: <5233AFC4.4040103@oracle.com>

looks fine.

On 9/13/13 12:07 PM, roger riggs wrote:
> Ping, Reviewer needed for these minor updates, the test is now more 
> robust thanks to Peter's nudging.
>
> http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>
> Please review for two corrections:
>
> -  The java/time/tck/java/time/TCKLocalTime test failed on a slow 
> runtime due to -Xcomp;
>     the test should be more lenient.   The test is not appropriate for 
> a conformance test
>     and is moved to java/time/test/java/time/TestLocalTime and is 
> updated to be
>     more robust in the face of DST changes.
>
> - The javadoc for the JapaneseEra.MEIJI era should indicate the start 
> date is 1868-01-01
>   to be consistent with java.util.Calendar.  Note that java.time does 
> not permit dates before Meiji 6
>   to be created since the calendar is not clearly defined until then.
>
> Thanks, Roger
>
>
>
>
>



From brian.burkhalter at oracle.com  Sat Sep 14 00:39:09 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 13 Sep 2013 17:39:09 -0700
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
	
	<52328A75.8030208@redhat.com>
	
Message-ID: 

I would suggest leaving it at 1100 for this review (JDK7) and to 768 (0x003) in JDK8. The latter will require another issue to be filed.

On Sep 12, 2013, at 9:25 PM, Dmitry Nadezhin wrote:

> For me, it is the only consideration.
> I'm sure in 768 because I proved it formally using ACL2 tool.
> 
> 
> On Fri, Sep 13, 2013 at 7:45 AM, David M. Lloyd wrote:
> 
>> If that's the only consideration then just use 0x300 instead, which is
>> easier to read *and* makes more sense anyway, in the context of the test.
>> 
>> 
>> On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote:
>> 
>>> Should we change conservative constant 1100 to optimal constant 768 ?
>>> My opinion is no (in JDK7), because the constant 1100 has lower cost of
>>> review.
>>> I mean that chances that a reviewer approves 1100 are higher than chances
>>> that [s]he approves 768.


From mike.duigou at oracle.com  Sat Sep 14 00:42:06 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Sep 2013 17:42:06 -0700
Subject: RFR: 8024825: Some fixes are missing from java.util.stream spec
	update
In-Reply-To: <5233AC4B.7070704@oracle.com>
References: <5233AC4B.7070704@oracle.com>
Message-ID: <3B046EA2-4F86-4AE5-B5F6-3A3A2B30ED2D@oracle.com>

changes look fine.

Mike
On Sep 13 2013, at 17:22 , Henry Jen wrote:

> Hi,
> 
> Please kindly review webrev at
> http://cr.openjdk.java.net/~henryjen/tl/8024825/0/webrev/
> 
> This webrev is a typo fix + the cleanup made in lambda repo in following
> changeset.
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a4babe938c8c
> 
> Summary of the changeset,
> - Typo fix, Short-circuting should be Short-circuiting
> - Javadoc format fix, {@code parallelStream()} cause a space
> character in front of parallemStream(), use ... instead.
> - remove not needed @SuppressWarnings
> - formatting cleanup
> 
> Cheers,
> Henry
> 



From joe.darcy at oracle.com  Sat Sep 14 00:45:14 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 13 Sep 2013 17:45:14 -0700
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <52321DC8.9060203@oracle.com>
References: <52321DC8.9060203@oracle.com>
Message-ID: <5233B19A.4040102@oracle.com>

On 09/12/2013 01:02 PM, Eric McCorkle wrote:
> Hello,
>
> Please review this patch, which implements correct behavior for the
> Parameter Reflection API in the case of malformed class files.
>
> The bug report is here:
> https://bugs.openjdk.java.net/browse/JDK-8020981
>
> The webrev is here:
> http://cr.openjdk.java.net/~emc/8020981/
>
> This review is also on crucible.  The ID is CR-JDK8TL-182.
>
> Thanks,
> Eric

Hi Eric,

The update to j.l.reflect.Modifiers is incorrect; the field in question 
is only supposed to encode *source* modifiers.

The new exception types needs to declare a serialVersionUID field since 
it is a serializable type (thanks RMI for making all Throwables 
serializable!).

-Joe


From joe.darcy at oracle.com  Sat Sep 14 00:48:43 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 13 Sep 2013 17:48:43 -0700
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <52335F62.1040305@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
	<52335F62.1040305@oracle.com>
Message-ID: <5233B26B.40000@oracle.com>

To avoid storing binaries in Hg, you could try something like:

* uuencode / ascii armor the class file
* convert to byte array in the test
* load classes from byte array

-Joe

On 09/13/2013 11:54 AM, Eric McCorkle wrote:
> I did it by hand with emacs.
>
> I would really rather tackle the bad class files for testing issue once
> and for all, the Right Way (tm).  But with ZBB looming, now is not the
> time to do it.
>
> Hence, I have created this task
> https://bugs.openjdk.java.net/browse/JDK-8024674
>
> I also just created this one:
> https://bugs.openjdk.java.net/browse/JDK-8024812
>
> On 09/13/13 13:54, Peter Levart wrote:
>> Hi Eric,
>>
>> How did you create those class files? By hand using a HEX editor? Did
>> you create a program that patched the original class file? If the later
>> is the case, you could pack that patching logic inside a custom
>> ClassLoader...
>>
>> To hacky? Dependent on future changes of javac? At least the "bad name"
>> patching could be performed trivially and reliably, I think: search and
>> replace with same-length string.
>>
>> Regards, Peter
>>
>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>>
>>> I have already filed a task for test development post ZBB to develop a
>>> solution for generating bad class files.  I'd prefer to file a follow-up
>>> to this to add the bad class file tests when that's done.
>>>
>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>>>> I think the right thing to do is to include the original compiling source in a comment, together with a comment on how you modify them, and then the result as a byte array.
>>>>
>>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>>
>>>> cheers
>>>> /Joel
>>>>
>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle  wrote:
>>>>
>>>>> There is no simple means of generating bad class files for testing.
>>>>> This is a huge deficiency in our testing abilities.
>>>>>
>>>>> If these class files shouldn't go in, then I'm left with no choice but
>>>>> to check in no test for this patch.
>>>>>
>>>>> However, anyone can run the test I've provided with the class files and
>>>>> see that it works.
>>>>>
>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>>>> Hi Eric,
>>>>>>
>>>>>> IIRC we don't check in classfiles into the repo.
>>>>>>
>>>>>> I'm not sure how we handle testing of broken class-files in jdk, but ASM might be an option, or storing the class file as an embedded byte array in the test.
>>>>>>
>>>>>> cheers
>>>>>> /Joel
>>>>>>
>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle  wrote:
>>>>>>
>>>>>>> A new webrev is posted (and crucible updated), which actually validates
>>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>>
>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review this patch, which implements correct behavior for the
>>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>>
>>>>>>>> The bug report is here:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>>
>>>>>>>> The webrev is here:
>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>>
>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Eric
>>>>>>>>
>>>>> 



From henry.jen at oracle.com  Sat Sep 14 01:51:41 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Sat, 14 Sep 2013 01:51:41 +0000
Subject: hg: jdk8/tl/jdk: 8024825: Some fixes are missing from
	java.util.stream spec update
Message-ID: <20130914015206.8D45562818@hg.openjdk.java.net>

Changeset: a7980b099af1
Author:    henryjen
Date:      2013-09-06 15:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7980b099af1

8024825: Some fixes are missing from java.util.stream spec update
Reviewed-by: mduigou

! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/package-info.java



From dmitry.nadezhin at gmail.com  Sat Sep 14 02:02:15 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 14 Sep 2013 06:02:15 +0400
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
	
	<52328A75.8030208@redhat.com>
	
	
Message-ID: 

I agree with 1100 for this review (JDK7).

I think that we shouldn't change from 1100 to 768 in JDK8 because this is a
small performance enhancement.
This will save time for fixing other bugs.

The performance enhancement could be smarter if we replace constant
MAX_NDIGIT by some piece-linear function
function maxNDigit(decExponent). See:
http://cr.openjdk.java.net/~bpb/nDigits/java/double.pdf
I'd like to postpone this to JDK9 .


On Sat, Sep 14, 2013 at 4:39 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> I would suggest leaving it at 1100 for this review (JDK7) and to 768
> (0x003) in JDK8. The latter will require another issue to be filed.
>
> On Sep 12, 2013, at 9:25 PM, Dmitry Nadezhin wrote:
>
> > For me, it is the only consideration.
> > I'm sure in 768 because I proved it formally using ACL2 tool.
> >
> >
> > On Fri, Sep 13, 2013 at 7:45 AM, David M. Lloyd  >wrote:
> >
> >> If that's the only consideration then just use 0x300 instead, which is
> >> easier to read *and* makes more sense anyway, in the context of the
> test.
> >>
> >>
> >> On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote:
> >>
> >>> Should we change conservative constant 1100 to optimal constant 768 ?
> >>> My opinion is no (in JDK7), because the constant 1100 has lower cost of
> >>> review.
> >>> I mean that chances that a reviewer approves 1100 are higher than
> chances
> >>> that [s]he approves 768.
>


From xueming.shen at oracle.com  Sat Sep 14 06:49:07 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 13 Sep 2013 23:49:07 -0700
Subject: RFR: 7186311: (props) "Unicode" is misspelled as "Uniocde" in JavaDoc
	and error message
Message-ID: <523406E3.6080202@oracle.com>

Hi,

Please help review this trivial javadoc typo fix.

http://cr.openjdk.java.net/~sherman/7186311/webrev

Thanks,
-Sherman


From Alan.Bateman at oracle.com  Sat Sep 14 06:52:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Sep 2013 07:52:27 +0100
Subject: RFR: 7186311: (props) "Unicode" is misspelled as "Uniocde" in
	JavaDoc and error message
In-Reply-To: <523406E3.6080202@oracle.com>
References: <523406E3.6080202@oracle.com>
Message-ID: <523407AB.1000003@oracle.com>

On 14/09/2013 07:49, Xueming Shen wrote:
> Hi,
>
> Please help review this trivial javadoc typo fix.
>
> http://cr.openjdk.java.net/~sherman/7186311/webrev
Looks good.

-Alan.


From chris.hegarty at oracle.com  Sat Sep 14 11:26:29 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 14 Sep 2013 12:26:29 +0100
Subject: RFR: 7186311: (props) "Unicode" is misspelled as "Uniocde" in
	JavaDoc and error message
In-Reply-To: <523406E3.6080202@oracle.com>
References: <523406E3.6080202@oracle.com>
Message-ID: <37C4D3DA-244F-4F72-956B-40A3725B343B@oracle.com>

I had to look at it a few times ;-) Looks fine to me.

-Chris

On 14 Sep 2013, at 07:49, Xueming Shen  wrote:

> Hi,
> 
> Please help review this trivial javadoc typo fix.
> 
> http://cr.openjdk.java.net/~sherman/7186311/webrev
> 
> Thanks,
> -Sherman


From Alan.Bateman at oracle.com  Sat Sep 14 12:24:09 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Sep 2013 13:24:09 +0100
Subject: RFR: 8920687: Deflater.setLevel does not work as expected
In-Reply-To: <52336B12.3040106@oracle.com>
References: <52336B12.3040106@oracle.com>
Message-ID: <52345569.2050308@oracle.com>

On 13/09/2013 20:44, Xueming Shen wrote:
> Hi,
>
> This is change to clarify the java doc to match the existing behavior.
>
> If there is a "pending" level/strategy change (via 
> setLevel/Stragety()) when
> deflate(...) is invoked, the implementation goes down to zlib's 
> deflateParams()
> for deflating operation, which clearly specifies its behavior in 
> zlib.h as
>
> ----------------------------------------------------------------
>    Dynamically update the compression level and compression strategy.  
> The
>    interpretation of level and strategy is as in deflateInit2.  This 
> can be
>    used to switch between compression and straight copy of the input 
> data, or
>    to switch to a different kind of input data requiring a different 
> strategy.
>    If the compression level is changed, the input available so far is
>    compressed with the old level (and may be flushed); the new level 
> will take
>    effect only at the next call of deflate().
> -----------------------------------------------------------------
>
> and its corresponding implementation does exactly that.
It seems reasonable to have new strategy or level take effect after the 
available input has been compressed.

Your proposed wording is okay but I wonder if the word "current" should 
be dropped from the existing statement in setLevel. You might also be 
able to get away with a single statement too, something like "If 
changed, the new compression strategy takes effect after the input 
available has been compressed (or flushed)". Your wording is okay too if 
you really need to be explicit about deflate being called.

-Alan




From vicente.romero at oracle.com  Sat Sep 14 14:25:15 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sat, 14 Sep 2013 14:25:15 +0000
Subject: hg: jdk8/tl/langtools: 8024207: javac crash in
	Flow.AssignAnalyzer.visitIdent
Message-ID: <20130914142518.A4D456282D@hg.openjdk.java.net>

Changeset: 03c26c60499c
Author:    vromero
Date:      2013-09-14 15:23 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/03c26c60499c

8024207: javac crash in Flow.AssignAnalyzer.visitIdent
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/T8024207/FlowCrashTest.java
+ test/tools/javac/T8024207/FlowCrashTest.out



From roger.riggs at oracle.com  Sat Sep 14 18:14:02 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Sat, 14 Sep 2013 18:14:02 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130914181439.5FDCF62830@hg.openjdk.java.net>

Changeset: 3255a4e348a1
Author:    rriggs
Date:      2013-09-14 13:55 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3255a4e348a1

8023639: Difference between LocalTime.now(Clock.systemDefaultZone()) and LocalTime.now() executed successively is more than 100 000 000 nanoseconds for slow machines
Summary: Test timed out on a slow machine; it is not a conformance test and should be in the test subtree
Reviewed-by: darcy, sherman

! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/test/java/time/TestLocalTime.java

Changeset: 35bb1c7f227c
Author:    rriggs
Date:      2013-09-14 13:55 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35bb1c7f227c

8023556: Update javadoc for start of Meiji era
Summary: correct the javadoc in JapaneseEra.MEIJI to match the implementation
Reviewed-by: darcy, sherman

! src/share/classes/java/time/chrono/JapaneseEra.java
! test/java/time/test/java/time/TestLocalTime.java



From vicente.romero at oracle.com  Sat Sep 14 18:21:30 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sat, 14 Sep 2013 18:21:30 +0000
Subject: hg: jdk8/tl/langtools: 7047734: javac,
	the LVT is not generated correctly in several scenarios
Message-ID: <20130914182133.5A34462831@hg.openjdk.java.net>

Changeset: 4932bb04c4b8
Author:    vromero
Date:      2013-09-14 19:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4932bb04c4b8

7047734: javac, the LVT is not generated correctly in several scenarios
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
+ src/share/classes/com/sun/tools/javac/jvm/LVTRanges.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/util/Bits.java
+ test/tools/javac/flow/AliveRanges.java
+ test/tools/javac/flow/LVTHarness.java
+ test/tools/javac/flow/tests/TestCaseConditional.java
+ test/tools/javac/flow/tests/TestCaseDoLoop.java
+ test/tools/javac/flow/tests/TestCaseFor.java
+ test/tools/javac/flow/tests/TestCaseForEach.java
+ test/tools/javac/flow/tests/TestCaseIf.java
+ test/tools/javac/flow/tests/TestCaseIfElse.java
+ test/tools/javac/flow/tests/TestCaseSwitch.java
+ test/tools/javac/flow/tests/TestCaseTry.java
+ test/tools/javac/flow/tests/TestCaseWhile.java



From ivan.gerasimov at oracle.com  Sat Sep 14 18:58:32 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 14 Sep 2013 22:58:32 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <5231DC0E.4080106@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
Message-ID: <5234B1D8.5000800@oracle.com>


On 12.09.2013 19:21, Alan Bateman wrote:
> On 12/09/2013 06:59, Ivan Gerasimov wrote:
>> Hello Alan, Martin, everyone!
>>
>> Some update on the issue.
>> When trying to integrate my test into Basic.java, I found that it 
>> already contains exactly the same.
>> I have just overlooked it before.
>>
>> Additional investigation showed that inheritIO() doesn't always fail 
>> on Windows.
>> If the scenario is like following:
>> - java application creates a child java process (no IO inheritance, 
>> redirecting IO through pipes by default),
>> - child process creates a grandchild which inherits the child's 
>> stdin/out/err,
>> everything works as expected.
>>
>> However, if the java app (started from a console) creates an 
>> immediate child that inherits its parent stdin/out/err, it fails.
>>
>> That's why this bug hasn't been caught by Basic.java before - because 
>> it uses the first testing scenario.
>> And that's why I had to introduce a new shell script test - because 
>> the problem couldn't be reproduced otherwise.
>>
>> Would you please review the updated webrev?
>> http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ 
>> 
>>
>>
> Based on the previous mails then the update to ProcessImpl_md.c seems 
> right. It's probably best to give this one some bake time in jdk8 
> before you backport it to jdk7u-dev. The reason is that the Process 
> code likes to bite back when it is changed.
>
> On the tests then you probably know we don't like shell tests because 
> they are usually slower and statistically more troublesome. Given the 
> scenario that you are trying to test (and it's useful that you've got 
> to the bottom of the issue) there they may not be other options here. 
> One small concern with the shell test as it stands is that it looks 
> like it is depend on the exact output. This makes me wonder about how 
> it will behave with a debug or fastdebug build that might have 
> additional output.

I only changed the way the test is called.
When the same test is run from Basic.java, it's also expected to receive 
some certain output.
So I think that if it worked well from Basic.java, it should also work 
from the shell script.

> Also a minor point but it might be more readable if the body of the 
> for statement was indented.
>
Yes, done.

Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/8023130/2/webrev/ 


Sincerely yours,
Ivan


> -Alan.



From ivan.gerasimov at oracle.com  Sat Sep 14 19:03:50 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 14 Sep 2013 23:03:50 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <5234B1D8.5000800@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com>
Message-ID: <5234B316.9060509@oracle.com>


On 14.09.2013 22:58, Ivan Gerasimov wrote:
>
> On 12.09.2013 19:21, Alan Bateman wrote:
>> On 12/09/2013 06:59, Ivan Gerasimov wrote:
>>> Hello Alan, Martin, everyone!
>>>
>>> Some update on the issue.
>>> When trying to integrate my test into Basic.java, I found that it 
>>> already contains exactly the same.
>>> I have just overlooked it before.
>>>
>>> Additional investigation showed that inheritIO() doesn't always fail 
>>> on Windows.
>>> If the scenario is like following:
>>> - java application creates a child java process (no IO inheritance, 
>>> redirecting IO through pipes by default),
>>> - child process creates a grandchild which inherits the child's 
>>> stdin/out/err,
>>> everything works as expected.
>>>
>>> However, if the java app (started from a console) creates an 
>>> immediate child that inherits its parent stdin/out/err, it fails.
>>>
>>> That's why this bug hasn't been caught by Basic.java before - 
>>> because it uses the first testing scenario.
>>> And that's why I had to introduce a new shell script test - because 
>>> the problem couldn't be reproduced otherwise.
>>>
>>> Would you please review the updated webrev?
>>> http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ 
>>> 
>>>
>>>
>> Based on the previous mails then the update to ProcessImpl_md.c seems 
>> right. It's probably best to give this one some bake time in jdk8 
>> before you backport it to jdk7u-dev. The reason is that the Process 
>> code likes to bite back when it is changed.
>>
>> On the tests then you probably know we don't like shell tests because 
>> they are usually slower and statistically more troublesome. Given the 
>> scenario that you are trying to test (and it's useful that you've got 
>> to the bottom of the issue) there they may not be other options here. 
>> One small concern with the shell test as it stands is that it looks 
>> like it is depend on the exact output. This makes me wonder about how 
>> it will behave with a debug or fastdebug build that might have 
>> additional output.
>
> I only changed the way the test is called.
> When the same test is run from Basic.java, it's also expected to 
> receive some certain output.
> So I think that if it worked well from Basic.java, it should also work 
> from the shell script.
>
Update:
Of course I tested it with JPRT, and the tests passed well on all platforms.
Though JPRT only run product versions of the tests.

Sincerely,
Ivan

>> Also a minor point but it might be more readable if the body of the 
>> for statement was indented.
>>
> Yes, done.
>
> Would you please review the updated webrev?
> http://cr.openjdk.java.net/~igerasim/8023130/2/webrev/ 
> 
>
> Sincerely yours,
> Ivan
>
>
>> -Alan.
>
>
>



From rob.mckenna at oracle.com  Sat Sep 14 23:21:59 2013
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Sun, 15 Sep 2013 00:21:59 +0100
Subject: RFR: JDK-7123493 : (proxy) Proxy.getProxyClass doesn't scale under
	high load
Message-ID: <5234EF97.70806@oracle.com>

Hi folks,

Looking to backport this fix to JDK7. The backport has resulted in 
relatively minor changes to the original fix such as replicating the 
BiFunction / Supplier interfaces in a limited sense as inner classes in 
WeakCache.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123493
Original review thread: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015854.html

     -Rob



From rob.mckenna at oracle.com  Sat Sep 14 23:32:45 2013
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Sun, 15 Sep 2013 00:32:45 +0100
Subject: RFR: JDK-7123493 : (proxy) Proxy.getProxyClass doesn't scale
	under high load
In-Reply-To: <5234EF97.70806@oracle.com>
References: <5234EF97.70806@oracle.com>
Message-ID: <5234F21D.6040006@oracle.com>

...and the actual webrev:

http://cr.openjdk.java.net/~robm/7123493/webrev.01/ 


     -Rob

On 15/09/13 00:21, Rob McKenna wrote:
> Hi folks,
>
> Looking to backport this fix to JDK7. The backport has resulted in 
> relatively minor changes to the original fix such as replicating the 
> BiFunction / Supplier interfaces in a limited sense as inner classes 
> in WeakCache.
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123493
> Original review thread: 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015854.html
>
>     -Rob
>



From john.r.rose at oracle.com  Sat Sep 14 23:44:14 2013
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 14 Sep 2013 16:44:14 -0700
Subject: RFR: 8022749: Convert junit tests to testng in
	test/java/lang/invoke
In-Reply-To: <5208A80C.6030002@oracle.com>
References: <5205887D.9070204@oracle.com> <5208A80C.6030002@oracle.com>
Message-ID: <27686295-ED46-4F7E-B62F-E50FF3B6F434@oracle.com>

Thanks for the heads up.  I noticed this just now; after refreshing my repos half of the tests fail.

Where is the doc that says how to run jtreg and ant (Netbeans) now that my tests have been changed for me?

? John

On Aug 12, 2013, at 2:17 AM, Alan Bateman  wrote:

> On 10/08/2013 01:25, Henry Jen wrote:
>> Hi,
>> 
>> Please review a webrev contributed by Mani Sarkar that converts junit
>> tests in test/java/lang/invoke to testng.
>> 
>> http://cr.openjdk.java.net/~henryjen/tl/8022749/0/webrev/
>> 
>> Cheers,
>> Henry
> This looks good to me (but cc'ing mlvm-dev so that John/Christian/others 
> that might run these tests interactively are aware of this).
> 
> -Alan.
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From Alan.Bateman at oracle.com  Sun Sep 15 07:15:28 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 15 Sep 2013 08:15:28 +0100
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <5234B1D8.5000800@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com>
Message-ID: <52355E90.7090501@oracle.com>

On 14/09/2013 19:58, Ivan Gerasimov wrote:
> :
>
> Yes, done.
>
> Would you please review the updated webrev?
> http://cr.openjdk.java.net/~igerasim/8023130/2/webrev/ 
> 
Thanks for the update, I think it's looks okay now. It is of course 
disappointing that we've had to resort to a shell script but for the 
scenario that is being tested then there weren't any alternatives proposed.

-Alan


From Alan.Bateman at oracle.com  Sun Sep 15 08:07:40 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 15 Sep 2013 09:07:40 +0100
Subject: static vs. default interface methods and inheritance VM/javac
	issues
In-Reply-To: <5232DCBD.1070105@gmail.com>
References: <5231D6C9.806@gmail.com>
	<7B094410-1F13-488C-A8B9-3B4321F31A0B@oracle.com>
	<1B928A74-E33B-4B42-9639-623621B70036@oracle.com>
	<5232DCBD.1070105@gmail.com>
Message-ID: <52356ACC.1000001@oracle.com>

On 13/09/2013 10:37, Peter Levart wrote:
>
>
> Karen, I filed a bug, but don't have the bug ID yet. Will let you know 
> when I get it.
I found it, and moved it into the JDK project as:
   8024836: static vs. default interface methods and inheritance - VM crash

-Alan.


From ivan.gerasimov at oracle.com  Sun Sep 15 11:06:50 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 15 Sep 2013 15:06:50 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <52355E90.7090501@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com> <52355E90.7090501@oracle.com>
Message-ID: <523594CA.4070104@oracle.com>


On 15.09.2013 11:15, Alan Bateman wrote:
> On 14/09/2013 19:58, Ivan Gerasimov wrote:
>> :
>>
>> Yes, done.
>>
>> Would you please review the updated webrev?
>> http://cr.openjdk.java.net/~igerasim/8023130/2/webrev/ 
>> 
> Thanks for the update, I think it's looks okay now. It is of course 
> disappointing that we've had to resort to a shell script but for the 
> scenario that is being tested then there weren't any alternatives 
> proposed.
>
I decided to check whether this test really detects the failure, and run 
JPRT job with the new test but no fix included.
Unfortunately, the new test *does not* fail with unmodified jdk.
The same thing happens when the test is run with jtreg locally.
I believe it is so, because the tested program is run not directly from 
a console, and this is the condition for the bug to manifest itself.

So I have to exclude the test, as it really doesn't check anything new.
I'm going to add noreg label and write an instruction to the QA about 
how to test the fix manually.

What is good is that we don't need another shell-based test.

Here's the new webrev: 
http://cr.openjdk.java.net/~igerasim/8023130/3/webrev/ 

Its only difference is that the shell script is excluded.

Sincerely yours,
Ivan

> -Alan



From paul.sandoz at oracle.com  Sun Sep 15 13:43:35 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Sun, 15 Sep 2013 13:43:35 +0000
Subject: hg: jdk8/tl/jdk: 8010293:
	java/util/concurrent/ConcurrentHashMap/toArray.java fails
	intermittently
Message-ID: <20130915134420.CAF1B6284C@hg.openjdk.java.net>

Changeset: ff6c76f7733e
Author:    psandoz
Date:      2013-09-02 11:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff6c76f7733e

8010293: java/util/concurrent/ConcurrentHashMap/toArray.java fails intermittently
Reviewed-by: forax, chegar, alanb
Contributed-by: Doug Lea 
, Peter Levart , Paul Sandoz 

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! test/java/util/concurrent/ConcurrentHashMap/toArray.java



From paul.sandoz at oracle.com  Sun Sep 15 14:21:43 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 15 Sep 2013 16:21:43 +0200
Subject: RFR 8010293  Re: Potential issue with CHM.toArray
In-Reply-To: <522F2E07.1080900@oracle.com>
References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>
	<521DF795.8070905@gmail.com> <52247422.1060607@cs.oswego.edu>
	<3A6AF037-3A54-498A-9E4D-C7321FC9B3AB@oracle.com>
	<05C57E52-1F3A-4FC1-AC6F-6BD9877F61D9@oracle.com>
	<5229ED0E.8010100@oracle.com>
	
	<522F2E07.1080900@oracle.com>
Message-ID: <54756B16-BF31-4AE3-A180-CA00199FA11A@oracle.com>


On Sep 10, 2013, at 4:34 PM, Alan Bateman  wrote:

> On 09/09/2013 14:35, Paul Sandoz wrote:
>> On Sep 6, 2013, at 4:56 PM, Alan Bateman  wrote:
>> 
>>> :
>>> The comments are very educational as the resizing is difficult to completely grok without going through examples on a whiteboard. Anyway, I don't see anything obviously wrong after going through it. The test case is useful although creating the list of threads is quite a mouth full to take in.
>>> 
>> Yeah, i left that in a convoluted intermediate state and wanted to use CountedCompleter instead, see below for a revised and preferred version.
>> 
>> Paul.
> Thanks, the "preferred version" looks good to me. In passing I wonder if it should be renamed to ToArray.java while you're there.
> 

Thanks.

Renamed and pushed.

However, although the rename (made from a refactor in the IDE) was reflected in my local workspace (with no diffs) it did not appear to be reflected remotely:

  http://hg.openjdk.java.net/jdk8/tl/jdk/diff/ff6c76f7733e/test/java/util/concurrent/ConcurrentHashMap/toArray.java

:-( something very strange is going on.

I logged another bug and pushed a fix (with you as reviewer) to resolve this:

  http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5025ed287a4a

Apologies for the noise.

Paul.

From paul.sandoz at oracle.com  Sun Sep 15 14:18:45 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Sun, 15 Sep 2013 14:18:45 +0000
Subject: hg: jdk8/tl/jdk: 8024837: Rename
	java/util/concurrent/ConcurrentHashMap/toArray.java to ToArray.java
Message-ID: <20130915141900.C95516284D@hg.openjdk.java.net>

Changeset: 5025ed287a4a
Author:    psandoz
Date:      2013-09-15 16:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5025ed287a4a

8024837: Rename java/util/concurrent/ConcurrentHashMap/toArray.java to ToArray.java
Reviewed-by: alanb

! test/java/util/concurrent/ConcurrentHashMap/ToArray.java < test/java/util/concurrent/ConcurrentHashMap/toArray.java



From peter.levart at gmail.com  Sun Sep 15 15:12:37 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 15 Sep 2013 17:12:37 +0200
Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters
	synchronized method
In-Reply-To: <522DFE08.5060604@gmail.com>
References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com>
	<520777E5.3050304@gmail.com>
	<20130812105439.GC6420@jfranck-desktop.jrpg.bea.com>
	<5208D7A7.9070608@gmail.com>
	<5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com>
	<521CA2F0.1020701@gmail.com>
	<2A6CD10E-FA3B-4BC9-AD22-AAA79C866731@oracle.com>
	<522DFE08.5060604@gmail.com>
Message-ID: <5235CE65.9040005@gmail.com>

Hi,

I rebased the changes and added @bug tag to test. Here's new webrev:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.04/


Joel, I believe you've got the "R" mojo now...


Regards, Peter

On 09/09/2013 06:57 PM, Peter Levart wrote:
> Hi Joel,
>
> Thanks for reviewing.
>
> On 09/09/2013 04:25 PM, Joel Borggr?n-Franck wrote:
>> Hi Peter,
>>
>> Thanks for this, please add a "@bug 8011940" tag to your test. IMO you don't need  a re-review for that. Otherwise looks good.
>
> I'll do that. I just didn't know whether tagging with bug-ID is meant 
> for all tests that arise from fixing a particular bug or just those 
> that test the presence/fixture of the bug. The 8011940 bug is about 
> scalability and the test is not testing scalability (it has been 
> demonstrated by a micro-benchmark, but that is not included in the 
> test). The test is just covering the logic that has been re-factored 
> and has not had any tests before.
>
> Regards, Peter
>
>> We still need a Reviewer, Chris, you reviewed a previous version, can you look at this one too?
>> cheers
>> /Joel
>>
>> On 27 aug 2013, at 15:00, Peter Levart  wrote:
>>
>>> Hi Joel and others,
>>>
>>> Here's a 3rd revision of this proposed patch:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.03/
>>>
>>> I used LinkedHashMap for annotations in this one. It means that now even .getAnnotations() are reported in "declaration order": 1st inherited (includes overridden) then declared (that are not overriding). For example, using @Inherited annotations A1, A2, A3:
>>>
>>> @A1("C")
>>> @A2("C")
>>> class C {}
>>>
>>> @A1("D")
>>> @A3("D")
>>> class D extends C {}
>>>
>>> D.class.getAnnotations() now returns: { @A1("D"), @A2("C"), @A3("D") } ...
>>>
>>> The LHM constructor uses the following expression to estimate the initial capacity of the LHM:
>>>
>>> 3326                         annotations = new LinkedHashMap<>((Math.max(
>>> 3327                                 declaredAnnotations.size(),
>>> 3328                                 Math.min(12, declaredAnnotations.size() + superAnnotations.size())
>>> 3329                             ) * 4 + 2) / 3
>>> 3330                         );
>>>
>>>
>>> I think this strikes some balance between effectivity and accuracy of estimation. I could pre-scan the superclass annotations and calculate the exact final size of the annotations Map before constructing it though. Tell me if this is worth the effort.
>>>
>>> I also created a test that tests 3 things:
>>> - class annotation inheritance
>>> - order of class annotations reported by .getAnnotations() and .getDeclaredAnnotations() methods (although not specified, the order is now stable and resembles declaration order)
>>> - behaviour of class annotation caching when class is redefined
>>>
>>>
>>> Regards, Peter
>>>
>>> On 08/13/2013 09:52 AM, Joel Borggr?n-Franck wrote:
>>>> Hi,
>>>>
>>>> Comments inline,
>>>>
>>>> On 12 aug 2013, at 14:40, Peter Levart  wrote:
>>>>> On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote:
>>>>> - annotation (@interface)  declarations can themselves be redefined (for example, defaults changed). Such redefinitions don't affect already initialized annotations. Default values are cached in AnnotationType which is not invalidated as a result of class redefinition. Maybe it should be. And even if AnnotationType was invalidated as a result of class redefinition, the defaults are looked-up when particular annotations are initialized and then combined with parsed values in a single values map inside each annotation instance (proxy), so invalidating AnnotationType would have no effect on those annotations.
>>>>>
>>>>>> 3326                 if (annotations == null) { // lazy construction
>>>>>> 3327                     annotations = new HashMap<>();
>>>>>> 3328                 }
>>>>>>
>>>>>> I think this should be a LinkedHashMap, so that iteration is predictable
>>>>>> (I know it isn't in the current code). Also the size of the map is known
>>>>>> so you can use a constructor with an explicit initial capacity.
>>>>> Right, AnnotationParser does return LinkedHashMap, so at least decalredAnnotations are in parse-order. I will change the code to use LinkedHashMap for inherited/combined case too.
>>>> Thanks.
>>>>
>>>>> The number of annotations that end-up in inherited/combined Map is not known in advance. I could make a separate pre-scan for superclass annotations that are @Inheritable and don't have the same key as any of declared annotations and then sum this count with declared annotations count, but I don't think this will be very effective. I could allocate a large-enough Map to always fit (the count of superclass annotations + the count of declared annotations), but that could sometimes lead to much over-allocated Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations count + declared annotations count) as the initial capacity for the Map. What do you think which of those 3 alternatives is the best?
>>>> My bad. I was thinking of the case where every inherited annotation was overridden, in that case annotations.size() == declaredAnnotations.size(). That is of course not generally true. I'm fine with handling this as a follow up since the situation is no worse than today and the surrounding code is better. However,
>>>>
>>>> 1) We should really measure this.
>>>> 2) My gut feeling is that the ratio of not overridden inherited annotations to declared annotations is small IE the expected nr of annotations is much closer to declare annotations than to declared + superclass annotations.
>>>> 3) The default initial capacity is 16 and load factor is 0.75. I do think the mean nr of annotations is closer to 3 than to 12. We are probably wasting some space here.
>>>>
>>>> Perhaps use min(default cap, (total annotations/0.75 (+ 1?))) for now as that will make the situation no worse than today and often better?
>>>>
>>>>>> Since this is a fairly significant rewrite I think it might be good to
>>>>>> make sure our tests exercise the new code. Can you run some kind of
>>>>>> coverage report on this?
>>>>> I successfully ran the jdk_lang jtreg tests which contain several tests for annotations.
>>>> I'm a bit worried these tests doesn't cover annotations + class redefine. But I might be persuaded to have more extensive testing as a follow up as well.
>>>>
>>>> cheers
>>>> /Joel
>



From paul.sandoz at oracle.com  Sun Sep 15 16:03:41 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 15 Sep 2013 18:03:41 +0200
Subject: RFR 8024405: Spliterators.spliterator should support CONCURRENT
	characteristic
Message-ID: 

Hi,

http://cr.openjdk.java.net/~psandoz/tl/JDK-8024405-spliterators-size-concurrent/webrev/

This fixes an oversight in creating spliterators from the iterator of a collection or directly from an iterator (+ primitive variants).

If CONCURRENT is supplied as a characteristic then the returned spliterator should not report SIZED/SUBSIZED.

This could have resulted in an issue with ArrayBlockingQueue since it's spliterator is created from a weakly consistently iterator and thus exact size is not known.

A CCC is required.

Paul.

From paul.sandoz at oracle.com  Sun Sep 15 16:20:53 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 15 Sep 2013 18:20:53 +0200
Subject: RFR 8024408: Specifications for
	Collection/List/Set/SortedSet.spliterator() need to document if
	all the (subclass) instances are required to return SIZED spliterators
Message-ID: 

Hi,

http://cr.openjdk.java.net/~psandoz/tl/JDK-8024408-split-col-size/webrev/

It is necessary to relax the constraints when SIZED should be reported for a Spliterator of a Collection or Set.

The spliterator of a Collection/Set can report SIZED, or CONCURRENT, or neither (and never both). The latter case can occur with the strange beast known as WeakHashMap, which is not CONCURRENT in the commonly understood sense, but it's traversal is weakly consistent and the size is only an estimate.

Note that no change was made to List, which basically means no List implementation can be concurrent. This interface is not well suited for concurrent implementations given the determinism expected for indexed access  e.g. l.get(l.size() - 1) could barf for a concurrent or weak list if something is concurrently removed.

A CCC is required.

Paul.

From paul.sandoz at oracle.com  Sun Sep 15 16:27:33 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 15 Sep 2013 18:27:33 +0200
Subject: RFR 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to
	split() method if using an example from the spec
Message-ID: 

Hi,

http://cr.openjdk.java.net/~psandoz/tl/JDK-8024341-pattern-splitAsStream/webrev/

This fixes an issue with Pattern.splitAsStream reporting empty trailing elements and aligns with the functionality of Pattern.split(CharSequence input).

The matching iterator passed to the stream was updated to aggressively consume and keep a count of a sequence of empty matching elements such that those elements can either be reported if not trailing, or discarded if trailing.

Paul.

From paul.sandoz at oracle.com  Sun Sep 15 16:32:46 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 15 Sep 2013 18:32:46 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the initial
	seed
Message-ID: 

Hi,

http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/

Now that the hash seed functionality, which utilized ThreadLocalRandom, has been removed from Hashtable and WeakHashMap we can update TLR to use the same seed initialization functionality as SplittableRandom, which includes using SecureRandom if the system property "java.util.secureRandomSeed" is set to true.

Paul.

From xueming.shen at oracle.com  Sun Sep 15 18:14:13 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sun, 15 Sep 2013 18:14:13 +0000
Subject: hg: jdk8/tl/jdk: 7186311: (props) "Unicode" is misspelled as
	"Uniocde" in JavaDoc and error message
Message-ID: <20130915181435.EEA0762851@hg.openjdk.java.net>

Changeset: b9d59414de23
Author:    sherman
Date:      2013-09-15 11:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9d59414de23

7186311: (props) "Unicode" is misspelled as "Uniocde" in JavaDoc and error message
Summary: to correct the typo
Reviewed-by: alanb, chegar

! make/tools/src/build/tools/generatecharacter/CharacterName.java
! src/share/classes/java/util/Properties.java



From xueming.shen at oracle.com  Sun Sep 15 18:30:23 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sun, 15 Sep 2013 11:30:23 -0700
Subject: RFR: 8920687: Deflater.setLevel does not work as expected
In-Reply-To: <52345569.2050308@oracle.com>
References: <52336B12.3040106@oracle.com> <52345569.2050308@oracle.com>
Message-ID: <5235FCBF.70501@oracle.com>

Thanks Alan. I dropped the "current" in setLevel. Yes, I would like to 
be explicit about the
deflate invocation here, as the implementation clearly just calls the 
deflate() blindly with
the old level/strategy after the level/strategy changed, regardless 
whether there is really
anything in the buffer or not. So I think it might be good to set the 
expectation clear here.

http://cr.openjdk.java.net/~sherman/8020687/webrev/

-Sherman

On 9/14/13 5:24 AM, Alan Bateman wrote:
> On 13/09/2013 20:44, Xueming Shen wrote:
>> Hi,
>>
>> This is change to clarify the java doc to match the existing behavior.
>>
>> If there is a "pending" level/strategy change (via 
>> setLevel/Stragety()) when
>> deflate(...) is invoked, the implementation goes down to zlib's 
>> deflateParams()
>> for deflating operation, which clearly specifies its behavior in 
>> zlib.h as
>>
>> ----------------------------------------------------------------
>>    Dynamically update the compression level and compression 
>> strategy.  The
>>    interpretation of level and strategy is as in deflateInit2. This 
>> can be
>>    used to switch between compression and straight copy of the input 
>> data, or
>>    to switch to a different kind of input data requiring a different 
>> strategy.
>>    If the compression level is changed, the input available so far is
>>    compressed with the old level (and may be flushed); the new level 
>> will take
>>    effect only at the next call of deflate().
>> -----------------------------------------------------------------
>>
>> and its corresponding implementation does exactly that.
> It seems reasonable to have new strategy or level take effect after 
> the available input has been compressed.
>
> Your proposed wording is okay but I wonder if the word "current" 
> should be dropped from the existing statement in setLevel. You might 
> also be able to get away with a single statement too, something like 
> "If changed, the new compression strategy takes effect after the input 
> available has been compressed (or flushed)". Your wording is okay too 
> if you really need to be explicit about deflate being called.
>
> -Alan
>
>



From Lance.Andersen at oracle.com  Sun Sep 15 18:38:48 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Sun, 15 Sep 2013 14:38:48 -0400
Subject: review request 7097386: Correct error in Predicate javadoc example
In-Reply-To: <506F739C-C68A-4F54-9777-0048CBB29968@oracle.com>
References: <506F739C-C68A-4F54-9777-0048CBB29968@oracle.com>
Message-ID: 

I added a webrev http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be a bit easier for this review.

Best
lance
On Sep 13, 2013, at 4:40 PM, Lance Andersen - Oracle wrote:

> Hi Everyone,
> 
> Looking for a reviewer for this trivial fix to correct the sample example in the Predicate javadoc for the evaluate method()
> 
> 
> ------------------
> !hg
> hg diff Predicate.java 
> diff -r 60d6f60416ca src/share/classes/javax/sql/rowset/Predicate.java
> --- a/src/share/classes/javax/sql/rowset/Predicate.java	Thu Sep 12 13:20:26 2013 -0400
> +++ b/src/share/classes/javax/sql/rowset/Predicate.java	Fri Sep 13 16:30:07 2013 -0400
> @@ -56,44 +56,42 @@
>  * 
{@code
>  *    public class Range implements Predicate {
>  *
> - *       private Object lo[];
> - *       private Object hi[];
> + *       private int lo[];
> + *       private int hi[];
>  *       private int idx[];
>  *
> - *       public Range(Object[] lo, Object[] hi, int[] idx) {
> + *       public Range(int[] lo, int[] hi, int[] idx) {
>  *          this.lo = lo;
>  *          this.hi = hi;
>  *          this.idx = idx;
>  *       }
>  *
>  *      public boolean evaluate(RowSet rs) {
> - *          CachedRowSet crs = (CachedRowSet)rs;
> - *          boolean bool1,bool2;
>  *
>  *          // Check the present row determine if it lies
>  *          // within the filtering criteria.
>  *
>  *          for (int i = 0; i < idx.length; i++) {
> + *             int value = 0;
> + *             try {
> + *                 value = (Integer) rs.getObject(idx[i]);
> + *             } catch (SQLException ex) {
> + *                 Logger.getLogger(Range.class.getName()).log(Level.SEVERE, null, ex);
> + *             }
>  *
> - *              if ((rs.getObject(idx[i]) >= lo[i]) &&
> - *                  (rs.getObject(idx[i]) >= hi[i]) {
> - *                  bool1 = true; // within filter constraints
> - *              } else {
> - *                  bool2 = true; // outside of filter constraints
> - *              }
> - *          }
> - *
> - *          if (bool2) {
> - *             return false;
> - *          } else {
> - *             return true;
> - *          }
> + *             if (value < lo[i] && value > hi[i]) {
> + *                 // outside of filter constraints
> + *                 return false; 
> + *             }
> + *         }
> + *         // Within filter constraints
> + *        return true;
>  *      }
> - *  }
> + *   }
>  * }

>  * 

>  * The example above implements a simple range predicate. Note, that
> - * implementations should but are not required to provider String
> + * implementations should but are not required to provide String
>  * and integer index based constructors to provide for JDBC RowSet Implementation
>  * applications that use both column identification conventions.
>  *
> 
> 
> -----------------
> 
> Best
> Lance
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From Alan.Bateman at oracle.com  Sun Sep 15 19:45:35 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 15 Sep 2013 20:45:35 +0100
Subject: RFR: 8920687: Deflater.setLevel does not work as expected
In-Reply-To: <5235FCBF.70501@oracle.com>
References: <52336B12.3040106@oracle.com> <52345569.2050308@oracle.com>
	<5235FCBF.70501@oracle.com>
Message-ID: <52360E5F.8050309@oracle.com>

On 15/09/2013 19:30, Xueming Shen wrote:
> Thanks Alan. I dropped the "current" in setLevel. Yes, I would like to 
> be explicit about the
> deflate invocation here, as the implementation clearly just calls the 
> deflate() blindly with
> the old level/strategy after the level/strategy changed, regardless 
> whether there is really
> anything in the buffer or not. So I think it might be good to set the 
> expectation clear here.
>
> http://cr.openjdk.java.net/~sherman/8020687/webrev/
>
> -Sherman
>
This is okay, the only thing is the words "of deflate methods" is a bit 
odd. Do you want to change this to simple "deflate"?

-Alan.


From Alan.Bateman at oracle.com  Sun Sep 15 19:49:13 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 15 Sep 2013 20:49:13 +0100
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <523594CA.4070104@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com> <52355E90.7090501@oracle.com>
	<523594CA.4070104@oracle.com>
Message-ID: <52360F39.9080103@oracle.com>

On 15/09/2013 12:06, Ivan Gerasimov wrote:
> :
>
> I decided to check whether this test really detects the failure, and 
> run JPRT job with the new test but no fix included.
> Unfortunately, the new test *does not* fail with unmodified jdk.
> The same thing happens when the test is run with jtreg locally.
> I believe it is so, because the tested program is run not directly 
> from a console, and this is the condition for the bug to manifest itself.
>
> So I have to exclude the test, as it really doesn't check anything new.
> I'm going to add noreg label and write an instruction to the QA about 
> how to test the fix manually.
>
> What is good is that we don't need another shell-based test.
>
> Here's the new webrev: 
> http://cr.openjdk.java.net/~igerasim/8023130/3/webrev/ 
> 
> Its only difference is that the shell script is excluded.
JPRT may be using ssh but others will likely run the tests in other 
configurations. If the shell test allows the scenario to be tested in 
other configurations then it may be better to just include it in your 
patch (in general we want to eliminate as many shell tests as possible 
but a shell tests bets the cost of a manual test any day).

-Alan.


From xueming.shen at oracle.com  Sun Sep 15 20:22:02 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sun, 15 Sep 2013 13:22:02 -0700
Subject: RFR: 8920687: Deflater.setLevel does not work as expected
In-Reply-To: <52360E5F.8050309@oracle.com>
References: <52336B12.3040106@oracle.com> <52345569.2050308@oracle.com>
	<5235FCBF.70501@oracle.com> <52360E5F.8050309@oracle.com>
Message-ID: <523616EA.6070400@oracle.com>

Updated accordingly.

http://cr.openjdk.java.net/~sherman/8020687/webrev/

Thanks!
-Sherman

On 9/15/13 12:45 PM, Alan Bateman wrote:
> On 15/09/2013 19:30, Xueming Shen wrote:
>> Thanks Alan. I dropped the "current" in setLevel. Yes, I would like 
>> to be explicit about the
>> deflate invocation here, as the implementation clearly just calls the 
>> deflate() blindly with
>> the old level/strategy after the level/strategy changed, regardless 
>> whether there is really
>> anything in the buffer or not. So I think it might be good to set the 
>> expectation clear here.
>>
>> http://cr.openjdk.java.net/~sherman/8020687/webrev/
>>
>> -Sherman
>>
> This is okay, the only thing is the words "of deflate methods" is a 
> bit odd. Do you want to change this to simple "deflate"?
>
> -Alan.



From xueming.shen at oracle.com  Sun Sep 15 20:56:16 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sun, 15 Sep 2013 20:56:16 +0000
Subject: hg: jdk8/tl/jdk: 8020687: Deflater.setLevel does not work as expected
Message-ID: <20130915205637.A73BA62856@hg.openjdk.java.net>

Changeset: efa09bf27d39
Author:    sherman
Date:      2013-09-15 13:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efa09bf27d39

8020687: Deflater.setLevel does not work as expected
Summary: to clarify the api to match the existing implementation behavior
Reviewed-by: alanb

! src/share/classes/java/util/zip/Deflater.java



From paul.sandoz at oracle.com  Mon Sep 16 08:13:29 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 16 Sep 2013 10:13:29 +0200
Subject: RFR: 8023339: (xs) Refine UOE conditions for removeIf()
In-Reply-To: 
References: 
Message-ID: 

Hi Mike,

I suppose there could also be implementations of removeIf that always throw UOE regardless of whether an element matched or not i.e. those that override just to throw UOE.

So perhaps:

* @throws UnsupportedOperationException if elements cannot be removed 
*         from this collection.  Implementations may throw this exception if a
*         matching element cannot be removed or if, in general, removal is not 
*         supported.

Paul.

On Sep 13, 2013, at 11:52 PM, Mike Duigou  wrote:

> Hello all;
> 
> A very small patch that refines the declared conditions under which the Collection.removeIf() method will throw UOE. The intent of this patch is to allow the default implementation to be used for immutable collections. It's important that the default implementations provided and the specifications of the methods allow for the behaviour which results from using the default method implementation on any reasonable implementation including immutable implementations. In this case there was a bug originally written against j.u.Arrays.asList() The bug asserted that it's removeIf() implementation was "lazy" and only throws UOE when an element is to be removed. One possible solution was to add a non-default implementation of removeIf() to the Arrays.asList()-List. Since the default method definition must also satisfy other potential immutable implementations we decided to enhance the UOE conditions rather than paper over the problem by adding a default.
> 
> (There are a couple of other similar issues which will have similar solutions)
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8023339/1/
> 
> Mike
> 


From aleksey.shipilev at oracle.com  Mon Sep 16 08:58:15 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 16 Sep 2013 12:58:15 +0400
Subject: review request 7097386: Correct error in Predicate javadoc example
In-Reply-To: 
References: <506F739C-C68A-4F54-9777-0048CBB29968@oracle.com>
	
Message-ID: <5236C827.8070904@oracle.com>

On 09/15/2013 10:38 PM, Lance Andersen - Oracle wrote:
> I added a webrev
> http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be
> a bit easier for this review.

Notes:
  - change C-style "int v[]" declarations to Java-ish "int[] v".
  - catching SQLException should probably return "false" right away?
  - "if" block can float up to the exception handler block, eliminating
the need for "int value = 0" line.

Otherwise, looks good (not a Reviewer).

Thanks,
-Aleksey,


From aleksey.shipilev at oracle.com  Mon Sep 16 09:01:18 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 16 Sep 2013 13:01:18 +0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: 
References: 
Message-ID: <5236C8DE.4040705@oracle.com>

On 09/15/2013 08:32 PM, Paul Sandoz wrote:
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/

+1.

-Aleksey.



From Alan.Bateman at oracle.com  Mon Sep 16 09:35:07 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Sep 2013 10:35:07 +0100
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: 
References: 
Message-ID: <5236D0CB.2060707@oracle.com>

On 15/09/2013 17:32, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/
>
> Now that the hash seed functionality, which utilized ThreadLocalRandom, has been removed from Hashtable and WeakHashMap we can update TLR to use the same seed initialization functionality as SplittableRandom, which includes using SecureRandom if the system property "java.util.secureRandomSeed" is set to true.
>
> Paul.
Looks okay to me although it might be better to catch UHE rather than 
Exception.

-Alan.


From Lance.Andersen at oracle.com  Mon Sep 16 11:12:09 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 16 Sep 2013 07:12:09 -0400
Subject: review request 7097386: Correct error in Predicate javadoc example
In-Reply-To: <5236C827.8070904@oracle.com>
References: <506F739C-C68A-4F54-9777-0048CBB29968@oracle.com>
	
	<5236C827.8070904@oracle.com>
Message-ID: <02298CEB-1AAE-4478-AB9C-E0018EB12100@oracle.com>

Thanks for the input.
On Sep 16, 2013, at 4:58 AM, Aleksey Shipilev wrote:

> On 09/15/2013 10:38 PM, Lance Andersen - Oracle wrote:
>> I added a webrev
>> http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be
>> a bit easier for this review.
> 
> Notes:
>  - change C-style "int v[]" declarations to Java-ish "int[] v".

I changed this.
>  - catching SQLException should probably return "false" right away?
True, was a missing cut and paste from the code I copied
>  - "if" block can float up to the exception handler block, eliminating
> the need for "int value = 0" line.

I left it as is as I try to keep the try/catch for SQLExceptions to just relevant code when applicable.
> 
> Otherwise, looks good (not a Reviewer).
> 
again, thank you for the feedback.

Changes are at http://cr.openjdk.java.net/~lancea/7097386/webrev.01/

Best
Lance
> Thanks,
> -Aleksey,

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From aleksey.shipilev at oracle.com  Mon Sep 16 11:15:48 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 16 Sep 2013 15:15:48 +0400
Subject: review request 7097386: Correct error in Predicate javadoc example
In-Reply-To: <02298CEB-1AAE-4478-AB9C-E0018EB12100@oracle.com>
References: <506F739C-C68A-4F54-9777-0048CBB29968@oracle.com>
	
	<5236C827.8070904@oracle.com>
	<02298CEB-1AAE-4478-AB9C-E0018EB12100@oracle.com>
Message-ID: <5236E864.5000904@oracle.com>

On 09/16/2013 03:12 PM, Lance Andersen - Oracle wrote:
> Changes are at http://cr.openjdk.java.net/~lancea/7097386/webrev.01/

Thumbs up.

-Aleksey.



From dl at cs.oswego.edu  Mon Sep 16 11:32:54 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 16 Sep 2013 07:32:54 -0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <5236D0CB.2060707@oracle.com>
References: 
	<5236D0CB.2060707@oracle.com>
Message-ID: <5236EC66.4040808@cs.oswego.edu>

On 09/16/2013 05:35 AM, Alan Bateman wrote:
> On 15/09/2013 17:32, Paul Sandoz wrote:
>> Hi,
>>
>> http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/
>>
>> Now that the hash seed functionality, which utilized ThreadLocalRandom, has
>> been removed from Hashtable and WeakHashMap we can update TLR to use the same
>> seed initialization functionality as SplittableRandom, which includes using
>> SecureRandom if the system property "java.util.secureRandomSeed" is set to true.
>>

Thanks. This just re-instates a change we had to hold off on
in last TLR updates because of the hash seed dependency.

> Looks okay to me although it might be better to catch UHE rather than Exception.

The intent is to ignore any problem in getting hashed host name
short of a VM error. On the other hand, it is not nice to consume
any unexpected mysterious RunTimeException. A coin flip...

-Doug




From peter.levart at gmail.com  Mon Sep 16 12:46:51 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Sep 2013 14:46:51 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <5236EC66.4040808@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
Message-ID: <5236FDBB.9010209@gmail.com>

On 09/16/2013 01:32 PM, Doug Lea wrote:
> On 09/16/2013 05:35 AM, Alan Bateman wrote:
>> On 15/09/2013 17:32, Paul Sandoz wrote:
>>> Hi,
>>>
>>> http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/
>>>
>>> Now that the hash seed functionality, which utilized 
>>> ThreadLocalRandom, has
>>> been removed from Hashtable and WeakHashMap we can update TLR to use 
>>> the same
>>> seed initialization functionality as SplittableRandom, which 
>>> includes using
>>> SecureRandom if the system property "java.util.secureRandomSeed" is 
>>> set to true.
>>>
>
> Thanks. This just re-instates a change we had to hold off on
> in last TLR updates because of the hash seed dependency.
>
>> Looks okay to me although it might be better to catch UHE rather than 
>> Exception.
>
> The intent is to ignore any problem in getting hashed host name
> short of a VM error. On the other hand, it is not nice to consume
> any unexpected mysterious RunTimeException. A coin flip...
>
> -Doug

Hi,

The InetAddress.getLocalHost() might throw SecurityException in some 
configurations (SecurityManager.checkConnect(localHostName, -1)). So 
perhaps, the call should be wrapped by 
AccessController.doPrivileged(...). But that's not so important. What 
worries me is that InetAddress.getLocalHost() involves name service 
look-up. It depends on configuration, but on my computer, it takes about 
5s to evaluate the hostname -> IP mapping the first time the program is 
run. The OS seems to cache this for a minute or so, because when I 
re-run the test program, it only takes 10ms. After a minute, the OS 
cache seems to expire and it again takes 5s to evaluate.

It may be that I have a strange unusual configuration (the name -> IP 
mapping is performed by DNS service even for local host name), but I 
have no other obvious problems using my machine.

I tried the following alternative:

     private static long interfacesHash() {
         long hash = 0L;
         try {
             Enumeration ifcs = 
NetworkInterface.getNetworkInterfaces();
             while (ifcs.hasMoreElements()) {
                 hash ^= interfaceHash(ifcs.nextElement());
             }
         } catch (Exception e) {
             // ignore
         }
         return hash;
     }

     private static long interfaceHash(NetworkInterface ni) {
         long hash = 0L;
         Enumeration ipAddresses = ni.getInetAddresses();
         while (ipAddresses.hasMoreElements()) {
             hash ^= mix64(ipAddresses.nextElement().hashCode());
         }
         Enumeration subNis = ni.getSubInterfaces();
         while (subNis.hasMoreElements()) {
             hash ^= interfaceHash(subNis.nextElement());
         }
         return hash;
     }


This iterates all interfaces (with sub-interfaces) on the machine and 
XORs together the mix64-ed hashes of their IP addresses. It does't do 
any name service look-up and on my machine (with one ethernet and a 
loopback interface) it runs about 6-10x faster than 
InetAddress.getLocalHost() (that's when InetAddress.getLocalHost() runs 
fast - the OS caches the mapping):

InetAddress.getLocalHost() ~ 7-10 ms
interfacesHash() ~ 0.5-1.2ms

Note that in order to gain as much seed as possible from 
interfacesHash(), it should also be wrapped by 
AccessController.doPrivileged(...)

NetworkInterface also has one method called getHardwareAddress(). This 
might me interesting too...


Regards, Peter



From peter.levart at gmail.com  Mon Sep 16 12:52:58 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Sep 2013 14:52:58 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <5236FDBB.9010209@gmail.com>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
Message-ID: <5236FF2A.6020801@gmail.com>

On 09/16/2013 02:46 PM, Peter Levart wrote:
> The InetAddress.getLocalHost() might throw SecurityException in some 
> configurations (SecurityManager.checkConnect(localHostName, -1)). So 
> perhaps, the call should be wrapped by AccessController.doPrivileged(...).

Correction: SecurityException is not propagated out of 
InetAddress.getLocalHost(), but loopback address is returned in case the 
security check fails, so AccessController.doPrivileged(...) might still 
be needed to gain as much seed as possible.

Peter



From vicente.romero at oracle.com  Mon Sep 16 13:30:27 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Mon, 16 Sep 2013 13:30:27 +0000
Subject: hg: jdk8/tl/langtools: 8021112: Spurious unchecked warning reported
	by javac; ...
Message-ID: <20130916133030.6BBB362873@hg.openjdk.java.net>

Changeset: 4ce8148ffc4f
Author:    jlahoda
Date:      2013-09-16 14:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ce8148ffc4f

8021112: Spurious unchecked warning reported by javac
6480588: No way to suppress deprecation warnings when implementing deprecated interface
Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! test/tools/javac/depDocComment/SuppressDeprecation.out
! test/tools/javac/warnings/6594914/T6594914a.out
! test/tools/javac/warnings/6594914/T6594914b.out
+ test/tools/javac/warnings/suppress/ImplicitTest.java
+ test/tools/javac/warnings/suppress/ImplicitTest.out
+ test/tools/javac/warnings/suppress/PackageInfo.java
+ test/tools/javac/warnings/suppress/PackageInfo.out
+ test/tools/javac/warnings/suppress/T6480588.java
+ test/tools/javac/warnings/suppress/T6480588.out
+ test/tools/javac/warnings/suppress/T8021112a.java
+ test/tools/javac/warnings/suppress/T8021112b.java
+ test/tools/javac/warnings/suppress/T8021112b.out
+ test/tools/javac/warnings/suppress/TypeAnnotations.java
+ test/tools/javac/warnings/suppress/TypeAnnotations.out
+ test/tools/javac/warnings/suppress/VerifySuppressWarnings.java
+ test/tools/javac/warnings/suppress/pack/DeprecatedClass.java
+ test/tools/javac/warnings/suppress/pack/ImplicitMain.java
+ test/tools/javac/warnings/suppress/pack/ImplicitUse.java
+ test/tools/javac/warnings/suppress/pack/package-info.java



From dl at cs.oswego.edu  Mon Sep 16 13:54:08 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 16 Sep 2013 09:54:08 -0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <5236FDBB.9010209@gmail.com>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
Message-ID: <52370D80.9020803@cs.oswego.edu>

On 09/16/2013 08:46 AM, Peter Levart wrote:

> What worries me is that InetAddress.getLocalHost() involves name
> service look-up. It depends on configuration, but on my computer, it takes about
> 5s to evaluate the hostname -> IP mapping the first time the program is run.
>
> NetworkInterface also has one method called getHardwareAddress(). This might me
> interesting too...

Using NetworkInterface.getHardwareAddress() is a good idea; thanks!
Using only one of them should suffice. And just giving up on
SecurityException seems fine.

Could you check that this performs reasonably on your
unusually-configured machine?

  private static long initialSeed() {
         String pp = java.security.AccessController.doPrivileged(
                 new sun.security.action.GetPropertyAction(
                         "java.util.secureRandomSeed"));
         if (pp != null && pp.equalsIgnoreCase("true")) {
             byte[] seedBytes = java.security.SecureRandom.getSeed(8);
             long s = (long)(seedBytes[0]) & 0xffL;
             for (int i = 1; i < 8; ++i)
                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
             return s;
         }
         long h = 0L;
         try {
             Enumeration ifcs =
                 NetworkInterface.getNetworkInterfaces();
             if (ifcs.hasMoreElements()) {
                 byte[] bs = ifcs.nextElement().getHardwareAddress();
                 if (bs != null) {
                     for (int i = 0; i < 8 && i < bs.length; ++i)
                         h = (h << 8) ^ bs[i];
                 }
             }
         } catch (Exception ignore) {
         }
         return (mix64(h ^ System.currentTimeMillis()) ^
                 mix64(System.nanoTime()));





From paul.sandoz at oracle.com  Mon Sep 16 14:00:44 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 16 Sep 2013 16:00:44 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <5236FDBB.9010209@gmail.com>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
Message-ID: 

Hi Peter,

Nice observation about name resolving.

On my MacBook, if i switch off the wifi, then 7 addresses are returned 4 for the en0 and 3 for lo0. Seems overkill to use all of them and the sub-interefaces, if any. I agree with Doug, selecting the first interface's MAC address is probably sufficient.

Paul.

On Sep 16, 2013, at 2:46 PM, Peter Levart  wrote:


> NetworkInterface also has one method called getHardwareAddress(). This might me interesting too...
> 
> 
> Regards, Peter
> 


From sundararajan.athijegannathan at oracle.com  Mon Sep 16 14:06:12 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 16 Sep 2013 14:06:12 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130916140615.31F0462878@hg.openjdk.java.net>

Changeset: 38378024a332
Author:    sundar
Date:      2013-09-16 15:08 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/38378024a332

8024847: Java.to should accept mirror and external JSObjects as array-like objects as well
Reviewed-by: hannesw, attila, lagergren

! src/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk/nashorn/internal/runtime/ECMAErrors.java
+ src/jdk/nashorn/internal/runtime/JSObjectListAdapter.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
+ src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java
+ test/script/basic/JDK-8024847.js
+ test/script/basic/JDK-8024847.js.EXPECTED

Changeset: f1fd5f0bc84c
Author:    attila
Date:      2013-09-16 14:44 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f1fd5f0bc84c

8024846: keep separate internal arguments variable
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/CompilerConstants.java
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8024846.js



From paul.sandoz at oracle.com  Mon Sep 16 14:10:03 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 16 Sep 2013 16:10:03 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52370D80.9020803@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com> <52370D80.9020803@cs.oswego.edu>
Message-ID: 

Hi Doug,

Perhaps it would be conservative to find the first non-loopback interface, if any, just in case the first one in the enumeration is a loopback (which will return a null byte array)?

e.g.:

           while (ifcs.hasMoreElements()) {
               byte[] bs = ifcs.nextElement().getHardwareAddress();
               if (bs != null) {
                   for (int i = 0; i < 8 && i < bs.length; ++i)
                       h = (h << 8) ^ bs[i];
                   break;
               }
           }

Paul.

On Sep 16, 2013, at 3:54 PM, Doug Lea 
 wrote:

> On 09/16/2013 08:46 AM, Peter Levart wrote:
> 
>> What worries me is that InetAddress.getLocalHost() involves name
>> service look-up. It depends on configuration, but on my computer, it takes about
>> 5s to evaluate the hostname -> IP mapping the first time the program is run.
>> 
>> NetworkInterface also has one method called getHardwareAddress(). This might me
>> interesting too...
> 
> Using NetworkInterface.getHardwareAddress() is a good idea; thanks!
> Using only one of them should suffice. And just giving up on
> SecurityException seems fine.
> 
> Could you check that this performs reasonably on your
> unusually-configured machine?
> 
> private static long initialSeed() {
>        String pp = java.security.AccessController.doPrivileged(
>                new sun.security.action.GetPropertyAction(
>                        "java.util.secureRandomSeed"));
>        if (pp != null && pp.equalsIgnoreCase("true")) {
>            byte[] seedBytes = java.security.SecureRandom.getSeed(8);
>            long s = (long)(seedBytes[0]) & 0xffL;
>            for (int i = 1; i < 8; ++i)
>                s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>            return s;
>        }
>        long h = 0L;
>        try {
>            Enumeration ifcs =
>                NetworkInterface.getNetworkInterfaces();
>            if (ifcs.hasMoreElements()) {
>                byte[] bs = ifcs.nextElement().getHardwareAddress();
>                if (bs != null) {
>                    for (int i = 0; i < 8 && i < bs.length; ++i)
>                        h = (h << 8) ^ bs[i];
>                }
>            }
>        } catch (Exception ignore) {
>        }
>        return (mix64(h ^ System.currentTimeMillis()) ^
>                mix64(System.nanoTime()));
> 
> 
> 


From Alan.Bateman at oracle.com  Mon Sep 16 14:25:38 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Sep 2013 15:25:38 +0100
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: 
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
Message-ID: <523714E2.4010906@oracle.com>

On 16/09/2013 15:00, Paul Sandoz wrote:
> Hi Peter,
>
> Nice observation about name resolving.
>
> On my MacBook, if i switch off the wifi, then 7 addresses are returned 4 for the en0 and 3 for lo0. Seems overkill to use all of them and the sub-interefaces, if any. I agree with Doug, selecting the first interface's MAC address is probably sufficient.
>
We periodically come across environments where they are a lot (as in 
hundreds) of network interfaces configured and might indeed be overkill 
to use bits from all of them.

On getHardwareAddress then there are platforms where you need to be root 
or have special privileges to get the mac address so this is one reason 
why it might return null. I see Doug's patch handles this and I'm just 
mentioning in that it may not be source of bits in some environments.

For the security manager case there is a permission check to avoid 
leaking details about the environment to untrusted code. So to be useful 
when running with a security manager will require it to be done as a 
privileged action.

-Alan.



From peter.levart at gmail.com  Mon Sep 16 14:27:42 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Sep 2013 16:27:42 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52370D80.9020803@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com> <52370D80.9020803@cs.oswego.edu>
Message-ID: <5237155E.1000204@gmail.com>

On 09/16/2013 03:54 PM, Doug Lea wrote:
> On 09/16/2013 08:46 AM, Peter Levart wrote:
>
>> What worries me is that InetAddress.getLocalHost() involves name
>> service look-up. It depends on configuration, but on my computer, it 
>> takes about
>> 5s to evaluate the hostname -> IP mapping the first time the program 
>> is run.
>>
>> NetworkInterface also has one method called getHardwareAddress(). 
>> This might me
>> interesting too...
>
> Using NetworkInterface.getHardwareAddress() is a good idea; thanks!
> Using only one of them should suffice. And just giving up on
> SecurityException seems fine.
>
> Could you check that this performs reasonably on your
> unusually-configured machine?

I checked and it performs fast. It doesn't involve name service look-up.

>
>  private static long initialSeed() {
>         String pp = java.security.AccessController.doPrivileged(
>                 new sun.security.action.GetPropertyAction(
>                         "java.util.secureRandomSeed"));
>         if (pp != null && pp.equalsIgnoreCase("true")) {
>             byte[] seedBytes = java.security.SecureRandom.getSeed(8);
>             long s = (long)(seedBytes[0]) & 0xffL;
>             for (int i = 1; i < 8; ++i)
>                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>             return s;
>         }
>         long h = 0L;
>         try {
>             Enumeration ifcs =
>                 NetworkInterface.getNetworkInterfaces();
>             if (ifcs.hasMoreElements()) {
>                 byte[] bs = ifcs.nextElement().getHardwareAddress();
>                 if (bs != null) {
>                     for (int i = 0; i < 8 && i < bs.length; ++i)
>                         h = (h << 8) ^ bs[i];
>                 }
>             }
>         } catch (Exception ignore) {
>         }
>         return (mix64(h ^ System.currentTimeMillis()) ^
>                 mix64(System.nanoTime()));
>
>
>

But not every interface has hardware address (loopback interface for 
example) and the order of returned interfaces is not defined. Also with 
security manager installed (System.setSecurityManager(new 
RMISecurityManager()) and no extra policy, the above code always 
evaluates 'h' to 0. The following is more robust (I included only the 
2nd part after SecureRandom and added some prints to see what gets 
evaluated):

     public static long initialSeed() {
         long h = 0L;
         try {
             h = AccessController.doPrivileged(new 
PrivilegedExceptionAction() {
                 @Override
                 public Long run() throws Exception {
                     long h = 0L;
                     Enumeration ifcs =
NetworkInterface.getNetworkInterfaces();
                     while (ifcs.hasMoreElements()) {
                         NetworkInterface ifc = ifcs.nextElement();
                         System.out.println(ifc);
                         byte[] bs = ifc.getHardwareAddress();
System.out.println(Arrays.toString(bs));
                         if (bs != null) {
                             for (int i = 0; i < 8 && i < bs.length; ++i)
                                 h = (h << 8) ^ bs[i];
                             break;
                         }
                     }
                     return h;
                 }
             });
         } catch (Exception ignore) {
         }
         return (
             mix64(h ^ System.currentTimeMillis()) ^
             mix64(System.nanoTime())
         );
     }


Regards, Peter



From peter.levart at gmail.com  Mon Sep 16 14:39:03 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Sep 2013 16:39:03 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <523714E2.4010906@oracle.com>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com>
Message-ID: <52371807.9080401@gmail.com>

On 09/16/2013 04:25 PM, Alan Bateman wrote:
> On 16/09/2013 15:00, Paul Sandoz wrote:
>> Hi Peter,
>>
>> Nice observation about name resolving.
>>
>> On my MacBook, if i switch off the wifi, then 7 addresses are 
>> returned 4 for the en0 and 3 for lo0. Seems overkill to use all of 
>> them and the sub-interefaces, if any. I agree with Doug, selecting 
>> the first interface's MAC address is probably sufficient.
>>
> We periodically come across environments where they are a lot (as in 
> hundreds) of network interfaces configured and might indeed be 
> overkill to use bits from all of them.
>
> On getHardwareAddress then there are platforms where you need to be 
> root or have special privileges to get the mac address so this is one 
> reason why it might return null. I see Doug's patch handles this and 
> I'm just mentioning in that it may not be source of bits in some 
> environments.
>
> For the security manager case there is a permission check to avoid 
> leaking details about the environment to untrusted code. So to be 
> useful when running with a security manager will require it to be done 
> as a privileged action.
>
> -Alan.
>

Hi,

So perhaps the right strategy would be to get the hardware address of 
the 1st interface that has it, but don't bother to search more than N 
interfaces (if 1st N interfaces don't return HW address then it is a 
good chance that OS security does not allow accessing them). Testing at 
least 2 interfaces would allow to skip over loopback in environments 
where it is returned as 1st interface. Other kinds of interfaces that 
don't have hardware address are some Point-to-Point interfaces (VPN 
interfaces for example).

Peter


From dl at cs.oswego.edu  Mon Sep 16 14:50:22 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 16 Sep 2013 10:50:22 -0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52371807.9080401@gmail.com>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
Message-ID: <52371AAE.9010801@cs.oswego.edu>

On 09/16/2013 10:39 AM, Peter Levart wrote:

> So perhaps the right strategy would be to get the hardware address of the 1st
> interface that has it, but don't bother to search more than N interfaces

Where N==2 seems to be the best policy, since at most loopback is
legitimately null. Putting the suggestions together:

     private static long initialSeed() {
         String pp = java.security.AccessController.doPrivileged(
                 new sun.security.action.GetPropertyAction(
                         "java.util.secureRandomSeed"));
         if (pp != null && pp.equalsIgnoreCase("true")) {
             byte[] seedBytes = java.security.SecureRandom.getSeed(8);
             long s = (long)(seedBytes[0]) & 0xffL;
             for (int i = 1; i < 8; ++i)
                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
             return s;
         }
         long h = 0L;
         try {
             Enumeration ifcs =
                 NetworkInterface.getNetworkInterfaces();
             boolean retry = false; // retry once if getHardwareAddress is null
             while (ifcs.hasMoreElements()) {
                 NetworkInterface ifc = ifcs.nextElement();
                 byte[] bs = ifc.getHardwareAddress();
                 if (bs != null) {
                     for (int i = 0; i < 8 && i < bs.length; ++i)
                         h = (h << 8) ^ bs[i];
                     break;
                 }
                 else if (!retry)
                     retry = true;
                 else
                     break;
             }
         } catch (Exception ignore) {
         }
         return (mix64(h ^ System.currentTimeMillis()) ^
                 mix64(System.nanoTime()));
     }




From peter.levart at gmail.com  Mon Sep 16 15:06:42 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Sep 2013 17:06:42 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52371AAE.9010801@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu>
Message-ID: <52371E82.9080803@gmail.com>

Hi Doug,

This seems reasonable for majority of environments.

Regards, Peter

On 09/16/2013 04:50 PM, Doug Lea wrote:
> On 09/16/2013 10:39 AM, Peter Levart wrote:
>
>> So perhaps the right strategy would be to get the hardware address of 
>> the 1st
>> interface that has it, but don't bother to search more than N interfaces
>
> Where N==2 seems to be the best policy, since at most loopback is
> legitimately null. Putting the suggestions together:
>
>     private static long initialSeed() {
>         String pp = java.security.AccessController.doPrivileged(
>                 new sun.security.action.GetPropertyAction(
>                         "java.util.secureRandomSeed"));
>         if (pp != null && pp.equalsIgnoreCase("true")) {
>             byte[] seedBytes = java.security.SecureRandom.getSeed(8);
>             long s = (long)(seedBytes[0]) & 0xffL;
>             for (int i = 1; i < 8; ++i)
>                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>             return s;
>         }
>         long h = 0L;
>         try {
>             Enumeration ifcs =
>                 NetworkInterface.getNetworkInterfaces();
>             boolean retry = false; // retry once if getHardwareAddress 
> is null
>             while (ifcs.hasMoreElements()) {
>                 NetworkInterface ifc = ifcs.nextElement();
>                 byte[] bs = ifc.getHardwareAddress();
>                 if (bs != null) {
>                     for (int i = 0; i < 8 && i < bs.length; ++i)
>                         h = (h << 8) ^ bs[i];
>                     break;
>                 }
>                 else if (!retry)
>                     retry = true;
>                 else
>                     break;
>             }
>         } catch (Exception ignore) {
>         }
>         return (mix64(h ^ System.currentTimeMillis()) ^
>                 mix64(System.nanoTime()));
>     }
>
>



From guy.steele at oracle.com  Mon Sep 16 15:10:20 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Mon, 16 Sep 2013 11:10:20 -0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52371AAE.9010801@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu>
Message-ID: 


On Sep 16, 2013, at 10:50 AM, Doug Lea 
 wrote:

>        try {
>            Enumeration ifcs =
>                NetworkInterface.getNetworkInterfaces();
>            boolean retry = false; // retry once if getHardwareAddress is null
>            while (ifcs.hasMoreElements()) {
>                NetworkInterface ifc = ifcs.nextElement();
>                byte[] bs = ifc.getHardwareAddress();
>                if (bs != null) {
>                    for (int i = 0; i < 8 && i < bs.length; ++i)
>                        h = (h << 8) ^ bs[i];
>                    break;
>                }
>                else if (!retry)
>                    retry = true;
>                else
>                    break;
>            }
>        } catch (Exception ignore) {
>        }


This retry logic seems a bit convoluted; how about:

       try {
           Enumeration ifcs =
               NetworkInterface.getNetworkInterfaces();
           if (ifcs.hasMoreElements()) {
               byte[] bs = ifcs.nextElement().getHardwareAddress();
	       if (bs == null && ifcs.hasMoreElements()) {  // try up to two
		   bs = ifcs.nextElement().getHardwareAddress();
	       }
               if (bs != null) {
                   for (int i = 0; i < 8 && i < bs.length; ++i)
                       h = (h << 8) ^ bs[i];
                   break;
               }
           }
       } catch (Exception ignore) {
       }

?



From volker.simonis at gmail.com  Mon Sep 16 15:20:50 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 16 Sep 2013 17:20:50 +0200
Subject: RFR(M): 8024265: Enable new build on AIX (jdk part)
Message-ID: 

Hi,

could you please review the following webrev which contains the changes
needed in the 'jdk' repository in order to build the OpenJDK on AIX:

http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/

With this change and "8024854: Basic changes and files to build the class
library on AIX "
it will be possible to configure and completely build the staging
repository on AIX 5.3 and 7.1 with the following command:

configure --with-boot-jdk= --with-jvm-variants=core
--with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
--x-includes=/opt/freeware/include

The webrev for 8024854 will follow within the next days...

Below you can find the changes and additions I've done, sorted by file.
Most of them are just additions which are only active during the AIX build
anyway or simple changes where AIX has been added to conditions which
already check for Linux and/or Solaris. Therefore, IMHO the impact on the
existing platforms is really minimal.

Thank you and best regards,
Volker

make/tools/sharing/classlist.aix

   - Add AIX-specific class list.

makefiles/CompileJavaClasses.gmk

   - Add corresponding AIX-files to the list of exclude files for non-AIX
   builds.

makefiles/CompileLaunchers.gmk

   - Statically link libjli on AIX because xlc on AIX doesn't support the
   -rpath option.

makefiles/CompileNativeLibraries.gmk

   - Add required flags for AIX (i.e. by specifying CFLAGS_aix and
   LDFLAGS_SUFFIX_aix).
   - Add corresponding AIX-files to the LIBATTACH_EXCLUDE_FILES list of
   exclude files for non-AIX builds.
   - Specify BUILD_LIBNIO_FILES and BUILD_LIBNIO_MAPFILE for the AIX build.
   - Statically link libjli on AIX becasue xlc on AIX doesn't support the
   -rpath option.
   - Specify -DX_PLATFORM=X_AIX in the LIBJSOUND_CFLAGS on AIX.

makefiles/GendataFontConfig.gmk

   - Specify AIX-specific fontconfig-settings.

makefiles/GensrcX11Wrappers.gmk

   - Use platform-independent $(COMPILER_TARGET_BITS_FLAG) variable
   (introduced by change "8024265: Enable new build on AIX (top level
part)")
instead of hard-coded
   -m option.

makefiles/mapfiles/libattach/mapfile-aix,
makefiles/mapfiles/libnio/mapfile-aix

   - Add currently unused but required dummy mapfiles for AIX build.


From chris.hegarty at oracle.com  Mon Sep 16 15:39:17 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 16 Sep 2013 16:39:17 +0100
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52371E82.9080803@gmail.com>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu> <52371E82.9080803@gmail.com>
Message-ID: <52372625.7050106@oracle.com>

On some platforms, Windows, tunneling interfaces report a very "bad" mac 
address, e.g.  00-00-00-00-00-00-00-E0. I wonder if it is worth skipping 
all isVirtual() nifs?

-Chris.

On 16/09/2013 16:06, Peter Levart wrote:
> Hi Doug,
>
> This seems reasonable for majority of environments.
>
> Regards, Peter
>
> On 09/16/2013 04:50 PM, Doug Lea wrote:
>> On 09/16/2013 10:39 AM, Peter Levart wrote:
>>
>>> So perhaps the right strategy would be to get the hardware address of
>>> the 1st
>>> interface that has it, but don't bother to search more than N interfaces
>>
>> Where N==2 seems to be the best policy, since at most loopback is
>> legitimately null. Putting the suggestions together:
>>
>> private static long initialSeed() {
>> String pp = java.security.AccessController.doPrivileged(
>> new sun.security.action.GetPropertyAction(
>> "java.util.secureRandomSeed"));
>> if (pp != null && pp.equalsIgnoreCase("true")) {
>> byte[] seedBytes = java.security.SecureRandom.getSeed(8);
>> long s = (long)(seedBytes[0]) & 0xffL;
>> for (int i = 1; i < 8; ++i)
>> s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>> return s;
>> }
>> long h = 0L;
>> try {
>> Enumeration ifcs =
>> NetworkInterface.getNetworkInterfaces();
>> boolean retry = false; // retry once if getHardwareAddress is null
>> while (ifcs.hasMoreElements()) {
>> NetworkInterface ifc = ifcs.nextElement();
>> byte[] bs = ifc.getHardwareAddress();
>> if (bs != null) {
>> for (int i = 0; i < 8 && i < bs.length; ++i)
>> h = (h << 8) ^ bs[i];
>> break;
>> }
>> else if (!retry)
>> retry = true;
>> else
>> break;
>> }
>> } catch (Exception ignore) {
>> }
>> return (mix64(h ^ System.currentTimeMillis()) ^
>> mix64(System.nanoTime()));
>> }
>>
>>
>


From chris.hegarty at oracle.com  Mon Sep 16 15:16:05 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 16 Sep 2013 15:16:05 +0000
Subject: hg: jdk8/tl/jdk: 6458027: Disabling IPv6 on a specific network
	interface causes problems
Message-ID: <20130916151646.30F2E6287B@hg.openjdk.java.net>

Changeset: db0fc2b71298
Author:    msheppar
Date:      2013-09-16 14:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db0fc2b71298

6458027: Disabling IPv6 on a specific network interface causes problems
Summary: added a check to test if an interface is configured for IPv6 to native code TwoStacklainDatagramSocketImpl: getMulticastInterface, setMulticastInterface
Reviewed-by: chegar, michaelm

! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
+ test/java/net/MulticastSocket/SetGetNetworkInterfaceTest.java



From sergey.kuksenko at oracle.com  Mon Sep 16 16:22:46 2013
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Mon, 16 Sep 2013 20:22:46 +0400
Subject: RFR: Direct LambdaMetaFactory invocation from CallSite
	significantly improves lambda linkage performance
In-Reply-To: 
References: <523098EF.1090508@oracle.com>
	
Message-ID: <52373056.3070200@oracle.com>

Hi John, Brian,
I did evaluation JDK-8024630(my patch) vs JDK-8024761(your patch).

I did it for lambda linkage vs anonymous classloading. Because of
non-capture lambdas behaviour significantly differ capturing lambdas I
have to measure linkage twice (non-capturing vs capturing). Other
dimension is Tiered vs NonTiered compilation. I checked it on loading
different amount of lambdas (classes) - 1K, 4K, 8K, 16K, 24K, 32K, 64K.
(K=1024)


Non-capturing lambda:
- JDK-8024630 is slightly faster (2-3%) than JDK-8024761 on less amount
of lambdas (1K,4K,8K). But starting from 16K JDK-8024761 is faster (also
2-3%). The same for tiered/non-tiered.

Capturing lambda:
- Non-tiered compilation show the same behaviour and the same
percentages as non-capturing lambda. In case of TieredCompilation the
initial difference is started from 8% (JDK-8024630 is faster) and became
lower and both RFEs has the same performance from 24K lambdas.

So looking into my results I'll vote for JDK-8024761 instead of
JDK-8024630. Because of your solution is general and performance
difference is not significant.

On 09/11/2013 10:18 PM, John Rose wrote:
> Yes, this is a good tactic, but as written it is too much of a point hack for lambdas (important though they are).
> 
> I have an alternate solution I would like you to measure.  It provides a fast path for other BSM lookups like Nashorn's, so (if it works well for lambda) it is preferable.
> 
> I will attach a patch to the bug report.
> 
> ? John
> 
> On Sep 11, 2013, at 9:23 AM, Sergey Kuksenko  wrote:
> 
>> Please review the webrev at:
>>
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
>>
>> LambdaMetafactory is is a quite frequent bootstrap method for
>> invokedynamic in JDK8.
>> We can do direct method (LambdaMetafactory) invocation as fastpath when
>> proved that bootstrap MethodHandle points to LambdaMetafactory.
>> The modification gives +10% - +35% to lambda linkage performance
>> (depends on amount of lambdas).
>>
>> -- 
>> Best regards,
>> Sergey Kuksenko
> 


-- 
Best regards,
Sergey Kuksenko


From john.r.rose at oracle.com  Mon Sep 16 16:50:24 2013
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Sep 2013 09:50:24 -0700
Subject: RFR: Direct LambdaMetaFactory invocation from CallSite
	significantly improves lambda linkage performance
In-Reply-To: <52373056.3070200@oracle.com>
References: <523098EF.1090508@oracle.com>
	
	<52373056.3070200@oracle.com>
Message-ID: <78CD2921-A3DB-4D5A-A99C-0662336E1397@oracle.com>

Thanks for those interesting measurements, Sergey.

As you point out, the 8024761 changes are be more broadly beneficial to most 292 users, such as Nashorn and JRuby.

So I'm glad to hear they hit near the mark of the specialized tweak.  We can keep your tweak in our "back pocket" in case we need the extra boost.  But I think further general work (in the JIT) on folding up MH.invoke will close the observable gap.

? John

On Sep 16, 2013, at 9:22 AM, Sergey Kuksenko  wrote:

> Hi John, Brian,
> I did evaluation JDK-8024630(my patch) vs JDK-8024761(your patch).
> 
> I did it for lambda linkage vs anonymous classloading. Because of
> non-capture lambdas behaviour significantly differ capturing lambdas I
> have to measure linkage twice (non-capturing vs capturing). Other
> dimension is Tiered vs NonTiered compilation. I checked it on loading
> different amount of lambdas (classes) - 1K, 4K, 8K, 16K, 24K, 32K, 64K.
> (K=1024)
> 
> 
> Non-capturing lambda:
> - JDK-8024630 is slightly faster (2-3%) than JDK-8024761 on less amount
> of lambdas (1K,4K,8K). But starting from 16K JDK-8024761 is faster (also
> 2-3%). The same for tiered/non-tiered.
> 
> Capturing lambda:
> - Non-tiered compilation show the same behaviour and the same
> percentages as non-capturing lambda. In case of TieredCompilation the
> initial difference is started from 8% (JDK-8024630 is faster) and became
> lower and both RFEs has the same performance from 24K lambdas.
> 
> So looking into my results I'll vote for JDK-8024761 instead of
> JDK-8024630. Because of your solution is general and performance
> difference is not significant.
> 
> On 09/11/2013 10:18 PM, John Rose wrote:
>> Yes, this is a good tactic, but as written it is too much of a point hack for lambdas (important though they are).
>> 
>> I have an alternate solution I would like you to measure.  It provides a fast path for other BSM lookups like Nashorn's, so (if it works well for lambda) it is preferable.
>> 
>> I will attach a patch to the bug report.
>> 
>> ? John
>> 
>> On Sep 11, 2013, at 9:23 AM, Sergey Kuksenko  wrote:
>> 
>>> Please review the webrev at:
>>> 
>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
>>> 
>>> LambdaMetafactory is is a quite frequent bootstrap method for
>>> invokedynamic in JDK8.
>>> We can do direct method (LambdaMetafactory) invocation as fastpath when
>>> proved that bootstrap MethodHandle points to LambdaMetafactory.
>>> The modification gives +10% - +35% to lambda linkage performance
>>> (depends on amount of lambdas).
>>> 
>>> -- 
>>> Best regards,
>>> Sergey Kuksenko
>> 
> 
> 
> -- 
> Best regards,
> Sergey Kuksenko



From dl at cs.oswego.edu  Mon Sep 16 17:02:10 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 16 Sep 2013 13:02:10 -0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52372625.7050106@oracle.com>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu> <52371E82.9080803@gmail.com>
	<52372625.7050106@oracle.com>
Message-ID: <52373992.2030206@cs.oswego.edu>

On 09/16/2013 11:39 AM, Chris Hegarty wrote:
> On some platforms, Windows, tunneling interfaces report a very "bad" mac
> address, e.g.  00-00-00-00-00-00-00-E0. I wonder if it is worth skipping all
> isVirtual() nifs?
>

Good idea.  This makes it impossible to also take advantage of Guy's
de-uglification though. Leaving the following.

(This might stand as a record for the most expert attention
spent on the least important issue ever in JDK :-)! Recall that
the motivation is solely to act as a tie-breaker in the
incredibly unlikely scenario of a cluster of communicating
hosts all starting at the same time.)


     private static long initialSeed() {
         String pp = java.security.AccessController.doPrivileged(
                 new sun.security.action.GetPropertyAction(
                         "java.util.secureRandomSeed"));
         if (pp != null && pp.equalsIgnoreCase("true")) {
             byte[] seedBytes = java.security.SecureRandom.getSeed(8);
             long s = (long)(seedBytes[0]) & 0xffL;
             for (int i = 1; i < 8; ++i)
                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
             return s;
         }
         long h = 0L;
         try {
             Enumeration ifcs =
                 NetworkInterface.getNetworkInterfaces();
             boolean retry = false; // retry once if getHardwareAddress is null
             while (ifcs.hasMoreElements()) {
                 NetworkInterface ifc = ifcs.nextElement();
                 if (!ifc.isVirtual()) { // skip fake addresses
                     byte[] bs = ifc.getHardwareAddress();
                     if (bs != null) {
                         for (int i = 0; i < 8 && i < bs.length; ++i)
                             h = (h << 8) ^ bs[i];
                         break;
                     }
                     else if (!retry)
                         retry = true;
                     else
                         break;
                 }
             }
         } catch (Exception ignore) {
         }
         return (mix64(h ^ System.currentTimeMillis()) ^
                 mix64(System.nanoTime()));
     }



From aleksey.shipilev at oracle.com  Mon Sep 16 17:22:10 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 16 Sep 2013 21:22:10 +0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52373992.2030206@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu> <52371E82.9080803@gmail.com>
	<52372625.7050106@oracle.com> <52373992.2030206@cs.oswego.edu>
Message-ID: <52373E42.4010004@oracle.com>

On 09/16/2013 09:02 PM, Doug Lea wrote:
> (This might stand as a record for the most expert attention
> spent on the least important issue ever in JDK :-)!

+1.

-Aleksey.


From henry.jen at oracle.com  Mon Sep 16 17:35:07 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Mon, 16 Sep 2013 17:35:07 +0000
Subject: hg: jdk8/tl/jdk: 8024874: Copy-paste typo in the spec for
	j.u.Comparator.thenComparing(Function, Comparator)
Message-ID: <20130916173533.3013562888@hg.openjdk.java.net>

Changeset: 86aa8e7503e9
Author:    henryjen
Date:      2013-09-16 10:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86aa8e7503e9

8024874: Copy-paste typo in the spec for j.u.Comparator.thenComparing(Function, Comparator)
Reviewed-by: mduigou

! src/share/classes/java/util/Comparator.java



From volker.simonis at gmail.com  Mon Sep 16 17:37:31 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 16 Sep 2013 19:37:31 +0200
Subject: RFR(L): 8024854: Basic changes and files to build the class library
	on AIX
Message-ID: 

 Hi,

could you please review the following webrev which contains the basic
changes and files needed in the 'jdk' repository in order to build the
OpenJDK on AIX:

http://cr.openjdk.java.net/~simonis/webrevs/8024854

This change together with "8024265: Enable new build on AIX (jdk
part)"
allows it to configure and completely build the staging repository on AIX
5.3 and 7.1 with the following command:

configure --with-boot-jdk= --with-jvm-variants=core
--with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
--x-includes=/opt/freeware/include

Below you can find the changes and additions I've done, sorted by file.
Most of them are just additions which are only active during the AIX build
anyway or simple changes where AIX has been added to conditions which
already check for Linux and/or Solaris. The files with the biggest changes
which you're probably want to look on more thoroughly are
'src/solaris/native/java/net/NetworkInterface.c' and
'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change
anything on the current OpenJDK platforms as well.

Notice that there are still some files and some functionality missing from
the current change (notably NIO) but it still yields a running JDK which
can execute "HelloWorld" on the command line and as AWT application. I've
intentionally tried to keep this initial change as simple as possible (with
respect tot shared changes) in order to get it reviewed as fast as
possible. The missing parts can then be added later on, grouped by logical
topics, to simplify the review process.

Thank you and best regards,
Volker

src/share/bin/jli_util.h

   - Define JLI_Lseek on AIX.

src/share/lib/security/java.security-aix

   - Provide default java.security-aix for AIX.

src/share/native/sun/awt/medialib/mlib_sys.c

   - malloc always returns 8-byte aligned pointers on AIX as well.

src/share/native/sun/awt/medialib/mlib_types.h

   - Add AIX to the list of known platforms.

src/share/native/sun/font/layout/KernTable.cpp

   - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common
   and may be defined in other headers as well as on the command line and
   xlc bails out on macro redefinitions with a different value.

src/share/native/sun/security/ec/impl/ecc_impl.h

   - Define required types and macros on AIX.

src/solaris/back/exec_md.c

   - AIX behaves like Linux in this case so check for it in the Linux
   branch.

src/solaris/bin/java_md_solinux.c,
src/solaris/bin/java_md_solinux.h

   - On AIX LD_LIBRARY_PATH is called LIBPATH
   - Always use LD_LIBRARY_PATH macro instead of using the string "
   LD_LIBRARY_PATH" directly to cope with different library path names.
   - Add jre/lib//jli to the standard library search path on AIX
   because the AIX linker doesn't support the -rpath option.
   - Replace #ifdef __linux__ by #ifndef __solaris__ because in this case,
   AIX behaves like Linux.

src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties

   - Provide basic fontconfig.propertiesfor AIX.

src/solaris/classes/java/lang/UNIXProcess.java.aix,
src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
src/solaris/classes/sun/tools/attach/AixVirtualMachine.java

   - Provide AIX specific Java versions, mostly based on the corresponding
   Linux versions.

src/solaris/demo/jvmti/hprof/hprof_md.c

   - Add AIX support. AIX mostly behaves like Linux, with the one exception
   that it has no dladdr functionality.
   - Implement dladdr functionality for AIX.

src/solaris/native/com/sun/management/UnixOperatingSystem_md.c

   - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).

src/solaris/native/common/jdk_util_md.h

   - Add AIX definitions of the ISNANF and ISNAND macros.

src/solaris/native/java/io/io_util_md.c

   - AIX behaves like Linux in this case so check for it in the Linux
   branch.

src/solaris/native/java/net/NetworkInterface.c

   - Add AIX support into the Linux branch because AIX mostly behaves like
   AIX for IPv4.
   - AIX needs a special function to enumerate IPv6 interfaces and to query
   the MAC address.

src/solaris/native/java/net/PlainSocketImpl.c

   - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
   socket is closed. The default error message is then confusing.

src/solaris/native/java/net/linux_close.c,
src/share/native/java/net/net_util.c

   - Also use the file and socket wrappers on AIX.
   - Add initialization of some previously uninitialized data structures.
   - On AIX we don't have __attribute((constructor)) so we need to
   initialize manually (from JNI_OnLoad() in
   'src/share/native/java/net/net_util.c'

src/solaris/native/java/net/net_util_md.h

   - AIX needs the same workaround for I/O cancellation like Linux and
   MacOSX.

src/solaris/native/java/util/TimeZone_md.c

   - Currently on AIX the only way to get the platform time zone is to read
   it from the TZ environment variable.

src/solaris/native/sun/awt/awt_LoadLibrary.c

   - There's no dladdr on AIX, but we can use the implementation from the
   HotSpot in this case because libjvm.so will be always loaded before the
   AWT.

src/solaris/native/sun/awt/fontpath.c

   - Add AIX specific fontpath settings and library search paths for
   libfontconfig.so.

src/solaris/native/sun/java2d/x11/X11SurfaceData.c

   - Only define MIN and MAX if they're not already defined because xlc on
   AIX fails on macro redefinitions.

src/solaris/native/sun/java2d/x11/XRBackendNative.c

   - Handle AIX like Solaris.

src/solaris/native/sun/nio/ch/Net.c

   - Add AIX-specific includes and constant definitions.
   - On AIX "socket extensions for multicast source filters" support
   depends on the OS version. Check for this and throw appropriate exceptions
   if it requested but not supported. This is needed to pass
   JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast

src/solaris/native/sun/security/pkcs11/j2secmod_md.c

   - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.

src/solaris/native/sun/tools/attach/AixVirtualMachine.c

   - AIX version mostly derived from the corresponding Linux version.


From Alan.Bateman at oracle.com  Mon Sep 16 18:11:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Sep 2013 19:11:36 +0100
Subject: RFR(L): 8024854: Basic changes and files to build the class
	library on AIX
In-Reply-To: 
References: 
Message-ID: <523749D8.8010200@oracle.com>

On 16/09/2013 18:37, Volker Simonis wrote:
>   Hi,
>
> could you please review the following webrev which contains the basic
> changes and files needed in the 'jdk' repository in order to build the
> OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854
>
Hi Volker,

You'll probably need to send the webrev to serviceability-dev, awt-dev 
and 2d-dev to catch more of the areas that are touched here.

I don't have time to look at this closely now but just a few comments 
from a quick pass:

1. There are a few changes for OS/400 in the patch, are they supposed to 
be there?

2. In src/solaris/native/sun/nio/ch/Net.c then I don't think the 
throwing of UOE is needed in any of the join or block functions. Instead 
you should be able to just adjust the error handling to map EOPNOTSUPP 
to IOS_UNAVAILABLE and it should work (at least I assume the issue is 
that AIX must be failing with EOPNOTSUPP rather than ENOPROTOOPT). You 
can also just return IOS_UNAVAILABLE isSourceFilterSupported return 
JNI_FALSE.

3. src/solaris/native/java/net/linux_close.c. Given the expanded usage 
then we should really consider renaming this. Also given the lack of 
__attribute((constructor)) support then it might make sense to always 
initialize the close mechanism from JNI_OnLoad (on platforms that need 
it). This is something for net-dev of course.

That's all I have for a quick first pass, there are actually a lot less 
changes that I expected. The patch reminds me (again) that we really 
need to sort out the src/solaris tree. I'm actually curious if it would 
build with the AIX specific sources in src/aix.

-Alan


From guy.steele at oracle.com  Mon Sep 16 18:11:52 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Mon, 16 Sep 2013 14:11:52 -0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <52373992.2030206@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu> <52371E82.9080803@gmail.com>
	<52372625.7050106@oracle.com> <52373992.2030206@cs.oswego.edu>
Message-ID: <656CE6B7-EA7D-4944-9B63-F5CA943B1B1A@oracle.com>


On Sep 16, 2013, at 1:02 PM, Doug Lea 
 wrote:

> On 09/16/2013 11:39 AM, Chris Hegarty wrote:
>> On some platforms, Windows, tunneling interfaces report a very "bad" mac
>> address, e.g.  00-00-00-00-00-00-00-E0. I wonder if it is worth skipping all
>> isVirtual() nifs?
>> 
> 
> Good idea.  This makes it impossible to also take advantage of Guy's
> de-uglification though. Leaving the following.
> 
> (This might stand as a record for the most expert attention
> spent on the least important issue ever in JDK :-)! Recall that
> the motivation is solely to act as a tie-breaker in the
> incredibly unlikely scenario of a cluster of communicating
> hosts all starting at the same time.)


+1

Okay, as long as we're obsessing: the code defends against the hardware
address being longer than 8 bytes.  Should the trailing bytes be the ones
dropped?  In a MAC address, I think they are the ones more likely to be
distinct (the leading bytes indicate manufacturer, yes?).  Then again,
does the Java interface provide any guarantees about the order in which
the bytes are presented in the array?

So how about this code?

                   if (bs != null) {
		       int m = Math.min(bs.length >> 1, 4);
                       for (int i = 0; i < m; ++i)
                           h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
		       if (m < 4) h = (h << 8) ^ bs[n-1-m];  // might include this byte twice, but this is the cheapest possible test for whether we *don't* want it
                       break;
                   }

:-) :-)

--Guy



From martinrb at google.com  Mon Sep 16 18:27:42 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 16 Sep 2013 11:27:42 -0700
Subject: RFR 8024405: Spliterators.spliterator should support CONCURRENT
	characteristic
In-Reply-To: 
References: 
Message-ID: 

delete "the" typo

+     * @param characteristics Characteristics of the this spliterator's source


A top-level Spliterator should not report CONCURRENT and SIZED
=>
A top-level Spliterator should not report both CONCURRENT and SIZED


I think the docs for SIZED can make it clearer that it is an error for the
size to change while the spliterator is in progress.  One can imagine
CONCURRENT data structures whose SIZE does not change.  An iterator over an
*AtomicReferenceArray
comes
to mind.*

static final int SIZED

Characteristic value signifying that the value returned from
estimateSize() prior
to traversal or splitting represents a finite size that, in the absence of
structural source modification, represents an exact count of the number of
elements that would be encountered by a complete traversal.


On Sun, Sep 15, 2013 at 9:03 AM, Paul Sandoz  wrote:

> Hi,
>
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8024405-spliterators-size-concurrent/webrev/
>
> This fixes an oversight in creating spliterators from the iterator of a
> collection or directly from an iterator (+ primitive variants).
>
> If CONCURRENT is supplied as a characteristic then the returned
> spliterator should not report SIZED/SUBSIZED.
>
> This could have resulted in an issue with ArrayBlockingQueue since it's
> spliterator is created from a weakly consistently iterator and thus exact
> size is not known.
>
> A CCC is required.
>
> Paul.
>


From martinrb at google.com  Mon Sep 16 18:36:40 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 16 Sep 2013 11:36:40 -0700
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work on
	Windows
In-Reply-To: <523594CA.4070104@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com> <52355E90.7090501@oracle.com>
	<523594CA.4070104@oracle.com>
Message-ID: 

I'm only doing superficial review, but Looks Good To Me!


From eric.mccorkle at oracle.com  Mon Sep 16 18:50:33 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Mon, 16 Sep 2013 14:50:33 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <5233B26B.40000@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
	<52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com>
Message-ID: <523752F9.5050509@oracle.com>

I pulled the class files into byte array constants, as a temporary
measure until a viable method for testing bad class files is developed.

The webrev has been refreshed.  The class files will be taken out before
I push.

http://cr.openjdk.java.net/~emc/8020981/

On 09/13/13 20:48, Joe Darcy wrote:
> To avoid storing binaries in Hg, you could try something like:
> 
> * uuencode / ascii armor the class file
> * convert to byte array in the test
> * load classes from byte array
> 
> -Joe
> 
> On 09/13/2013 11:54 AM, Eric McCorkle wrote:
>> I did it by hand with emacs.
>>
>> I would really rather tackle the bad class files for testing issue once
>> and for all, the Right Way (tm).  But with ZBB looming, now is not the
>> time to do it.
>>
>> Hence, I have created this task
>> https://bugs.openjdk.java.net/browse/JDK-8024674
>>
>> I also just created this one:
>> https://bugs.openjdk.java.net/browse/JDK-8024812
>>
>> On 09/13/13 13:54, Peter Levart wrote:
>>> Hi Eric,
>>>
>>> How did you create those class files? By hand using a HEX editor? Did
>>> you create a program that patched the original class file? If the later
>>> is the case, you could pack that patching logic inside a custom
>>> ClassLoader...
>>>
>>> To hacky? Dependent on future changes of javac? At least the "bad name"
>>> patching could be performed trivially and reliably, I think: search and
>>> replace with same-length string.
>>>
>>> Regards, Peter
>>>
>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>>>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>>>
>>>> I have already filed a task for test development post ZBB to develop a
>>>> solution for generating bad class files.  I'd prefer to file a
>>>> follow-up
>>>> to this to add the bad class file tests when that's done.
>>>>
>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>>>>> I think the right thing to do is to include the original compiling
>>>>> source in a comment, together with a comment on how you modify
>>>>> them, and then the result as a byte array.
>>>>>
>>>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>>>
>>>>> cheers
>>>>> /Joel
>>>>>
>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle
>>>>>  wrote:
>>>>>
>>>>>> There is no simple means of generating bad class files for testing.
>>>>>> This is a huge deficiency in our testing abilities.
>>>>>>
>>>>>> If these class files shouldn't go in, then I'm left with no choice
>>>>>> but
>>>>>> to check in no test for this patch.
>>>>>>
>>>>>> However, anyone can run the test I've provided with the class
>>>>>> files and
>>>>>> see that it works.
>>>>>>
>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>>>>> Hi Eric,
>>>>>>>
>>>>>>> IIRC we don't check in classfiles into the repo.
>>>>>>>
>>>>>>> I'm not sure how we handle testing of broken class-files in jdk,
>>>>>>> but ASM might be an option, or storing the class file as an
>>>>>>> embedded byte array in the test.
>>>>>>>
>>>>>>> cheers
>>>>>>> /Joel
>>>>>>>
>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> A new webrev is posted (and crucible updated), which actually
>>>>>>>> validates
>>>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>>>
>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review this patch, which implements correct behavior for
>>>>>>>>> the
>>>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>>>
>>>>>>>>> The bug report is here:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>>>
>>>>>>>>> The webrev is here:
>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>>>
>>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Eric
>>>>>>>>>
>>>>>> 
> 

From paul.sandoz at oracle.com  Mon Sep 16 19:13:30 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 16 Sep 2013 21:13:30 +0200
Subject: RFR 8024405: Spliterators.spliterator should support CONCURRENT
	characteristic
In-Reply-To: 
References: 
	
Message-ID: 

On Sep 16, 2013, at 8:27 PM, Martin Buchholz  wrote:
> delete "the" typo
> +     * @param characteristics Characteristics of the this spliterator's source
> 
> 
> A top-level Spliterator should not report CONCURRENT and SIZED
> =>
> A top-level Spliterator should not report both CONCURRENT and SIZED
> 

Thanks i updated Spliterators and Spliterator.


> 
> I think the docs for SIZED can make it clearer that it is an error for the size to change while the spliterator is in progress.  One can imagine CONCURRENT data structures whose SIZE does not change.  An iterator over an AtomicReferenceArray comes to mind.

I presume each element is an instance of AtomicReference? so elements of the array are not concurrently replaced but the values held by the ARs, and the iterator would need to report a ConcurrentModificationException if structural interference is detected? under such circumstances it might be OK for a spliterator of such a data structure to report SIZED/SUBSIZED.

Paul. 

From volker.simonis at gmail.com  Mon Sep 16 19:30:10 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 16 Sep 2013 21:30:10 +0200
Subject: RFR(L): 8024854: Basic changes and files to build the class library
	on AIX
In-Reply-To: 
References: 
Message-ID: 

Resending this to more lists as requested by Alan Bateman with the kind
request to anybody to review the parts for which he feels responsible:)

For those not up to date, this change is part of the ongoing PowerPC/AIX
Porting Project:
http://openjdk.java.net/projects/ppc-aix-port
https://wiki.openjdk.java.net/display/PPCAIXPort
http://openjdk.java.net/jeps/175

Please send reviews to all currently included recipients.

Thank you and best regards,
Volker


---------- Forwarded message ----------
From: *Volker Simonis*
Date: Monday, September 16, 2013
Subject: RFR(L): 8024854: Basic changes and files to build the class
library on AIX
To: "ppc-aix-port-dev at openjdk.java.net" ,
Java Core Libs 


Hi,

could you please review the following webrev which contains the basic
changes and files needed in the 'jdk' repository in order to build the
OpenJDK on AIX:

http://cr.openjdk.java.net/~simonis/webrevs/8024854

This change together with "8024265: Enable new build on AIX (jdk
part)"
allows it to configure and completely build the staging repository on AIX
5.3 and 7.1 with the following command:

configure --with-boot-jdk= --with-jvm-variants=core
--with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
--x-includes=/opt/freeware/include

Below you can find the changes and additions I've done, sorted by file.
Most of them are just additions which are only active during the AIX build
anyway or simple changes where AIX has been added to conditions which
already check for Linux and/or Solaris. The files with the biggest changes
which you're probably want to look on more thoroughly are
'src/solaris/native/java/net/NetworkInterface.c' and
'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change
anything on the current OpenJDK platforms as well.

Notice that there are still some files and some functionality missing from
the current change (notably NIO) but it still yields a running JDK which
can execute "HelloWorld" on the command line and as AWT application. I've
intentionally tried to keep this initial change as simple as possible (with
respect tot shared changes) in order to get it reviewed as fast as
possible. The missing parts can then be added later on, grouped by logical
topics, to simplify the review process.

Thank you and best regards,
Volker

src/share/bin/jli_util.h

   - Define JLI_Lseek on AIX.

src/share/lib/security/java.security-aix

   - Provide default java.security-aix for AIX.

src/share/native/sun/awt/medialib/mlib_sys.c

   - malloc always returns 8-byte aligned pointers on AIX as well.

src/share/native/sun/awt/medialib/mlib_types.h

   - Add AIX to the list of known platforms.

src/share/native/sun/font/layout/KernTable.cpp

   - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common
   and may be defined in other headers as well as on the command line and
   xlc bails out on macro redefinitions with a different value.

src/share/native/sun/security/ec/impl/ecc_impl.h

   - Define required types and macros on AIX.

src/solaris/back/exec_md.c

   - AIX behaves like Linux in this case so check for it in the Linux
   branch.

src/solaris/bin/java_md_solinux.c,
src/solaris/bin/java_md_solinux.h

   - On AIX LD_LIBRARY_PATH is called LIBPATH
   - Always use LD_LIBRARY_PATH macro instead of using the string "
   LD_LIBRARY_PATH" directly to cope with different library path names.
   - Add jre/lib//jli to the standard library search path on AIX
   because the AIX linker doesn't support the -rpath option.
   - Replace #ifdef __linux__ by #ifndef __solaris__ because in this case,
   AIX behaves like Linux.

src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties

   - Provide basic fontconfig.propertiesfor AIX.

src/solaris/classes/java/lang/UNIXProcess.java.aix,
src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
src/solaris/classes/sun/tools/attach/AixVirtualMachine.java

   - Provide AIX specific Java versions, mostly based on the corresponding
   Linux versions.

src/solaris/demo/jvmti/hprof/hprof_md.c

   - Add AIX support. AIX mostly behaves like Linux, with the one exception
   that it has no dladdr functionality.
   - Implement dladdr functionality for AIX.

src/solaris/native/com/sun/management/UnixOperatingSystem_md.c

   - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).

src/solaris/native/common/jdk_util_md.h

   - Add AIX definitions of the ISNANF and ISNAND macros.

src/solaris/native/java/io/io_util_md.c

   - AIX behaves like Linux in this case so check for it in the Linux
   branch.

src/solaris/native/java/net/NetworkInterface.c

   - Add AIX support into the Linux branch because AIX mostly behaves like
   AIX for IPv4.
   - AIX needs a special function to enumerate IPv6 interfaces and to query
   the MAC address.

src/solaris/native/java/net/PlainSocketImpl.c

   - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
   socket is closed. The default error message is then confusing.

src/solaris/native/java/net/linux_close.c,
src/share/native/java/net/net_util.c

   - Also use the file and socket wrappers on AIX.
   - Add initialization of some previously uninitialized data structures.
   - On AIX we don't have __attribute((constructor)) so we need to
   initialize manually (from JNI_OnLoad() in
   'src/share/native/java/net/net_util.c'

src/solaris/native/java/net/net_util_md.h

   - AIX needs the same workaround for I/O cancellation like Linux and
   MacOSX.

src/solaris/native/java/util/TimeZone_md.c

   - Currently on AIX the only way to get the platform time zone is to read
   it from the TZ environment variable.

src/solaris/native/sun/awt/awt_LoadLibrary.c

   - There's no dladdr on AIX, but we can use the implementation from the
   HotSpot in this case because libjvm.so will be always loaded before the
   AWT.

src/solaris/native/sun/awt/fontpath.c

   - Add AIX specific fontpath settings and library search paths for
   libfontconfig.so.

src/solaris/native/sun/java2d/x11/X11SurfaceData.c

   - Only define MIN and MAX if they're not already defined because xlc on
   AIX fails on macro redefinitions.

src/solaris/native/sun/java2d/x11/XRBackendNative.c

   - Handle AIX like Solaris.

src/solaris/native/sun/nio/ch/Net.c

   - Add AIX-specific includes and constant definitions.
   - On AIX "socket extensions for multicast source filters" support
   depends on the OS version. Check for this and throw appropriate exceptions
   if it requested but not supported. This is needed to pass
   JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast

src/solaris/native/sun/security/pkcs11/j2secmod_md.c

   - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.

src/solaris/native/sun/tools/attach/AixVirtualMachine.c

   - AIX version mostly derived from the corresponding Linux version.


From mike.duigou at oracle.com  Mon Sep 16 19:49:42 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 16 Sep 2013 12:49:42 -0700
Subject: RFR: 8023339: (xs) Refine UOE conditions for removeIf()
In-Reply-To: 
References: 
	
Message-ID: 

I think this is a reasonable compromise (and will be what I use for the other cases).

Thanks!

Mike

On Sep 16 2013, at 01:13 , Paul Sandoz wrote:

> Hi Mike,
> 
> I suppose there could also be implementations of removeIf that always throw UOE regardless of whether an element matched or not i.e. those that override just to throw UOE.
> 
> So perhaps:
> 
> * @throws UnsupportedOperationException if elements cannot be removed 
> *         from this collection.  Implementations may throw this exception if a
> *         matching element cannot be removed or if, in general, removal is not 
> *         supported.
> 
> Paul.
> 
> On Sep 13, 2013, at 11:52 PM, Mike Duigou  wrote:
> 
>> Hello all;
>> 
>> A very small patch that refines the declared conditions under which the Collection.removeIf() method will throw UOE. The intent of this patch is to allow the default implementation to be used for immutable collections. It's important that the default implementations provided and the specifications of the methods allow for the behaviour which results from using the default method implementation on any reasonable implementation including immutable implementations. In this case there was a bug originally written against j.u.Arrays.asList() The bug asserted that it's removeIf() implementation was "lazy" and only throws UOE when an element is to be removed. One possible solution was to add a non-default implementation of removeIf() to the Arrays.asList()-List. Since the default method definition must also satisfy other potential immutable implementations we decided to enhance the UOE conditions rather than paper over the problem by adding a default.
>> 
>> (There are a couple of other similar issues which will have similar solutions)
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8023339/1/
>> 
>> Mike
>> 
> 



From martinrb at google.com  Mon Sep 16 20:46:13 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 16 Sep 2013 13:46:13 -0700
Subject: RFR 8024405: Spliterators.spliterator should support CONCURRENT
	characteristic
In-Reply-To: 
References: 
	
	
Message-ID: 

On Mon, Sep 16, 2013 at 12:13 PM, Paul Sandoz wrote:

> >
> > I think the docs for SIZED can make it clearer that it is an error for
> the size to change while the spliterator is in progress.  One can imagine
> CONCURRENT data structures whose SIZE does not change.  An iterator over an
> AtomicReferenceArray comes to mind.
>
> I presume each element is an instance of AtomicReference? so elements of
> the array are not concurrently replaced but the values held by the ARs, and
> the iterator would need to report a ConcurrentModificationException if
> structural interference is detected? under such circumstances it might be
> OK for a spliterator of such a data structure to report SIZED/SUBSIZED.
>

 AtomicReferenceArray is an array of T, with elements atomically updated.
 You could argue there is never any "structural" modification, just like an
array of final AtomicReference ... which might qualify for IMMUTABLE.

Anyways, no matter what simple rules you come up with, someone will have a
data structure where it won't quite fit in.


From vladimir.kozlov at oracle.com  Mon Sep 16 21:32:31 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 16 Sep 2013 14:32:31 -0700
Subject: RFR(M): 8024265: Enable new build on AIX (jdk part)
In-Reply-To: 
References: 
Message-ID: <523778EF.5040007@oracle.com>

Volker,

You need different bug ID for these JDK changes.
8024265 (top level changes) is already fixed:

https://bugs.openjdk.java.net/browse/JDK-8024265

I created new one for you:

https://bugs.openjdk.java.net/browse/JDK-8024900

Thanks,
Vladimir

On 9/16/13 8:20 AM, Volker Simonis wrote:
>
>         Hi,
>
> could you please review the following webrev which contains the changes
> needed in the 'jdk' repository in order to build the OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/
> 
>
> With this change and "8024854: Basic changes and files to build the
> class library on AIX
> " it will be
> possible to configure and completely build the staging repository on AIX
> 5.3 and 7.1 with the following command:
>
> configure --with-boot-jdk= --with-jvm-variants=core
> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
> --x-includes=/opt/freeware/include
>
> The webrev for 8024854 will follow within the next days...
>
> Below you can find the changes and additions I've done, sorted by file.
> Most of them are just additions which are only active during the AIX
> build anyway or simple changes where AIX has been added to conditions
> which already check for Linux and/or Solaris. Therefore, IMHO the impact
> on the existing platforms is really minimal.
>
> Thank you and best regards,
>
> Volker
>
>
>         make/tools/sharing/classlist.aix
>
>   * Add AIX-specific class list.
>
>
>         makefiles/CompileJavaClasses.gmk
>
>   * Add corresponding AIX-files to the list of exclude files for non-AIX
>     builds.
>
>
>         makefiles/CompileLaunchers.gmk
>
>   * Statically link |libjli| on AIX because |xlc| on AIX doesn't support
>     the |-rpath| option.
>
>
>         makefiles/CompileNativeLibraries.gmk
>
>   * Add required flags for AIX (i.e. by specifying |CFLAGS_aix| and
>     |LDFLAGS_SUFFIX_aix|).
>   * Add corresponding AIX-files to the |LIBATTACH_EXCLUDE_FILES| list of
>     exclude files for non-AIX builds.
>   * Specify |BUILD_LIBNIO_FILES| and |BUILD_LIBNIO_MAPFILE| for the AIX
>     build.
>   * Statically link |libjli| on AIX becasue |xlc| on AIX doesn't support
>     the |-rpath| option.
>   * Specify |-DX_PLATFORM=X_AIX| in the |LIBJSOUND_CFLAGS| on AIX.
>
>
>         makefiles/GendataFontConfig.gmk
>
>   * Specify AIX-specific fontconfig-settings.
>
>
>         makefiles/GensrcX11Wrappers.gmk
>
>   * Use platform-independent |$(COMPILER_TARGET_BITS_FLAG)| variable
>     (introduced by change "8024265: Enable new build on AIX (top level
>     part)"
>      )
>     instead of hard-coded |-m| option.
>
>
>         makefiles/mapfiles/libattach/mapfile-aix,
>         makefiles/mapfiles/libnio/mapfile-aix
>
>   * Add currently unused but required dummy mapfiles for AIX build.
>
>


From mike.duigou at oracle.com  Mon Sep 16 22:49:43 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 16 Sep 2013 15:49:43 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: <8811C5FD-389A-4FF8-9157-F1DEFD4C9A9F@oracle.com>
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	<8811C5FD-389A-4FF8-9157-F1DEFD4C9A9F@oracle.com>
Message-ID: <3A32F64F-000A-492D-A120-4883FFA7BB25@oracle.com>

Ping!

(still need a reviewer on this)

Mike

On Sep 4 2013, at 11:44 , Mike Duigou wrote:

> Hello all;
> 
> I have updated the proposed changeset for this issue. I have moved the note to the interface documentation for Collection and Map and made it more general:
> 
>> Some collection operations which perform recursive traversal of the
>> collection may fail with an exception for self-referential instances where
>> the collection directly or indirectly contains itself. This includes the
>> {@code clone()}, {@code equals()}, {@code hashCode()} and {@code toString()}
>> methods. Implementations may optionally handle the self-referential scenario,
>> however most current implementations do not do so.
> 
> The webrev is at:
> 
> http://cr.openjdk.java.net/~mduigou/JDK-7057785/1/webrev/
> 
> Mike
> 
> On Aug 27 2013, at 19:06 , Mike Duigou wrote:
> 
>> Hello all;
>> 
>> Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is:
>> 
>>> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances.
>> 
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/
>> 
>> Cheers,
>> 
>> Mike
> 



From joe.darcy at oracle.com  Mon Sep 16 23:29:50 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Mon, 16 Sep 2013 16:29:50 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: <3A32F64F-000A-492D-A120-4883FFA7BB25@oracle.com>
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	<8811C5FD-389A-4FF8-9157-F1DEFD4C9A9F@oracle.com>
	<3A32F64F-000A-492D-A120-4883FFA7BB25@oracle.com>
Message-ID: <5237946E.5070008@oracle.com>

Looks fine; cheers,

-Joe

On 9/16/2013 3:49 PM, Mike Duigou wrote:
> Ping!
>
> (still need a reviewer on this)
>
> Mike
>
> On Sep 4 2013, at 11:44 , Mike Duigou wrote:
>
>> Hello all;
>>
>> I have updated the proposed changeset for this issue. I have moved the note to the interface documentation for Collection and Map and made it more general:
>>
>>> Some collection operations which perform recursive traversal of the
>>> collection may fail with an exception for self-referential instances where
>>> the collection directly or indirectly contains itself. This includes the
>>> {@code clone()}, {@code equals()}, {@code hashCode()} and {@code toString()}
>>> methods. Implementations may optionally handle the self-referential scenario,
>>> however most current implementations do not do so.
>> The webrev is at:
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-7057785/1/webrev/
>>
>> Mike
>>
>> On Aug 27 2013, at 19:06 , Mike Duigou wrote:
>>
>>> Hello all;
>>>
>>> Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is:
>>>
>>>> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances.
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/
>>>
>>> Cheers,
>>>
>>> Mike



From dl at cs.oswego.edu  Mon Sep 16 23:22:07 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 16 Sep 2013 19:22:07 -0400
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <656CE6B7-EA7D-4944-9B63-F5CA943B1B1A@oracle.com>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu> <52371E82.9080803@gmail.com>
	<52372625.7050106@oracle.com> <52373992.2030206@cs.oswego.edu>
	<656CE6B7-EA7D-4944-9B63-F5CA943B1B1A@oracle.com>
Message-ID: <5237929F.7070200@cs.oswego.edu>

On 09/16/2013 02:11 PM, Guy Steele wrote:

> Okay, as long as we're obsessing: the code defends against the hardware
> address being longer than 8 bytes.

This was to protect ourselves from the impact of this code being used in some
alternative universe in which hardware addresses are not always 48bits.
But you are right that we could do a little better.

> So how about this code?
>...
>                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];

On first glance the sign extension of byte to long conversion
makes this suspicious, but I see that it cannot hurt.
So, sure; thanks.

Here's the full current version, including another minor tweak.
(Paul: I'm committing to our CVS.)

     private static long initialSeed() {
         String pp = java.security.AccessController.doPrivileged(
                 new sun.security.action.GetPropertyAction(
                         "java.util.secureRandomSeed"));
         if (pp != null && pp.equalsIgnoreCase("true")) {
             byte[] seedBytes = java.security.SecureRandom.getSeed(8);
             long s = (long)(seedBytes[0]) & 0xffL;
             for (int i = 1; i < 8; ++i)
                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
             return s;
         }
         long h = 0L;
         try {
             Enumeration ifcs =
                 NetworkInterface.getNetworkInterfaces();
             boolean retry = false; // retry once if getHardwareAddress is null
             while (ifcs.hasMoreElements()) {
                 NetworkInterface ifc = ifcs.nextElement();
                 if (!ifc.isVirtual()) { // skip fake addresses
                     byte[] bs = ifc.getHardwareAddress();
                     if (bs != null) {
                         int n = bs.length;
                         int m = Math.min(n >>> 1, 4);
                         for (int i = 0; i < m; ++i)
                             h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
                         if (m < 4)
                             h = (h << 8) ^ bs[n-1-m];
                         h = mix64(h);
                         break;
                     }
                     else if (!retry)
                         retry = true;
                     else
                         break;
                 }
             }
         } catch (Exception ignore) {
         }
         return (h ^ mix64(System.currentTimeMillis()) ^
                 mix64(System.nanoTime()));
     }



From brian.burkhalter at oracle.com  Mon Sep 16 23:44:57 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 16 Sep 2013 16:44:57 -0700
Subject: JDK 7u-dev review request 8024356: Double.parseDouble() is slow
	for long Strings
In-Reply-To: 
References: <220E3CFD-178A-43BE-9677-DEB8499DCBF9@oracle.com>
	<5230ACFC.9040801@oracle.com>
	
	
	<952E6A1A-32D6-4A4C-B6D5-5E5FA45B7A86@oracle.com>
	
	<52328A75.8030208@redhat.com>
	
	
	
Message-ID: <54E30250-3DE7-415D-B26B-031E0D92C1B3@oracle.com>


On Sep 13, 2013, at 7:02 PM, Dmitry Nadezhin wrote:

> I agree with 1100 for this review (JDK7).

OK. I will post an approval request to 7u-dev for the patch as-is.

> I think that we shouldn't change from 1100 to 768 in JDK8 because this is a small performance enhancement.
> This will save time for fixing other bugs.

Fine with me.

> The performance enhancement could be smarter if we replace constant MAX_NDIGIT by some piece-linear function
> function maxNDigit(decExponent). See:
> http://cr.openjdk.java.net/~bpb/nDigits/java/double.pdf
> I'd like to postpone this to JDK9 .


Thanks,

Brian

From mike.duigou at oracle.com  Tue Sep 17 00:16:42 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 16 Sep 2013 17:16:42 -0700
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
Message-ID: 

Hello all;

This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor. 

Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired.

http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/

Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person).

Mike

From vladimir.kozlov at oracle.com  Tue Sep 17 00:29:07 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 16 Sep 2013 17:29:07 -0700
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: 
References: 
Message-ID: <5237A253.4060705@oracle.com>

Looks good. Both.

I assume you will send webrev for closed changes.

Thanks,
Vladimir

PS: RIP jbb2005 ;)

On 9/16/13 5:16 PM, Mike Duigou wrote:
> Hello all;
>
> This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor.
>
> Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/
>
> Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person).
>
> Mike
>


From john.r.rose at oracle.com  Tue Sep 17 00:41:05 2013
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Sep 2013 17:41:05 -0700
Subject: RFR: Caching MethodType's descriptor string improves lambda
	linkage performance
In-Reply-To: <5230BE6B.6090104@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
Message-ID: <4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>

The algorithmic change (string cache) is acceptable, although it will tend to increase footprint somewhat.  We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well.  What you propose is fine.

But, please don't hand-inline methods (checkPtype, checkSlotCount).  That is usually the wrong answer.  If there is a JIT inlining decision that isn't going right, we need to fix that, not distort the Java code.

Also, I think you deleted a call to checkSlotCount that should still be there to detect illegal inputs.  One of the costs of hand-inlining is bitrot like that.

? John

On Sep 11, 2013, at 12:03 PM, Sergey Kuksenko  wrote:

> On 09/11/2013 09:01 PM, Aleksey Shipilev wrote:
>> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/
>> 
>> As much as I hate to see the hand code tweaking instead of relying on
>> compiler to do it's job, I understand this is about interpreter. Seems
>> good then.
>> 
>> * Formatting: "if(...)" should be "if (...")
> Will do
>> 
>> * Formatting: "//NPE" should be "// null check"
> I just preserve exiting comments.
> Decided don't modify original code which is not important to required
> functionality.
> 
>> 
>> * Formatting: "desc =  " should be "desc = "
>> 
>> * Formatting: this one should not use braces (for consistency with other
>> usages)?
>> 364         if(nptype == null) { //NPE
>> 365             throw new NullPointerException();
>> 366         }
> Let ask code owner.
>> 
>> * Explicit null-checks: implicits via .getClass and .equals always
>> bothered me in j.l.i.*; the idea was seemingly to piggyback on the
>> compiler intrinsics. 
> anyway it is doesn't matter after C1/C2
> 
>> Any idea what's the cost of using
>> Objects.requireNonNull there?
> If we are running under the interpreter Objects.requireNonNull costs
> enough to eliminate benefits from this fine tuning.
> 
> -- 
> Best regards,
> Sergey Kuksenko



From david.holmes at oracle.com  Tue Sep 17 02:37:19 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Sep 2013 12:37:19 +1000
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: 
References: 
Message-ID: <5237C05F.9050506@oracle.com>

Reviewed both hotspot and jdk changes.

Thumbs up and good riddance! :)

How do you propose to handle the coordination of the push?

Thanks,
David

On 17/09/2013 10:16 AM, Mike Duigou wrote:
> Hello all;
>
> This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor.
>
> Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/
>
> Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person).
>
> Mike
>


From mike.duigou at oracle.com  Tue Sep 17 03:24:03 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 16 Sep 2013 20:24:03 -0700
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: <5237C05F.9050506@oracle.com>
References: 
	<5237C05F.9050506@oracle.com>
Message-ID: <5E37DE88-F850-41BB-BDCF-0D24C4C33EFC@oracle.com>


On Sep 16 2013, at 19:37 , David Holmes wrote:

> Reviewed both hotspot and jdk changes.
> 
> Thumbs up and good riddance! :)
> 
> How do you propose to handle the coordination of the push?

The hotspot and jdk changes can go in any order. I plan to push them sequential after cross platform test build along with the closed source portion. The closed portion has to happen after the open jdk repo makefile changes.

Mike

> 
> Thanks,
> David
> 
> On 17/09/2013 10:16 AM, Mike Duigou wrote:
>> Hello all;
>> 
>> This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor.
>> 
>> Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/
>> 
>> Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person).
>> 
>> Mike
>> 



From paul.sandoz at oracle.com  Tue Sep 17 05:21:28 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Sep 2013 07:21:28 +0200
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <5237929F.7070200@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu> <52371E82.9080803@gmail.com>
	<52372625.7050106@oracle.com> <52373992.2030206@cs.oswego.edu>
	<656CE6B7-EA7D-4944-9B63-F5CA943B1B1A@oracle.com>
	<5237929F.7070200@cs.oswego.edu>
Message-ID: 

On Sep 17, 2013, at 1:22 AM, Doug Lea 
 wrote:
> On 09/16/2013 02:11 PM, Guy Steele wrote:
> 
>> Okay, as long as we're obsessing: the code defends against the hardware
>> address being longer than 8 bytes.
> 
> This was to protect ourselves from the impact of this code being used in some
> alternative universe in which hardware addresses are not always 48bits.
> But you are right that we could do a little better.
> 
>> So how about this code?
>> ...
>>                           h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
> 
> On first glance the sign extension of byte to long conversion
> makes this suspicious, but I see that it cannot hurt.
> So, sure; thanks.
> 
> Here's the full current version, including another minor tweak.
> (Paul: I'm committing to our CVS.)
> 

OK, i will sync this and SplittableRandom this week, and probably switch myself to a reviewer to speed this up.

Paul.

From paul.sandoz at oracle.com  Tue Sep 17 05:24:22 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Sep 2013 07:24:22 +0200
Subject: RFR: 8023339: (xs) Refine UOE conditions for removeIf()
In-Reply-To: 
References: 
	
	
Message-ID: <030B206A-BE28-4DD0-8080-904C97D10E49@oracle.com>


On Sep 16, 2013, at 9:49 PM, Mike Duigou  wrote:

> I think this is a reasonable compromise (and will be what I use for the other cases).
> 

OK, +1 from me.

Paul.

> Thanks!
> 
> Mike
> 
> On Sep 16 2013, at 01:13 , Paul Sandoz wrote:
> 
>> Hi Mike,
>> 
>> I suppose there could also be implementations of removeIf that always throw UOE regardless of whether an element matched or not i.e. those that override just to throw UOE.
>> 
>> So perhaps:
>> 
>> * @throws UnsupportedOperationException if elements cannot be removed 
>> *         from this collection.  Implementations may throw this exception if a
>> *         matching element cannot be removed or if, in general, removal is not 
>> *         supported.
>> 
>> Paul.


From Alan.Bateman at oracle.com  Tue Sep 17 07:01:41 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Sep 2013 08:01:41 +0100
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: 
References: 
Message-ID: <5237FE55.1070407@oracle.com>

On 17/09/2013 01:16, Mike Duigou wrote:
> Hello all;
>
> This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor.
>
> Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/
>
> Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person).
>
> Mike
Thank you Mike, looks like you've caught everything and it's great to 
finally get rid of this.

-Alan.


From erik.joelsson at oracle.com  Tue Sep 17 07:09:45 2013
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 17 Sep 2013 09:09:45 +0200
Subject: RFR(M): 8024265: Enable new build on AIX (jdk part)
In-Reply-To: 
References: 
Message-ID: <52380039.604@oracle.com>

Hello Volker,

This looks good to me. I think the mapfile situation could be solved 
better, but your solution is probably the simplest, at least if you 
anticipate using them in the future.

/Erik

On 2013-09-16 17:20, Volker Simonis wrote:
> Hi,
>
> could you please review the following webrev which contains the changes
> needed in the 'jdk' repository in order to build the OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/
>
> With this change and "8024854: Basic changes and files to build the class
> library on AIX "
> it will be possible to configure and completely build the staging
> repository on AIX 5.3 and 7.1 with the following command:
>
> configure --with-boot-jdk= --with-jvm-variants=core
> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
> --x-includes=/opt/freeware/include
>
> The webrev for 8024854 will follow within the next days...
>
> Below you can find the changes and additions I've done, sorted by file.
> Most of them are just additions which are only active during the AIX build
> anyway or simple changes where AIX has been added to conditions which
> already check for Linux and/or Solaris. Therefore, IMHO the impact on the
> existing platforms is really minimal.
>
> Thank you and best regards,
> Volker
>
> make/tools/sharing/classlist.aix
>
>     - Add AIX-specific class list.
>
> makefiles/CompileJavaClasses.gmk
>
>     - Add corresponding AIX-files to the list of exclude files for non-AIX
>     builds.
>
> makefiles/CompileLaunchers.gmk
>
>     - Statically link libjli on AIX because xlc on AIX doesn't support the
>     -rpath option.
>
> makefiles/CompileNativeLibraries.gmk
>
>     - Add required flags for AIX (i.e. by specifying CFLAGS_aix and
>     LDFLAGS_SUFFIX_aix).
>     - Add corresponding AIX-files to the LIBATTACH_EXCLUDE_FILES list of
>     exclude files for non-AIX builds.
>     - Specify BUILD_LIBNIO_FILES and BUILD_LIBNIO_MAPFILE for the AIX build.
>     - Statically link libjli on AIX becasue xlc on AIX doesn't support the
>     -rpath option.
>     - Specify -DX_PLATFORM=X_AIX in the LIBJSOUND_CFLAGS on AIX.
>
> makefiles/GendataFontConfig.gmk
>
>     - Specify AIX-specific fontconfig-settings.
>
> makefiles/GensrcX11Wrappers.gmk
>
>     - Use platform-independent $(COMPILER_TARGET_BITS_FLAG) variable
>     (introduced by change "8024265: Enable new build on AIX (top level
> part)")
> instead of hard-coded
>     -m option.
>
> makefiles/mapfiles/libattach/mapfile-aix,
> makefiles/mapfiles/libnio/mapfile-aix
>
>     - Add currently unused but required dummy mapfiles for AIX build.



From david.holmes at oracle.com  Tue Sep 17 07:21:01 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Sep 2013 17:21:01 +1000
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: <5237C05F.9050506@oracle.com>
References: 
	<5237C05F.9050506@oracle.com>
Message-ID: <523802DD.3020709@oracle.com>

Hi Mike,

Looks like there is one test that knows it has to exercise the 
alt-rt.jar version:

./java/util/TreeMap/Clone.java

  * @run main/othervm Clone
  * @run main/othervm -XX:+AggressiveOpts Clone

but it's harmless to leave the second invocation.

I didn't see anything in JDK or hotspot regression tests that would be 
impacted.

Once you are ready I will sponsor the hotspot patch for you through 
hotspot-rt.

Thanks,
David

On 17/09/2013 12:37 PM, David Holmes wrote:
> Reviewed both hotspot and jdk changes.
>
> Thumbs up and good riddance! :)
>
> How do you propose to handle the coordination of the push?
>
> Thanks,
> David
>
> On 17/09/2013 10:16 AM, Mike Duigou wrote:
>> Hello all;
>>
>> This is a cross-repo patch which disables building and enabling of the
>> alt-rt.jar file. The alt-rt.jar file has been used with the
>> -XX:+AggressiveOpts option (which will be remaining for other
>> optimizations). This jar file formerly contained (closed-source)
>> versions of several JDK classes which were optimized for very specific
>> workloads. The implementations weren't generally applicable and in
>> many cases induced performance drops. In particular since we will not
>> be providing optimized implementations of the Java 8 streams API for
>> the alternate versions of these classes the performance relative to
>> the standard implementations would be poor.
>>
>> Over time we've (largely Alan Bateman) been trying to eliminate this
>> difficult to support feature. With this changeset the alt-rt.jar
>> feature is retired.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/
>>
>> Ideally I would like a reviewer for both the HotSpot and JDK repos
>> (could be the same person).
>>
>> Mike
>>


From volker.simonis at gmail.com  Tue Sep 17 07:25:42 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 17 Sep 2013 09:25:42 +0200
Subject: RFR(M): 8024265: Enable new build on AIX (jdk part)
In-Reply-To: <523778EF.5040007@oracle.com>
References: 
	<523778EF.5040007@oracle.com>
Message-ID: 

On Mon, Sep 16, 2013 at 11:32 PM, Vladimir Kozlov
 wrote:
> Volker,
>
> You need different bug ID for these JDK changes.
> 8024265 (top level changes) is already fixed:
>
> https://bugs.openjdk.java.net/browse/JDK-8024265
>

Erik Joelsson told me that it is possible to use the same BugID for
related changes to different forests and it is the way we did it for
"8017568: Enable new build on Linux/PPC64":

http://hg.openjdk.java.net/ppc-aix-port/stage/rev/3ef3f4174c2b
http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/2465dffd6054

Actually, you pushed both of them:)

> I created new one for you:
>
> https://bugs.openjdk.java.net/browse/JDK-8024900
>

But it's no problem to use the new BugID. I'll take it for pushing.

Thanks for creating it,
Volker


> Thanks,
> Vladimir
>
>
> On 9/16/13 8:20 AM, Volker Simonis wrote:
>>
>>
>>         Hi,
>>
>> could you please review the following webrev which contains the changes
>> needed in the 'jdk' repository in order to build the OpenJDK on AIX:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/
>> 
>>
>>
>> With this change and "8024854: Basic changes and files to build the
>> class library on AIX
>> " it will be
>>
>> possible to configure and completely build the staging repository on AIX
>> 5.3 and 7.1 with the following command:
>>
>> configure --with-boot-jdk= --with-jvm-variants=core
>> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
>> --x-includes=/opt/freeware/include
>>
>> The webrev for 8024854 will follow within the next days...
>>
>> Below you can find the changes and additions I've done, sorted by file.
>> Most of them are just additions which are only active during the AIX
>> build anyway or simple changes where AIX has been added to conditions
>> which already check for Linux and/or Solaris. Therefore, IMHO the impact
>> on the existing platforms is really minimal.
>>
>> Thank you and best regards,
>>
>> Volker
>>
>>
>>         make/tools/sharing/classlist.aix
>>
>>   * Add AIX-specific class list.
>>
>>
>>         makefiles/CompileJavaClasses.gmk
>>
>>   * Add corresponding AIX-files to the list of exclude files for non-AIX
>>     builds.
>>
>>
>>         makefiles/CompileLaunchers.gmk
>>
>>   * Statically link |libjli| on AIX because |xlc| on AIX doesn't support
>>     the |-rpath| option.
>>
>>
>>         makefiles/CompileNativeLibraries.gmk
>>
>>   * Add required flags for AIX (i.e. by specifying |CFLAGS_aix| and
>>     |LDFLAGS_SUFFIX_aix|).
>>   * Add corresponding AIX-files to the |LIBATTACH_EXCLUDE_FILES| list of
>>
>>     exclude files for non-AIX builds.
>>   * Specify |BUILD_LIBNIO_FILES| and |BUILD_LIBNIO_MAPFILE| for the AIX
>>     build.
>>   * Statically link |libjli| on AIX becasue |xlc| on AIX doesn't support
>>     the |-rpath| option.
>>   * Specify |-DX_PLATFORM=X_AIX| in the |LIBJSOUND_CFLAGS| on AIX.
>>
>>
>>         makefiles/GendataFontConfig.gmk
>>
>>   * Specify AIX-specific fontconfig-settings.
>>
>>
>>         makefiles/GensrcX11Wrappers.gmk
>>
>>   * Use platform-independent |$(COMPILER_TARGET_BITS_FLAG)| variable
>>
>>     (introduced by change "8024265: Enable new build on AIX (top level
>>     part)"
>>      )
>>
>>     instead of hard-coded |-m| option.
>>
>>
>>         makefiles/mapfiles/libattach/mapfile-aix,
>>         makefiles/mapfiles/libnio/mapfile-aix
>>
>>   * Add currently unused but required dummy mapfiles for AIX build.
>>
>>
>


From peter.levart at gmail.com  Tue Sep 17 07:35:14 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Sep 2013 09:35:14 +0200
Subject: RFR: JDK-7123493 : (proxy) Proxy.getProxyClass doesn't scale
	under high load
In-Reply-To: <5234F21D.6040006@oracle.com>
References: <5234EF97.70806@oracle.com> <5234F21D.6040006@oracle.com>
Message-ID: <52380632.7090102@gmail.com>

Hi Rob,

I can confirm that this is a faithful backport of JDK8 fix. I'm glad 
that it could be made without too much hassle, since there were other 
changes to JDK8 Proxy code before that fix (some of them, I can see, 
have been backported already)...

Regards, Peter

On 09/15/2013 01:32 AM, Rob McKenna wrote:
> ...and the actual webrev:
>
> http://cr.openjdk.java.net/~robm/7123493/webrev.01/ 
> 
>
>     -Rob
>
> On 15/09/13 00:21, Rob McKenna wrote:
>> Hi folks,
>>
>> Looking to backport this fix to JDK7. The backport has resulted in 
>> relatively minor changes to the original fix such as replicating the 
>> BiFunction / Supplier interfaces in a limited sense as inner classes 
>> in WeakCache.
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123493
>> Original review thread: 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015854.html
>>
>>     -Rob
>>
>



From chris.hegarty at oracle.com  Tue Sep 17 08:36:55 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 17 Sep 2013 09:36:55 +0100
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: <5E37DE88-F850-41BB-BDCF-0D24C4C33EFC@oracle.com>
References: 
	<5237C05F.9050506@oracle.com>
	<5E37DE88-F850-41BB-BDCF-0D24C4C33EFC@oracle.com>
Message-ID: <523814A7.5080903@oracle.com>

The changes look fine to me too.

With such a trivial change to hotspot it may be possible to push this 
through TL?

Trivially, and separate to this change, I can see further cleanup 
opportunities [1], as well as some tests that ref alt-rt.jar [2] [3].

Not that I really care (but I know others do), will the old build still 
work after these changes?

-Chris.

[1] 
http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/1b7f5a27c4ba/src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java 
(L99)
[2] 
http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/1b7f5a27c4ba/test/tools/javac/processing/model/testgetallmembers/Main.java 
(L136)
[3] 
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/b67c8099ba28/test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java 
(L228)



On 09/17/2013 04:24 AM, Mike Duigou wrote:
>
> On Sep 16 2013, at 19:37 , David Holmes wrote:
>
>> Reviewed both hotspot and jdk changes.
>>
>> Thumbs up and good riddance! :)
>>
>> How do you propose to handle the coordination of the push?
>
> The hotspot and jdk changes can go in any order. I plan to push them sequential after cross platform test build along with the closed source portion. The closed portion has to happen after the open jdk repo makefile changes.
>
> Mike
>
>>
>> Thanks,
>> David
>>
>> On 17/09/2013 10:16 AM, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor.
>>>
>>> Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired.
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/
>>>
>>> Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person).
>>>
>>> Mike
>>>
>


From aleksey.shipilev at oracle.com  Tue Sep 17 08:43:04 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 17 Sep 2013 12:43:04 +0400
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: 
References: 
Message-ID: <52381618.6080709@oracle.com>

On 09/17/2013 04:16 AM, Mike Duigou wrote:
> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/

I, for one who is responsible for eliminating the need for alt-rt.jar,
greatly applaud this change.

-Aleksey.



From erik.helin at oracle.com  Tue Sep 17 08:48:28 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 17 Sep 2013 10:48:28 +0200
Subject: RFR: 8014659: NPG: performance counters for compressed klass space
In-Reply-To: 
References: <20130910155657.GA12910@ehelin-thinkpad>
	
Message-ID: <20130917084828.GA2261@ehelin-thinkpad>

Hi Staffan,

On 2013-09-12, Staffan Larsen wrote:
> Looks good (I'll take your word that the nasty awk scripts are correct...).

thanks for the review!

On 2013-09-12, Staffan Larsen wrote:
> I think you should have included serviceability-dev on this review request.

Agree, I'm adding them as part this email to let everyone at
serviceability-dev have a look.

Thanks,
Erik

> /Staffan
> 
> 
> On 10 sep 2013, at 18:56, Erik Helin  wrote:
> 
> > Hi all,
> > 
> > this is the JDK part of the fix for 8014659 [0]. I've added the output
> > of the compressed class space performance counters next to the metaspace
> > output. I've also updated the jstat and jstatd tests to take the new
> > output into account.
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> > 
> > Testing:
> > - jdk/test/sun/tools/jstat
> > - jdk/test/sun/tools/jstatd
> > 
> > Thanks,
> > Erik
> > 
> > [0]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
> 


From joel.franck at oracle.com  Tue Sep 17 09:53:24 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Tue, 17 Sep 2013 11:53:24 +0200
Subject: RFR: 8007072: Update Core Reflection for Type Annotations to match
	latest spec
Message-ID: <20130917095324.GD368@jfranck-desktop.jrpg.bea.com>

Hi,

Here is an update to the javadoc and implementation of reflection for
type annotations.

The biggest change is an update to the javadoc of Class and Executable
to match return types of the getGeneric* functions. That is, when
getGenericFoo returns an empty array getAnnotatedFoo should return an
empty array. Likewise for null.

Also the javadoc wording is updated to better match the style of
existing docs, for example type names in {@code }.

Change is actually quite small:

http://cr.openjdk.java.net/~jfranck/8007072/webrev.00/

Two of the three bugs fixed:

https://bugs.openjdk.java.net/browse/JDK-8007072
https://bugs.openjdk.java.net/browse/JDK-8024915

Please review.

cheers
/Joel


From Lance.Andersen at oracle.com  Tue Sep 17 10:55:48 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 17 Sep 2013 06:55:48 -0400
Subject: Fwd: review request 7097386: Correct error in Predicate javadoc
	example --- Still need an approval from a reviewer
References: <02298CEB-1AAE-4478-AB9C-E0018EB12100@oracle.com>
Message-ID: 

Hi Folks,

Aleksey has been kind enough to review this change.  Still need the blessing of a reviewer to put this back...

any takers :-)

Best
Lance

Begin forwarded message:

> From: Lance Andersen - Oracle 
> Date: September 16, 2013 7:12:09 AM EDT
> To: Aleksey Shipilev 
> Cc: core-libs-dev Core-Libs-Dev 
> Subject: Re: review request 7097386: Correct error in Predicate javadoc example
> 
> Thanks for the input.
> On Sep 16, 2013, at 4:58 AM, Aleksey Shipilev wrote:
> 
>> On 09/15/2013 10:38 PM, Lance Andersen - Oracle wrote:
>>> I added a webrev
>>> http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be
>>> a bit easier for this review.
>> 
>> Notes:
>> - change C-style "int v[]" declarations to Java-ish "int[] v".
> 
> I changed this.
>> - catching SQLException should probably return "false" right away?
> True, was a missing cut and paste from the code I copied
>> - "if" block can float up to the exception handler block, eliminating
>> the need for "int value = 0" line.
> 
> I left it as is as I try to keep the try/catch for SQLExceptions to just relevant code when applicable.
>> 
>> Otherwise, looks good (not a Reviewer).
>> 
> again, thank you for the feedback.
> 
> Changes are at http://cr.openjdk.java.net/~lancea/7097386/webrev.01/
> 
> Best
> Lance
>> Thanks,
>> -Aleksey,
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From Alan.Bateman at oracle.com  Tue Sep 17 11:14:59 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Sep 2013 12:14:59 +0100
Subject: Fwd: review request 7097386: Correct error in Predicate javadoc
	example --- Still need an approval from a reviewer
In-Reply-To: 
References: <02298CEB-1AAE-4478-AB9C-E0018EB12100@oracle.com>
	
Message-ID: <523839B3.5090306@oracle.com>

On 17/09/2013 11:55, Lance Andersen - Oracle wrote:
> Hi Folks,
>
> Aleksey has been kind enough to review this change.  Still need the blessing of a reviewer to put this back...
>
> any takers :-)
It looks okay although if is this is sample code that we expect 
developers to copy then we could do more, like taking a defensive copy 
of the array. If that is going further than you originally expected then 
you can ignore this suggestion.

-Alan.



From Lance.Andersen at oracle.com  Tue Sep 17 11:20:31 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 17 Sep 2013 07:20:31 -0400
Subject: review request 7097386: Correct error in Predicate javadoc
	example --- Still need an approval from a reviewer
In-Reply-To: <523839B3.5090306@oracle.com>
References: <02298CEB-1AAE-4478-AB9C-E0018EB12100@oracle.com>
	
	<523839B3.5090306@oracle.com>
Message-ID: <6D5E96E8-21BA-4F25-A6B2-71E85792D709@oracle.com>


On Sep 17, 2013, at 7:14 AM, Alan Bateman wrote:

> On 17/09/2013 11:55, Lance Andersen - Oracle wrote:
>> Hi Folks,
>> 
>> Aleksey has been kind enough to review this change.  Still need the blessing of a reviewer to put this back...
>> 
>> any takers :-)
> It looks okay although if is this is sample code that we expect developers to copy then we could do more, like taking a defensive copy of the array. If that is going further than you originally expected then you can ignore this suggestion.

No, the intent was just to be a trivial example not to deep dive into things such as defensive copying of the array.

The previous code from the original authors was not even functional :-(
> 
> -Alan.
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From aleksey.shipilev at oracle.com  Tue Sep 17 11:22:54 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 17 Sep 2013 15:22:54 +0400
Subject: RFR: Caching MethodType's descriptor string improves lambda
	linkage performance
In-Reply-To: <4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
Message-ID: <52383B8E.8040202@oracle.com>

On 09/17/2013 04:41 AM, John Rose wrote:
> But, please don't hand-inline methods (checkPtype, checkSlotCount).
> That is usually the wrong answer.  If there is a JIT inlining
> decision that isn't going right, we need to fix that, not distort the
> Java code.

I thought this issue is one of those rare instances, where we are
dealing with the interpreter performance. It is too early to invoke the
"Smart JIT Will Solve That For Us" argument :)

-Aleksey.


From aleksej.efimov at oracle.com  Tue Sep 17 12:01:33 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 17 Sep 2013 16:01:33 +0400
Subject: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH NODE
	LIST OF LENGTH =1 IN JAXP
Message-ID: <5238449D.50509@oracle.com>

Hi Everyone,

There is a bug [1] in JAXP about transformation of one-item sized node list:
When the length of nodelist which is passed to a XSLT extension function 
is 1, the node gotten from the node list becomes null.
New test illustrates this issue [2]. Full webrev with proposed fix can 
be found here: [3].

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707
[2] 
http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java
[3] http://cr.openjdk.java.net/~aefimov/8024707/

Best regards,
Aleksej


From volker.simonis at gmail.com  Tue Sep 17 12:43:49 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 17 Sep 2013 14:43:49 +0200
Subject: RFR(M): 8024265: Enable new build on AIX (jdk part)
In-Reply-To: <52380039.604@oracle.com>
References: 
	<52380039.604@oracle.com>
Message-ID: 

Hi Erik,

thank for the review!

On Tue, Sep 17, 2013 at 9:09 AM, Erik Joelsson  wrote:
> Hello Volker,
>
> This looks good to me. I think the mapfile situation could be solved better,
> but your solution is probably the simplest, at least if you anticipate using
> them in the future.

Yes, you're right. We still have to figure out the best way of
exporting/hiding symbols on AIX. But with the current solution at
least the build works without fine without big changes and we have
placeholders for AIX-specific export files if we should need them in
the future.

Is it OK if I push this change (with the new BugID
https://bugs.openjdk.java.net/browse/JDK-8024900 created by Vladimir)
to the stage repository? As far as I can see, there are no closed
dependencies in this case.

Thanks,
Volker

>
> /Erik
>
>
> On 2013-09-16 17:20, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please review the following webrev which contains the changes
>> needed in the 'jdk' repository in order to build the OpenJDK on AIX:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/
>>
>> With this change and "8024854: Basic changes and files to build the class
>> library on AIX
>> "
>>
>> it will be possible to configure and completely build the staging
>> repository on AIX 5.3 and 7.1 with the following command:
>>
>> configure --with-boot-jdk= --with-jvm-variants=core
>> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
>> --x-includes=/opt/freeware/include
>>
>> The webrev for 8024854 will follow within the next days...
>>
>> Below you can find the changes and additions I've done, sorted by file.
>> Most of them are just additions which are only active during the AIX build
>> anyway or simple changes where AIX has been added to conditions which
>> already check for Linux and/or Solaris. Therefore, IMHO the impact on the
>> existing platforms is really minimal.
>>
>> Thank you and best regards,
>> Volker
>>
>> make/tools/sharing/classlist.aix
>>
>>     - Add AIX-specific class list.
>>
>> makefiles/CompileJavaClasses.gmk
>>
>>     - Add corresponding AIX-files to the list of exclude files for non-AIX
>>     builds.
>>
>> makefiles/CompileLaunchers.gmk
>>
>>     - Statically link libjli on AIX because xlc on AIX doesn't support the
>>     -rpath option.
>>
>> makefiles/CompileNativeLibraries.gmk
>>
>>     - Add required flags for AIX (i.e. by specifying CFLAGS_aix and
>>     LDFLAGS_SUFFIX_aix).
>>     - Add corresponding AIX-files to the LIBATTACH_EXCLUDE_FILES list of
>>
>>     exclude files for non-AIX builds.
>>     - Specify BUILD_LIBNIO_FILES and BUILD_LIBNIO_MAPFILE for the AIX
>> build.
>>     - Statically link libjli on AIX becasue xlc on AIX doesn't support the
>>     -rpath option.
>>     - Specify -DX_PLATFORM=X_AIX in the LIBJSOUND_CFLAGS on AIX.
>>
>> makefiles/GendataFontConfig.gmk
>>
>>     - Specify AIX-specific fontconfig-settings.
>>
>> makefiles/GensrcX11Wrappers.gmk
>>
>>     - Use platform-independent $(COMPILER_TARGET_BITS_FLAG) variable
>>
>>     (introduced by change "8024265: Enable new build on AIX (top level
>> part)")
>>
>> instead of hard-coded
>>     -m option.
>>
>> makefiles/mapfiles/libattach/mapfile-aix,
>> makefiles/mapfiles/libnio/mapfile-aix
>>
>>     - Add currently unused but required dummy mapfiles for AIX build.
>
>


From lance.andersen at oracle.com  Tue Sep 17 11:57:15 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Tue, 17 Sep 2013 11:57:15 +0000
Subject: hg: jdk8/tl/jdk: 7097386: Correct error in Predicate javadoc example
Message-ID: <20130917115759.A0484628A9@hg.openjdk.java.net>

Changeset: 657482758408
Author:    lancea
Date:      2013-09-17 07:56 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/657482758408

7097386: Correct error in Predicate javadoc example
Reviewed-by: alanb, shade

! src/share/classes/javax/sql/rowset/Predicate.java



From ivan.gerasimov at oracle.com  Tue Sep 17 13:22:49 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 17 Sep 2013 17:22:49 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <52360F39.9080103@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com> <52355E90.7090501@oracle.com>
	<523594CA.4070104@oracle.com> <52360F39.9080103@oracle.com>
Message-ID: <523857A9.2070902@oracle.com>


Hi Alan!

On 15.09.2013 23:49, Alan Bateman wrote:
> On 15/09/2013 12:06, Ivan Gerasimov wrote:
>> :
>>
>> I decided to check whether this test really detects the failure, and 
>> run JPRT job with the new test but no fix included.
>> Unfortunately, the new test *does not* fail with unmodified jdk.
>> The same thing happens when the test is run with jtreg locally.
>> I believe it is so, because the tested program is run not directly 
>> from a console, and this is the condition for the bug to manifest itself.
>>
>> So I have to exclude the test, as it really doesn't check anything new.
>> I'm going to add noreg label and write an instruction to the QA about 
>> how to test the fix manually.
>>
>> What is good is that we don't need another shell-based test.
>>
>> Here's the new webrev: 
>> http://cr.openjdk.java.net/~igerasim/8023130/3/webrev/ 
>> 
>> Its only difference is that the shell script is excluded.
> JPRT may be using ssh but others will likely run the tests in other 
> configurations. If the shell test allows the scenario to be tested in 
> other configurations then it may be better to just include it in your 
> patch (in general we want to eliminate as many shell tests as possible 
> but a shell tests bets the cost of a manual test any day).

I totally agree with you that any automated test is better than any manual.
The problem is that I couldn't make the test fail no matter how I 
invoked it - from JPRT, from a locally running jtreg or even from plain 
cygwin.
The only way I could reproduce the problem with unpatched jdk was to run 
the test application directly from a Windows console.

Sincerely yours,
Ivan

>
> -Alan.



From kumar.x.srinivasan at oracle.com  Tue Sep 17 14:47:38 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 17 Sep 2013 07:47:38 -0700
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: 
References: 
Message-ID: <52386B8A.1050509@oracle.com>

+1, good riddance to this, which has caused other woes.

Thanks!!!!!
Kumar

> Hello all;
>
> This is a cross-repo patch which disables building and enabling of the alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts option (which will be remaining for other optimizations). This jar file formerly contained (closed-source) versions of several JDK classes which were optimized for very specific workloads. The implementations weren't generally applicable and in many cases induced performance drops. In particular since we will not be providing optimized implementations of the Java 8 streams API for the alternate versions of these classes the performance relative to the standard implementations would be poor.
>
> Over time we've (largely Alan Bateman) been trying to eliminate this difficult to support feature. With this changeset the alt-rt.jar feature is retired.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/
>
> Ideally I would like a reviewer for both the HotSpot and JDK repos (could be the same person).
>
> Mike



From mandy.chung at oracle.com  Tue Sep 17 14:55:55 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 17 Sep 2013 07:55:55 -0700
Subject: RFR: JDK-7123493 : (proxy) Proxy.getProxyClass doesn't scale
	under high load
In-Reply-To: <5234F21D.6040006@oracle.com>
References: <5234EF97.70806@oracle.com> <5234F21D.6040006@oracle.com>
Message-ID: <52386D7B.9070509@oracle.com>

Rob,

Thanks for backporting this fix.  Looks good to me.

Mandy

On 9/14/2013 4:32 PM, Rob McKenna wrote:
> ...and the actual webrev:
>
> http://cr.openjdk.java.net/~robm/7123493/webrev.01/ 
> 
>
>     -Rob
>
> On 15/09/13 00:21, Rob McKenna wrote:
>> Hi folks,
>>
>> Looking to backport this fix to JDK7. The backport has resulted in 
>> relatively minor changes to the original fix such as replicating the 
>> BiFunction / Supplier interfaces in a limited sense as inner classes 
>> in WeakCache.
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123493
>> Original review thread: 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015854.html
>>
>>     -Rob
>>
>



From mike.duigou at oracle.com  Tue Sep 17 16:34:06 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 17 Sep 2013 09:34:06 -0700
Subject: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"
In-Reply-To: <523802DD.3020709@oracle.com>
References: 
	<5237C05F.9050506@oracle.com> <523802DD.3020709@oracle.com>
Message-ID: <4ABE2E27-FDFA-4309-9CD5-940D41F7AD28@oracle.com>


On Sep 17 2013, at 00:21 , David Holmes wrote:

> Hi Mike,
> 
> Looks like there is one test that knows it has to exercise the alt-rt.jar version:
> 
> ./java/util/TreeMap/Clone.java
> 
> * @run main/othervm Clone
> * @run main/othervm -XX:+AggressiveOpts Clone
> 
> but it's harmless to leave the second invocation.

I will remove it.

Since the +AggressiveOpts option remains it is still valid. A better general solution (that I hope someone is running) is to run the entire jtreg suite with +AggressiveOpts as an extra JDK option. 

> I didn't see anything in JDK or hotspot regression tests that would be impacted.
> 
> Once you are ready I will sponsor the hotspot patch for you through hotspot-rt.

Thank you.

Mike

> 
> Thanks,
> David
> 
> On 17/09/2013 12:37 PM, David Holmes wrote:
>> Reviewed both hotspot and jdk changes.
>> 
>> Thumbs up and good riddance! :)
>> 
>> How do you propose to handle the coordination of the push?
>> 
>> Thanks,
>> David
>> 
>> On 17/09/2013 10:16 AM, Mike Duigou wrote:
>>> Hello all;
>>> 
>>> This is a cross-repo patch which disables building and enabling of the
>>> alt-rt.jar file. The alt-rt.jar file has been used with the
>>> -XX:+AggressiveOpts option (which will be remaining for other
>>> optimizations). This jar file formerly contained (closed-source)
>>> versions of several JDK classes which were optimized for very specific
>>> workloads. The implementations weren't generally applicable and in
>>> many cases induced performance drops. In particular since we will not
>>> be providing optimized implementations of the Java 8 streams API for
>>> the alternate versions of these classes the performance relative to
>>> the standard implementations would be poor.
>>> 
>>> Over time we've (largely Alan Bateman) been trying to eliminate this
>>> difficult to support feature. With this changeset the alt-rt.jar
>>> feature is retired.
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/
>>> 
>>> Ideally I would like a reviewer for both the HotSpot and JDK repos
>>> (could be the same person).
>>> 
>>> Mike
>>> 



From sean.coffey at oracle.com  Tue Sep 17 16:41:13 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 17 Sep 2013 17:41:13 +0100
Subject: RFR: 8016271: wsimport -clientjar does not create portable jar
	on windows due to hardcoded '\'
In-Reply-To: <5225DBB2.6090503@oracle.com>
References: <5225B0C0.1020301@oracle.com> <5225B403.3010801@oracle.com>
	<5225B5C2.1000704@oracle.com> <5225B769.1020302@oracle.com>
	<5225D6D8.1020706@oracle.com> <5225DBB2.6090503@oracle.com>
Message-ID: <52388629.1050607@oracle.com>

Miran,

are you on schedule to push this fix into jdk8/tl ? I'd like to get it 
ported to jdk7u also. If no push is pending for jdk8 from jaxws group, I 
might go ahead and push the fix to jdk. We have a testcase in different 
repo to catch any sync issues if necessary.

regards,
Sean.

On 03/09/2013 13:53, Se?n Coffey wrote:
> First option sounds good to me too Miran. Sounds like we can expect 
> this fix to be sync'ed into JDK8 from JAXWS team over next week or two 
> then. Hopefully you can do the same for jdk7u-dev.
>
> regards,
> Sean.
>
> On 03/09/2013 13:32, Miroslav Kos wrote:
>> Hi Sean,
>> up to now, integrations JAX-WS > JDK haven't been done on regular 
>> basis, just when bug fixes were required, for current JDK development 
>> version it was time to time - 2x or 3x during a year (?) ...
>>
>> For future, we would like make it on regular basis for development 
>> version JAX-WS trunk/Jdk8 - let's say once or twice (?) a month, for 
>> other jdk version it would be same as now, only up on request ...
>>
>> How to proceed with this issue depends on how critical is it - we can 
>> integrate that first on our side and later (one week delay) deliver 
>> jdk patch or, if it is something critical, we can push it 
>> simultaneously into both codebasis. We definitely prefer the first 
>> option.
>>
>> Miran
>>
>>
>> On 09/03/2013 12:18 PM, Se?n Coffey wrote:
>>> Miran,
>>>
>>> can you clarify how we get this fix in then. Will you patch into 
>>> JAX-WS and port to the jdk/jaxws repo or do can we push it to both 
>>> repos independently? How often does JAX-WS team sync with openJDK ?
>>>
>>> I need to get this ported to jdk7u also.
>>>
>>> regards,
>>> Sean.
>>>
>>> On 03/09/2013 11:11, Miroslav Kos wrote:
>>>> Hi Alan,
>>>> good catch! Yes, we need to apply the fix on our side too, 
>>>> otherwise it would be reverted with a new integration JAX-WS > JDK.
>>>>
>>>> Miran
>>>>
>>>>
>>>>
>>>> On 09/03/2013 12:03 PM, Alan Bateman wrote:
>>>>> On 03/09/2013 10:49, Se?n Coffey wrote:
>>>>>> Bug report not public at moment. (should appear shortly)
>>>>>>
>>>>>> Issue with wsimport tool. Use of jar files created from wsimport 
>>>>>> on windows don't work on unix systems. Portability issue.
>>>>>> Simple fix. wsimport testcase to accompany it.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8016271/
>>>>> Does this need to go into an upstream project first?  As I 
>>>>> understand it, the JAX-WS folks have an industrial blender to mix 
>>>>> the ingredients for the jaxws repository. At one point then I 
>>>>> think there were about 10 upstream projects to pull code from. 
>>>>> Maybe things have changed but I just wonder if changes/patches 
>>>>> pushed to the jaxws repository will be wiped by a re-sync from 
>>>>> upstream. I've cc'ed martin Grebac and Miroslav Kos to comment.
>>>>>
>>>>> -Alan.
>>>>
>>>
>>
>



From cowwoc at bbs.darktech.org  Tue Sep 17 17:32:18 2013
From: cowwoc at bbs.darktech.org (cowwoc)
Date: Tue, 17 Sep 2013 13:32:18 -0400
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
Message-ID: <52389222.4090300@bbs.darktech.org>

Hi,

     Has this been any new progress on this thread? 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480

     I'd like to second J?rn concerns that shipping JDK8 (less than a 
month to go!) without a fix would be extremely problematic. The 
performance impact would be huge and the difficulty of introducing a 
change would be far more difficult than doing it before JDK8 is out.

     How do we go about moving this forward?

Thanks,
Gili


From sergey.kuksenko at oracle.com  Tue Sep 17 18:19:00 2013
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Tue, 17 Sep 2013 22:19:00 +0400
Subject: RFR: Caching MethodType's descriptor string improves lambda
	linkage performance
In-Reply-To: <4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
Message-ID: <52389D14.2080606@oracle.com>

On 09/17/2013 04:41 AM, John Rose wrote:
> The algorithmic change (string cache) is acceptable, although it will tend to increase footprint somewhat.  
I don't think that it would be visible footprint increasing. MethodTypes
are interned by implementation, so I don't expect that this "overhead"
will be significant.

> We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well. 
In case of small amount of such strings we will get a huge overhead from
any kind of map. From performance point of view map may acceptable when
we have a lot of such strings. The key fact here that we have a few
amount of MethodTypes, but calls "toMethodDescriptorString@ very frequent.

> 
> But, please don't hand-inline methods (checkPtype, checkSlotCount).  That is usually the wrong answer.  
> If there is a JIT inlining decision that isn't going right, we need to fix that, not distort the Java code.
Unfortunately it is not a case when we may rely on JIT. Certainly, there
are no perf problems here (except caching) after JIT (at least C2, I did
n't check C1). But we have huge performance problems/impact here while
interpreting. I know (I think) a really general solution for such perf
problems. Besides it will be useful in a big amount of other places.  It
is a bytecode level inline before interpretation.

Let's back to the patch.

checkPType is method which performs two _different_ actions. The first
is check that type in not null and type is not void. The second action
is calculate size of extra parameter slot (lond/double types). So we
came to idea that we need two different methods as from performance and
OOP purity points of view. checkPType has exactly two usages. And the
second usage don't need calculate size of parameters slots. So one
action used only in the single place and we get more readable code if we
inline it. The second action used twice, but it a very simple action
(NPE and void check) and I think here we may do manual inline because of
it is give us visible benefits and don't create any problems as for
later JITing and code reading.

> Also, I think you deleted a call to checkSlotCount that should still be there to detect illegal inputs.  One of the costs of hand-inlining is bitrot like that.
Oops.
You are right. I did a mistake. I eliminate one checkSlotCount usage by
error, but I didn't inline anything in that place. So it is not a cost
of hand-inlining, it is a cost of my inadvertence when I eliminame a
whole code line by misclick and didn't noticed that.


Tomorrow I'll do other webrev -  will try to pay attention to all
comments and we may continue the discussion.


> 
> ? John
> 
> On Sep 11, 2013, at 12:03 PM, Sergey Kuksenko  wrote:
> 
>> On 09/11/2013 09:01 PM, Aleksey Shipilev wrote:
>>> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/
>>>
>>> As much as I hate to see the hand code tweaking instead of relying on
>>> compiler to do it's job, I understand this is about interpreter. Seems
>>> good then.
>>>
>>> * Formatting: "if(...)" should be "if (...")
>> Will do
>>>
>>> * Formatting: "//NPE" should be "// null check"
>> I just preserve exiting comments.
>> Decided don't modify original code which is not important to required
>> functionality.
>>
>>>
>>> * Formatting: "desc =  " should be "desc = "
>>>
>>> * Formatting: this one should not use braces (for consistency with other
>>> usages)?
>>> 364         if(nptype == null) { //NPE
>>> 365             throw new NullPointerException();
>>> 366         }
>> Let ask code owner.
>>>
>>> * Explicit null-checks: implicits via .getClass and .equals always
>>> bothered me in j.l.i.*; the idea was seemingly to piggyback on the
>>> compiler intrinsics. 
>> anyway it is doesn't matter after C1/C2
>>
>>> Any idea what's the cost of using
>>> Objects.requireNonNull there?
>> If we are running under the interpreter Objects.requireNonNull costs
>> enough to eliminate benefits from this fine tuning.
>>
>> -- 
>> Best regards,
>> Sergey Kuksenko
> 


-- 
Best regards,
Sergey Kuksenko


From nick at transparentech.com  Thu Sep 12 20:41:23 2013
From: nick at transparentech.com (Nicholas Rahn)
Date: Thu, 12 Sep 2013 22:41:23 +0200
Subject: RFR 7199674: (props) user.home property does not return an
	accessible location in sandboxed environment [macosx]
In-Reply-To: <05F4A4A9-E77B-4D26-961F-BB972F44E95C@oracle.com>
References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com>
	
	<5229DAE7.80307@oracle.com>
	
	
	
	<6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com>
	
	
	<522FB8E6.4020209@oracle.com>
	
	
	
	<5230E995.3090609@oracle.com>
	<05F4A4A9-E77B-4D26-961F-BB972F44E95C@oracle.com>
Message-ID: 

Ok, I've tried this out with my app in the sandbox. I can confirm that
opening a file dialog (NSSavePanel underneath), with a directory pointing
to the Container's Documents directory
(/Users/nick/Library/Containers/my.app/Data/Documents), will show the
standard Mac file selection dialog with the standard ~/Documents directory
selected. If you then select a file there, say 'selected-file.txt', click
OK, the dialog will return the path ~/Documents/selected-file.txt.  Since I
have the com.apple.security.files.user-selected.read-write entitlement in
my application, I can subsequently write to this path, and the file is
written in ~/Documents/selected-file.txt, not in the Container's Documents
directory.

So this clears up my questions about this patch. Thanks for helping me
through it.

Cheers,
Nick



On Thu, Sep 12, 2013 at 12:11 AM, David DeHaven wrote:

>
> >>> The bottom line is, if what you have now allows you to write to
> >>> ~/Documents and you're sandboxed then this change should not
> >>> affect your application at all, except maybe in the UI if you're
> >>> displaying that path to the user. The user won't notice the
> >>> difference otherwise.
> >>
> >> My users *will* notice because I display this path in the export dialog,
> >> along with the other export options they can use.
> >
> > If the path displayed is coming from the selected file, then it will
> continue to show the correct path.
>
> I don't think I was clear on that comment... if you're building the path
> from say System.getProperty("user.home") + "/Documents/blah" and showing it
> to the user, then that's a problem. If you're showing paths returned by the
> open/save panels then you're fine, the user will never see the container
> path.
>
> -DrD-
>
>


From andrey.x.nazarov at oracle.com  Thu Sep 12 23:13:37 2013
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Fri, 13 Sep 2013 03:13:37 +0400
Subject: Review: lamda expressions and bulk data operations on collections.
Message-ID: <52324AA1.1040206@oracle.com>

Hi guys,

We want to push our demo code for try-with-resources feature
Could you please review this code?
http://cr.openjdk.java.net/~anazarov/try-with-resources/


--Andrey.



From andrey.x.nazarov at oracle.com  Fri Sep 13 01:49:03 2013
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Fri, 13 Sep 2013 05:49:03 +0400
Subject: Review: demos for try-with-resources feature
Message-ID: <52326F0F.9010707@oracle.com>

I've fixed subject
---
Hi guys,

We want to push our demo code for try-with-resources feature
Could you please review this code?
http://cr.openjdk.java.net/~anazarov/try-with-resources/


--Andrey.



From brian.burkhalter at oracle.com  Tue Sep 17 20:49:01 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Sep 2013 13:49:01 -0700
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is
	null and the key is absent
Message-ID: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>

Please review this proposed patch at your convenience.

Summary:	Explicitly check for null remappingFunction parameter (and clean up similar code for consistency).
Issue:		http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024331
Webrev:		http://cr.openjdk.java.net/~bpb/8024331/

Thanks,

Brian

From mandy.chung at oracle.com  Tue Sep 17 20:53:51 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 17 Sep 2013 13:53:51 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <52389222.4090300@bbs.darktech.org>
References: <52389222.4090300@bbs.darktech.org>
Message-ID: <5238C15F.4080408@oracle.com>

On 9/17/13 10:32 AM, cowwoc wrote:
> Hi,
>
>     Has this been any new progress on this thread? 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480
>

I have sent my feedback a couple weeks ago on this proposed patch but 
haven't heard back from Nick.

You asked at a good time.  I discussed this with John Rose last couple 
days on this topic.  He has been thinking about how to do 
fillInStackTrace performantly and walk the stack with laziness and frame 
filtering.  The current implementation fills the entire stack trace 
while Groovy and Log4j use case filters the frames of some specific 
classes until it reaches the first one not being filtered.

He suggests to consider an API taking a callback shape (e.g. Function, 
Consumer, etc) that Remi Forax suggested at one time that allows the JVM 
to do something.   I will work with John to work out the details and 
determine the interface between VM and library and hash out issues.

I like the callback shape idea and hope to work out a proposal soon.

> I'd like to second J?rn concerns that shipping JDK8 (less than a month 
> to go!) without a fix would be extremely problematic. The performance 
> impact would be huge and the difficulty of introducing a change would 
> be far more difficult than doing it before JDK8 is out.
>
>     How do we go about moving this forward?
>

This RFE is target for JDK 8 and my priority to get that in.  I'm well 
aware the impact to Groovy and Log4j and some other existing 
applications that are seeking for a replacement of 
Reflection.getCallerClass.

Mandy





From john.r.rose at oracle.com  Tue Sep 17 20:59:59 2013
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 17 Sep 2013 13:59:59 -0700
Subject: RFR: Caching MethodType's descriptor string improves lambda
	linkage performance
In-Reply-To: <52389D14.2080606@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
	<52389D14.2080606@oracle.com>
Message-ID: 

On Sep 17, 2013, at 11:19 AM, Sergey Kuksenko  wrote:

> On 09/17/2013 04:41 AM, John Rose wrote:
>> The algorithmic change (string cache) is acceptable, although it will tend to increase footprint somewhat.  
> I don't think that it would be visible footprint increasing. MethodTypes
> are interned by implementation, so I don't expect that this "overhead"
> will be significant.

That's reasonable for now.  You should know that the 292 API does not mandate MethodType interning, and that future versions could possibly drop it.  But if we did we'd take all current caches, including this one, into consideration.

One problem with MT interning is that a lookup of a virtual method in a small class C has to create a direct MH whose type mentions C as a leading parameter type.  In many use cases, this type then gets dropped in favor of superclass, such as Object.  The MT then goes dead almost as soon as it was created.

>> We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well. 
> In case of small amount of such strings we will get a huge overhead from
> any kind of map.

I would expect O(10^1.5) memory references and branches.  Depends on what you mean by "huge".

> From performance point of view map may acceptable when
> we have a lot of such strings. The key fact here that we have a few
> amount of MethodTypes, but calls "toMethodDescriptorString@ very frequent.

Would there be any benefit from recording the original string from the constant pool?  The JVM path for this is SystemDictionary::find_method_handle_type, which makes an upcall to MethodHandleNatives.findMethodHandleType.  Currently only the ptypes and rtype are passed, but the JVM could also convert the internal Symbol to a java.lang.String and pass that also.  In that case, MT's created by JVM upcalls would be pre-equipped with descriptor strings.

This is probably worth an experiment, although it requires some JVM work.

>> But, please don't hand-inline methods (checkPtype, checkSlotCount).  That is usually the wrong answer.  
>> If there is a JIT inlining decision that isn't going right, we need to fix that, not distort the Java code.
> Unfortunately it is not a case when we may rely on JIT. Certainly, there
> are no perf problems here (except caching) after JIT (at least C2, I did
> n't check C1). But we have huge performance problems/impact here while
> interpreting. I know (I think) a really general solution for such perf
> problems. Besides it will be useful in a big amount of other places.  It
> is a bytecode level inline before interpretation.

As long as such transforms are online, it is better to run it through C1, which is about as fast as a bytecode transform and produces more a favorable end result.  To make that happen, consider pre-marking some methods with inflated invocation counts, so that they are queued for C1 compilation as soon as they start getting used.

Although that would be an unorthodox tactic for hotspot, it is an easier change to make, for similar performance gains, to any upstream code transformation.  (Eventually we'll figure out AOT, and then all this stuff will be moot.)

> Let's back to the patch.
> 
> checkPType is method which performs two _different_ actions. The first
> is check that type in not null and type is not void. The second action
> is calculate size of extra parameter slot (lond/double types).

You got me there.  As a compiler guy I pushed the second computation into the subroutine because I knew it would go dead if the value was unused.  I see that it bumps up the bootstrap cost for no benefit.

> So we
> came to idea that we need two different methods as from performance and
> OOP purity points of view. checkPType has exactly two usages. And the
> second usage don't need calculate size of parameters slots. So one
> action used only in the single place and we get more readable code if we
> inline it. The second action used twice, but it a very simple action
> (NPE and void check) and I think here we may do manual inline because of
> it is give us visible benefits and don't create any problems as for
> later JITing and code reading.

Rather than hand-inlining, then, please split checkPtype into checkPtype and ptypeSlotCount.  Leave checkPtypes alone, since it is probably marginally helpful to do both jobs in one pass over the data.

>> Also, I think you deleted a call to checkSlotCount that should still be there to detect illegal inputs.  One of the costs of hand-inlining is bitrot like that.
> Oops.
> You are right. I did a mistake.

I hope you get my overall point:  Hand optimizations have a continuing cost, related to obscuring the logical structure of the code.  The transforming engineer might make a mistake, and later maintaining engineers might also make mistakes.

https://blogs.oracle.com/jrose/entry/three_software_proverbs

> I eliminate one checkSlotCount usage by
> error, but I didn't inline anything in that place. So it is not a cost
> of hand-inlining, it is a cost of my inadvertence when I eliminame a
> whole code line by misclick and didn't noticed that.
> 
> 
> Tomorrow I'll do other webrev -  will try to pay attention to all
> comments and we may continue the discussion.

Good.

? John


> 
>> 
>> ? John
>> 
>> On Sep 11, 2013, at 12:03 PM, Sergey Kuksenko  wrote:
>> 
>>> On 09/11/2013 09:01 PM, Aleksey Shipilev wrote:
>>>> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>>>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/
>>>> 
>>>> As much as I hate to see the hand code tweaking instead of relying on
>>>> compiler to do it's job, I understand this is about interpreter. Seems
>>>> good then.
>>>> 
>>>> * Formatting: "if(...)" should be "if (...")
>>> Will do
>>>> 
>>>> * Formatting: "//NPE" should be "// null check"
>>> I just preserve exiting comments.
>>> Decided don't modify original code which is not important to required
>>> functionality.
>>> 
>>>> 
>>>> * Formatting: "desc =  " should be "desc = "
>>>> 
>>>> * Formatting: this one should not use braces (for consistency with other
>>>> usages)?
>>>> 364         if(nptype == null) { //NPE
>>>> 365             throw new NullPointerException();
>>>> 366         }
>>> Let ask code owner.
>>>> 
>>>> * Explicit null-checks: implicits via .getClass and .equals always
>>>> bothered me in j.l.i.*; the idea was seemingly to piggyback on the
>>>> compiler intrinsics. 
>>> anyway it is doesn't matter after C1/C2
>>> 
>>>> Any idea what's the cost of using
>>>> Objects.requireNonNull there?
>>> If we are running under the interpreter Objects.requireNonNull costs
>>> enough to eliminate benefits from this fine tuning.
>>> 
>>> -- 
>>> Best regards,
>>> Sergey Kuksenko
>> 
> 
> 
> -- 
> Best regards,
> Sergey Kuksenko



From jonathan.gibbons at oracle.com  Tue Sep 17 21:17:25 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 17 Sep 2013 21:17:25 +0000
Subject: hg: jdk8/tl/langtools: 8024538: -Xdoclint + -Xprefer:source +
	incremental compilation == FAIL
Message-ID: <20130917211728.84334628CD@hg.openjdk.java.net>

Changeset: fdfbc5f0c4ed
Author:    jjg
Date:      2013-09-17 14:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fdfbc5f0c4ed

8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
+ test/tools/javac/doclint/implicitSource/ImplicitSourceTest.java
+ test/tools/javac/doclint/implicitSource/Other.java



From mike.duigou at oracle.com  Tue Sep 17 21:33:44 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 17 Sep 2013 14:33:44 -0700
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is
	null and the key is absent
In-Reply-To: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
Message-ID: <574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>

The Map/Defaults.java changes only test HashMap. It should probably be extended to test most/all of the other implementations.

I have some worry that the superfluous assignment of the Objects.requireNonNull() result might have a non-negligible cost. 

Mike

On Sep 17 2013, at 13:49 , Brian Burkhalter wrote:

> Please review this proposed patch at your convenience.
> 
> Summary:	Explicitly check for null remappingFunction parameter (and clean up similar code for consistency).
> Issue:		http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024331
> Webrev:		http://cr.openjdk.java.net/~bpb/8024331/
> 
> Thanks,
> 
> Brian



From xueming.shen at oracle.com  Tue Sep 17 21:55:00 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 17 Sep 2013 14:55:00 -0700
Subject: RFR:  8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
Message-ID: <5238CFB4.1040304@oracle.com>

Hi,

Please help the small update to the test case tools/jar/ChangeDir.java,
which might fail if the "dedicated" test directory /tmp/a exists and the
user does not have privilege to delete/clean it up.

The proposed change here is to use a random file name (from File.getTempFile())
for the top test directory (instead of the fixed /tmp/a), and really clean it up
after testing (the old test leaves /tmp/a and those temp files undeleted).

http://cr.openjdk.java.net/~sherman/8023113/webrev

Thanks,
-Sherman




From forax at univ-mlv.fr  Tue Sep 17 22:00:14 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 18 Sep 2013 00:00:14 +0200
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is null and
	the key is absent
In-Reply-To: <574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
	<574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
Message-ID: <5238D0EE.9010405@univ-mlv.fr>

On 09/17/2013 11:33 PM, Mike Duigou wrote:
> The Map/Defaults.java changes only test HashMap. It should probably be extended to test most/all of the other implementations.
>
> I have some worry that the superfluous assignment of the Objects.requireNonNull() result might have a non-negligible cost.

apart from
   foo(Object.requireNonNull(var))
or
   this.var = Objects.requireNonNull(var) in a constructor,

I think that
   Object.requireNonNull(var);
is more readable than
   var = Object.requireNonNull(var);

Also for HashMap, I think it's better to not use Object.requireNonNull
as the current code does otherwise we need to re-run all perf benchs we 
have.

>
> Mike

R?mi

>
> On Sep 17 2013, at 13:49 , Brian Burkhalter wrote:
>
>> Please review this proposed patch at your convenience.
>>
>> Summary:	Explicitly check for null remappingFunction parameter (and clean up similar code for consistency).
>> Issue:		http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024331
>> Webrev:		http://cr.openjdk.java.net/~bpb/8024331/
>>
>> Thanks,
>>
>> Brian



From mike.duigou at oracle.com  Tue Sep 17 22:35:49 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 17 Sep 2013 15:35:49 -0700
Subject: RFR: 8023339 & 8023340 : (xs) Refine throws UOE/NPE Conditions
Message-ID: <42F9A023-664B-4AEF-B071-D7315F28400C@oracle.com>

Hello all;

Another, hopefully final, attempt at refining the @throws UOE javadoc for Collections.removeIf and the @throws UOE and NPE javadoc for List.replaceAll().

This cycle adopts the verbiage suggested by Paul Sandoz in the last round of 8023339.

Both changesets are combined into a single webrev:

http://cr.openjdk.java.net/~mduigou/JDK-8023340/1/webrev/

Thanks,

Mike

From brian.burkhalter at oracle.com  Tue Sep 17 23:25:52 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Sep 2013 16:25:52 -0700
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is
	null and the key is absent
In-Reply-To: <5238D0EE.9010405@univ-mlv.fr>
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
	<574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
	<5238D0EE.9010405@univ-mlv.fr>
Message-ID: <2F73A892-1A0E-4097-BF49-81165ADE60BA@oracle.com>

On Sep 17, 2013, at 3:00 PM, Remi Forax wrote:

> apart from
>  foo(Object.requireNonNull(var))
> or
>  this.var = Objects.requireNonNull(var) in a constructor,
> 
> I think that
>  Object.requireNonNull(var);
> is more readable than
>  var = Object.requireNonNull(var);

I don't feel strongly about it: it's mostly about not ignoring the return value. I don't think it's that important in this case.

> Also for HashMap, I think it's better to not use Object.requireNonNull
> as the current code does otherwise we need to re-run all perf benchs we have.

Likewise, I don't have any objection to not replacing equivalent code which is known to work.

I'll update the patch and repost.

Thanks,

Brian

From brian.burkhalter at Oracle.COM  Tue Sep 17 23:27:09 2013
From: brian.burkhalter at Oracle.COM (Brian Burkhalter)
Date: Tue, 17 Sep 2013 16:27:09 -0700
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is
	null and the key is absent
In-Reply-To: <574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
	<574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
Message-ID: <1DA14A6A-CD1E-4FC1-BC0A-235F3F623BE7@Oracle.COM>


On Sep 17, 2013, at 2:33 PM, Mike Duigou wrote:

> The Map/Defaults.java changes only test HashMap. It should probably be extended to test most/all of the other implementations.

OK I will add those.

> I have some worry that the superfluous assignment of the Objects.requireNonNull() result might have a non-negligible cost. 

As I responded to Remi, I don't feel strongly about this.

I'll make the various updates and repost.

Thanks,

Brian

From brian.burkhalter at oracle.com  Wed Sep 18 00:08:31 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Sep 2013 17:08:31 -0700
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is
	null and the key is absent
In-Reply-To: <1DA14A6A-CD1E-4FC1-BC0A-235F3F623BE7@Oracle.COM>
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
	<574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
	<1DA14A6A-CD1E-4FC1-BC0A-235F3F623BE7@Oracle.COM>
Message-ID: <7E8EB639-9908-4658-96EF-FB414EDF445D@oracle.com>

The proposed patch has been updated at the same location:

http://cr.openjdk.java.net/~bpb/8024331/.

Thanks,

Brian

On Sep 17, 2013, at 4:27 PM, Brian Burkhalter wrote:

> I'll make the various updates and repost.



From forax at univ-mlv.fr  Wed Sep 18 01:03:39 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 18 Sep 2013 03:03:39 +0200
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is null and
	the key is absent
In-Reply-To: <7E8EB639-9908-4658-96EF-FB414EDF445D@oracle.com>
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
	<574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
	<1DA14A6A-CD1E-4FC1-BC0A-235F3F623BE7@Oracle.COM>
	<7E8EB639-9908-4658-96EF-FB414EDF445D@oracle.com>
Message-ID: <5238FBEB.4030907@univ-mlv.fr>

On 09/18/2013 02:08 AM, Brian Burkhalter wrote:
> The proposed patch has been updated at the same location:
>
> http://cr.openjdk.java.net/~bpb/8024331/.
>
> Thanks,
>
> Brian

looks good.

R?mi

>
> On Sep 17, 2013, at 4:27 PM, Brian Burkhalter wrote:
>
>> I'll make the various updates and repost.



From henry.jen at oracle.com  Wed Sep 18 06:18:55 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 17 Sep 2013 23:18:55 -0700
Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log lambda
	code generation
Message-ID: <523945CF.9060804@oracle.com>

Hi,

Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8023524/0/webrev/

This webrev enable writing generated classes for lambda to disk at a
directory specified with -Djdk.internal.lambda.dumpProxyClasses.

The directory has to be an existing writable directory, otherwise, a
message will be logged. The validation is done in static block to fail
early, and is done each time when lambda capture occurs in case file
system is modified(for example, created after seeing error message).

As the code using AccessController.doPrivileged to perform file I/O, it
would be much appreciated to have extra eyes from security experts to
have a look at this.

As the directory specified should be existing writable directory, and
the generated filename is lambda class name controlled by the program,
there should be no security concerns.

Cheers,
Henry


From shanliang.jiang at oracle.com  Wed Sep 18 06:52:08 2013
From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com)
Date: Wed, 18 Sep 2013 06:52:08 +0000
Subject: hg: jdk8/tl/jdk: 8023954: MBean*Info.equals: throw NPE
Message-ID: <20130918065258.B1348628EC@hg.openjdk.java.net>

Changeset: 8708569b5524
Author:    sjiang
Date:      2013-09-18 08:51 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8708569b5524

8023954: MBean*Info.equals: throw NPE
Reviewed-by: dfuchs, dholmes

! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanFeatureInfo.java
! src/share/classes/javax/management/MBeanNotificationInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
! src/share/classes/javax/management/MBeanParameterInfo.java
+ test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java



From joel.franck at oracle.com  Wed Sep 18 09:28:18 2013
From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=)
Date: Wed, 18 Sep 2013 11:28:18 +0200
Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters
	synchronized method
In-Reply-To: <5235CE65.9040005@gmail.com>
References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com>
	<520777E5.3050304@gmail.com>
	<20130812105439.GC6420@jfranck-desktop.jrpg.bea.com>
	<5208D7A7.9070608@gmail.com>
	<5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com>
	<521CA2F0.1020701@gmail.com>
	<2A6CD10E-FA3B-4BC9-AD22-AAA79C866731@oracle.com>
	<522DFE08.5060604@gmail.com> <5235CE65.9040005@gmail.com>
Message-ID: <20130918092818.GD5572@jfranck-desktop.jrpg.bea.com>

Looks good Peter,

cheers
/Joel

On 2013-09-15, Peter Levart wrote:
> Hi,
> 
> I rebased the changes and added @bug tag to test. Here's new webrev:
> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.04/
> 
> 
> Joel, I believe you've got the "R" mojo now...
> 
> 
> Regards, Peter
> 
> On 09/09/2013 06:57 PM, Peter Levart wrote:
> >Hi Joel,
> >
> >Thanks for reviewing.
> >
> >On 09/09/2013 04:25 PM, Joel Borggr?n-Franck wrote:
> >>Hi Peter,
> >>
> >>Thanks for this, please add a "@bug 8011940" tag to your test. IMO you don't need  a re-review for that. Otherwise looks good.
> >
> >I'll do that. I just didn't know whether tagging with bug-ID is
> >meant for all tests that arise from fixing a particular bug or
> >just those that test the presence/fixture of the bug. The 8011940
> >bug is about scalability and the test is not testing scalability
> >(it has been demonstrated by a micro-benchmark, but that is not
> >included in the test). The test is just covering the logic that
> >has been re-factored and has not had any tests before.
> >
> >Regards, Peter
> >
> >>We still need a Reviewer, Chris, you reviewed a previous version, can you look at this one too?
> >>cheers
> >>/Joel
> >>
> >>On 27 aug 2013, at 15:00, Peter Levart  wrote:
> >>
> >>>Hi Joel and others,
> >>>
> >>>Here's a 3rd revision of this proposed patch:
> >>>
> >>>http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.03/
> >>>
> >>>I used LinkedHashMap for annotations in this one. It means that now even .getAnnotations() are reported in "declaration order": 1st inherited (includes overridden) then declared (that are not overriding). For example, using @Inherited annotations A1, A2, A3:
> >>>
> >>>@A1("C")
> >>>@A2("C")
> >>>class C {}
> >>>
> >>>@A1("D")
> >>>@A3("D")
> >>>class D extends C {}
> >>>
> >>>D.class.getAnnotations() now returns: { @A1("D"), @A2("C"), @A3("D") } ...
> >>>
> >>>The LHM constructor uses the following expression to estimate the initial capacity of the LHM:
> >>>
> >>>3326                         annotations = new LinkedHashMap<>((Math.max(
> >>>3327                                 declaredAnnotations.size(),
> >>>3328                                 Math.min(12, declaredAnnotations.size() + superAnnotations.size())
> >>>3329                             ) * 4 + 2) / 3
> >>>3330                         );
> >>>
> >>>
> >>>I think this strikes some balance between effectivity and accuracy of estimation. I could pre-scan the superclass annotations and calculate the exact final size of the annotations Map before constructing it though. Tell me if this is worth the effort.
> >>>
> >>>I also created a test that tests 3 things:
> >>>- class annotation inheritance
> >>>- order of class annotations reported by .getAnnotations() and .getDeclaredAnnotations() methods (although not specified, the order is now stable and resembles declaration order)
> >>>- behaviour of class annotation caching when class is redefined
> >>>
> >>>
> >>>Regards, Peter
> >>>
> >>>On 08/13/2013 09:52 AM, Joel Borggr?n-Franck wrote:
> >>>>Hi,
> >>>>
> >>>>Comments inline,
> >>>>
> >>>>On 12 aug 2013, at 14:40, Peter Levart  wrote:
> >>>>>On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote:
> >>>>>- annotation (@interface)  declarations can themselves be redefined (for example, defaults changed). Such redefinitions don't affect already initialized annotations. Default values are cached in AnnotationType which is not invalidated as a result of class redefinition. Maybe it should be. And even if AnnotationType was invalidated as a result of class redefinition, the defaults are looked-up when particular annotations are initialized and then combined with parsed values in a single values map inside each annotation instance (proxy), so invalidating AnnotationType would have no effect on those annotations.
> >>>>>
> >>>>>>3326                 if (annotations == null) { // lazy construction
> >>>>>>3327                     annotations = new HashMap<>();
> >>>>>>3328                 }
> >>>>>>
> >>>>>>I think this should be a LinkedHashMap, so that iteration is predictable
> >>>>>>(I know it isn't in the current code). Also the size of the map is known
> >>>>>>so you can use a constructor with an explicit initial capacity.
> >>>>>Right, AnnotationParser does return LinkedHashMap, so at least decalredAnnotations are in parse-order. I will change the code to use LinkedHashMap for inherited/combined case too.
> >>>>Thanks.
> >>>>
> >>>>>The number of annotations that end-up in inherited/combined Map is not known in advance. I could make a separate pre-scan for superclass annotations that are @Inheritable and don't have the same key as any of declared annotations and then sum this count with declared annotations count, but I don't think this will be very effective. I could allocate a large-enough Map to always fit (the count of superclass annotations + the count of declared annotations), but that could sometimes lead to much over-allocated Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations count + declared annotations count) as the initial capacity for the Map. What do you think which of those 3 alternatives is the best?
> >>>>My bad. I was thinking of the case where every inherited annotation was overridden, in that case annotations.size() == declaredAnnotations.size(). That is of course not generally true. I'm fine with handling this as a follow up since the situation is no worse than today and the surrounding code is better. However,
> >>>>
> >>>>1) We should really measure this.
> >>>>2) My gut feeling is that the ratio of not overridden inherited annotations to declared annotations is small IE the expected nr of annotations is much closer to declare annotations than to declared + superclass annotations.
> >>>>3) The default initial capacity is 16 and load factor is 0.75. I do think the mean nr of annotations is closer to 3 than to 12. We are probably wasting some space here.
> >>>>
> >>>>Perhaps use min(default cap, (total annotations/0.75 (+ 1?))) for now as that will make the situation no worse than today and often better?
> >>>>
> >>>>>>Since this is a fairly significant rewrite I think it might be good to
> >>>>>>make sure our tests exercise the new code. Can you run some kind of
> >>>>>>coverage report on this?
> >>>>>I successfully ran the jdk_lang jtreg tests which contain several tests for annotations.
> >>>>I'm a bit worried these tests doesn't cover annotations + class redefine. But I might be persuaded to have more extensive testing as a follow up as well.
> >>>>
> >>>>cheers
> >>>>/Joel
> >
> 


From magnus.ihse.bursie at oracle.com  Wed Sep 18 10:14:46 2013
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 18 Sep 2013 12:14:46 +0200
Subject: RFR(M): 8024265: Enable new build on AIX (jdk part)
In-Reply-To: 
References: 
Message-ID: <52397D16.7050500@oracle.com>

On 2013-09-16 17:20, Volker Simonis wrote:
> Hi,
>
> could you please review the following webrev which contains the changes
> needed in the 'jdk' repository in order to build the OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/

All in all, it looks good!

My only nitpick is that there's a copy/paste error in 
CompileNativeLibraries.gmk, where the comment does not match the actual 
if condition:

2866 ifeq ($(OPENJDK_TARGET_OS), aix)
2867         LIBJSOUND_CFLAGS += -DX_PLATFORM=X_AIX
2868 endif # OPENJDK_TARGET_OS linux

I don't think this warrants a new review, but if you get the chance you 
might want to fix it.

/Magnus


From weijun.wang at oracle.com  Wed Sep 18 10:25:52 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Wed, 18 Sep 2013 10:25:52 +0000
Subject: hg: jdk8/tl/jdk: 8012615: Realm.getRealmsList returns realms list in
	wrong
Message-ID: <20130918102712.42787628FD@hg.openjdk.java.net>

Changeset: ee8b292ee568
Author:    weijun
Date:      2013-09-18 18:22 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee8b292ee568

8012615: Realm.getRealmsList returns realms list in wrong
Reviewed-by: valeriep, xuelei

! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! test/sun/security/krb5/ParseCAPaths.java
! test/sun/security/krb5/krb5-capaths.conf



From Alan.Bateman at oracle.com  Wed Sep 18 10:31:11 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Sep 2013 11:31:11 +0100
Subject: RFR:  8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
In-Reply-To: <5238CFB4.1040304@oracle.com>
References: <5238CFB4.1040304@oracle.com>
Message-ID: <523980EF.6010208@oracle.com>

On 17/09/2013 22:55, Xueming Shen wrote:
> Hi,
>
> Please help the small update to the test case tools/jar/ChangeDir.java,
> which might fail if the "dedicated" test directory /tmp/a exists and the
> user does not have privilege to delete/clean it up.
>
> The proposed change here is to use a random file name (from 
> File.getTempFile())
> for the top test directory (instead of the fixed /tmp/a), and really 
> clean it up
> after testing (the old test leaves /tmp/a and those temp files 
> undeleted).
>
> http://cr.openjdk.java.net/~sherman/8023113/webrev
I've run into this a few times so thanks for fixing it.

What you have is okay although some of the setup and cleanup could be 
reduced, for example doTest could setup the test tree with:

Path topDir = Files.createTempDirectory("delete");
Path testDir = Files.createDirectories(topDir.resolve("a").resolve("b"));

It's not important for this fix of course, just an observation when 
looking at an old test.

-Alan.


From fweimer at redhat.com  Wed Sep 18 11:56:01 2013
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 18 Sep 2013 13:56:01 +0200
Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log
	lambda code generation
In-Reply-To: <523945CF.9060804@oracle.com>
References: <523945CF.9060804@oracle.com>
Message-ID: <523994D1.8090200@redhat.com>

On 09/18/2013 08:18 AM, Henry Jen wrote:
> Hi,
>
> Please review the webrev at
> http://cr.openjdk.java.net/~henryjen/ccc/8023524/0/webrev/
>
> This webrev enable writing generated classes for lambda to disk at a
> directory specified with -Djdk.internal.lambda.dumpProxyClasses.

+   File out = new File(dirPath, lambdaClassName.replace('/', '.') + 
".class");

Class names can contain '\' and other characters which are problematic 
on Windows.

-- 
Florian Weimer / Red Hat Product Security Team


From alan.bateman at oracle.com  Wed Sep 18 13:18:05 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 18 Sep 2013 13:18:05 +0000
Subject: hg: jdk8/tl/jdk: 8024883: (se) SelectableChannel.register throws NPE
	if fd >= 64k (lnx)
Message-ID: <20130918131836.525DC62904@hg.openjdk.java.net>

Changeset: e92635d6834c
Author:    alanb
Date:      2013-09-18 14:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e92635d6834c

8024883: (se) SelectableChannel.register throws NPE if fd >= 64k (lnx)
Reviewed-by: alanb, coffeys
Contributed-by: nmaurer at redhat.com, alan.bateman at oracle.com

! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EventPortWrapper.java
! test/java/nio/channels/Selector/LotsOfChannels.java
! test/java/nio/channels/Selector/SelectorLimit.java



From joel.franck at oracle.com  Wed Sep 18 13:27:33 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Wed, 18 Sep 2013 13:27:33 +0000
Subject: hg: jdk8/tl/langtools: 8024127: javac,
	Code_attribute.exception_table_langth should be
	Code_attribute.exception_table_length
Message-ID: <20130918132738.E8E6F62906@hg.openjdk.java.net>

Changeset: ac6ec071c2b2
Author:    alundblad
Date:      2013-09-18 14:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ac6ec071c2b2

8024127: javac, Code_attribute.exception_table_langth should be Code_attribute.exception_table_length
Summary: exception_table_langth renamed to exception_table_length
Reviewed-by: jfranck, jjg

! src/share/classes/com/sun/tools/classfile/Code_attribute.java
! src/share/classes/com/sun/tools/javap/CodeWriter.java
! test/tools/javac/T7093325.java
! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java
! test/tools/javac/multicatch/Pos05.java



From weijun.wang at oracle.com  Wed Sep 18 13:39:51 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Wed, 18 Sep 2013 13:39:51 +0000
Subject: hg: jdk8/tl/jdk: 8011402: Move blacklisting certificate logic from
	hard code to data
Message-ID: <20130918134014.5492762907@hg.openjdk.java.net>

Changeset: 07d73060e0da
Author:    weijun
Date:      2013-09-18 21:37 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07d73060e0da

8011402: Move blacklisting certificate logic from hard code to data
Reviewed-by: erikj, mullan

! make/java/security/Makefile
! makefiles/CopyFiles.gmk
! src/share/classes/java/security/cert/Certificate.java
! src/share/classes/sun/security/util/UntrustedCertificates.java
! src/share/classes/sun/security/x509/X509CertImpl.java
+ src/share/lib/security/BlacklistedCertsConverter.java
+ src/share/lib/security/blacklisted.certs
+ src/share/lib/security/blacklisted.certs.pem
+ test/lib/security/CheckBlacklistedCerts.java



From sundararajan.athijegannathan at oracle.com  Wed Sep 18 14:37:36 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Wed, 18 Sep 2013 14:37:36 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130918143741.268BA6290E@hg.openjdk.java.net>

Changeset: 1971c2d770ae
Author:    sundar
Date:      2013-09-18 13:06 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1971c2d770ae

8024972: for (LeftHandSideExpression in Expression) crashes the compiler
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8024972.js
+ test/script/basic/JDK-8024972.js.EXPECTED

Changeset: a62172fe5bae
Author:    sundar
Date:      2013-09-18 16:36 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a62172fe5bae

8024973: Using a different ScriptContext with a CompiledScript results in ScriptException
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/runtime/Source.java
! test/script/trusted/JDK-8008305.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java



From chris.hegarty at oracle.com  Wed Sep 18 14:13:40 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 18 Sep 2013 14:13:40 +0000
Subject: hg: jdk8/tl/jdk: 8015762: TEST_BUG:
	java/nio/channels/DatagramChannel/AdaptDatagramSocket.java
	failing intermittently [win]
Message-ID: <20130918141403.6FA616290A@hg.openjdk.java.net>

Changeset: b3a506a30fda
Author:    ewang
Date:      2013-09-18 15:13 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3a506a30fda

8015762: TEST_BUG: java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failing intermittently [win]
Reviewed-by: chegar, alanb

! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java



From nicholas+openjdk at nicholaswilliams.net  Wed Sep 18 15:00:50 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 18 Sep 2013 10:00:50 -0500
Subject: Replacement of sun.reflect.Reflection#getCallerClass
In-Reply-To: <52267FCE.70207@oracle.com>
References: 
	<522551AE.7060000@oracle.com> <52259B13.8060100@gmx.org>
	<52267FCE.70207@oracle.com>
Message-ID: 

Alright, I'm back! I'm sorry about my extended absence. I am over a month behind on my book (as mentioned in an earlier email) and I have been heads-down for a couple of weeks trying to get it finished. Still not finished yet, but I know people here are awaiting my feedback. I have several emails to respond to, so please bear with me. I'll be responding to several emails over the next few hours. I'll include in my last response an indication that I have finally caught up. All of my responses will be inline, starting with:

On Sep 3, 2013, at 7:33 PM, Mandy Chung wrote:

> On 9/3/13 1:17 AM, Jochen Theodorou wrote:
>>> Defining a SE supported @CallerSensitive and also getCallerClass API 
>>> poses the risk of "encouraging" developers to implement more @CS methods 
>>> while not fully understand its implication. 
>> 
>> Again I am curious... what is such an implication? That your method will behave different depending on from where it got called and, depending on if that is from an expected or unexpected source, you may get an expected or unexpected result here?
> 
> *and* this could lead to surprises and hard-to-diagnose issue to any framework/library or even another API provided in the same library calling a caller-sensitive method that can't tell if they get the true caller or not.
> 
> Caller-sensitivity is used in getting the right visibility (e.g. Resource.getBundle and Class.forName) and for security checks.

While I certainly agree that this is a big use-case for caller sensitivity, it's just the JVM's use case. Any library or application could potentially come up a different and perfectly legitimate use case. Log4j's three major use cases for caller sensitivity, for example, are not represented in this sentence.

> The platform's caller-sensitive methods involve both visibility and security.  For the former (visiability): the use cases of getCallerClass are mostly for gaining visibility to avoid having the client code to supply the appropriate ClassLoader or Class.  Such convenience has led to the existing stack walking code to search for a ClassLoader that it can find what the client code is asking for - it's not impossible that it might find the wrong ClassLoader but that happens to find a resource with the same name.  For the latter (security), caller sensitive methods have kept us having "so much fun" in the past CPU releases.
> 
> Groovy/log4j and other existing framework has already dealt with such problem and written some non-trivial code to solve this problem.  My point is more about the general app developers that need education and big warning in the documentation before they attempt learning this API to get the immediate caller.

Agreed. Big, huge warning. As big as you can make it, I'm okay with that. But don't restrict what developers can do.

> Couple months ago a few of us discussed some security issues we had fixed in the past and evaluated what we could do about them - one thing we want to do is to remove the caller sensitive-ness.  This is certainly a big big change and high compatibility risk - some future work.  Just to give you a sense how serious we are the security issue around caller-sensitive methods.
> 
> I'm happy to know that you will build into Groovy 3.x the ability to transport the caller class from the Groovy class.  I strongly believe this is the right thing to do and use the       ResourceBundle.getBundle and Class.forName with the ClassLoader parameter. No filtering and no magic caller class API as you said.
> 
> I have replied to Nick's patch with the focus on the ability to get Class instance from stack trace for diagnosability purpose.  I will soon bring up the discussion on the ability to get caller's Class / ClassLoader use case.
> 
> Until tomorrow.
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html



From nicholas+openjdk at nicholaswilliams.net  Wed Sep 18 15:10:24 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 18 Sep 2013 10:10:24 -0500
Subject: Replacement of sun.reflect.Reflection#getCallerClass
In-Reply-To: <4015A83A-B3A8-44B1-BDE9-EE3E00363DB2@me.com>
References: 
	<522551AE.7060000@oracle.com>
	
	<5225F268.2000707@oracle.com>
	<7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net>
	<5226197F.1050301@gmail.com> <52261F3A.3010604@redhat.com>
	<52262661.5000900@gmail.com> <522636AA.6000304@oracle.com>
	
	<4015A83A-B3A8-44B1-BDE9-EE3E00363DB2@me.com>
Message-ID: <9D0282BA-C659-48EB-A01C-C95C3532D14C@nicholaswilliams.net>


On Sep 4, 2013, at 11:38 PM, Andrew Thompson wrote:

> Indeed if giving access to arbitrary Class is going to introduce such headaches as exposing sun.* and trying to support arbitrary class loaders then Ralph has the right point. 
> It's also an example of the advantages or mirrors that Gilad is talking about here:http://gbracha.blogspot.com/2010/03/through-looking-glass-darkly.html

The fact of the matter is, code can still access sun.* Classes if it wants to. It can either use Class#forName (which can be subverted with a SecurityManager) or it can compile against them. Sure, you're not _supposed_ to use the sun.* classes, but the compiler lets you. If getting a Class is a security vulnerability, then the game's already over.

> 
> 
> So how about replace
> 
> Class getDeclaringClass()
> 
> With
> 
> DeclaringType getDeclaringType()
> 
> Where DeclaringType is
> 
> package java.lang.reflect(
> public interface DeclaringType extends Type {
> 
> public ClassLoader getClassLoader() throws SecurityException;
> public String getName();
> public ProtectionDomain getProductionDomain() throws SecurityException;
> public Package getPackage();

I'm not completely opposed to this idea, but it seems unnecessary to me and it restricts future development. Somebody somewhere will come up with a legitimate reason for getting some other information from the class, and they'll have to wait until the next JDK to get the change made to DeclaringType. The solution is to keep people from misusing Class.

It has been well established that a determined developer can get a Class somehow. The protections in the JVM should prevent you from actually *using* that class (instantiating, calling methods, etc.) if you're not allowed to. They should *not* prevent you from *inspecting* that class.

> 
> For convenience java.lang.Class could implement this interface but security sensitive contexts could return a much more limited type when appropriate. 
> 
> 
> 
> 
> On Sep 3, 2013, at 3:45 PM, Ralph Goers  wrote:
> 
>> In Log4j's case the information we want from each StackTraceFrame is:
>> 
>> a) the class name,
>> b) the jar or directory where the class resided.
>> c) the version of the jar.
>> d) the ClassLoader associated with the class.
>> 
>> Having the actually Class object allows us to get all of this information but if it is deemed more secure to just include all the individual information instead that would be fine.
>> 
>> Ralph
>> 
>> On Sep 3, 2013, at 12:21 PM, Mandy Chung wrote:
>> 
>>> On 9/3/13 11:11 AM, Peter Levart wrote:
>>>> On 09/03/2013 07:41 PM, David M. Lloyd wrote:
>>>>>> What about a simple restriction on methods returning such instances that
>>>>>> Class objects are only returned when they are resolvable from the
>>>>>> ClassLoader of client code. If they are not resolvable, null is
>>>>>> returned. For example, the equivalent of:
>>>>>> 
>>>>> 
>>>>> I don't think this will hold up.  Why would (for example) a logging API have access to every class loader that might need to log something?  In any system of appreciable size, there is typically at least *some* class loader isolation, often a lot of it.  Utilities like logging or security code that need to do this kind of check do not typically have direct access to classes which are "higher on the stack", so to speak. 
>>>> 
>>>> Ok, I understand. What about the other way around - would this be acceptable from security perspective (asking Mandy?):
>>> 
>>> I don't think that works for log4j either.  In general we should only allow a ClassLoader A to access classes loaded by a ClassLoader B only if B trusts A (i.e A is the same or an ancestor of B); otherwise some kind of permission check (e.g. package access) is required.    Log4j wants to access all Class instances on the stack for diagnosibility purpose and unless Log4j is loaded by the bootstrap class loader (put -Xbootclasspath) it may not be able to get access to all classes via Class.forName call.
>>> 
>>> This would probably need a coarse-grained permission than a fine-grained permission check on the indivdual stack frame subject to the ClassLoader/Class.
>>> 
>>> Mandy
>>> 
>>>> 
>>>> - If you can see me (by name), then you're exposed (I can get you):
>>>> 
>>>> public class StackTraceFrame {
>>>> 
>>>>  private final Class declaringClass;
>>>> 
>>>>  @CallerSensitive
>>>>  public Class getDeclaringClass() {
>>>>      try {
>>>>          Class cc = Reflection.getCallerClass();
>>>>         return Class.forName(cc.getName(),
>>>>                               false,
>>>> declaringClass.getClassLoader())
>>>>                 == cc ? declaringClass : null;
>>>> 
>>>>      } catch (ClassNotFoundException ignore) {}
>>>>      return null;
>>>>  }
>>>> 
>>>> 
>>>> This would not present a problem for JDK system classes since they can not see client code.
>>> 
>> 
> 



From Alan.Bateman at oracle.com  Wed Sep 18 15:20:45 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Sep 2013 16:20:45 +0100
Subject: RFR 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond
	to split() method if using an example from the spec
In-Reply-To: 
References: 
Message-ID: <5239C4CD.1060307@oracle.com>

On 15/09/2013 17:27, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8024341-pattern-splitAsStream/webrev/
>
> This fixes an issue with Pattern.splitAsStream reporting empty trailing elements and aligns with the functionality of Pattern.split(CharSequence input).
>
> The matching iterator passed to the stream was updated to aggressively consume and keep a count of a sequence of empty matching elements such that those elements can either be reported if not trailing, or discarded if trailing.
>
> Paul.
It make sense to adjust the spec to have it consistent with 
split(CharSequence).

On the implementation then I had to read it a few times to understand 
how emptyElementCount is used. I wonder if it could be done in a simpler 
way, say just setting a flag when current reaches input.length? Maybe 
you have tried this already.

On the test then you probably should include 8016846 in @bug tag as 
otherwise it looks like it was added specifically for 8024341.

-Alan.


From david.lloyd at redhat.com  Wed Sep 18 15:21:47 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 18 Sep 2013 10:21:47 -0500
Subject: Replacement of sun.reflect.Reflection#getCallerClass
In-Reply-To: <5226197F.1050301@gmail.com>
References: 
	<522551AE.7060000@oracle.com>
	
	<5225F268.2000707@oracle.com>
	<7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net>
	<5226197F.1050301@gmail.com>
Message-ID: <5239C50B.7080300@redhat.com>

On 09/03/2013 12:16 PM, Peter Levart wrote:
[...]
> *AND* that Reflection.getCallerClass() can only be called from within
>  methods annotated with @CallerSensitive.
>
> Now for that part, the public API equivalent
> (StackTraceFrame.getCallerClass() or whatever it is called) need not
> be restricted to methods annotated with any annotation, but that
> means that this public API should not be used to implement security
> decisions since MethodHandles API allows caller to be spoofed unless
> looking-up a method annotated with @CallerSensitive...

Peter, can you please elaborate on this a bit?  I could find nothing in 
the MethodHandles API or its associated classes that would seem to give 
the ability to call another method with a spoofed caller.  Yes you can 
set up a Lookup for another class but I don't see how that would affect 
the ability of (say) a security manager to make access decisions based 
on the call stack/class context?

-- 
- DML


From nicholas+openjdk at nicholaswilliams.net  Wed Sep 18 15:30:49 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 18 Sep 2013 10:30:49 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <5226787F.6060307@oracle.com>
References: 
	<5226787F.6060307@oracle.com>
Message-ID: 


On Sep 3, 2013, at 7:02 PM, Mandy Chung wrote:

> Nick,
> 
> I skimmed through the changes.  Congratulations for your first patch making changes in both hotspot and jdk code.

Thanks. And, again, apologies for my extended absence.

> In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class / loader to lookup resources.  While the new APIs might be in the same class, I will discuss them individually and keep us focus one at a time.

Ok.

> Ralph has pointed out [1] that Log4j also needs the ability to find an appropriate ClassLoader which is used for logging separation (thank you Ralph). That will be the caller-sensitivity (i.e. obtain caller's class/loader) discussion.
> 
> There are a couple of RFEs:
> https://bugs.openjdk.java.net/browse/JDK-4942697
> https://bugs.openjdk.java.net/browse/JDK-6349551
> 
> Performance is critical for Log4j to traverse the stack trace and obtain Class information.  I like your patch to speed up the generation of StackTraceElement[] (and StackTraceFrame[] - essentially same code with different type). java.util.logging.LogRecord has workaround the performance overhead and go to a specific frame directly and avoid the cost of generating the entire array. JDK-6349551 requests to lazily instantiate the StackTraceElement object unless that frame is requested.  Does Log4J always walk all frames and log all information?  Do you just log only some max number of frames rather than the entire stack trace?

It depends on what part of Log4j is using the stack trace. *Sometimes* it walks the entire stack. For example, if an exception is logged, Log4j walks the entire stack for that exception and any causing and suppressed exceptions to print out the stack trace. Most of the time, it only walks back part of the stack. For example, if the logging configuration includes the printing of the class/method/file/line that issued the log event, every time an event is logged the layout walks back the stack until it finds the caller of the trace/info/debug/warn/error/fatal method. This happens *a lot* (every time a log event is written), so performance is critical. Then there's the case where we just find the immediate caller--LogManager.getLogger() uses the immediate caller class to determine the name of the Logger. These are all important use cases of the stack in Log4j.

> Class getDeclaringClass() method is the key method you need to enhance the diagnosability.  This method opens up a new way to access a Class instance that untrusted code wouldn't be able in the past.  A permission check is needed as Alan points out early.  Performance as well as logging framework can't access all class loaders are two factors to be considered when defining the permission check.

I still don't understand this assertion. Let's say I write malicious code that somehow gets a Class it doesn't have access to, even with a SecurityManager installed. Will I be allowed to instantiate this class? Will I be allowed to invoke static methods on this class. If so, I see *THAT* as the big problem. Not the fact that I got the Class and can inspect its properties. I can't really do anything menacing with that. I shouldn't be able to instantiate the class or invoke methods. If I can, I think *THAT* needs to be fixed.

> I saw your other comment about permission check (cut-n-paste below).  It seems to me that you don't agree a permission check is needed for the getDeclaringClass() method (regardless of which class it belongs to) and if that's the case, no point to continue.

Yes, that's my stance, as per my statement immediately above. I'm sure I could be convinced otherwise, but I haven't yet been.

> I want to make it very clear that I have agreed to take this on and provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases.  It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time).

That is good news. Thank you for agreeing to take it on.

> The second comment on your patch is that there are lot of duplicated code in hotspot in order to support two similar but different types (StackTraceFrame and StackTraceElement). Serialization is the reason leading you to have a new StackTraceFrame class.

Yes. In the original discussion about this back in June, it was made *very* clear to me that we could not include the Class in StackTraceElement due to serialization issues. That insistence is what I based my patch on.

> Maybe some refactoring can help but this is the cost of having the VM directly creating the instance.  One other option, as suggested in the previous thread, is to keep the declaring class in the StackTraceElement as a transient field.

It was also made *very* clear to me that transience was not an option. I was told that the Class needed to be in a separate class that wasn't serializable. This insistence is another thing I based my patch on.

> If we add the getDeclaringClass method in the StackTraceElement class, it would need to specify to be optional that it only returns the Class instance when it's available.

Agreed. That's what I originally argued for because it was going to be a vastly simpler change. I'm not saying it's not the right answer, but I must admit I'll be very dismayed if we end up reverting to my original suggestion...

> There are currently three different ways to get a stack trace:
> 1. Throwable.getStackTrace()
> 2. Thread.getStackTrace() and Thread.getAllStackTraces()
> 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int maxDepth).getStackTrace() and multiple thread IDs version
>  (a) local (b) remote
> 
> Since it's a new StackTraceFrame class, you have to provide a new method replacing #1 and #2.  I don't see any need to provide a new API equivalent to Thread.getAllStackTraces() and java.lang.management.

Agreed. And that's why I didn't.

> The proposal I originally have last week was to keep declaring class as transient and add a method in StackTraceElement with a permission check at every call. Tom raises a good question about the cost of permission check.  Would that be a concern to Log4j?

Anything that has cost is a concern to Log4j. Additionally, please see my earlier reservations about a security check when calling getDeclaringClass. I see no need for a permission check to determine whether they can obtain the Class if there are additional security checks that keep them from instantiating and/or using the class.

> Is log4j on bootclasspath or extension directory?  I assume not.

Not usually. Typically it's just on the app class path. In a Java EE application server / Servlet container, it may be on the container class path (if the container is using Log4j), or it may be on the application's WEB-INF/lib class path (if the container is not using Log4j but the application is).

> So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm?

Maybe one of the other Log4j guys listening in can provide input on this. Ralph? I'm relatively new to the Log4j team (just joined in last 6 months). Personally, I've never heard anyone complain about having issues with the SecurityManager. However, Log4j 1 did not use getCallerClass, and many users are still on that version. Log4j 2 started using getCallerClass.

> For example it calls sun.reflect.Reflection.getCallerClass method that will require RuntimePermission("accessClassInPackage.sun.reflect") permission.  Calling Class.getProtectionDomain and Class.getClassLoader() requires RuntimePermission("getProtectionDomain") and
> RuntimePermission("getClassLoader") respectively.  That gives me an impression that permission check on individual stack frame might be a non-issue?

I'm not sure exactly what you mean here, but okay. There are security restrictions. So, you're probably right, we're bound to run into trouble eventually. I'd like to eliminate that trouble, including for users that have no control over their security manager.

> 
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html
> 
> On 9/3/13 5:24 AM, Nick Williams wrote:
>> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
>>>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check.
>>> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API.
>> As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should!
>> 
>> Nick
> 
> 
> 
> On 9/1/13 1:16 AM, Nick Williams wrote:
>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444).
>> 
>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong.
>> 
>> *Summary of Changes*
>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows:
>> 
>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8.
>> 
>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8.
>> 
>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame.
>> 
>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame.
>> 
>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames.
>> 
>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast.
>> 
>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive.
>> 
>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected.
>> 
>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works).
>> 
>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods.
>> 
>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch!
>> 
>> *The Code Changes*
>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes):
>> 
>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch
>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch
>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch
>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch
>> 
>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions.
>> 
>> Thanks!
>> 
>> Nick
> 
> 



From nicholas+openjdk at nicholaswilliams.net  Wed Sep 18 16:11:53 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 18 Sep 2013 11:11:53 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <5227C0F0.5040108@oracle.com>
References: 
	<5227C0F0.5040108@oracle.com>
Message-ID: 


On Sep 4, 2013, at 6:23 PM, Mandy Chung wrote:

> On 9/1/2013 1:16 AM, Nick Williams wrote:
>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8.
>> 
>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8.
>> 
> 
> The other part of this patch is about the ability to obtain the caller information.  The use case includes Groovy 2.x and GUI app to look up resource bundles on behalf on the caller and Log4j for logging isolation depending on its caller (isolation on ClassLoader for the app).
> 
> Such methods are caller-sensitive and must obtain the right caller; otherwise it might get surprises.
> 
> The proposed getCallerClass() method, no-arg version, looks reasonable and it will return the immediate effective caller of the method calling the getCallerClass method. Use your example (I add the class for the discussion later).  Let's ignore the @CallerSensitive annotation for now.
> 
>    getCallerClass();
>    Foo.someMethod1();
>    Bar.someMethod2();
>    Gee.someMethod3();
>    App.actualCallerMethod()
> 
> The caller is Bar.someMethod2() and getCallerClass() method will return Bar.  It will return the same result even if Foo is called via reflection (the VM already handles this and skips the reflection machinery).
> 
> When security manager is installed, under what condition can Foo class access Bar class (any permission check)?  What if Bar is in a restricted package?

I would say "under all circumstances." For example, if some bit of code is able to call Log4j's LogManager.getLogger(), I see no reason that LogManager should ever be restricted from seeing Bar. It should be a two-way street. Restricting access to Bar would be like an email provider allowing people to email me but not allowing me to email them back. Makes no sense. If I'm a method, and some other method can call me, I should have visibility to that calling method.

> The standard way to determine if class A has access to class B is based on their class loaders and also it is a restricted class (configured in the package.access property in JRE/lib/security/java.security).  Code has full access to its own class loader and any class loader that is a descendent.  There are several methods in java.lang.Class that are performing this security check:
> 
>     * @throw  SecurityException
>     *         If a security manager, s, is present and the caller's
>     *         class loader is not the same as or an ancestor of the class
>     *         loader for the returning Class object and invocation of {@link
>     *         SecurityManager#checkPackageAccess s.checkPackageAccess()}
>     *         denies access to the package of returning Class object
> 
> I think the above security check should be applicable to the getCallerClass method.

I disagree, for reasons I stated above. I think the security check should happen later, preventing the holder of the Class from instantiating or invoking a restricted class or a class in a restricted package or restricted ClassLoader.

> It means that
> Foo can access Bar if Foo's class loader is the same or an ancestor of Bar's class loader; otherwise, it will perform the package access check. BTW - including an example in the javadoc would be helpful since the term "caller" might be confusing.

Agreed--an example should go in the Javadoc for these methods.

> For the known use cases, they are interested in getting the caller's class loader.  Class.getClassLoader method has the following security check:
> 
>     * 
 If a security manager is present, and the caller's class loader is
>     * not null and the caller's class loader is not the same as or an ancestor of
>     * the class loader for the class whose class loader is requested, then
>     * this method calls the security manager's {@code checkPermission}
>     * method with a {@code RuntimePermission("getClassLoader")}
>     * permission to ensure it's ok to access the class loader for the class.
> 
> I wonder if Class instance is really needed while I understand we can't anticipate all cases.  Most of the caller-sensitive methods in the JDK only need to get caller's ClassLoader.

But not most of the caller-sensitve methods in Log4j--it needs to access the class name, package, ClassLoader, and CodeSource.

> There are very few cases that require the caller class (used in the reflection implementation that I have yet to understand deeper).   Perhaps all you need is getCallerClassLoader method?

Nope. See above.

> In that case, you will be able to get the caller's class loader if you have the access.  This is one thing I'd like to explore further (either one or both).
> 
> Performance - I believe in common cases Foo's class loader should be the same or ancestor of Bar's clas loader.  Bar calls Foo which should be visible to Bar's class loader.  It'd be very useful if Groovy and Log4j can measure the performance overhead with security manager installed when it's available and see if it is a concern.

I can't guarantee that I can do this within the next month. I'm still not done with my book, and it has to come first. Maybe one of the other Log4j devs can. Ralph? Can you take this on?

> About the proposed getCallerClass(int) method to find a frame at a specific depth is essentially putting back the sun.reflect.Reflection.getCallerClass(int depth) method.  This method is very flexible but brittle.

It's what Log4j is currently using to fill in as much of the stack trace as it can for Throwables. It calls getCallerClass repeatedly with increasing depth to build the stack trace. If we have a way to get the stack trace with Classes (StackTraceFrame.getCurrentStackTrace(), StackTraceFrame.getStackTrace(Throwable)), Log4j no longer needs to use getCallerClass(int). However, there could be other code out there using getCallerClass(int) where getCallerClass() would not work and getting a stack trace with Classes would be a performance hindrance. I wanted to ensure these use cases were supported, but admittedly I can't immediately enumerate what these uses cases might be.

> I still think it's more reliable that a caller-sensitive method should capture the caller and pass it to the runtime properly. Groovy 3.x doesn't do the stack walk. Groovy 2.x needs a temporary solution to filter out the intermediate frames of groovy runtime, would StackTraceFrame.getDeclaringClass be an adequate interim solution?

I can't speak to this.

> More on @CallerSensitive and s.r.Reflection.getCallerClass(int):
> 
> We had found severe bugs in the code to call s.r.Reflection.getCallerClass(int) when prototying the fix for JEP 176 but they were not noticed and no test uncovered them.  e.g. wrong depth was used (easy to miscount the depth or the depth is modified due to refactoring but difficult to be caught during review).  As a caller-sensitive method, it's important to find the right caller; otherwise unexpected behavior.
> 
> In the first prototype, Chris Thalinger did implement JVM_GetCallerClass to walk past all @CS frames and find the immediate caller.  All methods in the method chain invoked by the actual caller must be annotated by @CS which ends up something like the example you used earlier:
> 
> @CallerSensitive getCallerClass(int)
> @CallerSensitive someMethod1()
> @CallerSensitive someMethod2()
> @CallerSensitive someMethod3()
> @CallerSensitive someMethod4()
> actualCallerMethod()
> 
> With more analysis, we identified that there was no absolute need (in the JDK) to walk the stack but instead a more reliable way is to capture the caller at the entry point of the caller-sensitive methods.  In the example above, someMethodxx() are internal implementation in the JDK case and thus we modified them to take the caller class parameter (instead of looking it up at its execution point).  This greatly simplifies the VM enforcement to detect if the method calling JVM_GetCallerClass is a caller-sensitive method.

I do agree with how it was ultimately implemented. The main theoretical problem I see with the first prototype is that if the caller method is itself annotated @CallerSensitive for its own reasons, it breaks the method it's calling. The way it was ultimately implemented prevents this from happening. Of course, that eliminates the need for the specific @CallerSensitive annotation completely, in my opinion. But that's just my $0.02.

> My feedback is that the getCallerClass() method seems to be adequate for all use cases except Groovy 2.x.  I would suggest traversing the stack trace (with the new getDeclaringClass method) be the alternative to adding getCallerClass(int) method.  Jochen and others - what do you think?
> 
> On the @CS subject, if we keep @CallerSensitive in sun.reflect in JDK8, the new getCallerClass() method is a caller-sensitive method and if it is called by the system classes, it will enforce that the caller must be annotated with @s.r.CS; if it called by non-system classes, the VM will return the caller and no check on the annotation.

I'm fine with this approach, I just see little point in using @CallerSensitive at all once the API is public. The native code as written would still work identically to the way it does now if we removed the @CallerSensitive annotation.

> The implication is in the 292 method handles. The current behavior is that if a MethodHandle for a caller-sensitive method is requested, it will bind the method handle with the lookup class (i.e. as if it were called from an instruction contained in the lookup class).  There is no change to the current behavior since the current implementation only allows JVM_GetCallerClass be called from system classes.  If an app (e.g. Foo.m method) calls the new getCallerClass method, a MethodHandle for Foo.m will not bind with the lookup class.  This will need to get John Rose and other 292 members' feedback on it.

I don't think I understand what you're saying/asking here, but maybe it wasn't meant for me.

> 
> This is my thinking so far.  Feedback and comments?
> 
> Mandy



From nicholas+openjdk at nicholaswilliams.net  Wed Sep 18 16:19:21 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 18 Sep 2013 11:19:21 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <522E0BF7.7060403@gmail.com>
References: 
	<5226787F.6060307@oracle.com> <522DE112.4090905@oracle.com>
	
	<522E0BF7.7060403@gmail.com>
Message-ID: <6751C7B1-EE72-41BA-921F-3D7B7599A031@nicholaswilliams.net>


On Sep 9, 2013, at 12:57 PM, Peter Levart wrote:

> 
> On 09/09/2013 07:02 PM, David Chase wrote:
>> Take this lightly informed suggestion with a grain of salt, but why not, for purposes of performance and security,
>> change the logging-specific getCallerClass methods so that their "class" references are instead wrapped in some sort of proxy object that only forwards certain operations quickly without a security check?  For example, equals, hashcode, and toString are probably not security-sensitive.
>> 
>> i.e.
>> class SafeClass {
>>  private final Class clazz;
>>  public SafeClass(Class clazz) { this.clazz = class; }
>>  public String toString() { return clazz.toString(); }
>>  public int hashCode() { return clazz.hashCode(); }
>>  public boolean equals(Object o) { return clazz.equals(o); }
>>  public Class maybeWeLetYouLookAtTheRealClass() { ... a bunch of security checks ... }
>> }
>> 
>> If necessary, do the same for classloaders.
>> And them, no security checks needed, as long as the "safe" methods are enough to get the job done.
> 
> Hi,
> 
> This is a good idea. It got me thinking that there are a bunch of methods in j.l.Class that are not security-sensitive. So instead of proxy-ing those in a wrapper SafeClass, let's just identify "unsafe" methods 1st. If the security checks that are planned for obtaining j.l.Class instances from call-stack are transferred to those unsafe methods instead, then holding a reference to a j.l.Class instance becomes a security-nonissue.

Yes! This is what I have been saying. If there are unsafe methods in Class not protected from restricted access, then security checks need to be added to *those* methods. Otherwise, once malicious code gets a Class all bets are off. Don't restrict access to the Class, just to its unsafe methods (instantiation, invoking Constructors, invoking Methods, etc.).

> Just a quick example - presumably the "unsafe" methods of j.l.Class are: get(Declared)Method(s), get(Declared)Field(s) and get(Declared)Constructor(s)

I would actually argue that those aren't unsafe. The *invoke* methods on Constructors/Methods are what are unsafe.

> , because they enable you to call/access public methods/fields/constructors of a class represented by j.l.Class object. If this class is from a restricted package (say sun.misc) then you could get access to restricted methods/fields/instances. Now if the security checks for obtaining reflective object would include checking the "class visibility/restrictability", then j.l.Class object of say sun.misc.Unsafe class would not represent any security issue. It's just about ******delaying******* the security check. What do you think?

(asterisks mine) Yes. Please. Let's do this. :-)

> Are there any other security-sensitive j.l.Class methods? Are there any public methods in JDK that take j.l.Class instances and delegate to internal logic assuming that the caller can only pass-in security-pre-checked j.l.Class instances?

A legitimate concern that would need to be researched to identify if this will be a problem.

> Regards, Peter
> 
>> David
>> 
>> On 2013-09-09, at 10:54 AM, Mandy Chung  wrote:
>> 
>>> Nick,
>>> 
>>> Do you have any information to some of the questions I asked below that can help the API discussion?
>>> 
>>> We need to decide on the permission check and also the hotspot change has to be integrated and the jdk change will need to wait until it shows in a promoted build.  Schedule-wise, to make JDK 8, we should finalize the API this week so that you can update the patch soon.
>>> 
>>> Mandy
>>> 
>>> On 9/3/2013 5:02 PM, Mandy Chung wrote:
>>>> Nick,
>>>> 
>>>> I skimmed through the changes.  Congratulations for your first patch making changes in both hotspot and jdk code.
>>>> 
>>>> In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class / loader to lookup resources.  While the new APIs might be in the same class, I will discuss them individually and keep us focus one at a time.
>>>> 
>>>> Ralph has pointed out [1] that Log4j also needs the ability to find an appropriate ClassLoader which is used for logging separation (thank you Ralph). That will be the caller-sensitivity (i.e. obtain caller's class/loader) discussion.
>>>> 
>>>> There are a couple of RFEs:
>>>> https://bugs.openjdk.java.net/browse/JDK-4942697
>>>> https://bugs.openjdk.java.net/browse/JDK-6349551
>>>> 
>>>> Performance is critical for Log4j to traverse the stack trace and obtain Class information.  I like your patch to speed up the generation of StackTraceElement[] (and StackTraceFrame[] - essentially same code with different type). java.util.logging.LogRecord has workaround the performance overhead and go to a specific frame directly and avoid the cost of generating the entire array. JDK-6349551 requests to lazily instantiate the StackTraceElement object unless that frame is requested.  Does Log4J always walk all frames and log all information?  Do you just log only some max number of frames rather than the entire stack trace?
>>>> 
>>>> Class getDeclaringClass() method is the key method you need to enhance the diagnosability.  This method opens up a new way to access a Class instance that untrusted code wouldn't be able in the past.  A permission check is needed as Alan points out early.  Performance as well as logging framework can't access all class loaders are two factors to be considered when defining the permission check.
>>>> 
>>>> I saw your other comment about permission check (cut-n-paste below).  It seems to me that you don't agree a permission check is needed for the getDeclaringClass() method (regardless of which class it belongs to) and if that's the case, no point to continue.
>>>> 
>>>> I want to make it very clear that I have agreed to take this on and provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases.  It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time).
>>>> 
>>>> The second comment on your patch is that there are lot of duplicated code in hotspot in order to support two similar but different types (StackTraceFrame and StackTraceElement). Serialization is the reason leading you to have a new StackTraceFrame class.  Maybe some refactoring can help but this is the cost of having the VM directly creating the instance.  One other option, as suggested in the previous thread, is to keep the declaring class in the StackTraceElement as a transient field.  If we add the getDeclaringClass method in the StackTraceElement class, it would need to specify to be optional that it only returns the Class instance when it's available.
>>>> 
>>>> There are currently three different ways to get a stack trace:
>>>> 1. Throwable.getStackTrace()
>>>> 2. Thread.getStackTrace() and Thread.getAllStackTraces()
>>>> 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int maxDepth).getStackTrace() and multiple thread IDs version
>>>> (a) local (b) remote
>>>> 
>>>> Since it's a new StackTraceFrame class, you have to provide a new method replacing #1 and #2.  I don't see any need to provide a new API equivalent to Thread.getAllStackTraces() and java.lang.management.
>>>> 
>>>> The proposal I originally have last week was to keep declaring class as transient and add a method in StackTraceElement with a permission check at every call. Tom raises a good question about the cost of permission check.  Would that be a concern to Log4j? Is log4j on bootclasspath or extension directory?  I assume not. So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm?  For example it calls sun.reflect.Reflection.getCallerClass method that will require RuntimePermission("accessClassInPackage.sun.reflect") permission. Calling Class.getProtectionDomain and Class.getClassLoader() requires RuntimePermission("getProtectionDomain") and
>>>> RuntimePermission("getClassLoader") respectively.  That gives me an impression that permission check on individual stack frame might be a non-issue?
>>>> 
>>>> Mandy
>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html
>>>> 
>>>> On 9/3/13 5:24 AM, Nick Williams wrote:
>>>>> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
>>>>>>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check.
>>>>>> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API.
>>>>> As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should!
>>>>> 
>>>>> Nick
>>>> On 9/1/13 1:16 AM, Nick Williams wrote:
>>>>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444).
>>>>> 
>>>>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong.
>>>>> 
>>>>> *Summary of Changes*
>>>>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows:
>>>>> 
>>>>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8.
>>>>> 
>>>>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8.
>>>>> 
>>>>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame.
>>>>> 
>>>>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame.
>>>>> 
>>>>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames.
>>>>> 
>>>>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast.
>>>>> 
>>>>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive.
>>>>> 
>>>>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected.
>>>>> 
>>>>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works).
>>>>> 
>>>>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods.
>>>>> 
>>>>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch!
>>>>> 
>>>>> *The Code Changes*
>>>>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes):
>>>>> 
>>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch
>>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch
>>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch
>>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch
>>>>> 
>>>>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Nick
> 



From nicholas+openjdk at nicholaswilliams.net  Wed Sep 18 16:20:01 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 18 Sep 2013 11:20:01 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <522E409A.6000502@oracle.com>
References: 
	<5226787F.6060307@oracle.com> <522DE112.4090905@oracle.com>
	
	<522E409A.6000502@oracle.com>
Message-ID: <055706FA-FD1D-4C1C-BB2F-7D479084793B@nicholaswilliams.net>


On Sep 9, 2013, at 4:41 PM, Mandy Chung wrote:

> On 9/9/13 10:02 AM, David Chase wrote:
>> Take this lightly informed suggestion with a grain of salt, but why not, for purposes of performance and security,
>> change the logging-specific getCallerClass methods so that their "class" references are instead wrapped in some sort of proxy object that only forwards certain operations quickly without a security check?  For example, equals, hashcode, and toString are probably not security-sensitive.
> 
> Most of the information obtained from a class the use cases are interested in are security-sensitive information (e.g. protection domain, code source, class loader).

Why?

> 
> Mandy
> 
>> i.e.
>> class SafeClass {
>>  private final Class clazz;
>>  public SafeClass(Class clazz) { this.clazz = class; }
>>  public String toString() { return clazz.toString(); }
>>  public int hashCode() { return clazz.hashCode(); }
>>  public boolean equals(Object o) { return clazz.equals(o); }
>>  public Class maybeWeLetYouLookAtTheRealClass() { ... a bunch of security checks ... }
>> }
>> 
>> If necessary, do the same for classloaders.
>> And them, no security checks needed, as long as the "safe" methods are enough to get the job done.
>> 
>> David
>> 
>> On 2013-09-09, at 10:54 AM, Mandy Chung  wrote:
>> 
>>> Nick,
>>> 
>>> Do you have any information to some of the questions I asked below that can help the API discussion?
>>> 
>>> We need to decide on the permission check and also the hotspot change has to be integrated and the jdk change will need to wait until it shows in a promoted build.  Schedule-wise, to make JDK 8, we should finalize the API this week so that you can update the patch soon.
>>> 
>>> Mandy
>>> 
>>> On 9/3/2013 5:02 PM, Mandy Chung wrote:
>>>> Nick,
>>>> 
>>>> I skimmed through the changes.  Congratulations for your first patch making changes in both hotspot and jdk code.
>>>> 
>>>> In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class / loader to lookup resources.  While the new APIs might be in the same class, I will discuss them individually and keep us focus one at a time.
>>>> 
>>>> Ralph has pointed out [1] that Log4j also needs the ability to find an appropriate ClassLoader which is used for logging separation (thank you Ralph). That will be the caller-sensitivity (i.e. obtain caller's class/loader) discussion.
>>>> 
>>>> There are a couple of RFEs:
>>>> https://bugs.openjdk.java.net/browse/JDK-4942697
>>>> https://bugs.openjdk.java.net/browse/JDK-6349551
>>>> 
>>>> Performance is critical for Log4j to traverse the stack trace and obtain Class information.  I like your patch to speed up the generation of StackTraceElement[] (and StackTraceFrame[] - essentially same code with different type). java.util.logging.LogRecord has workaround the performance overhead and go to a specific frame directly and avoid the cost of generating the entire array. JDK-6349551 requests to lazily instantiate the StackTraceElement object unless that frame is requested.  Does Log4J always walk all frames and log all information?  Do you just log only some max number of frames rather than the entire stack trace?
>>>> 
>>>> Class getDeclaringClass() method is the key method you need to enhance the diagnosability.  This method opens up a new way to access a Class instance that untrusted code wouldn't be able in the past.  A permission check is needed as Alan points out early.  Performance as well as logging framework can't access all class loaders are two factors to be considered when defining the permission check.
>>>> 
>>>> I saw your other comment about permission check (cut-n-paste below).  It seems to me that you don't agree a permission check is needed for the getDeclaringClass() method (regardless of which class it belongs to) and if that's the case, no point to continue.
>>>> 
>>>> I want to make it very clear that I have agreed to take this on and provide a replacement of sun.reflect.Reflection.getCallerClass(int) in JDK 8 to address the use cases.  It will take time for the API and security discussion and please be prepared for that (also I am working on other things at the same time).
>>>> 
>>>> The second comment on your patch is that there are lot of duplicated code in hotspot in order to support two similar but different types (StackTraceFrame and StackTraceElement). Serialization is the reason leading you to have a new StackTraceFrame class.  Maybe some refactoring can help but this is the cost of having the VM directly creating the instance.  One other option, as suggested in the previous thread, is to keep the declaring class in the StackTraceElement as a transient field.  If we add the getDeclaringClass method in the StackTraceElement class, it would need to specify to be optional that it only returns the Class instance when it's available.
>>>> 
>>>> There are currently three different ways to get a stack trace:
>>>> 1. Throwable.getStackTrace()
>>>> 2. Thread.getStackTrace() and Thread.getAllStackTraces()
>>>> 3. java.lang.management.ThreadMXBean.getThreadInfo(long id, int maxDepth).getStackTrace() and multiple thread IDs version
>>>> (a) local (b) remote
>>>> 
>>>> Since it's a new StackTraceFrame class, you have to provide a new method replacing #1 and #2.  I don't see any need to provide a new API equivalent to Thread.getAllStackTraces() and java.lang.management.
>>>> 
>>>> The proposal I originally have last week was to keep declaring class as transient and add a method in StackTraceElement with a permission check at every call. Tom raises a good question about the cost of permission check.  Would that be a concern to Log4j? Is log4j on bootclasspath or extension directory?  I assume not. So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm?  For example it calls sun.reflect.Reflection.getCallerClass method that will require RuntimePermission("accessClassInPackage.sun.reflect") permission. Calling Class.getProtectionDomain and Class.getClassLoader() requires RuntimePermission("getProtectionDomain") and
>>>> RuntimePermission("getClassLoader") respectively.  That gives me an impression that permission check on individual stack frame might be a non-issue?
>>>> 
>>>> Mandy
>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020525.html
>>>> 
>>>> On 9/3/13 5:24 AM, Nick Williams wrote:
>>>>> On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
>>>>>>> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check.
>>>>>> I would say this is TBD and start by asking the question as to whether there are concerns about leaking reference to Class objects that untrusted code wouldn't normally be able to get a reference to. Tom brings up the cost of the permission check and also whether any API should be tied to class loader. There are clearly discussion points here that could potentially influence the API.
>>>>> As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should!
>>>>> 
>>>>> Nick
>>>> 
>>>> 
>>>> On 9/1/13 1:16 AM, Nick Williams wrote:
>>>>> I have completed and am proposing a patch for replacing sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw no point in duplicating an issue, even though it's over 10 years old, so I'm indicating that this is a patch for 4851444 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444).
>>>>> 
>>>>> I welcome and solicit support/+1s and a sponsor. Someone about a month ago had mentioned that they would be willing to be a sponsor if the patch looked good, but I can't remember who it was and I can't find the email. I want to say it was someone with RedHat, but my memory could be faulty, so please don't hold it against me if I'm wrong.
>>>>> 
>>>>> *Summary of Changes*
>>>>> Added the new class java.lang.StackTraceFrame. It's a virtual mirror of StackTraceElement, except that it contains a Class declaringClass property instead of a String className property. Since the list members expressed reluctance to add methods to Thread and Throwable, StackTraceFrame also contains several static methods for retrieving Classes and StackTraceFrames from the stack. These methods are as follows:
>>>>> 
>>>>> Class getCallerClass(): Retrieves the class of the caller of the method calling getCallerClass(). This is identical to the new Reflection#getCallerClass() added in Java 7u25/8.
>>>>> 
>>>>> Class getCallerClass(int): Retrieves the class of the caller n frames down the stack. This is identical to the old Reflection#getCallerClass(int) that was deprecated in Java 7u25 and removed in Java 8.
>>>>> 
>>>>> StackTraceFrame getCallerFrame(): Retrieves the StackTraceFrame of the line of code that called the method calling getCallerClass(). This is similar to the new Reflection#getCallerClass() added in Java 7u25/8, except that it returns a StackTraceFrame.
>>>>> 
>>>>> StackTraceFrame getCallerFrame(int): Retrieves the StackTraceFrame of the caller n frames down the stack. This is similar to the old Reflection#getCallerClass(int), except that it returns a StackTraceFrame.
>>>>> 
>>>>> StackTraceFrame[] getCurrentStackTrace(): Functionally equivalent to Thread#getStackTrace(), except that it returns an array of StackTraceFrames.
>>>>> 
>>>>> StackTraceFrame[] getStackTrace(Throwable throwable): Functionally equivalent to Throwable#getStackTrace(), except that it returns an array of StackTraceFrames. It uses the same save point (backtrace) created when the Throwable is created that Throwable#getStackTrace() uses when it's first called. It caches the array of StackTraceFrames in the Throwable just like the array of StackTraceElements are cached, so that multiple calls for the same Throwable are fast.
>>>>> 
>>>>> As a result of this change, sun.reflect.CallerSensitive has been moved to java.lang.CallerSensitive.
>>>>> 
>>>>> I spent considerable time reviewing, revising, considering, and testing these changes. I included several unit tests that establish the proper behavior. I also spent considerable time benchmarking the changes. While benchmarking, I noticed some things. First, getCallerClass() and getCallerClass(int) are as fast as their counterparts in sun.reflect.Reflection, and they easily inline when appropriate. Second, getCallerFrame() and getCallerFrame(int) are /almost/ as fast as the Class versions, but there is some additional overhead for the construction of the StackTraceFrame. This is minuscule (1,000,000 invocations consume around 500 ms total on my machine). At this point, all of the benchmarking was as expected.
>>>>> 
>>>>> However, I then encountered a surprise. The getCurrentStackTrace() and getStackTrace(Throwable) methods executed (again, 1,000,000 times) in about 70% of the time that Thread#getStackTrace() and Throwable#getStackTrace() did, respectively. Theoretically, they should have executed in the same amount of time, not faster. After extensive analysis, I discovered (what I considered to be) a serious flaw in how the stack trace is filled in within Throwable (which also affects how Thread#getStackTrace() works).
>>>>> 
>>>>> Instead of simply iterating over the entire save point and filling in the Throwable stack trace in native code (which is what I did when I implemented the StackTraceFrame methods), the Java code in Throwable first called a native method to figure out how deep the stack was, then called another native method once for every frame in the stack to retrieve each element individually. This native method that is called repeatedly iterates over the entire backtrace once for each call, stopping only when it finds the matching element (so it's O(1) for the first call, O(2) for the second call, O(3) for the third call, and so on). While my StackTraceFrame methods were iterating over the backtrace exactly 1 time (O(n)), the Throwable methods were iterating over the backtrace 1+(n/2) times (worse than O(nlogn) but not as bad as O(n^2)). This problem would not have been extremely apparent over small stack traces (the 30% improvement was a stack trace of 6 elements), but over a large (200+ elements) stack traces the performance difference would be huge and noticeable. Seeing a room for improvement, I refactored the code that fills in the stack trace for Throwable, improving its performance accordingly to match the performance of the StackTraceFrame methods.
>>>>> 
>>>>> I'm very pleased with how this turned out, and both the unit tests and my extensive functional testing show that the new class and its methods are working great. I just need someone willing to review and sponsor my patch!
>>>>> 
>>>>> *The Code Changes*
>>>>> I couldn't get WebRev to run without all kinds of errors. So I ran `hg diff -g` on every repository in the forest with changes. Here are the four patch files for the four repositories that had changes (no other repositories had changes):
>>>>> 
>>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8.patch
>>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_jdk.patch
>>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_hotspot.patch
>>>>> https://java.nicholaswilliams.net/Java8GetCallerClass/jdk8_nashorn.patch
>>>>> 
>>>>> I believe I have followed all of the procedures as closely as possible. I await feedback and hope for some support on this, so that we can get a public replacement for this method in Java 8. Let me know if you have any questions.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Nick
>>>> 
> 
> 



From nicholas+openjdk at nicholaswilliams.net  Wed Sep 18 16:22:43 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 18 Sep 2013 11:22:43 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <5238C15F.4080408@oracle.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
Message-ID: <18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>

Okay. Again, sorry for my absence. This wraps up my feedback for now. I now await responses from Mandy.

On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:

> On 9/17/13 10:32 AM, cowwoc wrote:
>> Hi,
>> 
>>    Has this been any new progress on this thread? http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480
>> 
> 
> I have sent my feedback a couple weeks ago on this proposed patch but haven't heard back from Nick.
> 
> You asked at a good time.  I discussed this with John Rose last couple days on this topic.  He has been thinking about how to do fillInStackTrace performantly and walk the stack with laziness and frame filtering.  The current implementation fills the entire stack trace while Groovy and Log4j use case filters the frames of some specific classes until it reaches the first one not being filtered.
> 
> He suggests to consider an API taking a callback shape (e.g. Function, Consumer, etc) that Remi Forax suggested at one time that allows the JVM to do something.   I will work with John to work out the details and determine the interface between VM and library and hash out issues.
> 
> I like the callback shape idea and hope to work out a proposal soon.
> 
>> I'd like to second J?rn concerns that shipping JDK8 (less than a month to go!) without a fix would be extremely problematic. The performance impact would be huge and the difficulty of introducing a change would be far more difficult than doing it before JDK8 is out.
>> 
>>    How do we go about moving this forward?
>> 
> 
> This RFE is target for JDK 8 and my priority to get that in.  I'm well aware the impact to Groovy and Log4j and some other existing applications that are seeking for a replacement of Reflection.getCallerClass.
> 
> Mandy
> 
> 
> 



From mandy.chung at oracle.com  Wed Sep 18 16:28:57 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Sep 2013 09:28:57 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <055706FA-FD1D-4C1C-BB2F-7D479084793B@nicholaswilliams.net>
References: 
	<5226787F.6060307@oracle.com> <522DE112.4090905@oracle.com>
	
	<522E409A.6000502@oracle.com>
	<055706FA-FD1D-4C1C-BB2F-7D479084793B@nicholaswilliams.net>
Message-ID: <5239D4C9.6080903@oracle.com>


On 9/18/2013 9:20 AM, Nick Williams wrote:
> On Sep 9, 2013, at 4:41 PM, Mandy Chung wrote:
>
>> >On 9/9/13 10:02 AM, David Chase wrote:
>>> >>Take this lightly informed suggestion with a grain of salt, but why not, for purposes of performance and security,
>>> >>change the logging-specific getCallerClass methods so that their "class" references are instead wrapped in some sort of proxy object that only forwards certain operations quickly without a security check?  For example, equals, hashcode, and toString are probably not security-sensitive.
>> >
>> >Most of the information obtained from a class the use cases are interested in are security-sensitive information (e.g. protection domain, code source, class loader).
> Why?
>

That's the information Log4j wants to get once it gets a Class object.  
The methods getting protection domain, code source, class loader require 
permission check.

Mandy


From xueming.shen at oracle.com  Wed Sep 18 16:42:13 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 18 Sep 2013 09:42:13 -0700
Subject: RFR:  8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
In-Reply-To: <523980EF.6010208@oracle.com>
References: <5238CFB4.1040304@oracle.com> <523980EF.6010208@oracle.com>
Message-ID: <5239D7E5.6040803@oracle.com>

On 09/18/2013 03:31 AM, Alan Bateman wrote:
> On 17/09/2013 22:55, Xueming Shen wrote:
>> Hi,
>>
>> Please help the small update to the test case tools/jar/ChangeDir.java,
>> which might fail if the "dedicated" test directory /tmp/a exists and the
>> user does not have privilege to delete/clean it up.
>>
>> The proposed change here is to use a random file name (from File.getTempFile())
>> for the top test directory (instead of the fixed /tmp/a), and really clean it up
>> after testing (the old test leaves /tmp/a and those temp files undeleted).
>>
>> http://cr.openjdk.java.net/~sherman/8023113/webrev
> I've run into this a few times so thanks for fixing it.
>
> What you have is okay although some of the setup and cleanup could be reduced, for example doTest could setup the test tree with:
>
> Path topDir = Files.createTempDirectory("delete");
> Path testDir = Files.createDirectories(topDir.resolve("a").resolve("b"));
>
> It's not important for this fix of course, just an observation when looking at an old test.
>
thought about using the nio,  but then decided to keep the test as the classic "old" io,
otherwise I would end up with rewriting the test:-)

-Sherman

> -Alan.



From nicholas+openjdk at nicholaswilliams.net  Wed Sep 18 16:46:45 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Wed, 18 Sep 2013 11:46:45 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <5239D4C9.6080903@oracle.com>
References: 
	<5226787F.6060307@oracle.com> <522DE112.4090905@oracle.com>
	
	<522E409A.6000502@oracle.com>
	<055706FA-FD1D-4C1C-BB2F-7D479084793B@nicholaswilliams.net>
	<5239D4C9.6080903@oracle.com>
Message-ID: <522EC406-9E7D-4FB5-A782-3A6CE1AFE3B5@nicholaswilliams.net>


On Sep 18, 2013, at 11:28 AM, Mandy Chung wrote:

> 
> On 9/18/2013 9:20 AM, Nick Williams wrote:
>> On Sep 9, 2013, at 4:41 PM, Mandy Chung wrote:
>> 
>>> >On 9/9/13 10:02 AM, David Chase wrote:
>>>> >>Take this lightly informed suggestion with a grain of salt, but why not, for purposes of performance and security,
>>>> >>change the logging-specific getCallerClass methods so that their "class" references are instead wrapped in some sort of proxy object that only forwards certain operations quickly without a security check?  For example, equals, hashcode, and toString are probably not security-sensitive.
>>> >
>>> >Most of the information obtained from a class the use cases are interested in are security-sensitive information (e.g. protection domain, code source, class loader).
>> Why?
>> 
> 
> That's the information Log4j wants to get once it gets a Class object.  The methods getting protection domain, code source, class loader require permission check.

My "why" was "why do they require a permission check?" Why are these sensitive?

Nick

From paul.sandoz at oracle.com  Wed Sep 18 17:16:13 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 18 Sep 2013 10:16:13 -0700
Subject: RFR 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond
	to split() method if using an example from the spec
In-Reply-To: <5239C4CD.1060307@oracle.com>
References: 
	<5239C4CD.1060307@oracle.com>
Message-ID: <0AD3D9CB-F5CA-4BF6-930D-1B02733C68F6@oracle.com>


On Sep 18, 2013, at 8:20 AM, Alan Bateman  wrote:

> On 15/09/2013 17:27, Paul Sandoz wrote:
>> Hi,
>> 
>> http://cr.openjdk.java.net/~psandoz/tl/JDK-8024341-pattern-splitAsStream/webrev/
>> 
>> This fixes an issue with Pattern.splitAsStream reporting empty trailing elements and aligns with the functionality of Pattern.split(CharSequence input).
>> 
>> The matching iterator passed to the stream was updated to aggressively consume and keep a count of a sequence of empty matching elements such that those elements can either be reported if not trailing, or discarded if trailing.
>> 
>> Paul.
> It make sense to adjust the spec to have it consistent with split(CharSequence).
> 
> On the implementation then I had to read it a few times to understand how emptyElementCount is used. I wonder if it could be done in a simpler way, say just setting a flag when current reaches input.length? Maybe you have tried this already.
> 

The problem is when an empty matching element is encountered we don't know if it is trailing or not. This can only be determined when, later on, a non-empty matching element is encountered and/or there are no further matches. Thus we need to aggressively consume empty matching elements and retain how many have been encountered in case we need report them, for example, here is a particular test exercising this:

        description = "Many repeated separators before last match";
        input = "fooooo:";
        pattern = Pattern.compile("o");
        expected = new ArrayList<>();
        expected.add("f");
        expected.add("");
        expected.add("");
        expected.add("");
        expected.add("");
        expected.add(":");  // At this point we know the previously encountered matching empty elements need to be reported and not discarded 

I don't think it is practically possible in general to derive the number of empty elements from a start and end index since we don't know easily know the lengths of strings matched by the pattern in the input.


> On the test then you probably should include 8016846 in @bug tag as otherwise it looks like it was added specifically for 8024341.
> 

Thanks, updated. I wish there was a way to automate this by adding bug ids to meta-data to files in the repository. Any commit with tests would automatically update the test meta-data with the correspond bug id.

Paul.

From paul.sandoz at oracle.com  Wed Sep 18 18:27:24 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 18 Sep 2013 11:27:24 -0700
Subject: RFR 8025002 "".codePoints().sorted().iterator().hasNext() causes
	NegativeArraySizeException
Message-ID: <17A5552F-C992-459A-B821-E566AD8F7763@oracle.com>

Hi,

Please review a fix for CharSequence.codePoints:

  http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e040a0dda7e4

(That change set should apply cleanly to tl.)

The incorrect spliterator characteristics were being reported when constructing the stream. Specifically it should not report SIZED/SUBSIZED.

I added a quick test of the characteristics but we should probably add further tests using the stream test framework which would have most likely caught this error much earlier (since parallel evaluation should barf in certain cases). Plus there are more optimal impls that could be provided for String (even IIUC for codePoints if care is taken when splitting). All stuff to consider later on...

Paul.

From xueming.shen at oracle.com  Wed Sep 18 19:45:21 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 18 Sep 2013 12:45:21 -0700
Subject: RFR:  8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
In-Reply-To: <5239D7E5.6040803@oracle.com>
References: <5238CFB4.1040304@oracle.com> <523980EF.6010208@oracle.com>
	<5239D7E5.6040803@oracle.com>
Message-ID: <523A02D1.6090503@oracle.com>

OK, how about this one? I'm even using lambda:-)

http://cr.openjdk.java.net/~sherman/8023113/webrev/

-Sherman

On 09/18/2013 09:42 AM, Xueming Shen wrote:
> On 09/18/2013 03:31 AM, Alan Bateman wrote:
>> On 17/09/2013 22:55, Xueming Shen wrote:
>>> Hi,
>>>
>>> Please help the small update to the test case tools/jar/ChangeDir.java,
>>> which might fail if the "dedicated" test directory /tmp/a exists and the
>>> user does not have privilege to delete/clean it up.
>>>
>>> The proposed change here is to use a random file name (from File.getTempFile())
>>> for the top test directory (instead of the fixed /tmp/a), and really clean it up
>>> after testing (the old test leaves /tmp/a and those temp files undeleted).
>>>
>>> http://cr.openjdk.java.net/~sherman/8023113/webrev
>> I've run into this a few times so thanks for fixing it.
>>
>> What you have is okay although some of the setup and cleanup could be reduced, for example doTest could setup the test tree with:
>>
>> Path topDir = Files.createTempDirectory("delete");
>> Path testDir = Files.createDirectories(topDir.resolve("a").resolve("b"));
>>
>> It's not important for this fix of course, just an observation when looking at an old test.
>>
> thought about using the nio,  but then decided to keep the test as the classic "old" io,
> otherwise I would end up with rewriting the test:-)
>
> -Sherman
>
>> -Alan.
>



From henry.jen at oracle.com  Wed Sep 18 21:00:07 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 18 Sep 2013 14:00:07 -0700
Subject: RFR 8025002 "".codePoints().sorted().iterator().hasNext() causes
	NegativeArraySizeException
In-Reply-To: <17A5552F-C992-459A-B821-E566AD8F7763@oracle.com>
References: <17A5552F-C992-459A-B821-E566AD8F7763@oracle.com>
Message-ID: <2271A948-EDA5-4040-B062-AB9B04A8A5C5@oracle.com>

Looks good to me.

Cheers,
Henry


On Sep 18, 2013, at 11:27 AM, Paul Sandoz  wrote:

> Hi,
> 
> Please review a fix for CharSequence.codePoints:
> 
>  http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e040a0dda7e4
> 
> (That change set should apply cleanly to tl.)
> 
> The incorrect spliterator characteristics were being reported when constructing the stream. Specifically it should not report SIZED/SUBSIZED.
> 
> I added a quick test of the characteristics but we should probably add further tests using the stream test framework which would have most likely caught this error much earlier (since parallel evaluation should barf in certain cases). Plus there are more optimal impls that could be provided for String (even IIUC for codePoints if care is taken when splitting). All stuff to consider later on...
> 
> Paul.



From roger.riggs at oracle.com  Wed Sep 18 21:31:59 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 18 Sep 2013 17:31:59 -0400
Subject: Review java.time test refactoring
Message-ID: <523A1BCF.3030001@oracle.com>

A review of the TCK tests for java.time resulted in a number of changes
including refactoring the serialization tests into subpackages to follow 
JCK conventions,
discovery that a number of tests were missing for serialization, and cleanup
of the test code to utilize common test functions for testing serialization.
Thanks to the JCK folks for identifying the issues and doing some of the 
refactoring.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-serial-refactor-8024896/

  * JDK-8024896 
    Refactor java.time serialization tests into separate subpackage

  * JDK-8024427 
    Missing java.time.chrono serialization tests

Thanks, Roger



From philip.race at oracle.com  Wed Sep 18 22:22:32 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 18 Sep 2013 15:22:32 -0700
Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to
	build the class library on AIX
In-Reply-To: 
References: 
	
Message-ID: <523A27A8.404@oracle.com>

Volker,

I've skimmed the client related changes - mostly based on the descriptions.
I'll look in more detail as soon as I can after JavaOne. We also have some
engineers out on vacation who might want to look at these too.

A couple of things that stood out :
"On AIX, fontconfig is not a standard package supported by IBM."
I am surprised AIX does not support fontconfig.
That is something IBM should reconsider as its hard to imagine
a modern Unix based system working without it ..

Very basic start for AIX -  feel free to complete ..
  169  */
  170 static char *fullAixFontPath[] = {
...

I'd really like to see it completed but these days
that's largely a fall back for no fontconfig.

/* AIX does not provide the 'dladdr' function. But fortunately, we've
   42  * already implemented it in the HotSpot, because we need it there as
   43  * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}).

Whilst this is in "ifdef AIX" this reliance on an exported hotspot
function sounds hacky. What actual requirement is there that the
AIX class libraries be so tightly-coupled with that VM?
There is no contract there.

-phil.



On 9/16/2013 12:30 PM, Volker Simonis wrote:
> Resending this to more lists as requested by Alan Bateman with the 
> kind request to anybody to review the parts for which he feels 
> responsible:)
>
> For those not up to date, this change is part of the ongoing 
> PowerPC/AIX Porting Project:
> http://openjdk.java.net/projects/ppc-aix-port
> https://wiki.openjdk.java.net/display/PPCAIXPort
> http://openjdk.java.net/jeps/175
>
> Please send reviews to all currently included recipients.
>
> Thank you and best regards,
> Volker
>
>
> ---------- Forwarded message ----------
> From: *Volker Simonis*
> Date: Monday, September 16, 2013
> Subject: RFR(L): 8024854: Basic changes and files to build the class 
> library on AIX
> To: "ppc-aix-port-dev at openjdk.java.net 
> " 
>  >, Java Core Libs 
> >
>
>
>         Hi,
>
> could you please review the following webrev which contains the basic 
> changes and files needed in the 'jdk' repository in order to build the 
> OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854 
> 
>
> This change together with "8024265: Enable new build on AIX (jdk part) 
> " allows 
> it to configure and completely build the staging repository on AIX 5.3 
> and 7.1 with the following command:
>
> configure --with-boot-jdk= --with-jvm-variants=core 
> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include 
> --x-includes=/opt/freeware/include
>
> Below you can find the changes and additions I've done, sorted by 
> file. Most of them are just additions which are only active during the 
> AIX build anyway or simple changes where AIX has been added to 
> conditions which already check for Linux and/or Solaris. The files 
> with the biggest changes which you're probably want to look on more 
> thoroughly are 'src/solaris/native/java/net/NetworkInterface.c' and 
> 'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change 
> anything on the current OpenJDK platforms as well.
>
> Notice that there are still some files and some functionality missing 
> from the current change (notably NIO) but it still yields a running 
> JDK which can execute "HelloWorld" on the command line and as AWT 
> application. I've intentionally tried to keep this initial change as 
> simple as possible (with respect tot shared changes) in order to get 
> it reviewed as fast as possible. The missing parts can then be added 
> later on, grouped by logical topics, to simplify the review process.
>
> Thank you and best regards,
>
> Volker
>
>
>         src/share/bin/jli_util.h
>
>   * Define |JLI_Lseek| on AIX.
>
>
>         src/share/lib/security/java.security-aix
>
>   * Provide default |java.security-aix| for AIX.
>
>
>         src/share/native/sun/awt/medialib/mlib_sys.c
>
>   * |malloc| always returns 8-byte aligned pointers on AIX as well.
>
>
>         src/share/native/sun/awt/medialib/mlib_types.h
>
>   * Add AIX to the list of known platforms.
>
>
>         src/share/native/sun/font/layout/KernTable.cpp
>
>   * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
>     too common and may be defined in other headers as well as on the
>     command line and |xlc| bails out on macro redefinitions with a
>     different value.
>
>
>         src/share/native/sun/security/ec/impl/ecc_impl.h
>
>   * Define required types and macros on AIX.
>
>
>         src/solaris/back/exec_md.c
>
>   * AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
>
>         src/solaris/bin/java_md_solinux.c,
>         src/solaris/bin/java_md_solinux.h
>
>   * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>   * Always use |LD_LIBRARY_PATH| macro instead of using the string
>     "|LD_LIBRARY_PATH|" directly to cope with different library path
>     names.
>   * Add |jre/lib//jli| to the standard library search path on
>     AIX because the AIX linker doesn't support the |-rpath| option.
>   * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in
>     this case, AIX behaves like Linux.
>
>
>         src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>   * Provide basic |fontconfig.properties|for AIX.
>
>
>         src/solaris/classes/java/lang/UNIXProcess.java.aix,
>         src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
>         src/solaris/classes/sun/tools/attach/AixVirtualMachine.java
>
>   * Provide AIX specific Java versions, mostly based on the
>     corresponding Linux versions.
>
>
>         src/solaris/demo/jvmti/hprof/hprof_md.c
>
>   * Add AIX support. AIX mostly behaves like Linux, with the one
>     exception that it has no |dladdr| functionality.
>   * Implement |dladdr| functionality for AIX.
>
>
>         src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>   * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>
>
>         src/solaris/native/common/jdk_util_md.h
>
>   * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>
>
>         src/solaris/native/java/io/io_util_md.c
>
>   * AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
>
>         src/solaris/native/java/net/NetworkInterface.c
>
>   * Add AIX support into the Linux branch because AIX mostly behaves
>     like AIX for IPv4.
>   * AIX needs a special function to enumerate IPv6 interfaces and to
>     query the MAC address.
>
>
>         src/solaris/native/java/net/PlainSocketImpl.c
>
>   * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL|
>     if the socket is closed. The default error message is then confusing.
>
>
>         src/solaris/native/java/net/linux_close.c,
>         src/share/native/java/net/net_util.c
>
>   * Also use the file and socket wrappers on AIX.
>   * Add initialization of some previously uninitialized data structures.
>   * On AIX we don't have |__attribute((constructor))| so we need to
>     initialize manually (from |JNI_OnLoad()| in
>     'src/share/native/java/net/net_util.c'
>
>
>         src/solaris/native/java/net/net_util_md.h
>
>   * AIX needs the same workaround for I/O cancellation like Linux and
>     MacOSX.
>
>
>         src/solaris/native/java/util/TimeZone_md.c
>
>   * Currently on AIX the only way to get the platform time zone is to
>     read it from the |TZ| environment variable.
>
>
>         src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>   * There's no |dladdr| on AIX, but we can use the implementation from
>     the HotSpot in this case because |libjvm.so| will be always loaded
>     before the AWT.
>
>
>         src/solaris/native/sun/awt/fontpath.c
>
>   * Add AIX specific fontpath settings and library search paths for
>     |libfontconfig.so|.
>
>
>         src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>   * Only define |MIN| and |MAX| if they're not already defined because
>     xlc on AIX fails on macro redefinitions.
>
>
>         src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>   * Handle AIX like Solaris.
>
>
>         src/solaris/native/sun/nio/ch/Net.c
>
>   * Add AIX-specific includes and constant definitions.
>   * On AIX "socket extensions for multicast source filters" support
>     depends on the OS version. Check for this and throw appropriate
>     exceptions if it requested but not supported. This is needed to
>     pass
>     JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
>
>         src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>   * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>
>
>         src/solaris/native/sun/tools/attach/AixVirtualMachine.c
>
>   * AIX version mostly derived from the corresponding Linux version.
>
>



From henry.jen at oracle.com  Wed Sep 18 23:00:14 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 18 Sep 2013 16:00:14 -0700
Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log
	lambda code generation
In-Reply-To: <523994D1.8090200@redhat.com>
References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com>
Message-ID: <523A307E.6080202@oracle.com>

On 09/18/2013 04:56 AM, Florian Weimer wrote:
> On 09/18/2013 08:18 AM, Henry Jen wrote:
>> Hi,
>>
>> Please review the webrev at
>> http://cr.openjdk.java.net/~henryjen/ccc/8023524/0/webrev/
>>
>> This webrev enable writing generated classes for lambda to disk at a
>> directory specified with -Djdk.internal.lambda.dumpProxyClasses.
> 
> +   File out = new File(dirPath, lambdaClassName.replace('/', '.') +
> ".class");
> 
> Class names can contain '\' and other characters which are problematic
> on Windows.
> 

Thanks for reviewing, I suspect you are pointing out a potential issue
to look at, not that the problem exists in current implementation.

According to JLS 3.8, the classname(an identifier) can only have
letters, digits, plus '_' and '$'.

The '/' is converted from '.' earlier from, thus there won't be '\'
involved as separator.

Therefore, I think we are safe here.

Cheers,
Henry



From eric.mccorkle at oracle.com  Wed Sep 18 23:59:50 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 18 Sep 2013 19:59:50 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <523752F9.5050509@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
	<52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com>
	<523752F9.5050509@oracle.com>
Message-ID: <523A3E76.30307@oracle.com>

This still needs to be reviewed.

On 09/16/13 14:50, Eric McCorkle wrote:
> I pulled the class files into byte array constants, as a temporary
> measure until a viable method for testing bad class files is developed.
> 
> The webrev has been refreshed.  The class files will be taken out before
> I push.
> 
> http://cr.openjdk.java.net/~emc/8020981/
> 
> On 09/13/13 20:48, Joe Darcy wrote:
>> To avoid storing binaries in Hg, you could try something like:
>>
>> * uuencode / ascii armor the class file
>> * convert to byte array in the test
>> * load classes from byte array
>>
>> -Joe
>>
>> On 09/13/2013 11:54 AM, Eric McCorkle wrote:
>>> I did it by hand with emacs.
>>>
>>> I would really rather tackle the bad class files for testing issue once
>>> and for all, the Right Way (tm).  But with ZBB looming, now is not the
>>> time to do it.
>>>
>>> Hence, I have created this task
>>> https://bugs.openjdk.java.net/browse/JDK-8024674
>>>
>>> I also just created this one:
>>> https://bugs.openjdk.java.net/browse/JDK-8024812
>>>
>>> On 09/13/13 13:54, Peter Levart wrote:
>>>> Hi Eric,
>>>>
>>>> How did you create those class files? By hand using a HEX editor? Did
>>>> you create a program that patched the original class file? If the later
>>>> is the case, you could pack that patching logic inside a custom
>>>> ClassLoader...
>>>>
>>>> To hacky? Dependent on future changes of javac? At least the "bad name"
>>>> patching could be performed trivially and reliably, I think: search and
>>>> replace with same-length string.
>>>>
>>>> Regards, Peter
>>>>
>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>>>>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>>>>
>>>>> I have already filed a task for test development post ZBB to develop a
>>>>> solution for generating bad class files.  I'd prefer to file a
>>>>> follow-up
>>>>> to this to add the bad class file tests when that's done.
>>>>>
>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>>>>>> I think the right thing to do is to include the original compiling
>>>>>> source in a comment, together with a comment on how you modify
>>>>>> them, and then the result as a byte array.
>>>>>>
>>>>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>>>>
>>>>>> cheers
>>>>>> /Joel
>>>>>>
>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle
>>>>>>  wrote:
>>>>>>
>>>>>>> There is no simple means of generating bad class files for testing.
>>>>>>> This is a huge deficiency in our testing abilities.
>>>>>>>
>>>>>>> If these class files shouldn't go in, then I'm left with no choice
>>>>>>> but
>>>>>>> to check in no test for this patch.
>>>>>>>
>>>>>>> However, anyone can run the test I've provided with the class
>>>>>>> files and
>>>>>>> see that it works.
>>>>>>>
>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>>>>>> Hi Eric,
>>>>>>>>
>>>>>>>> IIRC we don't check in classfiles into the repo.
>>>>>>>>
>>>>>>>> I'm not sure how we handle testing of broken class-files in jdk,
>>>>>>>> but ASM might be an option, or storing the class file as an
>>>>>>>> embedded byte array in the test.
>>>>>>>>
>>>>>>>> cheers
>>>>>>>> /Joel
>>>>>>>>
>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> A new webrev is posted (and crucible updated), which actually
>>>>>>>>> validates
>>>>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>>>>
>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review this patch, which implements correct behavior for
>>>>>>>>>> the
>>>>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>>>>
>>>>>>>>>> The bug report is here:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>>>>
>>>>>>>>>> The webrev is here:
>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>>>>
>>>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>> 
>>

From christian.thalinger at oracle.com  Wed Sep 18 19:52:05 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 18 Sep 2013 12:52:05 -0700
Subject: RFR (S) 8001109: arity mismatch on a call to spreader method
	handle should elicit IllegalArgumentException
In-Reply-To: <74280088-19F3-4B0B-AC62-3332E9AED63A@oracle.com>
References: <74280088-19F3-4B0B-AC62-3332E9AED63A@oracle.com>
Message-ID: <25ACD0D6-FB63-41DB-9321-8CB2D982B993@oracle.com>

Looks good.

On Sep 12, 2013, at 6:02 PM, John Rose  wrote:

> Please review this change for a change to the JSR 292 implementation:
> 
> http://cr.openjdk.java.net/~jrose/8001109/webrev.00/
> 
> The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
> 
> In the RI, the exception-raising code is simplified to throw just IAE.
> 
> Thanks,
> ? John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From christian.thalinger at oracle.com  Thu Sep 19 00:05:09 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 18 Sep 2013 17:05:09 -0700
Subject: RFR (S) 8001108: an attempt to use "" as a method name
	should elicit NoSuchMethodException
In-Reply-To: <6FAC275C-6374-41F5-BAB7-CA1AC729EF9F@oracle.com>
References: <6FAC275C-6374-41F5-BAB7-CA1AC729EF9F@oracle.com>
Message-ID: <09F68115-21E6-450C-8DC2-6FCDB6C191B4@oracle.com>

src/share/classes/java/lang/invoke/MethodHandles.java:

+     * methods as if they were normal methods, but the JVM verifier rejects them.

I think you should say "JVM byte code verifier" here.

+         * (Note:  JVM internal methods named {@code } not visible to this API,
+         * even though the {@code invokespecial} instruction can refer to them
+         * in special circumstances.  Use {@link #findConstructor findConstructor}

Not exactly sure but should this read "are not visible"?

         MemberName resolveOrFail(byte refKind, Class refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException {
+            type.getClass();  // NPE
             checkSymbolicClass(refc);  // do this before attempting to resolve
-            name.getClass(); type.getClass();  // NPE
+            checkMethodName(refKind, name);

Could you add a comment here saying that checkMethodName does an implicit null pointer check on name?  Maybe a comment for checkMethodName too.

What was the problem with the null pointer exceptions?  Is it okay that we might throw another exception before null checking name?

On Sep 12, 2013, at 6:47 PM, John Rose  wrote:

> Please review this change for a change to the JSR 292 implementation:
> 
> http://cr.openjdk.java.net/~jrose/8001108/webrev.00
> 
> Summary: add an explicit check for leading "<", upgrade the unit tests
> 
> The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
> 
> In the RI, there is an explicit error check.
> 
> Thanks,
> ? John
> 
> P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
> Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From bhavesh.x.patel at oracle.com  Thu Sep 19 00:14:39 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 19 Sep 2013 00:14:39 +0000
Subject: hg: jdk8/tl/langtools: 8015249: javadoc fails to document static
	final fields in annotation types
Message-ID: <20130919001444.EDE5062920@hg.openjdk.java.net>

Changeset: a2a5ad0853ed
Author:    bpatel
Date:      2013-09-18 17:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a2a5ad0853ed

8015249: javadoc fails to document static final fields in annotation types
Reviewed-by: jjg

+ src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeFieldWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeFieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java
+ test/com/sun/javadoc/testAnnotationTypes/pkg/AnnotationTypeField.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java



From david.holmes at oracle.com  Thu Sep 19 04:11:31 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Sep 2013 14:11:31 +1000
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <523A3E76.30307@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
	<52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com>
	<523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com>
Message-ID: <523A7973.4010909@oracle.com>

On 19/09/2013 9:59 AM, Eric McCorkle wrote:
> This still needs to be reviewed.

You seem to have ignored Joe's comments regarding the change to Modifier 
being incorrect.

David

> On 09/16/13 14:50, Eric McCorkle wrote:
>> I pulled the class files into byte array constants, as a temporary
>> measure until a viable method for testing bad class files is developed.
>>
>> The webrev has been refreshed.  The class files will be taken out before
>> I push.
>>
>> http://cr.openjdk.java.net/~emc/8020981/
>>
>> On 09/13/13 20:48, Joe Darcy wrote:
>>> To avoid storing binaries in Hg, you could try something like:
>>>
>>> * uuencode / ascii armor the class file
>>> * convert to byte array in the test
>>> * load classes from byte array
>>>
>>> -Joe
>>>
>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote:
>>>> I did it by hand with emacs.
>>>>
>>>> I would really rather tackle the bad class files for testing issue once
>>>> and for all, the Right Way (tm).  But with ZBB looming, now is not the
>>>> time to do it.
>>>>
>>>> Hence, I have created this task
>>>> https://bugs.openjdk.java.net/browse/JDK-8024674
>>>>
>>>> I also just created this one:
>>>> https://bugs.openjdk.java.net/browse/JDK-8024812
>>>>
>>>> On 09/13/13 13:54, Peter Levart wrote:
>>>>> Hi Eric,
>>>>>
>>>>> How did you create those class files? By hand using a HEX editor? Did
>>>>> you create a program that patched the original class file? If the later
>>>>> is the case, you could pack that patching logic inside a custom
>>>>> ClassLoader...
>>>>>
>>>>> To hacky? Dependent on future changes of javac? At least the "bad name"
>>>>> patching could be performed trivially and reliably, I think: search and
>>>>> replace with same-length string.
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>>>>>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>>>>>
>>>>>> I have already filed a task for test development post ZBB to develop a
>>>>>> solution for generating bad class files.  I'd prefer to file a
>>>>>> follow-up
>>>>>> to this to add the bad class file tests when that's done.
>>>>>>
>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>>>>>>> I think the right thing to do is to include the original compiling
>>>>>>> source in a comment, together with a comment on how you modify
>>>>>>> them, and then the result as a byte array.
>>>>>>>
>>>>>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>>>>>
>>>>>>> cheers
>>>>>>> /Joel
>>>>>>>
>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> There is no simple means of generating bad class files for testing.
>>>>>>>> This is a huge deficiency in our testing abilities.
>>>>>>>>
>>>>>>>> If these class files shouldn't go in, then I'm left with no choice
>>>>>>>> but
>>>>>>>> to check in no test for this patch.
>>>>>>>>
>>>>>>>> However, anyone can run the test I've provided with the class
>>>>>>>> files and
>>>>>>>> see that it works.
>>>>>>>>
>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>>>>>>> Hi Eric,
>>>>>>>>>
>>>>>>>>> IIRC we don't check in classfiles into the repo.
>>>>>>>>>
>>>>>>>>> I'm not sure how we handle testing of broken class-files in jdk,
>>>>>>>>> but ASM might be an option, or storing the class file as an
>>>>>>>>> embedded byte array in the test.
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>> /Joel
>>>>>>>>>
>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> A new webrev is posted (and crucible updated), which actually
>>>>>>>>>> validates
>>>>>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>>>>>
>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review this patch, which implements correct behavior for
>>>>>>>>>>> the
>>>>>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>>>>>
>>>>>>>>>>> The bug report is here:
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>>>>>
>>>>>>>>>>> The webrev is here:
>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>>>>>
>>>>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Eric
>>>>>>>>>>>
>>>>>>>> 
>>>


From bhavesh.x.patel at oracle.com  Thu Sep 19 05:47:32 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 19 Sep 2013 05:47:32 +0000
Subject: hg: jdk8/tl/langtools: 8024096: some javadoc tests may contain false
	positive results
Message-ID: <20130919054739.11EF662932@hg.openjdk.java.net>

Changeset: 8df12c315ea3
Author:    bpatel
Date:      2013-09-18 22:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8df12c315ea3

8024096: some javadoc tests may contain false positive results
Reviewed-by: jjg

! test/com/sun/javadoc/lib/JavadocTester.java
! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java
! test/com/sun/javadoc/testEncoding/EncodeTest.java
! test/com/sun/javadoc/testEncoding/TestEncoding.java
! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java



From fweimer at redhat.com  Thu Sep 19 07:27:32 2013
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 19 Sep 2013 09:27:32 +0200
Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log
	lambda code generation
In-Reply-To: <523A307E.6080202@oracle.com>
References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com>
	<523A307E.6080202@oracle.com>
Message-ID: <523AA764.60301@redhat.com>

On 09/19/2013 01:00 AM, Henry Jen wrote:

>> Class names can contain '\' and other characters which are problematic
>> on Windows.

> Thanks for reviewing, I suspect you are pointing out a potential issue
> to look at, not that the problem exists in current implementation.
>
> According to JLS 3.8, the classname(an identifier) can only have
> letters, digits, plus '_' and '$'.

You need to look at the JVM specification, there are only very few 
characters it excludes.  The restrictions come from javac, not the JVM. 
  For example, on Linux, "java '\'" will load a \.class file and run it 
(yes, I tried).

-- 
Florian Weimer / Red Hat Product Security Team


From forax at univ-mlv.fr  Thu Sep 19 07:48:11 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 19 Sep 2013 09:48:11 +0200
Subject: RFR: 8023524: Mechanism to dump generated lambda classes / log
	lambda code generation
In-Reply-To: <523AA764.60301@redhat.com>
References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com>
	<523A307E.6080202@oracle.com> <523AA764.60301@redhat.com>
Message-ID: <523AAC3B.5080903@univ-mlv.fr>

On 09/19/2013 09:27 AM, Florian Weimer wrote:
> On 09/19/2013 01:00 AM, Henry Jen wrote:
>
>>> Class names can contain '\' and other characters which are problematic
>>> on Windows.
>
>> Thanks for reviewing, I suspect you are pointing out a potential issue
>> to look at, not that the problem exists in current implementation.
>>
>> According to JLS 3.8, the classname(an identifier) can only have
>> letters, digits, plus '_' and '$'.
>
> You need to look at the JVM specification, there are only very few 
> characters it excludes.  The restrictions come from javac, not the 
> JVM.  For example, on Linux, "java '\'" will load a \.class file and 
> run it (yes, I tried).
>

There is a nice blog post about that:
https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm

R?mi



From Alan.Bateman at oracle.com  Thu Sep 19 08:37:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Sep 2013 09:37:34 +0100
Subject: RFR 8025002 "".codePoints().sorted().iterator().hasNext() causes
	NegativeArraySizeException
In-Reply-To: <17A5552F-C992-459A-B821-E566AD8F7763@oracle.com>
References: <17A5552F-C992-459A-B821-E566AD8F7763@oracle.com>
Message-ID: <523AB7CE.3040606@oracle.com>

On 18/09/2013 19:27, Paul Sandoz wrote:
> Hi,
>
> Please review a fix for CharSequence.codePoints:
>
>    http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e040a0dda7e4
>
> (That change set should apply cleanly to tl.)
>
> The incorrect spliterator characteristics were being reported when constructing the stream. Specifically it should not report SIZED/SUBSIZED.
>
> I added a quick test of the characteristics but we should probably add further tests using the stream test framework which would have most likely caught this error much earlier (since parallel evaluation should barf in certain cases). Plus there are more optimal impls that could be provided for String (even IIUC for codePoints if care is taken when splitting). All stuff to consider later on...
>
> Paul.
It is easy to get the characteristics wrong (or maybe this one was 
copied down from the chars methods). The change looks good to me.

-Alan.


From Alan.Bateman at oracle.com  Thu Sep 19 08:52:52 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Sep 2013 09:52:52 +0100
Subject: RFR:  8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
In-Reply-To: <523A02D1.6090503@oracle.com>
References: <5238CFB4.1040304@oracle.com> <523980EF.6010208@oracle.com>
	<5239D7E5.6040803@oracle.com> <523A02D1.6090503@oracle.com>
Message-ID: <523ABB64.8080309@oracle.com>

On 18/09/2013 20:45, Xueming Shen wrote:
> OK, how about this one? I'm even using lambda:-)
>
> http://cr.openjdk.java.net/~sherman/8023113/webrev/
>
> -Sherman
Looks okay except that Files.list returns a stream that needs to be 
closed to avoid leaking resources.

As a side note, as cleanup is attempting to delete a file tree then you 
could eliminate the recursion by using Files.walkFileTree with the 
directories removed in the postVisitDirectory method. It might be 
tempting to use the new walk method but it returns each directory before 
its entries and so isn't appropriate for recursive ops where you need to 
do touch the directory after its entries. I'm not suggesting spending 
any more time on this test of course, you've done more than enough.

-Alan.


From rieberandreas at gmail.com  Thu Sep 19 10:10:41 2013
From: rieberandreas at gmail.com (Andreas Rieber)
Date: Thu, 19 Sep 2013 12:10:41 +0200
Subject: Review request for 8011697: ScriptEngine "js" randomly means either
	"rhino" or "nashorn", but should instead select one
In-Reply-To: <523A9FF3.8080809@gmail.com>
References: <523A95F5.4040103@gmail.com> <523A9B13.2090603@oracle.com>
	<523A9FF3.8080809@gmail.com>
Message-ID: <523ACDA1.7080303@gmail.com>

Hi,

the HashSet used for the script engine factories caused the random 
behaviour.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8011697

Webrev:
http://cr.openjdk.java.net/~arieber/8011697/webrev.01/

Please review and sponsor required...

thanks
Andreas


On 19.09.2013 08:55, Andreas Rieber wrote:
> Hi Sundar,
>
> On 19.09.2013 08:34, A. Sundararajan wrote:
>> Hi,
>>
>> Few comments on this:
>>
>> 1) This is a JDK repo (where javax.script lives) change and so 
>> core-libs-dev review is needed
> will do that (when i have 3).
>
>> 2) Not sure if it affects any word on spec. - need to go through spec 
>> + javadoc comments closely
> I checked the javadoc, there is nothing mentioned about the internal 
> implementation of the script engine factories. So this should be fine.
>
>> 3) You need a test that demonstrates that order is preserved
> I will try to setup a test with your sample script engine attached to 
> the issue.
>
>>
>> Hope this helps,
>> -Sundar
> thanks
> Andreas
>
>>
>> On Thursday 19 September 2013 11:43 AM, Andreas Rieber wrote:
>>> Hi,
>>>
>>> the HashSet used for the script engine factories caused the random 
>>> behaviour.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8011697
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~arieber/8011697/webrev.00/
>>>
>>> Please review and sponsor required...
>>>
>>> thanks
>>> Andreas
>>>
>>
>



From volker.simonis at gmail.com  Thu Sep 19 11:29:33 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 19 Sep 2013 13:29:33 +0200
Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to
	build the class library on AIX
In-Reply-To: <523A27A8.404@oracle.com>
References: 
	
	<523A27A8.404@oracle.com>
Message-ID: 

Hi Phil,

thank you for looking at the changes. Please find my answers inline:


On Thu, Sep 19, 2013 at 12:22 AM, Phil Race  wrote:

> Volker,
>
> I've skimmed the client related changes - mostly based on the descriptions.
> I'll look in more detail as soon as I can after JavaOne. We also have some
> engineers out on vacation who might want to look at these too.
>
> A couple of things that stood out :
> "On AIX, fontconfig is not a standard package supported by IBM."
> I am surprised AIX does not support fontconfig.
> That is something IBM should reconsider as its hard to imagine
> a modern Unix based system working without it ..
>

I totally agree, but this is an OpenJDK port not a AIX renovation:)

That said, IBM offers fontconfig packages from a special "AIX Toolbox for
Linux Applications" OpenSource site. But these OpenSource packages are not
supported and users have to install them manually (i.e. they are not part
of the standard installation images and you can not rely on them beeing
installed).


>
> Very basic start for AIX -  feel free to complete ..
>  169  */
>  170 static char *fullAixFontPath[] = {
> ...
>

I'd really like to see it completed but these days
> that's largely a fall back for no fontconfig.
>
>
Again, this can get quite complicated and AIX-version dependent. I think
the provided list is a good starting point.


> /* AIX does not provide the 'dladdr' function. But fortunately, we've
>   42  * already implemented it in the HotSpot, because we need it there as
>   43  * well (see hotspot/src/os/aix/vm/porting_**aix.{hpp,cpp}).
>
> Whilst this is in "ifdef AIX" this reliance on an exported hotspot
> function sounds hacky. What actual requirement is there that the
> AIX class libraries be so tightly-coupled with that VM?
> There is no contract there.
>
>
You're right, there is no contract. It's just pragmatic solution and I
think it should always work because the libjvm will always be loaded at the
point in AWT where it is used. Another solution would be to re-implement
the functionality in the class library and I don't like code duplication
either.


> -phil.
>
>
>
>
> On 9/16/2013 12:30 PM, Volker Simonis wrote:
>
>> Resending this to more lists as requested by Alan Bateman with the kind
>> request to anybody to review the parts for which he feels responsible:)
>>
>> For those not up to date, this change is part of the ongoing PowerPC/AIX
>> Porting Project:
>> http://openjdk.java.net/**projects/ppc-aix-port
>> https://wiki.openjdk.java.net/**display/PPCAIXPort
>> http://openjdk.java.net/jeps/**175 
>>
>> Please send reviews to all currently included recipients.
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> ---------- Forwarded message ----------
>> From: *Volker Simonis*
>> Date: Monday, September 16, 2013
>> Subject: RFR(L): 8024854: Basic changes and files to build the class
>> library on AIX
>> To: "ppc-aix-port-dev at openjdk.**java.net> ppc-aix-port-dev@**openjdk.java.net >"
>> > ppc-aix-port-dev@**openjdk.java.net >>,
>> Java Core Libs > core-libs-dev at openjdk.**java.net >>
>>
>>
>>         Hi,
>>
>> could you please review the following webrev which contains the basic
>> changes and files needed in the 'jdk' repository in order to build the
>> OpenJDK on AIX:
>>
>> http://cr.openjdk.java.net/~**simonis/webrevs/8024854<
>> http://cr.openjdk.java.net/%**7Esimonis/webrevs/8024854
>> >
>>
>> This change together with "8024265: Enable new build on AIX (jdk part) <
>> http://cr.openjdk.java.net/%**7Esimonis/webrevs/8024265_jdk/
>> **>" allows it to configure and completely build the staging repository
>> on AIX 5.3 and 7.1 with the following command:
>>
>>
>> configure --with-boot-jdk= --with-jvm-variants=core
>> --with-jvm-interpreter=cpp --with-cups-include=/opt/**freeware/include
>> --x-includes=/opt/freeware/**include
>>
>> Below you can find the changes and additions I've done, sorted by file.
>> Most of them are just additions which are only active during the AIX build
>> anyway or simple changes where AIX has been added to conditions which
>> already check for Linux and/or Solaris. The files with the biggest changes
>> which you're probably want to look on more thoroughly are
>> 'src/solaris/native/java/net/**NetworkInterface.c' and
>> 'src/solaris/native/sun/nio/**ch/Net.c' altough they shouldn't change
>> anything on the current OpenJDK platforms as well.
>>
>> Notice that there are still some files and some functionality missing
>> from the current change (notably NIO) but it still yields a running JDK
>> which can execute "HelloWorld" on the command line and as AWT application.
>> I've intentionally tried to keep this initial change as simple as possible
>> (with respect tot shared changes) in order to get it reviewed as fast as
>> possible. The missing parts can then be added later on, grouped by logical
>> topics, to simplify the review process.
>>
>> Thank you and best regards,
>>
>> Volker
>>
>>
>>         src/share/bin/jli_util.h
>>
>>   * Define |JLI_Lseek| on AIX.
>>
>>
>>         src/share/lib/security/java.**security-aix
>>
>>   * Provide default |java.security-aix| for AIX.
>>
>>
>>         src/share/native/sun/awt/**medialib/mlib_sys.c
>>
>>   * |malloc| always returns 8-byte aligned pointers on AIX as well.
>>
>>
>>         src/share/native/sun/awt/**medialib/mlib_types.h
>>
>>   * Add AIX to the list of known platforms.
>>
>>
>>         src/share/native/sun/font/**layout/KernTable.cpp
>>
>>   * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
>>
>>     too common and may be defined in other headers as well as on the
>>     command line and |xlc| bails out on macro redefinitions with a
>>     different value.
>>
>>
>>         src/share/native/sun/security/**ec/impl/ecc_impl.h
>>
>>   * Define required types and macros on AIX.
>>
>>
>>         src/solaris/back/exec_md.c
>>
>>   * AIX behaves like Linux in this case so check for it in the Linux
>>     branch.
>>
>>
>>         src/solaris/bin/java_md_**solinux.c,
>>         src/solaris/bin/java_md_**solinux.h
>>
>>   * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>>   * Always use |LD_LIBRARY_PATH| macro instead of using the string
>>
>>     "|LD_LIBRARY_PATH|" directly to cope with different library path
>>     names.
>>   * Add |jre/lib//jli| to the standard library search path on
>>
>>     AIX because the AIX linker doesn't support the |-rpath| option.
>>   * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in
>>
>>     this case, AIX behaves like Linux.
>>
>>
>>         src/solaris/classes/sun/awt/**fontconfigs/aix.fontconfig.**
>> properties
>>
>>   * Provide basic |fontconfig.properties|for AIX.
>>
>>
>>         src/solaris/classes/java/lang/**UNIXProcess.java.aix,
>>         src/solaris/classes/sun/tools/**attach/AixAttachProvider.java,
>>         src/solaris/classes/sun/tools/**attach/AixVirtualMachine.java
>>
>>   * Provide AIX specific Java versions, mostly based on the
>>     corresponding Linux versions.
>>
>>
>>         src/solaris/demo/jvmti/hprof/**hprof_md.c
>>
>>   * Add AIX support. AIX mostly behaves like Linux, with the one
>>
>>     exception that it has no |dladdr| functionality.
>>   * Implement |dladdr| functionality for AIX.
>>
>>
>>         src/solaris/native/com/sun/**management/**
>> UnixOperatingSystem_md.c
>>
>>   * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>>
>>
>>         src/solaris/native/common/jdk_**util_md.h
>>
>>   * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>>
>>
>>         src/solaris/native/java/io/io_**util_md.c
>>
>>   * AIX behaves like Linux in this case so check for it in the Linux
>>     branch.
>>
>>
>>         src/solaris/native/java/net/**NetworkInterface.c
>>
>>   * Add AIX support into the Linux branch because AIX mostly behaves
>>     like AIX for IPv4.
>>   * AIX needs a special function to enumerate IPv6 interfaces and to
>>
>>     query the MAC address.
>>
>>
>>         src/solaris/native/java/net/**PlainSocketImpl.c
>>
>>   * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL|
>>
>>     if the socket is closed. The default error message is then confusing.
>>
>>
>>         src/solaris/native/java/net/**linux_close.c,
>>         src/share/native/java/net/net_**util.c
>>
>>   * Also use the file and socket wrappers on AIX.
>>   * Add initialization of some previously uninitialized data structures.
>>   * On AIX we don't have |__attribute((constructor))| so we need to
>>
>>     initialize manually (from |JNI_OnLoad()| in
>>     'src/share/native/java/net/**net_util.c'
>>
>>
>>         src/solaris/native/java/net/**net_util_md.h
>>
>>   * AIX needs the same workaround for I/O cancellation like Linux and
>>     MacOSX.
>>
>>
>>         src/solaris/native/java/util/**TimeZone_md.c
>>
>>   * Currently on AIX the only way to get the platform time zone is to
>>
>>     read it from the |TZ| environment variable.
>>
>>
>>         src/solaris/native/sun/awt/**awt_LoadLibrary.c
>>
>>   * There's no |dladdr| on AIX, but we can use the implementation from
>>
>>     the HotSpot in this case because |libjvm.so| will be always loaded
>>     before the AWT.
>>
>>
>>         src/solaris/native/sun/awt/**fontpath.c
>>
>>   * Add AIX specific fontpath settings and library search paths for
>>     |libfontconfig.so|.
>>
>>
>>         src/solaris/native/sun/java2d/**x11/X11SurfaceData.c
>>
>>   * Only define |MIN| and |MAX| if they're not already defined because
>>
>>     xlc on AIX fails on macro redefinitions.
>>
>>
>>         src/solaris/native/sun/java2d/**x11/XRBackendNative.c
>>
>>   * Handle AIX like Solaris.
>>
>>
>>         src/solaris/native/sun/nio/ch/**Net.c
>>
>>   * Add AIX-specific includes and constant definitions.
>>   * On AIX "socket extensions for multicast source filters" support
>>
>>     depends on the OS version. Check for this and throw appropriate
>>     exceptions if it requested but not supported. This is needed to
>>     pass
>>     JCK-api/java_nio/channels/**DatagramChannel/**
>> DatagramChannel.html#Multicast
>>
>>
>>         src/solaris/native/sun/**security/pkcs11/j2secmod_md.c
>>
>>   * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>>
>>
>>         src/solaris/native/sun/tools/**attach/AixVirtualMachine.c
>>
>>   * AIX version mostly derived from the corresponding Linux version.
>>
>>
>>
>


From peter.levart at gmail.com  Thu Sep 19 12:03:31 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Sep 2013 14:03:31 +0200
Subject: Replacement of sun.reflect.Reflection#getCallerClass
In-Reply-To: <5239C50B.7080300@redhat.com>
References: 
	<522551AE.7060000@oracle.com>
	
	<5225F268.2000707@oracle.com>
	<7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net>
	<5226197F.1050301@gmail.com> <5239C50B.7080300@redhat.com>
Message-ID: <523AE813.6070900@gmail.com>

On 09/18/2013 05:21 PM, David M. Lloyd wrote:
> On 09/03/2013 12:16 PM, Peter Levart wrote:
> [...]
>> *AND* that Reflection.getCallerClass() can only be called from within
>>  methods annotated with @CallerSensitive.
>>
>> Now for that part, the public API equivalent
>> (StackTraceFrame.getCallerClass() or whatever it is called) need not
>> be restricted to methods annotated with any annotation, but that
>> means that this public API should not be used to implement security
>> decisions since MethodHandles API allows caller to be spoofed unless
>> looking-up a method annotated with @CallerSensitive...
>
> Peter, can you please elaborate on this a bit?  I could find nothing 
> in the MethodHandles API or its associated classes that would seem to 
> give the ability to call another method with a spoofed caller.  Yes 
> you can set up a Lookup for another class but I don't see how that 
> would affect the ability of (say) a security manager to make access 
> decisions based on the call stack/class context?
>

Hi David,

The thing with method handles is that they perform all security checks 
not at invoke-time (like reflection), but at lookup-time. If you have a 
hold on a MethodHandle object, you can always invoke it. All security 
checks must have been performed at lookup-time. This includes security 
checks that are based on what the "caller" of the method is. In case of 
method handles, the "caller" is the class associated with the Lookup 
object - the lookup class.

Try this example:

// --- the following be loaded by the bootstrap class loader
package sys;

import sun.reflect.CallerSensitive;
import sun.reflect.Reflection;

import java.lang.invoke.MethodHandles;

public class CSUtil
{
     public static final MethodHandles.Lookup lookup = 
MethodHandles.lookup();

     @CallerSensitive
     public static void printCallerClassLoader(String prefix) {
         Class cc = Reflection.getCallerClass();
         System.err.println(prefix + ":\n  "
                            + cc + "\n  loaded by "
                            + cc.getClassLoader() + "\n");
     }

     public static class Nested {}
}


// ---the following be loaded by application class loader
package usr;

import sys.CSUtil;

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

public class CSTest
{
     public static final MethodHandles.Lookup lookup = 
MethodHandles.lookup();

     public static void main(String[] args) throws Throwable
     {
         MethodHandle mh1  = CSTest.lookup.findStatic(
             CSUtil.class,
             "printCallerClassLoader",
             MethodType.methodType(void.class, String.class)
         );

         mh1.invokeExact("mh1");

         MethodHandle mh2  = CSUtil.lookup.findStatic(
             CSUtil.class,
             "printCallerClassLoader",
             MethodType.methodType(void.class, String.class)
         );

         mh2.invokeExact("mh2");

         MethodHandle mh3  = 
CSUtil.lookup.in(CSUtil.Nested.class).findStatic(
             CSUtil.class,
             "printCallerClassLoader",
             MethodType.methodType(void.class, String.class)
         );

         mh3.invokeExact("mh3");

         MethodHandle mh4  = CSUtil.lookup.in(CSTest.class).findStatic(
             CSUtil.class,
             "printCallerClassLoader",
             MethodType.methodType(void.class, String.class)
         );

         mh4.invokeExact("mh4");
     }
}


...which prints:

mh1:
   class java.lang.invoke.MethodHandleImpl$BindCaller$T/523429237
   loaded by sun.misc.Launcher$AppClassLoader at 15db9742

mh2:
   class java.lang.invoke.MethodHandleImpl$BindCaller$T/1450495309
   loaded by null

mh3:
   class java.lang.invoke.MethodHandleImpl$BindCaller$T/2001049719
   loaded by null

Exception in thread "main" java.lang.IllegalAccessException: Attempt to 
lookup caller-sensitive method using restricted lookup object
     at 
java.lang.invoke.MethodHandles$Lookup.findBoundCallerClass(MethodHandles.java:1123)
     at 
java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:619)
     at usr.CSTest.main(CSTest.java:39)


You can see that the "caller" class it not actually the class doing 
lookup, but some anonymous class which is loaded by the same class 
loader as the lookup class and maybe it shares some other properties 
with it (it seems that this is sufficient for security checks). The mh3 
is interesting in that the "caller" is different from that of mh2. The 
Lookup.in(Class) method returns a Lookup object with different lookup 
class and so the "caller" class is different too. Although the 
printCallerClassLoader is a public method in a public class, the mh4 can 
not be looked-up, because this could be used to "spoof" the caller class 
loader for any such public method. Imagine:


         // this throws IllegalAccessException. If it didn't...
         MethodHandle mh = MethodHandles.lookup()
             .in(String.class)
             .findVirtual(
                 Field.class,
                 "get",
                 MethodType.methodType(Object.class, Object.class)
             );

         Field valueField = String.class.getDeclaredField("value");

         String abc = "abc";

         // ... then the following would invoke: valueField.get(abc) and 
pretend that
         // it was invoked from the String class, which would succeed...
         char[] abcArray = (char[])(Object) mh.invokeExact(valueField, 
(Object) abc);

         // ...and you could observe the following:
         abcArray[0] = 'A';
         assert abc.charAt(0) == 'A';



Regards, Peter



From kasperni at gmail.com  Thu Sep 19 12:05:31 2013
From: kasperni at gmail.com (Kasper Nielsen)
Date: Thu, 19 Sep 2013 14:05:31 +0200
Subject: java.lang.reflect.Parameter comments
In-Reply-To: <522FB555.9040009@oracle.com>
References: 
	<522FB555.9040009@oracle.com>
Message-ID: 

Sorry for the late reply,

On 8/25/2013 7:03 AM, Kasper Nielsen wrote:
>
>> Hi,
>>
>> just 2 short questions/commons on java.lang.reflect.Parameter
>>
>> 1)
>> I was wondering if there is any reason for java.lang.reflect.Parameter not
>> to expose the index field?
>>
>
> "Not sure what you mean by the "index field", but if you mean the
> name_index item in the MethodParameters attribute, then it is possible to
> know whether it's zero by calling Parameter#isNamePresent."
>
>
I'm talking about the "index field" as in
java.lang.reflect.Parameter.index, the field that indicates which parameter
you "are" if you call parameter.getDeclaringExecutable().getParameters().
I have a couple of places where I have to include the index when passing a
parameter around. Instead of just being able to call parameter.getIndex().
A simple getter should do

public int getIndex() {
   return index;
}



> "Yes and no. First, the historic use of getGenericXXX in java.lang.reflect
> is wrong (it should be getParameterizedXXX) but it can't be changed now.
> The Language Model API in javax.lang.model.** is much better with
> terminology. Second, when we add methods to existing java.lang.reflect
> types, we hold our noses and use "Generic" for consistency, e.g., the new
> AnnotatedArrayType interface for type annotations has a method
> getAnnotatedGenericComponentTy**pe that is consistent with the
> getGenericComponentType method in GenericArrayType. Third, when we add new
> types to java.lang.reflect, we use the correct terminology, hence Parameter#
> **getParameterizedType."
>
> Thanks for explanation.


- Kasper


From alexander.zuev at oracle.com  Thu Sep 19 13:06:11 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Thu, 19 Sep 2013 13:06:11 +0000
Subject: hg: jdk8/tl/langtools: 8017248: Compiler Diacritics Issue
Message-ID: <20130919130614.CA5CB62947@hg.openjdk.java.net>

Changeset: 36e342dd57e2
Author:    kizune
Date:      2013-09-19 17:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36e342dd57e2

8017248: Compiler Diacritics Issue
Reviewed-by: naoto

! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java



From alexander.zuev at oracle.com  Thu Sep 19 13:07:17 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Thu, 19 Sep 2013 13:07:17 +0000
Subject: hg: jdk8/tl/jdk: 8017248: Compiler Diacritics Issue
Message-ID: <20130919130827.594B262948@hg.openjdk.java.net>

Changeset: 22e9f0067b5a
Author:    kizune
Date:      2013-09-19 17:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22e9f0067b5a

8017248: Compiler Diacritics Issue
Reviewed-by: naoto

! src/share/classes/sun/launcher/LauncherHelper.java
+ test/tools/launcher/8017248/ClassA??.java
+ test/tools/launcher/8017248/test.sh



From philip.race at oracle.com  Thu Sep 19 13:53:35 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 19 Sep 2013 06:53:35 -0700
Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to
	build the class library on AIX
In-Reply-To: 
References: 
	
	<523A27A8.404@oracle.com>
	
Message-ID: <523B01DF.1030902@oracle.com>

Hi,

w.r.t the one issue below : is the awt load library code the only place you
need/are doing this ? If someone else (hotspot, core-libs) already 
assented to this
then I guess I could too but I'd like to hear for sure that hotspot and 
core-libs
teams both agree to this approach and whether there is an alternative.

-phil.

On 9/19/13 4:29 AM, Volker Simonis wrote:
> Hi Phil,
>
> thank you for looking at the changes. Please find my answers inline:
>
>     /* AIX does not provide the 'dladdr' function. But fortunately, we've
>       42  * already implemented it in the HotSpot, because we need it
>     there as
>       43  * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}).
>
>     Whilst this is in "ifdef AIX" this reliance on an exported hotspot
>     function sounds hacky. What actual requirement is there that the
>     AIX class libraries be so tightly-coupled with that VM?
>     There is no contract there.
>
>
> You're right, there is no contract. It's just pragmatic solution and I 
> think it should always work because the libjvm will always be loaded 
> at the point in AWT where it is used. Another solution would be to 
> re-implement the functionality in the class library and I don't like 
> code duplication either.
>
>     -phil.
>
>



From peter.levart at gmail.com  Thu Sep 19 14:13:02 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Sep 2013 16:13:02 +0200
Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters
	synchronized method
In-Reply-To: <20130918092818.GD5572@jfranck-desktop.jrpg.bea.com>
References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com>
	<520777E5.3050304@gmail.com>
	<20130812105439.GC6420@jfranck-desktop.jrpg.bea.com>
	<5208D7A7.9070608@gmail.com>
	<5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com>
	<521CA2F0.1020701@gmail.com>
	<2A6CD10E-FA3B-4BC9-AD22-AAA79C866731@oracle.com>
	<522DFE08.5060604@gmail.com> <5235CE65.9040005@gmail.com>
	<20130918092818.GD5572@jfranck-desktop.jrpg.bea.com>
Message-ID: <523B066E.8050306@gmail.com>

Thanks Joel,

I will push this now.

Regards, Peter

On 09/18/2013 11:28 AM, Joel Borggr?n-Franck wrote:
> Looks good Peter,
>
> cheers
> /Joel
>
> On 2013-09-15, Peter Levart wrote:
>> Hi,
>>
>> I rebased the changes and added @bug tag to test. Here's new webrev:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.04/
>>
>>
>> Joel, I believe you've got the "R" mojo now...
>>
>>
>> Regards, Peter
>>
>> On 09/09/2013 06:57 PM, Peter Levart wrote:
>>> Hi Joel,
>>>
>>> Thanks for reviewing.
>>>
>>> On 09/09/2013 04:25 PM, Joel Borggr?n-Franck wrote:
>>>> Hi Peter,
>>>>
>>>> Thanks for this, please add a "@bug 8011940" tag to your test. IMO you don't need  a re-review for that. Otherwise looks good.
>>> I'll do that. I just didn't know whether tagging with bug-ID is
>>> meant for all tests that arise from fixing a particular bug or
>>> just those that test the presence/fixture of the bug. The 8011940
>>> bug is about scalability and the test is not testing scalability
>>> (it has been demonstrated by a micro-benchmark, but that is not
>>> included in the test). The test is just covering the logic that
>>> has been re-factored and has not had any tests before.
>>>
>>> Regards, Peter
>>>
>>>> We still need a Reviewer, Chris, you reviewed a previous version, can you look at this one too?
>>>> cheers
>>>> /Joel
>>>>
>>>> On 27 aug 2013, at 15:00, Peter Levart  wrote:
>>>>
>>>>> Hi Joel and others,
>>>>>
>>>>> Here's a 3rd revision of this proposed patch:
>>>>>
>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.03/
>>>>>
>>>>> I used LinkedHashMap for annotations in this one. It means that now even .getAnnotations() are reported in "declaration order": 1st inherited (includes overridden) then declared (that are not overriding). For example, using @Inherited annotations A1, A2, A3:
>>>>>
>>>>> @A1("C")
>>>>> @A2("C")
>>>>> class C {}
>>>>>
>>>>> @A1("D")
>>>>> @A3("D")
>>>>> class D extends C {}
>>>>>
>>>>> D.class.getAnnotations() now returns: { @A1("D"), @A2("C"), @A3("D") } ...
>>>>>
>>>>> The LHM constructor uses the following expression to estimate the initial capacity of the LHM:
>>>>>
>>>>> 3326                         annotations = new LinkedHashMap<>((Math.max(
>>>>> 3327                                 declaredAnnotations.size(),
>>>>> 3328                                 Math.min(12, declaredAnnotations.size() + superAnnotations.size())
>>>>> 3329                             ) * 4 + 2) / 3
>>>>> 3330                         );
>>>>>
>>>>>
>>>>> I think this strikes some balance between effectivity and accuracy of estimation. I could pre-scan the superclass annotations and calculate the exact final size of the annotations Map before constructing it though. Tell me if this is worth the effort.
>>>>>
>>>>> I also created a test that tests 3 things:
>>>>> - class annotation inheritance
>>>>> - order of class annotations reported by .getAnnotations() and .getDeclaredAnnotations() methods (although not specified, the order is now stable and resembles declaration order)
>>>>> - behaviour of class annotation caching when class is redefined
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>> On 08/13/2013 09:52 AM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Comments inline,
>>>>>>
>>>>>> On 12 aug 2013, at 14:40, Peter Levart  wrote:
>>>>>>> On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote:
>>>>>>> - annotation (@interface)  declarations can themselves be redefined (for example, defaults changed). Such redefinitions don't affect already initialized annotations. Default values are cached in AnnotationType which is not invalidated as a result of class redefinition. Maybe it should be. And even if AnnotationType was invalidated as a result of class redefinition, the defaults are looked-up when particular annotations are initialized and then combined with parsed values in a single values map inside each annotation instance (proxy), so invalidating AnnotationType would have no effect on those annotations.
>>>>>>>
>>>>>>>> 3326                 if (annotations == null) { // lazy construction
>>>>>>>> 3327                     annotations = new HashMap<>();
>>>>>>>> 3328                 }
>>>>>>>>
>>>>>>>> I think this should be a LinkedHashMap, so that iteration is predictable
>>>>>>>> (I know it isn't in the current code). Also the size of the map is known
>>>>>>>> so you can use a constructor with an explicit initial capacity.
>>>>>>> Right, AnnotationParser does return LinkedHashMap, so at least decalredAnnotations are in parse-order. I will change the code to use LinkedHashMap for inherited/combined case too.
>>>>>> Thanks.
>>>>>>
>>>>>>> The number of annotations that end-up in inherited/combined Map is not known in advance. I could make a separate pre-scan for superclass annotations that are @Inheritable and don't have the same key as any of declared annotations and then sum this count with declared annotations count, but I don't think this will be very effective. I could allocate a large-enough Map to always fit (the count of superclass annotations + the count of declared annotations), but that could sometimes lead to much over-allocated Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations count + declared annotations count) as the initial capacity for the Map. What do you think which of those 3 alternatives is the best?
>>>>>> My bad. I was thinking of the case where every inherited annotation was overridden, in that case annotations.size() == declaredAnnotations.size(). That is of course not generally true. I'm fine with handling this as a follow up since the situation is no worse than today and the surrounding code is better. However,
>>>>>>
>>>>>> 1) We should really measure this.
>>>>>> 2) My gut feeling is that the ratio of not overridden inherited annotations to declared annotations is small IE the expected nr of annotations is much closer to declare annotations than to declared + superclass annotations.
>>>>>> 3) The default initial capacity is 16 and load factor is 0.75. I do think the mean nr of annotations is closer to 3 than to 12. We are probably wasting some space here.
>>>>>>
>>>>>> Perhaps use min(default cap, (total annotations/0.75 (+ 1?))) for now as that will make the situation no worse than today and often better?
>>>>>>
>>>>>>>> Since this is a fairly significant rewrite I think it might be good to
>>>>>>>> make sure our tests exercise the new code. Can you run some kind of
>>>>>>>> coverage report on this?
>>>>>>> I successfully ran the jdk_lang jtreg tests which contain several tests for annotations.
>>>>>> I'm a bit worried these tests doesn't cover annotations + class redefine. But I might be persuaded to have more extensive testing as a follow up as well.
>>>>>>
>>>>>> cheers
>>>>>> /Joel



From volker.simonis at gmail.com  Thu Sep 19 14:28:59 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 19 Sep 2013 16:28:59 +0200
Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to
	build the class library on AIX
In-Reply-To: <523B01DF.1030902@oracle.com>
References: 
	
	<523A27A8.404@oracle.com>
	
	<523B01DF.1030902@oracle.com>
Message-ID: 

Hi Phil,

I'm open to any good ideas.

The current solution is pragmatic, simple and it has no impact on
existing platforms.

The other possibility I see is to put the 'dladdr' implantation into
its own library (something equivalent to "libjli") and link that
library to "libawt". But I currently don't see any existing library I
could put the implementation into.

Notice that the change I propose already contains an extra
implementation of 'dladdr' for AIX in
"src/solaris/demo/jvmti/hprof/hprof_md.c" because "libhprof" is not
linked against libjvm and we therefore can not use the 'extern'-trick
there.

Of course it would be nice if there would be a small library which
contains 'dladdr' and which could be linked against both, "libawt" and
"libhprof". But I think that would require bigger shared changes (with
possible empty implementations on the current platforms).

What do other think?

Regards,
Volker


On Thu, Sep 19, 2013 at 3:53 PM, Phil Race  wrote:
> Hi,
>
> w.r.t the one issue below : is the awt load library code the only place you
> need/are doing this ? If someone else (hotspot, core-libs) already assented
> to this
> then I guess I could too but I'd like to hear for sure that hotspot and
> core-libs
> teams both agree to this approach and whether there is an alternative.
>
> -phil.
>
>
> On 9/19/13 4:29 AM, Volker Simonis wrote:
>
> Hi Phil,
>
> thank you for looking at the changes. Please find my answers inline:
>
>
>>
>> /* AIX does not provide the 'dladdr' function. But fortunately, we've
>>
>>   42  * already implemented it in the HotSpot, because we need it there as
>>   43  * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}).
>>
>> Whilst this is in "ifdef AIX" this reliance on an exported hotspot
>> function sounds hacky. What actual requirement is there that the
>> AIX class libraries be so tightly-coupled with that VM?
>> There is no contract there.
>>
>
> You're right, there is no contract. It's just pragmatic solution and I think
> it should always work because the libjvm will always be loaded at the point
> in AWT where it is used. Another solution would be to re-implement the
> functionality in the class library and I don't like code duplication either.
>
>>
>> -phil.
>>
>>
>


From peter.levart at gmail.com  Thu Sep 19 14:27:48 2013
From: peter.levart at gmail.com (peter.levart at gmail.com)
Date: Thu, 19 Sep 2013 14:27:48 +0000
Subject: hg: jdk8/tl/jdk: 8011940: java.lang.Class.getAnnotations() always
	enters synchronized method
Message-ID: <20130919142812.8ECD062956@hg.openjdk.java.net>

Changeset: 7557062d2dd2
Author:    plevart
Date:      2013-09-19 16:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7557062d2dd2

8011940: java.lang.Class.getAnnotations() always enters synchronized method
Reviewed-by: jfranck, chegar, psandoz, shade

! src/share/classes/java/lang/Class.java
+ test/java/lang/annotation/AnnotationsInheritanceOrderRedefinitionTest.java



From jonathan.gibbons at oracle.com  Thu Sep 19 15:27:11 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 19 Sep 2013 15:27:11 +0000
Subject: hg: jdk8/tl/langtools: 8024609: sjavac assertion fails during call to
	BuildState.collectArtifacts
Message-ID: <20130919152713.F295A62959@hg.openjdk.java.net>

Changeset: 0cfd5baa7154
Author:    ohrstrom
Date:      2013-09-19 08:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0cfd5baa7154

8024609: sjavac assertion fails during call to BuildState.collectArtifacts
Reviewed-by: jjg

! src/share/classes/com/sun/tools/sjavac/BuildState.java
! src/share/classes/com/sun/tools/sjavac/Main.java
! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java



From alexander.zuev at oracle.com  Thu Sep 19 16:43:13 2013
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Thu, 19 Sep 2013 20:43:13 +0400
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
Message-ID: <523B29A1.9000204@oracle.com>

Hi,

   please review my fix for 8025076: Fix for JDK-8017248 breaks jprt 
submission for non-unicode locales

   The idea of the fix is to replace test case with the complex file 
name in it by the
test that generates and compiles such file at the run time.

   The webrev can be found at: 
http://cr.openjdk.java.net/~kizune/8025076/webrev.04/

With best regards,
/Alex


From xueming.shen at oracle.com  Thu Sep 19 16:53:36 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 19 Sep 2013 09:53:36 -0700
Subject: RFR:  8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
In-Reply-To: <523ABB64.8080309@oracle.com>
References: <5238CFB4.1040304@oracle.com> <523980EF.6010208@oracle.com>
	<5239D7E5.6040803@oracle.com> <523A02D1.6090503@oracle.com>
	<523ABB64.8080309@oracle.com>
Message-ID: <523B2C10.3030707@oracle.com>


On 9/19/2013 1:52 AM, Alan Bateman wrote:
> On 18/09/2013 20:45, Xueming Shen wrote:
>> OK, how about this one? I'm even using lambda:-)
>>
>> http://cr.openjdk.java.net/~sherman/8023113/webrev/
>>
>> -Sherman
> Looks okay except that Files.list returns a stream that needs to be closed to avoid leaking resources.

updated accordingly.
http://cr.openjdk.java.net/~sherman/8023113/webrev
agreed we had enough fun already here.

-Sherman

>
> As a side note, as cleanup is attempting to delete a file tree then you could eliminate the recursion by using Files.walkFileTree with the directories removed in the postVisitDirectory method. It might be tempting to use the new walk method but it returns each directory before its entries and so isn't appropriate for recursive ops where you need to do touch the directory after its entries. I'm not suggesting spending any more time on this test of course, you've done more than enough.
>
> -Alan.



From david.r.chase at oracle.com  Thu Sep 19 16:57:22 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 19 Sep 2013 12:57:22 -0400
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: <9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
	
	<9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>
Message-ID: 

Recommended changes made:

http://cr.openjdk.java.net/~drchase/8022701/webrev.04/

Test with jtreg (for pass and for induced failure) on MacOS,
not sure what additional other testing is desired since it is entirely in the libraries.

I included code to handle the case of a broken field-referencing methodhandle,
but did not test it because there's no syntax for these in Java, nor is their creation
well-documented.

David


On 2013-09-13, at 12:02 AM, John Rose  wrote:

> On Sep 12, 2013, at 5:44 PM, David Chase  wrote:
> 
>> Do these sibling bugs have numbers?
> 
> Yes, 8022701.  I just updated the bug to explain their common genesis.
> 
>> And I take it you would like to see
>> 
>> 1) a test enhanced with ASM to do all 3 variants of this
> 
> Yes, please.  The case of "no such field" does not have a direct cause from lambda expressions AFAIK, but it can occur with "raw" CONSTANT_MethodHandles.  (It would be reasonable for javac to emit CONSTANT_MH's for fields in some very limited circumstances, but I'll bet it doesn't.)
> 
>> 2) DO attach the underlying cause
> 
> Yes.  Read the javadoc for ExceptionInInitializerError for an example of why users want the underlying cause for linkage errors.
> 
> (Golly, I wonder what happens if resolution of a CONSTANT_MethodHandle tries to touch a class with a booby-trapped .  I hope it's the case that the ExceptionInInitializerError just passes straight up the stack.  But if it were to get wrapped in a ROE of some sort, it would probably bubble up as an IAE.  Could be a charming exploration.  Actually, no, I don't want to go in there.  Getting all possible linkage errors correct is fine, but we have more important things to do.)
> 
> ? John
> 
>> David
>> 
>> On 2013-09-12, at 5:35 PM, John Rose  wrote:
>> 
>>> It looks good.  I have three requests.
>>> 
>>> Regarding this comment:
>>> +     * See MethodSupplier.java to see how to produce these bytes.
>>> +     * They encode that class, except that method m is private, not public.
>>> 
>>> The recipe is incomplete, since it does not say which bits to tweak to make m private.  Please add that step to the comments more explicitly, or if possible to the code (so bogusMethodSupplier is a clean copy of the od output).  I suppose you could ask sed to change the byte for you.  That will make this test a better example for future tests, and make it easier to maintain if javac output changes.  The high road to use would be asm, although for a single byte tweak od works OK.
>>> 
>>> Also, this bug has two twins.  The same thing will happen with NoSuchMethodE* and NoSuchFieldE*.  Can you please make fixes for those guys also?
>>> 
>>> FTR, see MemberName.makeAccessException() for logic which maps the other way, from *Error to *Exception.  I don't see a direct way to avoid the double mapping (Error=>Exception=>Error) when it occurs.
>>> 
>>> For the initCause bit we should do this:
>>> 
>>>      } catch (IllegalAccessException ex) {
>>>          Error err = new IllegalAccessError(ex.getMessage());
>>>          err.initCause(ex.getCause());  // reuse underlying cause of ex
>>>          throw err;
>>>      } ... and for NSME and NSFE...
>>> 
>>> That way users can avoid the duplicate exception but can see any underlying causes that the JVM may include.
>>> 
>>> Thanks for untangling this!
>>> 
>>> ? John
>>> 
>>> On Sep 12, 2013, at 12:17 PM, David Chase  wrote:
>>> 
>>>> The test is adapted from the test in the bug report.
>>>> The headline on the bug report is wrong -- because it uses reflection in the test to do the invocation,
>>>> the thrown exception is wrapped with InvocationTargetException, which is completely correct.
>>>> HOWEVER, the exception inside the wrapper is the wrong one.
>>>> 
>>>> The new test checks the exception in both the reflective-invocation and plain-invocation cases,
>>>> and also checks both a method handle call (which threw the wrong exception) and a plain
>>>> call (which threw, and throws, the right exception).
>>>> 
>>>> The test also uses a tweaked classloader to substitute the borked bytecodes necessary to get
>>>> the error, so it is not only shell-free, it can also be run outside jtreg.
>>>> 
>>>> On 2013-09-12, at 2:34 PM, Christian Thalinger  wrote:
>>>> 
>>>>> 
>>>>> On Sep 12, 2013, at 11:28 AM, David Chase  wrote:
>>>>> 
>>>>>> New webrev, commented line removed:
>>>>>> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
>>>>> 
>>>>> I think the change is good given that the tests work now.  Is your test derived from the test in the bug report?
>>>>> 
>>>>> And it would be good if John could also have a quick look (just be to be sure).
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>>> 
>>>>>> On 2013-09-12, at 1:53 PM, David Chase  wrote:
>>>>>> 
>>>>>>> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
>>>>>>> 
>>>>>>> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
>>>>>>> 
>>>>>>>> +             // err.initCause(ex);
>>>>>>>> 
>>>>>>>> Why is this commented?
>>>>>>>> 
>>>>>>>> -- Chris
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>> 
> 


From xueming.shen at oracle.com  Thu Sep 19 17:04:13 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Thu, 19 Sep 2013 17:04:13 +0000
Subject: hg: jdk8/tl/jdk: 8023113: tools/jar/ChangeDir.java fails if /tmp/a
	exists
Message-ID: <20130919170439.772EB6296B@hg.openjdk.java.net>

Changeset: 278873b2b3f8
Author:    sherman
Date:      2013-09-19 10:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/278873b2b3f8

8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
Summary: updated the test case
Reviewed-by: alanb

! test/tools/jar/ChangeDir.java



From martinrb at google.com  Thu Sep 19 17:17:27 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 19 Sep 2013 10:17:27 -0700
Subject: Classload of sun.nio.ch.Net fails - regression in jdk7u25
Message-ID: 

Hi, this is a bug report.

Here is a tiny program that does class loading:

public class LoadClass {
    public static void main(String[] args) throws Throwable {
        for (String className : args)
            Class.forName(className, true, null);
    }
}

If I run this against 1.7.0_21, it succeeds, but if I run it against
1.7.0_25 I get

java LoadClass sun.nio.ch.Net
Exception in thread "main" java.lang.UnsatisfiedLinkError:
sun.nio.ch.Net.isExclusiveBindAvailable()I
at sun.nio.ch.Net.isExclusiveBindAvailable(Native Method)
at sun.nio.ch.Net.(Net.java:58)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)

sun.nio.ch.Net clearly tries to prevent this from happening by calling
Util.load(), but the problem is that the static block is called too late.
 Those static blocks calling Util.load() need to be at the top of each
source file instead of the bottom, to prevent such failures.

Regression was introduced with this changeset:

changeset:   6272:8dd8266a2f4b
user:        khazra
date:        Thu Mar 14 13:54:32 2013 -0700
summary:     7170730: Improve Windows network stack support.

I think Oracle testing folks should regularly run the above little program
against every single class in the JDK (although it might be too expensive
to run in a jtreg test).

The fix is obvious, but I can provide a webrev if desired.


From vladimir.x.ivanov at oracle.com  Thu Sep 19 17:45:18 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 19 Sep 2013 21:45:18 +0400
Subject: RFR (S) 8001109: arity mismatch on a call to spreader method
	handle should elicit IllegalArgumentException
In-Reply-To: <74280088-19F3-4B0B-AC62-3332E9AED63A@oracle.com>
References: <74280088-19F3-4B0B-AC62-3332E9AED63A@oracle.com>
Message-ID: <523B382E.4060304@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 9/13/13 5:02 AM, John Rose wrote:
> Please review this change for a change to the JSR 292 implementation:
>
> http://cr.openjdk.java.net/~jrose/8001109/webrev.00/
>
> The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
>
> In the RI, the exception-raising code is simplified to throw just IAE.
>
> Thanks,
> ? John
>


From david.lloyd at redhat.com  Thu Sep 19 19:55:24 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 19 Sep 2013 14:55:24 -0500
Subject: Replacement of sun.reflect.Reflection#getCallerClass
In-Reply-To: <523AE813.6070900@gmail.com>
References: 
	<522551AE.7060000@oracle.com>
	
	<5225F268.2000707@oracle.com>
	<7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net>
	<5226197F.1050301@gmail.com> <5239C50B.7080300@redhat.com>
	<523AE813.6070900@gmail.com>
Message-ID: <523B56AC.8000909@redhat.com>

On 09/19/2013 07:03 AM, Peter Levart wrote:
> On 09/18/2013 05:21 PM, David M. Lloyd wrote:
>> On 09/03/2013 12:16 PM, Peter Levart wrote:
>> [...]
>>> *AND* that Reflection.getCallerClass() can only be called from within
>>>  methods annotated with @CallerSensitive.
>>>
>>> Now for that part, the public API equivalent
>>> (StackTraceFrame.getCallerClass() or whatever it is called) need not
>>> be restricted to methods annotated with any annotation, but that
>>> means that this public API should not be used to implement security
>>> decisions since MethodHandles API allows caller to be spoofed unless
>>> looking-up a method annotated with @CallerSensitive...
>>
>> Peter, can you please elaborate on this a bit?  I could find nothing
>> in the MethodHandles API or its associated classes that would seem to
>> give the ability to call another method with a spoofed caller.  Yes
>> you can set up a Lookup for another class but I don't see how that
>> would affect the ability of (say) a security manager to make access
>> decisions based on the call stack/class context?
>>
>
> Hi David,
>
> The thing with method handles is that they perform all security checks
> not at invoke-time (like reflection), but at lookup-time. If you have a
> hold on a MethodHandle object, you can always invoke it. All security
> checks must have been performed at lookup-time. This includes security
> checks that are based on what the "caller" of the method is. In case of
> method handles, the "caller" is the class associated with the Lookup
> object - the lookup class.
>
> Try this example:
>
> // --- the following be loaded by the bootstrap class loader
> package sys;
>
> import sun.reflect.CallerSensitive;
> import sun.reflect.Reflection;
>
> import java.lang.invoke.MethodHandles;
>
> public class CSUtil
> {
>      public static final MethodHandles.Lookup lookup =
> MethodHandles.lookup();
>
>      @CallerSensitive
>      public static void printCallerClassLoader(String prefix) {
>          Class cc = Reflection.getCallerClass();
>          System.err.println(prefix + ":\n  "
>                             + cc + "\n  loaded by "
>                             + cc.getClassLoader() + "\n");
>      }
>
>      public static class Nested {}
> }
>
>
> // ---the following be loaded by application class loader
> package usr;
>
> import sys.CSUtil;
>
> import java.lang.invoke.MethodHandle;
> import java.lang.invoke.MethodHandles;
> import java.lang.invoke.MethodType;
>
> public class CSTest
> {
>      public static final MethodHandles.Lookup lookup =
> MethodHandles.lookup();
>
>      public static void main(String[] args) throws Throwable
>      {
>          MethodHandle mh1  = CSTest.lookup.findStatic(
>              CSUtil.class,
>              "printCallerClassLoader",
>              MethodType.methodType(void.class, String.class)
>          );
>
>          mh1.invokeExact("mh1");
>
>          MethodHandle mh2  = CSUtil.lookup.findStatic(
>              CSUtil.class,
>              "printCallerClassLoader",
>              MethodType.methodType(void.class, String.class)
>          );
>
>          mh2.invokeExact("mh2");
>
>          MethodHandle mh3  =
> CSUtil.lookup.in(CSUtil.Nested.class).findStatic(
>              CSUtil.class,
>              "printCallerClassLoader",
>              MethodType.methodType(void.class, String.class)
>          );
>
>          mh3.invokeExact("mh3");
>
>          MethodHandle mh4  = CSUtil.lookup.in(CSTest.class).findStatic(
>              CSUtil.class,
>              "printCallerClassLoader",
>              MethodType.methodType(void.class, String.class)
>          );
>
>          mh4.invokeExact("mh4");
>      }
> }
>
>
> ...which prints:
>
> mh1:
>    class java.lang.invoke.MethodHandleImpl$BindCaller$T/523429237
>    loaded by sun.misc.Launcher$AppClassLoader at 15db9742
>
> mh2:
>    class java.lang.invoke.MethodHandleImpl$BindCaller$T/1450495309
>    loaded by null
>
> mh3:
>    class java.lang.invoke.MethodHandleImpl$BindCaller$T/2001049719
>    loaded by null
>
> Exception in thread "main" java.lang.IllegalAccessException: Attempt to
> lookup caller-sensitive method using restricted lookup object
>      at
> java.lang.invoke.MethodHandles$Lookup.findBoundCallerClass(MethodHandles.java:1123)
>
>      at
> java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:619)
>      at usr.CSTest.main(CSTest.java:39)
>
>
> You can see that the "caller" class it not actually the class doing
> lookup, but some anonymous class which is loaded by the same class
> loader as the lookup class and maybe it shares some other properties
> with it (it seems that this is sufficient for security checks). The mh3
> is interesting in that the "caller" is different from that of mh2. The
> Lookup.in(Class) method returns a Lookup object with different lookup
> class and so the "caller" class is different too. Although the
> printCallerClassLoader is a public method in a public class, the mh4 can
> not be looked-up, because this could be used to "spoof" the caller class
> loader for any such public method. Imagine:
>
>
>          // this throws IllegalAccessException. If it didn't...
>          MethodHandle mh = MethodHandles.lookup()
>              .in(String.class)
>              .findVirtual(
>                  Field.class,
>                  "get",
>                  MethodType.methodType(Object.class, Object.class)
>              );
>
>          Field valueField = String.class.getDeclaredField("value");
>
>          String abc = "abc";
>
>          // ... then the following would invoke: valueField.get(abc) and
> pretend that
>          // it was invoked from the String class, which would succeed...
>          char[] abcArray = (char[])(Object) mh.invokeExact(valueField,
> (Object) abc);
>
>          // ...and you could observe the following:
>          abcArray[0] = 'A';
>          assert abc.charAt(0) == 'A';

This must have changed since JDK 7 because I don't see any of this 
behavior with the classic getCallerClass(int) method.  In other words 
using "in" does not appear to affect the frames reported by 
getCallerClass(int) (or SecurityManager.getClassContext() or 
Thread.getStackTrace()) at all.

It looks like this new behavior is a result of @CallerSensitive and 
changes associated with it (in particular those weird pseudo-class names 
are not reported in 7); I'd say the fatal flaw exposed here is in those 
changes, not in the original method behavior.  It seems like we've gone 
way off course if this is the case.

Especially consider that SecurityManager.getClassContext() is a 
supported, non-deprecated API designed for the express purpose of access 
checking, which (as far as I can test) works similarly to 
getCallerClass(int).  If method handles could spoof callers in this way 
then we've blown yet another massive hole in Java security.
-- 
- DML


From vicente.romero at oracle.com  Thu Sep 19 19:59:14 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 19 Sep 2013 19:59:14 +0000
Subject: hg: jdk8/tl/langtools: 8024437: Inferring the exception thrown:
	sometimes fails to compile
Message-ID: <20130919195922.15E2A62998@hg.openjdk.java.net>

Changeset: 2375ce96e80d
Author:    vromero
Date:      2013-09-19 20:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2375ce96e80d

8024437: Inferring the exception thrown: sometimes fails to compile
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
+ test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java



From huizhe.wang at oracle.com  Thu Sep 19 21:19:57 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 19 Sep 2013 14:19:57 -0700
Subject: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH
	NODE LIST OF LENGTH =1 IN JAXP
In-Reply-To: <5238449D.50509@oracle.com>
References: <5238449D.50509@oracle.com>
Message-ID: <523B6A7D.3080501@oracle.com>

Hi Aleksej,

Looks like the getLength() method has the same problem.

Joe

On 9/17/2013 5:01 AM, Aleksej Efimov wrote:
> Hi Everyone,
>
> There is a bug [1] in JAXP about transformation of one-item sized node 
> list:
> When the length of nodelist which is passed to a XSLT extension 
> function is 1, the node gotten from the node list becomes null.
> New test illustrates this issue [2]. Full webrev with proposed fix can 
> be found here: [3].
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707
> [2] 
> http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java
> [3] http://cr.openjdk.java.net/~aefimov/8024707/
>
> Best regards,
> Aleksej



From brian.burkhalter at oracle.com  Thu Sep 19 21:31:01 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 19 Sep 2013 14:31:01 -0700
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is
	null and the key is absent
In-Reply-To: <5238FBEB.4030907@univ-mlv.fr>
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
	<574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
	<1DA14A6A-CD1E-4FC1-BC0A-235F3F623BE7@Oracle.COM>
	<7E8EB639-9908-4658-96EF-FB414EDF445D@oracle.com>
	<5238FBEB.4030907@univ-mlv.fr>
Message-ID: <31F446B3-A1FB-44C7-887E-B78979F9B05C@oracle.com>

On Sep 17, 2013, at 6:03 PM, Remi Forax wrote:

> On 09/18/2013 02:08 AM, Brian Burkhalter wrote:
>> The proposed patch has been updated at the same location:
>> 
>> http://cr.openjdk.java.net/~bpb/8024331/.
>> 
>> Thanks,
>> 
>> Brian
> 
> looks good.
> 
> R?mi

Thanks, R?mi

JDK 8 Reviewers: This patch still needs Official Approval unless of course there are objections.

Thanks,

Brian

> 
>> 
>> On Sep 17, 2013, at 4:27 PM, Brian Burkhalter wrote:
>> 
>>> I'll make the various updates and repost.
> 



From john.r.rose at oracle.com  Thu Sep 19 21:31:43 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 19 Sep 2013 14:31:43 -0700
Subject: RFR (S) 8001108: an attempt to use "" as a method name
	should elicit NoSuchMethodException
In-Reply-To: <09F68115-21E6-450C-8DC2-6FCDB6C191B4@oracle.com>
References: <6FAC275C-6374-41F5-BAB7-CA1AC729EF9F@oracle.com>
	<09F68115-21E6-450C-8DC2-6FCDB6C191B4@oracle.com>
Message-ID: <99860D39-C18B-4638-94BB-12084139AE1E@oracle.com>


On Sep 18, 2013, at 5:05 PM, Christian Thalinger  wrote:

> src/share/classes/java/lang/invoke/MethodHandles.java:
> 
> +     * methods as if they were normal methods, but the JVM verifier rejects them.
> 
> I think you should say "JVM byte code verifier" here.

Done.  s/byte code/bytecode/.

> 
> +         * (Note:  JVM internal methods named {@code } not visible to this API,
> +         * even though the {@code invokespecial} instruction can refer to them
> +         * in special circumstances.  Use {@link #findConstructor findConstructor}
> 
> Not exactly sure but should this read "are not visible"?

Yes.

> 
>         MemberName resolveOrFail(byte refKind, Class refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException {
> +            type.getClass();  // NPE
>             checkSymbolicClass(refc);  // do this before attempting to resolve
> -            name.getClass(); type.getClass();  // NPE
> +            checkMethodName(refKind, name);
> 
> Could you add a comment here saying that checkMethodName does an implicit null pointer check on name?  Maybe a comment for checkMethodName too.

Done.

> 
> What was the problem with the null pointer exceptions?  Is it okay that we might throw another exception before null checking name?

Foo.  The reordering of those null checks seems to be a needless change that crept in.  I'm going to keep them the way they are.

See updated webrev:
  http://cr.openjdk.java.net/~jrose/8001108/webrev.01/

? John

> On Sep 12, 2013, at 6:47 PM, John Rose  wrote:
> 
>> Please review this change for a change to the JSR 292 implementation:
>> 
>> http://cr.openjdk.java.net/~jrose/8001108/webrev.00
>> 
>> Summary: add an explicit check for leading "<", upgrade the unit tests
>> 
>> The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
>> 
>> In the RI, there is an explicit error check.
>> 
>> Thanks,
>> ? John
>> 
>> P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
>> Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From naoto.sato at oracle.com  Thu Sep 19 21:34:42 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 19 Sep 2013 14:34:42 -0700
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
In-Reply-To: <523B29A1.9000204@oracle.com>
References: <523B29A1.9000204@oracle.com>
Message-ID: <523B6DF2.5000109@oracle.com>

Hi Alex,

Should the test case also check the encoding of the platform? Does it 
work under the environment where the encoding is, say US-ASCII?

Naoto

On 9/19/13 9:43 AM, Alexander Zuev wrote:
> Hi,
>
>    please review my fix for 8025076: Fix for JDK-8017248 breaks jprt
> submission for non-unicode locales
>
>    The idea of the fix is to replace test case with the complex file
> name in it by the
> test that generates and compiles such file at the run time.
>
>    The webrev can be found at:
> http://cr.openjdk.java.net/~kizune/8025076/webrev.04/
>
> With best regards,
> /Alex



From john.r.rose at oracle.com  Thu Sep 19 21:38:30 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 19 Sep 2013 14:38:30 -0700
Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect
	initialization rules for static members
In-Reply-To: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>
References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>
Message-ID: <239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com>

On Sep 12, 2013, at 7:24 PM, John Rose  wrote:

> Please review this change for a change to the JSR 292 implementation:
> 
> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
> 
> Summary: Align MH semantic with bytecode behavior of constructor and static member accesses, regarding  invocation.
> 
> The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.

I have a reviewer (Alex Buckley) for the documentation changes, but I would also like a quick code review for the unit test.

Also, there is a code insertion (predicated on a "false" symbolic constant) which serves to document the buggy JDK 7 behavior.  I'm not particularly attached to it, so I'm open to either a yea or nay on keeping it.  Leaning nay at the moment.

? John

From peter.levart at gmail.com  Thu Sep 19 21:47:02 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Sep 2013 23:47:02 +0200
Subject: Replacement of sun.reflect.Reflection#getCallerClass
In-Reply-To: <523B56AC.8000909@redhat.com>
References: 
	<522551AE.7060000@oracle.com>
	
	<5225F268.2000707@oracle.com>
	<7C218B80-64F7-4E76-981E-579B3AE7DF1D@nicholaswilliams.net>
	<5226197F.1050301@gmail.com> <5239C50B.7080300@redhat.com>
	<523AE813.6070900@gmail.com> <523B56AC.8000909@redhat.com>
Message-ID: <523B70D6.70908@gmail.com>


On 09/19/2013 09:55 PM, David M. Lloyd wrote:
>> Imagine:
>>
>>
>>          // this throws IllegalAccessException. If it didn't...
>>          MethodHandle mh = MethodHandles.lookup()
>>              .in(String.class)
>>              .findVirtual(
>>                  Field.class,
>>                  "get",
>>                  MethodType.methodType(Object.class, Object.class)
>>              );
>>
>>          Field valueField = String.class.getDeclaredField("value");
>>
>>          String abc = "abc";
>>
>>          // ... then the following would invoke: valueField.get(abc) and
>> pretend that
>>          // it was invoked from the String class, which would succeed...
>>          char[] abcArray = (char[])(Object) mh.invokeExact(valueField,
>> (Object) abc);
>>
>>          // ...and you could observe the following:
>>          abcArray[0] = 'A';
>>          assert abc.charAt(0) == 'A';
>
> This must have changed since JDK 7 because I don't see any of this 
> behavior with the classic getCallerClass(int) method.  In other words 
> using "in" does not appear to affect the frames reported by 
> getCallerClass(int) (or SecurityManager.getClassContext() or 
> Thread.getStackTrace()) at all.

It only affects frames seen in caller sensitive methods. In other 
methods, the JDK7 reported caller is the one invoking the MH, I think, 
but that's not important, since other methods are not caller sensitive. 
In JDK8 you can't even get the caller unless you are in the @CS 
annotated method.

>
> It looks like this new behavior is a result of @CallerSensitive and 
> changes associated with it (in particular those weird pseudo-class 
> names are not reported in 7); I'd say the fatal flaw exposed here is 
> in those changes, not in the original method behavior.  It seems like 
> we've gone way off course if this is the case.

I think the behavior is equivalent. In JDK7 all caller-sensitive methods 
are maintained as a hard-coded list/switch inside MHs implementation. 
They are marked with @CS annotation in JDK8 instead, which is easier to 
maintain.

>
> Especially consider that SecurityManager.getClassContext() is a 
> supported, non-deprecated API designed for the express purpose of 
> access checking, which (as far as I can test) works similarly to 
> getCallerClass(int).  If method handles could spoof callers in this 
> way then we've blown yet another massive hole in Java security.

They can't spoof callers. As you can see in above example, such spoofing 
look-ups of @CS methods are prevented.

>
> -- 
> - DML


Regards, Peter



From xueming.shen at oracle.com  Thu Sep 19 22:10:00 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 19 Sep 2013 15:10:00 -0700
Subject: RFR:  6233323,,ZipEntry.isDirectory() may return false incorrectly
Message-ID: <523B7638.7010108@oracle.com>

Hi,

Please help review the change for #6233323.

http://cr.openjdk.java.net/~sherman/6233323/webrev

Background info:

ZipFile.getEntry() is implemented the way that it first tries to find the entry
with the exactly matched name. If failed, it then tries to see if the specified
name ends with a slash '/', if not, it then tries to find the entry with the '/'
appended, with the expectation that there might be a "directory" entry, whose
name ends with '/'. The problem here is that the returned entry actually sets
its name with the original passed in name in this situation, so if the passed
in name does not end with the '/' and the search result is the one with '/'
(directory), the returned entry then fails the ZipEntry.isDirectory() test, which
is purely implemented on the assumption/specification that "A directory entry
is defined to be one whose name ends with a '/'".

The change here is to return the entry with the name of the "real" name of
the entry in the zip file, with the '/' slash appended. I also added some words
to clarify this behavior (given the nature of the change, I probably need a
CCC approval).

Interestingly, "an entry whose name ends with a slash is a directory entry"
appears to be a convention, instead of something being explicitly specified
in either pkware or info-zip's specification. zip/uzip and our jar definitely work
with the assumption that a "slash / ended" entry is a directory, however it
easily to read/write an entry with slash ended name as a "normal" file entry
via ZipInputStream/OutputStream (both unzip and jar treat such an entry as
a directory entry, they create a directory instead of extracting it as a file, when
being extracted). One of the reasons that I did not explicitly say "directory
entry" in the wording added to the getEntry() method.

Thanks!
-Sherman



From alexander.zuev at oracle.com  Thu Sep 19 22:12:07 2013
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Fri, 20 Sep 2013 02:12:07 +0400
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
In-Reply-To: <523B6DF2.5000109@oracle.com>
References: <523B29A1.9000204@oracle.com> <523B6DF2.5000109@oracle.com>
Message-ID: 

Hi Naoto,

  I've checked that it works in C locale - since I'm setting LC_CTYPE to UTF-8 before calling both javac and java everything works as expected.

With best regards, 
/Alex

20.09.2013, ? 1:34, Naoto Sato  ???????(?):

> Hi Alex,
> 
> Should the test case also check the encoding of the platform? Does it work under the environment where the encoding is, say US-ASCII?
> 
> Naoto
> 
> On 9/19/13 9:43 AM, Alexander Zuev wrote:
>> Hi,
>> 
>>   please review my fix for 8025076: Fix for JDK-8017248 breaks jprt
>> submission for non-unicode locales
>> 
>>   The idea of the fix is to replace test case with the complex file
>> name in it by the
>> test that generates and compiles such file at the run time.
>> 
>>   The webrev can be found at:
>> http://cr.openjdk.java.net/~kizune/8025076/webrev.04/
>> 
>> With best regards,
>> /Alex
> 


From eric.mccorkle at oracle.com  Thu Sep 19 22:15:36 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 19 Sep 2013 18:15:36 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <523A7973.4010909@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
	<52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com>
	<523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com>
	<523A7973.4010909@oracle.com>
Message-ID: <523B7788.1070907@oracle.com>

The webrev has been updated with Joe's comments addressed.

On 09/19/13 00:11, David Holmes wrote:
> On 19/09/2013 9:59 AM, Eric McCorkle wrote:
>> This still needs to be reviewed.
> 
> You seem to have ignored Joe's comments regarding the change to Modifier
> being incorrect.
> 
> David
> 
>> On 09/16/13 14:50, Eric McCorkle wrote:
>>> I pulled the class files into byte array constants, as a temporary
>>> measure until a viable method for testing bad class files is developed.
>>>
>>> The webrev has been refreshed.  The class files will be taken out before
>>> I push.
>>>
>>> http://cr.openjdk.java.net/~emc/8020981/
>>>
>>> On 09/13/13 20:48, Joe Darcy wrote:
>>>> To avoid storing binaries in Hg, you could try something like:
>>>>
>>>> * uuencode / ascii armor the class file
>>>> * convert to byte array in the test
>>>> * load classes from byte array
>>>>
>>>> -Joe
>>>>
>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote:
>>>>> I did it by hand with emacs.
>>>>>
>>>>> I would really rather tackle the bad class files for testing issue
>>>>> once
>>>>> and for all, the Right Way (tm).  But with ZBB looming, now is not the
>>>>> time to do it.
>>>>>
>>>>> Hence, I have created this task
>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674
>>>>>
>>>>> I also just created this one:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812
>>>>>
>>>>> On 09/13/13 13:54, Peter Levart wrote:
>>>>>> Hi Eric,
>>>>>>
>>>>>> How did you create those class files? By hand using a HEX editor? Did
>>>>>> you create a program that patched the original class file? If the
>>>>>> later
>>>>>> is the case, you could pack that patching logic inside a custom
>>>>>> ClassLoader...
>>>>>>
>>>>>> To hacky? Dependent on future changes of javac? At least the "bad
>>>>>> name"
>>>>>> patching could be performed trivially and reliably, I think:
>>>>>> search and
>>>>>> replace with same-length string.
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>>>>>>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>>>>>>
>>>>>>> I have already filed a task for test development post ZBB to
>>>>>>> develop a
>>>>>>> solution for generating bad class files.  I'd prefer to file a
>>>>>>> follow-up
>>>>>>> to this to add the bad class file tests when that's done.
>>>>>>>
>>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>>>>>>>> I think the right thing to do is to include the original compiling
>>>>>>>> source in a comment, together with a comment on how you modify
>>>>>>>> them, and then the result as a byte array.
>>>>>>>>
>>>>>>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>>>>>>
>>>>>>>> cheers
>>>>>>>> /Joel
>>>>>>>>
>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> There is no simple means of generating bad class files for
>>>>>>>>> testing.
>>>>>>>>> This is a huge deficiency in our testing abilities.
>>>>>>>>>
>>>>>>>>> If these class files shouldn't go in, then I'm left with no choice
>>>>>>>>> but
>>>>>>>>> to check in no test for this patch.
>>>>>>>>>
>>>>>>>>> However, anyone can run the test I've provided with the class
>>>>>>>>> files and
>>>>>>>>> see that it works.
>>>>>>>>>
>>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>>>>>>>> Hi Eric,
>>>>>>>>>>
>>>>>>>>>> IIRC we don't check in classfiles into the repo.
>>>>>>>>>>
>>>>>>>>>> I'm not sure how we handle testing of broken class-files in jdk,
>>>>>>>>>> but ASM might be an option, or storing the class file as an
>>>>>>>>>> embedded byte array in the test.
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> /Joel
>>>>>>>>>>
>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> A new webrev is posted (and crucible updated), which actually
>>>>>>>>>>> validates
>>>>>>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>>>>>>
>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review this patch, which implements correct behavior for
>>>>>>>>>>>> the
>>>>>>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>>>>>>
>>>>>>>>>>>> The bug report is here:
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>>>>>>
>>>>>>>>>>>> The webrev is here:
>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>>>>>>
>>>>>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Eric
>>>>>>>>>>>>
>>>>>>>>> 
>>>>

From naoto.sato at oracle.com  Thu Sep 19 23:14:30 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 19 Sep 2013 16:14:30 -0700
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
In-Reply-To: 
References: <523B29A1.9000204@oracle.com> <523B6DF2.5000109@oracle.com>
	
Message-ID: <523B8556.7010007@oracle.com>

Thanks for checking. Looks good to me.

Naoto

On 9/19/13 3:12 PM, Alexander Zuev wrote:
> Hi Naoto,
>
>    I've checked that it works in C locale - since I'm setting LC_CTYPE to UTF-8 before calling both javac and java everything works as expected.
>
> With best regards,
> /Alex
>
> 20.09.2013, ? 1:34, Naoto Sato  ???????(?):
>
>> Hi Alex,
>>
>> Should the test case also check the encoding of the platform? Does it work under the environment where the encoding is, say US-ASCII?
>>
>> Naoto
>>
>> On 9/19/13 9:43 AM, Alexander Zuev wrote:
>>> Hi,
>>>
>>>    please review my fix for 8025076: Fix for JDK-8017248 breaks jprt
>>> submission for non-unicode locales
>>>
>>>    The idea of the fix is to replace test case with the complex file
>>> name in it by the
>>> test that generates and compiles such file at the run time.
>>>
>>>    The webrev can be found at:
>>> http://cr.openjdk.java.net/~kizune/8025076/webrev.04/
>>>
>>> With best regards,
>>> /Alex
>>



From kumar.x.srinivasan at oracle.com  Thu Sep 19 23:20:00 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 19 Sep 2013 16:20:00 -0700
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
In-Reply-To: <523B29A1.9000204@oracle.com>
References: <523B29A1.9000204@oracle.com>
Message-ID: <523B86A0.9080904@oracle.com>

Hi Alex,

The class can be compiled into the current directory (scratch), this 
will  eliminate:
a. the deletion of the files and allow jtreg to clean out the scratch 
directory
b. uses of  TEST_CLASSES_DIR.getAbsolutePath().

Thanks
Kumar



> Hi,
>
>   please review my fix for 8025076: Fix for JDK-8017248 breaks jprt 
> submission for non-unicode locales
>
>   The idea of the fix is to replace test case with the complex file 
> name in it by the
> test that generates and compiles such file at the run time.
>
>   The webrev can be found at: 
> http://cr.openjdk.java.net/~kizune/8025076/webrev.04/
>
> With best regards,
> /Alex



From paul.sandoz at oracle.com  Fri Sep 20 00:54:57 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 20 Sep 2013 00:54:57 +0000
Subject: hg: jdk8/tl/jdk: 8025002:
	"".codePoints().sorted().iterator().hasNext() causes
	NegativeArraySizeException
Message-ID: <20130920005511.4E322629AF@hg.openjdk.java.net>

Changeset: f36714707c38
Author:    psandoz
Date:      2013-09-18 10:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f36714707c38

8025002: "".codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException
Reviewed-by: henryjen, alanb

! src/share/classes/java/lang/CharSequence.java
! test/java/lang/CharSequence/DefaultTest.java



From jonathan.gibbons at oracle.com  Fri Sep 20 02:19:30 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 20 Sep 2013 02:19:30 +0000
Subject: hg: jdk8/tl/langtools: 8025110: TreeCopier does not correctly copy
	LabeledStatementTree
Message-ID: <20130920021934.36083629B5@hg.openjdk.java.net>

Changeset: 9a75bdb249a2
Author:    jjg
Date:      2013-09-19 19:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9a75bdb249a2

8025110: TreeCopier does not correctly copy LabeledStatementTree
Reviewed-by: jjg
Contributed-by: Werner Dietl 

! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java



From sundararajan.athijegannathan at oracle.com  Fri Sep 20 03:41:39 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Fri, 20 Sep 2013 03:41:39 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20130920034143.8F0EC629B7@hg.openjdk.java.net>

Changeset: f954d3f4d192
Author:    sundar
Date:      2013-09-19 13:34 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f954d3f4d192

8025048: true as case label results in ClassCastException
Reviewed-by: lagergren

! src/jdk/nashorn/internal/codegen/Attr.java
+ test/script/basic/JDK-8025048-2.js
+ test/script/basic/JDK-8025048.js

Changeset: 740b1133f1b6
Author:    hannesw
Date:      2013-09-19 15:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/740b1133f1b6

8023154: compileAllTests fails with: 2 tests failed to compile
Reviewed-by: sundar, jlaskey

! make/build-benchmark.xml
! make/build.xml
! make/project.properties

Changeset: 821b0b610861
Author:    sundar
Date:      2013-09-19 21:20 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/821b0b610861

8025080: Object literal getter, setter function with number format property name results in ClassFormatError
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/ir/debug/JSONWriter.java
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8025080.js
+ test/script/basic/JDK-8025080.js.EXPECTED
! test/script/basic/parser/objectLitExpr.js.EXPECTED

Changeset: 18d64bc4937d
Author:    sundar
Date:      2013-09-19 23:48 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/18d64bc4937d

8025090: 'while' statement with 'test' using var before being declared in body results in VerifyError
Reviewed-by: jlaskey

! src/jdk/nashorn/internal/ir/WhileNode.java
+ test/script/basic/JDK-8025090.js



From paul.sandoz at oracle.com  Fri Sep 20 03:55:49 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 20 Sep 2013 03:55:49 +0000
Subject: hg: jdk8/tl/jdk: 8024405: Spliterators.spliterator should support
	CONCURRENT characteristic
Message-ID: <20130920035602.ABB36629B9@hg.openjdk.java.net>

Changeset: 0ef7ddef9de0
Author:    psandoz
Date:      2013-09-19 20:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ef7ddef9de0

8024405: Spliterators.spliterator should support CONCURRENT characteristic
Reviewed-by: martin

! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/Spliterators.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java



From iris.clark at oracle.com  Fri Sep 20 05:59:53 2013
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 19 Sep 2013 22:59:53 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to
	build the class library on AIX
In-Reply-To: <523A27A8.404@oracle.com>
References: 
	
	<523A27A8.404@oracle.com>
Message-ID: 

Hi, Volker.

Just wanted to say that in addition to preparing for JavaOne (next week!), we're also busy fixing bugs in anticipation of JDK 8 ZBB milestone on 24 Oct [1].

Thanks,
iris

[1]: http://openjdk.java.net/projects/jdk8/milestones

-----Original Message-----
From: Phil Race 
Sent: Wednesday, September 18, 2013 3:23 PM
To: Volker Simonis
Cc: serviceability-dev at openjdk.java.net; 2d-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Java Core Libs; awt-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX

Volker,

I've skimmed the client related changes - mostly based on the descriptions.
I'll look in more detail as soon as I can after JavaOne. We also have some engineers out on vacation who might want to look at these too.

A couple of things that stood out :
"On AIX, fontconfig is not a standard package supported by IBM."
I am surprised AIX does not support fontconfig.
That is something IBM should reconsider as its hard to imagine a modern Unix based system working without it ..

Very basic start for AIX -  feel free to complete ..
  169  */
  170 static char *fullAixFontPath[] = { ...

I'd really like to see it completed but these days that's largely a fall back for no fontconfig.

/* AIX does not provide the 'dladdr' function. But fortunately, we've
   42  * already implemented it in the HotSpot, because we need it there as
   43  * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}).

Whilst this is in "ifdef AIX" this reliance on an exported hotspot function sounds hacky. What actual requirement is there that the AIX class libraries be so tightly-coupled with that VM?
There is no contract there.

-phil.



On 9/16/2013 12:30 PM, Volker Simonis wrote:
> Resending this to more lists as requested by Alan Bateman with the 
> kind request to anybody to review the parts for which he feels
> responsible:)
>
> For those not up to date, this change is part of the ongoing 
> PowerPC/AIX Porting Project:
> http://openjdk.java.net/projects/ppc-aix-port
> https://wiki.openjdk.java.net/display/PPCAIXPort
> http://openjdk.java.net/jeps/175
>
> Please send reviews to all currently included recipients.
>
> Thank you and best regards,
> Volker
>
>
> ---------- Forwarded message ----------
> From: *Volker Simonis*
> Date: Monday, September 16, 2013
> Subject: RFR(L): 8024854: Basic changes and files to build the class 
> library on AIX
> To: "ppc-aix-port-dev at openjdk.java.net
> " 
>  >, Java Core Libs 
>  >
>
>
>         Hi,
>
> could you please review the following webrev which contains the basic 
> changes and files needed in the 'jdk' repository in order to build the 
> OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854
> 
>
> This change together with "8024265: Enable new build on AIX (jdk part) 
> " allows 
> it to configure and completely build the staging repository on AIX 5.3 
> and 7.1 with the following command:
>
> configure --with-boot-jdk= --with-jvm-variants=core 
> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
> --x-includes=/opt/freeware/include
>
> Below you can find the changes and additions I've done, sorted by 
> file. Most of them are just additions which are only active during the 
> AIX build anyway or simple changes where AIX has been added to 
> conditions which already check for Linux and/or Solaris. The files 
> with the biggest changes which you're probably want to look on more 
> thoroughly are 'src/solaris/native/java/net/NetworkInterface.c' and 
> 'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change 
> anything on the current OpenJDK platforms as well.
>
> Notice that there are still some files and some functionality missing 
> from the current change (notably NIO) but it still yields a running 
> JDK which can execute "HelloWorld" on the command line and as AWT 
> application. I've intentionally tried to keep this initial change as 
> simple as possible (with respect tot shared changes) in order to get 
> it reviewed as fast as possible. The missing parts can then be added 
> later on, grouped by logical topics, to simplify the review process.
>
> Thank you and best regards,
>
> Volker
>
>
>         src/share/bin/jli_util.h
>
>   * Define |JLI_Lseek| on AIX.
>
>
>         src/share/lib/security/java.security-aix
>
>   * Provide default |java.security-aix| for AIX.
>
>
>         src/share/native/sun/awt/medialib/mlib_sys.c
>
>   * |malloc| always returns 8-byte aligned pointers on AIX as well.
>
>
>         src/share/native/sun/awt/medialib/mlib_types.h
>
>   * Add AIX to the list of known platforms.
>
>
>         src/share/native/sun/font/layout/KernTable.cpp
>
>   * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
>     too common and may be defined in other headers as well as on the
>     command line and |xlc| bails out on macro redefinitions with a
>     different value.
>
>
>         src/share/native/sun/security/ec/impl/ecc_impl.h
>
>   * Define required types and macros on AIX.
>
>
>         src/solaris/back/exec_md.c
>
>   * AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
>
>         src/solaris/bin/java_md_solinux.c,
>         src/solaris/bin/java_md_solinux.h
>
>   * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>   * Always use |LD_LIBRARY_PATH| macro instead of using the string
>     "|LD_LIBRARY_PATH|" directly to cope with different library path
>     names.
>   * Add |jre/lib//jli| to the standard library search path on
>     AIX because the AIX linker doesn't support the |-rpath| option.
>   * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in
>     this case, AIX behaves like Linux.
>
>
>         
> src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>   * Provide basic |fontconfig.properties|for AIX.
>
>
>         src/solaris/classes/java/lang/UNIXProcess.java.aix,
>         src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
>         src/solaris/classes/sun/tools/attach/AixVirtualMachine.java
>
>   * Provide AIX specific Java versions, mostly based on the
>     corresponding Linux versions.
>
>
>         src/solaris/demo/jvmti/hprof/hprof_md.c
>
>   * Add AIX support. AIX mostly behaves like Linux, with the one
>     exception that it has no |dladdr| functionality.
>   * Implement |dladdr| functionality for AIX.
>
>
>         src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>   * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>
>
>         src/solaris/native/common/jdk_util_md.h
>
>   * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>
>
>         src/solaris/native/java/io/io_util_md.c
>
>   * AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
>
>         src/solaris/native/java/net/NetworkInterface.c
>
>   * Add AIX support into the Linux branch because AIX mostly behaves
>     like AIX for IPv4.
>   * AIX needs a special function to enumerate IPv6 interfaces and to
>     query the MAC address.
>
>
>         src/solaris/native/java/net/PlainSocketImpl.c
>
>   * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL|
>     if the socket is closed. The default error message is then confusing.
>
>
>         src/solaris/native/java/net/linux_close.c,
>         src/share/native/java/net/net_util.c
>
>   * Also use the file and socket wrappers on AIX.
>   * Add initialization of some previously uninitialized data structures.
>   * On AIX we don't have |__attribute((constructor))| so we need to
>     initialize manually (from |JNI_OnLoad()| in
>     'src/share/native/java/net/net_util.c'
>
>
>         src/solaris/native/java/net/net_util_md.h
>
>   * AIX needs the same workaround for I/O cancellation like Linux and
>     MacOSX.
>
>
>         src/solaris/native/java/util/TimeZone_md.c
>
>   * Currently on AIX the only way to get the platform time zone is to
>     read it from the |TZ| environment variable.
>
>
>         src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>   * There's no |dladdr| on AIX, but we can use the implementation from
>     the HotSpot in this case because |libjvm.so| will be always loaded
>     before the AWT.
>
>
>         src/solaris/native/sun/awt/fontpath.c
>
>   * Add AIX specific fontpath settings and library search paths for
>     |libfontconfig.so|.
>
>
>         src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>   * Only define |MIN| and |MAX| if they're not already defined because
>     xlc on AIX fails on macro redefinitions.
>
>
>         src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>   * Handle AIX like Solaris.
>
>
>         src/solaris/native/sun/nio/ch/Net.c
>
>   * Add AIX-specific includes and constant definitions.
>   * On AIX "socket extensions for multicast source filters" support
>     depends on the OS version. Check for this and throw appropriate
>     exceptions if it requested but not supported. This is needed to
>     pass
>     
> JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multica
> st
>
>
>         src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>   * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>
>
>         src/solaris/native/sun/tools/attach/AixVirtualMachine.c
>
>   * AIX version mostly derived from the corresponding Linux version.
>
>



From mandy.chung at oracle.com  Fri Sep 20 07:09:19 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Sep 2013 00:09:19 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
Message-ID: <523BF49F.2030300@oracle.com>

On 9/18/2013 9:22 AM, Nick Williams wrote:
> Okay. Again, sorry for my absence. This wraps up my feedback for now. I now await responses from Mandy.
>
> On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
>
>> You asked at a good time.  I discussed this with John Rose last couple days on this topic.  He has been thinking about how to do fillInStackTrace performantly and walk the stack with laziness and frame filtering.  The current implementation fills the entire stack trace while Groovy and Log4j use case filters the frames of some specific classes until it reaches the first one not being filtered.
>>
>> He suggests to consider an API taking a callback shape (e.g. Function, Consumer, etc) that Remi Forax suggested at one time that allows the JVM to do something.   I will work with John to work out the details and determine the interface between VM and library and hash out issues.
>>
>> I like the callback shape idea and hope to work out a proposal soon.

This will give you an idea the API we are thinking about:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/walkstack-webrev/

More work to do as we are working on the VM interface and 
implementation.  We'll post an update when it's ready.

Stack is a "stream" that allows you to walk partial stack (e.g. find 
caller) or full stack trace (e.g. throwable). The filtering and mapping 
operations are lazy to avoid having the VM eagerly copying the entire 
stack trace data even for the short reach case (like Groovy and Log4j).

The API takes a predicate, consumer or function so that the caller will 
only need to carry the data it needs.  There is no method to return the 
stream of stack frames; otherwise, the returned stack frame stream would 
be a snapshot and require to do fillInStackTrace and get the entire 
stack trace. The API can also take a depth limit to control the number 
of elements and can use it as optimization (currently the VM has a 
predefined max number of stack frames returned in a stack trace).

I have modified java.util.logging.LogRecord to infer the caller using 
the new API (much simpler):

     StackTraceElement frame =
         Thread.firstCaller(e -> {return !isLoggerImplFrame(e.getClassName()); },
                            StackFrameInfo::stackTraceElement);

Replacement for getCallerClass()
     Class c = Thread.getCaller(StackFrameInfo::getDeclaringClass);

Replacement for traversing the stack with getCallerClass(int depth)
     Thread.walkStack(e -> doSomething(e));

We'll be busy at JavaOne next week and if you don't hear from me, that 
explains why.

Mandy


From nicholas+openjdk at nicholaswilliams.net  Fri Sep 20 07:28:12 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Fri, 20 Sep 2013 02:28:12 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523BF49F.2030300@oracle.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
Message-ID: 


On Sep 20, 2013, at 2:09 AM, Mandy Chung wrote:

> On 9/18/2013 9:22 AM, Nick Williams wrote:
>> Okay. Again, sorry for my absence. This wraps up my feedback for now. I now await responses from Mandy.
>> 
>> On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
>> 
>>> You asked at a good time.  I discussed this with John Rose last couple days on this topic.  He has been thinking about how to do fillInStackTrace performantly and walk the stack with laziness and frame filtering.  The current implementation fills the entire stack trace while Groovy and Log4j use case filters the frames of some specific classes until it reaches the first one not being filtered.
>>> 
>>> He suggests to consider an API taking a callback shape (e.g. Function, Consumer, etc) that Remi Forax suggested at one time that allows the JVM to do something.   I will work with John to work out the details and determine the interface between VM and library and hash out issues.
>>> 
>>> I like the callback shape idea and hope to work out a proposal soon.
> 
> This will give you an idea the API we are thinking about:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/walkstack-webrev/

Just to be clear, this means the patch I worked on for a month has been completely junked. Correct? Awesome.

> More work to do as we are working on the VM interface and implementation.  We'll post an update when it's ready.
> 
> Stack is a "stream" that allows you to walk partial stack (e.g. find caller) or full stack trace (e.g. throwable). The filtering and mapping operations are lazy to avoid having the VM eagerly copying the entire stack trace data even for the short reach case (like Groovy and Log4j).
> 
> The API takes a predicate, consumer or function so that the caller will only need to carry the data it needs.  There is no method to return the stream of stack frames; otherwise, the returned stack frame stream would be a snapshot and require to do fillInStackTrace and get the entire stack trace. The API can also take a depth limit to control the number of elements and can use it as optimization (currently the VM has a predefined max number of stack frames returned in a stack trace).

This is all well and good, but some of us just need a simple array. This seems like over-engineering. I just want an array of StackFrameInfos/StackTraceFrames.

> I have modified java.util.logging.LogRecord to infer the caller using the new API (much simpler):
> 
>    StackTraceElement frame =
>        Thread.firstCaller(e -> {return !isLoggerImplFrame(e.getClassName()); },
>                           StackFrameInfo::stackTraceElement);
> 
> Replacement for getCallerClass()
>    Class c = Thread.getCaller(StackFrameInfo::getDeclaringClass);
> 
> Replacement for traversing the stack with getCallerClass(int depth)
>    Thread.walkStack(e -> doSomething(e));

This looks beautiful for Java 8, sure. Now try doing these same things in a library compiled for Java 6 but made to be compatible with Java 8 and so all of this has to happen via reflection. Suddenly it's nightmarish.

Finally, none of the points I made and questions I raised a couple of days ago have been addressed (see five emails on September 18). Particularly, the security checks bother me and we _still_ have no explanation as to why they're necessary.

Nick



From ivan.gerasimov at oracle.com  Fri Sep 20 07:51:54 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 20 Sep 2013 11:51:54 +0400
Subject: remove 5u-cpu 8021334
Message-ID: <523BFE9A.6010700@oracle.com>




From staffan.larsen at oracle.com  Fri Sep 20 07:55:52 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 20 Sep 2013 09:55:52 +0200
Subject: RFR(L): 8024854: Basic changes and files to build the class
	library on AIX
In-Reply-To: 
References: 
	
Message-ID: 

Volker,

The serviceability-related changes look ok to me (not a Reviewer).

/Staffan

On 16 sep 2013, at 21:30, Volker Simonis  wrote:

> Resending this to more lists as requested by Alan Bateman with the kind request to anybody to review the parts for which he feels responsible:)
> 
> For those not up to date, this change is part of the ongoing PowerPC/AIX Porting Project:
> http://openjdk.java.net/projects/ppc-aix-port
> https://wiki.openjdk.java.net/display/PPCAIXPort
> http://openjdk.java.net/jeps/175
> 
> Please send reviews to all currently included recipients.
> 
> Thank you and best regards,
> Volker
> 
> 
> ---------- Forwarded message ----------
> From: Volker Simonis 
> Date: Monday, September 16, 2013
> Subject: RFR(L): 8024854: Basic changes and files to build the class library on AIX
> To: "ppc-aix-port-dev at openjdk.java.net" , Java Core Libs 
> 
> 
> Hi,
> 
> could you please review the following webrev which contains the basic changes and files needed in the 'jdk' repository in order to build the OpenJDK on AIX:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/8024854
> This change together with "8024265: Enable new build on AIX (jdk part)" allows it to configure and completely build the staging repository on AIX 5.3 and 7.1 with the following command:
> 
> configure --with-boot-jdk= --with-jvm-variants=core --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include --x-includes=/opt/freeware/include
> 
> Below you can find the changes and additions I've done, sorted by file. Most of them are just additions which are only active during the AIX build anyway or simple changes where AIX has been added to conditions which already check for Linux and/or Solaris. The files with the biggest changes which you're probably want to look on more thoroughly are 'src/solaris/native/java/net/NetworkInterface.c' and 'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change anything on the current OpenJDK platforms as well.
> 
> Notice that there are still some files and some functionality missing from the current change (notably NIO) but it still yields a running JDK which can execute "HelloWorld" on the command line and as AWT application. I've intentionally tried to keep this initial change as simple as possible (with respect tot shared changes) in order to get it reviewed as fast as possible. The missing parts can then be added later on, grouped by logical topics, to simplify the review process.
> Thank you and best regards,
> 
> Volker
> 
> src/share/bin/jli_util.h
> 
> Define JLI_Lseek on AIX.
> src/share/lib/security/java.security-aix
> 
> Provide default java.security-aix for AIX.
> src/share/native/sun/awt/medialib/mlib_sys.c
> 
> malloc always returns 8-byte aligned pointers on AIX as well.
> src/share/native/sun/awt/medialib/mlib_types.h
> 
> Add AIX to the list of known platforms.
> src/share/native/sun/font/layout/KernTable.cpp
> 
> Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common and may be defined in other headers as well as on the command line and xlc bails out on macro redefinitions with a different value.
> src/share/native/sun/security/ec/impl/ecc_impl.h
> 
> Define required types and macros on AIX.
> src/solaris/back/exec_md.c
> 
> AIX behaves like Linux in this case so check for it in the Linux branch.
> src/solaris/bin/java_md_solinux.c,
> src/solaris/bin/java_md_solinux.h
> 
> On AIX LD_LIBRARY_PATH is called LIBPATH
> Always use LD_LIBRARY_PATH macro instead of using the string "LD_LIBRARY_PATH" directly to cope with different library path names.
> Add jre/lib//jli to the standard library search path on AIX because the AIX linker doesn't support the -rpath option.
> Replace #ifdef __linux__ by #ifndef __solaris__ because in this case, AIX behaves like Linux.
> src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties
> 
> Provide basic fontconfig.propertiesfor AIX.
> src/solaris/classes/java/lang/UNIXProcess.java.aix,
> src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
> src/solaris/classes/sun/tools/attach/AixVirtualMachine.java
> 
> Provide AIX specific Java versions, mostly based on the corresponding Linux versions.
> src/solaris/demo/jvmti/hprof/hprof_md.c
> 
> Add AIX support. AIX mostly behaves like Linux, with the one exception that it has no dladdr functionality.
> Implement dladdr functionality for AIX.
> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
> 
> Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).
> src/solaris/native/common/jdk_util_md.h
> 
> Add AIX definitions of the ISNANF and ISNAND macros.
> src/solaris/native/java/io/io_util_md.c
> 
> AIX behaves like Linux in this case so check for it in the Linux branch.
> src/solaris/native/java/net/NetworkInterface.c
> 
> Add AIX support into the Linux branch because AIX mostly behaves like AIX for IPv4.
> AIX needs a special function to enumerate IPv6 interfaces and to query the MAC address.
> src/solaris/native/java/net/PlainSocketImpl.c
> 
> On AIX (like on Solaris) setsockopt will set errno to EINVAL if the socket is closed. The default error message is then confusing.
> src/solaris/native/java/net/linux_close.c,
> src/share/native/java/net/net_util.c
> 
> Also use the file and socket wrappers on AIX.
> Add initialization of some previously uninitialized data structures.
> On AIX we don't have __attribute((constructor)) so we need to initialize manually (from JNI_OnLoad() in 'src/share/native/java/net/net_util.c'
> src/solaris/native/java/net/net_util_md.h
> 
> AIX needs the same workaround for I/O cancellation like Linux and MacOSX.
> src/solaris/native/java/util/TimeZone_md.c
> 
> Currently on AIX the only way to get the platform time zone is to read it from the TZ environment variable.
> src/solaris/native/sun/awt/awt_LoadLibrary.c
> 
> There's no dladdr on AIX, but we can use the implementation from the HotSpot in this case because libjvm.so will be always loaded before the AWT.
> src/solaris/native/sun/awt/fontpath.c
> 
> Add AIX specific fontpath settings and library search paths for libfontconfig.so.
> src/solaris/native/sun/java2d/x11/X11SurfaceData.c
> 
> Only define MIN and MAX if they're not already defined because xlc on AIX fails on macro redefinitions.
> src/solaris/native/sun/java2d/x11/XRBackendNative.c
> 
> Handle AIX like Solaris.
> src/solaris/native/sun/nio/ch/Net.c
> 
> Add AIX-specific includes and constant definitions.
> On AIX "socket extensions for multicast source filters" support depends on the OS version. Check for this and throw appropriate exceptions if it requested but not supported. This is needed to pass JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
> src/solaris/native/sun/security/pkcs11/j2secmod_md.c
> 
> Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.
> src/solaris/native/sun/tools/attach/AixVirtualMachine.c
> 
> AIX version mostly derived from the corresponding Linux version.
> 



From jhuxhorn at googlemail.com  Fri Sep 20 08:50:57 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Fri, 20 Sep 2013 10:50:57 +0200
Subject: =?UTF-8?Q?Re=3A_=5BPATCH=5D_4851444=3A_Exposing_sun.reflect.Reflection=23getCallerClass_as_a_public_API_in_Java_8?=
In-Reply-To: 
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
Message-ID: 

On 20. September 2013 at 09:28:52, Nick Williams (nicholas+openjdk at nicholaswilliams.net) wrote:
> This will give you an idea the API we are thinking about:?
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/walkstack-webrev/?

Just to be clear, this means the patch I worked on for a month has been completely junked. Correct? Awesome.
I'm less than impressed how all this is turning out.

"I expect that at this stage, patches speak louder than words :)"
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019376.html

I was very happy that Nick actually did just that and proposed a solution. His proposals have been discussed on this list, he listened to the feedback and provided an implementation based on all of that. Thanks for the effort.

?

> More work to do as we are working on the VM interface and implementation. We'll post an update when it's ready.?
>?
> Stack is a "stream" that allows you to walk partial stack (e.g. find caller) or full stack trace (e.g. throwable). The filtering and mapping operations are lazy to avoid having the VM eagerly copying the entire stack trace data even for the short reach case (like Groovy and Log4j).?
>?
> The API takes a predicate, consumer or function so that the caller will only need to carry the data it needs. There is no method to return the stream of stack frames; otherwise, the returned stack frame stream would be a snapshot and require to do fillInStackTrace and get the entire stack trace. The API can also take a depth limit to control the number of elements and can use it as optimization (currently the VM has a predefined max number of stack frames returned in a stack trace).?

This is all well and good, but some of us just need a simple array. This seems like over-engineering. I just want an array of StackFrameInfos/StackTraceFrames.
+1

> I have modified java.util.logging.LogRecord to infer the caller using the new API (much simpler):?
>?
> StackTraceElement frame =?
> Thread.firstCaller(e -> {return !isLoggerImplFrame(e.getClassName()); },?
> StackFrameInfo::stackTraceElement);?
>?
> Replacement for getCallerClass()?
> Class c = Thread.getCaller(StackFrameInfo::getDeclaringClass);?
>?
> Replacement for traversing the stack with getCallerClass(int depth)?
> Thread.walkStack(e -> doSomething(e));?

This looks beautiful for Java 8, sure. Now try doing these same things in a library compiled for Java 6 but made to be compatible with Java 8 and so all of this has to happen via reflection. Suddenly it's nightmarish.
+1 again.

This API is great. Lambdas, yay! Nice code. Very awesome & clean.

But I have serious doubts that *this* is going to be more efficient than just iterating over an array.

Feel free to add all that functionality but all we are asking for right now is access to the call stack array in a way that is as fast, or, ideally, even faster than using the current getCallerClass(int) method. Performance is the main reason for this whole discussion.

And it is very, very crucial that all of this can be done via (Java 6) reflection so that code will be able to use sun.reflect.Reflection up to J7 and the new API after that...

Joern.


From blackdrag at gmx.org  Fri Sep 20 08:57:47 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 10:57:47 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: 
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
Message-ID: <523C0E0B.7040407@gmx.org>

Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
> This is all well and good, but some of us just need a simple array. This seems like over-engineering. I just want an array of StackFrameInfos/StackTraceFrames.

if you need the full stack, then misusing a Predicate and a dummy 
Consumer to collect everything looks a lot like not intended use. The 
intended inability of lambdas to write to local variables outside the 
lambda is not helping here to avoid anonymous inner classes. So what was 
a simple method call, will look really awful - I agree. But if you would 
have designed the API that uses the information now, rather than fitting 
the old API from the frame work and the new API here together, then this 
problem would most probably not have appeared, since the structure would 
have been very different from the beginning.

>> I have modified java.util.logging.LogRecord to infer the caller using the new API (much simpler):
>>
>>     StackTraceElement frame =
>>         Thread.firstCaller(e -> {return !isLoggerImplFrame(e.getClassName()); },
>>                            StackFrameInfo::stackTraceElement);
>>
>> Replacement for getCallerClass()
>>     Class c = Thread.getCaller(StackFrameInfo::getDeclaringClass);
>>
>> Replacement for traversing the stack with getCallerClass(int depth)
>>     Thread.walkStack(e -> doSomething(e));
>
> This looks beautiful for Java 8, sure. Now try doing these same things in a library compiled for Java 6 but made to be compatible with Java 8 and so all of this has to happen via reflection. Suddenly it's nightmarish.

With a new class to contain the information it will look like a 
nightmare even if you get an array and do not have that callback style. 
What we will probably do is a kind of plugin that gets enabled if jdk8 
is used. That class will have to be compiled using jdk8 though. And in 
case of an older jdk the old implementation will be used

bye Jochen


-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From blackdrag at gmx.org  Fri Sep 20 08:58:20 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 10:58:20 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523BF49F.2030300@oracle.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
Message-ID: <523C0E2C.1030206@gmx.org>

Am 20.09.2013 09:09, schrieb Mandy Chung:
[...]
> Stack is a "stream" that allows you to walk partial stack (e.g. find
> caller) or full stack trace (e.g. throwable). The filtering and mapping
> operations are lazy to avoid having the VM eagerly copying the entire
> stack trace data even for the short reach case (like Groovy and Log4j).

and is there a link to StackStram too?
The Thread#walkStack methods don't really describe the behaviour of the 
consumer. Will the consumer applied only once, or multiple times? If 
only once, then to replace getCallerClass(int depth), you will need the 
version with the predicate, which will be difficult to realize with a 
simple lambda, since you will need to count as well.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From blackdrag at gmx.org  Fri Sep 20 09:04:09 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 11:04:09 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: 
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	
Message-ID: <523C0F89.80305@gmx.org>

Am 20.09.2013 10:50, schrieb J?rn Huxhorn:
[...]
> But I have serious doubts that *this* is going to be more efficient than just iterating over an array.

+1

> Feel free to add all that functionality but all we are asking for right now is access to the call stack array in a way that is as fast, or, ideally, even faster than using the current getCallerClass(int) method. Performance is the main reason for this whole discussion.

when it comes to getCallerClass(int) I see need for improvement in the 
API. But I see the patch as a draft only

> And it is very, very crucial that all of this can be done via (Java 6) reflection so that code will be able to use sun.reflect.Reflection up to J7 and the new API after that...

you mean you want to use the new API via Java6 reflection? Then there 
should be no new class to be used. Otherwise you will get crazy with 
writing out all the reflective calls. I think it is better to go with a 
plugin-like structure and write code for the new API with JDK8. I am of 
course aware, that this makes the build more complicated

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From staffan.larsen at oracle.com  Fri Sep 20 08:15:35 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Fri, 20 Sep 2013 08:15:35 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130920081633.6ECED629C8@hg.openjdk.java.net>

Changeset: 58fd427b454d
Author:    sla
Date:      2013-09-20 10:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58fd427b454d

8024985: com/sun/jdi/StepTest.java failed since jdk8b107
Reviewed-by: dcubed

! test/com/sun/jdi/ExceptionEvents.java
! test/com/sun/jdi/FilterNoMatch.java
! test/com/sun/jdi/JDIScaffold.java
! test/com/sun/jdi/PopAndStepTest.java
! test/com/sun/jdi/RepStep.java
! test/com/sun/jdi/TestScaffold.java

Changeset: 6a1c70e191d4
Author:    sla
Date:      2013-09-20 10:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a1c70e191d4

8024416: TESTBUG: com/sun/jdi/MethodEntryExitEvents.java: method entry count mismatch
Reviewed-by: dcubed

! test/com/sun/jdi/MethodEntryExitEvents.java



From peter.levart at gmail.com  Fri Sep 20 09:24:56 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Sep 2013 11:24:56 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: 
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
Message-ID: <523C1468.6020401@gmail.com>

On 09/20/2013 09:28 AM, Nick Williams wrote:
> On Sep 20, 2013, at 2:09 AM, Mandy Chung wrote:
>
>> On 9/18/2013 9:22 AM, Nick Williams wrote:
>>> Okay. Again, sorry for my absence. This wraps up my feedback for now. I now await responses from Mandy.
>>>
>>> On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
>>>
>>>> You asked at a good time.  I discussed this with John Rose last couple days on this topic.  He has been thinking about how to do fillInStackTrace performantly and walk the stack with laziness and frame filtering.  The current implementation fills the entire stack trace while Groovy and Log4j use case filters the frames of some specific classes until it reaches the first one not being filtered.
>>>>
>>>> He suggests to consider an API taking a callback shape (e.g. Function, Consumer, etc) that Remi Forax suggested at one time that allows the JVM to do something.   I will work with John to work out the details and determine the interface between VM and library and hash out issues.
>>>>
>>>> I like the callback shape idea and hope to work out a proposal soon.
>> This will give you an idea the API we are thinking about:
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/walkstack-webrev/
> Just to be clear, this means the patch I worked on for a month has been completely junked. Correct? Awesome.
>
>> More work to do as we are working on the VM interface and implementation.  We'll post an update when it's ready.
>>
>> Stack is a "stream" that allows you to walk partial stack (e.g. find caller) or full stack trace (e.g. throwable). The filtering and mapping operations are lazy to avoid having the VM eagerly copying the entire stack trace data even for the short reach case (like Groovy and Log4j).
>>
>> The API takes a predicate, consumer or function so that the caller will only need to carry the data it needs.  There is no method to return the stream of stack frames; otherwise, the returned stack frame stream would be a snapshot and require to do fillInStackTrace and get the entire stack trace. The API can also take a depth limit to control the number of elements and can use it as optimization (currently the VM has a predefined max number of stack frames returned in a stack trace).
> This is all well and good, but some of us just need a simple array. This seems like over-engineering. I just want an array of StackFrameInfos/StackTraceFrames.
>
>> I have modified java.util.logging.LogRecord to infer the caller using the new API (much simpler):
>>
>>     StackTraceElement frame =
>>         Thread.firstCaller(e -> {return !isLoggerImplFrame(e.getClassName()); },
>>                            StackFrameInfo::stackTraceElement);
>>
>> Replacement for getCallerClass()
>>     Class c = Thread.getCaller(StackFrameInfo::getDeclaringClass);
>>
>> Replacement for traversing the stack with getCallerClass(int depth)
>>     Thread.walkStack(e -> doSomething(e));
> This looks beautiful for Java 8, sure. Now try doing these same things in a library compiled for Java 6 but made to be compatible with Java 8 and so all of this has to happen via reflection. Suddenly it's nightmarish.

Hi,

Nick: You can always create a "facade" class that has a 
reflection-friendly API and compile it with JDK8. You load this class 
and use it via reflection if you detect JDK8 in runtime. It's just that 
the build procedure is more complicated (you need both JDK6/7 and JDK8 
compilers).

Mandy: I like the API. It covers the use-cases optimally. I can see how 
StackStreamcould be implemented with a single JNI -> Java callback per 
StackFrameInfo...  Why not using the same call-back principle for 
Throwable API too. Instead of implementing Throwable.walkStackTracein 
terms of getStackTrace it could be the other way around. For 
completeness, getCaller() and firstCaller() could also be added to 
Throwable although we don't yet have a use-case for that.


Regards, Peter

>
> Finally, none of the points I made and questions I raised a couple of days ago have been addressed (see five emails on September 18). Particularly, the security checks bother me and we _still_ have no explanation as to why they're necessary.
>
> Nick
>



From jhuxhorn at googlemail.com  Fri Sep 20 09:31:04 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Fri, 20 Sep 2013 11:31:04 +0200
Subject: =?UTF-8?Q?Re=3A_=5BPATCH=5D_4851444=3A_Exposing_sun.reflect.Reflection=23getCallerClass_as_a_public_API_in_Java_8?=
In-Reply-To: <523C0F89.80305@gmx.org>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	
	<523C0F89.80305@gmx.org>
Message-ID: 

On 20. September 2013 at 11:03:49, Jochen Theodorou (blackdrag at gmx.org) wrote:
Am 20.09.2013 10:50, schrieb J?rn Huxhorn:?
[...]?
> But I have serious doubts that *this* is going to be more efficient than just iterating over an array.?

+1?

> Feel free to add all that functionality but all we are asking for right now is access to the call stack array in a way that is as fast, or, ideally, even faster than using the current getCallerClass(int) method. Performance is the main reason for this whole discussion.?

when it comes to getCallerClass(int) I see need for improvement in the?
API. But I see the patch as a draft only?

> And it is very, very crucial that all of this can be done via (Java 6) reflection so that code will be able to use sun.reflect.Reflection up to J7 and the new API after that...?

you mean you want to use the new API via Java6 reflection? Then there?
should be no new class to be used. Otherwise you will get crazy with?
writing out all the reflective calls. I think it is better to go with a?
plugin-like structure and write code for the new API with JDK8. I am of?
course aware, that this makes the build more complicated?
I mean that it must be possible to handle the call by means of simple <= JDK1.5 Class.forName("StackTraceFrame") and clazz.getMethod(..) and method.invoke(..).

That way, the only thing to care about is a ClassNotFoundException and the "method" could be kept for any future calls. The class file responsible for the call should be able to have?49.0 or 50.0 since handling a ClassNotFoundException is less hardcore than catching a?UnsupportedClassVersionError.

I'd consider a jar file containing files with more than one java class version way more brittle than any alternative.



Joern


From peter.levart at gmail.com  Fri Sep 20 09:34:47 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Sep 2013 11:34:47 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C0E0B.7040407@gmx.org>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C0E0B.7040407@gmx.org>
Message-ID: <523C16B7.7080708@gmail.com>

On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
> Am 20.09.2013 09:28, schrieb Nick Williams:
> [...]
>> This is all well and good, but some of us just need a simple array. 
>> This seems like over-engineering. I just want an array of 
>> StackFrameInfos/StackTraceFrames.
>
> if you need the full stack, then misusing a Predicate and a dummy 
> Consumer to collect everything looks a lot like not intended use. The 
> intended inability of lambdas to write to local variables outside the 
> lambda is not helping here to avoid anonymous inner classes. So what 
> was a simple method call, will look really awful - I agree.

List frames = new ArrayList<>();
Thread.walkStack(frames::add);

No so awfull.

Regards, Peter

> But if you would have designed the API that uses the information now, 
> rather than fitting the old API from the frame work and the new API 
> here together, then this problem would most probably not have 
> appeared, since the structure would have been very different from the 
> beginning.
>
>>> I have modified java.util.logging.LogRecord to infer the caller 
>>> using the new API (much simpler):
>>>
>>>     StackTraceElement frame =
>>>         Thread.firstCaller(e -> {return 
>>> !isLoggerImplFrame(e.getClassName()); },
>>>                            StackFrameInfo::stackTraceElement);
>>>
>>> Replacement for getCallerClass()
>>>     Class c = Thread.getCaller(StackFrameInfo::getDeclaringClass);
>>>
>>> Replacement for traversing the stack with getCallerClass(int depth)
>>>     Thread.walkStack(e -> doSomething(e));
>>
>> This looks beautiful for Java 8, sure. Now try doing these same 
>> things in a library compiled for Java 6 but made to be compatible 
>> with Java 8 and so all of this has to happen via reflection. Suddenly 
>> it's nightmarish.
>
> With a new class to contain the information it will look like a 
> nightmare even if you get an array and do not have that callback 
> style. What we will probably do is a kind of plugin that gets enabled 
> if jdk8 is used. That class will have to be compiled using jdk8 
> though. And in case of an older jdk the old implementation will be used
>
> bye Jochen
>
>



From staffan.larsen at oracle.com  Fri Sep 20 09:49:07 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 20 Sep 2013 11:49:07 +0200
Subject: RFR(S): 7200277 [parfait] potential buffer overflow in npt/utf.c
Message-ID: <7884D2B2-7C75-4F56-9D62-AA70D5E5E1D2@oracle.com>

Please review this change to avoid a buffer overflow in npt/utf.c.

webrev: http://cr.openjdk.java.net/~sla/7200277/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-7200277

Thanks,
/Staffan


From jhuxhorn at googlemail.com  Fri Sep 20 09:57:25 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Fri, 20 Sep 2013 11:57:25 +0200
Subject: =?UTF-8?Q?Re=3A_=5BPATCH=5D_4851444=3A_Exposing_sun.reflect.Reflection=23getCallerClass_as_a_public_API_in_Java_8?=
In-Reply-To: <523C16B7.7080708@gmail.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C0E0B.7040407@gmx.org> <523C16B7.7080708@gmail.com>
Message-ID: 

On 20. September 2013 at 11:35:24, Peter Levart (peter.levart at gmail.com) wrote:
On 09/20/2013 10:57 AM, Jochen Theodorou wrote:?
> Am 20.09.2013 09:28, schrieb Nick Williams:?
> [...]?
>> This is all well and good, but some of us just need a simple array.?
>> This seems like over-engineering. I just want an array of?
>> StackFrameInfos/StackTraceFrames.?
>?
> if you need the full stack, then misusing a Predicate and a dummy?
> Consumer to collect everything looks a lot like not intended use. The?
> intended inability of lambdas to write to local variables outside the?
> lambda is not helping here to avoid anonymous inner classes. So what?
> was a simple method call, will look really awful - I agree.?

List frames = new ArrayList<>();?
Thread.walkStack(frames::add);?

No so awfull.?

Regards, Peter?
This is precisely what I mean. Yes, it has a nice syntax but it will perform worse than simply working on a StackTraceFrame[].

It's not that awful but it's the construction of an additional ArrayList instance and n additional method calls plus additional gc heat.

We are talking about code that will be executed for every single log statement, i.e. millions/billions of times. This *will* add up and it *will* make a significant difference. This isn't premature optimization either - it's just a very hot hotspot.



Joern


From peter.levart at gmail.com  Fri Sep 20 10:05:39 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Sep 2013 12:05:39 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C0E2C.1030206@gmx.org>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
Message-ID: <523C1DF3.7070002@gmail.com>

On 09/20/2013 10:58 AM, Jochen Theodorou wrote:
> Am 20.09.2013 09:09, schrieb Mandy Chung:
> [...]
>> Stack is a "stream" that allows you to walk partial stack (e.g. find
>> caller) or full stack trace (e.g. throwable). The filtering and mapping
>> operations are lazy to avoid having the VM eagerly copying the entire
>> stack trace data even for the short reach case (like Groovy and Log4j).
>
> and is there a link to StackStram too?
> The Thread#walkStack methods don't really describe the behaviour of 
> the consumer. Will the consumer applied only once, or multiple times? 
> If only once, then to replace getCallerClass(int depth), you will need 
> the version with the predicate, which will be difficult to realize 
> with a simple lambda, since you will need to count as well.

The use-cases described used getCallerClass(int depth) repeatedly to 
find a caller by iterating over a range of depths and calling 
getCallerClass(depth). You can use either Thread.walkStack or 
Thread.firstCaller for implementing those use-cases.

Maybe the following method would be handy to optimize search when we 
know that we want to skip 1st N frames before starting testing with 
predicate:

public static  T firstCaller(int startDepth,
                                 Predicate predicate,
                                 Function function) {


Reflection.getCallerClass(depth)

then becomes:

Thread.firstCaller(depth, f -> true, StackFrameInfo::getDeclaringClass);


Hm...

Peter

> bye Jochen
>



From forax at univ-mlv.fr  Fri Sep 20 10:03:34 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 20 Sep 2013 12:03:34 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: 
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C0E0B.7040407@gmx.org> <523C16B7.7080708@gmail.com>
	
Message-ID: <523C1D76.6000202@univ-mlv.fr>

On 09/20/2013 11:57 AM, J?rn Huxhorn wrote:
> On 20. September 2013 at 11:35:24, Peter Levart (peter.levart at gmail.com) wrote:
> On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
>> Am 20.09.2013 09:28, schrieb Nick Williams:
>> [...]
>>> This is all well and good, but some of us just need a simple array.
>>> This seems like over-engineering. I just want an array of
>>> StackFrameInfos/StackTraceFrames.
>>   
>> if you need the full stack, then misusing a Predicate and a dummy
>> Consumer to collect everything looks a lot like not intended use. The
>> intended inability of lambdas to write to local variables outside the
>> lambda is not helping here to avoid anonymous inner classes. So what
>> was a simple method call, will look really awful - I agree.
> List frames = new ArrayList<>();
> Thread.walkStack(frames::add);
>
> No so awfull.
>
> Regards, Peter
> This is precisely what I mean. Yes, it has a nice syntax but it will perform worse than simply working on a StackTraceFrame[].

why ?

>
> It's not that awful but it's the construction of an additional ArrayList instance and n additional method calls plus additional gc heat.
>
> We are talking about code that will be executed for every single log statement, i.e. millions/billions of times. This *will* add up and it *will* make a significant difference. This isn't premature optimization either - it's just a very hot hotspot.
>
>
>
> Joern

R?mi



From alexander.zuev at oracle.com  Fri Sep 20 10:43:21 2013
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Fri, 20 Sep 2013 14:43:21 +0400
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
In-Reply-To: <523B86A0.9080904@oracle.com>
References: <523B29A1.9000204@oracle.com> <523B86A0.9080904@oracle.com>
Message-ID: <523C26C9.2000507@oracle.com>

Hi Kumar,

   thanks for suggestion - the corrected (and simplified) webrev can be 
found at:
http://cr.openjdk.java.net/~kizune/8025076/webrev.05

With best regards,
/Alex

On 9/20/13 3:20, Kumar Srinivasan wrote:
> Hi Alex,
>
> The class can be compiled into the current directory (scratch), this 
> will  eliminate:
> a. the deletion of the files and allow jtreg to clean out the scratch 
> directory
> b. uses of  TEST_CLASSES_DIR.getAbsolutePath().
>
> Thanks
> Kumar
>
>
>
>> Hi,
>>
>>   please review my fix for 8025076: Fix for JDK-8017248 breaks jprt 
>> submission for non-unicode locales
>>
>>   The idea of the fix is to replace test case with the complex file 
>> name in it by the
>> test that generates and compiles such file at the run time.
>>
>>   The webrev can be found at: 
>> http://cr.openjdk.java.net/~kizune/8025076/webrev.04/
>>
>> With best regards,
>> /Alex
>



From blackdrag at gmx.org  Fri Sep 20 10:56:46 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 12:56:46 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C16B7.7080708@gmail.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C0E0B.7040407@gmx.org> <523C16B7.7080708@gmail.com>
Message-ID: <523C29EE.4030907@gmx.org>

Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
> List frames = new ArrayList<>();
> Thread.walkStack(frames::add);
>
> No so awfull.

as I said, it is unclear to me as of if walkStack walks the whole stack 
or not. Your code implies it does. If It does, I don't see the advantage 
of suing a Stream here.... or does the predicate version not?

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From blackdrag at gmx.org  Fri Sep 20 11:19:58 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 13:19:58 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C1DF3.7070002@gmail.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com>
Message-ID: <523C2F5E.5010301@gmx.org>

Am 20.09.2013 12:05, schrieb Peter Levart:
[...]
> The use-cases described used getCallerClass(int depth) repeatedly to
> find a caller by iterating over a range of depths and calling
> getCallerClass(depth). You can use either Thread.walkStack or
> Thread.firstCaller for implementing those use-cases.

first Caller is only going back one, or not? Not useful for us in the 
cases we need this. I wouldn't say the API through getCallerClass(int) 
was optimal for us, I think the new one can be better... I only miss (or 
didn't get how) the ability not to have to walk the entire stack, 
without knowing before how deep I have to go

> Maybe the following method would be handy to optimize search when we
> know that we want to skip 1st N frames before starting testing with
> predicate:
>
> public static  T firstCaller(int startDepth,
>                                  Predicate predicate,
>                                  Function function) {
>
>
> Reflection.getCallerClass(depth)
>
> then becomes:
>
> Thread.firstCaller(depth, f -> true, StackFrameInfo::getDeclaringClass);
>
>
> Hm...

that is I think a usecase for some... as I said, getCallerClass(int) is 
not really ideal for us either. More ideal in this style would be for us

>  public static  T findCaller(Predicate predicate,
>                                 Function function)

with the predicate indicating when to stop.. though the usage of this is 
not that nice:

> Class getCallerClass(final int nonSkippedFramesDepth) {
>    return findCaller(new Predicate() {
> 		int depth = 0;
> 		boolean test(StackFrameInfo info) {
>                     if (haveToSkip(info.getDeclaringClass())) return false;
>                     depth++;
>                     if (depth>=nonSkippedFramesDepth) return info.getDeclaringClass();
>                 }
>           }, StackFrameInfo::getDeclaringClass());
> }

Have you guys though about exposing the StackStream instead? Then you 
could use all the existing JDK method for streams on that, which gives 
you a much more flexible API. I could then for example change the Stream 
of StackFrameInfo into one of Class.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From daniel.fuchs at oracle.com  Fri Sep 20 12:33:27 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 20 Sep 2013 14:33:27 +0200
Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles
Message-ID: <523C4097.10200@oracle.com>

Hi,

Please find below a patch for:

8013839: Enhance Logger API for handling of resource bundles, and
4814565: (rb) add method to get basename from a ResourceBundle



    1. It adds a ResourceBundle.getBaseBundleName() method,
    2. It adds a Logger.setResourceBundle(ResourceBundle) method,
    3. It adds a series of Logger.logrb(...) that take a ResourceBundle
         object instead of a ResourceBundle name.
         The previous versions of Logger.logrb(...) that took a
         resource bundle name are therefore no longer needed,
         they offer no added value above the new methods, and
         are thus now deprecated.

Logger.getLogger(name, rbname) will continue to work as before,
      and will also throw an exception if a RB with a different name
      has been set before, either through setResourceBundle or
      Logger.getLogger(name, rbname).

Logger.setResourceBundle works similarly to
      Logger.getLogger(name, rbname) in the sense that it will not
      allow to replace an existing bundle, unless both have the same
      name. Like for Logger.getLogger(name, rbname) - it doesn't matter
      by which method the previous bundle has been set.

      This is mostly for consistency of the API - if thread A has
      requested a logger with resource bundle name 'foo.Bundle'
      and thread B attempts to set the resource bundle of that
      logger to 'bar.Bundle' then thread B will get an IAE.

      The resource bundle passed to Logger.setResourceBundle *must*
      have a base name. Note that ResourceBundle objects will have
      a base name by default if they have been loaded through
      one of the ResourceBundle.getBundle(...) methods;
      If ResourceBundle.getBaseBundleName() returns null an IAE
      will be thrown.

      Logger.setResourceBundle requires the "control" permission.

      When a resource bundle is set with Logger.setResourceBundle,
      then it's that resource bundle locale that will be used
      when logging (and not the default locale).

I have written a set of unit tests which should cover all the points
listed above.

best regards,

-- daniel


From jhuxhorn at googlemail.com  Fri Sep 20 12:40:44 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Fri, 20 Sep 2013 14:40:44 +0200
Subject: =?UTF-8?Q?Re=3A_=5BPATCH=5D_4851444=3A_Exposing_sun.reflect.Reflection=23getCallerClass_as_a_public_API_in_Java_8?=
In-Reply-To: <523C1D76.6000202@univ-mlv.fr>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C0E0B.7040407@gmx.org> <523C16B7.7080708@gmail.com>
	
	<523C1D76.6000202@univ-mlv.fr>
Message-ID: 

On 20. September 2013 at 12:06:42, Remi Forax (forax at univ-mlv.fr) wrote:
On 09/20/2013 11:57 AM, J?rn Huxhorn wrote:?
> On 20. September 2013 at 11:35:24, Peter Levart (peter.levart at gmail.com) wrote:?
> On 09/20/2013 10:57 AM, Jochen Theodorou wrote:?
>> Am 20.09.2013 09:28, schrieb Nick Williams:?
>> [...]?
>>> This is all well and good, but some of us just need a simple array.?
>>> This seems like over-engineering. I just want an array of?
>>> StackFrameInfos/StackTraceFrames.?
>>?
>> if you need the full stack, then misusing a Predicate and a dummy?
>> Consumer to collect everything looks a lot like not intended use. The?
>> intended inability of lambdas to write to local variables outside the?
>> lambda is not helping here to avoid anonymous inner classes. So what?
>> was a simple method call, will look really awful - I agree.?
> List frames = new ArrayList<>();?
> Thread.walkStack(frames::add);?
>?
> No so awfull.?
>?
> Regards, Peter?
> This is precisely what I mean. Yes, it has a nice syntax but it will perform worse than simply working on a StackTraceFrame[].?

why ??

>?
> It's not that awful but it's the construction of an additional ArrayList instance and n additional method calls plus additional gc heat.?
>?
> We are talking about code that will be executed for every single log statement, i.e. millions/billions of times. This *will* add up and it *will* make a significant difference. This isn't premature optimization either - it's just a very hot hotspot.
Because of the explanation in the very next paragraph.

An additional instance is created (two, if you count the closure that is hidden behind the innocent-looking "frames::add") and the add method is called for every StackFrameInfo.?If the stack is deeper than 10, ArrayList will recreate the array used to store the entries followed by an Arrays.copyOf call.

There are different cases requiring different things. One of them is walking the entire stack trace and there are cases were starting at the front or the back might be beneficial. Other cases involve retrieving of a specific element at a known index. If I'm only interested in one StackTraceFrame it would definitely be overkill to retrieve the whole array. If I need the whole stack trace, though, it would be a bad idea to retrieve the stack trace step by step since that would mean multiple JNI calls. I think Nicks implementation took both cases into account.



Joern


From sundararajan.athijegannathan at oracle.com  Fri Sep 20 13:05:35 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Fri, 20 Sep 2013 13:05:35 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130920130538.04E23629CF@hg.openjdk.java.net>

Changeset: 195be8ca5c97
Author:    sundar
Date:      2013-09-20 12:56 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/195be8ca5c97

8025111: undefined or null 'with' expression in empty with block should throw TypeError
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8025111.js

Changeset: fa491b75d3e4
Author:    hannesw
Date:      2013-09-20 12:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fa491b75d3e4

8022587: ClassCache is not optimal and leaks Source instances
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/objects/Global.java



From chris.hegarty at oracle.com  Fri Sep 20 13:13:33 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Sep 2013 14:13:33 +0100
Subject: RFR(L): 8024854: Basic changes and files to build the class
	library on AIX
In-Reply-To: 
References: 
	
Message-ID: <523C49FD.60904@oracle.com>

Volker,

I skimmed over the networking part of the changes, and nothing jumps out 
at me. I'd like to spend a little more time doing a more detailed 
review, but I will not have time to do this until after JavaOne.

-Chris.

On 09/16/2013 08:30 PM, Volker Simonis wrote:
> Resending this to more lists as requested by Alan Bateman with the kind
> request to anybody to review the parts for which he feels responsible:)
>
> For those not up to date, this change is part of the ongoing PowerPC/AIX
> Porting Project:
> http://openjdk.java.net/projects/ppc-aix-port
> https://wiki.openjdk.java.net/display/PPCAIXPort
> http://openjdk.java.net/jeps/175
>
> Please send reviews to all currently included recipients.
>
> Thank you and best regards,
> Volker
>
>
> ---------- Forwarded message ----------
> From: *Volker Simonis*
> Date: Monday, September 16, 2013
> Subject: RFR(L): 8024854: Basic changes and files to build the class
> library on AIX
> To: "ppc-aix-port-dev at openjdk.java.net" ,
> Java Core Libs 
>
>
> Hi,
>
> could you please review the following webrev which contains the basic
> changes and files needed in the 'jdk' repository in order to build the
> OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854
>
> This change together with "8024265: Enable new build on AIX (jdk
> part)"
> allows it to configure and completely build the staging repository on AIX
> 5.3 and 7.1 with the following command:
>
> configure --with-boot-jdk= --with-jvm-variants=core
> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
> --x-includes=/opt/freeware/include
>
> Below you can find the changes and additions I've done, sorted by file.
> Most of them are just additions which are only active during the AIX build
> anyway or simple changes where AIX has been added to conditions which
> already check for Linux and/or Solaris. The files with the biggest changes
> which you're probably want to look on more thoroughly are
> 'src/solaris/native/java/net/NetworkInterface.c' and
> 'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change
> anything on the current OpenJDK platforms as well.
>
> Notice that there are still some files and some functionality missing from
> the current change (notably NIO) but it still yields a running JDK which
> can execute "HelloWorld" on the command line and as AWT application. I've
> intentionally tried to keep this initial change as simple as possible (with
> respect tot shared changes) in order to get it reviewed as fast as
> possible. The missing parts can then be added later on, grouped by logical
> topics, to simplify the review process.
>
> Thank you and best regards,
> Volker
>
> src/share/bin/jli_util.h
>
>     - Define JLI_Lseek on AIX.
>
> src/share/lib/security/java.security-aix
>
>     - Provide default java.security-aix for AIX.
>
> src/share/native/sun/awt/medialib/mlib_sys.c
>
>     - malloc always returns 8-byte aligned pointers on AIX as well.
>
> src/share/native/sun/awt/medialib/mlib_types.h
>
>     - Add AIX to the list of known platforms.
>
> src/share/native/sun/font/layout/KernTable.cpp
>
>     - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common
>     and may be defined in other headers as well as on the command line and
>     xlc bails out on macro redefinitions with a different value.
>
> src/share/native/sun/security/ec/impl/ecc_impl.h
>
>     - Define required types and macros on AIX.
>
> src/solaris/back/exec_md.c
>
>     - AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
> src/solaris/bin/java_md_solinux.c,
> src/solaris/bin/java_md_solinux.h
>
>     - On AIX LD_LIBRARY_PATH is called LIBPATH
>     - Always use LD_LIBRARY_PATH macro instead of using the string "
>     LD_LIBRARY_PATH" directly to cope with different library path names.
>     - Add jre/lib//jli to the standard library search path on AIX
>     because the AIX linker doesn't support the -rpath option.
>     - Replace #ifdef __linux__ by #ifndef __solaris__ because in this case,
>     AIX behaves like Linux.
>
> src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>     - Provide basic fontconfig.propertiesfor AIX.
>
> src/solaris/classes/java/lang/UNIXProcess.java.aix,
> src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
> src/solaris/classes/sun/tools/attach/AixVirtualMachine.java
>
>     - Provide AIX specific Java versions, mostly based on the corresponding
>     Linux versions.
>
> src/solaris/demo/jvmti/hprof/hprof_md.c
>
>     - Add AIX support. AIX mostly behaves like Linux, with the one exception
>     that it has no dladdr functionality.
>     - Implement dladdr functionality for AIX.
>
> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>     - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).
>
> src/solaris/native/common/jdk_util_md.h
>
>     - Add AIX definitions of the ISNANF and ISNAND macros.
>
> src/solaris/native/java/io/io_util_md.c
>
>     - AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
> src/solaris/native/java/net/NetworkInterface.c
>
>     - Add AIX support into the Linux branch because AIX mostly behaves like
>     AIX for IPv4.
>     - AIX needs a special function to enumerate IPv6 interfaces and to query
>     the MAC address.
>
> src/solaris/native/java/net/PlainSocketImpl.c
>
>     - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
>     socket is closed. The default error message is then confusing.
>
> src/solaris/native/java/net/linux_close.c,
> src/share/native/java/net/net_util.c
>
>     - Also use the file and socket wrappers on AIX.
>     - Add initialization of some previously uninitialized data structures.
>     - On AIX we don't have __attribute((constructor)) so we need to
>     initialize manually (from JNI_OnLoad() in
>     'src/share/native/java/net/net_util.c'
>
> src/solaris/native/java/net/net_util_md.h
>
>     - AIX needs the same workaround for I/O cancellation like Linux and
>     MacOSX.
>
> src/solaris/native/java/util/TimeZone_md.c
>
>     - Currently on AIX the only way to get the platform time zone is to read
>     it from the TZ environment variable.
>
> src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>     - There's no dladdr on AIX, but we can use the implementation from the
>     HotSpot in this case because libjvm.so will be always loaded before the
>     AWT.
>
> src/solaris/native/sun/awt/fontpath.c
>
>     - Add AIX specific fontpath settings and library search paths for
>     libfontconfig.so.
>
> src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>     - Only define MIN and MAX if they're not already defined because xlc on
>     AIX fails on macro redefinitions.
>
> src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>     - Handle AIX like Solaris.
>
> src/solaris/native/sun/nio/ch/Net.c
>
>     - Add AIX-specific includes and constant definitions.
>     - On AIX "socket extensions for multicast source filters" support
>     depends on the OS version. Check for this and throw appropriate exceptions
>     if it requested but not supported. This is needed to pass
>     JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
> src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>     - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.
>
> src/solaris/native/sun/tools/attach/AixVirtualMachine.c
>
>     - AIX version mostly derived from the corresponding Linux version.
>


From dmitry.samersoff at oracle.com  Fri Sep 20 13:28:29 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 20 Sep 2013 17:28:29 +0400
Subject: RFR(S): 7200277 [parfait] potential buffer overflow in npt/utf.c
In-Reply-To: <7884D2B2-7C75-4F56-9D62-AA70D5E5E1D2@oracle.com>
References: <7884D2B2-7C75-4F56-9D62-AA70D5E5E1D2@oracle.com>
Message-ID: <523C4D7D.4060803@oracle.com>

Staffan,

Looks good for me.

PS:
 > is redundant.

-Dmitry

On 2013-09-20 13:49, Staffan Larsen wrote:
> Please review this change to avoid a buffer overflow in npt/utf.c.
> 
> webrev: http://cr.openjdk.java.net/~sla/7200277/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-7200277
> 
> Thanks,
> /Staffan
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.


From alexander.zuev at oracle.com  Fri Sep 20 13:57:31 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Fri, 20 Sep 2013 13:57:31 +0000
Subject: hg: jdk8/tl/jdk: 8025076: Fix for JDK-8017248 breaks jprt submission
	for non-unicode locales
Message-ID: <20130920135753.A25E9629D3@hg.openjdk.java.net>

Changeset: afe857b13b62
Author:    kizune
Date:      2013-09-20 17:56 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/afe857b13b62

8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
Reviewed-by: naoto, ksrini

- test/tools/launcher/8017248/ClassA??.java
- test/tools/launcher/8017248/test.sh
+ test/tools/launcher/DiacriticTest.java



From daniel.daugherty at oracle.com  Fri Sep 20 14:11:37 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 20 Sep 2013 08:11:37 -0600
Subject: RFR(S): 7200277 [parfait] potential buffer overflow in npt/utf.c
In-Reply-To: <7884D2B2-7C75-4F56-9D62-AA70D5E5E1D2@oracle.com>
References: <7884D2B2-7C75-4F56-9D62-AA70D5E5E1D2@oracle.com>
Message-ID: <523C5799.3050807@oracle.com>

On 9/20/13 3:49 AM, Staffan Larsen wrote:
> Please review this change to avoid a buffer overflow in npt/utf.c.
>
> webrev: http://cr.openjdk.java.net/~sla/7200277/webrev.00/

Thumbs up.

src/share/npt/utf.c
     No comments

Dan

> bug: https://bugs.openjdk.java.net/browse/JDK-7200277
>
> Thanks,
> /Staffan



From dl at cs.oswego.edu  Fri Sep 20 14:11:50 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 20 Sep 2013 10:11:50 -0400
Subject: SplittableRandom update
Message-ID: <523C57A6.2000508@cs.oswego.edu>


In the course of writing up a report (coming soon) that includes
discussion of SplittableRandom, we had a chance to further
analyze and test things, resulting in a few small improvements. Plus
some internal renamings to better reflect intent.
Plus now with the same initial seed mechanics
discussed a few days ago for ThreadLocalRandom.

Thanks to Paul Sandoz for creating webrevs:

https://bugs.openjdk.java.net/browse/JDK-8025136

http://cr.openjdk.java.net/~psandoz/tl/JDK-8025136-SR-enhancements/webrev/

I think we need one more reviewer for it.

-Doug


From staffan.larsen at oracle.com  Fri Sep 20 14:41:13 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Fri, 20 Sep 2013 14:41:13 +0000
Subject: hg: jdk8/tl/jdk: 7200277: [parfait] potential buffer overflow in
	npt/utf.c
Message-ID: <20130920144137.2B426629D5@hg.openjdk.java.net>

Changeset: 94cc251d0c45
Author:    sla
Date:      2013-09-20 16:40 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94cc251d0c45

7200277: [parfait] potential buffer overflow in npt/utf.c
Reviewed-by: dsamersoff, dcubed

! src/share/npt/utf.c



From naoto.sato at oracle.com  Fri Sep 20 14:45:28 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Sep 2013 07:45:28 -0700
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
In-Reply-To: <523C26C9.2000507@oracle.com>
References: <523B29A1.9000204@oracle.com> <523B86A0.9080904@oracle.com>
	<523C26C9.2000507@oracle.com>
Message-ID: <09D3E1F0-DAE1-4183-A451-0FDC58F00D63@oracle.com>

Is it ok to let jtreg clean up the files that contain non ascii filenames? Does it gracefully remove them?

Naoto

> On Sep 20, 2013, at 3:43 AM, Alexander Zuev  wrote:
> 
> Hi Kumar,
> 
>  thanks for suggestion - the corrected (and simplified) webrev can be found at:
> http://cr.openjdk.java.net/~kizune/8025076/webrev.05
> 
> With best regards,
> /Alex
> 
>> On 9/20/13 3:20, Kumar Srinivasan wrote:
>> Hi Alex,
>> 
>> The class can be compiled into the current directory (scratch), this will  eliminate:
>> a. the deletion of the files and allow jtreg to clean out the scratch directory
>> b. uses of  TEST_CLASSES_DIR.getAbsolutePath().
>> 
>> Thanks
>> Kumar
>> 
>> 
>> 
>>> Hi,
>>> 
>>>  please review my fix for 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
>>> 
>>>  The idea of the fix is to replace test case with the complex file name in it by the
>>> test that generates and compiles such file at the run time.
>>> 
>>>  The webrev can be found at: http://cr.openjdk.java.net/~kizune/8025076/webrev.04/
>>> 
>>> With best regards,
>>> /Alex
> 


From kasperni at gmail.com  Fri Sep 20 15:25:03 2013
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 20 Sep 2013 17:25:03 +0200
Subject: SplittableRandom update
In-Reply-To: <523C57A6.2000508@cs.oswego.edu>
References: <523C57A6.2000508@cs.oswego.edu>
Message-ID: 

Hi,

This is minor, but I hate it when bounds check does not include the
specified parameters.
Makes it much harder to track down a bug, if all you have is a stack trace.

- Kasper


On Fri, Sep 20, 2013 at 4:11 PM, Doug Lea 
 wrote:

>
> In the course of writing up a report (coming soon) that includes
> discussion of SplittableRandom, we had a chance to further
> analyze and test things, resulting in a few small improvements. Plus
> some internal renamings to better reflect intent.
> Plus now with the same initial seed mechanics
> discussed a few days ago for ThreadLocalRandom.
>
> Thanks to Paul Sandoz for creating webrevs:
>
> https://bugs.openjdk.java.net/**browse/JDK-8025136
>
> http://cr.openjdk.java.net/~**psandoz/tl/JDK-8025136-SR-**
> enhancements/webrev/
>
> I think we need one more reviewer for it.
>
> -Doug
>


From vladimir.x.ivanov at oracle.com  Fri Sep 20 15:29:46 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 20 Sep 2013 19:29:46 +0400
Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect
	initialization rules for static members
In-Reply-To: <239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com>
References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>
	<239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com>
Message-ID: <523C69EA.3030107@oracle.com>

John,

I don't see much value in documenting buggy behavior of early JDK7 in 
JDK8 code. So, I would remove it.

Regarding the test:
   31  * @run main/othervm/timeout=3600
   - why do you have timeout set to 1h?

I like the idea how you count events.

As a suggestion for enhancement - maybe it's more reliable to check the 
"type" of event as well? To ensure that particular class was initialized.

Best regards,
Vladimir Ivanov

On 9/20/13 1:38 AM, John Rose wrote:
> On Sep 12, 2013, at 7:24 PM, John Rose  > wrote:
>
>> Please review this change for a change to the JSR 292 implementation:
>>
>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
>>
>> Summary: Align MH semantic with bytecode behavior of constructor and
>> static member accesses, regarding  invocation.
>>
>> The change is to javadoc and unit tests, documenting and testing some
>> corner cases of JSR 292 APIs.
>
> I have a reviewer (Alex Buckley) for the documentation changes, but I
> would also like a quick code review for the unit test.
>
> Also, there is a code insertion (predicated on a "false" symbolic
> constant) which serves to document the buggy JDK 7 behavior.  I'm not
> particularly attached to it, so I'm open to either a yea or nay on
> keeping it.  Leaning nay at the moment.
>
> ? John
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From martinrb at google.com  Fri Sep 20 15:30:32 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Sep 2013 08:30:32 -0700
Subject: SplittableRandom update
In-Reply-To: <523C57A6.2000508@cs.oswego.edu>
References: <523C57A6.2000508@cs.oswego.edu>
Message-ID: 

Looks good.

Random nitpicks:

I prefer the old variable name DOUBLE_UNIT to DOUBLE_ULP; else you are
inventing a slightly different meaning for ULP.

I think using hex floating point literals is preferred:

-    private static final double DOUBLE_ULP = 1.0 / (1L << 53);
+    private static final double DOUBLE_ULP = 0x1.0p-53;

comment tidy:

-     * Appleby's MurmurHash3 algorithm See
-     * http://code.google.com/p/smhasher/wiki/MurmurHash3 . The mix32
+     * Appleby's MurmurHash3 algorithm (see
+     * http://code.google.com/p/smhasher/wiki/MurmurHash3). The mix32




On Fri, Sep 20, 2013 at 7:11 AM, Doug Lea 
 wrote:

>
> In the course of writing up a report (coming soon) that includes
> discussion of SplittableRandom, we had a chance to further
> analyze and test things, resulting in a few small improvements. Plus
> some internal renamings to better reflect intent.
> Plus now with the same initial seed mechanics
> discussed a few days ago for ThreadLocalRandom.
>
> Thanks to Paul Sandoz for creating webrevs:
>
> https://bugs.openjdk.java.net/**browse/JDK-8025136
>
> http://cr.openjdk.java.net/~**psandoz/tl/JDK-8025136-SR-**
> enhancements/webrev/
>
> I think we need one more reviewer for it.
>
> -Doug
>


From martinrb at google.com  Fri Sep 20 15:34:51 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Sep 2013 08:34:51 -0700
Subject: SplittableRandom update
In-Reply-To: 
References: <523C57A6.2000508@cs.oswego.edu>
	
Message-ID: 

On Fri, Sep 20, 2013 at 8:25 AM, Kasper Nielsen  wrote:

> Hi,
>
> This is minor, but I hate it when bounds check does not include the
> specified parameters.
> Makes it much harder to track down a bug, if all you have is a stack trace.
>

I agree.  My own Best Practice is to write

         if (!(bound > 0.0))
            throw new IllegalArgumentException(badBound(bound));

(I'm still waiting for VMs to take care of the out-lining of cold code
automatically)


From paul.sandoz at oracle.com  Fri Sep 20 15:36:10 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Sep 2013 08:36:10 -0700
Subject: SplittableRandom update
In-Reply-To: 
References: <523C57A6.2000508@cs.oswego.edu>
	
Message-ID: <60518C87-9FB9-4B07-A074-E925691AF1F3@oracle.com>

Hi Kasper,

Can you please log a bug [1] (and also note that ThreadLocal/Random does the same) ?

My preference would be to get this code in and fix the error reporting separately.

Thanks,
Paul.

[1] https://bugs.openjdk.java.net/


On Sep 20, 2013, at 8:25 AM, Kasper Nielsen  wrote:

> Hi,
> 
> This is minor, but I hate it when bounds check does not include the
> specified parameters.
> Makes it much harder to track down a bug, if all you have is a stack trace.
> 
> - Kasper
> 
> 
> On Fri, Sep 20, 2013 at 4:11 PM, Doug Lea 
 wrote:
> 
>> 
>> In the course of writing up a report (coming soon) that includes
>> discussion of SplittableRandom, we had a chance to further
>> analyze and test things, resulting in a few small improvements. Plus
>> some internal renamings to better reflect intent.
>> Plus now with the same initial seed mechanics
>> discussed a few days ago for ThreadLocalRandom.
>> 
>> Thanks to Paul Sandoz for creating webrevs:
>> 
>> https://bugs.openjdk.java.net/**browse/JDK-8025136
>> 
>> http://cr.openjdk.java.net/~**psandoz/tl/JDK-8025136-SR-**
>> enhancements/webrev/
>> 
>> I think we need one more reviewer for it.
>> 
>> -Doug
>> 


From alexander.zuev at oracle.com  Fri Sep 20 15:40:15 2013
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Fri, 20 Sep 2013 19:40:15 +0400
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
In-Reply-To: <09D3E1F0-DAE1-4183-A451-0FDC58F00D63@oracle.com>
References: <523B29A1.9000204@oracle.com> <523B86A0.9080904@oracle.com>
	<523C26C9.2000507@oracle.com>
	<09D3E1F0-DAE1-4183-A451-0FDC58F00D63@oracle.com>
Message-ID: <523C6C5F.2070109@oracle.com>

Naoto,

   i just tested - jtreg has no issues with deleting files even in 
non-unicode locales.

/Alex

On 9/20/13 18:45, Naoto Sato wrote:
> Is it ok to let jtreg clean up the files that contain non ascii filenames? Does it gracefully remove them?
>
> Naoto
>
>> On Sep 20, 2013, at 3:43 AM, Alexander Zuev  wrote:
>>
>> Hi Kumar,
>>
>>   thanks for suggestion - the corrected (and simplified) webrev can be found at:
>> http://cr.openjdk.java.net/~kizune/8025076/webrev.05
>>
>> With best regards,
>> /Alex
>>
>>> On 9/20/13 3:20, Kumar Srinivasan wrote:
>>> Hi Alex,
>>>
>>> The class can be compiled into the current directory (scratch), this will  eliminate:
>>> a. the deletion of the files and allow jtreg to clean out the scratch directory
>>> b. uses of  TEST_CLASSES_DIR.getAbsolutePath().
>>>
>>> Thanks
>>> Kumar
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>>   please review my fix for 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
>>>>
>>>>   The idea of the fix is to replace test case with the complex file name in it by the
>>>> test that generates and compiles such file at the run time.
>>>>
>>>>   The webrev can be found at: http://cr.openjdk.java.net/~kizune/8025076/webrev.04/
>>>>
>>>> With best regards,
>>>> /Alex



From peter.levart at gmail.com  Fri Sep 20 15:45:55 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Sep 2013 17:45:55 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C29EE.4030907@gmx.org>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C0E0B.7040407@gmx.org> <523C16B7.7080708@gmail.com>
	<523C29EE.4030907@gmx.org>
Message-ID: <523C6DB3.6040302@gmail.com>

On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
> Am 20.09.2013 11:34, schrieb Peter Levart:
> [...]
>> List frames = new ArrayList<>();
>> Thread.walkStack(frames::add);
>>
>> No so awfull.
>
> as I said, it is unclear to me as of if walkStack walks the whole 
> stack or not. Your code implies it does. If It does, I don't see the 
> advantage of suing a Stream here.... or does the predicate version not?

Right.

I think the reasoning behind call-back API is that it moves the logic to 
construct a suitable data structure to the Java side, skipping 
intermediary representations and conversions. I don't know what the 
overhead of call-backs from native code to Java is though. For 
constructing and returning an array of StackFrameInfo objects, the 
native code has to collect the objects into a GrowableArray (a native 
equivalent of ArrayList). Before returning, it has to copy elements into 
the Java array. And this Java array is usually later used just to 
iterate it's elements... Imagine a situation where GrowableArray and 
Java array could be skipped and StackFrameInfo objects directly 
formatted into a StringBuilder, creating the final logger message. This 
assumes that call-backs from native code are cheap. Are they? Can native 
method be intrinsified together with call-back invocations?

To support this call-back API in a JDK6 compatible way, but optimally, I 
would create a similar API to the one in JDK8 in the form of interfaces 
and then provide two implementations:
- the JDK8 implementation: a thin wrapper over JDK8 API
- the JDK6/7 implementation: an emulation adapter using JDK6/7 provided APIs

Regards, Peter

>
> bye blackdrag
>



From michael.x.mcmahon at oracle.com  Fri Sep 20 16:07:25 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 20 Sep 2013 17:07:25 +0100
Subject: RFR(L): 8024854: Basic changes and files to build the class
	library on AIX
In-Reply-To: 
References: 
	
Message-ID: <523C72BD.9090903@oracle.com>

A few comments:

1) Seems to be two macros _AIX and AIX. Is this intended?

NetworkInterface.c
============
2) line 1098: new style of variable declaration. First time we would 
have that in this code.
     I think it should be okay though

3) Can't comment on the AIX functionality, except I notice at line 1381: 
an exit(1) call
     which seems a bit extreme, in case of error. Can it not just return 
an error.

linux_close.c
========
4) I see Alan commented that we should create a common module for this 
functionality.
    Right now, we have a separate (but similar) bsd_close.c. I wonder if 
in the short term
    an aix_close.c might be the easiest thing, as I'm not sure it makes 
sense to have a
    bsd version and AIX lumped in with Linux.

- Michael

On 16/09/13 20:30, Volker Simonis wrote:
> Resending this to more lists as requested by Alan Bateman with the kind
> request to anybody to review the parts for which he feels responsible:)
>
> For those not up to date, this change is part of the ongoing PowerPC/AIX
> Porting Project:
> http://openjdk.java.net/projects/ppc-aix-port
> https://wiki.openjdk.java.net/display/PPCAIXPort
> http://openjdk.java.net/jeps/175
>
> Please send reviews to all currently included recipients.
>
> Thank you and best regards,
> Volker
>
>
> ---------- Forwarded message ----------
> From: *Volker Simonis*
> Date: Monday, September 16, 2013
> Subject: RFR(L): 8024854: Basic changes and files to build the class
> library on AIX
> To: "ppc-aix-port-dev at openjdk.java.net" ,
> Java Core Libs 
>
>
> Hi,
>
> could you please review the following webrev which contains the basic
> changes and files needed in the 'jdk' repository in order to build the
> OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854
>
> This change together with "8024265: Enable new build on AIX (jdk
> part)"
> allows it to configure and completely build the staging repository on AIX
> 5.3 and 7.1 with the following command:
>
> configure --with-boot-jdk= --with-jvm-variants=core
> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
> --x-includes=/opt/freeware/include
>
> Below you can find the changes and additions I've done, sorted by file.
> Most of them are just additions which are only active during the AIX build
> anyway or simple changes where AIX has been added to conditions which
> already check for Linux and/or Solaris. The files with the biggest changes
> which you're probably want to look on more thoroughly are
> 'src/solaris/native/java/net/NetworkInterface.c' and
> 'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change
> anything on the current OpenJDK platforms as well.
>
> Notice that there are still some files and some functionality missing from
> the current change (notably NIO) but it still yields a running JDK which
> can execute "HelloWorld" on the command line and as AWT application. I've
> intentionally tried to keep this initial change as simple as possible (with
> respect tot shared changes) in order to get it reviewed as fast as
> possible. The missing parts can then be added later on, grouped by logical
> topics, to simplify the review process.
>
> Thank you and best regards,
> Volker
>
> src/share/bin/jli_util.h
>
>     - Define JLI_Lseek on AIX.
>
> src/share/lib/security/java.security-aix
>
>     - Provide default java.security-aix for AIX.
>
> src/share/native/sun/awt/medialib/mlib_sys.c
>
>     - malloc always returns 8-byte aligned pointers on AIX as well.
>
> src/share/native/sun/awt/medialib/mlib_types.h
>
>     - Add AIX to the list of known platforms.
>
> src/share/native/sun/font/layout/KernTable.cpp
>
>     - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common
>     and may be defined in other headers as well as on the command line and
>     xlc bails out on macro redefinitions with a different value.
>
> src/share/native/sun/security/ec/impl/ecc_impl.h
>
>     - Define required types and macros on AIX.
>
> src/solaris/back/exec_md.c
>
>     - AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
> src/solaris/bin/java_md_solinux.c,
> src/solaris/bin/java_md_solinux.h
>
>     - On AIX LD_LIBRARY_PATH is called LIBPATH
>     - Always use LD_LIBRARY_PATH macro instead of using the string "
>     LD_LIBRARY_PATH" directly to cope with different library path names.
>     - Add jre/lib//jli to the standard library search path on AIX
>     because the AIX linker doesn't support the -rpath option.
>     - Replace #ifdef __linux__ by #ifndef __solaris__ because in this case,
>     AIX behaves like Linux.
>
> src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>     - Provide basic fontconfig.propertiesfor AIX.
>
> src/solaris/classes/java/lang/UNIXProcess.java.aix,
> src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
> src/solaris/classes/sun/tools/attach/AixVirtualMachine.java
>
>     - Provide AIX specific Java versions, mostly based on the corresponding
>     Linux versions.
>
> src/solaris/demo/jvmti/hprof/hprof_md.c
>
>     - Add AIX support. AIX mostly behaves like Linux, with the one exception
>     that it has no dladdr functionality.
>     - Implement dladdr functionality for AIX.
>
> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>     - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).
>
> src/solaris/native/common/jdk_util_md.h
>
>     - Add AIX definitions of the ISNANF and ISNAND macros.
>
> src/solaris/native/java/io/io_util_md.c
>
>     - AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
> src/solaris/native/java/net/NetworkInterface.c
>
>     - Add AIX support into the Linux branch because AIX mostly behaves like
>     AIX for IPv4.
>     - AIX needs a special function to enumerate IPv6 interfaces and to query
>     the MAC address.
>
> src/solaris/native/java/net/PlainSocketImpl.c
>
>     - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
>     socket is closed. The default error message is then confusing.
>
> src/solaris/native/java/net/linux_close.c,
> src/share/native/java/net/net_util.c
>
>     - Also use the file and socket wrappers on AIX.
>     - Add initialization of some previously uninitialized data structures.
>     - On AIX we don't have __attribute((constructor)) so we need to
>     initialize manually (from JNI_OnLoad() in
>     'src/share/native/java/net/net_util.c'
>
> src/solaris/native/java/net/net_util_md.h
>
>     - AIX needs the same workaround for I/O cancellation like Linux and
>     MacOSX.
>
> src/solaris/native/java/util/TimeZone_md.c
>
>     - Currently on AIX the only way to get the platform time zone is to read
>     it from the TZ environment variable.
>
> src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>     - There's no dladdr on AIX, but we can use the implementation from the
>     HotSpot in this case because libjvm.so will be always loaded before the
>     AWT.
>
> src/solaris/native/sun/awt/fontpath.c
>
>     - Add AIX specific fontpath settings and library search paths for
>     libfontconfig.so.
>
> src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>     - Only define MIN and MAX if they're not already defined because xlc on
>     AIX fails on macro redefinitions.
>
> src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>     - Handle AIX like Solaris.
>
> src/solaris/native/sun/nio/ch/Net.c
>
>     - Add AIX-specific includes and constant definitions.
>     - On AIX "socket extensions for multicast source filters" support
>     depends on the OS version. Check for this and throw appropriate exceptions
>     if it requested but not supported. This is needed to pass
>     JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
> src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>     - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.
>
> src/solaris/native/sun/tools/attach/AixVirtualMachine.c
>
>     - AIX version mostly derived from the corresponding Linux version.



From naoto.sato at oracle.com  Fri Sep 20 16:12:43 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Sep 2013 09:12:43 -0700
Subject: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for
	non-unicode locales
In-Reply-To: <523C6C5F.2070109@oracle.com>
References: <523B29A1.9000204@oracle.com> <523B86A0.9080904@oracle.com>
	<523C26C9.2000507@oracle.com>
	<09D3E1F0-DAE1-4183-A451-0FDC58F00D63@oracle.com>
	<523C6C5F.2070109@oracle.com>
Message-ID: <523C73FB.7060406@oracle.com>

OK, good.

Naoto

On 9/20/13 8:40 AM, Alexander Zuev wrote:
> Naoto,
>
>    i just tested - jtreg has no issues with deleting files even in
> non-unicode locales.
>
> /Alex
>
> On 9/20/13 18:45, Naoto Sato wrote:
>> Is it ok to let jtreg clean up the files that contain non ascii
>> filenames? Does it gracefully remove them?
>>
>> Naoto
>>
>>> On Sep 20, 2013, at 3:43 AM, Alexander Zuev
>>>  wrote:
>>>
>>> Hi Kumar,
>>>
>>>   thanks for suggestion - the corrected (and simplified) webrev can
>>> be found at:
>>> http://cr.openjdk.java.net/~kizune/8025076/webrev.05
>>>
>>> With best regards,
>>> /Alex
>>>
>>>> On 9/20/13 3:20, Kumar Srinivasan wrote:
>>>> Hi Alex,
>>>>
>>>> The class can be compiled into the current directory (scratch), this
>>>> will  eliminate:
>>>> a. the deletion of the files and allow jtreg to clean out the
>>>> scratch directory
>>>> b. uses of  TEST_CLASSES_DIR.getAbsolutePath().
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>>   please review my fix for 8025076: Fix for JDK-8017248 breaks jprt
>>>>> submission for non-unicode locales
>>>>>
>>>>>   The idea of the fix is to replace test case with the complex file
>>>>> name in it by the
>>>>> test that generates and compiles such file at the run time.
>>>>>
>>>>>   The webrev can be found at:
>>>>> http://cr.openjdk.java.net/~kizune/8025076/webrev.04/
>>>>>
>>>>> With best regards,
>>>>> /Alex
>



From david.lloyd at redhat.com  Fri Sep 20 16:12:44 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 20 Sep 2013 11:12:44 -0500
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C6DB3.6040302@gmail.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C0E0B.7040407@gmx.org> <523C16B7.7080708@gmail.com>
	<523C29EE.4030907@gmx.org> <523C6DB3.6040302@gmail.com>
Message-ID: <523C73FC.6010708@redhat.com>

On 09/20/2013 10:45 AM, Peter Levart wrote:
> On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
>> Am 20.09.2013 11:34, schrieb Peter Levart:
>> [...]
>>> List frames = new ArrayList<>();
>>> Thread.walkStack(frames::add);
>>>
>>> No so awfull.
>>
>> as I said, it is unclear to me as of if walkStack walks the whole
>> stack or not. Your code implies it does. If It does, I don't see the
>> advantage of suing a Stream here.... or does the predicate version not?
>
> Right.
>
> I think the reasoning behind call-back API is that it moves the logic to
> construct a suitable data structure to the Java side, skipping
> intermediary representations and conversions. I don't know what the
> overhead of call-backs from native code to Java is though. For
> constructing and returning an array of StackFrameInfo objects, the
> native code has to collect the objects into a GrowableArray (a native
> equivalent of ArrayList). Before returning, it has to copy elements into
> the Java array. And this Java array is usually later used just to
> iterate it's elements... Imagine a situation where GrowableArray and
> Java array could be skipped and StackFrameInfo objects directly
> formatted into a StringBuilder, creating the final logger message. This
> assumes that call-backs from native code are cheap. Are they? Can native
> method be intrinsified together with call-back invocations?
>
> To support this call-back API in a JDK6 compatible way, but optimally, I
> would create a similar API to the one in JDK8 in the form of interfaces
> and then provide two implementations:
> - the JDK8 implementation: a thin wrapper over JDK8 API
> - the JDK6/7 implementation: an emulation adapter using JDK6/7 provided
> APIs
>
> Regards, Peter

 From my testing (in JDK 6), I found that calling back from JNI was not 
very cheap, but perhaps rather than making this call be a JNI 
call+callback it can simply be an intrinsic operation to begin with?  I 
like the idea of using a JDK8-style lambda to process frames.

-- 
- DML


From ivan.gerasimov at oracle.com  Fri Sep 20 16:24:24 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 20 Sep 2013 20:24:24 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <523857A9.2070902@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com> <52355E90.7090501@oracle.com>
	<523594CA.4070104@oracle.com> <52360F39.9080103@oracle.com>
	<523857A9.2070902@oracle.com>
Message-ID: <523C76B8.1060205@oracle.com>

Hi Alan!

I yet modified the test, so now it can be run both from jprt and as a 
standalone test.
I also added a comment for QA with the instruction on how to test the 
fix manually.

Would you please review the hopefully final webrev?
http://cr.openjdk.java.net/~igerasim/8023130/4/webrev/ 


Sincerely yours,
Ivan

On 17.09.2013 17:22, Ivan Gerasimov wrote:
>
> Hi Alan!
>
> On 15.09.2013 23:49, Alan Bateman wrote:
>> On 15/09/2013 12:06, Ivan Gerasimov wrote:
>>> :
>>>
>>> I decided to check whether this test really detects the failure, and 
>>> run JPRT job with the new test but no fix included.
>>> Unfortunately, the new test *does not* fail with unmodified jdk.
>>> The same thing happens when the test is run with jtreg locally.
>>> I believe it is so, because the tested program is run not directly 
>>> from a console, and this is the condition for the bug to manifest 
>>> itself.
>>>
>>> So I have to exclude the test, as it really doesn't check anything new.
>>> I'm going to add noreg label and write an instruction to the QA 
>>> about how to test the fix manually.
>>>
>>> What is good is that we don't need another shell-based test.
>>>
>>> Here's the new webrev: 
>>> http://cr.openjdk.java.net/~igerasim/8023130/3/webrev/ 
>>> 
>>> Its only difference is that the shell script is excluded.
>> JPRT may be using ssh but others will likely run the tests in other 
>> configurations. If the shell test allows the scenario to be tested in 
>> other configurations then it may be better to just include it in your 
>> patch (in general we want to eliminate as many shell tests as 
>> possible but a shell tests bets the cost of a manual test any day).
>
> I totally agree with you that any automated test is better than any 
> manual.
> The problem is that I couldn't make the test fail no matter how I 
> invoked it - from JPRT, from a locally running jtreg or even from 
> plain cygwin.
> The only way I could reproduce the problem with unpatched jdk was to 
> run the test application directly from a Windows console.
>
> Sincerely yours,
> Ivan
>
>>
>> -Alan.
>
>
>



From peter.levart at gmail.com  Fri Sep 20 16:38:28 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Sep 2013 18:38:28 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C2F5E.5010301@gmx.org>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com> <523C2F5E.5010301@gmx.org>
Message-ID: <523C7A04.8030606@gmail.com>

On 09/20/2013 01:19 PM, Jochen Theodorou wrote:
> that is I think a usecase for some... as I said, getCallerClass(int) 
> is not really ideal for us either. More ideal in this style would be 
> for us
>
>>  public static  T findCaller(Predicate predicate,
>>                                 Function function)
>
> with the predicate indicating when to stop.. 

As I understand the Thread.firstCaller() does exactly that. 
"findFirstCallerMatchingPredicate". Choosen name abbreviation is maybe 
not making the semantic immediately obvious.

> though the usage of this is not that nice:
>
>> Class getCallerClass(final int nonSkippedFramesDepth) {
>>    return findCaller(new Predicate() {
>>         int depth = 0;
>>         boolean test(StackFrameInfo info) {
>>                     if (haveToSkip(info.getDeclaringClass())) return 
>> false;
>>                     depth++;
>>                     if (depth>=nonSkippedFramesDepth) return 
>> info.getDeclaringClass();
>>                 }
>>           }, StackFrameInfo::getDeclaringClass());
>> }
>

But the API is making it possible without walking entire stack or making 
N partial walks with lengths 1..N, which is O(N^2)...

More compact, using lambda:

Class getCallerClass(int nonSkippedFramesDepth) {
    int[] depth = new int[1];
    return Thread.fistCaller(
       info -> !haveToSkip(info.getDeclaringClass()) && (++depth[0] > 
nonSkippedFramesDepth),
       StackFrameInfo::getDeclaringClass
    );
}

> Have you guys though about exposing the StackStream instead? Then you 
> could use all the existing JDK method for streams on that, which gives 
> you a much more flexible API. I could then for example change the 
> Stream of StackFrameInfo into one of Class.

I don't think StackStream is-a Stream ...

Peter

>
> bye Jochen 



From naoto.sato at oracle.com  Fri Sep 20 17:11:04 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Sep 2013 10:11:04 -0700
Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles
In-Reply-To: <523C4097.10200@oracle.com>
References: <523C4097.10200@oracle.com>
Message-ID: <523C81A8.5060508@oracle.com>

Hi Daniel,

I only looked at the ResourceBundle portion of the changeset, and it 
looks good to me (assuming it'll go through the CCC).

Naoto

On 9/20/13 5:33 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8013839: Enhance Logger API for handling of resource bundles, and
> 4814565: (rb) add method to get basename from a ResourceBundle
>
> 
>
>     1. It adds a ResourceBundle.getBaseBundleName() method,
>     2. It adds a Logger.setResourceBundle(ResourceBundle) method,
>     3. It adds a series of Logger.logrb(...) that take a ResourceBundle
>          object instead of a ResourceBundle name.
>          The previous versions of Logger.logrb(...) that took a
>          resource bundle name are therefore no longer needed,
>          they offer no added value above the new methods, and
>          are thus now deprecated.
>
> Logger.getLogger(name, rbname) will continue to work as before,
>       and will also throw an exception if a RB with a different name
>       has been set before, either through setResourceBundle or
>       Logger.getLogger(name, rbname).
>
> Logger.setResourceBundle works similarly to
>       Logger.getLogger(name, rbname) in the sense that it will not
>       allow to replace an existing bundle, unless both have the same
>       name. Like for Logger.getLogger(name, rbname) - it doesn't matter
>       by which method the previous bundle has been set.
>
>       This is mostly for consistency of the API - if thread A has
>       requested a logger with resource bundle name 'foo.Bundle'
>       and thread B attempts to set the resource bundle of that
>       logger to 'bar.Bundle' then thread B will get an IAE.
>
>       The resource bundle passed to Logger.setResourceBundle *must*
>       have a base name. Note that ResourceBundle objects will have
>       a base name by default if they have been loaded through
>       one of the ResourceBundle.getBundle(...) methods;
>       If ResourceBundle.getBaseBundleName() returns null an IAE
>       will be thrown.
>
>       Logger.setResourceBundle requires the "control" permission.
>
>       When a resource bundle is set with Logger.setResourceBundle,
>       then it's that resource bundle locale that will be used
>       when logging (and not the default locale).
>
> I have written a set of unit tests which should cover all the points
> listed above.
>
> best regards,
>
> -- daniel



From mandy.chung at oracle.com  Fri Sep 20 18:00:28 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Sep 2013 11:00:28 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C1468.6020401@gmail.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C1468.6020401@gmail.com>
Message-ID: <523C8D3C.5090608@oracle.com>

On 9/20/13 2:24 AM, Peter Levart wrote:
> Mandy: I like the API. It covers the use-cases optimally. I can see 
> how StackStreamcould be implemented with a single JNI -> Java callback 
> per StackFrameInfo...  Why not using the same call-back principle for 
> Throwable API too. 

One important design goal is to minimize the VM transition (did I 
mention it in an early mail?  My apology if I missed that).  One 
approach is to fetch stack frames one batch at a time and the users can 
give the VM hint to determine a good size of each batch and allocate an 
estimated size of buffer for the stack frames.  To filter and find one 
frame only, the implementation should pass a smaller buffer for JVM to 
fill the stack frames in one single VM transition.  To walk the entire 
stack, it could be like Throwable.fillInStackTrace to pass a bigger 
array for VM to fill.

The VM transition has a costand that's the performance issue that Nick 
fixed in Throwable.getStackTrace(). Instead of calling VM to fill one 
element at a time, his patch has the VM to fill the entire 
StackTraceElement array.  To get a stack frame, the VM may have to flush 
the registers and other machinery out - this is the cost that should be 
avoided if the user is not interested in the entire stack trace.

> Instead of implementing Throwable.walkStackTracein terms of 
> getStackTrace it could be the other way around. For completeness, 
> getCaller() and firstCaller() could also be added to Throwable 
> although we don't yet have a use-case for that. 

Will give more thought on this.  There are open issues and discussion to 
follow on my proposal.

I sent this out last night because I want to share the proposal early 
enough to get feedback.  Thank you, Peter, for your replies to answer 
some of the questions.

Mandy


From paul.sandoz at oracle.com  Fri Sep 20 18:24:44 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 20 Sep 2013 18:24:44 +0000
Subject: hg: jdk8/tl/jdk: 8024253: ThreadLocal random can use SecureRandom for
	the initial seed
Message-ID: <20130920182538.5F238629E5@hg.openjdk.java.net>

Changeset: 7913855ff66c
Author:    psandoz
Date:      2013-09-20 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7913855ff66c

8024253: ThreadLocal random can use SecureRandom for the initial seed
Reviewed-by: psandoz, chegar, alanb
Contributed-by: Doug Lea 
, Peter Levart , Guy Steele 

! src/share/classes/java/util/SplittableRandom.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java



From mandy.chung at oracle.com  Fri Sep 20 18:46:44 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Sep 2013 11:46:44 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C2F5E.5010301@gmx.org>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com> <523C2F5E.5010301@gmx.org>
Message-ID: <523C9814.4090805@oracle.com>

Jochen,

On 9/20/13 4:19 AM, Jochen Theodorou wrote:
> Am 20.09.2013 12:05, schrieb Peter Levart:
> [...]
>> The use-cases described used getCallerClass(int depth) repeatedly to
>> find a caller by iterating over a range of depths and calling
>> getCallerClass(depth). You can use either Thread.walkStack or
>> Thread.firstCaller for implementing those use-cases.
>
> first Caller is only going back one, or not? Not useful for us in the 
> cases we need this. I wouldn't say the API through getCallerClass(int) 
> was optimal for us, I think the new one can be better... I only miss 
> (or didn't get how) the ability not to have to walk the entire stack, 
> without knowing before how deep I have to go

What I understand is that Groovy [1] is similar to what 
j.u.logging.LogRecord.inferCaller that skips the frames of the internal 
Groovy implementation as well as reflection classes.

   
    Thread.firstCaller(e -> {return !isLoggerImplFrame(e.getClassName()); }, Function::identity);

For example,

	java.lang.Thread.firstCaller
	java.util.logging.LogRecord.inferCaller
	java.util.logging.LogRecord.getSourceClassName
	java.util.logging.SimpleFormatter.format
	java.util.logging.StreamHandler.publish
	java.util.logging.ConsoleHandler.publish
	java.util.logging.Logger.log
	java.util.logging.Logger.doLog
	java.util.logging.Logger.log
	java.util.logging.Logger.severe
         sun.reflect.....
         sun.reflect.....
         java.lang.reflect.Method.invoke
	Hi.foo  <----- the first caller that isLoggerImplFrame returns true.
         ....

The firstCaller method will stop at the first non-reflection frame that 
the given predicate returns true.

Thread.getCaller method is equivalent to calling
       Thread.firstCaller(skipToSecondPredicate, Function::identity);

I have some trouble in expressing the skipToSecondPredicate without side 
effect in lambda.  With the help from Paul Sandoz (thanks Paul), if I 
had a stack stream, Thread.getCaller() method would be like this:
    stream.filter(e -> return 
REFLECTION_CLASSES.contains(e->getClassName()))
              .skip(2).findFirst();

With the example you gave below, I think a method that takes a parameter 
to skip the number of frames that matches the predicate will be useful:

    findCaller(Predicate predicate,
               int skips,
               Function function)

Thread.getCaller is equivalent to calling
       findCaller(e -> { return true; }, 2, function);


See below for your example.

[1] 
https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/reflection/ReflectionUtils.java#L105

>
>> Maybe the following method would be handy to optimize search when we
>> know that we want to skip 1st N frames before starting testing with
>> predicate:
>>
>> public static  T firstCaller(int startDepth,
>>                                  Predicate predicate,
>> Function function) {
>>
>>
>> Reflection.getCallerClass(depth)
>>
>> then becomes:
>>
>> Thread.firstCaller(depth, f -> true, StackFrameInfo::getDeclaringClass);
>>
>>
>> Hm...
>
> that is I think a usecase for some... as I said, getCallerClass(int) 
> is not really ideal for us either. More ideal in this style would be 
> for us
>
>>  public static  T findCaller(Predicate predicate,
>>                                 Function function)
>
> with the predicate indicating when to stop.. though the usage of this 
> is not that nice:
>
>> Class getCallerClass(final int nonSkippedFramesDepth) {
>>    return findCaller(new Predicate() {
>>         int depth = 0;
>>         boolean test(StackFrameInfo info) {
>>                     if (haveToSkip(info.getDeclaringClass())) return 
>> false;
>>                     depth++;
>>                     if (depth>=nonSkippedFramesDepth) return 
>> info.getDeclaringClass();
>>                 }
>>           }, StackFrameInfo::getDeclaringClass());
>> }
>
> Have you guys though about exposing the StackStream instead? Then you 
> could use all the existing JDK method for streams on that, which gives 
> you a much more flexible API. I could then for example change the 
> Stream of StackFrameInfo into one of Class.

Exposing a StackStream API means that you need to eagerly walk the stack 
and copy the stack frames to it before it returns.  I agree it is a much 
more flexible API.  On the other hand, stack walking is sequential and 
ordered and a stack stream will be traversed as in an iterator.

What about a findCaller method that takes a parameter to indicate how 
many times you skip over the matching elements before applying the function:

    Thread.findCaller(info -> {return !haveToSkip(info.getDeclaringClass());},
                      nonSkippedFramesDepth,
                      StackFrameInfo::getDeclaringClass());

Getting a StackStream instance would be performant only if you know the 
number of frames that guarantees to find the matching frame. The 
Thread.findCaller method allows the stack walk engine to perform the 
lazy computation without doing the eager copying.

Mandy


From paul.sandoz at oracle.com  Fri Sep 20 19:05:15 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Sep 2013 12:05:15 -0700
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is
	null and the key is absent
In-Reply-To: <31F446B3-A1FB-44C7-887E-B78979F9B05C@oracle.com>
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
	<574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
	<1DA14A6A-CD1E-4FC1-BC0A-235F3F623BE7@Oracle.COM>
	<7E8EB639-9908-4658-96EF-FB414EDF445D@oracle.com>
	<5238FBEB.4030907@univ-mlv.fr>
	<31F446B3-A1FB-44C7-887E-B78979F9B05C@oracle.com>
Message-ID: 


On Sep 19, 2013, at 2:31 PM, Brian Burkhalter  wrote:

> On Sep 17, 2013, at 6:03 PM, Remi Forax wrote:
> 
>> On 09/18/2013 02:08 AM, Brian Burkhalter wrote:
>>> The proposed patch has been updated at the same location:
>>> 
>>> http://cr.openjdk.java.net/~bpb/8024331/.
>>> 
>>> Thanks,
>>> 
>>> Brian
>> 
>> looks good.
>> 
>> R?mi
> 
> Thanks, R?mi
> 
> JDK 8 Reviewers: This patch still needs Official Approval unless of course there are objections.
> 

Looks ok to me,
Paul.

From paul.sandoz at oracle.com  Fri Sep 20 19:11:44 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Sep 2013 12:11:44 -0700
Subject: RFR: 8023339 & 8023340 : (xs) Refine throws UOE/NPE Conditions
In-Reply-To: <42F9A023-664B-4AEF-B071-D7315F28400C@oracle.com>
References: <42F9A023-664B-4AEF-B071-D7315F28400C@oracle.com>
Message-ID: 

Hi Mike,

You made changes to the documentation of List.replaceAll which does not perform matching:

 398      * @param operator the operator to apply to each element
 399      * @throws UnsupportedOperationException if this list is unmodifiable.
 400      *         Implementations may throw this exception if a matching element
 401      *         cannot be replaced or if, in general, modification is not
 402      *         supported
 403      * @throws NullPointerException if the specified operator is null or
 404      *         if the operator result is a null value and this list does
 405      *         not permit null elements
 406      *         (optional)
 407      * @since 1.8
 408      */
 409     default void replaceAll(UnaryOperator operator) {

* @throws UnsupportedOperationException if this list is unmodifiable.
*         Implementations may throw this exception if an element
*         cannot be replaced or if, in general, modification is not
*         supported

?

Paul.

On Sep 17, 2013, at 3:35 PM, Mike Duigou  wrote:

> Hello all;
> 
> Another, hopefully final, attempt at refining the @throws UOE javadoc for Collections.removeIf and the @throws UOE and NPE javadoc for List.replaceAll().
> 
> This cycle adopts the verbiage suggested by Paul Sandoz in the last round of 8023339.
> 
> Both changesets are combined into a single webrev:
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8023340/1/webrev/
> 
> Thanks,
> 
> Mike


From brian.burkhalter at oracle.com  Fri Sep 20 19:15:40 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 20 Sep 2013 12:15:40 -0700
Subject: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault
	implementations don't throw NPE if the remappingFunction is
	null and the key is absent
In-Reply-To: 
References: <1AB1DED2-CF29-44C0-BB95-081E53FAB1FB@oracle.com>
	<574BDB64-564E-4F89-AF14-F47751E08412@oracle.com>
	<1DA14A6A-CD1E-4FC1-BC0A-235F3F623BE7@Oracle.COM>
	<7E8EB639-9908-4658-96EF-FB414EDF445D@oracle.com>
	<5238FBEB.4030907@univ-mlv.fr>
	<31F446B3-A1FB-44C7-887E-B78979F9B05C@oracle.com>
	
Message-ID: <20F557A2-9140-40C8-9939-C80246C8FE46@oracle.com>


On Sep 20, 2013, at 12:05 PM, Paul Sandoz wrote:

>> JDK 8 Reviewers: This patch still needs Official Approval unless of course there are objections.
>> 
> 
> Looks ok to me,

Cool.

Thanks,

Brian

From mandy.chung at oracle.com  Fri Sep 20 19:25:13 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Sep 2013 12:25:13 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C0E2C.1030206@gmx.org>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
Message-ID: <523CA119.20601@oracle.com>

On 9/20/13 1:58 AM, Jochen Theodorou wrote:
> Am 20.09.2013 09:09, schrieb Mandy Chung:
> [...]
>> Stack is a "stream" that allows you to walk partial stack (e.g. find
>> caller) or full stack trace (e.g. throwable). The filtering and mapping
>> operations are lazy to avoid having the VM eagerly copying the entire
>> stack trace data even for the short reach case (like Groovy and Log4j).
>
> and is there a link to StackStram too?

No.  The concrete implementation is yet to be done and it would need a 
new VM entry point that the library code to use.

It's not interesting to read what I did in my hack version that is 
intended to help design how the API works with the use cases.

> The Thread#walkStack methods don't really describe the behaviour of 
> the consumer. Will the consumer applied only once, or multiple times? 

Apply once to each element like Iterable.forEach.
> If only once, then to replace getCallerClass(int depth), you will need 
> the version with the predicate, which will be difficult to realize 
> with a simple lambda, since you will need to count as well.
>

Ah... I see what you need as you mentioned in [1]. Thread.getCaller 
skips the first frame that matches the predicate and you want to be able 
to control the number of skips.  Just curious - do you mind explaining 
what the matchLevel is in 
org.codehaus.groovy.reflection.ReflectionUtils.getCallingClass(int 
matchLevel, Collection extraIgnoredPackages)?

I understand matchLevel == 1 when you look for the immediate caller.   
Understand what situation do you look for matchLevel > 1?

Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021243.html
https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/reflection/ReflectionUtils.java#L105


From blackdrag at gmx.org  Fri Sep 20 21:07:06 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 23:07:06 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C6DB3.6040302@gmail.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com>
	
	<523C0E0B.7040407@gmx.org> <523C16B7.7080708@gmail.com>
	<523C29EE.4030907@gmx.org> <523C6DB3.6040302@gmail.com>
Message-ID: <523CB8FA.4000203@gmx.org>

Am 20.09.2013 17:45, schrieb Peter Levart:
[...]
> I think the reasoning behind call-back API is that it moves the logic to
> construct a suitable data structure to the Java side, skipping
> intermediary representations and conversions.

StackFrameInfo is already a conversion for me. I see some value in the 
additional ability to impose security checks, but nothing for ease of 
use. I somehow cannot believe that StackFrameInfo is a structure the VM 
uses internally to manage stack frames

> I don't know what the
> overhead of call-backs from native code to Java is though. For
> constructing and returning an array of StackFrameInfo objects, the
> native code has to collect the objects into a GrowableArray (a native
> equivalent of ArrayList). Before returning, it has to copy elements into
> the Java array. And this Java array is usually later used just to
> iterate it's elements... Imagine a situation where GrowableArray and
> Java array could be skipped and StackFrameInfo objects directly
> formatted into a StringBuilder, creating the final logger message. This
> assumes that call-backs from native code are cheap. Are they? Can native
> method be intrinsified together with call-back invocations?

You won't need a GrowableArray if you know the stack length. Then you 
can just create the target StackFrameInfo[]

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From blackdrag at gmx.org  Fri Sep 20 21:21:19 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 23:21:19 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C7A04.8030606@gmail.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com> <523C2F5E.5010301@gmx.org>
	<523C7A04.8030606@gmail.com>
Message-ID: <523CBC4F.60600@gmx.org>

Am 20.09.2013 18:38, schrieb Peter Levart:
[...]
> As I understand the Thread.firstCaller() does exactly that.
> "findFirstCallerMatchingPredicate". Choosen name abbreviation is maybe
> not making the semantic immediately obvious.

then sorry, I overlooked that in the link

>> though the usage of this is not that nice:
>>
>>> Class getCallerClass(final int nonSkippedFramesDepth) {
>>>    return findCaller(new Predicate() {
>>>         int depth = 0;
>>>         boolean test(StackFrameInfo info) {
>>>                     if (haveToSkip(info.getDeclaringClass())) return
>>> false;
>>>                     depth++;
>>>                     if (depth>=nonSkippedFramesDepth) return
>>> info.getDeclaringClass();
>>>                 }
>>>           }, StackFrameInfo::getDeclaringClass());
>>> }
>>
>
> But the API is making it possible without walking entire stack or making
> N partial walks with lengths 1..N, which is O(N^2)...

You know the trouble with the O-notation. For once, there are constants 
in this, that are not mentioned and for second O(N^2) is only always 
better than any O(N^3) if N is big enough. Otherwise even an O(2^N) can 
be less effort. And the lengths we are talking here about are not big Ns

> More compact, using lambda:
>
> Class getCallerClass(int nonSkippedFramesDepth) {
>     int[] depth = new int[1];
>     return Thread.fistCaller(
>        info -> !haveToSkip(info.getDeclaringClass()) && (++depth[0] >
> nonSkippedFramesDepth),
>        StackFrameInfo::getDeclaringClass
>     );
> }

silly me... of course... why do I return the class when I need to return 
a boolean.. its been a long day already... ok, your version is accepted 
;)  using an array instead is quite the hack for me, but we are used to 
that for Java AIC

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From blackdrag at gmx.org  Fri Sep 20 21:46:04 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 23:46:04 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C9814.4090805@oracle.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com> <523C2F5E.5010301@gmx.org>
	<523C9814.4090805@oracle.com>
Message-ID: <523CC21C.4060801@gmx.org>

Am 20.09.2013 20:46, schrieb Mandy Chung:
[...]
> Exposing a StackStream API means that you need to eagerly walk the stack
> and copy the stack frames to it before it returns.  I agree it is a much
> more flexible API.  On the other hand, stack walking is sequential and
> ordered and a stack stream will be traversed as in an iterator.

not the StackStream API, I did mean a Stream as in 
http://download.java.net/lambda/b78/docs/api/java/util/stream/Stream.html But 
I must say, I did not realize Stream has so little to offer in terms of 
default implementations. I am not saying using this class is a good 
idea, but if you already go on lambdas, then this should be at least 
something to consider... and to underline it: Stream does not require 
you to eagerly read all values

> What about a findCaller method that takes a parameter to indicate how
> many times you skip over the matching elements before applying the
> function:
>
>     Thread.findCaller(info -> {return
> !haveToSkip(info.getDeclaringClass());},
>                       nonSkippedFramesDepth,
>                       StackFrameInfo::getDeclaringClass());

just to show you how this could work with the Stream

Thread.getStackStream().
       filter(info -> {return !haveToSkip(info.getDeclaringClass());}.
       subStream(nonSkippedFramesDepth).
       map(StackFrameInfo::getDeclaringClass).findFirst()

I am looking at those things since only recently, so there is surely a 
better way, but have an impression it should be enough. Especially I 
show this to you, so you can see that with a Stream no new method is needed.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From blackdrag at gmx.org  Fri Sep 20 21:49:49 2013
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 20 Sep 2013 23:49:49 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523C9814.4090805@oracle.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com> <523C2F5E.5010301@gmx.org>
	<523C9814.4090805@oracle.com>
Message-ID: <523CC2FD.8070805@gmx.org>

Am 20.09.2013 20:46, schrieb Mandy Chung:
[...]
> I have some trouble in expressing the skipToSecondPredicate without side
> effect in lambda.  With the help from Paul Sandoz (thanks Paul), if I
> had a stack stream, Thread.getCaller() method would be like this:
>     stream.filter(e -> return
> REFLECTION_CLASSES.contains(e->getClassName()))
>               .skip(2).findFirst();

and here I was and tried to show you what a Stream really is... I should 
have read that mail before the other ;) Only I was irritated not to find 
skip in 
http://download.java.net/lambda/b78/docs/api/java/util/stream/Stream.html I 
have seen skip in several examples. Anyway... has nothing to do with the 
matter here

  bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



From kumar.x.srinivasan at oracle.com  Fri Sep 20 21:59:20 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 20 Sep 2013 14:59:20 -0700
Subject: RFR: 8016110: Japanese char (MS932) 0x5C cannot be used as an argument
	when quoted
Message-ID: <523CC538.2040301@oracle.com>

Hi Naoto, Sherman, Akhil,

Can you please review this:
http://cr.openjdk.java.net/~ksrini/8016110/webrev.0

Bug:
http://bugs.sun.com/view_bug.do?bug_id=8016110

The code was provided by IBM, I wrote up the test.

Thanks
Kumar




From vladimir.x.ivanov at oracle.com  Fri Sep 20 22:07:12 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 21 Sep 2013 02:07:12 +0400
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
In-Reply-To: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
Message-ID: <523CC710.5030806@oracle.com>

John,

I cleaned javadoc a little [1], so it is more readable in the browser now.

The test code looks ok, though the logic is over-complicated.
But the whole MethodHandlesTest is written in the same vein.

Best regards,
Vladimir Ivanov

diff --git a/src/share/classes/java/lang/invoke/MethodHandles.java 
b/src/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/share/classes/java/lang/invoke/MethodHandles.java
@@ -2013,6 +2013,7 @@
       * 

       * In all cases, {@code pos} must be greater than or equal to 
zero, and
       * {@code pos} must also be less than or equal to the target's arity.
+     * 

       * Example:
       * 
  import static java.lang.invoke.MethodHandles.*;
@@ -2020,17 +2021,22 @@
  ...
  MethodHandle deepToString = publicLookup()
    .findStatic(Arrays.class, "deepToString", methodType(String.class, 
Object[].class));
+
  MethodHandle ts1 = deepToString.asCollector(String[].class, 1);
  assertEquals("[strange]", (String) ts1.invokeExact("strange"));
+
  MethodHandle ts2 = deepToString.asCollector(String[].class, 2);
  assertEquals("[up, down]", (String) ts2.invokeExact("up", "down"));
+
  MethodHandle ts3 = deepToString.asCollector(String[].class, 3);
  MethodHandle ts3_ts2 = collectArguments(ts3, 1, ts2);
  assertEquals("[top, [up, down], strange]",
               (String) ts3_ts2.invokeExact("top", "up", "down", 
"strange"));
+
  MethodHandle ts3_ts2_ts1 = collectArguments(ts3_ts2, 3, ts1);
  assertEquals("[top, [up, down], [strange]]",
               (String) ts3_ts2_ts1.invokeExact("top", "up", "down", 
"strange"));
+
  MethodHandle ts3_ts2_ts3 = collectArguments(ts3_ts2, 1, ts3);
  assertEquals("[top, [[up, down, strange], charm], bottom]",
               (String) ts3_ts2_ts3.invokeExact("top", "up", "down", 
"strange", "charm", "bottom"));


On 9/13/13 6:55 AM, John Rose wrote:
> Please review this change for a change to the JSR 292 implementation:
>
> http://cr.openjdk.java.net/~jrose/8001110/webrev.00/
>
> Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types
>
> The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
>
> Bug Description:  Currently, a method handle can be transformed so that multiple arguments are collected and passed to the original method handle. However, the two routes to doing this are both limited to special purposes.
>
> (They are asCollector, which collects only trailing arguments, and only into an array; and foldArguments, which collects only leading arguments into filter function, and passes both the filtered result *and* the original arguments to the original.)
>
> MethodHandles.collectArguments(mh, pos, collector) should produce a method handle which acts like lambda(a*, b*, c*) { x = collector(b*); return mh(a*, x, c*) }, where the span of arguments b* is located by pos and the arity of the collector.
>
> There is internal machinery in any JSR 292 implementation to do this. It should be made available to users.
>
> This is a missing part of the JSR 292 spec.
>
> Thanks,
> ? John
>
> P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
> Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
>


From brian.burkhalter at oracle.com  Fri Sep 20 22:13:59 2013
From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com)
Date: Fri, 20 Sep 2013 22:13:59 +0000
Subject: hg: jdk8/tl/jdk: 8024331: j.u.Map.computeIfPresent()
	default/nondefault implementations don't throw NPE if the
	remappingFunction is null and the key is absent
Message-ID: <20130920221443.E34CA629F3@hg.openjdk.java.net>

Changeset: 2552cd270350
Author:    bpb
Date:      2013-09-20 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2552cd270350

8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent
Summary: Explicitly check for null remappingFunction parameter.
Reviewed-by: mduigou, forax, psandoz
Contributed-by: Brian Burkhalter 

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Map.java
! test/java/util/Map/Defaults.java



From dl at cs.oswego.edu  Fri Sep 20 23:14:02 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 20 Sep 2013 19:14:02 -0400
Subject: SplittableRandom update
In-Reply-To: <60518C87-9FB9-4B07-A074-E925691AF1F3@oracle.com>
References: <523C57A6.2000508@cs.oswego.edu>
	
	<60518C87-9FB9-4B07-A074-E925691AF1F3@oracle.com>
Message-ID: <523CD6BA.20704@cs.oswego.edu>

On 09/20/2013 11:36 AM, Paul Sandoz wrote:
> Hi Kasper,
>
> Can you please log a bug [1] (and also note that ThreadLocal/Random does the same) ?
>
> My preference would be to get this code in and fix the error reporting separately.
>

Even though a minor nuisance, I agree; it would be a simple
practice bug for us (especially me!) to get used to the
newly-externally-accessible bug system.

-Doug

> [1] https://bugs.openjdk.java.net/
>
>
> On Sep 20, 2013, at 8:25 AM, Kasper Nielsen  wrote:
>
>> Hi,
>>
>> This is minor, but I hate it when bounds check does not include the
>> specified parameters.
>> Makes it much harder to track down a bug, if all you have is a stack trace.
>>
>> - Kasper
>>
>>
>> On Fri, Sep 20, 2013 at 4:11 PM, Doug Lea 
 wrote:
>>
>>>
>>> In the course of writing up a report (coming soon) that includes
>>> discussion of SplittableRandom, we had a chance to further
>>> analyze and test things, resulting in a few small improvements. Plus
>>> some internal renamings to better reflect intent.
>>> Plus now with the same initial seed mechanics
>>> discussed a few days ago for ThreadLocalRandom.
>>>
>>> Thanks to Paul Sandoz for creating webrevs:
>>>
>>> https://bugs.openjdk.java.net/**browse/JDK-8025136
>>>
>>> http://cr.openjdk.java.net/~**psandoz/tl/JDK-8025136-SR-**
>>> enhancements/webrev/
>>>
>>> I think we need one more reviewer for it.
>>>
>>> -Doug
>>>
>



From naoto.sato at oracle.com  Fri Sep 20 23:18:40 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Sep 2013 16:18:40 -0700
Subject: RFR: 8016110: Japanese char (MS932) 0x5C cannot be used as an
	argument when quoted
In-Reply-To: <523CC538.2040301@oracle.com>
References: <523CC538.2040301@oracle.com>
Message-ID: <523CD7D0.30101@oracle.com>

Hi Kumar,

Here are my comments:

cmdtoarg.c

- Line 151: 'p' is not used anywhere. Remaining debugging code?
- Line 155: Although this seems to do no harm, but it is not necessary.

I18NArgTest.java

- Currently it is testing only "Katakana SO" which is a single 
character. Maybe some more cases need to be tested?

Naoto

On 9/20/13 2:59 PM, Kumar Srinivasan wrote:
> Hi Naoto, Sherman, Akhil,
>
> Can you please review this:
> http://cr.openjdk.java.net/~ksrini/8016110/webrev.0
>
> Bug:
> http://bugs.sun.com/view_bug.do?bug_id=8016110
>
> The code was provided by IBM, I wrote up the test.
>
> Thanks
> Kumar
>
>



From mandy.chung at oracle.com  Fri Sep 20 23:58:49 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Sep 2013 16:58:49 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523CC21C.4060801@gmx.org>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com> <523C2F5E.5010301@gmx.org>
	<523C9814.4090805@oracle.com> <523CC21C.4060801@gmx.org>
Message-ID: <523CE139.9060808@oracle.com>

On 9/20/2013 2:46 PM, Jochen Theodorou wrote:
>> Exposing a StackStream API means that you need to eagerly walk the stack
>> and copy the stack frames to it before it returns.  I agree it is a much
>> more flexible API.  On the other hand, stack walking is sequential and
>> ordered and a stack stream will be traversed as in an iterator.
> to underline it: Stream does not require you to eagerly read all values 


Yes.  What I was trying to explain is that if we want to return a Stream 
instance to the caller and traverse later, it means that it has to take 
a snapshot of the stack trace of the current thread. The stack trace 
data has to be stored in whatever data structure like how Throwable is 
currently implemented.

I think referring this as a "stream" cause the confusion - will revisit 
this.

Mandy


From john.r.rose at oracle.com  Sat Sep 21 00:09:07 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 20 Sep 2013 17:09:07 -0700
Subject: RFR (M) 8001110: method handles should have a collectArguments
	transform, generalizing asCollector
In-Reply-To: <523CC710.5030806@oracle.com>
References: <06D6C12B-CE7F-4180-8DD2-222B9CEE8CB8@oracle.com>
	<523CC710.5030806@oracle.com>
Message-ID: 

On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov  wrote:

> I cleaned javadoc a little [1], so it is more readable in the browser now.

Thanks; I applied those edits.  I fixed the problem of a missing 
 in a few other places too.

> The test code looks ok, though the logic is over-complicated.
> But the whole MethodHandlesTest is written in the same vein.

Thanks.  (Looks like it wasn't written by a real test engineer.)

? John

From paul.sandoz at oracle.com  Sat Sep 21 00:12:55 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Sat, 21 Sep 2013 00:12:55 +0000
Subject: hg: jdk8/tl/jdk: 8024341: j.u.regex.Pattern.splitAsStream() doesn't
	correspond to split() method if using an example from the spec
Message-ID: <20130921001330.8DC40629F5@hg.openjdk.java.net>

Changeset: c30dc8e7744e
Author:    psandoz
Date:      2013-09-20 17:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c30dc8e7744e

8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec
Reviewed-by: alanb

! src/share/classes/java/util/regex/Pattern.java
+ test/java/util/regex/PatternStreamTest.java
- test/java/util/regex/PatternTest.java



From forax at univ-mlv.fr  Sat Sep 21 00:25:23 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 21 Sep 2013 02:25:23 +0200
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523CE139.9060808@oracle.com>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com> <523C2F5E.5010301@gmx.org>
	<523C9814.4090805@oracle.com> <523CC21C.4060801@gmx.org>
	<523CE139.9060808@oracle.com>
Message-ID: <523CE773.1060206@univ-mlv.fr>

On 09/21/2013 01:58 AM, Mandy Chung wrote:
> On 9/20/2013 2:46 PM, Jochen Theodorou wrote:
>>> Exposing a StackStream API means that you need to eagerly walk the 
>>> stack
>>> and copy the stack frames to it before it returns.  I agree it is a 
>>> much
>>> more flexible API.  On the other hand, stack walking is sequential and
>>> ordered and a stack stream will be traversed as in an iterator.
>> to underline it: Stream does not require you to eagerly read all values 
>
>
> Yes.  What I was trying to explain is that if we want to return a 
> Stream instance to the caller and traverse later, it means that it has 
> to take a snapshot of the stack trace of the current thread. The stack 
> trace data has to be stored in whatever data structure like how 
> Throwable is currently implemented.
>
> I think referring this as a "stream" cause the confusion - will 
> revisit this.
>
> Mandy

What you can do is to call a function that will take the stream as 
argument and close the stream after its use and before returning.

 R processStackStream(Function fun) {
     StackStream stackStream = new 
StackStream(Thread.currentThread());   // bias the stack stream on the 
current thread
// the current thread is checked before doing something on the stream.
     try {
       return fun.apply(stackStream);  // the stack stream is visible by 
the user, but it can not use it in another thread
     } finally {
       stackStream.close();   // set a flag saying that you can't access 
to the underlying stack stream anymore
                                               // the flag doesn't need 
to be volatile if the current thread is checked first
     }
  }

cheers,
R?mi



From mandy.chung at oracle.com  Sat Sep 21 00:43:55 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Sep 2013 17:43:55 -0700
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: <523CE773.1060206@univ-mlv.fr>
References: <52389222.4090300@bbs.darktech.org> <5238C15F.4080408@oracle.com>
	<18DC3559-D915-4FB0-9866-A947BE41F04C@nicholaswilliams.net>
	<523BF49F.2030300@oracle.com> <523C0E2C.1030206@gmx.org>
	<523C1DF3.7070002@gmail.com> <523C2F5E.5010301@gmx.org>
	<523C9814.4090805@oracle.com> <523CC21C.4060801@gmx.org>
	<523CE139.9060808@oracle.com> <523CE773.1060206@univ-mlv.fr>
Message-ID: <523CEBCB.4010207@oracle.com>


On 9/20/2013 5:25 PM, Remi Forax wrote:
> What you can do is to call a function that will take the stream as 
> argument and close the stream after its use and before returning.
>
>  R processStackStream(Function fun) {
>     StackStream stackStream = new 
> StackStream(Thread.currentThread());   // bias the stack stream on the 
> current thread
> // the current thread is checked before doing something on the stream.
>     try {
>       return fun.apply(stackStream);  // the stack stream is visible 
> by the user, but it can not use it in another thread
>     } finally {
>       stackStream.close();   // set a flag saying that you can't 
> access to the underlying stack stream anymore
>                                               // the flag doesn't need 
> to be volatile if the current thread is checked first
>     }
>  } 

Good idea.  I'll explore this.

thanks
Mandy


From john.r.rose at oracle.com  Sat Sep 21 01:18:05 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 20 Sep 2013 18:18:05 -0700
Subject: RFR (S) 8024599: JSR 292 direct method handles need to respect
	initialization rules for static members
In-Reply-To: <523C69EA.3030107@oracle.com>
References: <2A858714-7C1D-4A3D-B971-E193E1E256D3@oracle.com>
	<239656DF-E18F-4F88-8983-38C3ECE15DD3@oracle.com>
	<523C69EA.3030107@oracle.com>
Message-ID: <11945016-EBBA-48B6-8881-5648BD285BE7@oracle.com>

On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov  wrote:

> John,
> 
> I don't see much value in documenting buggy behavior of early JDK7 in JDK8 code. So, I would remove it.

OK.  I think I had it in mainly to make sure the unit tests did something interesting.

> Regarding the test:
>  31  * @run main/othervm/timeout=3600
>  - why do you have timeout set to 1h?

Copy-and-paste from some other test.  Removed.

> I like the idea how you count events.
> 
> As a suggestion for enhancement - maybe it's more reliable to check the "type" of event as well? To ensure that particular class was initialized.

Good idea.  But since each unique init event is stored in a separate variable, it's easy to check this without explicit event types.  I did the following, for each of the six test cases:

@@ -150,9 +150,11 @@
     }
 
     private static int runFoo() throws Throwable {
+        assertEquals(Init1Tick, 0);  // Init1 not initialized yet
         int t1 = tick("runFoo");
         int t2 = (int) INDY_foo().invokeExact();
         int t3 = tick("runFoo done");
+        assertEquals(Init1Tick, t2);  // when Init1 was initialized
         assertEquals(t1+2, t3);  // exactly two ticks in between
         assertEquals(t1+1, t2);  // init happened inside
         return t2;


? John

> Best regards,
> Vladimir Ivanov
> 
> On 9/20/13 1:38 AM, John Rose wrote:
>> On Sep 12, 2013, at 7:24 PM, John Rose > > wrote:
>> 
>>> Please review this change for a change to the JSR 292 implementation:
>>> 
>>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
>>> 
>>> Summary: Align MH semantic with bytecode behavior of constructor and
>>> static member accesses, regarding  invocation.
>>> 
>>> The change is to javadoc and unit tests, documenting and testing some
>>> corner cases of JSR 292 APIs.
>> 
>> I have a reviewer (Alex Buckley) for the documentation changes, but I
>> would also like a quick code review for the unit test.
>> 
>> Also, there is a code insertion (predicated on a "false" symbolic
>> constant) which serves to document the buggy JDK 7 behavior.  I'm not
>> particularly attached to it, so I'm open to either a yea or nay on
>> keeping it.  Leaning nay at the moment.
>> 
>> ? John
>> 
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 



From ralph.goers at dslextreme.com  Sat Sep 21 03:28:31 2013
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Fri, 20 Sep 2013 21:28:31 -0600
Subject: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass
	as a public API in Java 8
In-Reply-To: 
References: 
	<5226787F.6060307@oracle.com>
	
Message-ID: <477AC75C-CCA6-48DF-AF91-813441108C90@dslextreme.com>


On Sep 18, 2013, at 9:30 AM, Nick Williams wrote:

> 
> On Sep 3, 2013, at 7:02 PM, Mandy Chung wrote:
> 
> 
>> So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm?
> 
> Maybe one of the other Log4j guys listening in can provide input on this. Ralph? I'm relatively new to the Log4j team (just joined in last 6 months). Personally, I've never heard anyone complain about having issues with the SecurityManager. However, Log4j 1 did not use getCallerClass, and many users are still on that version. Log4j 2 started using getCallerClass.

Log4j 2 is relatively new. However, the feature of adding the jar and version when printing the stack trace is copied from Logback, which has been doing this for years and has a fairly large user base at this point.  Only recently was http://jira.qos.ch/browse/LOGBACK-866 created and it still has no comments on the issue, no votes and only 1 watcher (presumably the person who created the issue). http://jira.qos.ch/browse/LOGBACK-472 was also open for this but it was closed as won't fix as it added too much overhead. Again, that issue has no votes and only the single watcher. So almost no one is having problems with this.

Again, the two use cases we are trying to solve for are:
1. Print the stack trace as shown at http://macstrac.blogspot.com/2008/09/better-stack-traces-in-java-with-log4j.html. Both Log4j 2 and Logback are doing this. If the JDK simply had a 
        public void printExtendedStackTrace(OutputStream) 
or 
        public StackTraceFrame[] getStackTraceFrames() 
methods where all the information necessary to format the stack trace as shown in the link is present our needs would be met on this.
2. Determine the ClassLoader associated with the parent of Class somewhere above the current method in the call stack.  Again, something like
        public ClassLoader getParentClassLoader(String className) 
where we provide a fully qualified class name and the ClassLoader of the Class that called that Class would meet our needs. (Note that in this case the FQCN class may call itself so those calls are skipped to find the parent).

Because the JDK doesn't provide these methods we are basically trying to implement them ourselves and thus need the more basic functionality Nick has been proposing.  I can't say how well any of the proposals perform, but I would think encapsulating these in the JDK would alleviate many of the security concerns.

Ralph

From dmitry.nadezhin at gmail.com  Sat Sep 21 04:13:33 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 21 Sep 2013 08:13:33 +0400
Subject: RFC 6910473: BigInteger negative bit length, value range, and
	future prospects
In-Reply-To: <51D38710.30804@oracle.com>
References: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com>
	<51D38710.30804@oracle.com>
Message-ID: 

It is important that BigInteger objects be full-fledged instances on which
all methods may be correctly invoked.

This bitLength bug started this discussion:
P4 JDK-6910473 : java.math.BigInteger.bitLength() may return negative "int"
on large numbers
https://bugs.openjdk.java.net/browse/JDK-6910473

I reviewed the behavior of very large BigInteger objects and found a few
other bugs:

P3 JDK-8021204 : Constructor BigInteger(String val, int radix) doesn't
detect overflow
https://bugs.openjdk.java.net/browse/JDK-8021204

P3 JDK-8021203 : BigInteger.doubleValue/floatValue returns 0.0 instead of
Infinity
https://bugs.openjdk.java.net/browse/JDK-8021203

P3 JDK-8022780 : Incorrect BigInteger division because of
MutableBigInteger.bitLength() overflow
https://bugs.openjdk.java.net/browse/JDK-8022780

In these bugs (and also in the original bitLength bug) a BigInteger method
silently returns an incorrect result.
Silently incorrect behavior may lead to unexpected failures and difficult
to debug scenarios in applications.

Some applications try to adapt to these bugs with performance overhead. As
clients of java.math.BigInteger can't trust bitLength() , they have to
perform inefficient checks for bitLength overflow. See for example the
methods isValidFloat, isValidDouble, bitLengthOverflow in lines 135-167 of
this file from the Scala library:
https://github.com/scala/scala/blob/master/src/library/scala/math/BigInt.scala

As Brian said:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018403.html
there are two ways to fix bitLength bug:
a) simply by throwing an ArithmeticException if the bit length as an int
would be negative;
b) to define BigInteger to support a limited range and to clamp to that
range in the constructor,
   throwing an ArithmeticException if the supplied parameter(s) would cause
the BigInteger to overflow.
This can be applied to other bugs too.

We found a few bugs appearing on large BigInteger objects, but I'm not sure
that we find all of them.
So I prefer to limit the supported range because this not only fixes known
bugs
but also prevents the occurrence of bugs that haven't been discovered yet.

Joe Darcy suggested that the limiting of the supported range would not be
a specification change but instead an implementation note
"in JDK 8, BigInteger operates on values in the range ....":
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018644.html

So I prepared a patch that fixes the bitLength bug together with another
bugs mentioned above.

The WebRev is here:
http://cr.openjdk.java.net/~bpb/BigIntRange/

This patch limits the supported range of BigInteger in JDK 8. The APIdoc of
the class contains an implementation note that BigInteger constructors and
operations throw an ArithmeticException when the result is out of the
supported range.
The supported range in JDK 8 is -2^Integer.MAX_VALUE to
2^Integer.MAX_VALUE, exclusive. This range is symmetric to make patch
simpler.

All constructors contains call checkRange() guarded by cheap test
"mag.length >= MAX_MAG_LENGTH". The checkRange() method throws an
ArithmeticException if the BigInteger instance would be out of the
supported range. APIdocs of public constructors and methods contain an
appropriate @throws ArithmeticException clause .

The patch contains a fix of various other problems related to overflow:
1) Calculation of prime searchLen suffered from int overflow when bitLength
was large;
2) int overflow in pow() method;
3) Overflow of intermediate results in modPow() method;
4) Removed the implementation restriction on Integer.MIN_VALUE
  in shiftLeft() and shiftRight() methods introduced during the fix of:
JDK-6371401 : java.math.BigInteger.shift(Integer.MIN_VALUE) throws
StackOverflowError
https://bugs.openjdk.java.net/browse/JDK-6371401

Please, review this patch.



On Wed, Jul 3, 2013 at 6:06 AM, Joseph Darcy  wrote:

> Hello,
>
> A quick note on this issue, before the recent work to use better
> algorithms for BigInteger arithmetic operation, working with huge numbers
> was impractical and thus BigInteger.bitLength misbehavior was mostly an
> academic concern. With the better algorithms, exposure to these large
> values is likely to increase so BigInteger.bitLength should do something
> reasonable.
>
> There are at least two implementation limits of note in the current code:
>
> * Total bit length given a single backing array
> * Max size of serializable BigInteger given old byte-array based format.
>
> My preference for addressing this issue includes adding an implementation
> note along the lines of "in JDK 8, BigInteger operates on values in the
> range ...." without requiring that range to be part of the specification.
>
> Cheers,
>
> -Joe
>
>
> On 6/25/2013 6:18 PM, Brian Burkhalter wrote:
>
>> This request for comment regards this issue
>>
>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6910473
>> BigInteger.bigLength() may return negative value for large numbers
>>
>> but more importantly Dmitry's thread
>>
>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-**
>> June/018345.html
>> What is the range of BigInteger values?
>>
>> The issue may be fixed superficially simply by throwing an
>> ArithmeticException if the bit length as an int would be negative. A better
>> fix suggested both in the issue description and in the aforementioned
>> thread (option 1 of 3), is to define BigInteger to support a limited range
>> and to clamp to that range in the constructor, throwing an
>> ArithmeticException if the supplied parameter(s) would cause the BigInteger
>> to overflow. This check would be relatively inexpensive. The suggested
>> constraint range is
>> [ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) )
>> This constraint would guarantee that all BigInteger instances are capable
>> of accurately returning their properties such as bit length, bit count, etc.
>>
>> This naturally would require a minor specification change to BigInteger.
>> The question is whether this change would limit any future developments of
>> this and related classes. For example, one could envision BigInteger
>> supporting bit lengths representable by a long instead of an int. In this
>> case the second option would be preferable.
>>
>> It has been suggested that an alternative to extending the ranges
>> supported by BigInteger would be to define a different class altogether to
>> handle the larger ranges, keeping BigInteger as a well-specified API for
>> the ranges it supports. Other related classes for arbitrary precision
>> binary floating point and rational numbers might also be considered.
>>
>> In summary the specific questions being posed here are:
>>
>> 1) what is the general opinion on clamping the range of BigInteger and
>> the various options suggested at the end of
>>
>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-**
>> June/018345.html?
>>
>> 2) what are the forward looking thoughts on handling integers outside the
>> current BigInteger range?
>>
>>  From a practical point of view, any changes need to be considered with
>> respect to what may be done in the short term (JDK 8) versus the long (JDK
>> 9), so to speak.
>>
>> Thanks,
>>
>> Brian
>>
>
>


From kasperni at gmail.com  Sat Sep 21 07:03:57 2013
From: kasperni at gmail.com (Kasper Nielsen)
Date: Sat, 21 Sep 2013 09:03:57 +0200
Subject: SplittableRandom update
In-Reply-To: <523CD6BA.20704@cs.oswego.edu>
References: <523C57A6.2000508@cs.oswego.edu>
	
	<60518C87-9FB9-4B07-A074-E925691AF1F3@oracle.com>
	<523CD6BA.20704@cs.oswego.edu>
Message-ID: 

Hi,

As I wrote to Paul.
Only OpenJDK Authors and above can create/edit/comment on bugs.

Might be nice to at least allow people to comment/vote/setup notification
on bugs.

- Kasper


On Sat, Sep 21, 2013 at 1:14 AM, Doug Lea 
 wrote:

> On 09/20/2013 11:36 AM, Paul Sandoz wrote:
>
>> Hi Kasper,
>>
>> Can you please log a bug [1] (and also note that ThreadLocal/Random does
>> the same) ?
>>
>> My preference would be to get this code in and fix the error reporting
>> separately.
>>
>>
> Even though a minor nuisance, I agree; it would be a simple
> practice bug for us (especially me!) to get used to the
> newly-externally-accessible bug system.
>
> -Doug
>
>


From Alan.Bateman at oracle.com  Sat Sep 21 12:42:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 21 Sep 2013 05:42:27 -0700
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <523C76B8.1060205@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com> <52355E90.7090501@oracle.com>
	<523594CA.4070104@oracle.com> <52360F39.9080103@oracle.com>
	<523857A9.2070902@oracle.com> <523C76B8.1060205@oracle.com>
Message-ID: <523D9433.8050006@oracle.com>

On 20/09/2013 09:24, Ivan Gerasimov wrote:
> Hi Alan!
>
> I yet modified the test, so now it can be run both from jprt and as a 
> standalone test.
> I also added a comment for QA with the instruction on how to test the 
> fix manually.
>
> Would you please review the hopefully final webrev?
> http://cr.openjdk.java.net/~igerasim/8023130/4/webrev/ 
> 
Okay, let's go with this.

(Minor comment is that InheritIO.java has a 2003 date in the header so I 
assume this was copied from another file).

-Alan.


From paul.sandoz at oracle.com  Sat Sep 21 13:46:45 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sat, 21 Sep 2013 06:46:45 -0700
Subject: SplittableRandom update
In-Reply-To: 
References: <523C57A6.2000508@cs.oswego.edu>
	
	<60518C87-9FB9-4B07-A074-E925691AF1F3@oracle.com>
	<523CD6BA.20704@cs.oswego.edu>
	
Message-ID: 

On Sep 21, 2013, at 12:03 AM, Kasper Nielsen  wrote:
> Hi,
> 
> As I wrote to Paul.
> Only OpenJDK Authors and above can create/edit/comment on bugs.
> 

Sorry, did not realize that. I mistakenly thought a contributor (OCA signer) could create issues via bugs.openjdk.java.net.


> Might be nice to at least allow people to comment/vote/setup notification
> on bugs.
> 

I don't know what future plans entail but perhaps we should place a link on the main page to:

  http://bugreport.sun.com/bugreport/

for those what wish to just submit a report?

Paul.

> - Kasper
> 
> 
> On Sat, Sep 21, 2013 at 1:14 AM, Doug Lea 
 wrote:
> 
>> On 09/20/2013 11:36 AM, Paul Sandoz wrote:
>> 
>>> Hi Kasper,
>>> 
>>> Can you please log a bug [1] (and also note that ThreadLocal/Random does
>>> the same) ?
>>> 
>>> My preference would be to get this code in and fix the error reporting
>>> separately.
>>> 
>>> 
>> Even though a minor nuisance, I agree; it would be a simple
>> practice bug for us (especially me!) to get used to the
>> newly-externally-accessible bug system.
>> 
>> -Doug
>> 
>> 


From joel.franck at oracle.com  Sat Sep 21 14:26:47 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Sat, 21 Sep 2013 16:26:47 +0200
Subject: RFR: 8009719: core reflection should get type annotation data from
	the VM lazily
Message-ID: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>

Hi

A while ago [1] I introduced an extra field in to j.l.r.Method,
j.l.r.Constructor, and j.l.r.Field in order to support reflection for
type annotations. These fields were intended to be removed later, they
were there to make the coordination between VM and libraries easier when
implementing reflection for type annotations.

This change removes the fields. Reflection for type annotations simply
get the bytes from the vm lazily when it needs them. Because reflection
for type annotations is suspected to be fairly uncommon and not
performance critical no caching is done. This can be changed later.

The vm side of things were pushed a while back [2], this is the JDK side
of the changes.

This is a refactoring, all current annotation and type annotation tests
pass after this change.

Webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.01/
Bug id: https://bugs.openjdk.java.net/browse/JDK-8009719

Also including build-dev since I needed to update the mapfiles. To my
knowledge I have updated both the old and the new build.

Please review

cheers
/Joel

[1] : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d977f61af5e
[2] : http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1916ca1dec2f


From mwisnicki at gmail.com  Sat Sep 21 15:27:09 2013
From: mwisnicki at gmail.com (=?UTF-8?Q?Marcin_Wi=C5=9Bnicki?=)
Date: Sat, 21 Sep 2013 17:27:09 +0200
Subject: Expose elementType of EnumSet and EnumMap
Message-ID: 

Third party serialization libraries and other tools need to know the
type of EnumSet elementType. Currently this field is package-private
and said libraries have to resort to non-portable reflection hacks.

Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.

I've submitted this request to bugs.sun.com last month, where it
received Bug Id: 9006352. There was no further communication and that
bug is still not visible which doesn't surprise me as I've never had
any luck with bugs.sun.com even when submitting actual bug :(

PS. Please keep me CC'ed.


From rieberandreas at gmail.com  Sat Sep 21 16:06:04 2013
From: rieberandreas at gmail.com (Andreas Rieber)
Date: Sat, 21 Sep 2013 18:06:04 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: 
References: 
Message-ID: <523DC3EC.2080301@gmail.com>

Hi Marcin,

your issue is here: https://bugs.openjdk.java.net/browse/JDK-8024037

try the new JDK bug system ;-)

Andreas

On 21.09.2013 17:27, Marcin Wi?nicki wrote:
> Third party serialization libraries and other tools need to know the
> type of EnumSet elementType. Currently this field is package-private
> and said libraries have to resort to non-portable reflection hacks.
>
> Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.
>
> I've submitted this request to bugs.sun.com last month, where it
> received Bug Id: 9006352. There was no further communication and that
> bug is still not visible which doesn't surprise me as I've never had
> any luck with bugs.sun.com even when submitting actual bug :(
>
> PS. Please keep me CC'ed.



From ivan.gerasimov at oracle.com  Sat Sep 21 16:17:55 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 21 Sep 2013 20:17:55 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <523D9433.8050006@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
	
	<52315858.3050006@oracle.com> <5231DC0E.4080106@oracle.com>
	<5234B1D8.5000800@oracle.com> <52355E90.7090501@oracle.com>
	<523594CA.4070104@oracle.com> <52360F39.9080103@oracle.com>
	<523857A9.2070902@oracle.com> <523C76B8.1060205@oracle.com>
	<523D9433.8050006@oracle.com>
Message-ID: <523DC6B3.3030405@oracle.com>


On 21.09.2013 16:42, Alan Bateman wrote:
> On 20/09/2013 09:24, Ivan Gerasimov wrote:
>> Hi Alan!
>>
>> I yet modified the test, so now it can be run both from jprt and as a 
>> standalone test.
>> I also added a comment for QA with the instruction on how to test the 
>> fix manually.
>>
>> Would you please review the hopefully final webrev?
>> http://cr.openjdk.java.net/~igerasim/8023130/4/webrev/ 
>> 
> Okay, let's go with this.
>
> (Minor comment is that InheritIO.java has a 2003 date in the header so 
> I assume this was copied from another file).
>
Yes, thanks!

> -Alan.
>
>



From mwisnicki at gmail.com  Sat Sep 21 18:16:39 2013
From: mwisnicki at gmail.com (=?UTF-8?Q?Marcin_Wi=C5=9Bnicki?=)
Date: Sat, 21 Sep 2013 20:16:39 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: <523DC3EC.2080301@gmail.com>
References: 
	<523DC3EC.2080301@gmail.com>
Message-ID: 

Nice, are submissions converted automatically ? Still it's basically
useless for outsiders - there is no public registration and without it
I can't create new issues, add comment or even watch existing issues.

On Sat, Sep 21, 2013 at 6:06 PM, Andreas Rieber  wrote:
> Hi Marcin,
>
> your issue is here: https://bugs.openjdk.java.net/browse/JDK-8024037
>
> try the new JDK bug system ;-)
>
> Andreas
>
>
> On 21.09.2013 17:27, Marcin Wi?nicki wrote:
>>
>> Third party serialization libraries and other tools need to know the
>> type of EnumSet elementType. Currently this field is package-private
>> and said libraries have to resort to non-portable reflection hacks.
>>
>> Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.
>>
>> I've submitted this request to bugs.sun.com last month, where it
>> received Bug Id: 9006352. There was no further communication and that
>> bug is still not visible which doesn't surprise me as I've never had
>> any luck with bugs.sun.com even when submitting actual bug :(
>>
>> PS. Please keep me CC'ed.
>
>


From forax at univ-mlv.fr  Sat Sep 21 18:15:44 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 21 Sep 2013 20:15:44 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: 
References: 
Message-ID: <523DE250.10002@univ-mlv.fr>

On 09/21/2013 05:27 PM, Marcin Wi?nicki wrote:
> Third party serialization libraries and other tools need to know the
> type of EnumSet elementType. Currently this field is package-private
> and said libraries have to resort to non-portable reflection hacks.
>
> Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.
>
> I've submitted this request to bugs.sun.com last month, where it
> received Bug Id: 9006352. There was no further communication and that
> bug is still not visible which doesn't surprise me as I've never had
> any luck with bugs.sun.com even when submitting actual bug :(
>
> PS. Please keep me CC'ed.

Hi Marcin,
I've read the bug file but failed to find a description of a compelling 
use case for these methods.

Adding these two methods goes against an important rule:
try to avoid for sub-types of Collection, methods that are 
implementation specific, the history has proven multiple times that 
implementations of collections change a lot. This is a general rule, 
that we may want to ignore but it has to worth it.

Also, I think it worth to understand what's elementType represent. 
elementType is not the class of the values contained in the set but the 
declaring class (Enum.getDeclaringClass) of the enum values. So despite 
being a Class, elementType is a type information that only exists has a 
field because generics are not reified. This has two consequences, the 
first one is that if you want to create an EnumSet, you need a way to 
have an elementType and the second one is that it may make the work of 
the people that want to reify generics in a future version of Java harder.

and don't think I'm the dragon that keep the treasure, this is just my 
humble opinion and I try to do my best to explain why adding these 
methods is not obvious.

regards,
R?mi




From roger.riggs at oracle.com  Sat Sep 21 18:31:17 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Sat, 21 Sep 2013 14:31:17 -0400
Subject: Please Review integration of Java Time updates
Message-ID: <523DE5F5.40806@oracle.com>

Hi,

A number of issues including some API changes have been addressed in the
Threeten Project and are to be integrated into jdk8-tl.
The changes are from Stephen Colebourne and myself, an OpenJDK reviewer 
is needed.

The webrev author comments include the Jira issues covered.

Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-period-until-8023762-807-834-835/

I expect folks are busy with JavaOne but did not want this to sit in my 
queue longer
since the deadlines for API freeze and Zero Bug bounce occur soon after j1.

Thanks, Roger

p.s.  From the Webrev:

8023762: Add ChronoPeriod interface and bind period to Chronology
Summary: Make Period ISO-only, adding a Chronology-specific period concept
Contributed-by: scolebourne at joda.org

8023763: Rename ChronoDateImpl
Summary: Rename ChronoDateImpl to ChronoLocalDateImpl
Contributed-by: scolebourne at joda.org

8023764: Optimize Period addition
Summary: Optimise plus/minus for common cases
Contributed-by: scolebourne at joda.org

8024835: Change until() to accept any compatible temporal
Summary: Method until(Temporal,TemporalUnit) now uses from() to convert; Enhance from() methods where necessary
Contributed-by: scolebourne at joda.org

8024807: Add getChronlogy() to CLDT/CZDT
Summary: Alternative to method is clunky and hard to find
Contributed-by: scolebourne at joda.org

8024834: Better return type for TemporalField resolve
Summary: Allow resolve method to return more than just ChronoLocalDate
Contributed-by: scolebourne at joda.org

8024999: Instant.Parse typo in example
Summary: javadoc only fix to correct example to use "." and "Z"




From mwisnicki at gmail.com  Sat Sep 21 18:43:50 2013
From: mwisnicki at gmail.com (=?UTF-8?Q?Marcin_Wi=C5=9Bnicki?=)
Date: Sat, 21 Sep 2013 20:43:50 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: <523DE250.10002@univ-mlv.fr>
References: 
	<523DE250.10002@univ-mlv.fr>
Message-ID: 

First of all EnumSet/EnumMap are not general purpose collections, they
are already implementation specific.

Also, since you can't subclass enum, class of contained values will be
the same as declaring class.
>From EnumSet documentation: "All of the elements in an enum set must
come from a single enum type".

I don't see how exposing getElementType() can hinder reification. I'm
going to say that it doesn't. Please provide counterexample if you
think I'm mistaken.

Here are your use cases:
1. Remove ugly hacks from serialization libraries that were known to
cause problems with different JVM implementations in the past (for
example see this code from jackson: http://goo.gl/yudBps)
2. A Visual editor of some sort may display EnumSet as a list of
checkboxes if it knows what type of enum values can be contained
within this set.

On Sat, Sep 21, 2013 at 8:15 PM, Remi Forax  wrote:
> On 09/21/2013 05:27 PM, Marcin Wi?nicki wrote:
>>
>> Third party serialization libraries and other tools need to know the
>> type of EnumSet elementType. Currently this field is package-private
>> and said libraries have to resort to non-portable reflection hacks.
>>
>> Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.
>>
>> I've submitted this request to bugs.sun.com last month, where it
>> received Bug Id: 9006352. There was no further communication and that
>> bug is still not visible which doesn't surprise me as I've never had
>> any luck with bugs.sun.com even when submitting actual bug :(
>>
>> PS. Please keep me CC'ed.
>
>
> Hi Marcin,
> I've read the bug file but failed to find a description of a compelling use
> case for these methods.
>
> Adding these two methods goes against an important rule:
> try to avoid for sub-types of Collection, methods that are implementation
> specific, the history has proven multiple times that implementations of
> collections change a lot. This is a general rule, that we may want to ignore
> but it has to worth it.
>
> Also, I think it worth to understand what's elementType represent.
> elementType is not the class of the values contained in the set but the
> declaring class (Enum.getDeclaringClass) of the enum values. So despite
> being a Class, elementType is a type information that only exists has a
> field because generics are not reified. This has two consequences, the first
> one is that if you want to create an EnumSet, you need a way to have an
> elementType and the second one is that it may make the work of the people
> that want to reify generics in a future version of Java harder.
>
> and don't think I'm the dragon that keep the treasure, this is just my
> humble opinion and I try to do my best to explain why adding these methods
> is not obvious.
>
> regards,
> R?mi
>
>


From roger.riggs at oracle.com  Sat Sep 21 19:15:42 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Sat, 21 Sep 2013 15:15:42 -0400
Subject: Please Review fix for reduced value parser 8024076
Message-ID: <523DF05E.5020009@oracle.com>

Hi,

The java.time reduced value parser does work as expected (issue 8024076)
for chronologies other than ISO.
The base value is assumed to be chronology independent but is not
converted to the requested Chronology before it is used.

Please review:

     http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/

Thanks, Roger

[1] https://bugs.openjdk.java.net/browse/JDK-8024076



From forax at univ-mlv.fr  Sat Sep 21 20:21:57 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 21 Sep 2013 22:21:57 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: 
References: 
	<523DE250.10002@univ-mlv.fr>
	
Message-ID: <523DFFE5.5000909@univ-mlv.fr>

On 09/21/2013 08:43 PM, Marcin Wi?nicki wrote:
> First of all EnumSet/EnumMap are not general purpose collections, they
> are already implementation specific.
>
> Also, since you can't subclass enum, class of contained values will be
> the same as declaring class.
>  From EnumSet documentation: "All of the elements in an enum set must
> come from a single enum type".

No, you can add methods to one value of an enum using the anonymous 
class syntax.

>
> I don't see how exposing getElementType() can hinder reification. I'm
> going to say that it doesn't. Please provide counterexample if you
> think I'm mistaken.

elementType and the reified type are the same information.
by the way, elementType and the class of the array (universe) are also 
the same information.

>
> Here are your use cases:
> 1. Remove ugly hacks from serialization libraries that were known to
> cause problems with different JVM implementations in the past (for
> example see this code from jackson: http://goo.gl/yudBps)

I've taken a look to the code, it can be changed to avoid to use 
getElementType(),
the parameterized type is not propagated when deserializing.
see the comment here:
https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/ClassNameIdResolver.java#L49

> 2. A Visual editor of some sort may display EnumSet as a list of
> checkboxes if it knows what type of enum values can be contained
> within this set.

again the declared type can be propagated.

R?mi

>
> On Sat, Sep 21, 2013 at 8:15 PM, Remi Forax  wrote:
>> On 09/21/2013 05:27 PM, Marcin Wi?nicki wrote:
>>> Third party serialization libraries and other tools need to know the
>>> type of EnumSet elementType. Currently this field is package-private
>>> and said libraries have to resort to non-portable reflection hacks.
>>>
>>> Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.
>>>
>>> I've submitted this request to bugs.sun.com last month, where it
>>> received Bug Id: 9006352. There was no further communication and that
>>> bug is still not visible which doesn't surprise me as I've never had
>>> any luck with bugs.sun.com even when submitting actual bug :(
>>>
>>> PS. Please keep me CC'ed.
>>
>> Hi Marcin,
>> I've read the bug file but failed to find a description of a compelling use
>> case for these methods.
>>
>> Adding these two methods goes against an important rule:
>> try to avoid for sub-types of Collection, methods that are implementation
>> specific, the history has proven multiple times that implementations of
>> collections change a lot. This is a general rule, that we may want to ignore
>> but it has to worth it.
>>
>> Also, I think it worth to understand what's elementType represent.
>> elementType is not the class of the values contained in the set but the
>> declaring class (Enum.getDeclaringClass) of the enum values. So despite
>> being a Class, elementType is a type information that only exists has a
>> field because generics are not reified. This has two consequences, the first
>> one is that if you want to create an EnumSet, you need a way to have an
>> elementType and the second one is that it may make the work of the people
>> that want to reify generics in a future version of Java harder.
>>
>> and don't think I'm the dragon that keep the treasure, this is just my
>> humble opinion and I try to do my best to explain why adding these methods
>> is not obvious.
>>
>> regards,
>> R?mi
>>
>>



From joe.darcy at oracle.com  Sat Sep 21 20:30:06 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 21 Sep 2013 13:30:06 -0700
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: 
References: 
	<523DE250.10002@univ-mlv.fr>
	
Message-ID: <523E01CE.6090906@oracle.com>

On 9/21/2013 11:43 AM, Marcin Wi?nicki wrote:
> First of all EnumSet/EnumMap are not general purpose collections, they
> are already implementation specific.
>
> Also, since you can't subclass enum, class of contained values will be
> the same as declaring class.

No, not necessarily.

Specialized enum constants can be implemented by having anonymous 
subclasses of the enum type.

The following two enums declarations are semantically equivalent:

// 1st
public enum MetaSyntVar {
     FOO(21),
     BAR(42);
     private int answer;
         MetaSyntVar(int answer) {
         this.answer = answer;
     }
     public int answer() {
     return answer;}
}

// 2nd
public enum MetaSyntVar {
     FOO {
         public int answer() {
             return 21;}},
     BAR {
         public int answer() {
             return 42;}};
     public abstract int answer();
}

The former compiles down to one class file; the latter compiles down to 
three.

-Joe

> >From EnumSet documentation: "All of the elements in an enum set must
> come from a single enum type".
>
> I don't see how exposing getElementType() can hinder reification. I'm
> going to say that it doesn't. Please provide counterexample if you
> think I'm mistaken.
>
> Here are your use cases:
> 1. Remove ugly hacks from serialization libraries that were known to
> cause problems with different JVM implementations in the past (for
> example see this code from jackson: http://goo.gl/yudBps)
> 2. A Visual editor of some sort may display EnumSet as a list of
> checkboxes if it knows what type of enum values can be contained
> within this set.
>
> On Sat, Sep 21, 2013 at 8:15 PM, Remi Forax  wrote:
>> On 09/21/2013 05:27 PM, Marcin Wi?nicki wrote:
>>> Third party serialization libraries and other tools need to know the
>>> type of EnumSet elementType. Currently this field is package-private
>>> and said libraries have to resort to non-portable reflection hacks.
>>>
>>> Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.
>>>
>>> I've submitted this request to bugs.sun.com last month, where it
>>> received Bug Id: 9006352. There was no further communication and that
>>> bug is still not visible which doesn't surprise me as I've never had
>>> any luck with bugs.sun.com even when submitting actual bug :(
>>>
>>> PS. Please keep me CC'ed.
>>
>> Hi Marcin,
>> I've read the bug file but failed to find a description of a compelling use
>> case for these methods.
>>
>> Adding these two methods goes against an important rule:
>> try to avoid for sub-types of Collection, methods that are implementation
>> specific, the history has proven multiple times that implementations of
>> collections change a lot. This is a general rule, that we may want to ignore
>> but it has to worth it.
>>
>> Also, I think it worth to understand what's elementType represent.
>> elementType is not the class of the values contained in the set but the
>> declaring class (Enum.getDeclaringClass) of the enum values. So despite
>> being a Class, elementType is a type information that only exists has a
>> field because generics are not reified. This has two consequences, the first
>> one is that if you want to create an EnumSet, you need a way to have an
>> elementType and the second one is that it may make the work of the people
>> that want to reify generics in a future version of Java harder.
>>
>> and don't think I'm the dragon that keep the treasure, this is just my
>> humble opinion and I try to do my best to explain why adding these methods
>> is not obvious.
>>
>> regards,
>> R?mi
>>
>>



From mwisnicki at gmail.com  Sat Sep 21 21:32:45 2013
From: mwisnicki at gmail.com (=?UTF-8?Q?Marcin_Wi=C5=9Bnicki?=)
Date: Sat, 21 Sep 2013 23:32:45 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: <523DFFE5.5000909@univ-mlv.fr>
References: 
	<523DE250.10002@univ-mlv.fr>
	
	<523DFFE5.5000909@univ-mlv.fr>
Message-ID: 

On Sat, Sep 21, 2013 at 10:21 PM, Remi Forax  wrote:
> No, you can add methods to one value of an enum using the anonymous class
> syntax.
>
>

Thanks for pointing this out. This is something that can be clarified
in javadoc.
Though javadocs of existing factory methods of EnumSet are not so
pedantic about "elementType" argument.

> elementType and the reified type are the same information.
> by the way, elementType and the class of the array (universe) are also the
> same information.
>
>

I fail to see a problem here. In fact this is a good case why such
method is necessary - if generics get reified in Java 9 and designers
of EnumSet decide to remove redundant elementType field, all software
depending on existence of this field will break. If on the other hand
there was a getElementType() method in Java 8, it could be safely
changed to obtain element type through whatever new mechanism is
available and existing software using getElementType() keeps working
correctly.

> I've taken a look to the code, it can be changed to avoid to use
> getElementType(),
> the parameterized type is not propagated when deserializing.
> see the comment here:
> https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/ClassNameIdResolver.java#L49
>
>

That was just an example, there is more code like that out there,
including my own and it's not always easy to restructure it in a way
that would allow propagating declared type.

>> 2. A Visual editor of some sort may display EnumSet as a list of
>> checkboxes if it knows what type of enum values can be contained
>> within this set.
>
>
> again the declared type can be propagated.
>


From mwisnicki at gmail.com  Sat Sep 21 21:45:23 2013
From: mwisnicki at gmail.com (=?UTF-8?Q?Marcin_Wi=C5=9Bnicki?=)
Date: Sat, 21 Sep 2013 23:45:23 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: 
References: 
	<523DE250.10002@univ-mlv.fr>
	
	<523DFFE5.5000909@univ-mlv.fr>
	
Message-ID: 

On Sat, Sep 21, 2013 at 11:32 PM, Marcin Wi?nicki  wrote:
> On Sat, Sep 21, 2013 at 10:21 PM, Remi Forax  wrote:
>> No, you can add methods to one value of an enum using the anonymous class
>> syntax.
>>
>>
>
> Thanks for pointing this out. This is something that can be clarified
> in javadoc.
> Though javadocs of existing factory methods of EnumSet are not so
> pedantic about "elementType" argument.

Alternatively the method can be called getElementDeclaringClass().


From scolebourne at joda.org  Sat Sep 21 23:15:08 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 22 Sep 2013 00:15:08 +0100
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: 
References: 
Message-ID: 

FWIW, I'm surprised that these methods don't exist. I've not hit the
problem myself but I know I'd curse if I discovered their absence.

Stephen
 On 21 Sep 2013 08:35, "Marcin Wi?nicki"  wrote:

> Third party serialization libraries and other tools need to know the
> type of EnumSet elementType. Currently this field is package-private
> and said libraries have to resort to non-portable reflection hacks.
>
> Please add EnumSet#getElementType() and EnumMap#getKeyType() methods.
>
> I've submitted this request to bugs.sun.com last month, where it
> received Bug Id: 9006352. There was no further communication and that
> bug is still not visible which doesn't surprise me as I've never had
> any luck with bugs.sun.com even when submitting actual bug :(
>
> PS. Please keep me CC'ed.
>


From rob.lougher at gmail.com  Sun Sep 22 00:58:35 2013
From: rob.lougher at gmail.com (Robert Lougher)
Date: Sun, 22 Sep 2013 01:58:35 +0100
Subject: RFR: 8009719: core reflection should get type annotation data
	from the VM lazily
In-Reply-To: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
References: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
Message-ID: 

Hi,

Not a reviewer, but in Field.c the parameter to
getTypeAnnotationBytes0 is a field not a method.

Rob.

On 21 September 2013 15:26, Joel Borggren-Franck  wrote:
> Hi
>
> A while ago [1] I introduced an extra field in to j.l.r.Method,
> j.l.r.Constructor, and j.l.r.Field in order to support reflection for
> type annotations. These fields were intended to be removed later, they
> were there to make the coordination between VM and libraries easier when
> implementing reflection for type annotations.
>
> This change removes the fields. Reflection for type annotations simply
> get the bytes from the vm lazily when it needs them. Because reflection
> for type annotations is suspected to be fairly uncommon and not
> performance critical no caching is done. This can be changed later.
>
> The vm side of things were pushed a while back [2], this is the JDK side
> of the changes.
>
> This is a refactoring, all current annotation and type annotation tests
> pass after this change.
>
> Webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.01/
> Bug id: https://bugs.openjdk.java.net/browse/JDK-8009719
>
> Also including build-dev since I needed to update the mapfiles. To my
> knowledge I have updated both the old and the new build.
>
> Please review
>
> cheers
> /Joel
>
> [1] : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d977f61af5e
> [2] : http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1916ca1dec2f


From forax at univ-mlv.fr  Sun Sep 22 09:17:27 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 22 Sep 2013 11:17:27 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: 
References: 
	<523DE250.10002@univ-mlv.fr>
	
	<523DFFE5.5000909@univ-mlv.fr>
	
Message-ID: <523EB5A7.5050509@univ-mlv.fr>

On 09/21/2013 11:32 PM, Marcin Wi?nicki wrote:
> On Sat, Sep 21, 2013 at 10:21 PM, Remi Forax  wrote:
>> No, you can add methods to one value of an enum using the anonymous class
>> syntax.
>>
>>
> Thanks for pointing this out. This is something that can be clarified
> in javadoc.
> Though javadocs of existing factory methods of EnumSet are not so
> pedantic about "elementType" argument.
>
>> elementType and the reified type are the same information.
>> by the way, elementType and the class of the array (universe) are also the
>> same information.
>>
>>
> I fail to see a problem here. In fact this is a good case why such
> method is necessary - if generics get reified in Java 9 and designers
> of EnumSet decide to remove redundant elementType field, all software
> depending on existence of this field will break. If on the other hand
> there was a getElementType() method in Java 8, it could be safely
> changed to obtain element type through whatever new mechanism is
> available and existing software using getElementType() keeps working
> correctly.

There is a lot of code that cast to T or to EnumSet that will start 
to fail at runtime if generics are reified. One possible way to avoid 
that is to create a new collection API, another is to try to reuse 
existing implementations with an opt-in mecanism. In the later case, the 
same class will be seen refiied
or not depending on how the collection is created, so enabling 
reification will be done incrementally in that case.
getElementType is a way to export a refied type, it will add burden to 
mixed mode implementation.

>
>> I've taken a look to the code, it can be changed to avoid to use
>> getElementType(),
>> the parameterized type is not propagated when deserializing.
>> see the comment here:
>> https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/ClassNameIdResolver.java#L49
>>
>>
> That was just an example, there is more code like that out there,
> including my own and it's not always easy to restructure it in a way
> that would allow propagating declared type.

You have to propagate declared types otherwise your code is not typesafe.
If you don't propagate type that you can de-serialize a List of String 
without checking that the elements inside the List are String.

R?mi



From scolebourne at joda.org  Sun Sep 22 12:40:26 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 22 Sep 2013 13:40:26 +0100
Subject: Point lambdaification of List/Set/Map
In-Reply-To: 
References: 
	
	<90FA03DA-CBE4-4EAD-9842-EB7C3D5CA48C@oracle.com>
	
Message-ID: 

I coded the methods I was thinking of on the plane  to SFO:
https://gist.github.com/jodastephen/6659515

If there is still interest for JDK8 perhaps a group could work on
tidying this up at the codegarten.

Stephen



On 12 July 2013 00:49, Stephen Colebourne  wrote:
> On 12 July 2013 00:04, Mike Duigou  wrote:
>>>> Implementation would ideally be via new dedicated immutable classes,
>>>> however space could be saved by simply reusing the existing classes.
>>
>> I would prefer to use existing Collections implementations. Primarily because they have already been thoroughly used. Any reason to use new dedicated classes?
>
> Google Guava is the model here. It has dedicated immutable classes
> that are more efficient because they don't have the overhead of an
> immutable wrapper.
>
> If it has to be existing classes, then so be it, but the
> implementation may suffer as a result.
>
> I don't believe it can be changed later, as users may see the
> implementation class as significant, perhaps via a serialization ID.
> If it is considered acceptable to change the implementation class in a
> later release, then I would be happy to accept reusing the existing
> classes to get this into 8. Is it possible to get an opinion on a
> later implementation class change?
>
>>>> Is this something we could fit in? (Is resourcing the problem, or the idea?)
>>
>> Patches are *always* welcome and are usually more grease to make things happen than just a squeaky wheel. :-) Without a patch I wouldn't be willing to commit that this RFE would make it into Java 8.
>
> I may be able to find time to do this. Or I may not. Other list
> readers might want to chime in here and volunteer.
>
> I certainly think it would be a popular addition.
>
> Stephen


From cowwoc at bbs.darktech.org  Sun Sep 22 13:17:28 2013
From: cowwoc at bbs.darktech.org (Gili)
Date: Sun, 22 Sep 2013 09:17:28 -0400
Subject: Reified Generics (was Re: Expose elementType of EnumSet and EnumMap)
In-Reply-To: <523EB5A7.5050509@univ-mlv.fr>
References: 
	<523DE250.10002@univ-mlv.fr>
	
	<523DFFE5.5000909@univ-mlv.fr>
	
	<523EB5A7.5050509@univ-mlv.fr>
Message-ID: <523EEDE8.9030109@bbs.darktech.org>

On 9/22/2013 5:17 AM, Remi Forax wrote:
>> I fail to see a problem here. In fact this is a good case why such
>> method is necessary - if generics get reified in Java 9 and designers
>> of EnumSet decide to remove redundant elementType field, all software
>> depending on existence of this field will break. If on the other hand
>> there was a getElementType() method in Java 8, it could be safely
>> changed to obtain element type through whatever new mechanism is
>> available and existing software using getElementType() keeps working
>> correctly.
>
> There is a lot of code that cast to T or to EnumSet that will start 
> to fail at runtime if generics are reified. One possible way to avoid 
> that is to create a new collection API, another is to try to reuse 
> existing implementations with an opt-in mecanism. In the later case, 
> the same class will be seen refiied
> or not depending on how the collection is created, so enabling 
> reification will be done incrementally in that case.
> getElementType is a way to export a refied type, it will add burden to 
> mixed mode implementation.

     Are Reified Generics officially part of JDK9? (I hope so!) Is there 
an official announcement/link to that respect?

Thanks,
Gili


From mwisnicki at gmail.com  Sun Sep 22 14:05:08 2013
From: mwisnicki at gmail.com (=?UTF-8?Q?Marcin_Wi=C5=9Bnicki?=)
Date: Sun, 22 Sep 2013 16:05:08 +0200
Subject: Expose elementType of EnumSet and EnumMap
In-Reply-To: <523EB5A7.5050509@univ-mlv.fr>
References: 
	<523DE250.10002@univ-mlv.fr>
	
	<523DFFE5.5000909@univ-mlv.fr>
	
	<523EB5A7.5050509@univ-mlv.fr>
Message-ID: 

On Sun, Sep 22, 2013 at 11:17 AM, Remi Forax  wrote:
>
> There is a lot of code that cast to T or to EnumSet that will start to fail at runtime if generics are reified.


Yes, but how is that relevant ? Most of the code using reflection or
unchecked casts will likely fail if existing generics get reified
which is why IMHO it won't be added, at least not to existing classes.

>
> One possible way to avoid that is to create a new collection API, another is to try to reuse existing implementations with an opt-in mecanism. In the later case, the same class will be seen refiied
> or not depending on how the collection is created, so enabling reification will be done incrementally in that case.
> getElementType is a way to export a refied type, it will add burden to mixed mode implementation.


Whether EnumSet is reified or not, it does not change the fact that
it is and must be associated with a class that declares enum values.
There can be only one such class in any case.

> You have to propagate declared types otherwise your code is not typesafe.
> If you don't propagate type that you can de-serialize a List of String without checking that the elements inside the List are String.


Indeed, such code is not safe, but almost all serialization APIs let
you read/write an object without specifying its type. That includes
java serialization, which is only safe in case of EnumSet due to
specific handling inside that class.


From scolebourne at joda.org  Sun Sep 22 14:27:47 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 22 Sep 2013 15:27:47 +0100
Subject: Please Review fix for reduced value parser 8024076
In-Reply-To: <523DF05E.5020009@oracle.com>
References: <523DF05E.5020009@oracle.com>
Message-ID: 

The patch only changes the text of one of the two appendValueReduced
methods. The patch does not handle week based years or provide for
users to add their own year fields. It also does not handle
formatting.

After much thinking, I think the right solution is to add a new
appendValueReduced method where "int baseValue" is replaced by
"ChronoLocalDate baseDate". The new method would be used if you want
year-like fields in multiple chronologies to work. The appendPattern
method would be changed to use the new date variant for y/u/W

The first of the two existing appendValueReduced methods can be
removed as a simplification.

Patch here:
https://gist.github.com/jodastephen/6660394

Note that this patch still has a bug, as the effective chrono is not
determined fully until the end of the parsing phase. However, that bug
fix requires a bit of an internal redesign and since it does not
affect the API it can be delayed,

Stephen




On 21 September 2013 20:15, roger riggs  wrote:
> Hi,
>
> The java.time reduced value parser does work as expected (issue 8024076)
> for chronologies other than ISO.
> The base value is assumed to be chronology independent but is not
> converted to the requested Chronology before it is used.
>
> Please review:
>
>     http://cr.openjdk.java.net/~rriggs/webrev-two-digit-8024076/
>
> Thanks, Roger
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8024076
>


From brian.goetz at oracle.com  Sun Sep 22 14:33:00 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 22 Sep 2013 07:33:00 -0700
Subject: Point lambdaification of List/Set/Map
In-Reply-To: 
References: 
	
	<90FA03DA-CBE4-4EAD-9842-EB7C3D5CA48C@oracle.com>
	
	
Message-ID: 

To put it in aviation lingo: the cabin door has been closed and we've pulled away from the jetbridge.  

On Sep 22, 2013, at 5:40 AM, Stephen Colebourne wrote:

> I coded the methods I was thinking of on the plane  to SFO:
> https://gist.github.com/jodastephen/6659515
> 
> If there is still interest for JDK8 perhaps a group could work on
> tidying this up at the codegarten.
> 
> Stephen
> 
> 
> 
> On 12 July 2013 00:49, Stephen Colebourne  wrote:
>> On 12 July 2013 00:04, Mike Duigou  wrote:
>>>>> Implementation would ideally be via new dedicated immutable classes,
>>>>> however space could be saved by simply reusing the existing classes.
>>> 
>>> I would prefer to use existing Collections implementations. Primarily because they have already been thoroughly used. Any reason to use new dedicated classes?
>> 
>> Google Guava is the model here. It has dedicated immutable classes
>> that are more efficient because they don't have the overhead of an
>> immutable wrapper.
>> 
>> If it has to be existing classes, then so be it, but the
>> implementation may suffer as a result.
>> 
>> I don't believe it can be changed later, as users may see the
>> implementation class as significant, perhaps via a serialization ID.
>> If it is considered acceptable to change the implementation class in a
>> later release, then I would be happy to accept reusing the existing
>> classes to get this into 8. Is it possible to get an opinion on a
>> later implementation class change?
>> 
>>>>> Is this something we could fit in? (Is resourcing the problem, or the idea?)
>>> 
>>> Patches are *always* welcome and are usually more grease to make things happen than just a squeaky wheel. :-) Without a patch I wouldn't be willing to commit that this RFE would make it into Java 8.
>> 
>> I may be able to find time to do this. Or I may not. Other list
>> readers might want to chime in here and volunteer.
>> 
>> I certainly think it would be a popular addition.
>> 
>> Stephen



From vicente.romero at oracle.com  Sun Sep 22 11:56:34 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sun, 22 Sep 2013 11:56:34 +0000
Subject: hg: jdk8/tl/langtools: 8024696: Missing null check in bound method
	reference capture
Message-ID: <20130922115638.18B8162A1E@hg.openjdk.java.net>

Changeset: 571f8ebc2d51
Author:    vromero
Date:      2013-09-22 12:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/571f8ebc2d51

8024696: Missing null check in bound method reference capture
Reviewed-by: jjg, briangoetz

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! test/tools/javac/lambda/8023558/T8023558a.java
+ test/tools/javac/lambda/methodReferenceExecution/MethodReferenceNullCheckTest.java



From Alan.Bateman at oracle.com  Sun Sep 22 16:31:00 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 22 Sep 2013 09:31:00 -0700
Subject: RFR 8024408: Specifications for
	Collection/List/Set/SortedSet.spliterator()
	need to document if all the (subclass) instances are required to return
	SIZED spliterators
In-Reply-To: 
References: 
Message-ID: <523F1B44.80609@oracle.com>

On 15/09/2013 09:20, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8024408-split-col-size/webrev/
>
> It is necessary to relax the constraints when SIZED should be reported for a Spliterator of a Collection or Set.
>
> The spliterator of a Collection/Set can report SIZED, or CONCURRENT, or neither (and never both). The latter case can occur with the strange beast known as WeakHashMap, which is not CONCURRENT in the commonly understood sense, but it's traversal is weakly consistent and the size is only an estimate.
>
> Note that no change was made to List, which basically means no List implementation can be concurrent. This interface is not well suited for concurrent implementations given the determinism expected for indexed access  e.g. l.get(l.size() - 1) could barf for a concurrent or weak list if something is concurrently removed.
>
> A CCC is required.
>
> Paul.
I looked through one and it looks okay to me.

-Alan


From alan.bateman at oracle.com  Mon Sep 23 03:08:55 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 23 Sep 2013 03:08:55 +0000
Subject: hg: jdk8/tl/jdk: 8023130: (process) ProcessBuilder#inheritIO does not
	work on Windows
Message-ID: <20130923030925.25AF462A31@hg.openjdk.java.net>

Changeset: 56d247821694
Author:    alanb
Date:      2013-09-23 04:05 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d247821694

8023130: (process) ProcessBuilder#inheritIO does not work on Windows
Reviewed-by: alanb, martin
Contributed-by: ivan.gerasimov at oracle.com

! src/windows/native/java/lang/ProcessImpl_md.c
! test/java/lang/ProcessBuilder/Basic.java
+ test/java/lang/ProcessBuilder/InheritIO/InheritIO.java
+ test/java/lang/ProcessBuilder/InheritIO/InheritIO.sh



From lana.steuck at oracle.com  Mon Sep 23 03:22:28 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 23 Sep 2013 03:22:28 +0000
Subject: hg: jdk8/tl: 13 new changesets
Message-ID: <20130923032231.3535862A32@hg.openjdk.java.net>

Changeset: 0874bb4707b7
Author:    omajid
Date:      2013-09-11 12:08 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/0874bb4707b7

8024320: Add s390(x) detection to platform.m4
Reviewed-by: erikj, ihse, dsamersoff

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4

Changeset: 14fe208b657c
Author:    cl
Date:      2013-09-12 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/14fe208b657c

Added tag jdk8-b107 for changeset 0874bb4707b7

! .hgtags

Changeset: 4bf059350c51
Author:    lana
Date:      2013-09-17 08:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/4bf059350c51

Merge


Changeset: 8dadd26c2a58
Author:    ihse
Date:      2013-09-12 10:38 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/8dadd26c2a58

8024467: Update autoconf-config.guess to autoconf 2.69
Reviewed-by: erikj

! common/autoconf/build-aux/autoconf-config.guess

Changeset: 64f52ef175a4
Author:    ihse
Date:      2013-09-12 10:42 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/64f52ef175a4

8010185: Build should support --with-override-nashorn
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4

Changeset: b1e9396fb8af
Author:    vadim
Date:      2013-09-12 12:12 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/b1e9396fb8af

8008022: Upgrade Direct X SDK used to build JDK
Reviewed-by: erikj, prr, ihse

! Makefile
! README-builds.html
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! common/autoconf/toolchain_windows.m4

Changeset: 69da99676239
Author:    ihse
Date:      2013-09-13 13:07 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/69da99676239

8024620: config.log does not end up in corresponding configuration
Reviewed-by: erikj

! common/autoconf/configure
! common/autoconf/configure.ac
! common/autoconf/generated-configure.sh

Changeset: ac3f5137f84d
Author:    ihse
Date:      2013-09-13 14:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/ac3f5137f84d

8024665: Move open changes for JDK-8020411 to closed source
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in

Changeset: aab351790498
Author:    katleman
Date:      2013-09-17 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/aab351790498

Merge


Changeset: 59d6af7422af
Author:    katleman
Date:      2013-09-17 19:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/59d6af7422af

Merge


Changeset: 7697621037fd
Author:    ihse
Date:      2013-09-18 12:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/7697621037fd

8024815: Make --with-dxsdk and friends deprecated
Reviewed-by: erikj

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: 9286a6e61291
Author:    ihse
Date:      2013-09-18 13:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/9286a6e61291

8024849: Don't remove upper case letters from username when setting USER_RELEASE_SUFFIX
Reviewed-by: erikj

! common/autoconf/basics_windows.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4

Changeset: d4762f463fe0
Author:    cl
Date:      2013-09-19 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/d4762f463fe0

Added tag jdk8-b108 for changeset 9286a6e61291

! .hgtags



From lana.steuck at oracle.com  Mon Sep 23 03:22:24 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 23 Sep 2013 03:22:24 +0000
Subject: hg: jdk8/tl/corba: 3 new changesets
Message-ID: <20130923032233.85B5262A33@hg.openjdk.java.net>

Changeset: 260f00a95705
Author:    cl
Date:      2013-09-12 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/260f00a95705

Added tag jdk8-b107 for changeset 23fc34133152

! .hgtags

Changeset: a4bb3b450016
Author:    lana
Date:      2013-09-17 08:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/a4bb3b450016

Merge


Changeset: c1eb93f57603
Author:    cl
Date:      2013-09-19 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/c1eb93f57603

Added tag jdk8-b108 for changeset a4bb3b450016

! .hgtags



From lana.steuck at oracle.com  Mon Sep 23 03:22:33 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 23 Sep 2013 03:22:33 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20130923032321.E2FEA62A34@hg.openjdk.java.net>

Changeset: d1ea68556fd7
Author:    cl
Date:      2013-09-12 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d1ea68556fd7

Added tag jdk8-b107 for changeset e3c9328f7563

! .hgtags

Changeset: f64b1e497722
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f64b1e497722

Added tag jdk8-b108 for changeset d1ea68556fd7

! .hgtags



From lana.steuck at oracle.com  Mon Sep 23 03:22:35 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 23 Sep 2013 03:22:35 +0000
Subject: hg: jdk8/tl/jaxp: 2 new changesets
Message-ID: <20130923032322.9C1AC62A35@hg.openjdk.java.net>

Changeset: 8ade3eed63da
Author:    cl
Date:      2013-09-12 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/8ade3eed63da

Added tag jdk8-b107 for changeset d6a32e3831aa

! .hgtags

Changeset: 21b10835b88a
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/21b10835b88a

Added tag jdk8-b108 for changeset 8ade3eed63da

! .hgtags



From lana.steuck at oracle.com  Mon Sep 23 03:23:07 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 23 Sep 2013 03:23:07 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20130923032341.1668D62A36@hg.openjdk.java.net>

Changeset: a1f980cc1355
Author:    cl
Date:      2013-09-12 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a1f980cc1355

Added tag jdk8-b107 for changeset f35e1255024b

! .hgtags

Changeset: 445ad3f6d3b4
Author:    lana
Date:      2013-09-17 08:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/445ad3f6d3b4

Merge

- src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java

Changeset: 6ec2f9e5ed5b
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6ec2f9e5ed5b

Added tag jdk8-b108 for changeset 445ad3f6d3b4

! .hgtags

Changeset: 13210550765c
Author:    lana
Date:      2013-09-20 19:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/13210550765c

Merge




From lana.steuck at oracle.com  Mon Sep 23 03:23:14 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 23 Sep 2013 03:23:14 +0000
Subject: hg: jdk8/tl/langtools: 5 new changesets
Message-ID: <20130923032416.155C962A37@hg.openjdk.java.net>

Changeset: 1b7f5a27c4ba
Author:    cl
Date:      2013-09-12 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1b7f5a27c4ba

Added tag jdk8-b107 for changeset 3f274927ec18

! .hgtags

Changeset: 252f872b8a2f
Author:    lana
Date:      2013-09-17 08:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/252f872b8a2f

Merge

- src/share/classes/com/sun/tools/javac/code/Annotations.java
- test/tools/javac/diags/examples/CyclicInference.java
- test/tools/javac/diags/examples/MrefStat.java.rej
- test/tools/javac/diags/examples/MrefStat1.java.rej
- test/tools/javac/lambda/TargetType10.out
- test/tools/javac/lambda/typeInference/InferenceTest5.java
- test/tools/javac/lambda/typeInference/InferenceTest_neg5.java
- test/tools/javac/lambda/typeInference/InferenceTest_neg5.out

Changeset: 8ecfe6a3ba4c
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8ecfe6a3ba4c

Added tag jdk8-b108 for changeset 252f872b8a2f

! .hgtags

Changeset: 86dd72166267
Author:    lana
Date:      2013-09-20 19:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/86dd72166267

Merge


Changeset: 20b72bae83d7
Author:    lana
Date:      2013-09-22 20:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/20b72bae83d7

Merge




From lana.steuck at oracle.com  Mon Sep 23 03:24:02 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 23 Sep 2013 03:24:02 +0000
Subject: hg: jdk8/tl/hotspot: 69 new changesets
Message-ID: <20130923032734.CF61262A38@hg.openjdk.java.net>

Changeset: c169f7038414
Author:    amurillo
Date:      2013-08-30 00:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c169f7038414

8024022: new hotspot build - hs25-b49
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 4a1efab850f4
Author:    shade
Date:      2013-08-26 17:42 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a1efab850f4

8023638: Add the regression test for 8006997
Summary: Add the relevant test and proofread the VM messages as well
Reviewed-by: coleenp, mseledtsov, dcubed

! src/share/vm/runtime/arguments.cpp
+ test/runtime/contended/Options.java

Changeset: a7d8baf4cca7
Author:    dcubed
Date:      2013-08-26 18:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7d8baf4cca7

Merge


Changeset: 91b93f523ec6
Author:    acorn
Date:      2013-08-26 11:35 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91b93f523ec6

8012294: remove generic handling for default methods
Reviewed-by: kamg, coleenp

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/defaultMethods.cpp
- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/runtime/globals.hpp

Changeset: d80493ee6430
Author:    acorn
Date:      2013-08-27 01:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d80493ee6430

Merge

- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 6b3ac96bada6
Author:    jiangli
Date:      2013-08-26 13:32 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b3ac96bada6

8023477: Invalid CP index when reading ConstantPool.
Summary: Need to check for 0 case for InstanceKlass::_generic_signature_index.
Reviewed-by: sspitsyn, sla

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java

Changeset: b3596321fbf4
Author:    jiangli
Date:      2013-08-27 04:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b3596321fbf4

Merge


Changeset: 7e7dd25666da
Author:    ccheung
Date:      2013-08-26 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e7dd25666da

8020675: invalid jar file in the bootclasspath could lead to jvm fatal error
Summary: removed offending EXCEPTION_MARK calls and code cleanup
Reviewed-by: dholmes, iklam, coleenp, mseledtsov

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp
+ test/runtime/LoadClass/LoadClassNegative.java
+ test/runtime/LoadClass/TestForName.java
+ test/runtime/LoadClass/dummy.jar

Changeset: 5351fe805c12
Author:    minqi
Date:      2013-08-27 07:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5351fe805c12

Merge


Changeset: f462e61bce87
Author:    iklam
Date:      2013-08-26 21:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f462e61bce87

8020622: create.bat on Windows failed to create project file for Visual Studio 2012
Summary: Treat VS2012 the same as VS2010.
Reviewed-by: dcubed, kamg, minqi

! make/windows/create.bat
! make/windows/makefiles/rules.make

Changeset: 35471dcba316
Author:    iklam
Date:      2013-08-27 03:35 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35471dcba316

Merge


Changeset: c26d57fa08aa
Author:    iklam
Date:      2013-08-27 16:02 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c26d57fa08aa

Merge


Changeset: 915cc4f3fb15
Author:    acorn
Date:      2013-08-28 08:15 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/915cc4f3fb15

8020489: VM crash when non-existent interface called by invokespecial
Reviewed-by: kamg, coleenp

! src/share/vm/classfile/defaultMethods.cpp

Changeset: cc56f122f3f7
Author:    sla
Date:      2013-08-29 11:05 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc56f122f3f7

8023720: (hotspot) setjmp/longjmp changes the process signal mask on OS X
Reviewed-by: dholmes, rbackman

! src/os/posix/vm/os_posix.cpp

Changeset: 76482cbba706
Author:    hseigel
Date:      2013-08-29 10:33 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/76482cbba706

8016764: JVM does not prohibit invokespecial in c.f.v 51.0 that invokes default interface method in c.f.v 52.0
Summary: Check cfv before allowing invokespecial call to default method.
Reviewed-by: kamg, acorn, dholmes

! src/share/vm/classfile/verifier.cpp

Changeset: dfc126b2f659
Author:    hseigel
Date:      2013-08-29 13:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dfc126b2f659

8022407: sun/misc/CopyMemory.java fails with SIGSEGV in Unsafe_SetByte+0x35
Summary: lower optimization level for unsafe.cpp due to MacOS Xcode 4.6.2 compiler optimization issue.
Reviewed-by: coleenp, twisti, dholmes
Contributed-by: lois.foltan at oracle.com

! make/bsd/makefiles/gcc.make

Changeset: d8e99408faad
Author:    dsamersoff
Date:      2013-08-29 21:48 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8e99408faad

8009062: poor performance of JNI AttachCurrentThread after fix for 7017193
Summary: don't re-evaluate stack bounds for main thread before install guard page
Reviewed-by: coleenp, dholmes, dlong

! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
+ test/runtime/InitialThreadOverflow/DoOverflow.java
+ test/runtime/InitialThreadOverflow/invoke.cxx
+ test/runtime/InitialThreadOverflow/testme.sh

Changeset: cef1e56a4d88
Author:    dsamersoff
Date:      2013-08-29 21:46 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cef1e56a4d88

Merge


Changeset: 9758d9f36299
Author:    coleenp
Date:      2013-08-29 18:56 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9758d9f36299

8021954: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced
Summary: declare all user-defined operator new()s within Hotspot code with the empty throw() exception specification
Reviewed-by: coleenp, twisti, dholmes, hseigel, dcubed, kvn, ccheung
Contributed-by: lois.foltan at oracle.com

! src/share/vm/adlc/arena.cpp
! src/share/vm/adlc/arena.hpp
! src/share/vm/adlc/main.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/relocInfo.hpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/gc_implementation/shared/gcUtil.hpp
! src/share/vm/libadt/port.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/memRegion.cpp
! src/share/vm/memory/memRegion.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/machnode.hpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/objectMonitor.hpp
! src/share/vm/runtime/park.cpp
! src/share/vm/runtime/park.hpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memTrackWorker.cpp
! src/share/vm/services/memTrackWorker.hpp
! src/share/vm/utilities/array.hpp

Changeset: c636758ea616
Author:    dcubed
Date:      2013-08-30 07:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c636758ea616

Merge

! src/os/posix/vm/os_posix.cpp
- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp

Changeset: 522d69638aa8
Author:    zgu
Date:      2013-08-30 11:54 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/522d69638aa8

6991327: using -Xprof trigger native memory leak
Summary: Fixed a memory leak in FlatProfiler::record_thread_tick() method
Reviewed-by: dholmes, ccheung

! src/share/vm/runtime/fprofiler.cpp

Changeset: 491de79915eb
Author:    zgu
Date:      2013-08-30 12:22 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/491de79915eb

Merge

! src/share/vm/runtime/fprofiler.cpp

Changeset: ac2764460da7
Author:    zgu
Date:      2013-08-30 13:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac2764460da7

Merge


Changeset: ca0501b58953
Author:    hseigel
Date:      2013-08-30 15:07 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca0501b58953

8024050: Incorrect optimization level and comment specified for unsafe.cpp
Summary: Fix comments and optimization level.
Reviewed-by: rdurbin, coleenp, hseigel
Contributed-by: lois.foltan at oracle.com

! make/bsd/makefiles/gcc.make

Changeset: d8ff06fb87ae
Author:    hseigel
Date:      2013-08-30 15:15 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8ff06fb87ae

Merge


Changeset: abff50660360
Author:    hseigel
Date:      2013-08-30 15:57 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abff50660360

Merge


Changeset: 3a1df0dce3e5
Author:    acorn
Date:      2013-08-30 15:15 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a1df0dce3e5

8023872: Verification error in generated lambda classes
Summary: skip verification for generated lambda classes
Reviewed-by: kamg, dholmes

! src/share/vm/classfile/verifier.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 735f94656acc
Author:    acorn
Date:      2013-08-30 12:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/735f94656acc

Merge


Changeset: 2918c7e21a3a
Author:    acorn
Date:      2013-08-30 15:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2918c7e21a3a

Merge


Changeset: 35b99e7e0af2
Author:    hseigel
Date:      2013-09-01 10:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35b99e7e0af2

8023381: VM fails to initialize in runtime/CDSCompressedKPtrs/XShareAuto.java runtime/SharedArchiveFile/CdsSameObjectAlignment.java
Summary: Improve handling when CDS archive cannot be mapped
Reviewed-by: kvn, dholmes, mseledtsov

! src/share/vm/memory/filemap.cpp
! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java
! test/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java

Changeset: 766fac3395d6
Author:    kvn
Date:      2013-08-23 11:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/766fac3395d6

8012972: Incremental Inlining should support scalar replaced object in debug info
Summary: store in _first_index not absolute index but an index relative to the last (youngest) jvms->_scloff value
Reviewed-by: roland, twisti

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp

Changeset: b17d8f6d9ed7
Author:    kvn
Date:      2013-08-23 18:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b17d8f6d9ed7

8023472: C2 optimization breaks with G1
Summary: set control edge for previous value load in G1 pre-barrier
Reviewed-by: twisti

! src/share/vm/opto/graphKit.cpp
+ test/compiler/gcbarriers/G1CrashTest.java

Changeset: f98f5d48f511
Author:    roland
Date:      2013-08-21 13:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f98f5d48f511

7199175: JSR 292: C1 needs patching when invokedynamic/invokehandle call site is not linked
Summary: Do patching rather bailing out for unlinked call with appendix
Reviewed-by: twisti, kvn

! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/c1/c1_globals.cpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciObjectFactory.hpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: e1fbb86b47e4
Author:    roland
Date:      2013-08-26 16:12 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e1fbb86b47e4

8016277: Crash in nmethod::is_compiled_by_c1() on x86
Summary: Method pointer for zombie methods may be invalid
Reviewed-by: kvn, coleenp

! src/share/vm/code/nmethod.cpp

Changeset: e47de6dfec5d
Author:    vlivanov
Date:      2013-08-26 17:37 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e47de6dfec5d

8022456: LogCompilation tool does not work with C1 output again
Reviewed-by: kvn

! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java
! src/share/vm/c1/c1_Compilation.cpp

Changeset: 74608df95ba3
Author:    vlivanov
Date:      2013-08-26 17:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/74608df95ba3

8022595: JSR292: deadlock during class loading of MethodHandles, MethodHandleImpl & MethodHandleNatives
Reviewed-by: kvn, coleenp, dholmes

! src/share/vm/runtime/thread.cpp
+ test/compiler/jsr292/ConcurrentClassLoadingTest.java

Changeset: 022415fe638e
Author:    vlivanov
Date:      2013-08-26 21:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/022415fe638e

Merge


Changeset: 59982ff9e0ec
Author:    rbackman
Date:      2013-08-20 09:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59982ff9e0ec

8022283: Assertion failed: assert(is_loaded() && field->holder()->is_loaded() && klass()->is_subclass_of (field->holder())) failed: invalid access
Reviewed-by: roland, twisti

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciInstance.cpp

Changeset: 58e010ab2d06
Author:    rbackman
Date:      2013-08-27 19:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58e010ab2d06

Merge


Changeset: 650868c062a9
Author:    adlertz
Date:      2013-08-26 12:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/650868c062a9

8023691: Create interface for nodes in class Block
Summary: Create public methods for accessing the nodes in a block
Reviewed-by: kvn, roland

! src/share/vm/adlc/output_c.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp

Changeset: 7181dd13a6c4
Author:    adlertz
Date:      2013-08-27 21:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7181dd13a6c4

Merge


Changeset: 29aa8936f03c
Author:    kvn
Date:      2013-08-28 11:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/29aa8936f03c

8023597: Optimize G1 barriers code for unsafe load_store
Summary: Avoid loading old values in G1 pre-barriers for inlined unsafe load_store nodes.
Reviewed-by: kvn, tonyp
Contributed-by: Martin Doerr 

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp

Changeset: 8947af8a9cec
Author:    vlivanov
Date:      2013-08-29 22:44 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8947af8a9cec

8023976: assert(!CompilationPolicy::can_be_compiled(this, comp_level)) failed: sanity check
Reviewed-by: kvn, twisti

! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp

Changeset: 4b078f877b56
Author:    adlertz
Date:      2013-09-01 19:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b078f877b56

8023988: Move local scheduling of nodes to the CFG creation and code motion phase (PhaseCFG)
Summary: Moved local scheduling code from class Block to class PhaseCFG
Reviewed-by: kvn, roland

! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/lcm.cpp

Changeset: 40ed2dc92a79
Author:    adlertz
Date:      2013-09-01 19:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40ed2dc92a79

Merge


Changeset: 27ffd1c4537b
Author:    rbackman
Date:      2013-09-02 13:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/27ffd1c4537b

Merge

! src/share/vm/runtime/thread.cpp

Changeset: a9a968364704
Author:    adlertz
Date:      2013-09-02 22:44 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9a968364704

8024095: Missing brackets in local scheduling code.
Summary: Added brackets for if-statement
Reviewed-by: kvn, roland

! src/share/vm/opto/lcm.cpp

Changeset: 3bfb204913de
Author:    adlertz
Date:      2013-09-05 10:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3bfb204913de

Merge

! src/share/vm/code/nmethod.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/node.hpp

Changeset: 88c255656030
Author:    mgerdin
Date:      2013-08-22 10:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/88c255656030

8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld
Summary: When using NUMA and large pages we need to ease the requirement on which node the memory should be allocated on. To avoid the SIGBUS we now use the memory policy MPOL_PREFERRED, which prefers a certain node, instead of MPOL_BIND, which requires a certain node.
Reviewed-by: jmasa, pliden
Contributed-by: stefan.johansson at oracle.com

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp

Changeset: 0d59407e7e09
Author:    jmasa
Date:      2013-08-29 06:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0d59407e7e09

Merge

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp

Changeset: 84683e78e713
Author:    brutisso
Date:      2013-08-30 07:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/84683e78e713

8019902: G1: Use the average heap size rather than the minimum heap size to calculate the region size
Reviewed-by: tonyp, tschatzl, sjohanss

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp

Changeset: f175e3678be2
Author:    ehelin
Date:      2013-08-22 11:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f175e3678be2

8020692: TestGCEventMixed.java failed because of timestamp in event after end event
Reviewed-by: mgerdin, stefank

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/shared/gcTraceSend.cpp

Changeset: a701c16e8bbf
Author:    jmasa
Date:      2013-09-04 11:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a701c16e8bbf

8013938: Native OOME on fastdebug VM on Solaris
Reviewed-by: azeemj, brutisso, kvn, tschatzl

! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp

Changeset: 428025878417
Author:    jmasa
Date:      2013-09-04 12:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/428025878417

Merge


Changeset: bb57d48691f5
Author:    tschatzl
Date:      2013-09-05 14:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bb57d48691f5

Merge

! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp

Changeset: 50794d8ac11c
Author:    amurillo
Date:      2013-09-06 11:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/50794d8ac11c

Merge

- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp

Changeset: 5b7f90aab3ad
Author:    amurillo
Date:      2013-09-06 11:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b7f90aab3ad

Added tag hs25-b49 for changeset 50794d8ac11c

! .hgtags

Changeset: 9cd0183fe325
Author:    cl
Date:      2013-09-12 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9cd0183fe325

Added tag jdk8-b107 for changeset 5b7f90aab3ad

! .hgtags

Changeset: 313b724f8911
Author:    amurillo
Date:      2013-09-06 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/313b724f8911

8024258: new hotspot build - hs25-b50
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ceda33ff54a3
Author:    iignatyev
Date:      2013-09-05 16:38 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ceda33ff54a3

8012447: Java CTW implementation
Reviewed-by: vlivanov, kvn, twisti

! test/gc/TestVerifyDuringStartup.java
! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java
+ test/testlibrary/ctw/Makefile
+ test/testlibrary/ctw/README
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java
+ test/testlibrary/ctw/test/Bar.java
+ test/testlibrary/ctw/test/ClassesDirTest.java
+ test/testlibrary/ctw/test/ClassesListTest.java
+ test/testlibrary/ctw/test/CtwTest.java
+ test/testlibrary/ctw/test/Foo.java
+ test/testlibrary/ctw/test/JarDirTest.java
+ test/testlibrary/ctw/test/JarsTest.java
+ test/testlibrary/ctw/test/classes.lst
+ test/testlibrary/whitebox/Makefile

Changeset: cd16d587b0fa
Author:    adlertz
Date:      2013-09-09 19:53 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd16d587b0fa

Merge


Changeset: 72a567cce06f
Author:    anoll
Date:      2013-09-10 07:51 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72a567cce06f

8024473: Remove unused macro: IRT_ENTRY_FOR_NMETHOD
Summary: Removed unused macro
Reviewed-by: kvn, adlertz

! src/share/vm/runtime/interfaceSupport.hpp

Changeset: edb5ab0f3fe5
Author:    vlivanov
Date:      2013-09-10 14:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/edb5ab0f3fe5

8001107: @Stable annotation for constant folding of lazily evaluated variables
Reviewed-by: rbackman, twisti, kvn
Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com

! src/share/vm/ci/ciArray.cpp
! src/share/vm/ci/ciArray.hpp
! src/share/vm/ci/ciConstant.hpp
! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciField.hpp
! src/share/vm/ci/ciFlags.hpp
! src/share/vm/ci/ciInstance.cpp
! src/share/vm/ci/ciTypeArray.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/fieldInfo.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/accessFlags.hpp

Changeset: e0d33d2ce5aa
Author:    vlivanov
Date:      2013-09-10 15:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0d33d2ce5aa

Merge


Changeset: 34bd5e86aadb
Author:    adlertz
Date:      2013-09-11 09:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34bd5e86aadb

8010941: MinJumpTableSize is set to 18, investigate if that's still optimal
Summary: Lowered the MinJumpTableSize for each platform
Reviewed-by: kvn

! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp
! src/share/vm/opto/c2_globals.hpp

Changeset: 0821b5d72ca8
Author:    adlertz
Date:      2013-09-12 09:10 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0821b5d72ca8

Merge


Changeset: a09fe9d1e016
Author:    amurillo
Date:      2013-09-13 00:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a09fe9d1e016

Merge


Changeset: 85072013aad4
Author:    amurillo
Date:      2013-09-13 00:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85072013aad4

Added tag hs25-b50 for changeset a09fe9d1e016

! .hgtags

Changeset: 34aa07e92d22
Author:    cl
Date:      2013-09-19 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34aa07e92d22

Added tag jdk8-b108 for changeset 85072013aad4

! .hgtags



From lana.steuck at oracle.com  Mon Sep 23 03:25:02 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 23 Sep 2013 03:25:02 +0000
Subject: hg: jdk8/tl/jdk: 21 new changesets
Message-ID: <20130923033058.3588C62A39@hg.openjdk.java.net>

Changeset: eea685b9ccaa
Author:    amurillo
Date:      2013-09-10 05:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eea685b9ccaa

8024515: ProblemList.txt updates to exclude tests that fail with hs25-b49
Reviewed-by: alanb, chegar

! test/ProblemList.txt

Changeset: b67c8099ba28
Author:    cl
Date:      2013-09-12 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b67c8099ba28

Added tag jdk8-b107 for changeset eea685b9ccaa

! .hgtags

Changeset: 12ac08d79c9b
Author:    vadim
Date:      2013-08-23 14:13 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12ac08d79c9b

8023052: JVM crash in native layout
Reviewed-by: bae, prr

! src/share/native/sun/font/layout/SunLayoutEngine.cpp

Changeset: b5c5cff52455
Author:    lana
Date:      2013-08-28 08:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b5c5cff52455

Merge


Changeset: 7da90f645a63
Author:    jgodinez
Date:      2013-08-30 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da90f645a63

8017469: [macosx] Printing problem using ja and zh_CN locales
Reviewed-by: prr, jchen

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: dc09174469ef
Author:    prr
Date:      2013-08-30 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc09174469ef

4673406: RFE: Java Printing: Provide a way to display win32 printer driver's dialog
Reviewed-by: jgodinez, bae

+ src/share/classes/sun/print/DocumentPropertiesUI.java
+ src/share/classes/sun/print/PrinterJobWrapper.java
! src/share/classes/sun/print/RasterPrinterJob.java
! src/share/classes/sun/print/ServiceDialog.java
! src/windows/classes/sun/awt/windows/WPrinterJob.java
! src/windows/classes/sun/print/Win32MediaTray.java
! src/windows/classes/sun/print/Win32PrintService.java
! src/windows/native/sun/windows/awt_PrintControl.cpp
! src/windows/native/sun/windows/awt_PrintControl.h
! src/windows/native/sun/windows/awt_PrintJob.cpp

Changeset: 2114b624bf63
Author:    ceisserer
Date:      2013-09-01 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2114b624bf63

7189452: XRender pipeline does ignore source-surface offset for text rendering
Reviewed-by: prr, bae

! src/solaris/classes/sun/font/XRTextRenderer.java
! src/solaris/classes/sun/java2d/xr/XRBackendNative.java
! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java
! src/solaris/native/sun/java2d/x11/XRBackendNative.c

Changeset: a07c907a82b5
Author:    bae
Date:      2013-09-04 12:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a07c907a82b5

7043064: sun/java2d/cmm/ tests failed against RI b141 & b138-nightly
Reviewed-by: prr, vadim

! make/sun/cmm/lcms/mapfile-vers
! makefiles/mapfiles/liblcms/mapfile-vers
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/awt/color/ICC_ProfileGray.java
! src/share/classes/java/awt/color/ICC_ProfileRGB.java
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/PCMM.java
+ src/share/classes/sun/java2d/cmm/Profile.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
+ src/share/classes/sun/java2d/cmm/lcms/LCMSProfile.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
! src/share/native/sun/java2d/cmm/lcms/LCMS.c
! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java

Changeset: c561115d697d
Author:    ceisserer
Date:      2013-09-04 12:38 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c561115d697d

7159455: Nimbus scrollbar rendering glitch with xrender enabled on i945GM
Reviewed-by: prr, bae

! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java

Changeset: 0a317fc785fb
Author:    ceisserer
Date:      2013-09-05 11:50 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a317fc785fb

8024261: xrender: improve performance of small fillRect operations
Reviewed-by: prr, bae

! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java

Changeset: 2d223e1a9706
Author:    lana
Date:      2013-09-06 18:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d223e1a9706

Merge

- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java

Changeset: 08296c2d4c68
Author:    bae
Date:      2013-09-10 21:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08296c2d4c68

8024511: Crash during color profile destruction
Reviewed-by: vadim, prr

! src/share/native/sun/java2d/cmm/lcms/LCMS.c
+ test/sun/java2d/cmm/ProfileOp/DisposalCrashTest.java

Changeset: 1579407c0a82
Author:    bae
Date:      2013-09-13 20:28 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1579407c0a82

8024697: Fix for 8020983 causes Xcheck:jni warnings
Reviewed-by: prr, jchen

! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
! test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java

Changeset: da6cd0247b27
Author:    lana
Date:      2013-09-17 08:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da6cd0247b27

Merge


Changeset: ebc44e50df79
Author:    lana
Date:      2013-09-17 08:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ebc44e50df79

Merge

- src/share/classes/java/util/stream/CloseableStream.java
- src/share/classes/java/util/stream/DelegatingStream.java
! test/ProblemList.txt
- test/java/util/Collection/ListDefaults.java
- test/java/util/Map/CheckRandomHashSeed.java
- test/java/util/Map/TreeBinSplitBackToEntries.java
- test/java/util/concurrent/ConcurrentHashMap/toArray.java
- test/sun/tools/jconsole/ImmutableResourceTest.java
- test/sun/tools/jconsole/ImmutableResourceTest.sh

Changeset: 5063b43d7e09
Author:    vadim
Date:      2013-09-12 12:12 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5063b43d7e09

8008022: Upgrade Direct X SDK used to build JDK
Reviewed-by: erikj, prr, ihse

! make/Makefile
! make/common/Defs-windows.gmk
! make/common/Sanity.gmk
! make/common/shared/Defs-versions.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/javax/sound/jsoundds/Makefile
! make/jdk_generic_profile.sh
! make/netbeans/awt2d/README
! make/sun/awt/Makefile
! make/sun/jawt/Makefile
! makefiles/CompileNativeLibraries.gmk

Changeset: 5da2bb1419e6
Author:    katleman
Date:      2013-09-17 13:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5da2bb1419e6

Merge


Changeset: 006aaa5f069e
Author:    katleman
Date:      2013-09-17 19:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/006aaa5f069e

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: a7dd84b9557c
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7dd84b9557c

Added tag jdk8-b108 for changeset 006aaa5f069e

! .hgtags

Changeset: a3b17b91127d
Author:    lana
Date:      2013-09-20 19:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3b17b91127d

Merge


Changeset: f1b251affc6a
Author:    lana
Date:      2013-09-22 20:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1b251affc6a

Merge




From erik.joelsson at oracle.com  Mon Sep 23 07:59:36 2013
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 23 Sep 2013 09:59:36 +0200
Subject: RFR: 8009719: core reflection should get type annotation data
	from the VM lazily
In-Reply-To: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
References: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
Message-ID: <523FF4E8.4000304@oracle.com>

Build part of the changes are fine.

/Erik

On 2013-09-21 16:26, Joel Borggren-Franck wrote:
> Hi
>
> A while ago [1] I introduced an extra field in to j.l.r.Method,
> j.l.r.Constructor, and j.l.r.Field in order to support reflection for
> type annotations. These fields were intended to be removed later, they
> were there to make the coordination between VM and libraries easier when
> implementing reflection for type annotations.
>
> This change removes the fields. Reflection for type annotations simply
> get the bytes from the vm lazily when it needs them. Because reflection
> for type annotations is suspected to be fairly uncommon and not
> performance critical no caching is done. This can be changed later.
>
> The vm side of things were pushed a while back [2], this is the JDK side
> of the changes.
>
> This is a refactoring, all current annotation and type annotation tests
> pass after this change.
>
> Webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.01/
> Bug id: https://bugs.openjdk.java.net/browse/JDK-8009719
>
> Also including build-dev since I needed to update the mapfiles. To my
> knowledge I have updated both the old and the new build.
>
> Please review
>
> cheers
> /Joel
>
> [1] : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d977f61af5e
> [2] : http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1916ca1dec2f



From erik.joelsson at oracle.com  Mon Sep 23 08:02:58 2013
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 23 Sep 2013 10:02:58 +0200
Subject: RFR: 8009719: core reflection should get type annotation data
	from the VM lazily
In-Reply-To: <523FF4E8.4000304@oracle.com>
References: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
	<523FF4E8.4000304@oracle.com>
Message-ID: <523FF5B2.1070406@oracle.com>

Or wait, you added a c-file to libjava and want the old build to keep 
working, then you need to add that file to jdk/make/java/java/FILES_c.gmk.

/Erik

On 2013-09-23 09:59, Erik Joelsson wrote:
> Build part of the changes are fine.
>
> /Erik
>
> On 2013-09-21 16:26, Joel Borggren-Franck wrote:
>> Hi
>>
>> A while ago [1] I introduced an extra field in to j.l.r.Method,
>> j.l.r.Constructor, and j.l.r.Field in order to support reflection for
>> type annotations. These fields were intended to be removed later, they
>> were there to make the coordination between VM and libraries easier when
>> implementing reflection for type annotations.
>>
>> This change removes the fields. Reflection for type annotations simply
>> get the bytes from the vm lazily when it needs them. Because reflection
>> for type annotations is suspected to be fairly uncommon and not
>> performance critical no caching is done. This can be changed later.
>>
>> The vm side of things were pushed a while back [2], this is the JDK side
>> of the changes.
>>
>> This is a refactoring, all current annotation and type annotation tests
>> pass after this change.
>>
>> Webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.01/
>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8009719
>>
>> Also including build-dev since I needed to update the mapfiles. To my
>> knowledge I have updated both the old and the new build.
>>
>> Please review
>>
>> cheers
>> /Joel
>>
>> [1] : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d977f61af5e
>> [2] : http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1916ca1dec2f
>



From joel.franck at oracle.com  Mon Sep 23 08:08:33 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Mon, 23 Sep 2013 10:08:33 +0200
Subject: RFR: 8009719: core reflection should get type annotation data
	from the VM lazily
In-Reply-To: 
References: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
	
Message-ID: <20130923080833.GC15298@jfranck-desktop.jrpg.bea.com>

Hi,

On 2013-09-22, Robert Lougher wrote:
> Hi,
> 
> Not a reviewer, but in Field.c the parameter to
> getTypeAnnotationBytes0 is a field not a method.
> 

Thanks, will rename that parameter before pushing.

cheers
/Joel


From miroslav.kos at oracle.com  Mon Sep 23 09:19:37 2013
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Mon, 23 Sep 2013 11:19:37 +0200
Subject: Update JAX-WS RI integration to 2.2.9-b130918.1732
Message-ID: <524007A9.8040604@oracle.com>

Hi everybody,

There is another update syncing JAX-WS sources in jdk8/tl/jaxws to most 
recent development version.

As usually, it is quite big changeset (6k+ LOC changed) and includes 
several bug fixes, for details see the issue description:
https://bugs.openjdk.java.net/browse/JDK-8025054

Please, see weberevs here:
jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00
jdk/test: 
http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/


Thanks
Miran



From joel.franck at oracle.com  Mon Sep 23 08:57:46 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Mon, 23 Sep 2013 08:57:46 +0000
Subject: hg: jdk8/tl/langtools: 8024988: javac,
	LVT test harness should generate tests .class files in the scratch
	folder
Message-ID: <20130923085752.C7CD862A40@hg.openjdk.java.net>

Changeset: 1fe358ea75ff
Author:    alundblad
Date:      2013-09-23 10:10 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1fe358ea75ff

8024988: javac, LVT test harness should generate tests .class files in the scratch folder
Summary: Set the CLASS_OUTPUT location to the scratch directory. Changed the argument to checkClassFile accordingly.
Reviewed-by: jjg, vromero

! test/tools/javac/flow/LVTHarness.java



From sundararajan.athijegannathan at oracle.com  Mon Sep 23 10:04:54 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 23 Sep 2013 10:04:54 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20130923100500.C5EB862A43@hg.openjdk.java.net>

Changeset: 279f47b353f3
Author:    sundar
Date:      2013-09-20 20:55 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/279f47b353f3

8025147: Trailing comma is not allowed in JSONArray and JSONObject
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/parser/JSONParser.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
+ test/script/basic/JDK-8025147.js
+ test/script/basic/JDK-8025147.js.EXPECTED

Changeset: 16b6db9f7225
Author:    sundar
Date:      2013-09-20 22:37 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/16b6db9f7225

8025149: JSON.stringify does not handle 'space' argument as per the spec.
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/objects/NativeJSON.java
+ test/script/basic/JDK-8025149.js
+ test/script/basic/JDK-8025149.js.EXPECTED

Changeset: b8d9a63578e2
Author:    hannesw
Date:      2013-09-21 10:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b8d9a63578e2

8025163: Date methods should not return -0
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeDate.java
+ test/script/basic/JDK-8025163.js
+ test/script/basic/JDK-8025163.js.EXPECTED

Changeset: 8f6304373671
Author:    sundar
Date:      2013-09-23 14:20 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8f6304373671

Merge




From joel.franck at oracle.com  Mon Sep 23 11:10:31 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Mon, 23 Sep 2013 11:10:31 +0000
Subject: hg: jdk8/tl/langtools: 6386236: Please rename
	com.sun.tools.javac.util.ListBuffer.lb()
Message-ID: <20130923111034.523E562A47@hg.openjdk.java.net>

Changeset: 5f915a0c9615
Author:    alundblad
Date:      2013-09-23 10:42 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5f915a0c9615

6386236: Please rename com.sun.tools.javac.util.ListBuffer.lb()
Summary: Static factory method ListBuffer.lb removed. Replaced by constructor calls.
Reviewed-by: jfranck, jjg

! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/share/classes/com/sun/tools/javac/util/GraphUtils.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/ListBuffer.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java
! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java
! test/tools/javac/scope/7017664/CompoundScopeTest.java
! test/tools/javac/types/TypeHarness.java



From alexander.zuev at oracle.com  Mon Sep 23 13:27:58 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Mon, 23 Sep 2013 13:27:58 +0000
Subject: hg: jdk8/tl/langtools: 7154966: CRs found to be in Fixed state with
	no test and no noreg- keyword.
Message-ID: <20130923132801.1E3F062A57@hg.openjdk.java.net>

Changeset: 809a50f24d6f
Author:    kizune
Date:      2013-09-23 17:27 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/809a50f24d6f

7154966: CRs found to be in Fixed state with no test and no noreg- keyword.
Reviewed-by: ksrini

+ test/tools/javac/T7090499.java
+ test/tools/javac/T7090499.out
+ test/tools/javac/T7120463.java
+ test/tools/javac/T7120463.out
+ test/tools/javac/T7126754.java



From joel.franck at oracle.com  Mon Sep 23 14:00:18 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Mon, 23 Sep 2013 16:00:18 +0200
Subject: RFR: 8009719: core reflection should get type annotation data
	from the VM lazily
In-Reply-To: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
References: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
Message-ID: <20130923140018.GG15298@jfranck-desktop.jrpg.bea.com>

Hi all,

Updated webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.02/

Adds Field.c to make/java/java/FILES_c.gmk (old build)
Renames parameter in Field.c from method to field

Thanks for the suggestions/fixes!

cheers
/Joel

On 2013-09-21, Joel Borggren-Franck wrote:
> Hi
> 
> A while ago [1] I introduced an extra field in to j.l.r.Method,
> j.l.r.Constructor, and j.l.r.Field in order to support reflection for
> type annotations. These fields were intended to be removed later, they
> were there to make the coordination between VM and libraries easier when
> implementing reflection for type annotations.
> 
> This change removes the fields. Reflection for type annotations simply
> get the bytes from the vm lazily when it needs them. Because reflection
> for type annotations is suspected to be fairly uncommon and not
> performance critical no caching is done. This can be changed later.
> 
> The vm side of things were pushed a while back [2], this is the JDK side
> of the changes.
> 
> This is a refactoring, all current annotation and type annotation tests
> pass after this change.
> 
> Webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.01/
> Bug id: https://bugs.openjdk.java.net/browse/JDK-8009719
> 
> Also including build-dev since I needed to update the mapfiles. To my
> knowledge I have updated both the old and the new build.
> 
> Please review
> 
> cheers
> /Joel
> 
> [1] : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d977f61af5e
> [2] : http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1916ca1dec2f


From alexander.zuev at oracle.com  Mon Sep 23 14:30:07 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Mon, 23 Sep 2013 14:30:07 +0000
Subject: hg: jdk8/tl/langtools: 4881267: improve diagnostic for "instanceof T"
	for type parameter T
Message-ID: <20130923143013.1CD4162A5A@hg.openjdk.java.net>

Changeset: 64e79d38bd07
Author:    kizune
Date:      2013-09-23 18:29 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64e79d38bd07

4881267: improve diagnostic for "instanceof T" for type parameter T
Reviewed-by: vromero, jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/T4881267.java
+ test/tools/javac/T4881267.out



From jan.lahoda at oracle.com  Thu Sep 19 15:06:59 2013
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Thu, 19 Sep 2013 15:06:59 +0000
Subject: hg: jdk8/tl/langtools: 8022567: Javac Should Generate Warnings For
	Raw Array Type
Message-ID: <20130919150702.61C6B62958@hg.openjdk.java.net>

Changeset: 8d1c48de706d
Author:    jlahoda
Date:      2013-09-19 17:05 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8d1c48de706d

8022567: Javac Should Generate Warnings For Raw Array Type
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/warnings/6747671/T6747671.java
! test/tools/javac/warnings/6747671/T6747671.out



From jan.lahoda at oracle.com  Fri Sep 20 14:36:13 2013
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Fri, 20 Sep 2013 14:36:13 +0000
Subject: hg: jdk8/tl/langtools: 8023835: TreeMaker.QualIdent() too leafy
Message-ID: <20130920143620.14A0C629D4@hg.openjdk.java.net>

Changeset: 41599b57d262
Author:    jlahoda
Date:      2013-09-20 16:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/41599b57d262

8023835: TreeMaker.QualIdent() too leafy
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
+ test/tools/javac/tree/MakeQualIdent.java
+ test/tools/javac/tree/ScopeTest.java



From charlie.wang at oracle.com  Mon Sep 23 10:26:41 2013
From: charlie.wang at oracle.com (Charlie Wang)
Date: Mon, 23 Sep 2013 18:26:41 +0800
Subject: Fwd: Re: type anno test code check in
In-Reply-To: <20130923080133.GA15298@jfranck-desktop.jrpg.bea.com>
References: <522F56DE.4040807@oracle.com> <522FD95D.9040402@oracle.com>
	<20130911144428.GR11725@jfranck-desktop.jrpg.bea.com>
	<523FAA8F.3070506@oracle.com>
	<20130923080133.GA15298@jfranck-desktop.jrpg.bea.com>
Message-ID: <52401761.5000301@oracle.com>

OK, here's the link 
http://cr.openjdk.java.net/~pzhang/Charlie/TypeAnnotation1/webrev/
Also I would appreciate it if you could check in the code once you are 
OK with it, because these tests have gone through numerous rounds of 
review and I would like to wrap it up asap.
If others have comments, I will file RFE bugs to track them.




- Charlie


On 2013/9/23 16:01, Joel Borggren-Franck wrote:
> Hi Charlie,
>
> Please upload a webrev that I and others can review.
>
> cheers
> /Joel
>
> On 2013-09-23, Charlie Wang wrote:
>> Hi Joel,
>>    Fixed the issues people raised recently. Could you commit the code
>> for me? Files are attached. Thanks.
>>
>>
>> - Charlie
>>
>> On 2013/9/11 22:44, Joel Borggren-Franck wrote:
>>> Hi Charlie,
>>>
>>> These tests should go into TL, I can commit them there. The test review
>>> cycle should be on core-libs-dev at openjdk.java.net.
>>>
>>> However the test are not ready yet.
>>>
>>> If you run the tests vs jdk8-b106 or a recent copy of TL there is a few
>>> failures. How can I as a developer see the exact source which caused the
>>> failure?
>>>
>>> Further, there is an @author tag between two jtreg tags, @build and
>>> @run in almost every file. Please don't do that.
>>>
>>> As a user of these tests there needs to be a way for me to:
>>>
>>> 1) Understand the tests / ensure that the tests are correct
>>> 2) Run the tests
>>> 3) Understand what causes tests failures
>>>
>>> Out of these only 2) is currently easy. 1) is hard and 3) looks
>>> impossible.
>>>
>>> Here is what you need to do to bring this forward:
>>>
>>> - At a minimum you need to document how the tests work. It is not clear
>>>    at the moment.
>>>
>>> - Please explain why are the helpers split out into 2 interfaces and 4
>>>    classes?
>>>
>>> - You also need to improve failure friendliness. If a tests fail, it
>>>    must be possible to see the java source of the generated program that
>>>    fails together with a decent explanation of what went wrong.
>>>
>>> If this is currently available, please indicate how to do it.
>>>
>>> cheers
>>> /Joel
>>>
>>> On 2013-09-11, Charlie Wang wrote:
>>>> Hi,
>>>>    I'm looking for a committer to help me check in type annotation
>>>> reflection test code. Could someone give me a hand?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Charlie
>>>>
>>>> -------- Original Message --------
>>>> Subject: 	Re: type anno test code check in
>>>> Date: 	Tue, 10 Sep 2013 10:29:02 -0700
>>>> From: 	Alex Buckley 
>>>> Organization: 	Oracle Corporation
>>>> To: 	Charlie Wang 
>>>>
>>>>
>>>>
>>>> Ask on type-annotations-dev for a Committer in the Type Annotations
>>>> Project to push the tests for you. The tests will go in the jdk repo.
>>>>
>>>> Alex
>>>>
>



From scolebourne at joda.org  Mon Sep 23 15:04:26 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 23 Sep 2013 16:04:26 +0100
Subject: Review java.time test refactoring
In-Reply-To: <523A1BCF.3030001@oracle.com>
References: <523A1BCF.3030001@oracle.com>
Message-ID: 

The change looks fine AFAICT. I would prefer to see the new serial
package test classes have names that end in "Serialization", eg
"TCKLocalDateSerialization", but if that does not happen it is not the
end of the world.
Stephen


On 18 September 2013 22:31, roger riggs  wrote:
> A review of the TCK tests for java.time resulted in a number of changes
> including refactoring the serialization tests into subpackages to follow JCK
> conventions,
> discovery that a number of tests were missing for serialization, and cleanup
> of the test code to utilize common test functions for testing serialization.
> Thanks to the JCK folks for identifying the issues and doing some of the
> refactoring.
>
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-serial-refactor-8024896/
>
>  * JDK-8024896 
>    Refactor java.time serialization tests into separate subpackage
>
>  * JDK-8024427 
>    Missing java.time.chrono serialization tests
>
> Thanks, Roger
>


From Alan.Bateman at oracle.com  Mon Sep 23 15:38:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Sep 2013 08:38:56 -0700
Subject: Update JAX-WS RI integration to 2.2.9-b130918.1732
In-Reply-To: <524007A9.8040604@oracle.com>
References: <524007A9.8040604@oracle.com>
Message-ID: <52406090.6030403@oracle.com>

On 23/09/2013 02:19, Miroslav Kos wrote:
> Hi everybody,
>
> There is another update syncing JAX-WS sources in jdk8/tl/jaxws to 
> most recent development version.
>
> As usually, it is quite big changeset (6k+ LOC changed) and includes 
> several bug fixes, for details see the issue description:
> https://bugs.openjdk.java.net/browse/JDK-8025054
>
> Please, see weberevs here:
> jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00
> jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/
Just a passing comment (not a code review) on the copyright headers of 
the new source files. I assume they must have been copied from another 
file as they say 1997.  You might want to also check for tabs too 
(although jcheck will catch those) because it looks like some of the 
javadoc comments and annotations have inconsistent indentation.

-Alan


From erik.joelsson at oracle.com  Mon Sep 23 15:59:38 2013
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 23 Sep 2013 17:59:38 +0200
Subject: RFR: 8009719: core reflection should get type annotation data
	from the VM lazily
In-Reply-To: <20130923140018.GG15298@jfranck-desktop.jrpg.bea.com>
References: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
	<20130923140018.GG15298@jfranck-desktop.jrpg.bea.com>
Message-ID: <5240656A.8010906@oracle.com>

I'm happy with the build part now.

/Erik

On 2013-09-23 16:00, Joel Borggren-Franck wrote:
> Hi all,
>
> Updated webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.02/
>
> Adds Field.c to make/java/java/FILES_c.gmk (old build)
> Renames parameter in Field.c from method to field
>
> Thanks for the suggestions/fixes!
>
> cheers
> /Joel
>
> On 2013-09-21, Joel Borggren-Franck wrote:
>> Hi
>>
>> A while ago [1] I introduced an extra field in to j.l.r.Method,
>> j.l.r.Constructor, and j.l.r.Field in order to support reflection for
>> type annotations. These fields were intended to be removed later, they
>> were there to make the coordination between VM and libraries easier when
>> implementing reflection for type annotations.
>>
>> This change removes the fields. Reflection for type annotations simply
>> get the bytes from the vm lazily when it needs them. Because reflection
>> for type annotations is suspected to be fairly uncommon and not
>> performance critical no caching is done. This can be changed later.
>>
>> The vm side of things were pushed a while back [2], this is the JDK side
>> of the changes.
>>
>> This is a refactoring, all current annotation and type annotation tests
>> pass after this change.
>>
>> Webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.01/
>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8009719
>>
>> Also including build-dev since I needed to update the mapfiles. To my
>> knowledge I have updated both the old and the new build.
>>
>> Please review
>>
>> cheers
>> /Joel
>>
>> [1] : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d977f61af5e
>> [2] : http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1916ca1dec2f



From eric.mccorkle at oracle.com  Mon Sep 23 19:38:32 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Mon, 23 Sep 2013 19:38:32 +0000
Subject: hg: jdk8/tl/langtools: 6499673: Assertion check for
	TypeVariable.getUpperBound() fails.
Message-ID: <20130923193840.F247962A65@hg.openjdk.java.net>

Changeset: 09301757bb32
Author:    emc
Date:      2013-09-23 15:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09301757bb32

6499673: Assertion check for TypeVariable.getUpperBound() fails.
Summary: Fix TypeVariable.getUpperBound to return results as specified
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
! test/tools/javac/cast/intersection/model/Model01.java
! test/tools/javac/cast/intersection/model/ModelChecker.java
+ test/tools/javac/processing/model/type/BoundsTest.java
+ test/tools/javac/processing/model/type/IntersectionPropertiesTest.java



From martinrb at google.com  Tue Sep 24 07:16:25 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Sep 2013 00:16:25 -0700
Subject: RFR 8024253: ThreadLocal random can use SecureRandom for the
	initial seed
In-Reply-To: <5237929F.7070200@cs.oswego.edu>
References: 
	<5236D0CB.2060707@oracle.com> <5236EC66.4040808@cs.oswego.edu>
	<5236FDBB.9010209@gmail.com>
	
	<523714E2.4010906@oracle.com> <52371807.9080401@gmail.com>
	<52371AAE.9010801@cs.oswego.edu> <52371E82.9080803@gmail.com>
	<52372625.7050106@oracle.com> <52373992.2030206@cs.oswego.edu>
	<656CE6B7-EA7D-4944-9B63-F5CA943B1B1A@oracle.com>
	<5237929F.7070200@cs.oswego.edu>
Message-ID: 

Stupid SplittableRandom tricks:

            System.out.println(sr.nextDouble(0.0d,
Double.POSITIVE_INFINITY));
always prints constant 1.7976931348623157E308

which might be considered a bug.

---

The spec below fails to be pedantically correct when one of the args is NaN.

* @throws IllegalArgumentException if {@code origin} is greater than
     *         or equal to {@code bound}
     */
    public double nextDouble(double origin, double bound) {

Better to draw inspiration from the spec for
     * @throws IllegalArgumentException if {@code bound} is not positive
     */
    public double nextDouble(double bound) {

and write:

     * @throws IllegalArgumentException if {@code bound - origin} is not
positive
     */
    public double nextDouble(double origin, double bound) {



On Mon, Sep 16, 2013 at 4:22 PM, Doug Lea 
 wrote:

> On 09/16/2013 02:11 PM, Guy Steele wrote:
>
>  Okay, as long as we're obsessing: the code defends against the hardware
>> address being longer than 8 bytes.
>>
>
> This was to protect ourselves from the impact of this code being used in
> some
> alternative universe in which hardware addresses are not always 48bits.
> But you are right that we could do a little better.
>
>  So how about this code?
>> ...
>>
>>                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
>>
>
> On first glance the sign extension of byte to long conversion
> makes this suspicious, but I see that it cannot hurt.
> So, sure; thanks.
>
> Here's the full current version, including another minor tweak.
> (Paul: I'm committing to our CVS.)
>
>
>     private static long initialSeed() {
>         String pp = java.security.**AccessController.doPrivileged(
>                 new sun.security.action.**GetPropertyAction(
>                         "java.util.secureRandomSeed"))**;
>         if (pp != null && pp.equalsIgnoreCase("true")) {
>             byte[] seedBytes = java.security.SecureRandom.**getSeed(8);
>             long s = (long)(seedBytes[0]) & 0xffL;
>             for (int i = 1; i < 8; ++i)
>                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>             return s;
>         }
>         long h = 0L;
>         try {
>             Enumeration ifcs =
>                 NetworkInterface.**getNetworkInterfaces();
>             boolean retry = false; // retry once if getHardwareAddress is
> null
>             while (ifcs.hasMoreElements()) {
>                 NetworkInterface ifc = ifcs.nextElement();
>                 if (!ifc.isVirtual()) { // skip fake addresses
>                     byte[] bs = ifc.getHardwareAddress();
>                     if (bs != null) {
>                         int n = bs.length;
>                         int m = Math.min(n >>> 1, 4);
>
>                         for (int i = 0; i < m; ++i)
>                             h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
>                         if (m < 4)
>                             h = (h << 8) ^ bs[n-1-m];
>                         h = mix64(h);
>
>                         break;
>                     }
>                     else if (!retry)
>                         retry = true;
>                     else
>                         break;
>                 }
>             }
>         } catch (Exception ignore) {
>         }
>         return (h ^ mix64(System.**currentTimeMillis()) ^
>                 mix64(System.nanoTime()));
>     }
>
>


From ivan.gerasimov at oracle.com  Tue Sep 24 08:03:03 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 24 Sep 2013 12:03:03 +0400
Subject: [7u-dev] Request for approval for CRs 8007454, 7147084
Message-ID: <52414737.9090000@oracle.com>

Hello!

We have a request to backport fix for 7147084.

First, it depends on the fix for 8007454, so the webrev includes it too.
Second, the fix had to be adjusted a bit.
- I had to manually replaced Java_java_lang_ProcessImpl_create() 
function body with the new version, as 'hg patch' could not handle 
automatically.
- I had to replace wide-char strings to regular char*, in all the calls 
to win32Error() function.

Combined webrev:
http://cr.openjdk.java.net/~igerasim/7147084/0/webrev/

BUGS:
http://bugs.sun.com/view_bug.do?bug_id=7147084
http://bugs.sun.com/view_bug.do?bug_id=8007454

JDK8 Changesets:
7147084: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa
8007454: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d

Reviews for jdk8 fix:

7147084: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019604.html
8007454: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014602.html

I had set up a JPRT job, which completed successfully.
All the .*jdk_lang.* test passed.

Sincerely yours,
Ivan Gerasimov


From ivan.gerasimov at oracle.com  Tue Sep 24 08:13:36 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 24 Sep 2013 12:13:36 +0400
Subject: [7u-dev] Request for approval for CRs 8007454, 7147084
In-Reply-To: <52414737.9090000@oracle.com>
References: <52414737.9090000@oracle.com>
Message-ID: <524149B0.5040707@oracle.com>

It was meant to be sent to jdk7u-dev


On 24.09.2013 12:03, Ivan Gerasimov wrote:
> Hello!
>
> We have a request to backport fix for 7147084.
>
> First, it depends on the fix for 8007454, so the webrev includes it too.
> Second, the fix had to be adjusted a bit.
> - I had to manually replaced Java_java_lang_ProcessImpl_create() 
> function body with the new version, as 'hg patch' could not handle 
> automatically.
> - I had to replace wide-char strings to regular char*, in all the 
> calls to win32Error() function.
>
> Combined webrev:
> http://cr.openjdk.java.net/~igerasim/7147084/0/webrev/
>
> BUGS:
> http://bugs.sun.com/view_bug.do?bug_id=7147084
> http://bugs.sun.com/view_bug.do?bug_id=8007454
>
> JDK8 Changesets:
> 7147084: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa
> 8007454: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d
>
> Reviews for jdk8 fix:
>
> 7147084: 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019604.html
> 8007454: 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014602.html
>
> I had set up a JPRT job, which completed successfully.
> All the .*jdk_lang.* test passed.
>
> Sincerely yours,
> Ivan Gerasimov
>
>



From eric.mccorkle at oracle.com  Tue Sep 24 11:38:54 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 24 Sep 2013 07:38:54 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <523B7788.1070907@oracle.com>
References: <52321DC8.9060203@oracle.com> <523315B0.2040407@oracle.com>
	<51AF0CA4-91CF-427B-A26B-F248F0C4C42D@oracle.com>
	<5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
	<52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com>
	<523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com>
	<523A7973.4010909@oracle.com> <523B7788.1070907@oracle.com>
Message-ID: <524179CE.9030202@oracle.com>

Updated webrev here:
http://cr.openjdk.java.net/~emc/8020981/

Are there any more comments, or is this good to go?

On 09/19/13 18:15, Eric McCorkle wrote:
> The webrev has been updated with Joe's comments addressed.
> 
> On 09/19/13 00:11, David Holmes wrote:
>> On 19/09/2013 9:59 AM, Eric McCorkle wrote:
>>> This still needs to be reviewed.
>>
>> You seem to have ignored Joe's comments regarding the change to Modifier
>> being incorrect.
>>
>> David
>>
>>> On 09/16/13 14:50, Eric McCorkle wrote:
>>>> I pulled the class files into byte array constants, as a temporary
>>>> measure until a viable method for testing bad class files is developed.
>>>>
>>>> The webrev has been refreshed.  The class files will be taken out before
>>>> I push.
>>>>
>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>
>>>> On 09/13/13 20:48, Joe Darcy wrote:
>>>>> To avoid storing binaries in Hg, you could try something like:
>>>>>
>>>>> * uuencode / ascii armor the class file
>>>>> * convert to byte array in the test
>>>>> * load classes from byte array
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote:
>>>>>> I did it by hand with emacs.
>>>>>>
>>>>>> I would really rather tackle the bad class files for testing issue
>>>>>> once
>>>>>> and for all, the Right Way (tm).  But with ZBB looming, now is not the
>>>>>> time to do it.
>>>>>>
>>>>>> Hence, I have created this task
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674
>>>>>>
>>>>>> I also just created this one:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812
>>>>>>
>>>>>> On 09/13/13 13:54, Peter Levart wrote:
>>>>>>> Hi Eric,
>>>>>>>
>>>>>>> How did you create those class files? By hand using a HEX editor? Did
>>>>>>> you create a program that patched the original class file? If the
>>>>>>> later
>>>>>>> is the case, you could pack that patching logic inside a custom
>>>>>>> ClassLoader...
>>>>>>>
>>>>>>> To hacky? Dependent on future changes of javac? At least the "bad
>>>>>>> name"
>>>>>>> patching could be performed trivially and reliably, I think:
>>>>>>> search and
>>>>>>> replace with same-length string.
>>>>>>>
>>>>>>> Regards, Peter
>>>>>>>
>>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>>>>>>>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>>>>>>>
>>>>>>>> I have already filed a task for test development post ZBB to
>>>>>>>> develop a
>>>>>>>> solution for generating bad class files.  I'd prefer to file a
>>>>>>>> follow-up
>>>>>>>> to this to add the bad class file tests when that's done.
>>>>>>>>
>>>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>>>>>>>>> I think the right thing to do is to include the original compiling
>>>>>>>>> source in a comment, together with a comment on how you modify
>>>>>>>>> them, and then the result as a byte array.
>>>>>>>>>
>>>>>>>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>> /Joel
>>>>>>>>>
>>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> There is no simple means of generating bad class files for
>>>>>>>>>> testing.
>>>>>>>>>> This is a huge deficiency in our testing abilities.
>>>>>>>>>>
>>>>>>>>>> If these class files shouldn't go in, then I'm left with no choice
>>>>>>>>>> but
>>>>>>>>>> to check in no test for this patch.
>>>>>>>>>>
>>>>>>>>>> However, anyone can run the test I've provided with the class
>>>>>>>>>> files and
>>>>>>>>>> see that it works.
>>>>>>>>>>
>>>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>>>>>>>>> Hi Eric,
>>>>>>>>>>>
>>>>>>>>>>> IIRC we don't check in classfiles into the repo.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure how we handle testing of broken class-files in jdk,
>>>>>>>>>>> but ASM might be an option, or storing the class file as an
>>>>>>>>>>> embedded byte array in the test.
>>>>>>>>>>>
>>>>>>>>>>> cheers
>>>>>>>>>>> /Joel
>>>>>>>>>>>
>>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> A new webrev is posted (and crucible updated), which actually
>>>>>>>>>>>> validates
>>>>>>>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>>>>>>>
>>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review this patch, which implements correct behavior for
>>>>>>>>>>>>> the
>>>>>>>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The bug report is here:
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>>>>>>>
>>>>>>>>>>>>> The webrev is here:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>>>>>>>
>>>>>>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Eric
>>>>>>>>>>>>>
>>>>>>>>>> 
>>>>>

From joel.franck at oracle.com  Tue Sep 24 11:51:59 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Tue, 24 Sep 2013 13:51:59 +0200
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <523B7788.1070907@oracle.com>
References: <5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
	<52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com>
	<523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com>
	<523A7973.4010909@oracle.com> <523B7788.1070907@oracle.com>
Message-ID: <20130924115159.GL15298@jfranck-desktop.jrpg.bea.com>

Hi Eric,

Some feedback:

Executable.java:

299      * (i) The number of parameters (parameter_count) is wrong for the method

What is wrong in this case? Do you mean inconsistent with the signature?

302      * (iv) A parameter's name is "", or contains an illegal character [0]

What does [0] mean in this case? A placeholder for an in-mail reference
or a null byte in a modified utf8 array?

299      * (i) The number of parameters (parameter_count) is wrong for the method
300      * (ii) A constant pool index is out of bounds.
301      * (iii) A constant pool index does not refer to a UTF-8 entry
302      * (iv) A parameter's name is "", or contains an illegal character [0]
303      * (v) The flags field contains an illegal flag (something other than
304      *     FINAL, SYNTHETIC, or MANDATED)

The new "markup" looks odd. I think you should use 
     or 
       to be
consistent j.l.Class. See Class.getMethods() for an example.


306      * @throws MalformedParametersException if the class file contains
307      * a MethodParameters attribute that is improperly formatted.
308      * @return an array of {@code Parameter} objects representing all
309      * the parameters to the executable this object represents

@throws ends with a period, @return does not. I'm not sure what the
convention is but I think you want to be consistent.


364             try {
365                 tmp = getParameters0();
366             } catch(IllegalArgumentException e) {
367                 // Rethrow ClassFormatErrors
368                 throw new MalformedParametersException("Invalid constant pool index");
369             }

What is causing the IAE? Have you considered having
MalformedParametersExcepton taking a Throwable cause and having the IAE
as cause?


MalformedParametersException.java:

42     /**
43      * Use serialVersionUID from JDK 1.1.X for interoperability
44      */
45     private static final long serialVersionUID = 20130919L;

Was this type present in 1.1.x? This comment makes no sense to me.
Please explain.


BadClassFiles.java:

Thanks for encoding the class-files. Please include the original source
above the bytes.

cheers
/Joel


On 2013-09-19, Eric McCorkle wrote:
> The webrev has been updated with Joe's comments addressed.
> 
> On 09/19/13 00:11, David Holmes wrote:
> > On 19/09/2013 9:59 AM, Eric McCorkle wrote:
> >> This still needs to be reviewed.
> > 
> > You seem to have ignored Joe's comments regarding the change to Modifier
> > being incorrect.
> > 
> > David
> > 
> >> On 09/16/13 14:50, Eric McCorkle wrote:
> >>> I pulled the class files into byte array constants, as a temporary
> >>> measure until a viable method for testing bad class files is developed.
> >>>
> >>> The webrev has been refreshed.  The class files will be taken out before
> >>> I push.
> >>>
> >>> http://cr.openjdk.java.net/~emc/8020981/
> >>>
> >>> On 09/13/13 20:48, Joe Darcy wrote:
> >>>> To avoid storing binaries in Hg, you could try something like:
> >>>>
> >>>> * uuencode / ascii armor the class file
> >>>> * convert to byte array in the test
> >>>> * load classes from byte array
> >>>>
> >>>> -Joe
> >>>>
> >>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote:
> >>>>> I did it by hand with emacs.
> >>>>>
> >>>>> I would really rather tackle the bad class files for testing issue
> >>>>> once
> >>>>> and for all, the Right Way (tm).  But with ZBB looming, now is not the
> >>>>> time to do it.
> >>>>>
> >>>>> Hence, I have created this task
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8024674
> >>>>>
> >>>>> I also just created this one:
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8024812
> >>>>>
> >>>>> On 09/13/13 13:54, Peter Levart wrote:
> >>>>>> Hi Eric,
> >>>>>>
> >>>>>> How did you create those class files? By hand using a HEX editor? Did
> >>>>>> you create a program that patched the original class file? If the
> >>>>>> later
> >>>>>> is the case, you could pack that patching logic inside a custom
> >>>>>> ClassLoader...
> >>>>>>
> >>>>>> To hacky? Dependent on future changes of javac? At least the "bad
> >>>>>> name"
> >>>>>> patching could be performed trivially and reliably, I think:
> >>>>>> search and
> >>>>>> replace with same-length string.
> >>>>>>
> >>>>>> Regards, Peter
> >>>>>>
> >>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
> >>>>>>> Ugh.  Byte arrays of class file data is really a horrible solution.
> >>>>>>>
> >>>>>>> I have already filed a task for test development post ZBB to
> >>>>>>> develop a
> >>>>>>> solution for generating bad class files.  I'd prefer to file a
> >>>>>>> follow-up
> >>>>>>> to this to add the bad class file tests when that's done.
> >>>>>>>
> >>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
> >>>>>>>> I think the right thing to do is to include the original compiling
> >>>>>>>> source in a comment, together with a comment on how you modify
> >>>>>>>> them, and then the result as a byte array.
> >>>>>>>>
> >>>>>>>> IIRC I have seen test of that kind before somewhere in our repo.
> >>>>>>>>
> >>>>>>>> cheers
> >>>>>>>> /Joel
> >>>>>>>>
> >>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle
> >>>>>>>>  wrote:
> >>>>>>>>
> >>>>>>>>> There is no simple means of generating bad class files for
> >>>>>>>>> testing.
> >>>>>>>>> This is a huge deficiency in our testing abilities.
> >>>>>>>>>
> >>>>>>>>> If these class files shouldn't go in, then I'm left with no choice
> >>>>>>>>> but
> >>>>>>>>> to check in no test for this patch.
> >>>>>>>>>
> >>>>>>>>> However, anyone can run the test I've provided with the class
> >>>>>>>>> files and
> >>>>>>>>> see that it works.
> >>>>>>>>>
> >>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
> >>>>>>>>>> Hi Eric,
> >>>>>>>>>>
> >>>>>>>>>> IIRC we don't check in classfiles into the repo.
> >>>>>>>>>>
> >>>>>>>>>> I'm not sure how we handle testing of broken class-files in jdk,
> >>>>>>>>>> but ASM might be an option, or storing the class file as an
> >>>>>>>>>> embedded byte array in the test.
> >>>>>>>>>>
> >>>>>>>>>> cheers
> >>>>>>>>>> /Joel
> >>>>>>>>>>
> >>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle
> >>>>>>>>>>  wrote:
> >>>>>>>>>>
> >>>>>>>>>>> A new webrev is posted (and crucible updated), which actually
> >>>>>>>>>>> validates
> >>>>>>>>>>> parameter names correctly.  Apologies for the last one.
> >>>>>>>>>>>
> >>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
> >>>>>>>>>>>> Hello,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please review this patch, which implements correct behavior for
> >>>>>>>>>>>> the
> >>>>>>>>>>>> Parameter Reflection API in the case of malformed class files.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The bug report is here:
> >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
> >>>>>>>>>>>>
> >>>>>>>>>>>> The webrev is here:
> >>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
> >>>>>>>>>>>>
> >>>>>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Eric
> >>>>>>>>>>>>
> >>>>>>>>> 
> >>>>



From stefan.karlsson at oracle.com  Tue Sep 24 13:56:17 2013
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Tue, 24 Sep 2013 13:56:17 +0000
Subject: hg: jdk8/tl/jdk: 8014659: NPG: performance counters for compressed
	klass space
Message-ID: <20130924135655.F093662A86@hg.openjdk.java.net>

Changeset: b606775fd1a3
Author:    stefank
Date:      2013-08-29 11:08 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b606775fd1a3

8014659: NPG: performance counters for compressed klass space
Reviewed-by: jmasa, sla
Contributed-by: erik.helin at oracle.com

! src/share/classes/sun/tools/jstat/resources/jstat_options
! test/sun/tools/jstat/gcCapacityOutput1.awk
! test/sun/tools/jstat/gcCauseOutput1.awk
! test/sun/tools/jstat/gcMetaCapacityOutput1.awk
! test/sun/tools/jstat/gcOldOutput1.awk
! test/sun/tools/jstat/gcOutput1.awk
! test/sun/tools/jstat/lineCounts1.awk
! test/sun/tools/jstat/lineCounts2.awk
! test/sun/tools/jstat/lineCounts3.awk
! test/sun/tools/jstat/lineCounts4.awk
! test/sun/tools/jstat/timeStamp1.awk
! test/sun/tools/jstatd/jstatGcutilOutput1.awk



From daniel.fuchs at oracle.com  Tue Sep 24 14:24:24 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Sep 2013 16:24:24 +0200
Subject: RFR: 8025140 - TEST_BUG: java/util/logging/Logger/getGlobal tests
	fail due to timeout
Message-ID: <5241A098.2010509@oracle.com>

Hi,

This is a trivial fix for:

8025140 - TEST_BUG: java/util/logging/Logger/getGlobal tests fail
           due to timeout

JBS:    
webrev: 


The issue here is that the getGlobal/* tests had @run lines containing
timeout value which were too aggressive for certain configurations -
such as fastdebug JDK builds with all twist & bell options enabled.

There doesn't seem to be any reason to use any magic timeout value in
these tests - so I simply removed the /timeout=10 option and verified
that the tests passed in configurations where they previously failed.

best regards,

-- daniel


From Alan.Bateman at oracle.com  Tue Sep 24 17:11:26 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Sep 2013 10:11:26 -0700
Subject: RFR: 8025140 - TEST_BUG: java/util/logging/Logger/getGlobal tests
	fail due to timeout
In-Reply-To: <5241A098.2010509@oracle.com>
References: <5241A098.2010509@oracle.com>
Message-ID: <5241C7BE.5080708@oracle.com>

On 24/09/2013 07:24, Daniel Fuchs wrote:
> :
>
> There doesn't seem to be any reason to use any magic timeout value in
> these tests - so I simply removed the /timeout=10 option and verified
> that the tests passed in configurations where they previously failed.
  Sometimes people specify /timeout when they are checking the test 
against a JDK without the fix and maybe this is the case here. In any 
case, I agree there isn't any need for it and your changes look okay to me.

-Alan


From paul.sandoz at oracle.com  Tue Sep 24 17:14:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Sep 2013 10:14:00 -0700
Subject: Overloads warnings overly agressive?
Message-ID: 

Hi,

There is a new warning about overloads on methods with functional interfaces, but it appears to be over-agressive as Doug pointed out to me off-list.

If i enable this when compiling tl (make JAVAC_WARNINGS:=-Xlint:overloads) then one can observe warnings such as on the primitive spliterators:

/Users/sandoz/Projects/jdk8/tl/jdk/src/share/classes/java/util/Spliterator.java:642: warning: [overloads] tryAdvance(IntConsumer) in OfInt is potentially ambiguous with tryAdvance(Consumer) in OfInt
        boolean tryAdvance(IntConsumer action);
                ^
/Users/sandoz/Projects/jdk8/tl/jdk/src/share/classes/java/util/Spliterator.java:645: warning: [overloads] forEachRemaining(IntConsumer) in OfInt is potentially ambiguous with forEachRemaining(Consumer) in OfInt
        default void forEachRemaining(IntConsumer action) {

The warnings propagate down to implementations, for example:

/Users/sandoz/Projects/jdk8/tl/jdk/src/share/classes/java/util/Random.java:1025: warning: [overloads] tryAdvance(IntConsumer) in RandomIntsSpliterator is potentially ambiguous with tryAdvance(Consumer) in Spliterator
        public boolean tryAdvance(IntConsumer consumer) {
                       ^
  where T is a type-variable:
    T extends Object declared in interface Spliterator
/Users/sandoz/Projects/jdk8/tl/jdk/src/share/classes/java/util/Random.java:1036: warning: [overloads] forEachRemaining(IntConsumer) in RandomIntsSpliterator is potentially ambiguous with forEachRemaining(Consumer) in Spliterator
        public void forEachRemaining(IntConsumer consumer) {

(Incidentally it does not appear all warnings are reported, warnings for the double implementations are missing.)

If I write a SuppressWarnings on Spliterator.OfInt:

    @SuppressWarnings("overloads")
    public interface OfInt extends OfPrimitive {

then that stops the first set of warnings (above) but the warnings are still propagated to the second set for Random (or in general implementations or extensions of). That seems over aggressive and more of an annoyance than helpful. Can we change this?

Paul.

From jonathan.gibbons at oracle.com  Tue Sep 24 17:49:33 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 24 Sep 2013 17:49:33 +0000
Subject: hg: jdk8/tl/langtools: 8025050: Doclint doesn't recognize  tag
Message-ID: <20130924174953.ED0AE62A94@hg.openjdk.java.net>

Changeset: 96dcb66e6b0a
Author:    jjg
Date:      2013-09-24 10:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/96dcb66e6b0a

8025050: Doclint doesn't recognize  tag
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclint/HtmlTag.java
! test/tools/doclint/html/InlineTagsTest.java



From jonathan.gibbons at oracle.com  Tue Sep 24 17:52:23 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 24 Sep 2013 17:52:23 +0000
Subject: hg: jdk8/tl/langtools: 8025246: [doclint] doclint is showing error on
	anchor already defined when it's not
Message-ID: <20130924175229.55D0662A95@hg.openjdk.java.net>

Changeset: 503338f16d2b
Author:    jjg
Date:      2013-09-24 10:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/503338f16d2b

8025246: [doclint] doclint is showing error on anchor already defined when it's not
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/anchorTests/p/Test.java
+ test/tools/doclint/anchorTests/p/Test.javac.out
+ test/tools/doclint/anchorTests/p/Test.out
+ test/tools/doclint/anchorTests/p/package-info.java
+ test/tools/doclint/anchorTests/p/package-info.javac.out
+ test/tools/doclint/anchorTests/p/package-info.out



From henry.jen at oracle.com  Tue Sep 24 18:11:47 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 24 Sep 2013 11:11:47 -0700
Subject: Overloads warnings overly agressive?
In-Reply-To: 
References: 
Message-ID: <4EF8FE66-17CC-4F6B-BE25-1945A544A333@oracle.com>

Hi,

I had reported this issue with attached test with behavior I observed, Brian and me agreed that SuppressWarnings on either one as in this test case should be sufficient.

Cheers,
Henry


-------------- next part --------------


On Sep 24, 2013, at 10:14 AM, Paul Sandoz  wrote:

> Hi,
> 
> There is a new warning about overloads on methods with functional interfaces, but it appears to be over-agressive as Doug pointed out to me off-list.
> 
> If i enable this when compiling tl (make JAVAC_WARNINGS:=-Xlint:overloads) then one can observe warnings such as on the primitive spliterators:
> 
> /Users/sandoz/Projects/jdk8/tl/jdk/src/share/classes/java/util/Spliterator.java:642: warning: [overloads] tryAdvance(IntConsumer) in OfInt is potentially ambiguous with tryAdvance(Consumer) in OfInt
>        boolean tryAdvance(IntConsumer action);
>                ^
> /Users/sandoz/Projects/jdk8/tl/jdk/src/share/classes/java/util/Spliterator.java:645: warning: [overloads] forEachRemaining(IntConsumer) in OfInt is potentially ambiguous with forEachRemaining(Consumer) in OfInt
>        default void forEachRemaining(IntConsumer action) {
> 
> The warnings propagate down to implementations, for example:
> 
> /Users/sandoz/Projects/jdk8/tl/jdk/src/share/classes/java/util/Random.java:1025: warning: [overloads] tryAdvance(IntConsumer) in RandomIntsSpliterator is potentially ambiguous with tryAdvance(Consumer) in Spliterator
>        public boolean tryAdvance(IntConsumer consumer) {
>                       ^
>  where T is a type-variable:
>    T extends Object declared in interface Spliterator
> /Users/sandoz/Projects/jdk8/tl/jdk/src/share/classes/java/util/Random.java:1036: warning: [overloads] forEachRemaining(IntConsumer) in RandomIntsSpliterator is potentially ambiguous with forEachRemaining(Consumer) in Spliterator
>        public void forEachRemaining(IntConsumer consumer) {
> 
> (Incidentally it does not appear all warnings are reported, warnings for the double implementations are missing.)
> 
> If I write a SuppressWarnings on Spliterator.OfInt:
> 
>    @SuppressWarnings("overloads")
>    public interface OfInt extends OfPrimitive {
> 
> then that stops the first set of warnings (above) but the warnings are still propagated to the second set for Random (or in general implementations or extensions of). That seems over aggressive and more of an annoyance than helpful. Can we change this?
> 
> Paul.


From henry.jen at oracle.com  Tue Sep 24 18:17:55 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 24 Sep 2013 11:17:55 -0700
Subject: Overloads warnings overly agressive?
In-Reply-To: <4EF8FE66-17CC-4F6B-BE25-1945A544A333@oracle.com>
References: 
	<4EF8FE66-17CC-4F6B-BE25-1945A544A333@oracle.com>
Message-ID: 

Forgot that attachment is not allowed, the test code is following,

> public class TestOverload {
>     interface Foo {
>         void m(T arg);
>     }
> 
>     interface IntFoo {
>         void m(int arg);
>     }
> 
>     interface Bar {
>         void bar(Foo arg);
>     }
> 
>     interface IntBar extends Bar {
>         @SuppressWarnings("overloads")
>         default void bar(IntFoo arg) {
>             System.out.print("Primitive: ");
>         }
> 
>         @SuppressWarnings("overloads")
>         default void bar(Foo arg) {
>             System.out.print("Boxed: ");
>             bar((IntFoo) arg::m);
>         }
>     }
> 
>     public static void main(String[] args) {
>         class Impl implements IntBar {
>             @Override
>             public void bar(IntFoo foo) {
>                 IntBar.super.bar(foo);
>                 System.out.print("Overload: ");
>                 for (String arg: args) {
>                     Integer n = Integer.valueOf(arg);
>                     foo.m(n.intValue());
>                 }
>             }
>         }
>         Impl impl = new Impl();
>         impl.bar((int n) -> System.out.println(n + 100));
>         impl.bar((Integer n) -> System.out.println(n));
>     }
> }


On Sep 24, 2013, at 11:11 AM, Henry Jen  wrote:

> Hi,
> 
> I had reported this issue with attached test with behavior I observed, Brian and me agreed that SuppressWarnings on either one as in this test case should be sufficient.
> 
> Cheers,
> Henry
> 



From jonathan.gibbons at oracle.com  Tue Sep 24 18:47:51 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 24 Sep 2013 18:47:51 +0000
Subject: hg: jdk8/tl/langtools: 8025272: doclint needs to check for valid
	usage of @value tag
Message-ID: <20130924184800.C64EE62A96@hg.openjdk.java.net>

Changeset: 6a05a713450d
Author:    jjg
Date:      2013-09-24 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6a05a713450d

8025272: doclint needs to check for valid usage of @value tag
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
+ test/tools/doclint/ValueTest.java
+ test/tools/doclint/ValueTest.out



From eric.mccorkle at oracle.com  Tue Sep 24 19:15:23 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 24 Sep 2013 15:15:23 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: <20130924115159.GL15298@jfranck-desktop.jrpg.bea.com>
References: <5233260C.3010607@oracle.com>
	<6E231ADA-467F-43F2-87E5-201D71C79263@oracle.com>
	<52334CED.1030900@oracle.com> <52335156.3050308@gmail.com>
	<52335F62.1040305@oracle.com> <5233B26B.40000@oracle.com>
	<523752F9.5050509@oracle.com> <523A3E76.30307@oracle.com>
	<523A7973.4010909@oracle.com> <523B7788.1070907@oracle.com>
	<20130924115159.GL15298@jfranck-desktop.jrpg.bea.com>
Message-ID: <5241E4CB.5030807@oracle.com>

Webrev updated to address these issues.

On 09/24/13 07:51, Joel Borggren-Franck wrote:

> 364             try {
> 365                 tmp = getParameters0();
> 366             } catch(IllegalArgumentException e) {
> 367                 // Rethrow ClassFormatErrors
> 368                 throw new MalformedParametersException("Invalid constant pool index");
> 369             }
> 
> What is causing the IAE? Have you considered having
> MalformedParametersExcepton taking a Throwable cause and having the IAE
> as cause?
> 

The IAE comes from hotspot itself.  There is a standard constant pool
index verifying function that throws IAE if given a bad index.

> On 2013-09-19, Eric McCorkle wrote:
>> The webrev has been updated with Joe's comments addressed.
>>
>> On 09/19/13 00:11, David Holmes wrote:
>>> On 19/09/2013 9:59 AM, Eric McCorkle wrote:
>>>> This still needs to be reviewed.
>>>
>>> You seem to have ignored Joe's comments regarding the change to Modifier
>>> being incorrect.
>>>
>>> David
>>>
>>>> On 09/16/13 14:50, Eric McCorkle wrote:
>>>>> I pulled the class files into byte array constants, as a temporary
>>>>> measure until a viable method for testing bad class files is developed.
>>>>>
>>>>> The webrev has been refreshed.  The class files will be taken out before
>>>>> I push.
>>>>>
>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>
>>>>> On 09/13/13 20:48, Joe Darcy wrote:
>>>>>> To avoid storing binaries in Hg, you could try something like:
>>>>>>
>>>>>> * uuencode / ascii armor the class file
>>>>>> * convert to byte array in the test
>>>>>> * load classes from byte array
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>> On 09/13/2013 11:54 AM, Eric McCorkle wrote:
>>>>>>> I did it by hand with emacs.
>>>>>>>
>>>>>>> I would really rather tackle the bad class files for testing issue
>>>>>>> once
>>>>>>> and for all, the Right Way (tm).  But with ZBB looming, now is not the
>>>>>>> time to do it.
>>>>>>>
>>>>>>> Hence, I have created this task
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024674
>>>>>>>
>>>>>>> I also just created this one:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024812
>>>>>>>
>>>>>>> On 09/13/13 13:54, Peter Levart wrote:
>>>>>>>> Hi Eric,
>>>>>>>>
>>>>>>>> How did you create those class files? By hand using a HEX editor? Did
>>>>>>>> you create a program that patched the original class file? If the
>>>>>>>> later
>>>>>>>> is the case, you could pack that patching logic inside a custom
>>>>>>>> ClassLoader...
>>>>>>>>
>>>>>>>> To hacky? Dependent on future changes of javac? At least the "bad
>>>>>>>> name"
>>>>>>>> patching could be performed trivially and reliably, I think:
>>>>>>>> search and
>>>>>>>> replace with same-length string.
>>>>>>>>
>>>>>>>> Regards, Peter
>>>>>>>>
>>>>>>>> On 09/13/2013 07:35 PM, Eric McCorkle wrote:
>>>>>>>>> Ugh.  Byte arrays of class file data is really a horrible solution.
>>>>>>>>>
>>>>>>>>> I have already filed a task for test development post ZBB to
>>>>>>>>> develop a
>>>>>>>>> solution for generating bad class files.  I'd prefer to file a
>>>>>>>>> follow-up
>>>>>>>>> to this to add the bad class file tests when that's done.
>>>>>>>>>
>>>>>>>>> On 09/13/13 10:55, Joel Borggr?n-Franck wrote:
>>>>>>>>>> I think the right thing to do is to include the original compiling
>>>>>>>>>> source in a comment, together with a comment on how you modify
>>>>>>>>>> them, and then the result as a byte array.
>>>>>>>>>>
>>>>>>>>>> IIRC I have seen test of that kind before somewhere in our repo.
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> /Joel
>>>>>>>>>>
>>>>>>>>>> On Sep 13, 2013, at 4:49 PM, Eric McCorkle
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> There is no simple means of generating bad class files for
>>>>>>>>>>> testing.
>>>>>>>>>>> This is a huge deficiency in our testing abilities.
>>>>>>>>>>>
>>>>>>>>>>> If these class files shouldn't go in, then I'm left with no choice
>>>>>>>>>>> but
>>>>>>>>>>> to check in no test for this patch.
>>>>>>>>>>>
>>>>>>>>>>> However, anyone can run the test I've provided with the class
>>>>>>>>>>> files and
>>>>>>>>>>> see that it works.
>>>>>>>>>>>
>>>>>>>>>>> On 09/13/13 09:55, Joel Borggr?n-Franck wrote:
>>>>>>>>>>>> Hi Eric,
>>>>>>>>>>>>
>>>>>>>>>>>> IIRC we don't check in classfiles into the repo.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure how we handle testing of broken class-files in jdk,
>>>>>>>>>>>> but ASM might be an option, or storing the class file as an
>>>>>>>>>>>> embedded byte array in the test.
>>>>>>>>>>>>
>>>>>>>>>>>> cheers
>>>>>>>>>>>> /Joel
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 13, 2013, at 3:40 PM, Eric McCorkle
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> A new webrev is posted (and crucible updated), which actually
>>>>>>>>>>>>> validates
>>>>>>>>>>>>> parameter names correctly.  Apologies for the last one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 09/12/13 16:02, Eric McCorkle wrote:
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review this patch, which implements correct behavior for
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> Parameter Reflection API in the case of malformed class files.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The bug report is here:
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8020981
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The webrev is here:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~emc/8020981/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This review is also on crucible.  The ID is CR-JDK8TL-182.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Eric
>>>>>>>>>>>>>>
>>>>>>>>>>> 
>>>>>>
> 

From jonathan.gibbons at oracle.com  Tue Sep 24 20:49:33 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 24 Sep 2013 20:49:33 +0000
Subject: hg: jdk8/tl/langtools: 8002154: [doclint] doclint should check for
	issues which are errors in javadoc
Message-ID: <20130924204946.D794562AA4@hg.openjdk.java.net>

Changeset: 3ae62331a56f
Author:    jjg
Date:      2013-09-24 13:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ae62331a56f

8002154: [doclint] doclint should check for issues which are errors in javadoc
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
! test/tools/doclint/ReferenceTest.java
! test/tools/doclint/ReferenceTest.out



From pbenedict at apache.org  Tue Sep 24 21:28:31 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 24 Sep 2013 16:28:31 -0500
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw
	correct exceptions
Message-ID: 

Eric,

Should MalformedParametersException save IAE as the root cause? Or is that
an internal detail you don't want leaked?

> Webrev updated to address these issues.
>
> On 09/24/13 07:51, Joel Borggren-Franck wrote:
>
> > 364             try {
> > 365                 tmp = getParameters0();
> > 366             } catch(IllegalArgumentException e) {
> > 367                 // Rethrow ClassFormatErrors
> > 368                 throw new MalformedParametersException("Invalid
constant pool index");
> > 369             }
> >
> > What is causing the IAE? Have you considered having
> > MalformedParametersExcepton taking a Throwable cause and having the IAE
> > as cause?
> >
>
> The IAE comes from hotspot itself.  There is a standard constant pool
> index verifying function that throws IAE if given a bad index.

Cheers,
Paul


From mandy.chung at oracle.com  Tue Sep 24 21:40:13 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 24 Sep 2013 14:40:13 -0700
Subject: RFR: 8025140 - TEST_BUG: java/util/logging/Logger/getGlobal tests
	fail due to timeout
In-Reply-To: <5241A098.2010509@oracle.com>
References: <5241A098.2010509@oracle.com>
Message-ID: <524206BD.4030607@oracle.com>

Thumbs up.

Mandy

On 9/24/2013 7:24 AM, Daniel Fuchs wrote:
> Hi,
>
> This is a trivial fix for:
>
> 8025140 - TEST_BUG: java/util/logging/Logger/getGlobal tests fail
>           due to timeout
>
> JBS:    
> webrev: 
>
>
> The issue here is that the getGlobal/* tests had @run lines containing
> timeout value which were too aggressive for certain configurations -
> such as fastdebug JDK builds with all twist & bell options enabled.
>
> There doesn't seem to be any reason to use any magic timeout value in
> these tests - so I simply removed the /timeout=10 option and verified
> that the tests passed in configurations where they previously failed.
>
> best regards,
>
> -- daniel



From henry.jen at oracle.com  Tue Sep 24 21:59:13 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 24 Sep 2013 14:59:13 -0700
Subject: RFR (2nd): 8023524: Mechanism to dump generated lambda classes /
	log lambda code generation
In-Reply-To: <523AA764.60301@redhat.com>
References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com>
	<523A307E.6080202@oracle.com> <523AA764.60301@redhat.com>
Message-ID: <52420B31.2070703@oracle.com>

Hi,

Please review the new webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8023524/1/webrev/

The updated code will attempt to escape potentially bad characters(based
on our best knowledge on Windows and common systems), it's not likely we
can avoid problem for all file systems.

Anyhow, we avoid characters that can be used to navigate (known) file
system, and if there is any other invalid characters, that should cause
an IOException failed to create file and just skip dumping of that class.

Let me know if there are other concerns.

Cheers,
Henry


On 09/19/2013 12:27 AM, Florian Weimer wrote:
> On 09/19/2013 01:00 AM, Henry Jen wrote:
> 
>>> Class names can contain '\' and other characters which are problematic
>>> on Windows.
> 
>> Thanks for reviewing, I suspect you are pointing out a potential issue
>> to look at, not that the problem exists in current implementation.
>>
>> According to JLS 3.8, the classname(an identifier) can only have
>> letters, digits, plus '_' and '$'.
> 
> You need to look at the JVM specification, there are only very few
> characters it excludes.  The restrictions come from javac, not the JVM.
>  For example, on Linux, "java '\'" will load a \.class file and run it
> (yes, I tried).
> 



From bhavesh.x.patel at oracle.com  Tue Sep 24 23:12:52 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Tue, 24 Sep 2013 23:12:52 +0000
Subject: hg: jdk8/tl/langtools: 8016328: Regression : Javadoc i18n regression
	caused by fix for 8012375
Message-ID: <20130924231258.69B7D62AAC@hg.openjdk.java.net>

Changeset: 184c0d6698c3
Author:    bpatel
Date:      2013-09-24 16:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/184c0d6698c3

8016328: Regression : Javadoc i18n regression caused by fix for 8012375
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! test/com/sun/javadoc/testHref/TestHref.java
! test/com/sun/javadoc/testJavascript/TestJavascript.java
! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testUseOption/TestUseOption.java



From peter.levart at gmail.com  Wed Sep 25 05:56:26 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Sep 2013 07:56:26 +0200
Subject: RFR (2nd): 8023524: Mechanism to dump generated lambda classes
	/ log lambda code generation
In-Reply-To: <52420B31.2070703@oracle.com>
References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com>
	<523A307E.6080202@oracle.com> <523AA764.60301@redhat.com>
	<52420B31.2070703@oracle.com>
Message-ID: <52427B0A.6010004@gmail.com>

On 09/24/2013 11:59 PM, Henry Jen wrote:
> Hi,
>
> Please review the new webrev at
> http://cr.openjdk.java.net/~henryjen/ccc/8023524/1/webrev/
>
> The updated code will attempt to escape potentially bad characters(based
> on our best knowledge on Windows and common systems), it's not likely we
> can avoid problem for all file systems.
>
> Anyhow, we avoid characters that can be used to navigate (known) file
> system, and if there is any other invalid characters, that should cause
> an IOException failed to create file and just skip dumping of that class.
>
> Let me know if there are other concerns.

Hi Henry,

Just a thought. How does URLClassLoader do the class name -> path to 
resource translation? Perhaps there's already some code that does this 
correctly and in a platform-specific way (haven't looked)...

Regards, Peter

>
> Cheers,
> Henry
>
>
> On 09/19/2013 12:27 AM, Florian Weimer wrote:
>> On 09/19/2013 01:00 AM, Henry Jen wrote:
>>
>>>> Class names can contain '\' and other characters which are problematic
>>>> on Windows.
>>> Thanks for reviewing, I suspect you are pointing out a potential issue
>>> to look at, not that the problem exists in current implementation.
>>>
>>> According to JLS 3.8, the classname(an identifier) can only have
>>> letters, digits, plus '_' and '$'.
>> You need to look at the JVM specification, there are only very few
>> characters it excludes.  The restrictions come from javac, not the JVM.
>>   For example, on Linux, "java '\'" will load a \.class file and run it
>> (yes, I tried).
>>



From peter.levart at gmail.com  Wed Sep 25 06:28:30 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Sep 2013 08:28:30 +0200
Subject: RFR (2nd): 8023524: Mechanism to dump generated lambda classes
	/ log lambda code generation
In-Reply-To: <52427B0A.6010004@gmail.com>
References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com>
	<523A307E.6080202@oracle.com> <523AA764.60301@redhat.com>
	<52420B31.2070703@oracle.com> <52427B0A.6010004@gmail.com>
Message-ID: <5242828E.3000802@gmail.com>

On 09/25/2013 07:56 AM, Peter Levart wrote:
> Just a thought. How does URLClassLoader do the class name -> path to 
> resource translation? Perhaps there's already some code that does this 
> correctly and in a platform-specific way (haven't looked)... 
Hi,

sun.misc.ProxyGenerator has similar capability. It chooses to reject 
paths that are invalid for the underlying file system (using 
java.nio.file APIs)...

Peter



From henry.jen at oracle.com  Wed Sep 25 07:32:15 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 25 Sep 2013 00:32:15 -0700
Subject: RFR (2nd): 8023524: Mechanism to dump generated lambda classes
	/ log lambda code generation
In-Reply-To: <5242828E.3000802@gmail.com>
References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com>
	<523A307E.6080202@oracle.com> <523AA764.60301@redhat.com>
	<52420B31.2070703@oracle.com> <52427B0A.6010004@gmail.com>
	<5242828E.3000802@gmail.com>
Message-ID: <5242917F.2080800@oracle.com>

On 09/24/2013 11:28 PM, Peter Levart wrote:
> On 09/25/2013 07:56 AM, Peter Levart wrote:
>> Just a thought. How does URLClassLoader do the class name -> path to
>> resource translation? Perhaps there's already some code that does this
>> correctly and in a platform-specific way (haven't looked)... 
> Hi,
> 
> sun.misc.ProxyGenerator has similar capability. It chooses to reject
> paths that are invalid for the underlying file system (using
> java.nio.file APIs)...
> 

Hi Peter,

Thanks for the pointer, I asked similar question but didn't find this.
It seems to me simply failed if classname contains invalid characters
for the filesystem. I don't know enough to know whether that's
appropriate at this moment.

Our concern is that if it is possible to create file at bad places, and
do our best to save the generated class file for captured lambda. With
that, I guess current code is slightly better than previous one.

Cheers,
Henry



From henry.jen at oracle.com  Wed Sep 25 07:37:19 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 25 Sep 2013 00:37:19 -0700
Subject: RFR (3rd): 8023524: Mechanism to dump generated lambda classes
	/ log lambda code generation
In-Reply-To: <52420B31.2070703@oracle.com>
References: <523945CF.9060804@oracle.com>
	<523994D1.8090200@redhat.com>	<523A307E.6080202@oracle.com>
	<523AA764.60301@redhat.com> <52420B31.2070703@oracle.com>
Message-ID: <524292AF.3020209@oracle.com>

Hi,

Please review the update webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8023524/2/webrev/

In this revision, I moved out code for dumping the generated class files
into a separate class as Remi suggested, so that the code is only loaded
if the property is set. (Verified with -XX:+TraceClassLoading).

I also fixed two type as Jon brought to my attention.

Cheers,
Henry


On 09/24/2013 02:59 PM, Henry Jen wrote:
> Hi,
> 
> Please review the new webrev at
> http://cr.openjdk.java.net/~henryjen/ccc/8023524/1/webrev/
> 
> The updated code will attempt to escape potentially bad characters(based
> on our best knowledge on Windows and common systems), it's not likely we
> can avoid problem for all file systems.
> 
> Anyhow, we avoid characters that can be used to navigate (known) file
> system, and if there is any other invalid characters, that should cause
> an IOException failed to create file and just skip dumping of that class.
> 
> Let me know if there are other concerns.
> 
> Cheers,
> Henry
> 
> 
> On 09/19/2013 12:27 AM, Florian Weimer wrote:
>> On 09/19/2013 01:00 AM, Henry Jen wrote:
>>
>>>> Class names can contain '\' and other characters which are problematic
>>>> on Windows.
>>
>>> Thanks for reviewing, I suspect you are pointing out a potential issue
>>> to look at, not that the problem exists in current implementation.
>>>
>>> According to JLS 3.8, the classname(an identifier) can only have
>>> letters, digits, plus '_' and '$'.
>>
>> You need to look at the JVM specification, there are only very few
>> characters it excludes.  The restrictions come from javac, not the JVM.
>>  For example, on Linux, "java '\'" will load a \.class file and run it
>> (yes, I tried).
>>
> 



From daniel.fuchs at oracle.com  Wed Sep 25 07:49:27 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Wed, 25 Sep 2013 07:49:27 +0000
Subject: hg: jdk8/tl/jdk: 8025140: TEST_BUG:
	java/util/logging/Logger/getGlobal tests fail due to timeout
Message-ID: <20130925074953.D674C62AC5@hg.openjdk.java.net>

Changeset: 76619d71a7c5
Author:    dfuchs
Date:      2013-09-25 09:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76619d71a7c5

8025140: TEST_BUG: java/util/logging/Logger/getGlobal tests fail due to timeout
Summary: Arbitrary timeouts in the tests @run lines where too agressive for some configurations. The tests will now run with default timeout.
Reviewed-by: alanb, mchung

! test/java/util/logging/Logger/getGlobal/TestGetGlobal.java
! test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java
! test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java



From aleksej.efimov at oracle.com  Wed Sep 25 11:10:38 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 25 Sep 2013 15:10:38 +0400
Subject: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH
	NODE LIST OF LENGTH =1 IN JAXP
In-Reply-To: <523B6A7D.3080501@oracle.com>
References: <5238449D.50509@oracle.com> <523B6A7D.3080501@oracle.com>
Message-ID: <5242C4AE.4060305@oracle.com>

Hi Joe,
Your suggestion about getLength() brings to mine attention the following 
behavior of unmodified JDK:
If we slightly modify a TestFunc class [1] in such manner:

    public static Node test( NodeList list ) {
                 Node ret = list.item(0);
                 System.err.println(list.getLength());
                 return ret;
    }

And add more elements to in.xml:
inp1_1inp1_2inp1_3

The test will fails:

    2
    Transformation completed. Result:inp1_2
    Exception in thread "main" java.lang.RuntimeException: Incorrect
    transformation result
         at XSLT.main(XSLT.java:49)

As you can see the length of 2 is incorrect value and the 'inp1_1' 
element is ignored. But If we do another one change to test function - 
first get the length() and then get the item:

    public static Node test( NodeList list ) {
    	    System.err.println(list.getLength());
                 Node ret = list.item(0);
                 return ret;
    }

The test will pass:

    3
    Transformation completed. Result:inp1_1

This behavior tells that item() method incorrectly caches the nodes (The 
method called first - do the caching). But the caching of nodes is done 
in correct way by getLength() function, but its according to the test 
results. Currently, I'm trying to understand why it's working in such 
way in a view of source code.

-Aleksej



[1] 
http://cr.openjdk.java.net/~aefimov/8024707/jdk/test/javax/xml/jaxp/parsers/8024707/TestFunc.java 


On 09/20/2013 01:19 AM, huizhe wang wrote:
> Hi Aleksej,
>
> Looks like the getLength() method has the same problem.
>
> Joe
>
> On 9/17/2013 5:01 AM, Aleksej Efimov wrote:
>> Hi Everyone,
>>
>> There is a bug [1] in JAXP about transformation of one-item sized 
>> node list:
>> When the length of nodelist which is passed to a XSLT extension 
>> function is 1, the node gotten from the node list becomes null.
>> New test illustrates this issue [2]. Full webrev with proposed fix 
>> can be found here: [3].
>>
>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707
>> [2] 
>> http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java
>> [3] http://cr.openjdk.java.net/~aefimov/8024707/
>>
>> Best regards,
>> Aleksej
>



From eric.mccorkle at oracle.com  Wed Sep 25 13:41:36 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 25 Sep 2013 09:41:36 -0400
Subject: JDK-8020981: Update methods of java.lang.reflect.Parameter to
	throw correct exceptions
In-Reply-To: 
References: 
Message-ID: <5242E810.8060103@oracle.com>

The enhanced metadata spec says nothing at all about an IAE.  That is an
implementation detail, possibly subject to change at any point, and it
*should* not be leaked.

On 09/24/13 17:28, Paul Benedict wrote:
> Eric,
> 
> Should MalformedParametersException save IAE as the root cause? Or is that
> an internal detail you don't want leaked?
> 
>> Webrev updated to address these issues.
>>
>> On 09/24/13 07:51, Joel Borggren-Franck wrote:
>>
>>> 364             try {
>>> 365                 tmp = getParameters0();
>>> 366             } catch(IllegalArgumentException e) {
>>> 367                 // Rethrow ClassFormatErrors
>>> 368                 throw new MalformedParametersException("Invalid
> constant pool index");
>>> 369             }
>>>
>>> What is causing the IAE? Have you considered having
>>> MalformedParametersExcepton taking a Throwable cause and having the IAE
>>> as cause?
>>>
>>
>> The IAE comes from hotspot itself.  There is a standard constant pool
>> index verifying function that throws IAE if given a bad index.
> 
> Cheers,
> Paul
> 

From ivan.gerasimov at oracle.com  Wed Sep 25 13:50:55 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 25 Sep 2013 17:50:55 +0400
Subject: [7u-dev] Request for review of backport 7147084
In-Reply-To: <52415B60.5050608@oracle.com>
References: <52415B60.5050608@oracle.com>
Message-ID: <5242EA3F.7040307@oracle.com>

Hello!

May I please have a review for a backport of the fix for 7147084 to 
jdk7u-dev?

This webrev does not include fix 8007454 anymore, as it has already been 
pushed.
http://cr.openjdk.java.net/~igerasim/7147084/1/webrev/

Thanks in advance,
Ivan Gerasimov


-------- Original Message --------
Subject: 	Re: [7u-dev] Request for approval for CRs 8007454, 7147084
Date: 	Tue, 24 Sep 2013 10:29:04 +0100
From: 	Se?n Coffey 
To: 	Ivan Gerasimov 
CC: 	jdk7u-dev at openjdk.java.net



On 24/09/2013 10:25, Ivan Gerasimov wrote:
> Thanks Se?n!
>
> Then I'll ask for an approval to backport 8007454, which is applied
> cleanly.
Consider both bugs fixes approved. You could use this mail thread to
review the 7147084 changes if you want. They're innocent enough. Alan or
someone else should be able to review.

regards,
Sean.
> And once it is pushed, I'll initiate a review for 7147084 with
> adjustments.
>
> Sincerely,
> Ivan
>
> On 24.09.2013 12:59, Se?n Coffey wrote:
>> Approved for jdk7u-dev but you'll need a review first due to the
>> adjustments needed in the backport.
>>
>> Hopefully, you'll be resolving these issues with 2 different
>> changesets. It's been the trend in the past and helps keep changesets
>> more aligned to those in JDK 8.
>>
>> regards,
>> Sean.
>>
>> On 24/09/2013 09:08, Ivan Gerasimov wrote:
>>> Sending to the correct ML
>>>
>>> --------------
>>>
>>> Hello!
>>>
>>> We have a request to backport fix for 7147084.
>>>
>>> First, it depends on the fix for 8007454, so the webrev includes it
>>> too.
>>> Second, the fix had to be adjusted a bit.
>>> - I had to manually replaced Java_java_lang_ProcessImpl_create()
>>> function body with the new version, as 'hg patch' could not handle
>>> automatically.
>>> - I had to replace wide-char strings to regular char*, in all the
>>> calls to win32Error() function.
>>>
>>> Combined webrev:
>>> http://cr.openjdk.java.net/~igerasim/7147084/0/webrev/
>>>
>>> BUGS:
>>> http://bugs.sun.com/view_bug.do?bug_id=7147084
>>> http://bugs.sun.com/view_bug.do?bug_id=8007454
>>>
>>> JDK8 Changesets:
>>> 7147084: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa
>>> 8007454: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d
>>>
>>> Reviews for jdk8 fix:
>>>
>>> 7147084:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019604.html
>>> 8007454:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014602.html
>>>
>>> I had set up a JPRT job, which completed successfully.
>>> All the .*jdk_lang.* test passed.
>>>
>>> Sincerely yours,
>>> Ivan Gerasimov
>>
>>
>>
>







From joe.darcy at oracle.com  Wed Sep 25 16:48:27 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 25 Sep 2013 09:48:27 -0700
Subject: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH
	NODE LIST OF LENGTH =1 IN JAXP
In-Reply-To: <5242C4AE.4060305@oracle.com>
References: <5238449D.50509@oracle.com> <523B6A7D.3080501@oracle.com>
	<5242C4AE.4060305@oracle.com>
Message-ID: <524313DB.4040204@oracle.com>

PLEASE DON'T REFER TO BUGS USING A SUMMARY THAT IS ALL IN CAPITAL LETTERS.

-Joe

On 9/25/2013 4:10 AM, Aleksej Efimov wrote:
> Hi Joe,
> Your suggestion about getLength() brings to mine attention the 
> following behavior of unmodified JDK:
> If we slightly modify a TestFunc class [1] in such manner:
>
>    public static Node test( NodeList list ) {
>                 Node ret = list.item(0);
>                 System.err.println(list.getLength());
>                 return ret;
>    }
>
> And add more elements to in.xml:
> inp1_1inp1_2inp1_3 
>
>
> The test will fails:
>
>    2
>    Transformation completed. Result:    encoding="UTF-8"?>inp1_2
>    Exception in thread "main" java.lang.RuntimeException: Incorrect
>    transformation result
>         at XSLT.main(XSLT.java:49)
>
> As you can see the length of 2 is incorrect value and the 'inp1_1' 
> element is ignored. But If we do another one change to test function - 
> first get the length() and then get the item:
>
>    public static Node test( NodeList list ) {
>            System.err.println(list.getLength());
>                 Node ret = list.item(0);
>                 return ret;
>    }
>
> The test will pass:
>
>    3
>    Transformation completed. Result:    encoding="UTF-8"?>inp1_1
>
> This behavior tells that item() method incorrectly caches the nodes 
> (The method called first - do the caching). But the caching of nodes 
> is done in correct way by getLength() function, but its according to 
> the test results. Currently, I'm trying to understand why it's working 
> in such way in a view of source code.
>
> -Aleksej
>
>
>
> [1] 
> http://cr.openjdk.java.net/~aefimov/8024707/jdk/test/javax/xml/jaxp/parsers/8024707/TestFunc.java 
>  
>
>
> On 09/20/2013 01:19 AM, huizhe wang wrote:
>> Hi Aleksej,
>>
>> Looks like the getLength() method has the same problem.
>>
>> Joe
>>
>> On 9/17/2013 5:01 AM, Aleksej Efimov wrote:
>>> Hi Everyone,
>>>
>>> There is a bug [1] in JAXP about transformation of one-item sized 
>>> node list:
>>> When the length of nodelist which is passed to a XSLT extension 
>>> function is 1, the node gotten from the node list becomes null.
>>> New test illustrates this issue [2]. Full webrev with proposed fix 
>>> can be found here: [3].
>>>
>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707
>>> [2] 
>>> http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java
>>> [3] http://cr.openjdk.java.net/~aefimov/8024707/
>>>
>>> Best regards,
>>> Aleksej
>>
>



From jonathan.gibbons at oracle.com  Wed Sep 25 18:08:24 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 25 Sep 2013 18:08:24 +0000
Subject: hg: jdk8/tl/langtools: 8025407: TypeAnnotations does not use Context
Message-ID: <20130925180828.BE24762ADE@hg.openjdk.java.net>

Changeset: 5043e7056be8
Author:    jjg
Date:      2013-09-25 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5043e7056be8

8025407: TypeAnnotations does not use Context
Reviewed-by: jfranck

! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java



From michael.fang at oracle.com  Wed Sep 25 21:03:24 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 25 Sep 2013 21:03:24 +0000
Subject: hg: jdk8/tl/langtools: 4 new changesets
Message-ID: <20130925210341.AFAF062AF1@hg.openjdk.java.net>

Changeset: 1332a99572c5
Author:    mfang
Date:      2013-09-24 14:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1332a99572c5

8025215: jdk8 l10n resource file translation update 4
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties
! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties
! src/share/classes/com/sun/tools/javap/resources/javap_ja.properties
! src/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties

Changeset: daa3bfb82e58
Author:    mfang
Date:      2013-09-24 14:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/daa3bfb82e58

Merge


Changeset: 6b702ace3e45
Author:    mfang
Date:      2013-09-25 07:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b702ace3e45

Merge


Changeset: 68292726000e
Author:    mfang
Date:      2013-09-25 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/68292726000e

Merge




From jonathan.gibbons at oracle.com  Wed Sep 25 21:05:14 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 25 Sep 2013 21:05:14 +0000
Subject: hg: jdk8/tl/langtools: 8025412: Add legal header and comments to
	test/tools/doclint/tidy/util/Main.java
Message-ID: <20130925210517.1495A62AF2@hg.openjdk.java.net>

Changeset: 3d61984b077c
Author:    jjg
Date:      2013-09-25 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d61984b077c

8025412: Add legal header and comments to test/tools/doclint/tidy/util/Main.java
Reviewed-by: bpatel

! test/tools/doclint/tidy/util/Main.java
! test/tools/doclint/tidy/util/tidy.sh



From michael.fang at oracle.com  Wed Sep 25 20:57:54 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 25 Sep 2013 20:57:54 +0000
Subject: hg: jdk8/tl/jdk: 3 new changesets
Message-ID: <20130925205852.0285862AEF@hg.openjdk.java.net>

Changeset: 2b928330970a
Author:    mfang
Date:      2013-09-24 14:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b928330970a

8025215: jdk8 l10n resource file translation update 4
Reviewed-by: naoto, yhuang

! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties
+ src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java
+ src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties
! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java
! src/share/classes/sun/launcher/resources/launcher_de.properties
! src/share/classes/sun/launcher/resources/launcher_es.properties
! src/share/classes/sun/launcher/resources/launcher_fr.properties
! src/share/classes/sun/launcher/resources/launcher_it.properties
! src/share/classes/sun/launcher/resources/launcher_ja.properties
! src/share/classes/sun/launcher/resources/launcher_ko.properties
! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties
! src/share/classes/sun/launcher/resources/launcher_sv.properties
! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties
! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties
! src/share/classes/sun/print/resources/serviceui_de.properties
! src/share/classes/sun/print/resources/serviceui_es.properties
! src/share/classes/sun/print/resources/serviceui_fr.properties
! src/share/classes/sun/print/resources/serviceui_it.properties
! src/share/classes/sun/print/resources/serviceui_pt_BR.properties
! src/share/classes/sun/print/resources/serviceui_sv.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties
! src/share/classes/sun/rmi/server/resources/rmid_ko.properties
! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java
! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
! src/share/classes/sun/security/tools/keytool/Resources_de.java
! src/share/classes/sun/security/tools/keytool/Resources_es.java
! src/share/classes/sun/security/tools/keytool/Resources_fr.java
! src/share/classes/sun/security/tools/keytool/Resources_it.java
! src/share/classes/sun/security/tools/keytool/Resources_ja.java
! src/share/classes/sun/security/tools/keytool/Resources_ko.java
! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/keytool/Resources_sv.java
! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java
! src/share/classes/sun/security/tools/policytool/Resources_de.java
! src/share/classes/sun/security/tools/policytool/Resources_es.java
! src/share/classes/sun/security/tools/policytool/Resources_fr.java
! src/share/classes/sun/security/tools/policytool/Resources_it.java
! src/share/classes/sun/security/tools/policytool/Resources_ja.java
! src/share/classes/sun/security/tools/policytool/Resources_ko.java
! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/policytool/Resources_sv.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java
! src/share/classes/sun/security/util/Resources_fr.java
! src/share/classes/sun/tools/jar/resources/jar_de.properties
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_fr.properties
! src/share/classes/sun/tools/jar/resources/jar_it.properties
! src/share/classes/sun/tools/jar/resources/jar_ja.properties
! src/share/classes/sun/tools/jar/resources/jar_ko.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jar/resources/jar_sv.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties
! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties
! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties

Changeset: 9765801f209f
Author:    mfang
Date:      2013-09-24 14:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9765801f209f

Merge

- test/java/util/regex/PatternTest.java

Changeset: d16a53d1762f
Author:    mfang
Date:      2013-09-25 07:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d16a53d1762f

Merge




From brent.christian at oracle.com  Wed Sep 25 22:19:27 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 25 Sep 2013 15:19:27 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
Message-ID: <5243616F.1000006@oracle.com>

Please review this change for 8025173, "HashMap.put() replacing an 
existing key can trigger a resize()."

A description of the problem can be found in the bug report:
http://bugs.sun.com/view_bug.do?bug_id=8025173

Thanks to Doug Lea for sending in the diff for HashMap.java.

Webrev is here:
http://cr.openjdk.java.net/~bchristi/8025173/webrev.00/

Results of an automated test run look okay.

Thanks,
-Brent


From martinrb at google.com  Wed Sep 25 23:03:19 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 25 Sep 2013 16:03:19 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
In-Reply-To: <5243616F.1000006@oracle.com>
References: <5243616F.1000006@oracle.com>
Message-ID: 

Looks good.
I would only suggest the stylistic improvement of using proper /** javadoc
comments even for private test methods instead of /*


On Wed, Sep 25, 2013 at 3:19 PM, Brent Christian  wrote:

> Please review this change for 8025173, "HashMap.put() replacing an
> existing key can trigger a resize()."
>
> A description of the problem can be found in the bug report:
> http://bugs.sun.com/view_bug.**do?bug_id=8025173
>
> Thanks to Doug Lea for sending in the diff for HashMap.java.
>
> Webrev is here:
> http://cr.openjdk.java.net/~**bchristi/8025173/webrev.00/
>
> Results of an automated test run look okay.
>
> Thanks,
> -Brent
>


From christian.thalinger at oracle.com  Wed Sep 25 23:27:04 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 25 Sep 2013 16:27:04 -0700
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
Message-ID: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>

http://cr.openjdk.java.net/~twisti/8019192/webrev/

8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
Reviewed-by:

This is a race in MemberName's name and type getters.

MemberName's type field is of type Object so it can hold different objects when it gets filled in from the VM.  These types include String and Object[].  On the first invocation the current type if it's not MethodType gets converted to a MethodType.

There is a tiny window where some instanceof check have already been done on one thread and then another thread stores a MethodType.  The following checkcast then fails.

The fix is to make name and type volatile and do the conversion in a synchronized block.  This is okay because it's only done once.

src/share/classes/java/lang/invoke/MemberName.java



From bhavesh.x.patel at oracle.com  Thu Sep 26 05:27:13 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 26 Sep 2013 05:27:13 +0000
Subject: hg: jdk8/tl/langtools: 8004825: javadoc crash DocletAbortException
Message-ID: <20130926052719.EE6ED62B00@hg.openjdk.java.net>

Changeset: 9e884d3ddb0b
Author:    bpatel
Date:      2013-09-25 22:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9e884d3ddb0b

8004825: javadoc crash DocletAbortException
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java
! test/com/sun/javadoc/testValueTag/TestValueTag.java
! test/com/sun/javadoc/testValueTag/pkg1/Class1.java



From peter.levart at gmail.com  Thu Sep 26 08:22:44 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Sep 2013 10:22:44 +0200
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
Message-ID: <5243EED4.9030104@gmail.com>

On 09/26/2013 01:27 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>
> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
> Reviewed-by:
>
> This is a race in MemberName's name and type getters.
>
> MemberName's type field is of type Object so it can hold different objects when it gets filled in from the VM.  These types include String and Object[].  On the first invocation the current type if it's not MethodType gets converted to a MethodType.
>
> There is a tiny window where some instanceof check have already been done on one thread and then another thread stores a MethodType.  The following checkcast then fails.
>
> The fix is to make name and type volatile and do the conversion in a synchronized block.  This is okay because it's only done once.
>
> src/share/classes/java/lang/invoke/MemberName.java
>

Hi Christian,

Wouldn't it be cleaner that instead of just casting and catching 
ClassCastException, the volatile field 'type' was 1st copied to a local 
variable and then an instanceof check + casting and returning performed 
on the local variable. This would avoid throwing ClassCastException even 
if it is performed only once per MemberName...

Regards, Peter



From sundararajan.athijegannathan at oracle.com  Thu Sep 26 13:10:44 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Thu, 26 Sep 2013 13:10:44 +0000
Subject: hg: jdk8/tl/nashorn: 6 new changesets
Message-ID: <20130926131051.78D1862B0A@hg.openjdk.java.net>

Changeset: c5475f5d4647
Author:    sundar
Date:      2013-09-24 20:43 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c5475f5d4647

8025312: parseInt should convert 'radix' argument to ToInt32 even if empty string is parsed
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/runtime/GlobalFunctions.java
+ test/script/basic/JDK-8025312.js
+ test/script/basic/JDK-8025312.js.EXPECTED

Changeset: 754ecd62bde3
Author:    sundar
Date:      2013-09-25 08:17 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/754ecd62bde3

8025325: parseFloat does not handle '.' in exponent part
Reviewed-by: hannesw

! src/jdk/nashorn/internal/runtime/GlobalFunctions.java
+ test/script/basic/JDK-8025325.js
+ test/script/basic/JDK-8025325.js.EXPECTED

Changeset: 2f8f99e5ed76
Author:    hannesw
Date:      2013-09-25 16:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2f8f99e5ed76

8025434: RegExp lastIndex can exceed int range
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8025434.js

Changeset: 712f5e31739b
Author:    hannesw
Date:      2013-09-26 10:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/712f5e31739b

8025197: String replace method fails with regexp /$/gi
Reviewed-by: sundar

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8025197.js
+ test/script/basic/JDK-8025197.js.EXPECTED

Changeset: 23958764f866
Author:    hannesw
Date:      2013-09-26 11:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/23958764f866

8025486: RegExp constructor arguments are not evaluated in right order
Reviewed-by: sundar

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8025486.js
+ test/script/basic/JDK-8025486.js.EXPECTED

Changeset: f1f027907a69
Author:    sundar
Date:      2013-09-26 16:37 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f1f027907a69

Merge




From Alan.Bateman at oracle.com  Thu Sep 26 13:11:35 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Sep 2013 06:11:35 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
In-Reply-To: <5243616F.1000006@oracle.com>
References: <5243616F.1000006@oracle.com>
Message-ID: <52443287.4070408@oracle.com>

On 25/09/2013 15:19, Brent Christian wrote:
> Please review this change for 8025173, "HashMap.put() replacing an 
> existing key can trigger a resize()."
>
> A description of the problem can be found in the bug report:
> http://bugs.sun.com/view_bug.do?bug_id=8025173
>
> Thanks to Doug Lea for sending in the diff for HashMap.java.
>
> Webrev is here:
> http://cr.openjdk.java.net/~bchristi/8025173/webrev.00/
>
> Results of an automated test run look okay.
The fix looks right to me. One comment on the test is that testItr is 
using raw types, is there any reason for thaht?

-Alan


From erik.helin at oracle.com  Thu Sep 26 14:28:42 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 26 Sep 2013 16:28:42 +0200
Subject: RFR: 8025502: Exclude tests due to JDK-8025427
Message-ID: <20130926142842.GA11592@ehelin-thinkpad>

Hi all,

I need to exclude some tests due a recent change to jstat that caused to
jstat to output the \ufffd for Double.NaN, which confused the tests. I
am working on a solution to this, but in the meantime I would like to
exclude the tests in order not cause unexpected failures.

Webrev:
http://cr.openjdk.java.net/~ehelin/8025427/webrev.00/

Thanks,
Erik


From joel.franck at oracle.com  Thu Sep 26 14:53:26 2013
From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=)
Date: Thu, 26 Sep 2013 16:53:26 +0200
Subject: RFR: 8009411 : getMethods should not inherit static methods from
	interfaces
In-Reply-To: <20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
References: <034E2135-CBC1-41CD-8D26-9ED6F0610301@oracle.com>
	<20130912133717.GW11725@jfranck-desktop.jrpg.bea.com>
Message-ID: <20130926145325.GQ15298@jfranck-desktop.jrpg.bea.com>

Hi again,

New webrev with more tests contributed by Amy Lu.

http://cr.openjdk.java.net/~jfranck/8009411/webrev.02/

No change to non-test code since webrev.01

cheers
/Joel

On 2013-09-12, Joel Borggr?n-Franck wrote:
> Hi again,
> 
> New webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.01/
> 
> Thanks to Remi and Peter for the quick feedback, I've updated the code
> to use for-each as well as fixing getMethod(...).
> 
> Andreas Lundblad also added ~100 testcases for getMethod(), both
> positive and negative.
> 
> Please review
> 
> cheers
> /Joel
> 
> On 2013-09-09, Joel Borggr?n-Franck wrote:
> > Hi
> > 
> > Pleaser review fix for 8009411 : getMethods should not inherit static methods from interfaces 
> > 
> > The issue is that since we added static methods to interfaces those have erroneously been reflected in getMethods of implementing classes. This fix filters out static interface methods from superinterfaces when adding methods. I have also added a note to the javadoc for both getMembers and getDeclaredMembers pointing this out (though it is implied from JLS). Webrev is based on the clarification to getMethods and friends out for review on this list.
> > 
> > Webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.00/
> > Bug is here: http://bugs.sun.com/view_bug.do?bug_id=8009411
> > 
> > For oracle reviewers, ccc is approved.
> > 
> > cheers
> > /Joel


From sean.mullan at oracle.com  Thu Sep 26 15:59:18 2013
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 26 Sep 2013 08:59:18 -0700
Subject: RFR(L): 8024854: Basic changes and files to build the class
	library on AIX
In-Reply-To: 
References: 
	
Message-ID: <524459D6.9030800@oracle.com>

On 09/16/2013 12:30 PM, Volker Simonis wrote:
> src/share/lib/security/java.security-aix
>
>     - Provide default java.security-aix for AIX.

The login.configuration.provider property should be set to:

sun.security.provider.ConfigFile

See 8016848 for more info.

After you make this change, java.security-aix will be identical to 
java.security-linux. It would be nice if you could just use the 
java.security-linux file, so that we would have one less file to modify 
when making platform-independent changes to the java.security file, but 
I understand that might be odd, since AIX is not linux.

Ideally, the content for the java.security-* files needs to be revamped 
so there is less duplication across the (now) 5 platform-specific files 
but we probably won't have time to get to this for JDK 8.

--Sean



From miroslav.kos at oracle.com  Thu Sep 26 16:14:54 2013
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 26 Sep 2013 18:14:54 +0200
Subject: Update JAX-WS RI integration to 2.2.9-b130918.1732
In-Reply-To: <52406090.6030403@oracle.com>
References: <524007A9.8040604@oracle.com> <52406090.6030403@oracle.com>
Message-ID: <52445D7E.2050703@oracle.com>

Hi Sean,
anything new about this?

I fixed the copyright/indentation problems (the only change), so the 
updated jaxws-webrev is located here:
http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/

Since the timestamp (version number) changed too, I updated also the 
JIRA issue:
https://bugs.openjdk.java.net/browse/JDK-8025054

It would be good to push it soon.

Thanks
Miran


On 9/23/13 5:38 PM, Alan Bateman wrote:
> On 23/09/2013 02:19, Miroslav Kos wrote:
>> Hi everybody,
>>
>> There is another update syncing JAX-WS sources in jdk8/tl/jaxws to 
>> most recent development version.
>>
>> As usually, it is quite big changeset (6k+ LOC changed) and includes 
>> several bug fixes, for details see the issue description:
>> https://bugs.openjdk.java.net/browse/JDK-8025054
>>
>> Please, see weberevs here:
>> jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00
>> jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/
> Just a passing comment (not a code review) on the copyright headers of 
> the new source files. I assume they must have been copied from another 
> file as they say 1997.  You might want to also check for tabs too 
> (although jcheck will catch those) because it looks like some of the 
> javadoc comments and annotations have inconsistent indentation.
>
> -Alan



From sergey.kuksenko at oracle.com  Thu Sep 26 16:22:31 2013
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Thu, 26 Sep 2013 20:22:31 +0400
Subject: RFR: Caching MethodType's descriptor string improves lambda
	linkage performance
In-Reply-To: 
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
	<52389D14.2080606@oracle.com>
	
Message-ID: <52445F47.9030402@oracle.com>

Hi All,

I updated fix.
You may find it here
http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.01/

See my comments and new webrev descition below

On 09/18/2013 12:59 AM, John Rose wrote:
>>> We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well. 
>> In case of small amount of such strings we will get a huge overhead from
>> any kind of map.
> I would expect O(10^1.5) memory references and branches.  Depends on what you mean by "huge".
Sure. I think the question to use external map or field may be decided
later when/if it will be needed.
Just some statictics, I've collected on nashorn/octane benchmarks
(statistics collected only for the single(first) benchmark iteration:
mandreel: 514 unique strings, toMethodDescriptorString called 69047 times
box2d: 560 unique strings, 34776 toMethodDescriptorString invocations.

> Would there be any benefit from recording the original string from the constant pool?  The JVM path for this is SystemDictionary::find_method_handle_type, which makes an upcall to MethodHandleNatives.findMethodHandleType.  Currently only the ptypes and rtype are passed, but the JVM could also convert the internal Symbol to a java.lang.String and pass that also.  In that case, MT's created by JVM upcalls would be pre-equipped with descriptor strings.
> 
> This is probably worth an experiment, although it requires some JVM work.

I am definitely sure that we shouldn't do that.
Right now caching desriptor strings is internal decision of MethodType.
Otherwise it will make interfaces more complex.

> I hope you get my overall point:  Hand optimizations have a continuing cost, related to obscuring the logical structure of the code.  The transforming engineer might make a mistake, and later maintaining engineers might also make mistakes.
> 
> https://blogs.oracle.com/jrose/entry/three_software_proverbs

And it doesn't mean that we should afraid any kind of optimization.
Lucky positions - someone(or something) will optimize it for us. But
sometimes JIT (even smart JIT) is not enough.

Let's back to the patch.construstors
I decided not change original checkPType/checkRType code, except
explicit Objects.requireNonNull. The problem here that we are creating
new MethodType objects which are already exists, we have to create MT as
a key for searching in the internedTable. Ratio between already exiting
and new MethodTypes a quite huge.
Here is some statistics I've collected on nashorn/octane benchmarks
(statistics collected only for the single(first) benchmark iteration:

mandreel:
  - 1739 unique MethodTypes,
  - 878414 MethodType.makeImpl requests;
box2d:
  - 1861 unique MethodTypes,
  - 527486 MethodType.makeImpl requests;
gameboy:
  - 2062 unique MethodTypes,
  - 311378 MethodType.makeImpl requests;

So
1. MethodType constructor do checkPTypes/checkRType which are frequently
(99%) useless - we already have the same (checked) MethodType in the
internTable.
2. Less than 1% of created MethodTypes will be stored into internTable,
but reusing that MethodType objects prevent ti from scalar replacement.
(I've heard that Graal may do flow-sensitive scalar replacement, but C2
can't do).

What I did. I separate constructors:
- for long lived MethodTypes with all checks,
- for short lived MethodTypes used only as key for searching in the
InterTable, no checks are performed.
if we didn't find  MethodType in the table we always create a new one
(with checks) that is required in less than 1% cases. And we remove at
least one obstacle for scalar replacement. Unfortunately, scalaer
replacement for expression "internTable.get(new MethodType(rtype,
ptypes))" was not performed, the reason may be evaluated, and hope it
would be easier to achieve scalarization in this case.




-- 
Best regards,
Sergey Kuksenko


From kumar.x.srinivasan at oracle.com  Thu Sep 26 16:48:06 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 26 Sep 2013 09:48:06 -0700
Subject: RFR: 8025502: Exclude tests due to JDK-8025427
In-Reply-To: <20130926142842.GA11592@ehelin-thinkpad>
References: <20130926142842.GA11592@ehelin-thinkpad>
Message-ID: <52446546.3090708@oracle.com>

Hi Erik,

Looks good!,  the bug must be tagged with keyword "noreg-build".

Kumar

> Hi all,
>
> I need to exclude some tests due a recent change to jstat that caused to
> jstat to output the \ufffd for Double.NaN, which confused the tests. I
> am working on a solution to this, but in the meantime I would like to
> exclude the tests in order not cause unexpected failures.
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8025427/webrev.00/
>
> Thanks,
> Erik



From brent.christian at oracle.com  Thu Sep 26 17:42:14 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 26 Sep 2013 10:42:14 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
In-Reply-To: <52443287.4070408@oracle.com>
References: <5243616F.1000006@oracle.com> <52443287.4070408@oracle.com>
Message-ID: <524471F6.6050203@oracle.com>

On 9/26/13 6:11 AM, Alan Bateman wrote:
> On 25/09/2013 15:19, Brent Christian wrote:
 >
> The fix looks right to me.

Thanks.

> One comment on the test is that testItr is
> using raw types, is there any reason for thaht?

Pure laziness!  Here, this one's nicer:
http://cr.openjdk.java.net/~bchristi/8025173/webrev.01/

-Brent


From brent.christian at oracle.com  Thu Sep 26 17:51:44 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 26 Sep 2013 10:51:44 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
In-Reply-To: 
References: <5243616F.1000006@oracle.com>
	
Message-ID: <52447430.9070300@oracle.com>

On 9/25/13 4:03 PM, Martin Buchholz wrote:
> Looks good.
> I would only suggest the stylistic improvement of using proper /**
> javadoc comments even for private test methods instead of /*

The comments were meant as internal documentation and not "real" 
javadoc.  After dabbling with some doclint cleanup a while ago, I'm 
inclined now to only use /** if what I'm writing will be doclint-clean. 
  testItr(), for instance, would (at least) need @param tags and that's 
more than I thought was needed for this test code.

So that was the thinking there.

Thanks,
-Brent


From jan.lahoda at oracle.com  Thu Sep 26 18:09:06 2013
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Thu, 26 Sep 2013 18:09:06 +0000
Subject: hg: jdk8/tl/langtools: 8025491: Javac regression test
	tools/javac/T8003967/DetectMutableStaticFields.java failing
Message-ID: <20130926180910.8371762B1A@hg.openjdk.java.net>

Changeset: 9235ae08a449
Author:    jlahoda
Date:      2013-09-26 20:07 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9235ae08a449

8025491: Javac regression test tools/javac/T8003967/DetectMutableStaticFields.java failing
Summary: Making HtmlTree.NONENCODING_CHARS final
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java



From vicente.romero at oracle.com  Thu Sep 26 18:13:22 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 26 Sep 2013 18:13:22 +0000
Subject: hg: jdk8/tl/langtools: 8025139: javac patch for using bootstrap
	compiler for debugging is not working properly
Message-ID: <20130926181325.2903762B1B@hg.openjdk.java.net>

Changeset: 13eba2e322e6
Author:    vromero
Date:      2013-09-26 19:06 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/13eba2e322e6

8025139: javac patch for using bootstrap compiler for debugging is not working properly
Reviewed-by: jjg

! make/netbeans/langtools/build.xml
! make/tools/anttasks/SelectToolTask.java



From huizhe.wang at oracle.com  Thu Sep 26 18:46:54 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 26 Sep 2013 11:46:54 -0700
Subject: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH
	NODE LIST OF LENGTH =1 IN JAXP
In-Reply-To: <5242C4AE.4060305@oracle.com>
References: <5238449D.50509@oracle.com> <523B6A7D.3080501@oracle.com>
	<5242C4AE.4060305@oracle.com>
Message-ID: <5244811E.3040207@oracle.com>

Hi Aleksej,

 From your tests, it appears that the getLength() method was implemented 
correctly, and that the bug is not in the call to m_iter.next(), but it 
should not be called again once the count is > index.  So that fix would 
be to move the conditions around such that:
     public Node item(int index) {
         if (m_iter != null) {
             int node;
             int count = m_cachedNodes.size();

             if (count > index) {
                 node = m_cachedNodes.elementAt(index);
                 return m_dtm.getNode(node);
             } else if (m_last == -1) {
-                while (((node = m_iter.next()) != DTMAxisIterator.END)
-                           && count <= index) {
+                while (count <= index
+                           && ((node = m_iter.next()) != 
DTMAxisIterator.END)) {
                     m_cachedNodes.addElement(node);
                     count++;
                 }
                 if (node == DTMAxisIterator.END) {
                     m_last = count;
                 } else {
                     return m_dtm.getNode(node);
                 }
             }
         }
         return null;
     }

Thanks,
Joe


On 9/25/2013 4:10 AM, Aleksej Efimov wrote:
> Hi Joe,
> Your suggestion about getLength() brings to mine attention the 
> following behavior of unmodified JDK:
> If we slightly modify a TestFunc class [1] in such manner:
>
>     public static Node test( NodeList list ) {
>                  Node ret = list.item(0);
>                  System.err.println(list.getLength());
>                  return ret;
>     }
>
> And add more elements to in.xml:
> inp1_1inp1_2inp1_3
>
> The test will fails:
>
>     2
>     Transformation completed. Result:     encoding="UTF-8"?>inp1_2
>     Exception in thread "main" java.lang.RuntimeException: Incorrect
>     transformation result
>         at XSLT.main(XSLT.java:49)
>
> As you can see the length of 2 is incorrect value and the 'inp1_1' 
> element is ignored. But If we do another one change to test function - 
> first get the length() and then get the item:
>
>     public static Node test( NodeList list ) {
>     	    System.err.println(list.getLength());
>                  Node ret = list.item(0);
>                  return ret;
>     }
>
> The test will pass:
>
>     3
>     Transformation completed. Result:     encoding="UTF-8"?>inp1_1
>
> This behavior tells that item() method incorrectly caches the nodes 
> (The method called first - do the caching). But the caching of nodes 
> is done in correct way by getLength() function, but its according to 
> the test results. Currently, I'm trying to understand why it's working 
> in such way in a view of source code.
>
> -Aleksej
>
>
>
> [1] 
> http://cr.openjdk.java.net/~aefimov/8024707/jdk/test/javax/xml/jaxp/parsers/8024707/TestFunc.java 
> 
>
> On 09/20/2013 01:19 AM, huizhe wang wrote:
>> Hi Aleksej,
>>
>> Looks like the getLength() method has the same problem.
>>
>> Joe
>>
>> On 9/17/2013 5:01 AM, Aleksej Efimov wrote:
>>> Hi Everyone,
>>>
>>> There is a bug [1] in JAXP about transformation of one-item sized 
>>> node list:
>>> When the length of nodelist which is passed to a XSLT extension 
>>> function is 1, the node gotten from the node list becomes null.
>>> New test illustrates this issue [2]. Full webrev with proposed fix 
>>> can be found here: [3].
>>>
>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707
>>> [2] 
>>> http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java
>>> [3] http://cr.openjdk.java.net/~aefimov/8024707/
>>>
>>> Best regards,
>>> Aleksej
>>
>



From christian.thalinger at oracle.com  Thu Sep 26 18:50:05 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 11:50:05 -0700
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: <5243EED4.9030104@gmail.com>
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
Message-ID: <4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>


On Sep 26, 2013, at 1:22 AM, Peter Levart  wrote:

> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>> 
>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
>> Reviewed-by:
>> 
>> This is a race in MemberName's name and type getters.
>> 
>> MemberName's type field is of type Object so it can hold different objects when it gets filled in from the VM.  These types include String and Object[].  On the first invocation the current type if it's not MethodType gets converted to a MethodType.
>> 
>> There is a tiny window where some instanceof check have already been done on one thread and then another thread stores a MethodType.  The following checkcast then fails.
>> 
>> The fix is to make name and type volatile and do the conversion in a synchronized block.  This is okay because it's only done once.
>> 
>> src/share/classes/java/lang/invoke/MemberName.java
>> 
> 
> Hi Christian,
> 
> Wouldn't it be cleaner that instead of just casting and catching ClassCastException, the volatile field 'type' was 1st copied to a local variable and then an instanceof check + casting and returning performed on the local variable. This would avoid throwing ClassCastException even if it is performed only once per MemberName?

Not sure it would be cleaner; depends on the definition of "cleaner".  I had similar code as you describe before but I changed it to catch the exception.  If people have a strong opinion here I can change it back.

> 
> Regards, Peter
> 



From john.r.rose at oracle.com  Thu Sep 26 19:09:13 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 26 Sep 2013 12:09:13 -0700
Subject: RFR (M): 8024635: Caching MethodType's descriptor string improves
	lambda linkage performance
In-Reply-To: <52445F47.9030402@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
	<52389D14.2080606@oracle.com>
	
	<52445F47.9030402@oracle.com>
Message-ID: 

(Quick note on format:  I have changed the subject line to include the conventional bug number and size estimate.  The bug number makes it easier to track in mailers.)

On Sep 26, 2013, at 9:22 AM, Sergey Kuksenko  wrote:

> Hi All,
> 
> I updated fix.
> You may find it here
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.01/
> 
> See my comments and new webrev descition below
> 
> On 09/18/2013 12:59 AM, John Rose wrote:
>>>> We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well. 
>>> In case of small amount of such strings we will get a huge overhead from
>>> any kind of map.
>> I would expect O(10^1.5) memory references and branches.  Depends on what you mean by "huge".
> Sure. I think the question to use external map or field may be decided
> later when/if it will be needed.
> Just some statictics, I've collected on nashorn/octane benchmarks
> (statistics collected only for the single(first) benchmark iteration:
> mandreel: 514 unique strings, toMethodDescriptorString called 69047 times
> box2d: 560 unique strings, 34776 toMethodDescriptorString invocations.

Good data; thanks.

> 
>> Would there be any benefit from recording the original string from the constant pool?  The JVM path for this is SystemDictionary::find_method_handle_type, which makes an upcall to MethodHandleNatives.findMethodHandleType.  Currently only the ptypes and rtype are passed, but the JVM could also convert the internal Symbol to a java.lang.String and pass that also.  In that case, MT's created by JVM upcalls would be pre-equipped with descriptor strings.
>> 
>> This is probably worth an experiment, although it requires some JVM work.
> 
> I am definitely sure that we shouldn't do that.
> Right now caching desriptor strings is internal decision of MethodType.
> Otherwise it will make interfaces more complex.

Yes, I agree.  Also, it would only benefit the 514 calls which introduce unique strings, whereas your change helps the 69047 calls for descriptor strings.

>> I hope you get my overall point:  Hand optimizations have a continuing cost, related to obscuring the logical structure of the code.  The transforming engineer might make a mistake, and later maintaining engineers might also make mistakes.
>> 
>> https://blogs.oracle.com/jrose/entry/three_software_proverbs
> 
> And it doesn't mean that we should afraid any kind of optimization.
> Lucky positions - someone(or something) will optimize it for us. But
> sometimes JIT (even smart JIT) is not enough.

Sometimes.  When that happens we reluctantly hand-optimize our code.

> Let's back to the patch.construstors
> I decided not change original checkPType/checkRType code, except
> explicit Objects.requireNonNull. The problem here that we are creating
> new MethodType objects which are already exists, we have to create MT as
> a key for searching in the internedTable. Ratio between already exiting
> and new MethodTypes a quite huge.
> Here is some statistics I've collected on nashorn/octane benchmarks
> (statistics collected only for the single(first) benchmark iteration:
> 
> mandreel:
>  - 1739 unique MethodTypes,
>  - 878414 MethodType.makeImpl requests;
> box2d:
>  - 1861 unique MethodTypes,
>  - 527486 MethodType.makeImpl requests;
> gameboy:
>  - 2062 unique MethodTypes,
>  - 311378 MethodType.makeImpl requests;
> 
> So
> 1. MethodType constructor do checkPTypes/checkRType which are frequently
> (99%) useless - we already have the same (checked) MethodType in the
> internTable.
> 2. Less than 1% of created MethodTypes will be stored into internTable,
> but reusing that MethodType objects prevent ti from scalar replacement.
> (I've heard that Graal may do flow-sensitive scalar replacement, but C2
> can't do).
> 
> What I did. I separate constructors:
> - for long lived MethodTypes with all checks,
> - for short lived MethodTypes used only as key for searching in the
> InterTable, no checks are performed.
> if we didn't find  MethodType in the table we always create a new one
> (with checks) that is required in less than 1% cases. And we remove at
> least one obstacle for scalar replacement. Unfortunately, scalaer
> replacement for expression "internTable.get(new MethodType(rtype,
> ptypes))" was not performed, the reason may be evaluated, and hope it
> would be easier to achieve scalarization in this case.

Brilliant.  I love this.

The constructor signatures are too similar given the subtle difference between their semantics.  Please distort the signature of the extra-sensitive constructor.  (Imagine the wrong one accidentally invoked by helpful IDE code completers.)  Put in a leading int dummy argument, or reverse the parameters, or some similar hack.  (If we had named constructors, we'd hack the name instead.)  I admit this is of marginal benefit, since there is only one place where the constructors are called, but it's good style.  If there were more places calling the constructor, we'd absolutely want a clear distinction between checked and unchecked.

If it still makes sense, I wouldn't mind moving the slot-count logic (long/double adjustment) out of checkPType into checkPTypes.  But I think that's moot with this much better change.
-            slots += checkPtype(ptype);
+            checkPtype(ptype);
+            if (ptype == double.class || ptype == long.class) {
+                slots++;
+            }

Good work.  Reviewed.  (You need another reviewer, I think.)

? John

From christian.thalinger at oracle.com  Thu Sep 26 19:59:54 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 12:59:54 -0700
Subject: RFR: Caching MethodType's descriptor string improves lambda
	linkage performance
In-Reply-To: <52445F47.9030402@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
	<52389D14.2080606@oracle.com>
	
	<52445F47.9030402@oracle.com>
Message-ID: 


On Sep 26, 2013, at 9:22 AM, Sergey Kuksenko  wrote:

> Hi All,
> 
> I updated fix.
> You may find it here
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.01/

The change looks good.  Since we use Objects.requireNonNull now we can remove the null check comment:

+        Objects.requireNonNull(rtype);  // null check

> 
> See my comments and new webrev descition below
> 
> On 09/18/2013 12:59 AM, John Rose wrote:
>>>> We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well. 
>>> In case of small amount of such strings we will get a huge overhead from
>>> any kind of map.
>> I would expect O(10^1.5) memory references and branches.  Depends on what you mean by "huge".
> Sure. I think the question to use external map or field may be decided
> later when/if it will be needed.
> Just some statictics, I've collected on nashorn/octane benchmarks
> (statistics collected only for the single(first) benchmark iteration:
> mandreel: 514 unique strings, toMethodDescriptorString called 69047 times
> box2d: 560 unique strings, 34776 toMethodDescriptorString invocations.
> 
>> Would there be any benefit from recording the original string from the constant pool?  The JVM path for this is SystemDictionary::find_method_handle_type, which makes an upcall to MethodHandleNatives.findMethodHandleType.  Currently only the ptypes and rtype are passed, but the JVM could also convert the internal Symbol to a java.lang.String and pass that also.  In that case, MT's created by JVM upcalls would be pre-equipped with descriptor strings.
>> 
>> This is probably worth an experiment, although it requires some JVM work.
> 
> I am definitely sure that we shouldn't do that.
> Right now caching desriptor strings is internal decision of MethodType.
> Otherwise it will make interfaces more complex.
> 
>> I hope you get my overall point:  Hand optimizations have a continuing cost, related to obscuring the logical structure of the code.  The transforming engineer might make a mistake, and later maintaining engineers might also make mistakes.
>> 
>> https://blogs.oracle.com/jrose/entry/three_software_proverbs
> 
> And it doesn't mean that we should afraid any kind of optimization.
> Lucky positions - someone(or something) will optimize it for us. But
> sometimes JIT (even smart JIT) is not enough.
> 
> Let's back to the patch.construstors
> I decided not change original checkPType/checkRType code, except
> explicit Objects.requireNonNull. The problem here that we are creating
> new MethodType objects which are already exists, we have to create MT as
> a key for searching in the internedTable. Ratio between already exiting
> and new MethodTypes a quite huge.
> Here is some statistics I've collected on nashorn/octane benchmarks
> (statistics collected only for the single(first) benchmark iteration:
> 
> mandreel:
>  - 1739 unique MethodTypes,
>  - 878414 MethodType.makeImpl requests;
> box2d:
>  - 1861 unique MethodTypes,
>  - 527486 MethodType.makeImpl requests;
> gameboy:
>  - 2062 unique MethodTypes,
>  - 311378 MethodType.makeImpl requests;
> 
> So
> 1. MethodType constructor do checkPTypes/checkRType which are frequently
> (99%) useless - we already have the same (checked) MethodType in the
> internTable.
> 2. Less than 1% of created MethodTypes will be stored into internTable,
> but reusing that MethodType objects prevent ti from scalar replacement.
> (I've heard that Graal may do flow-sensitive scalar replacement, but C2
> can't do).
> 
> What I did. I separate constructors:
> - for long lived MethodTypes with all checks,
> - for short lived MethodTypes used only as key for searching in the
> InterTable, no checks are performed.
> if we didn't find  MethodType in the table we always create a new one
> (with checks) that is required in less than 1% cases. And we remove at
> least one obstacle for scalar replacement. Unfortunately, scalaer
> replacement for expression "internTable.get(new MethodType(rtype,
> ptypes))" was not performed, the reason may be evaluated, and hope it
> would be easier to achieve scalarization in this case.
> 
> 
> 
> 
> -- 
> Best regards,
> Sergey Kuksenko



From christian.thalinger at oracle.com  Thu Sep 26 20:13:24 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 13:13:24 -0700
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: <4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
	<4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
Message-ID: <4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>


On Sep 26, 2013, at 11:50 AM, Christian Thalinger  wrote:

> 
> On Sep 26, 2013, at 1:22 AM, Peter Levart  wrote:
> 
>> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
>>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>>> 
>>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
>>> Reviewed-by:
>>> 
>>> This is a race in MemberName's name and type getters.
>>> 
>>> MemberName's type field is of type Object so it can hold different objects when it gets filled in from the VM.  These types include String and Object[].  On the first invocation the current type if it's not MethodType gets converted to a MethodType.
>>> 
>>> There is a tiny window where some instanceof check have already been done on one thread and then another thread stores a MethodType.  The following checkcast then fails.
>>> 
>>> The fix is to make name and type volatile and do the conversion in a synchronized block.  This is okay because it's only done once.
>>> 
>>> src/share/classes/java/lang/invoke/MemberName.java
>>> 
>> 
>> Hi Christian,
>> 
>> Wouldn't it be cleaner that instead of just casting and catching ClassCastException, the volatile field 'type' was 1st copied to a local variable and then an instanceof check + casting and returning performed on the local variable. This would avoid throwing ClassCastException even if it is performed only once per MemberName?
> 
> Not sure it would be cleaner; depends on the definition of "cleaner".  I had similar code as you describe before but I changed it to catch the exception.  If people have a strong opinion here I can change it back.

Here are the two different versions:

http://cr.openjdk.java.net/~twisti/8019192/webrev.00/
http://cr.openjdk.java.net/~twisti/8019192/webrev.01/

> 
>> 
>> Regards, Peter
>> 
> 



From mandy.chung at oracle.com  Thu Sep 26 20:18:12 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Sep 2013 13:18:12 -0700
Subject: RFR: 8013839: Enhance Logger API for handling of resource bundles
In-Reply-To: <523C4097.10200@oracle.com>
References: <523C4097.10200@oracle.com>
Message-ID: <52449684.2080609@oracle.com>

Hi Daniel,

This is a good solution for Logger subclasses or existing apps that rely 
on the previous stack walk search to lookup a resource bundle.I have 
some comments on the specification:

Logger.setResourceBundle(ResourceBundle rb)
    Should this method simply throw NPE if rb == null since we can't 
reset a non-null rb/rbname to null?

Some suggestion to the javadoc:


   * Sets the resource bundle for this logger to use for localization.
   *
   * @param bundle  The resource bundle that this logger shall use.
   * @throws  IllegalArgumentException if the given bundle doesn't have a
   *         {@linkplain ResourceBundle#getBaseBundleName base name},
   *         or if this logger already has a resource bundle set but
   *         the given bundle has a different base name.


The getLogger(String name, String rbname) spec and the class specification
should be updated about different ways in setting a resource bundle for
a logger.

For example in the class spec, this paragraph and text following it talks
about resource bundle and name and also logrb method:

     Each Logger may have a ResourceBundle name associated with it.
     The named bundle will be used for localizing logging messages.
     If a Logger does not have its own ResourceBundle name, then
     it will inherit the ResourceBundle name from its parent,
     recursively up the tree.

Adding @see #setResourceBundle in the getLogger method would be helpful.

It'd be good to clarify the spec of getResourceBundle and getResourceBundleName
methods that they return the ResourceBundle and its base name if set via
setResourceBundle method.  Perhaps it might be good for the class spec
to capture different ways to set the resource bundle and and have the methods
to refer that specification.

The current implementation of the getLogger(String name, String rbname) method
uses the caller's class loader to look up the resource bundle.  Do you mind
taking this opportunity to update the spec to match the current implementation?
This fix is a follow-up on that change.

Maybe we should just use varargs (JDK-5001993) to replace the two
logrb methods one taking a single parameter and the other taking an
array of parameters:
     public void logrb(Level level, String sourceClass, String sourceMethod,
                       ResourceBundle bundle, String msg, Object... params)

I can live with the inconsistency.

ResourceBundle.getBaseBundleName - this is more a question to Naoto.

The implementation note about this method may return a pathname
but the spec states that it returns a fully qualified class name
is a bit strange.  Can you elaborate what problem we have here?
I am missing the context to connect how this is related to the
older versions of JRE

thanks
Mandy


On 9/20/2013 5:33 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8013839: Enhance Logger API for handling of resource bundles, and
> 4814565: (rb) add method to get basename from a ResourceBundle
>
> 
>
>    1. It adds a ResourceBundle.getBaseBundleName() method,
>    2. It adds a Logger.setResourceBundle(ResourceBundle) method,
>    3. It adds a series of Logger.logrb(...) that take a ResourceBundle
>         object instead of a ResourceBundle name.
>         The previous versions of Logger.logrb(...) that took a
>         resource bundle name are therefore no longer needed,
>         they offer no added value above the new methods, and
>         are thus now deprecated.
>
> Logger.getLogger(name, rbname) will continue to work as before,
>      and will also throw an exception if a RB with a different name
>      has been set before, either through setResourceBundle or
>      Logger.getLogger(name, rbname).
>
> Logger.setResourceBundle works similarly to
>      Logger.getLogger(name, rbname) in the sense that it will not
>      allow to replace an existing bundle, unless both have the same
>      name. Like for Logger.getLogger(name, rbname) - it doesn't matter
>      by which method the previous bundle has been set.
>
>      This is mostly for consistency of the API - if thread A has
>      requested a logger with resource bundle name 'foo.Bundle'
>      and thread B attempts to set the resource bundle of that
>      logger to 'bar.Bundle' then thread B will get an IAE.
>
>      The resource bundle passed to Logger.setResourceBundle *must*
>      have a base name. Note that ResourceBundle objects will have
>      a base name by default if they have been loaded through
>      one of the ResourceBundle.getBundle(...) methods;
>      If ResourceBundle.getBaseBundleName() returns null an IAE
>      will be thrown.
>
>      Logger.setResourceBundle requires the "control" permission.
>
>      When a resource bundle is set with Logger.setResourceBundle,
>      then it's that resource bundle locale that will be used
>      when logging (and not the default locale).
>
> I have written a set of unit tests which should cover all the points
> listed above.
>
> best regards,
>
> -- daniel



From mike.duigou at oracle.com  Thu Sep 26 20:42:58 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 26 Sep 2013 20:42:58 +0000
Subject: hg: jdk8/tl/jdk: 8025173: HashMap.put() replacing an existing key can
	trigger a resize()
Message-ID: <20130926204334.E7EF062B45@hg.openjdk.java.net>

Changeset: 8f27030686a6
Author:    bchristi
Date:      2013-09-26 11:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f27030686a6

8025173: HashMap.put() replacing an existing key can trigger a resize()
Summary: Ensure that HashMap is not resized if we're just replacing a value
Reviewed-by: alanb, martin

! src/share/classes/java/util/HashMap.java
+ test/java/util/HashMap/ReplaceExisting.java



From john.r.rose at oracle.com  Thu Sep 26 21:28:11 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 26 Sep 2013 14:28:11 -0700
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: <4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
	<4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
	<4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>
Message-ID: <207FA083-1CAE-4115-B154-D838E6A2E5D2@oracle.com>

On Sep 26, 2013, at 1:13 PM, Christian Thalinger  wrote:

> On Sep 26, 2013, at 11:50 AM, Christian Thalinger  wrote:
> 
>> 
>> On Sep 26, 2013, at 1:22 AM, Peter Levart  wrote:
>> 
>>> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
>>>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>>>> 
>>>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
>>>> Reviewed-by:
>>>> 
>>>> This is a race in MemberName's name and type getters.
>>>> 
>>>> MemberName's type field is of type Object so it can hold different objects when it gets filled in from the VM.  These types include String and Object[].  On the first invocation the current type if it's not MethodType gets converted to a MethodType.
>>>> 
>>>> There is a tiny window where some instanceof check have already been done on one thread and then another thread stores a MethodType.  The following checkcast then fails.
>>>> 
>>>> The fix is to make name and type volatile and do the conversion in a synchronized block.  This is okay because it's only done once.
>>>> 
>>>> src/share/classes/java/lang/invoke/MemberName.java
>>>> 
>>> 
>>> Hi Christian,
>>> 
>>> Wouldn't it be cleaner that instead of just casting and catching ClassCastException, the volatile field 'type' was 1st copied to a local variable and then an instanceof check + casting and returning performed on the local variable. This would avoid throwing ClassCastException even if it is performed only once per MemberName?
>> 
>> Not sure it would be cleaner; depends on the definition of "cleaner".  I had similar code as you describe before but I changed it to catch the exception.  If people have a strong opinion here I can change it back.
> 
> Here are the two different versions:
> 
> http://cr.openjdk.java.net/~twisti/8019192/webrev.00/
> http://cr.openjdk.java.net/~twisti/8019192/webrev.01/

I think the second version is better.  The first uses exception processing for normal (though rare) control flow, which is questionable style.

As we discussed offline, the fields do *not* need to be volatile, since the code in the synch. block will see an updated state without volatiles, and races outside the synch block are benign, leading to the same end-state.

Hoisting the field into a local is the best practice here.(***)  That's the hand we are dealt with the Java memory model.

Reviewed, with those adjustments.

? John

(***) P.S. This tickles one of my pet peeves.  A hoisted field value should have the same name (either approximately or exactly) as the field, as long as the difference is merely the sampling of a value which is not expected to change.  (As opposed to a clever saving of a field that is destined to be updated, etc.)

IDEs and purists may disagree with this, but it always sets my teeth on edge to see name changes that obscure consistency of values for the sake of some less interesting consistency (scope rules or rare state changes).

Is there at least some standard naming pattern for these things?  "typeSnapshot" doesn't do it for me.  "typeVal" is quieter; I prefer quieter.  Elsewhere in the same code I have defiantly used plain "type" with a shout-out to hostile IDEs, as with MethodHandle.bindTo or MethodHandle.asCollector.  Looking for a compromise...

(I also firmly believe that constructor parameter names are best named with the corresponding field names, even though quibblers of various species, IDE/human, note that there are distinctions to be made between them.  It is for the sake of this opinion of mine that blank finals can be initialized with the form 'this.foo = foo', which some dislike.)

But it's fine; push it!

From christian.thalinger at oracle.com  Thu Sep 26 21:46:56 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 14:46:56 -0700
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: <207FA083-1CAE-4115-B154-D838E6A2E5D2@oracle.com>
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
	<4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
	<4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>
	<207FA083-1CAE-4115-B154-D838E6A2E5D2@oracle.com>
Message-ID: <0FD1A213-B4D4-41FB-9F51-F2E36E4ACF4E@oracle.com>


On Sep 26, 2013, at 2:28 PM, John Rose  wrote:

> On Sep 26, 2013, at 1:13 PM, Christian Thalinger  wrote:
> 
>> On Sep 26, 2013, at 11:50 AM, Christian Thalinger  wrote:
>> 
>>> 
>>> On Sep 26, 2013, at 1:22 AM, Peter Levart  wrote:
>>> 
>>>> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
>>>>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>>>>> 
>>>>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
>>>>> Reviewed-by:
>>>>> 
>>>>> This is a race in MemberName's name and type getters.
>>>>> 
>>>>> MemberName's type field is of type Object so it can hold different objects when it gets filled in from the VM.  These types include String and Object[].  On the first invocation the current type if it's not MethodType gets converted to a MethodType.
>>>>> 
>>>>> There is a tiny window where some instanceof check have already been done on one thread and then another thread stores a MethodType.  The following checkcast then fails.
>>>>> 
>>>>> The fix is to make name and type volatile and do the conversion in a synchronized block.  This is okay because it's only done once.
>>>>> 
>>>>> src/share/classes/java/lang/invoke/MemberName.java
>>>>> 
>>>> 
>>>> Hi Christian,
>>>> 
>>>> Wouldn't it be cleaner that instead of just casting and catching ClassCastException, the volatile field 'type' was 1st copied to a local variable and then an instanceof check + casting and returning performed on the local variable. This would avoid throwing ClassCastException even if it is performed only once per MemberName?
>>> 
>>> Not sure it would be cleaner; depends on the definition of "cleaner".  I had similar code as you describe before but I changed it to catch the exception.  If people have a strong opinion here I can change it back.
>> 
>> Here are the two different versions:
>> 
>> http://cr.openjdk.java.net/~twisti/8019192/webrev.00/
>> http://cr.openjdk.java.net/~twisti/8019192/webrev.01/
> 
> I think the second version is better.  The first uses exception processing for normal (though rare) control flow, which is questionable style.
> 
> As we discussed offline, the fields do *not* need to be volatile, since the code in the synch. block will see an updated state without volatiles, and races outside the synch block are benign, leading to the same end-state.
> 
> Hoisting the field into a local is the best practice here.(***)  That's the hand we are dealt with the Java memory model.
> 
> Reviewed, with those adjustments.

?and there is the according webrev:

http://cr.openjdk.java.net/~twisti/8019192/webrev.02/

> 
> ? John
> 
> (***) P.S. This tickles one of my pet peeves.  A hoisted field value should have the same name (either approximately or exactly) as the field, as long as the difference is merely the sampling of a value which is not expected to change.  (As opposed to a clever saving of a field that is destined to be updated, etc.)
> 
> IDEs and purists may disagree with this, but it always sets my teeth on edge to see name changes that obscure consistency of values for the sake of some less interesting consistency (scope rules or rare state changes).

The problem I have with this is that some people might think the local variable is the instance field.  IDEs help here because they usually highlight local variables and instance fields in different colors.  How about this:

http://cr.openjdk.java.net/~twisti/8019192/webrev.03/

> 
> Is there at least some standard naming pattern for these things?  "typeSnapshot" doesn't do it for me.  "typeVal" is quieter; I prefer quieter.  Elsewhere in the same code I have defiantly used plain "type" with a shout-out to hostile IDEs, as with MethodHandle.bindTo or MethodHandle.asCollector.  Looking for a compromise...
> 
> (I also firmly believe that constructor parameter names are best named with the corresponding field names, even though quibblers of various species, IDE/human, note that there are distinctions to be made between them.  It is for the sake of this opinion of mine that blank finals can be initialized with the form 'this.foo = foo', which some dislike.)

I concur.  This is what I'm doing.

> 
> But it's fine; push it!



From sonali.goel at oracle.com  Thu Sep 26 22:04:53 2013
From: sonali.goel at oracle.com (sonali.goel at oracle.com)
Date: Thu, 26 Sep 2013 22:04:53 +0000
Subject: hg: jdk8/tl/langtools: 8011738: Write test to check for bootstrap
	attributes for lambda expressions in class file
Message-ID: <20130926220456.D269E62B48@hg.openjdk.java.net>

Changeset: 17653c4c22ec
Author:    sogoel
Date:      2013-09-26 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/17653c4c22ec

8011738: Write test to check for bootstrap attributes for lambda expressions in class file
Reviewed-by: mcimadamore

+ test/tools/javac/lambda/ByteCodeTest.java



From mandy.chung at oracle.com  Thu Sep 26 22:12:33 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Sep 2013 15:12:33 -0700
Subject: RFR (2nd): 8023524: Mechanism to dump generated lambda classes
	/ log lambda code generation
In-Reply-To: <52427B0A.6010004@gmail.com>
References: <523945CF.9060804@oracle.com> <523994D1.8090200@redhat.com>
	<523A307E.6080202@oracle.com> <523AA764.60301@redhat.com>
	<52420B31.2070703@oracle.com> <52427B0A.6010004@gmail.com>
Message-ID: <5244B151.1070802@oracle.com>

On 9/24/2013 10:56 PM, Peter Levart wrote:
> Just a thought. How does URLClassLoader do the class name -> path to
> resource translation? Perhaps there's already some code that does this
> correctly and in a platform-specific way (haven't looked)...

sun.misc.ParseUtil.encodePath

Mandy


From mandy.chung at oracle.com  Thu Sep 26 23:01:40 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Sep 2013 16:01:40 -0700
Subject: RFR (3rd): 8023524: Mechanism to dump generated lambda classes
	/ log lambda code generation
In-Reply-To: <524292AF.3020209@oracle.com>
References: <523945CF.9060804@oracle.com>
	<523994D1.8090200@redhat.com>	<523A307E.6080202@oracle.com>
	<523AA764.60301@redhat.com> <52420B31.2070703@oracle.com>
	<524292AF.3020209@oracle.com>
Message-ID: <5244BCD4.20002@oracle.com>

Hi Henry,

On 9/25/2013 12:37 AM, Henry Jen wrote:
> Hi,
>
> Please review the update webrev at
> http://cr.openjdk.java.net/~henryjen/ccc/8023524/2/webrev/

The doPrivileged block looks okay.  It'd be good to limit privileges
by calling the doPrivileged method with a specific set of Permissions.
In this case, it would be FilePermission("<>", "write").

If "jdk.internal.lambda.dumpProxyClasses" property is set with empty
value, would it be better to default to CWD?  ProxyClassesDumper currently
fails with non-existent directory.

ProxyClassesDumper - you may want to use java.nio.file.Path and
Files.  I also suggest to follow the convention of classfile pathname
and generate it in the directories reflecting the package name i.e.
   DIR/com/example/TestLambda$$Lambda$1.class

instead of DIR/com.example.TestLambda$$Lambda$1.class,

For escaping sequence, as Peter pointed out, I presume you can
consider using ParseUtil.encodePath but I am not sure how importance
it has to encode the path as this is for debugging purpose.
No strong opinion in this one.

Mandy



From vitalyd at gmail.com  Fri Sep 27 00:11:47 2013
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 26 Sep 2013 20:11:47 -0400
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: <0FD1A213-B4D4-41FB-9F51-F2E36E4ACF4E@oracle.com>
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
	<4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
	<4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>
	<207FA083-1CAE-4115-B154-D838E6A2E5D2@oracle.com>
	<0FD1A213-B4D4-41FB-9F51-F2E36E4ACF4E@oracle.com>
Message-ID: 

Chris,

Since you touched getName(), maybe get rid of that superfluous null check
after expandFromVM? The code can just fall through.

Vitaly

Sent from my phone
On Sep 26, 2013 5:47 PM, "Christian Thalinger" <
christian.thalinger at oracle.com> wrote:

>
> On Sep 26, 2013, at 2:28 PM, John Rose  wrote:
>
> > On Sep 26, 2013, at 1:13 PM, Christian Thalinger <
> christian.thalinger at oracle.com> wrote:
> >
> >> On Sep 26, 2013, at 11:50 AM, Christian Thalinger <
> christian.thalinger at oracle.com> wrote:
> >>
> >>>
> >>> On Sep 26, 2013, at 1:22 AM, Peter Levart 
> wrote:
> >>>
> >>>> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
> >>>>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
> >>>>>
> >>>>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
> >>>>> Reviewed-by:
> >>>>>
> >>>>> This is a race in MemberName's name and type getters.
> >>>>>
> >>>>> MemberName's type field is of type Object so it can hold different
> objects when it gets filled in from the VM.  These types include String and
> Object[].  On the first invocation the current type if it's not MethodType
> gets converted to a MethodType.
> >>>>>
> >>>>> There is a tiny window where some instanceof check have already been
> done on one thread and then another thread stores a MethodType.  The
> following checkcast then fails.
> >>>>>
> >>>>> The fix is to make name and type volatile and do the conversion in a
> synchronized block.  This is okay because it's only done once.
> >>>>>
> >>>>> src/share/classes/java/lang/invoke/MemberName.java
> >>>>>
> >>>>
> >>>> Hi Christian,
> >>>>
> >>>> Wouldn't it be cleaner that instead of just casting and catching
> ClassCastException, the volatile field 'type' was 1st copied to a local
> variable and then an instanceof check + casting and returning performed on
> the local variable. This would avoid throwing ClassCastException even if it
> is performed only once per MemberName?
> >>>
> >>> Not sure it would be cleaner; depends on the definition of "cleaner".
>  I had similar code as you describe before but I changed it to catch the
> exception.  If people have a strong opinion here I can change it back.
> >>
> >> Here are the two different versions:
> >>
> >> http://cr.openjdk.java.net/~twisti/8019192/webrev.00/
> >> http://cr.openjdk.java.net/~twisti/8019192/webrev.01/
> >
> > I think the second version is better.  The first uses exception
> processing for normal (though rare) control flow, which is questionable
> style.
> >
> > As we discussed offline, the fields do *not* need to be volatile, since
> the code in the synch. block will see an updated state without volatiles,
> and races outside the synch block are benign, leading to the same end-state.
> >
> > Hoisting the field into a local is the best practice here.(***)  That's
> the hand we are dealt with the Java memory model.
> >
> > Reviewed, with those adjustments.
>
> ?and there is the according webrev:
>
> http://cr.openjdk.java.net/~twisti/8019192/webrev.02/
>
> >
> > ? John
> >
> > (***) P.S. This tickles one of my pet peeves.  A hoisted field value
> should have the same name (either approximately or exactly) as the field,
> as long as the difference is merely the sampling of a value which is not
> expected to change.  (As opposed to a clever saving of a field that is
> destined to be updated, etc.)
> >
> > IDEs and purists may disagree with this, but it always sets my teeth on
> edge to see name changes that obscure consistency of values for the sake of
> some less interesting consistency (scope rules or rare state changes).
>
> The problem I have with this is that some people might think the local
> variable is the instance field.  IDEs help here because they usually
> highlight local variables and instance fields in different colors.  How
> about this:
>
> http://cr.openjdk.java.net/~twisti/8019192/webrev.03/
>
> >
> > Is there at least some standard naming pattern for these things?
>  "typeSnapshot" doesn't do it for me.  "typeVal" is quieter; I prefer
> quieter.  Elsewhere in the same code I have defiantly used plain "type"
> with a shout-out to hostile IDEs, as with MethodHandle.bindTo or
> MethodHandle.asCollector.  Looking for a compromise...
> >
> > (I also firmly believe that constructor parameter names are best named
> with the corresponding field names, even though quibblers of various
> species, IDE/human, note that there are distinctions to be made between
> them.  It is for the sake of this opinion of mine that blank finals can be
> initialized with the form 'this.foo = foo', which some dislike.)
>
> I concur.  This is what I'm doing.
>
> >
> > But it's fine; push it!
>
>


From christian.thalinger at oracle.com  Fri Sep 27 00:15:48 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 17:15:48 -0700
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: 
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
	<4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
	<4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>
	<207FA083-1CAE-4115-B154-D838E6A2E5D2@oracle.com>
	<0FD1A213-B4D4-41FB-9F51-F2E36E4ACF4E@oracle.com>
	
Message-ID: <3C1C7300-546A-4752-ACF9-455A6F04F0AD@oracle.com>


On Sep 26, 2013, at 5:11 PM, Vitaly Davidovich  wrote:

> Chris,
> 
> Since you touched getName(), maybe get rid of that superfluous null check after expandFromVM? The code can just fall through.
> 
> 

Was thinking about removing it and already had it but backed of because I wanted to keep the pattern if someone adds code to that method in the future.  The compiler will optimize it anyway.
> Vitaly
> 
> Sent from my phone
> 
> On Sep 26, 2013 5:47 PM, "Christian Thalinger"  wrote:
> 
> On Sep 26, 2013, at 2:28 PM, John Rose  wrote:
> 
> > On Sep 26, 2013, at 1:13 PM, Christian Thalinger  wrote:
> >
> >> On Sep 26, 2013, at 11:50 AM, Christian Thalinger  wrote:
> >>
> >>>
> >>> On Sep 26, 2013, at 1:22 AM, Peter Levart  wrote:
> >>>
> >>>> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
> >>>>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
> >>>>>
> >>>>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
> >>>>> Reviewed-by:
> >>>>>
> >>>>> This is a race in MemberName's name and type getters.
> >>>>>
> >>>>> MemberName's type field is of type Object so it can hold different objects when it gets filled in from the VM.  These types include String and Object[].  On the first invocation the current type if it's not MethodType gets converted to a MethodType.
> >>>>>
> >>>>> There is a tiny window where some instanceof check have already been done on one thread and then another thread stores a MethodType.  The following checkcast then fails.
> >>>>>
> >>>>> The fix is to make name and type volatile and do the conversion in a synchronized block.  This is okay because it's only done once.
> >>>>>
> >>>>> src/share/classes/java/lang/invoke/MemberName.java
> >>>>>
> >>>>
> >>>> Hi Christian,
> >>>>
> >>>> Wouldn't it be cleaner that instead of just casting and catching ClassCastException, the volatile field 'type' was 1st copied to a local variable and then an instanceof check + casting and returning performed on the local variable. This would avoid throwing ClassCastException even if it is performed only once per MemberName?
> >>>
> >>> Not sure it would be cleaner; depends on the definition of "cleaner".  I had similar code as you describe before but I changed it to catch the exception.  If people have a strong opinion here I can change it back.
> >>
> >> Here are the two different versions:
> >>
> >> http://cr.openjdk.java.net/~twisti/8019192/webrev.00/
> >> http://cr.openjdk.java.net/~twisti/8019192/webrev.01/
> >
> > I think the second version is better.  The first uses exception processing for normal (though rare) control flow, which is questionable style.
> >
> > As we discussed offline, the fields do *not* need to be volatile, since the code in the synch. block will see an updated state without volatiles, and races outside the synch block are benign, leading to the same end-state.
> >
> > Hoisting the field into a local is the best practice here.(***)  That's the hand we are dealt with the Java memory model.
> >
> > Reviewed, with those adjustments.
> 
> ?and there is the according webrev:
> 
> http://cr.openjdk.java.net/~twisti/8019192/webrev.02/
> 
> >
> > ? John
> >
> > (***) P.S. This tickles one of my pet peeves.  A hoisted field value should have the same name (either approximately or exactly) as the field, as long as the difference is merely the sampling of a value which is not expected to change.  (As opposed to a clever saving of a field that is destined to be updated, etc.)
> >
> > IDEs and purists may disagree with this, but it always sets my teeth on edge to see name changes that obscure consistency of values for the sake of some less interesting consistency (scope rules or rare state changes).
> 
> The problem I have with this is that some people might think the local variable is the instance field.  IDEs help here because they usually highlight local variables and instance fields in different colors.  How about this:
> 
> http://cr.openjdk.java.net/~twisti/8019192/webrev.03/
> 
> >
> > Is there at least some standard naming pattern for these things?  "typeSnapshot" doesn't do it for me.  "typeVal" is quieter; I prefer quieter.  Elsewhere in the same code I have defiantly used plain "type" with a shout-out to hostile IDEs, as with MethodHandle.bindTo or MethodHandle.asCollector.  Looking for a compromise...
> >
> > (I also firmly believe that constructor parameter names are best named with the corresponding field names, even though quibblers of various species, IDE/human, note that there are distinctions to be made between them.  It is for the sake of this opinion of mine that blank finals can be initialized with the form 'this.foo = foo', which some dislike.)
> 
> I concur.  This is what I'm doing.
> 
> >
> > But it's fine; push it!
> 



From martinrb at google.com  Fri Sep 27 00:16:50 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 26 Sep 2013 17:16:50 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
In-Reply-To: <52447430.9070300@oracle.com>
References: <5243616F.1000006@oracle.com>
	
	<52447430.9070300@oracle.com>
Message-ID: 

Yes, I see your problem.  It's one we have in jsr166 development as well.

We would like to use javadoc style, and have the javadoc tool warn us of
"real bugs" in our javadoc (even private methods) BUT we don't want javadoc
to enforce the same high standards for public methods, e.g. don't require
all of the @param for type parameters.

I think javadoc's current increased level of warning will have the
unintended consequence of causing users to revert to /* comments.
I would disable the more controversial ones by default.


On Thu, Sep 26, 2013 at 10:51 AM, Brent Christian <
brent.christian at oracle.com> wrote:

> On 9/25/13 4:03 PM, Martin Buchholz wrote:
>
>> Looks good.
>> I would only suggest the stylistic improvement of using proper /**
>> javadoc comments even for private test methods instead of /*
>>
>
> The comments were meant as internal documentation and not "real" javadoc.
>  After dabbling with some doclint cleanup a while ago, I'm inclined now to
> only use /** if what I'm writing will be doclint-clean.  testItr(), for
> instance, would (at least) need @param tags and that's more than I thought
> was needed for this test code.
>
> So that was the thinking there.
>
> Thanks,
> -Brent
>


From vitalyd at gmail.com  Fri Sep 27 00:24:04 2013
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 26 Sep 2013 20:24:04 -0400
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: <3C1C7300-546A-4752-ACF9-455A6F04F0AD@oracle.com>
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
	<4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
	<4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>
	<207FA083-1CAE-4115-B154-D838E6A2E5D2@oracle.com>
	<0FD1A213-B4D4-41FB-9F51-F2E36E4ACF4E@oracle.com>
	
	<3C1C7300-546A-4752-ACF9-455A6F04F0AD@oracle.com>
Message-ID: 

Why not add the required code when/if it's actually needed? It's not like
the pattern is tricky :) your call of course, just looks odd as-is.

Sent from my phone
On Sep 26, 2013 8:15 PM, "Christian Thalinger" <
christian.thalinger at oracle.com> wrote:

>
> On Sep 26, 2013, at 5:11 PM, Vitaly Davidovich  wrote:
>
> Chris,
>
> Since you touched getName(), maybe get rid of that superfluous null check
> after expandFromVM? The code can just fall through.
>
>
> Was thinking about removing it and already had it but backed of because I
> wanted to keep the pattern if someone adds code to that method in the
> future.  The compiler will optimize it anyway.
>
> Vitaly
>
> Sent from my phone
> On Sep 26, 2013 5:47 PM, "Christian Thalinger" <
> christian.thalinger at oracle.com> wrote:
>
>>
>> On Sep 26, 2013, at 2:28 PM, John Rose  wrote:
>>
>> > On Sep 26, 2013, at 1:13 PM, Christian Thalinger <
>> christian.thalinger at oracle.com> wrote:
>> >
>> >> On Sep 26, 2013, at 11:50 AM, Christian Thalinger <
>> christian.thalinger at oracle.com> wrote:
>> >>
>> >>>
>> >>> On Sep 26, 2013, at 1:22 AM, Peter Levart 
>> wrote:
>> >>>
>> >>>> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
>> >>>>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>> >>>>>
>> >>>>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
>> >>>>> Reviewed-by:
>> >>>>>
>> >>>>> This is a race in MemberName's name and type getters.
>> >>>>>
>> >>>>> MemberName's type field is of type Object so it can hold different
>> objects when it gets filled in from the VM.  These types include String and
>> Object[].  On the first invocation the current type if it's not MethodType
>> gets converted to a MethodType.
>> >>>>>
>> >>>>> There is a tiny window where some instanceof check have already
>> been done on one thread and then another thread stores a MethodType.  The
>> following checkcast then fails.
>> >>>>>
>> >>>>> The fix is to make name and type volatile and do the conversion in
>> a synchronized block.  This is okay because it's only done once.
>> >>>>>
>> >>>>> src/share/classes/java/lang/invoke/MemberName.java
>> >>>>>
>> >>>>
>> >>>> Hi Christian,
>> >>>>
>> >>>> Wouldn't it be cleaner that instead of just casting and catching
>> ClassCastException, the volatile field 'type' was 1st copied to a local
>> variable and then an instanceof check + casting and returning performed on
>> the local variable. This would avoid throwing ClassCastException even if it
>> is performed only once per MemberName?
>> >>>
>> >>> Not sure it would be cleaner; depends on the definition of "cleaner".
>>  I had similar code as you describe before but I changed it to catch the
>> exception.  If people have a strong opinion here I can change it back.
>> >>
>> >> Here are the two different versions:
>> >>
>> >> http://cr.openjdk.java.net/~twisti/8019192/webrev.00/
>> >> http://cr.openjdk.java.net/~twisti/8019192/webrev.01/
>> >
>> > I think the second version is better.  The first uses exception
>> processing for normal (though rare) control flow, which is questionable
>> style.
>> >
>> > As we discussed offline, the fields do *not* need to be volatile, since
>> the code in the synch. block will see an updated state without volatiles,
>> and races outside the synch block are benign, leading to the same end-state.
>> >
>> > Hoisting the field into a local is the best practice here.(***)  That's
>> the hand we are dealt with the Java memory model.
>> >
>> > Reviewed, with those adjustments.
>>
>> ?and there is the according webrev:
>>
>> http://cr.openjdk.java.net/~twisti/8019192/webrev.02/
>>
>> >
>> > ? John
>> >
>> > (***) P.S. This tickles one of my pet peeves.  A hoisted field value
>> should have the same name (either approximately or exactly) as the field,
>> as long as the difference is merely the sampling of a value which is not
>> expected to change.  (As opposed to a clever saving of a field that is
>> destined to be updated, etc.)
>> >
>> > IDEs and purists may disagree with this, but it always sets my teeth on
>> edge to see name changes that obscure consistency of values for the sake of
>> some less interesting consistency (scope rules or rare state changes).
>>
>> The problem I have with this is that some people might think the local
>> variable is the instance field.  IDEs help here because they usually
>> highlight local variables and instance fields in different colors.  How
>> about this:
>>
>> http://cr.openjdk.java.net/~twisti/8019192/webrev.03/
>>
>> >
>> > Is there at least some standard naming pattern for these things?
>>  "typeSnapshot" doesn't do it for me.  "typeVal" is quieter; I prefer
>> quieter.  Elsewhere in the same code I have defiantly used plain "type"
>> with a shout-out to hostile IDEs, as with MethodHandle.bindTo or
>> MethodHandle.asCollector.  Looking for a compromise...
>> >
>> > (I also firmly believe that constructor parameter names are best named
>> with the corresponding field names, even though quibblers of various
>> species, IDE/human, note that there are distinctions to be made between
>> them.  It is for the sake of this opinion of mine that blank finals can be
>> initialized with the form 'this.foo = foo', which some dislike.)
>>
>> I concur.  This is what I'm doing.
>>
>> >
>> > But it's fine; push it!
>>
>>
>


From john.r.rose at oracle.com  Fri Sep 27 00:36:45 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 26 Sep 2013 17:36:45 -0700
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: <0FD1A213-B4D4-41FB-9F51-F2E36E4ACF4E@oracle.com>
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
	<4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
	<4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>
	<207FA083-1CAE-4115-B154-D838E6A2E5D2@oracle.com>
	<0FD1A213-B4D4-41FB-9F51-F2E36E4ACF4E@oracle.com>
Message-ID: 

On Sep 26, 2013, at 2:46 PM, Christian Thalinger  wrote:

> The problem I have with this is that some people might think the local variable is the instance field.  IDEs help here because they usually highlight local variables and instance fields in different colors.  How about this:
> 
> http://cr.openjdk.java.net/~twisti/8019192/webrev.03/

Yes, that's good.  Thanks for untangling this.  Ship it.

(I also tried the "final" keyword on the hoisted guy, and NetBeans was still picky about it.)

? John

From jonathan.gibbons at oracle.com  Fri Sep 27 00:45:21 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 26 Sep 2013 17:45:21 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
In-Reply-To: 
References: <5243616F.1000006@oracle.com>		<52447430.9070300@oracle.com>
	
Message-ID: <5244D521.1080809@oracle.com>

The new diagnostics are generated by the new doclint feature which is 
available from the javac and javadoc command lines.

When invoked from javadoc, it only checks the comments being used for 
the docs that you are generating. So, if you are generating docs for 
just your public and protected methods, doclint will not (or should not) 
warn about your package-private and private methods.  The decision of 
which doc comments to check comes from the standard javadoc command line 
options used to select the elements to document, i.e. -private, 
-package, -protected, -public.

When invoked from javac, you actually have somewhat more versatility. 
The -Xdoclint command line option for javac actually allows you to 
specify different access levels for different types of check, so you 
could check syntax errors for all comments but only check for missing 
comments on public and protected elements.

With respect to your specific comments, I wonder if there is a typo in 
your message, because it doesn't quite make sense as written:

> We would like to use javadoc style, and have the javadoc tool warn us 
> of "real bugs" in our javadoc (even private methods) BUT we don't want 
> javadoc to enforce the same high standards for public methods, e.g. 
> don't require all of the @param for type parameters.

The word "public" in "the same high standards for public methods" makes 
more sense to me if you meant "private" here.  Which did you really mean?

-- Jon


On 09/26/2013 05:16 PM, Martin Buchholz wrote:
> Yes, I see your problem.  It's one we have in jsr166 development as well.
>
> We would like to use javadoc style, and have the javadoc tool warn us 
> of "real bugs" in our javadoc (even private methods) BUT we don't want 
> javadoc to enforce the same high standards for public methods, e.g. 
> don't require all of the @param for type parameters.
>
> I think javadoc's current increased level of warning will have the 
> unintended consequence of causing users to revert to /* comments.
> I would disable the more controversial ones by default.
>
>
> On Thu, Sep 26, 2013 at 10:51 AM, Brent Christian 
> > wrote:
>
>     On 9/25/13 4:03 PM, Martin Buchholz wrote:
>
>         Looks good.
>         I would only suggest the stylistic improvement of using proper /**
>         javadoc comments even for private test methods instead of /*
>
>
>     The comments were meant as internal documentation and not "real"
>     javadoc.  After dabbling with some doclint cleanup a while ago,
>     I'm inclined now to only use /** if what I'm writing will be
>     doclint-clean.  testItr(), for instance, would (at least) need
>     @param tags and that's more than I thought was needed for this
>     test code.
>
>     So that was the thinking there.
>
>     Thanks,
>     -Brent
>
>



From christian.thalinger at oracle.com  Fri Sep 27 00:49:30 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 17:49:30 -0700
Subject: RFR (S): 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
In-Reply-To: 
References: <0F5AFA91-3CBA-4441-90FA-F6220D7F841B@oracle.com>
	<5243EED4.9030104@gmail.com>
	<4E8A41B1-4315-4B29-899E-7F8FCC598913@oracle.com>
	<4283240B-366C-4D22-93A7-5DFD57903BEC@oracle.com>
	<207FA083-1CAE-4115-B154-D838E6A2E5D2@oracle.com>
	<0FD1A213-B4D4-41FB-9F51-F2E36E4ACF4E@oracle.com>
	
	<3C1C7300-546A-4752-ACF9-455A6F04F0AD@oracle.com>
	
Message-ID: <331F8341-65BD-4E9F-A331-3E2192B70660@oracle.com>


On Sep 26, 2013, at 5:24 PM, Vitaly Davidovich  wrote:

> Why not add the required code when/if it's actually needed? It's not like the pattern is tricky :)
> 
Of course the pattern is not tricky.  The fact that expandFromVM calls down into the VM which is filling in fields and name can actually be null is the tricky part.  Someone down the line in 5 years might not know about this conversation and be surprised.
> your call of course, just looks odd as-is.
> 
> Sent from my phone
> 
> On Sep 26, 2013 8:15 PM, "Christian Thalinger"  wrote:
> 
> On Sep 26, 2013, at 5:11 PM, Vitaly Davidovich  wrote:
> 
>> Chris,
>> 
>> Since you touched getName(), maybe get rid of that superfluous null check after expandFromVM? The code can just fall through.
>> 
>> 
> 
> Was thinking about removing it and already had it but backed of because I wanted to keep the pattern if someone adds code to that method in the future.  The compiler will optimize it anyway.
>> Vitaly
>> 
>> Sent from my phone
>> 
>> On Sep 26, 2013 5:47 PM, "Christian Thalinger"  wrote:
>> 
>> On Sep 26, 2013, at 2:28 PM, John Rose  wrote:
>> 
>> > On Sep 26, 2013, at 1:13 PM, Christian Thalinger  wrote:
>> >
>> >> On Sep 26, 2013, at 11:50 AM, Christian Thalinger  wrote:
>> >>
>> >>>
>> >>> On Sep 26, 2013, at 1:22 AM, Peter Levart  wrote:
>> >>>
>> >>>> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
>> >>>>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>> >>>>>
>> >>>>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
>> >>>>> Reviewed-by:
>> >>>>>
>> >>>>> This is a race in MemberName's name and type getters.
>> >>>>>
>> >>>>> MemberName's type field is of type Object so it can hold different objects when it gets filled in from the VM.  These types include String and Object[].  On the first invocation the current type if it's not MethodType gets converted to a MethodType.
>> >>>>>
>> >>>>> There is a tiny window where some instanceof check have already been done on one thread and then another thread stores a MethodType.  The following checkcast then fails.
>> >>>>>
>> >>>>> The fix is to make name and type volatile and do the conversion in a synchronized block.  This is okay because it's only done once.
>> >>>>>
>> >>>>> src/share/classes/java/lang/invoke/MemberName.java
>> >>>>>
>> >>>>
>> >>>> Hi Christian,
>> >>>>
>> >>>> Wouldn't it be cleaner that instead of just casting and catching ClassCastException, the volatile field 'type' was 1st copied to a local variable and then an instanceof check + casting and returning performed on the local variable. This would avoid throwing ClassCastException even if it is performed only once per MemberName?
>> >>>
>> >>> Not sure it would be cleaner; depends on the definition of "cleaner".  I had similar code as you describe before but I changed it to catch the exception.  If people have a strong opinion here I can change it back.
>> >>
>> >> Here are the two different versions:
>> >>
>> >> http://cr.openjdk.java.net/~twisti/8019192/webrev.00/
>> >> http://cr.openjdk.java.net/~twisti/8019192/webrev.01/
>> >
>> > I think the second version is better.  The first uses exception processing for normal (though rare) control flow, which is questionable style.
>> >
>> > As we discussed offline, the fields do *not* need to be volatile, since the code in the synch. block will see an updated state without volatiles, and races outside the synch block are benign, leading to the same end-state.
>> >
>> > Hoisting the field into a local is the best practice here.(***)  That's the hand we are dealt with the Java memory model.
>> >
>> > Reviewed, with those adjustments.
>> 
>> ?and there is the according webrev:
>> 
>> http://cr.openjdk.java.net/~twisti/8019192/webrev.02/
>> 
>> >
>> > ? John
>> >
>> > (***) P.S. This tickles one of my pet peeves.  A hoisted field value should have the same name (either approximately or exactly) as the field, as long as the difference is merely the sampling of a value which is not expected to change.  (As opposed to a clever saving of a field that is destined to be updated, etc.)
>> >
>> > IDEs and purists may disagree with this, but it always sets my teeth on edge to see name changes that obscure consistency of values for the sake of some less interesting consistency (scope rules or rare state changes).
>> 
>> The problem I have with this is that some people might think the local variable is the instance field.  IDEs help here because they usually highlight local variables and instance fields in different colors.  How about this:
>> 
>> http://cr.openjdk.java.net/~twisti/8019192/webrev.03/
>> 
>> >
>> > Is there at least some standard naming pattern for these things?  "typeSnapshot" doesn't do it for me.  "typeVal" is quieter; I prefer quieter.  Elsewhere in the same code I have defiantly used plain "type" with a shout-out to hostile IDEs, as with MethodHandle.bindTo or MethodHandle.asCollector.  Looking for a compromise...
>> >
>> > (I also firmly believe that constructor parameter names are best named with the corresponding field names, even though quibblers of various species, IDE/human, note that there are distinctions to be made between them.  It is for the sake of this opinion of mine that blank finals can be initialized with the form 'this.foo = foo', which some dislike.)
>> 
>> I concur.  This is what I'm doing.
>> 
>> >
>> > But it's fine; push it!
>> 
> 



From martinrb at google.com  Fri Sep 27 01:00:24 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 26 Sep 2013 18:00:24 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
In-Reply-To: <5244D521.1080809@oracle.com>
References: <5243616F.1000006@oracle.com>
	
	<52447430.9070300@oracle.com>
	
	<5244D521.1080809@oracle.com>
Message-ID: 

On Thu, Sep 26, 2013 at 5:45 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>  The new diagnostics are generated by the new doclint feature which is
> available from the javac and javadoc command lines.
>
> When invoked from javadoc, it only checks the comments being used for the
> docs that you are generating. So, if you are generating docs for just your
> public and protected methods, doclint will not (or should not) warn about
> your package-private and private methods.  The decision of which doc
> comments to check comes from the standard javadoc command line options used
> to select the elements to document, i.e. -private, -package, -protected,
> -public.
>
> When invoked from javac, you actually have somewhat more versatility. The
> -Xdoclint command line option for javac actually allows you to specify
> different access levels for different types of check, so you could check
> syntax errors for all comments but only check for missing comments on
> public and protected elements.
>
> With respect to your specific comments, I wonder if there is a typo in
> your message, because it doesn't quite make sense as written:
>
>
> We would like to use javadoc style, and have the javadoc tool warn us of
> "real bugs" in our javadoc (even private methods) BUT we don't want javadoc
> to enforce the same high standards for public methods, e.g. don't require
> all of the @param for type parameters.
>
>
> The word "public" in "the same high standards for public methods" makes
> more sense to me if you meant "private" here.  Which did you really mean?
>

I really meant  "BUT we don't want javadoc, when run against private
methods, to enforce the same high standards as for public methods"

E.g. for maintainers, adding @param or @returns (or @SuppressWarnings) to
the method below is not an improvement.

    /**
     * Returns the trigger time of a delayed action.
     */
    private long triggerTime(long delay, TimeUnit unit) {
        return triggerTime(unit.toNanos((delay < 0) ? 0 : delay));
    }


From jonathan.gibbons at oracle.com  Fri Sep 27 01:07:18 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 26 Sep 2013 18:07:18 -0700
Subject: RFR 8025173 : HashMap.put() replacing an existing key can trigger
	a resize()
In-Reply-To: 
References: <5243616F.1000006@oracle.com>		<52447430.9070300@oracle.com>		<5244D521.1080809@oracle.com>
	
Message-ID: <5244DA46.5000507@oracle.com>

On 09/26/2013 06:00 PM, Martin Buchholz wrote:
>
>
>
> On Thu, Sep 26, 2013 at 5:45 PM, Jonathan Gibbons 
> > wrote:
>
>     The new diagnostics are generated by the new doclint feature which
>     is available from the javac and javadoc command lines.
>
>     When invoked from javadoc, it only checks the comments being used
>     for the docs that you are generating. So, if you are generating
>     docs for just your public and protected methods, doclint will not
>     (or should not) warn about your package-private and private
>     methods. The decision of which doc comments to check comes from
>     the standard javadoc command line options used to select the
>     elements to document, i.e. -private, -package, -protected, -public.
>
>     When invoked from javac, you actually have somewhat more
>     versatility. The -Xdoclint command line option for javac actually
>     allows you to specify different access levels for different types
>     of check, so you could check syntax errors for all comments but
>     only check for missing comments on public and protected elements.
>
>     With respect to your specific comments, I wonder if there is a
>     typo in your message, because it doesn't quite make sense as written:
>
>
>>     We would like to use javadoc style, and have the javadoc tool
>>     warn us of "real bugs" in our javadoc (even private methods) BUT
>>     we don't want javadoc to enforce the same high standards for
>>     public methods, e.g. don't require all of the @param for type
>>     parameters.
>
>     The word "public" in "the same high standards for public methods"
>     makes more sense to me if you meant "private" here.  Which did you
>     really mean?
>
>
> I really meant  "BUT we don't want javadoc, when run against private 
> methods, to enforce the same high standards as for public methods"
>
> E.g. for maintainers, adding @param or @returns (or @SuppressWarnings) 
> to the method below is not an improvement.
>
>     /**
>      * Returns the trigger time of a delayed action.
>      */
>     private long triggerTime(long delay, TimeUnit unit) {
>         return triggerTime(unit.toNanos((delay < 0) ? 0 : delay));
>     }
>

Martin,

OK, yes, that is more what I was expecting you meant. We ran across 
exactly the same situation when applying doclint to our own code.

If you invoke doclint from javac, you should have the flexibility you 
are looking for in the -Xdoclint option and its suboptions. You can set 
a high standard for public and protected methods, and a lower standard 
(or no standard) for private and package-private methods.

-- Jon




From christian.thalinger at oracle.com  Fri Sep 27 01:22:36 2013
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Fri, 27 Sep 2013 01:22:36 +0000
Subject: hg: jdk8/tl/jdk: 8019192: StringIndexOutOfBoundsException: in
	Class.getSimpleName()
Message-ID: <20130927012257.E05CA62B50@hg.openjdk.java.net>

Changeset: 78b4dc33e6e6
Author:    twisti
Date:      2013-09-26 18:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78b4dc33e6e6

8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/MemberName.java



From christian.thalinger at oracle.com  Fri Sep 27 01:52:01 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 18:52:01 -0700
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
	
	<9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>
	
Message-ID: <70118D67-B367-461B-A4F2-04B2FB18047D@oracle.com>


On Sep 19, 2013, at 9:57 AM, David Chase  wrote:

> Recommended changes made:
> 
> http://cr.openjdk.java.net/~drchase/8022701/webrev.04/

Looks good.  Thanks for using ASM.

> 
> Test with jtreg (for pass and for induced failure) on MacOS,
> not sure what additional other testing is desired since it is entirely in the libraries.
> 
> I included code to handle the case of a broken field-referencing methodhandle,
> but did not test it because there's no syntax for these in Java, nor is their creation
> well-documented.
> 
> David
> 
> 
> On 2013-09-13, at 12:02 AM, John Rose  wrote:
> 
>> On Sep 12, 2013, at 5:44 PM, David Chase  wrote:
>> 
>>> Do these sibling bugs have numbers?
>> 
>> Yes, 8022701.  I just updated the bug to explain their common genesis.
>> 
>>> And I take it you would like to see
>>> 
>>> 1) a test enhanced with ASM to do all 3 variants of this
>> 
>> Yes, please.  The case of "no such field" does not have a direct cause from lambda expressions AFAIK, but it can occur with "raw" CONSTANT_MethodHandles.  (It would be reasonable for javac to emit CONSTANT_MH's for fields in some very limited circumstances, but I'll bet it doesn't.)
>> 
>>> 2) DO attach the underlying cause
>> 
>> Yes.  Read the javadoc for ExceptionInInitializerError for an example of why users want the underlying cause for linkage errors.
>> 
>> (Golly, I wonder what happens if resolution of a CONSTANT_MethodHandle tries to touch a class with a booby-trapped .  I hope it's the case that the ExceptionInInitializerError just passes straight up the stack.  But if it were to get wrapped in a ROE of some sort, it would probably bubble up as an IAE.  Could be a charming exploration.  Actually, no, I don't want to go in there.  Getting all possible linkage errors correct is fine, but we have more important things to do.)
>> 
>> ? John
>> 
>>> David
>>> 
>>> On 2013-09-12, at 5:35 PM, John Rose  wrote:
>>> 
>>>> It looks good.  I have three requests.
>>>> 
>>>> Regarding this comment:
>>>> +     * See MethodSupplier.java to see how to produce these bytes.
>>>> +     * They encode that class, except that method m is private, not public.
>>>> 
>>>> The recipe is incomplete, since it does not say which bits to tweak to make m private.  Please add that step to the comments more explicitly, or if possible to the code (so bogusMethodSupplier is a clean copy of the od output).  I suppose you could ask sed to change the byte for you.  That will make this test a better example for future tests, and make it easier to maintain if javac output changes.  The high road to use would be asm, although for a single byte tweak od works OK.
>>>> 
>>>> Also, this bug has two twins.  The same thing will happen with NoSuchMethodE* and NoSuchFieldE*.  Can you please make fixes for those guys also?
>>>> 
>>>> FTR, see MemberName.makeAccessException() for logic which maps the other way, from *Error to *Exception.  I don't see a direct way to avoid the double mapping (Error=>Exception=>Error) when it occurs.
>>>> 
>>>> For the initCause bit we should do this:
>>>> 
>>>>     } catch (IllegalAccessException ex) {
>>>>         Error err = new IllegalAccessError(ex.getMessage());
>>>>         err.initCause(ex.getCause());  // reuse underlying cause of ex
>>>>         throw err;
>>>>     } ... and for NSME and NSFE...
>>>> 
>>>> That way users can avoid the duplicate exception but can see any underlying causes that the JVM may include.
>>>> 
>>>> Thanks for untangling this!
>>>> 
>>>> ? John
>>>> 
>>>> On Sep 12, 2013, at 12:17 PM, David Chase  wrote:
>>>> 
>>>>> The test is adapted from the test in the bug report.
>>>>> The headline on the bug report is wrong -- because it uses reflection in the test to do the invocation,
>>>>> the thrown exception is wrapped with InvocationTargetException, which is completely correct.
>>>>> HOWEVER, the exception inside the wrapper is the wrong one.
>>>>> 
>>>>> The new test checks the exception in both the reflective-invocation and plain-invocation cases,
>>>>> and also checks both a method handle call (which threw the wrong exception) and a plain
>>>>> call (which threw, and throws, the right exception).
>>>>> 
>>>>> The test also uses a tweaked classloader to substitute the borked bytecodes necessary to get
>>>>> the error, so it is not only shell-free, it can also be run outside jtreg.
>>>>> 
>>>>> On 2013-09-12, at 2:34 PM, Christian Thalinger  wrote:
>>>>> 
>>>>>> 
>>>>>> On Sep 12, 2013, at 11:28 AM, David Chase  wrote:
>>>>>> 
>>>>>>> New webrev, commented line removed:
>>>>>>> http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
>>>>>> 
>>>>>> I think the change is good given that the tests work now.  Is your test derived from the test in the bug report?
>>>>>> 
>>>>>> And it would be good if John could also have a quick look (just be to be sure).
>>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> On 2013-09-12, at 1:53 PM, David Chase  wrote:
>>>>>>> 
>>>>>>>> I believe it produced extraneous output -- it was not clear to me that it was either necessary or useful to fully describe all the converted exceptions that lead to the defined exception being thrown.  The commented line should have just been removed (I think).
>>>>>>>> 
>>>>>>>> On 2013-09-12, at 1:24 PM, Christian Thalinger  wrote:
>>>>>>>> 
>>>>>>>>> +             // err.initCause(ex);
>>>>>>>>> 
>>>>>>>>> Why is this commented?
>>>>>>>>> 
>>>>>>>>> -- Chris
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> mlvm-dev mailing list
>>>>> mlvm-dev at openjdk.java.net
>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>> 
>>> 
>> 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From christian.thalinger at oracle.com  Fri Sep 27 01:55:00 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Sep 2013 18:55:00 -0700
Subject: RFR (S) 8001108: an attempt to use "" as a method name
	should elicit NoSuchMethodException
In-Reply-To: <99860D39-C18B-4638-94BB-12084139AE1E@oracle.com>
References: <6FAC275C-6374-41F5-BAB7-CA1AC729EF9F@oracle.com>
	<09F68115-21E6-450C-8DC2-6FCDB6C191B4@oracle.com>
	<99860D39-C18B-4638-94BB-12084139AE1E@oracle.com>
Message-ID: <35BFE992-4E0C-4816-851B-EE871FA375F2@oracle.com>


On Sep 19, 2013, at 2:31 PM, John Rose  wrote:

> 
> On Sep 18, 2013, at 5:05 PM, Christian Thalinger  wrote:
> 
>> src/share/classes/java/lang/invoke/MethodHandles.java:
>> 
>> +     * methods as if they were normal methods, but the JVM verifier rejects them.
>> 
>> I think you should say "JVM byte code verifier" here.
> 
> Done.  s/byte code/bytecode/.
> 
>> 
>> +         * (Note:  JVM internal methods named {@code } not visible to this API,
>> +         * even though the {@code invokespecial} instruction can refer to them
>> +         * in special circumstances.  Use {@link #findConstructor findConstructor}
>> 
>> Not exactly sure but should this read "are not visible"?
> 
> Yes.
> 
>> 
>>        MemberName resolveOrFail(byte refKind, Class refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException {
>> +            type.getClass();  // NPE
>>            checkSymbolicClass(refc);  // do this before attempting to resolve
>> -            name.getClass(); type.getClass();  // NPE
>> +            checkMethodName(refKind, name);
>> 
>> Could you add a comment here saying that checkMethodName does an implicit null pointer check on name?  Maybe a comment for checkMethodName too.
> 
> Done.
> 
>> 
>> What was the problem with the null pointer exceptions?  Is it okay that we might throw another exception before null checking name?
> 
> Foo.  The reordering of those null checks seems to be a needless change that crept in.  I'm going to keep them the way they are.
> 
> See updated webrev:
>  http://cr.openjdk.java.net/~jrose/8001108/webrev.01/

Looks good.

> 
> ? John
> 
>> On Sep 12, 2013, at 6:47 PM, John Rose  wrote:
>> 
>>> Please review this change for a change to the JSR 292 implementation:
>>> 
>>> http://cr.openjdk.java.net/~jrose/8001108/webrev.00
>>> 
>>> Summary: add an explicit check for leading "<", upgrade the unit tests
>>> 
>>> The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
>>> 
>>> In the RI, there is an explicit error check.
>>> 
>>> Thanks,
>>> ? John
>>> 
>>> P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
>>> Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From john.r.rose at oracle.com  Fri Sep 27 04:33:26 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 26 Sep 2013 21:33:26 -0700
Subject: RFR(S+M) / 8022701 Accessibility checking:
	InvocationTargetException is thrown instead of IllegalAccessError
In-Reply-To: 
References: <143F40F0-557E-48EA-9207-0FF1880663DF@oracle.com>
	<5229F4B8.9000506@oracle.com>
	<64E60D4E-0829-4B23-9EE7-61AD28DB7E2F@oracle.com>
	
	
	<49B1A36F-6C45-4E92-80D2-FA6F80A238CB@oracle.com>
	<2F83E9C4-B28A-4385-8FFB-78F1313A931F@oracle.com>
	<6F0563F9-7A78-42C7-9296-53991C18D5CA@oracle.com>
	
	<31FAE0CA-5EDD-4014-AED9-27533E53307F@oracle.com>
	
	<9092C3F3-EA5A-4748-BD67-0423F1B8964E@oracle.com>
	
Message-ID: 

On Sep 19, 2013, at 9:57 AM, David Chase  wrote:

> Recommended changes made:
> 
> http://cr.openjdk.java.net/~drchase/8022701/webrev.04/

Good; reviewed.

Consider adding this tweak, which would close the loop on alternation between the fooError and fooException versions:

+    static private void initCauseFrom(Error err, Exception ex) {
+        Throwable th = ex.getCause();
++      if (err.getClass().isInstance(th))  throw (Error) th;
+        err.initCause(th == null ? ex : th);
+    }

E.g., if the reason for linkage failure was originally NoSuchMethodError, but was mapped to NoSuchMethodException (which can happen in MemberName.makeAccessException) then the original NoSuchMethodError is extracted and thrown, rather than a new NoSuchMethodError which wraps the original NoSuchMethodError.

> Test with jtreg (for pass and for induced failure) on MacOS,
> not sure what additional other testing is desired since it is entirely in the libraries.

Your test case is enough.

> I included code to handle the case of a broken field-referencing methodhandle,
> but did not test it because there's no syntax for these in Java, nor is their creation
> well-documented.

That's fine.  Ship it, preferably with the tweak above.

? John

From weijun.wang at oracle.com  Fri Sep 27 07:26:26 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 27 Sep 2013 07:26:26 +0000
Subject: hg: jdk8/tl/jdk: 8024861: Incomplete token triggers GSS-API
	NullPointerException
Message-ID: <20130927072638.0BB3562B5B@hg.openjdk.java.net>

Changeset: eb2c81533876
Author:    weijun
Date:      2013-09-27 15:25 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb2c81533876

8024861: Incomplete token triggers GSS-API NullPointerException
Reviewed-by: mullan

! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
+ test/sun/security/jgss/spnego/MechTokenMissing.java



From vicente.romero at oracle.com  Fri Sep 27 09:26:11 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 27 Sep 2013 09:26:11 +0000
Subject: hg: jdk8/tl/langtools: 8024497: crash returning this-referencing
	lambda from default method
Message-ID: <20130927092617.CEFEC62B66@hg.openjdk.java.net>

Changeset: 16194509e483
Author:    vromero
Date:      2013-09-27 10:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/16194509e483

8024497: crash returning this-referencing lambda from default method
Reviewed-by: jjg, rfield

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/lambda/8024497/CrashUsingReturningThisRefLambdaFromDefaultMetTest.java



From Sergey.Bylokhov at oracle.com  Fri Sep 27 11:08:00 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 27 Sep 2013 15:08:00 +0400
Subject: JDK 8 code review request for doclint issues in
	java.lang.instrument
In-Reply-To: <51D1CEC6.7080702@oracle.com>
References: <51D1C974.80704@oracle.com> <51D1CEC6.7080702@oracle.com>
Message-ID: <52456710.6010600@oracle.com>

Hello,
I have a question about of 
       = > 
      . Should we follow html 
specification[1] here or we should always replace 
       to 
      ?
[1] http://dev.w3.org/html5/markup/p.html#p
see@ Tag omission

On 01.07.2013 22:47, Alan Bateman wrote:
> On 01/07/2013 19:24, Joe Darcy wrote:
>> Hello,
>>
>> Yet another found of doclint fixes for review; this batch to 
>> java.lang.instrument.
>>
>> Thanks,
>>
>> -Joe
> This looks okay to me.
>
> -Alan


-- 
Best regards, Sergey.



From sergey.kuksenko at oracle.com  Fri Sep 27 12:39:11 2013
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Fri, 27 Sep 2013 16:39:11 +0400
Subject: RFR (M): 8024635: Caching MethodType's descriptor string improves
	lambda linkage performance
In-Reply-To: 
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
	<52389D14.2080606@oracle.com>
	
	<52445F47.9030402@oracle.com>
	
Message-ID: <52457C6F.7010805@oracle.com>


Updated version at
http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.02/
according comments:
- remove "null check" comment near Object.requireNonNull calls
- distort/(change parameters order) in key-purposed MethodType constructor
- move count-slot logic from checkPType to checkPTypes.



On 09/26/2013 11:09 PM, John Rose wrote:
> (Quick note on format:  I have changed the subject line to include the conventional bug number and size estimate.  The bug number makes it easier to track in mailers.)
> 
> On Sep 26, 2013, at 9:22 AM, Sergey Kuksenko  wrote:
> 
>> Hi All,
>>
>> I updated fix.
>> You may find it here
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.01/
>>
>> See my comments and new webrev descition below
>>
>> On 09/18/2013 12:59 AM, John Rose wrote:
>>>>> We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well. 
>>>> In case of small amount of such strings we will get a huge overhead from
>>>> any kind of map.
>>> I would expect O(10^1.5) memory references and branches.  Depends on what you mean by "huge".
>> Sure. I think the question to use external map or field may be decided
>> later when/if it will be needed.
>> Just some statictics, I've collected on nashorn/octane benchmarks
>> (statistics collected only for the single(first) benchmark iteration:
>> mandreel: 514 unique strings, toMethodDescriptorString called 69047 times
>> box2d: 560 unique strings, 34776 toMethodDescriptorString invocations.
> 
> Good data; thanks.
> 
>>
>>> Would there be any benefit from recording the original string from the constant pool?  The JVM path for this is SystemDictionary::find_method_handle_type, which makes an upcall to MethodHandleNatives.findMethodHandleType.  Currently only the ptypes and rtype are passed, but the JVM could also convert the internal Symbol to a java.lang.String and pass that also.  In that case, MT's created by JVM upcalls would be pre-equipped with descriptor strings.
>>>
>>> This is probably worth an experiment, although it requires some JVM work.
>>
>> I am definitely sure that we shouldn't do that.
>> Right now caching desriptor strings is internal decision of MethodType.
>> Otherwise it will make interfaces more complex.
> 
> Yes, I agree.  Also, it would only benefit the 514 calls which introduce unique strings, whereas your change helps the 69047 calls for descriptor strings.
> 
>>> I hope you get my overall point:  Hand optimizations have a continuing cost, related to obscuring the logical structure of the code.  The transforming engineer might make a mistake, and later maintaining engineers might also make mistakes.
>>>
>>> https://blogs.oracle.com/jrose/entry/three_software_proverbs
>>
>> And it doesn't mean that we should afraid any kind of optimization.
>> Lucky positions - someone(or something) will optimize it for us. But
>> sometimes JIT (even smart JIT) is not enough.
> 
> Sometimes.  When that happens we reluctantly hand-optimize our code.
> 
>> Let's back to the patch.construstors
>> I decided not change original checkPType/checkRType code, except
>> explicit Objects.requireNonNull. The problem here that we are creating
>> new MethodType objects which are already exists, we have to create MT as
>> a key for searching in the internedTable. Ratio between already exiting
>> and new MethodTypes a quite huge.
>> Here is some statistics I've collected on nashorn/octane benchmarks
>> (statistics collected only for the single(first) benchmark iteration:
>>
>> mandreel:
>>  - 1739 unique MethodTypes,
>>  - 878414 MethodType.makeImpl requests;
>> box2d:
>>  - 1861 unique MethodTypes,
>>  - 527486 MethodType.makeImpl requests;
>> gameboy:
>>  - 2062 unique MethodTypes,
>>  - 311378 MethodType.makeImpl requests;
>>
>> So
>> 1. MethodType constructor do checkPTypes/checkRType which are frequently
>> (99%) useless - we already have the same (checked) MethodType in the
>> internTable.
>> 2. Less than 1% of created MethodTypes will be stored into internTable,
>> but reusing that MethodType objects prevent ti from scalar replacement.
>> (I've heard that Graal may do flow-sensitive scalar replacement, but C2
>> can't do).
>>
>> What I did. I separate constructors:
>> - for long lived MethodTypes with all checks,
>> - for short lived MethodTypes used only as key for searching in the
>> InterTable, no checks are performed.
>> if we didn't find  MethodType in the table we always create a new one
>> (with checks) that is required in less than 1% cases. And we remove at
>> least one obstacle for scalar replacement. Unfortunately, scalaer
>> replacement for expression "internTable.get(new MethodType(rtype,
>> ptypes))" was not performed, the reason may be evaluated, and hope it
>> would be easier to achieve scalarization in this case.
> 
> Brilliant.  I love this.
> 
> The constructor signatures are too similar given the subtle difference between their semantics.  Please distort the signature of the extra-sensitive constructor.  (Imagine the wrong one accidentally invoked by helpful IDE code completers.)  Put in a leading int dummy argument, or reverse the parameters, or some similar hack.  (If we had named constructors, we'd hack the name instead.)  I admit this is of marginal benefit, since there is only one place where the constructors are called, but it's good style.  If there were more places calling the constructor, we'd absolutely want a clear distinction between checked and unchecked.
> 
> If it still makes sense, I wouldn't mind moving the slot-count logic (long/double adjustment) out of checkPType into checkPTypes.  But I think that's moot with this much better change.
> -            slots += checkPtype(ptype);
> +            checkPtype(ptype);
> +            if (ptype == double.class || ptype == long.class) {
> +                slots++;
> +            }
> 
> Good work.  Reviewed.  (You need another reviewer, I think.)
> 
> ? John
> 


-- 
Best regards,
Sergey Kuksenko


From erik.helin at oracle.com  Fri Sep 27 12:39:30 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 27 Sep 2013 14:39:30 +0200
Subject: RFR: 8025502: Exclude tests due to JDK-8025427
In-Reply-To: <52446546.3090708@oracle.com>
References: <20130926142842.GA11592@ehelin-thinkpad>
	<52446546.3090708@oracle.com>
Message-ID: <20130927123929.GA2375@ehelin-thinkpad>

On 2013-09-26, Kumar Srinivasan wrote:
> Hi Erik,
> 
> Looks good!,  the bug must be tagged with keyword "noreg-build".

Thanks! I've added the label to the bug.

Erik

> Kumar
> 
> >Hi all,
> >
> >I need to exclude some tests due a recent change to jstat that caused to
> >jstat to output the \ufffd for Double.NaN, which confused the tests. I
> >am working on a solution to this, but in the meantime I would like to
> >exclude the tests in order not cause unexpected failures.
> >
> >Webrev:
> >http://cr.openjdk.java.net/~ehelin/8025427/webrev.00/
> >
> >Thanks,
> >Erik
> 


From erik.helin at oracle.com  Fri Sep 27 14:03:22 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 27 Sep 2013 16:03:22 +0200
Subject: RFR: 8025502: Exclude tests due to JDK-8025427
In-Reply-To: <20130927123929.GA2375@ehelin-thinkpad>
References: <20130926142842.GA11592@ehelin-thinkpad>
	<52446546.3090708@oracle.com>
	<20130927123929.GA2375@ehelin-thinkpad>
Message-ID: <20130927140322.GB2306@ehelin-thinkpad>

Hi all,

Joel found a small issue with the patch, the paths were slightly wrong.

An updated webrev is located at:
http://cr.openjdk.java.net/~ehelin/8025427/webrev.01/

Thanks,
Erik

On 2013-09-27, Erik Helin wrote:
> On 2013-09-26, Kumar Srinivasan wrote:
> > Hi Erik,
> > 
> > Looks good!,  the bug must be tagged with keyword "noreg-build".
> 
> Thanks! I've added the label to the bug.
> 
> Erik
> 
> > Kumar
> > 
> > >Hi all,
> > >
> > >I need to exclude some tests due a recent change to jstat that caused to
> > >jstat to output the \ufffd for Double.NaN, which confused the tests. I
> > >am working on a solution to this, but in the meantime I would like to
> > >exclude the tests in order not cause unexpected failures.
> > >
> > >Webrev:
> > >http://cr.openjdk.java.net/~ehelin/8025427/webrev.00/
> > >
> > >Thanks,
> > >Erik
> > 


From joel.franck at oracle.com  Fri Sep 27 14:26:16 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Fri, 27 Sep 2013 16:26:16 +0200
Subject: RFR: 8025502: Exclude tests due to JDK-8025427
In-Reply-To: <20130927140322.GB2306@ehelin-thinkpad>
References: <20130926142842.GA11592@ehelin-thinkpad>
	<52446546.3090708@oracle.com>
	<20130927123929.GA2375@ehelin-thinkpad>
	<20130927140322.GB2306@ehelin-thinkpad>
Message-ID: <20130927142616.GT15298@jfranck-desktop.jrpg.bea.com>

Hi

Looks good. I've run the jdk_tools tests and these gets excluded.

I'll sponsor this for you.

cheers
/Joel

On 2013-09-27, Erik Helin wrote:
> Hi all,
> 
> Joel found a small issue with the patch, the paths were slightly wrong.
> 
> An updated webrev is located at:
> http://cr.openjdk.java.net/~ehelin/8025427/webrev.01/
> 
> Thanks,
> Erik
> 
> On 2013-09-27, Erik Helin wrote:
> > On 2013-09-26, Kumar Srinivasan wrote:
> > > Hi Erik,
> > > 
> > > Looks good!,  the bug must be tagged with keyword "noreg-build".
> > 
> > Thanks! I've added the label to the bug.
> > 
> > Erik
> > 
> > > Kumar
> > > 
> > > >Hi all,
> > > >
> > > >I need to exclude some tests due a recent change to jstat that caused to
> > > >jstat to output the \ufffd for Double.NaN, which confused the tests. I
> > > >am working on a solution to this, but in the meantime I would like to
> > > >exclude the tests in order not cause unexpected failures.
> > > >
> > > >Webrev:
> > > >http://cr.openjdk.java.net/~ehelin/8025427/webrev.00/
> > > >
> > > >Thanks,
> > > >Erik
> > > 


From erik.helin at oracle.com  Fri Sep 27 14:48:53 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 27 Sep 2013 16:48:53 +0200
Subject: RFR: 8025502: Exclude tests due to JDK-8025427
In-Reply-To: <20130927142616.GT15298@jfranck-desktop.jrpg.bea.com>
References: <20130926142842.GA11592@ehelin-thinkpad>
	<52446546.3090708@oracle.com>
	<20130927123929.GA2375@ehelin-thinkpad>
	<20130927140322.GB2306@ehelin-thinkpad>
	<20130927142616.GT15298@jfranck-desktop.jrpg.bea.com>
Message-ID: <20130927144853.GD2306@ehelin-thinkpad>

On 2013-09-27, Joel Borggren-Franck wrote:
> Hi
> 
> Looks good. I've run the jdk_tools tests and these gets excluded.
> 
> I'll sponsor this for you.

Thanks!

Erik

> 
> cheers
> /Joel
> 
> On 2013-09-27, Erik Helin wrote:
> > Hi all,
> > 
> > Joel found a small issue with the patch, the paths were slightly wrong.
> > 
> > An updated webrev is located at:
> > http://cr.openjdk.java.net/~ehelin/8025427/webrev.01/
> > 
> > Thanks,
> > Erik
> > 
> > On 2013-09-27, Erik Helin wrote:
> > > On 2013-09-26, Kumar Srinivasan wrote:
> > > > Hi Erik,
> > > > 
> > > > Looks good!,  the bug must be tagged with keyword "noreg-build".
> > > 
> > > Thanks! I've added the label to the bug.
> > > 
> > > Erik
> > > 
> > > > Kumar
> > > > 
> > > > >Hi all,
> > > > >
> > > > >I need to exclude some tests due a recent change to jstat that caused to
> > > > >jstat to output the \ufffd for Double.NaN, which confused the tests. I
> > > > >am working on a solution to this, but in the meantime I would like to
> > > > >exclude the tests in order not cause unexpected failures.
> > > > >
> > > > >Webrev:
> > > > >http://cr.openjdk.java.net/~ehelin/8025427/webrev.00/
> > > > >
> > > > >Thanks,
> > > > >Erik
> > > > 


From joel.franck at oracle.com  Fri Sep 27 14:56:02 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Fri, 27 Sep 2013 14:56:02 +0000
Subject: hg: jdk8/tl/jdk: 8025502: Exclude tests due to JDK-8025427
Message-ID: <20130927145634.45AA762B7E@hg.openjdk.java.net>

Changeset: 95f609fcb639
Author:    ehelin
Date:      2013-09-26 16:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95f609fcb639

8025502: Exclude tests due to JDK-8025427
Reviewed-by: ksrini

! test/ProblemList.txt



From jan.lahoda at oracle.com  Fri Sep 27 15:29:51 2013
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Fri, 27 Sep 2013 15:29:51 +0000
Subject: hg: jdk8/tl/langtools: 8022765: Compiler crashes with exception on
	wrong usage of an annotation.
Message-ID: <20130927152958.F257962B87@hg.openjdk.java.net>

Changeset: b7d8b71e1658
Author:    jlahoda
Date:      2013-09-27 17:28 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7d8b71e1658

8022765: Compiler crashes with exception on wrong usage of an annotation.
Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately
Reviewed-by: jfranck, jjg

! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/annotations/neg/8022765/T8022765.java
+ test/tools/javac/annotations/neg/8022765/T8022765.out
+ test/tools/javac/annotations/neg/8022765/VerifyAnnotationsAttributed.java



From joe.darcy at oracle.com  Fri Sep 27 17:00:26 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 27 Sep 2013 10:00:26 -0700
Subject: JDK 8 code review request for doclint issues in
	java.lang.instrument
In-Reply-To: <52456710.6010600@oracle.com>
References: <51D1C974.80704@oracle.com> <51D1CEC6.7080702@oracle.com>
	<52456710.6010600@oracle.com>
Message-ID: <5245B9AA.6010500@oracle.com>

Adding Jon Gibbons, author of doclint.

Sergey, currently doclint is enforcing the rules of HTML 4 rather than 
HTML 5. At some point in the future, we may migrate to HTML 5.

-Joe

On 9/27/2013 4:08 AM, Sergey Bylokhov wrote:
> Hello,
> I have a question about of 
       = > 
      . Should we follow html 
> specification[1] here or we should always replace 
       to 
      ?
> [1] http://dev.w3.org/html5/markup/p.html#p
> see@ Tag omission
>
> On 01.07.2013 22:47, Alan Bateman wrote:
>> On 01/07/2013 19:24, Joe Darcy wrote:
>>> Hello,
>>>
>>> Yet another found of doclint fixes for review; this batch to 
>>> java.lang.instrument.
>>>
>>> Thanks,
>>>
>>> -Joe
>> This looks okay to me.
>>
>> -Alan
>
>



From alexander.zuev at oracle.com  Fri Sep 27 17:20:36 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Fri, 27 Sep 2013 17:20:36 +0000
Subject: hg: jdk8/tl/langtools: 6978886: javadoc shows stacktrace after print
	error resulting from disk full
Message-ID: <20130927172042.5CAFD62B95@hg.openjdk.java.net>

Changeset: 2c24a04ebfb4
Author:    kizune
Date:      2013-09-27 21:20 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2c24a04ebfb4

6978886: javadoc shows stacktrace after print error resulting from disk full
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java



From henry.jen at oracle.com  Fri Sep 27 17:25:21 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 27 Sep 2013 10:25:21 -0700
Subject: RFR (3rd): 8023524: Mechanism to dump generated lambda classes /
	log lambda code generation
In-Reply-To: <5244BCD4.20002@oracle.com>
References: <523945CF.9060804@oracle.com>
	<523994D1.8090200@redhat.com>	<523A307E.6080202@oracle.com>
	<523AA764.60301@redhat.com> <52420B31.2070703@oracle.com>
	<524292AF.3020209@oracle.com> <5244BCD4.20002@oracle.com>
Message-ID: <0934EECA-D02A-4C0D-977E-05C26792D29D@oracle.com>


On Sep 26, 2013, at 4:01 PM, Mandy Chung  wrote:

> Hi Henry,
> 
> On 9/25/2013 12:37 AM, Henry Jen wrote:
>> Hi,
>> 
>> Please review the update webrev at
>> http://cr.openjdk.java.net/~henryjen/ccc/8023524/2/webrev/
> 
> The doPrivileged block looks okay.  It'd be good to limit privileges
> by calling the doPrivileged method with a specific set of Permissions.
> In this case, it would be FilePermission("<>", "write").
> 

Good point, I will do that.

> If "jdk.internal.lambda.dumpProxyClasses" property is set with empty
> value, would it be better to default to CWD?  ProxyClassesDumper currently
> fails with non-existent directory.
> 

That sounds reasonable, I will replace empty string with ".".
Personally I prefer explicit value being specified, I always specify "." if I wanted current directory.

> ProxyClassesDumper - you may want to use java.nio.file.Path and
> Files.  I also suggest to follow the convention of classfile pathname
> and generate it in the directories reflecting the package name i.e.
>  DIR/com/example/TestLambda$$Lambda$1.class
> 
> instead of DIR/com.example.TestLambda$$Lambda$1.class,
> 

Make sense to me if that's safe enough to do so.  I don't have a strong opinion on this.
By avoiding create directories, less chance for malicious class to mess with file system.

> For escaping sequence, as Peter pointed out, I presume you can
> consider using ParseUtil.encodePath but I am not sure how importance
> it has to encode the path as this is for debugging purpose.
> No strong opinion in this one.

If I have known this, I could have used that. :)
In this latest webrev, a simple encoding is implemented which allows unicode characters to pass through, which is probably good enough?

Cheers,
Henry

From mike.duigou at oracle.com  Fri Sep 27 17:26:58 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 27 Sep 2013 17:26:58 +0000
Subject: hg: jdk8/tl/jdk: 8025595: Remove alt-rt.jar,
	used by +AggressiveOps (jdk repo portion of JDK-8024826)
Message-ID: <20130927172710.5675162B96@hg.openjdk.java.net>

Changeset: 914f8d4570df
Author:    mduigou
Date:      2013-09-27 10:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914f8d4570df

8025595: Remove alt-rt.jar, used by +AggressiveOps (jdk repo portion of JDK-8024826)
Reviewed-by: alanb, chegar, dholmes, ksrini

! makefiles/CompileJavaClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/Profiles.gmk
! makefiles/profile-includes.txt
! test/java/util/TreeMap/Clone.java



From sonali.goel at oracle.com  Fri Sep 27 17:40:27 2013
From: sonali.goel at oracle.com (sonali.goel at oracle.com)
Date: Fri, 27 Sep 2013 17:40:27 +0000
Subject: hg: jdk8/tl/langtools: 8025537: Convert 2 javac/enumdeclarations
	tests in jtreg for regression ws
Message-ID: <20130927174030.6833162B98@hg.openjdk.java.net>

Changeset: 699b86e82656
Author:    sogoel
Date:      2013-09-27 10:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/699b86e82656

8025537: Convert 2 javac/enumdeclarations tests in jtreg for regression ws
Reviewed-by: jjg

+ test/tools/javac/enum/EnumAsIdentifier.java
+ test/tools/javac/enum/EnumAsIdentifier.out
+ test/tools/javac/enum/EnumAsIdentifier4.out
+ test/tools/javac/enum/EnumAsIdentifier5.out
+ test/tools/javac/enum/EnumMembersOrder.java
+ test/tools/javac/enum/EnumMembersOrder.out



From joe.darcy at oracle.com  Fri Sep 27 18:14:46 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 27 Sep 2013 11:14:46 -0700
Subject: Fwd: Re: type anno test code check in
In-Reply-To: <52401761.5000301@oracle.com>
References: <522F56DE.4040807@oracle.com> <522FD95D.9040402@oracle.com>
	<20130911144428.GR11725@jfranck-desktop.jrpg.bea.com>
	<523FAA8F.3070506@oracle.com>
	<20130923080133.GA15298@jfranck-desktop.jrpg.bea.com>
	<52401761.5000301@oracle.com>
Message-ID: <5245CB16.9090303@oracle.com>

On 9/23/2013 3:26 AM, Charlie Wang wrote:
> OK, here's the link 
> http://cr.openjdk.java.net/~pzhang/Charlie/TypeAnnotation1/webrev/
> Also I would appreciate it if you could check in the code once you are 
> OK with it, because these tests have gone through numerous rounds of 
> review and I would like to wrap it up asap.
> If others have comments, I will file RFE bugs to track them.

Despite the previous rounds of review, this code is not yet suitable for 
inclusion in OpenJDK. From some spot checks, the code uses raw types in 
some locations,  it is questionable to define constant in interfaces as 
in TestCaseGenerator, and  many of the *.txt files that are checked in 
look a lot like valid Java source files.

There is no presumption of being able to check code in without reviewer 
approval.

-Joe

>
>
>
>
> - Charlie
>
>
> On 2013/9/23 16:01, Joel Borggren-Franck wrote:
>> Hi Charlie,
>>
>> Please upload a webrev that I and others can review.
>>
>> cheers
>> /Joel
>>
>> On 2013-09-23, Charlie Wang wrote:
>>> Hi Joel,
>>>    Fixed the issues people raised recently. Could you commit the code
>>> for me? Files are attached. Thanks.
>>>
>>>
>>> - Charlie
>>>
>>> On 2013/9/11 22:44, Joel Borggren-Franck wrote:
>>>> Hi Charlie,
>>>>
>>>> These tests should go into TL, I can commit them there. The test 
>>>> review
>>>> cycle should be on core-libs-dev at openjdk.java.net.
>>>>
>>>> However the test are not ready yet.
>>>>
>>>> If you run the tests vs jdk8-b106 or a recent copy of TL there is a 
>>>> few
>>>> failures. How can I as a developer see the exact source which 
>>>> caused the
>>>> failure?
>>>>
>>>> Further, there is an @author tag between two jtreg tags, @build and
>>>> @run in almost every file. Please don't do that.
>>>>
>>>> As a user of these tests there needs to be a way for me to:
>>>>
>>>> 1) Understand the tests / ensure that the tests are correct
>>>> 2) Run the tests
>>>> 3) Understand what causes tests failures
>>>>
>>>> Out of these only 2) is currently easy. 1) is hard and 3) looks
>>>> impossible.
>>>>
>>>> Here is what you need to do to bring this forward:
>>>>
>>>> - At a minimum you need to document how the tests work. It is not 
>>>> clear
>>>>    at the moment.
>>>>
>>>> - Please explain why are the helpers split out into 2 interfaces and 4
>>>>    classes?
>>>>
>>>> - You also need to improve failure friendliness. If a tests fail, it
>>>>    must be possible to see the java source of the generated program 
>>>> that
>>>>    fails together with a decent explanation of what went wrong.
>>>>
>>>> If this is currently available, please indicate how to do it.
>>>>
>>>> cheers
>>>> /Joel
>>>>
>>>> On 2013-09-11, Charlie Wang wrote:
>>>>> Hi,
>>>>>    I'm looking for a committer to help me check in type annotation
>>>>> reflection test code. Could someone give me a hand?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Charlie
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject:     Re: type anno test code check in
>>>>> Date:     Tue, 10 Sep 2013 10:29:02 -0700
>>>>> From:     Alex Buckley 
>>>>> Organization:     Oracle Corporation
>>>>> To:     Charlie Wang 
>>>>>
>>>>>
>>>>>
>>>>> Ask on type-annotations-dev for a Committer in the Type Annotations
>>>>> Project to push the tests for you. The tests will go in the jdk repo.
>>>>>
>>>>> Alex
>>>>>
>>
>



From mike.duigou at oracle.com  Fri Sep 27 18:35:29 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 27 Sep 2013 18:35:29 +0000
Subject: hg: jdk8/tl/langtools: 8024842: Define ABS_TEST_OUTPUT_DIR via
	TEST_OUTPUT_DIR
Message-ID: <20130927183536.6095762BA1@hg.openjdk.java.net>

Changeset: 4ed8565fa536
Author:    mduigou
Date:      2013-09-27 11:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ed8565fa536

8024842: Define ABS_TEST_OUTPUT_DIR via TEST_OUTPUT_DIR
Reviewed-by: ihse, erikj, vromero

! test/Makefile



From robert.field at oracle.com  Fri Sep 27 20:10:01 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Fri, 27 Sep 2013 20:10:01 +0000
Subject: hg: jdk8/tl/langtools: 8025548: langtools test
	tools/javac/lambda/methodReference/BridgeMethod.java
	incorrectly assumes no other methods generated in lambda class
Message-ID: <20130927201013.422DF62BA7@hg.openjdk.java.net>

Changeset: dee28dd47e12
Author:    rfield
Date:      2013-09-27 13:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dee28dd47e12

8025548: langtools test tools/javac/lambda/methodReference/BridgeMethod.java incorrectly assumes no other methods generated in lambda class
Reviewed-by: vromero

! test/tools/javac/lambda/methodReference/BridgeMethod.java



From christian.thalinger at oracle.com  Fri Sep 27 20:12:20 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 27 Sep 2013 13:12:20 -0700
Subject: RFR (M): 8024635: Caching MethodType's descriptor string improves
	lambda linkage performance
In-Reply-To: <52457C6F.7010805@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
	<52389D14.2080606@oracle.com>
	
	<52445F47.9030402@oracle.com>
	
	<52457C6F.7010805@oracle.com>
Message-ID: <93BF7768-CB54-4482-85E7-FEBD27A82910@oracle.com>

Looks good.

On Sep 27, 2013, at 5:39 AM, Sergey Kuksenko  wrote:

> 
> Updated version at
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.02/
> according comments:
> - remove "null check" comment near Object.requireNonNull calls
> - distort/(change parameters order) in key-purposed MethodType constructor
> - move count-slot logic from checkPType to checkPTypes.
> 
> 
> 
> On 09/26/2013 11:09 PM, John Rose wrote:
>> (Quick note on format:  I have changed the subject line to include the conventional bug number and size estimate.  The bug number makes it easier to track in mailers.)
>> 
>> On Sep 26, 2013, at 9:22 AM, Sergey Kuksenko  wrote:
>> 
>>> Hi All,
>>> 
>>> I updated fix.
>>> You may find it here
>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.01/
>>> 
>>> See my comments and new webrev descition below
>>> 
>>> On 09/18/2013 12:59 AM, John Rose wrote:
>>>>>> We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well. 
>>>>> In case of small amount of such strings we will get a huge overhead from
>>>>> any kind of map.
>>>> I would expect O(10^1.5) memory references and branches.  Depends on what you mean by "huge".
>>> Sure. I think the question to use external map or field may be decided
>>> later when/if it will be needed.
>>> Just some statictics, I've collected on nashorn/octane benchmarks
>>> (statistics collected only for the single(first) benchmark iteration:
>>> mandreel: 514 unique strings, toMethodDescriptorString called 69047 times
>>> box2d: 560 unique strings, 34776 toMethodDescriptorString invocations.
>> 
>> Good data; thanks.
>> 
>>> 
>>>> Would there be any benefit from recording the original string from the constant pool?  The JVM path for this is SystemDictionary::find_method_handle_type, which makes an upcall to MethodHandleNatives.findMethodHandleType.  Currently only the ptypes and rtype are passed, but the JVM could also convert the internal Symbol to a java.lang.String and pass that also.  In that case, MT's created by JVM upcalls would be pre-equipped with descriptor strings.
>>>> 
>>>> This is probably worth an experiment, although it requires some JVM work.
>>> 
>>> I am definitely sure that we shouldn't do that.
>>> Right now caching desriptor strings is internal decision of MethodType.
>>> Otherwise it will make interfaces more complex.
>> 
>> Yes, I agree.  Also, it would only benefit the 514 calls which introduce unique strings, whereas your change helps the 69047 calls for descriptor strings.
>> 
>>>> I hope you get my overall point:  Hand optimizations have a continuing cost, related to obscuring the logical structure of the code.  The transforming engineer might make a mistake, and later maintaining engineers might also make mistakes.
>>>> 
>>>> https://blogs.oracle.com/jrose/entry/three_software_proverbs
>>> 
>>> And it doesn't mean that we should afraid any kind of optimization.
>>> Lucky positions - someone(or something) will optimize it for us. But
>>> sometimes JIT (even smart JIT) is not enough.
>> 
>> Sometimes.  When that happens we reluctantly hand-optimize our code.
>> 
>>> Let's back to the patch.construstors
>>> I decided not change original checkPType/checkRType code, except
>>> explicit Objects.requireNonNull. The problem here that we are creating
>>> new MethodType objects which are already exists, we have to create MT as
>>> a key for searching in the internedTable. Ratio between already exiting
>>> and new MethodTypes a quite huge.
>>> Here is some statistics I've collected on nashorn/octane benchmarks
>>> (statistics collected only for the single(first) benchmark iteration:
>>> 
>>> mandreel:
>>> - 1739 unique MethodTypes,
>>> - 878414 MethodType.makeImpl requests;
>>> box2d:
>>> - 1861 unique MethodTypes,
>>> - 527486 MethodType.makeImpl requests;
>>> gameboy:
>>> - 2062 unique MethodTypes,
>>> - 311378 MethodType.makeImpl requests;
>>> 
>>> So
>>> 1. MethodType constructor do checkPTypes/checkRType which are frequently
>>> (99%) useless - we already have the same (checked) MethodType in the
>>> internTable.
>>> 2. Less than 1% of created MethodTypes will be stored into internTable,
>>> but reusing that MethodType objects prevent ti from scalar replacement.
>>> (I've heard that Graal may do flow-sensitive scalar replacement, but C2
>>> can't do).
>>> 
>>> What I did. I separate constructors:
>>> - for long lived MethodTypes with all checks,
>>> - for short lived MethodTypes used only as key for searching in the
>>> InterTable, no checks are performed.
>>> if we didn't find  MethodType in the table we always create a new one
>>> (with checks) that is required in less than 1% cases. And we remove at
>>> least one obstacle for scalar replacement. Unfortunately, scalaer
>>> replacement for expression "internTable.get(new MethodType(rtype,
>>> ptypes))" was not performed, the reason may be evaluated, and hope it
>>> would be easier to achieve scalarization in this case.
>> 
>> Brilliant.  I love this.
>> 
>> The constructor signatures are too similar given the subtle difference between their semantics.  Please distort the signature of the extra-sensitive constructor.  (Imagine the wrong one accidentally invoked by helpful IDE code completers.)  Put in a leading int dummy argument, or reverse the parameters, or some similar hack.  (If we had named constructors, we'd hack the name instead.)  I admit this is of marginal benefit, since there is only one place where the constructors are called, but it's good style.  If there were more places calling the constructor, we'd absolutely want a clear distinction between checked and unchecked.
>> 
>> If it still makes sense, I wouldn't mind moving the slot-count logic (long/double adjustment) out of checkPType into checkPTypes.  But I think that's moot with this much better change.
>> -            slots += checkPtype(ptype);
>> +            checkPtype(ptype);
>> +            if (ptype == double.class || ptype == long.class) {
>> +                slots++;
>> +            }
>> 
>> Good work.  Reviewed.  (You need another reviewer, I think.)
>> 
>> ? John
>> 
> 
> 
> -- 
> Best regards,
> Sergey Kuksenko



From jonathan.gibbons at oracle.com  Fri Sep 27 20:18:44 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 27 Sep 2013 13:18:44 -0700
Subject: JDK 8 code review request for doclint issues in
	java.lang.instrument
In-Reply-To: <5245B9AA.6010500@oracle.com>
References: <51D1C974.80704@oracle.com> <51D1CEC6.7080702@oracle.com>
	<52456710.6010600@oracle.com> <5245B9AA.6010500@oracle.com>
Message-ID: <5245E824.9030709@oracle.com>

Yes, doclint is enforcing the HTML 4.01 spec for JDK 8.

http://www.w3.org/TR/REC-html40/

This is in accordance with the DOCTYPE declaration generated at the 
beginning of all javadoc-generated files.

FWIW, 
       is *always* wrong.  It would signify an empty paragraph, 
equivalent to 
      .

-- Jon


On 09/27/2013 10:00 AM, Joe Darcy wrote:
> Adding Jon Gibbons, author of doclint.
>
> Sergey, currently doclint is enforcing the rules of HTML 4 rather than 
> HTML 5. At some point in the future, we may migrate to HTML 5.
>
> -Joe
>
> On 9/27/2013 4:08 AM, Sergey Bylokhov wrote:
>> Hello,
>> I have a question about of 
       = > 
      . Should we follow html 
>> specification[1] here or we should always replace 
       to 
      ?
>> [1] http://dev.w3.org/html5/markup/p.html#p
>> see@ Tag omission
>>
>> On 01.07.2013 22:47, Alan Bateman wrote:
>>> On 01/07/2013 19:24, Joe Darcy wrote:
>>>> Hello,
>>>>
>>>> Yet another found of doclint fixes for review; this batch to 
>>>> java.lang.instrument.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>> This looks okay to me.
>>>
>>> -Alan
>>
>>
>



From john.r.rose at oracle.com  Fri Sep 27 20:20:03 2013
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 27 Sep 2013 13:20:03 -0700
Subject: RFR (M): 8024635: Caching MethodType's descriptor string improves
	lambda linkage performance
In-Reply-To: <52457C6F.7010805@oracle.com>
References: <523098F2.7010307@oracle.com> <5230A1E7.7080703@oracle.com>
	<5230BE6B.6090104@oracle.com>
	<4580E399-DACF-4877-A6CC-9C7BFBC11E14@oracle.com>
	<52389D14.2080606@oracle.com>
	
	<52445F47.9030402@oracle.com>
	
	<52457C6F.7010805@oracle.com>
Message-ID: 

Good.  ? John

On Sep 27, 2013, at 5:39 AM, Sergey Kuksenko  wrote:

> Updated version at
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.02/
> according comments:
> - remove "null check" comment near Object.requireNonNull calls
> - distort/(change parameters order) in key-purposed MethodType constructor
> - move count-slot logic from checkPType to checkPTypes.
> 
> 
> 
> On 09/26/2013 11:09 PM, John Rose wrote:
>> (Quick note on format:  I have changed the subject line to include the conventional bug number and size estimate.  The bug number makes it easier to track in mailers.)
>> 
>> On Sep 26, 2013, at 9:22 AM, Sergey Kuksenko  wrote:
>> 
>>> Hi All,
>>> 
>>> I updated fix.
>>> You may find it here
>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.01/
>>> 
>>> See my comments and new webrev descition below
>>> 
>>> On 09/18/2013 12:59 AM, John Rose wrote:
>>>>>> We can tweak that later if necessary.  There are probably only a small number of such strings, so maybe a small leaky map would do the trick as well. 
>>>>> In case of small amount of such strings we will get a huge overhead from
>>>>> any kind of map.
>>>> I would expect O(10^1.5) memory references and branches.  Depends on what you mean by "huge".
>>> Sure. I think the question to use external map or field may be decided
>>> later when/if it will be needed.
>>> Just some statictics, I've collected on nashorn/octane benchmarks
>>> (statistics collected only for the single(first) benchmark iteration:
>>> mandreel: 514 unique strings, toMethodDescriptorString called 69047 times
>>> box2d: 560 unique strings, 34776 toMethodDescriptorString invocations.
>> 
>> Good data; thanks.
>> 
>>> 
>>>> Would there be any benefit from recording the original string from the constant pool?  The JVM path for this is SystemDictionary::find_method_handle_type, which makes an upcall to MethodHandleNatives.findMethodHandleType. Currently only the ptypes and rtype are passed, but the JVM could also convert the internal Symbol to a java.lang.String and pass that also.  In that case, MT's created by JVM upcalls would be pre-equipped with descriptor strings.
>>>> 
>>>> This is probably worth an experiment, although it requires some JVM work.
>>> 
>>> I am definitely sure that we shouldn't do that.
>>> Right now caching desriptor strings is internal decision of MethodType.
>>> Otherwise it will make interfaces more complex.
>> 
>> Yes, I agree.  Also, it would only benefit the 514 calls which introduce unique strings, whereas your change helps the 69047 calls for descriptor strings.
>> 
>>>> I hope you get my overall point:  Hand optimizations have a continuing cost, related to obscuring the logical structure of the code.  The transforming engineer might make a mistake, and later maintaining engineers might also make mistakes.
>>>> 
>>>> https://blogs.oracle.com/jrose/entry/three_software_proverbs
>>> 
>>> And it doesn't mean that we should afraid any kind of optimization.
>>> Lucky positions - someone(or something) will optimize it for us. But
>>> sometimes JIT (even smart JIT) is not enough.
>> 
>> Sometimes.  When that happens we reluctantly hand-optimize our code.
>> 
>>> Let's back to the patch.construstors
>>> I decided not change original checkPType/checkRType code, except
>>> explicit Objects.requireNonNull. The problem here that we are creating
>>> new MethodType objects which are already exists, we have to create MT as
>>> a key for searching in the internedTable. Ratio between already exiting
>>> and new MethodTypes a quite huge.
>>> Here is some statistics I've collected on nashorn/octane benchmarks
>>> (statistics collected only for the single(first) benchmark iteration:
>>> 
>>> mandreel:
>>> - 1739 unique MethodTypes,
>>> - 878414 MethodType.makeImpl requests;
>>> box2d:
>>> - 1861 unique MethodTypes,
>>> - 527486 MethodType.makeImpl requests;
>>> gameboy:
>>> - 2062 unique MethodTypes,
>>> - 311378 MethodType.makeImpl requests;
>>> 
>>> So
>>> 1. MethodType constructor do checkPTypes/checkRType which are frequently
>>> (99%) useless - we already have the same (checked) MethodType in the
>>> internTable.
>>> 2. Less than 1% of created MethodTypes will be stored into internTable,
>>> but reusing that MethodType objects prevent ti from scalar replacement.
>>> (I've heard that Graal may do flow-sensitive scalar replacement, but C2
>>> can't do).
>>> 
>>> What I did. I separate constructors:
>>> - for long lived MethodTypes with all checks,
>>> - for short lived MethodTypes used only as key for searching in the
>>> InterTable, no checks are performed.
>>> if we didn't find  MethodType in the table we always create a new one
>>> (with checks) that is required in less than 1% cases. And we remove at
>>> least one obstacle for scalar replacement. Unfortunately, scalaer
>>> replacement for expression "internTable.get(new MethodType(rtype,
>>> ptypes))" was not performed, the reason may be evaluated, and hope it
>>> would be easier to achieve scalarization in this case.
>> 
>> Brilliant.  I love this.
>> 
>> The constructor signatures are too similar given the subtle difference between their semantics.  Please distort the signature of the extra-sensitive constructor.  (Imagine the wrong one accidentally invoked by helpful IDE code completers.)  Put in a leading int dummy argument, or reverse the parameters, or some similar hack.  (If we had named constructors, we'd hack the name instead.) I admit this is of marginal benefit, since there is only one place where the constructors are called, but it's good style.  If there were more places calling the constructor, we'd absolutely want a clear distinction between checked and unchecked.
>> 
>> If it still makes sense, I wouldn't mind moving the slot-count logic (long/double adjustment) out of checkPType into checkPTypes. But I think that's moot with this much better change.
>> -            slots += checkPtype(ptype);
>> +            checkPtype(ptype);
>> +            if (ptype == double.class || ptype == long.class) {
>> +                slots++;
>> +            }
>> 
>> Good work.  Reviewed.  (You need another reviewer, I think.)
>> 
>> ? John
>> 
> 
> 



From mike.duigou at oracle.com  Fri Sep 27 20:30:56 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 27 Sep 2013 13:30:56 -0700
Subject: RFR: 8023339 & 8023340 : (xs) Refine throws UOE/NPE Conditions
In-Reply-To: 
References: <42F9A023-664B-4AEF-B071-D7315F28400C@oracle.com>
	
Message-ID: 

Corrected before push.

Mike

On Sep 20 2013, at 12:11 , Paul Sandoz wrote:

> Hi Mike,
> 
> You made changes to the documentation of List.replaceAll which does not perform matching:
> 
> 398      * @param operator the operator to apply to each element
> 399      * @throws UnsupportedOperationException if this list is unmodifiable.
> 400      *         Implementations may throw this exception if a matching element
> 401      *         cannot be replaced or if, in general, modification is not
> 402      *         supported
> 403      * @throws NullPointerException if the specified operator is null or
> 404      *         if the operator result is a null value and this list does
> 405      *         not permit null elements
> 406      *         (optional)
> 407      * @since 1.8
> 408      */
> 409     default void replaceAll(UnaryOperator operator) {
> 
> * @throws UnsupportedOperationException if this list is unmodifiable.
> *         Implementations may throw this exception if an element
> *         cannot be replaced or if, in general, modification is not
> *         supported
> 
> ?
> 
> Paul.
> 
> On Sep 17, 2013, at 3:35 PM, Mike Duigou  wrote:
> 
>> Hello all;
>> 
>> Another, hopefully final, attempt at refining the @throws UOE javadoc for Collections.removeIf and the @throws UOE and NPE javadoc for List.replaceAll().
>> 
>> This cycle adopts the verbiage suggested by Paul Sandoz in the last round of 8023339.
>> 
>> Both changesets are combined into a single webrev:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8023340/1/webrev/
>> 
>> Thanks,
>> 
>> Mike
> 



From mike.duigou at oracle.com  Fri Sep 27 20:31:38 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 27 Sep 2013 20:31:38 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130927203206.3B6C762BA9@hg.openjdk.java.net>

Changeset: fbe6f5dbb24f
Author:    mduigou
Date:      2013-09-27 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbe6f5dbb24f

8023339: Refined Collection.removeIf UOE conditions
Reviewed-by: mduigou
Contributed-by: paul.sandoz at oracle.com

! src/share/classes/java/util/Collection.java
! test/java/util/Collection/MOAT.java

Changeset: 91222be67b27
Author:    mduigou
Date:      2013-09-27 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91222be67b27

8023340: Clarify that unmodifiable List.replaceAll() may not throw UOE if there are no items to be replaced.
Reviewed-by: psandoz, jjg

! src/share/classes/java/util/List.java



From dan.xu at oracle.com  Fri Sep 27 20:40:37 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Fri, 27 Sep 2013 13:40:37 -0700
Subject: RFR: JDK-8025128,File.createTempFile fails if prefix is absolute path
Message-ID: <5245ED45.4090700@oracle.com>

Hi,

Recently I made changes in TempDirectory.generateFile() method to 
prevent using invalidparameters to create temporary files. But such 
tight control will bring a compatibility issue. This change is going to 
solve theseproblems. Please help review it. Thanks!

Bug: https://bugs.openjdk.java.net/browse/JDK-8025128
webrev: http://cr.openjdk.java.net/~dxu/8025128/webrev/ 


-Dan


From mike.duigou at oracle.com  Fri Sep 27 22:53:43 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 27 Sep 2013 15:53:43 -0700
Subject: RFR: JDK-8025610 : (xs) Optional constructor and Optional.of should
	explicitly document NPE
Message-ID: 

Hello all;

As pointed out by Roger Riggs, Optional.of (and the private Optional(T) constructor) don't explicitly document throwing NPE in response to a null value despite describing value as "non-null". This changeset improves the documentation to add an @throws NPE tag to the javadoc.

http://cr.openjdk.java.net/~mduigou/JDK-8025610/0/webrev/

Thanks,

Mike

From chris.hegarty at oracle.com  Fri Sep 27 23:06:23 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Sep 2013 16:06:23 -0700
Subject: RFR: JDK-8025128, File.createTempFile fails if prefix is absolute
	path
In-Reply-To: <5245ED45.4090700@oracle.com>
References: <5245ED45.4090700@oracle.com>
Message-ID: <52460F6F.3010702@oracle.com>

Looks ok to me Dan.

-Chris.

On 09/27/2013 01:40 PM, Dan Xu wrote:
> Hi,
>
> Recently I made changes in TempDirectory.generateFile() method to
> prevent using invalidparameters to create temporary files. But such
> tight control will bring a compatibility issue. This change is going to
> solve theseproblems. Please help review it. Thanks!
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8025128
> webrev: http://cr.openjdk.java.net/~dxu/8025128/webrev/
> 
>
> -Dan


From chris.hegarty at oracle.com  Fri Sep 27 23:25:34 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Sep 2013 18:25:34 -0500
Subject: RFR: JDK-8025610 : (xs) Optional constructor and Optional.of
	should explicitly document NPE
In-Reply-To: 
References: 
Message-ID: <7C117DC7-E160-4AD5-8529-383AA18850DB@oracle.com>

Looks good to me Mike.

-Chris

> On 27 Sep 2013, at 17:53, Mike Duigou  wrote:
> 
> Hello all;
> 
> As pointed out by Roger Riggs, Optional.of (and the private Optional(T) constructor) don't explicitly document throwing NPE in response to a null value despite describing value as "non-null". This changeset improves the documentation to add an @throws NPE tag to the javadoc.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8025610/0/webrev/
> 
> Thanks,
> 
> Mike


From Alan.Bateman at oracle.com  Fri Sep 27 23:25:52 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Sep 2013 16:25:52 -0700
Subject: RFR: JDK-8025128, File.createTempFile fails if prefix is absolute
	path
In-Reply-To: <5245ED45.4090700@oracle.com>
References: <5245ED45.4090700@oracle.com>
Message-ID: <52461400.1070308@oracle.com>

On 27/09/2013 13:40, Dan Xu wrote:
> Hi,
>
> Recently I made changes in TempDirectory.generateFile() method to 
> prevent using invalidparameters to create temporary files. But such 
> tight control will bring a compatibility issue. This change is going 
> to solve theseproblems. Please help review it. Thanks!
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8025128
> webrev: http://cr.openjdk.java.net/~dxu/8025128/webrev/ 
> 
Just to add more here, the prefix was originally intended to just the 
prefix to the file name but there are libraries and applications that 
are specifying path names. Your approach to use the file name part looks 
good to me. We may want to consider tightening up the spec a bit in the 
future.

-Alan


From Alan.Bateman at oracle.com  Fri Sep 27 23:39:35 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Sep 2013 16:39:35 -0700
Subject: RFR: JDK-8025610 : (xs) Optional constructor and Optional.of
	should explicitly document NPE
In-Reply-To: 
References: 
Message-ID: <52461737.4030909@oracle.com>

On 27/09/2013 15:53, Mike Duigou wrote:
> Hello all;
>
> As pointed out by Roger Riggs, Optional.of (and the private Optional(T) constructor) don't explicitly document throwing NPE in response to a null value despite describing value as "non-null". This changeset improves the documentation to add an @throws NPE tag to the javadoc.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8025610/0/webrev/
>
Looks okay.

-Alan.


From kumar.x.srinivasan at oracle.com  Fri Sep 27 23:25:21 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Fri, 27 Sep 2013 23:25:21 +0000
Subject: hg: jdk8/tl/langtools: 8015073: c.s.t.javac.api.JavacTool.getTask() -
	more informative exception
Message-ID: <20130927232538.DAAE862BB1@hg.openjdk.java.net>

Changeset: 82044fe8c7f7
Author:    ksrini
Date:      2013-09-27 16:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/82044fe8c7f7

8015073: c.s.t.javac.api.JavacTool.getTask() - more informative exception
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/api/JavacTool.java
! test/tools/javac/api/TestJavacTask.java



From dan.xu at oracle.com  Sat Sep 28 00:04:03 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Fri, 27 Sep 2013 17:04:03 -0700
Subject: RFR: JDK-8025610 : (xs) Optional constructor and Optional.of
	should explicitly document NPE
In-Reply-To: 
References: 
Message-ID: <52461CF3.9030206@oracle.com>

It looks good.

-Dan


On 09/27/2013 03:53 PM, Mike Duigou wrote:
> Hello all;
>
> As pointed out by Roger Riggs, Optional.of (and the private Optional(T) constructor) don't explicitly document throwing NPE in response to a null value despite describing value as "non-null". This changeset improves the documentation to add an @throws NPE tag to the javadoc.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8025610/0/webrev/
>
> Thanks,
>
> Mike



From dan.xu at oracle.com  Sat Sep 28 00:09:49 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Sat, 28 Sep 2013 00:09:49 +0000
Subject: hg: jdk8/tl/jdk: 8025128: File.createTempFile fails if prefix is
	absolute path
Message-ID: <20130928001019.1189862BB6@hg.openjdk.java.net>

Changeset: 754db1268be1
Author:    dxu
Date:      2013-09-27 17:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/754db1268be1

8025128: File.createTempFile fails if prefix is absolute path
Summary: Use only the file name from the supplied prefix for backward compatibility
Reviewed-by: alanb, chegar

! src/share/classes/java/io/File.java
! test/java/io/File/createTempFile/SpecialTempFile.java



From mike.duigou at oracle.com  Sat Sep 28 00:28:34 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Sat, 28 Sep 2013 00:28:34 +0000
Subject: hg: jdk8/tl/jdk: 8025610: Add explicit @throws NPE documentation to
	Optional constructor and Optional.of
Message-ID: <20130928002848.92AAC62BB7@hg.openjdk.java.net>

Changeset: d921ce805abe
Author:    mduigou
Date:      2013-09-27 17:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d921ce805abe

8025610: Add explicit @throws NPE documentation to Optional constructor and Optional.of
Reviewed-by: briangoetz, chegar, alanb

! src/share/classes/java/util/Optional.java



From lana.steuck at oracle.com  Sat Sep 28 02:47:27 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Sep 2013 02:47:27 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20130928024747.25EB862BBC@hg.openjdk.java.net>

Changeset: 428428cf5e06
Author:    tbell
Date:      2013-09-25 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/428428cf5e06

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: 3d2b7ce93c5c
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/3d2b7ce93c5c

Added tag jdk8-b109 for changeset 428428cf5e06

! .hgtags



From lana.steuck at oracle.com  Sat Sep 28 02:47:27 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Sep 2013 02:47:27 +0000
Subject: hg: jdk8/tl: 2 new changesets
Message-ID: <20130928024729.E698262BBB@hg.openjdk.java.net>

Changeset: 91f47e8da5c6
Author:    tbell
Date:      2013-09-25 12:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/91f47e8da5c6

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: 0cc21882d2f6
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/0cc21882d2f6

Added tag jdk8-b109 for changeset 91f47e8da5c6

! .hgtags



From lana.steuck at oracle.com  Sat Sep 28 02:48:10 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Sep 2013 02:48:10 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130928024833.CC1F662BBD@hg.openjdk.java.net>

Changeset: d1e2050e575e
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d1e2050e575e

Added tag jdk8-b109 for changeset 6ec2f9e5ed5b

! .hgtags

Changeset: 982dd6e1bf4f
Author:    lana
Date:      2013-09-27 18:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/982dd6e1bf4f

Merge




From lana.steuck at oracle.com  Sat Sep 28 02:47:47 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Sep 2013 02:47:47 +0000
Subject: hg: jdk8/tl/langtools: 3 new changesets
Message-ID: <20130928024847.6C87E62BC0@hg.openjdk.java.net>

Changeset: 985abf1cd327
Author:    tbell
Date:      2013-09-25 12:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/985abf1cd327

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: 6f11dc295641
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f11dc295641

Added tag jdk8-b109 for changeset 985abf1cd327

! .hgtags

Changeset: 34223fc58c1a
Author:    lana
Date:      2013-09-27 18:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34223fc58c1a

Merge




From lana.steuck at oracle.com  Sat Sep 28 02:47:51 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Sep 2013 02:47:51 +0000
Subject: hg: jdk8/tl/jaxp: 2 new changesets
Message-ID: <20130928024835.76E8B62BBE@hg.openjdk.java.net>

Changeset: 02bfab2aa938
Author:    tbell
Date:      2013-09-25 12:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/02bfab2aa938

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: 4c84c5b447b0
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4c84c5b447b0

Added tag jdk8-b109 for changeset 02bfab2aa938

! .hgtags



From lana.steuck at oracle.com  Sat Sep 28 02:48:55 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Sep 2013 02:48:55 +0000
Subject: hg: jdk8/tl/jdk: 3 new changesets
Message-ID: <20130928025011.4B8CA62BC1@hg.openjdk.java.net>

Changeset: 946f3fd5f8bf
Author:    tbell
Date:      2013-09-25 12:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/946f3fd5f8bf

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties
! makefiles/jprt.properties

Changeset: f8c9a4b80148
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8c9a4b80148

Added tag jdk8-b109 for changeset 946f3fd5f8bf

! .hgtags

Changeset: 0b535e920dd5
Author:    lana
Date:      2013-09-27 18:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b535e920dd5

Merge




From lana.steuck at oracle.com  Sat Sep 28 02:48:10 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Sep 2013 02:48:10 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20130928024840.3F8A062BBF@hg.openjdk.java.net>

Changeset: df5d4d016425
Author:    tbell
Date:      2013-09-25 12:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/df5d4d016425

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: cc682329886b
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/cc682329886b

Added tag jdk8-b109 for changeset df5d4d016425

! .hgtags



From lana.steuck at oracle.com  Sat Sep 28 02:49:16 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Sep 2013 02:49:16 +0000
Subject: hg: jdk8/tl/hotspot: 77 new changesets
Message-ID: <20130928025220.B5BB662BC2@hg.openjdk.java.net>

Changeset: e42e456fbe6e
Author:    amurillo
Date:      2013-09-13 00:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e42e456fbe6e

8024764: new hotspot build - hs25-b51
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: baa7927dfbd2
Author:    zgu
Date:      2013-09-04 08:55 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/baa7927dfbd2

8022798: "assert(seq > 0) failed: counter overflow" in Kitchensink
Summary: Removed incorrect assertion, sequence number can overflow
Reviewed-by: dholmes, kamg

! src/share/vm/services/memPtr.cpp

Changeset: 38f750491293
Author:    iklam
Date:      2013-09-06 08:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/38f750491293

8022335: Native stack walk while generating hs_err does not work on Windows x64
Summary: Use WinDbg API StackWalk64()
Reviewed-by: zgu, dholmes

! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/decoder_windows.hpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/decoder.cpp
! src/share/vm/utilities/decoder.hpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: 592520c14121
Author:    kevinw
Date:      2013-09-09 10:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/592520c14121

8023478: Test fails with HS crash in GCNotifier.
Reviewed-by: sla

! src/share/vm/services/gcNotifier.cpp

Changeset: b6767a18b379
Author:    hseigel
Date:      2013-09-09 14:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6767a18b379

8023167: JVM allows duplicate Runtime[In]VisibleTypeAnnotations attributes in ClassFile/field_info/method_info structures
Summary: Add checks for duplicates and issue errors when detected.
Reviewed-by: coleenp, zgu

! src/share/vm/classfile/classFileParser.cpp

Changeset: 0f648fbe4404
Author:    dsamersoff
Date:      2013-09-11 14:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f648fbe4404

8024056: runtime/InitialThreadOverflow/testme.sh fails
Summary: on some macines gcc not able to link cxx program
Reviewed-by: dholmes

! test/runtime/InitialThreadOverflow/testme.sh

Changeset: 1c6b721a3fbf
Author:    dsamersoff
Date:      2013-09-12 15:53 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c6b721a3fbf

8022617: Openjdk hotspot build is broken on BSD platforms using gcc
Summary: Enforce of preprocessing of all assembly sources by assembler-with-cpp
Reviewed-by: dholmes, erikj

! make/bsd/makefiles/gcc.make

Changeset: 225cedaf9a4b
Author:    zgu
Date:      2013-09-13 10:34 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/225cedaf9a4b

Merge

! src/share/vm/classfile/classFileParser.cpp

Changeset: 623d923529df
Author:    mgronlun
Date:      2013-09-13 17:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/623d923529df

8021353: Event based tracing is missing thread exit
Reviewed-by: allwin, acorn, dcubed, dholmes, egahlin

! src/share/vm/runtime/thread.cpp
! src/share/vm/trace/traceMacros.hpp

Changeset: b89a1a870965
Author:    mgronlun
Date:      2013-09-13 19:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b89a1a870965

Merge

! src/share/vm/runtime/thread.cpp

Changeset: ff8a09595db3
Author:    sspitsyn
Date:      2013-09-13 12:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff8a09595db3

8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed
Summary: Handle pending exceptions instead of firing a guarantee()
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: ce5ee9de50ce
Author:    sspitsyn
Date:      2013-09-13 12:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce5ee9de50ce

8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
Summary: The OOME's in the JVMTI merge_cp_and_rewrite and set_new_constant_pool must be handled correctly
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 0d3ff4d36a31
Author:    sspitsyn
Date:      2013-09-13 12:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0d3ff4d36a31

8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated
Summary: Pending exceptions must be handled properly after a call to the JVMTI merge_cp_and_rewrite
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: b135b600a66c
Author:    sspitsyn
Date:      2013-09-13 16:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b135b600a66c

Merge


Changeset: 2e6938dd68f2
Author:    dholmes
Date:      2013-09-16 07:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e6938dd68f2

6900441: PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock
Summary: Associate CLOCK_MONOTONIC with the pthread_cond_t objects used for relative timed waits
Reviewed-by: dcubed, shade

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp

Changeset: 4472884d8b37
Author:    dcubed
Date:      2013-09-16 12:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4472884d8b37

6986195: correctly identify Ubuntu as the operating system in crash report instead of "Debian"
Summary: Cleanup and document how various Linux release info files are used by print_distro_info().
Reviewed-by: dcubed, dsamersoff, coleenp, iklam, omajid
Contributed-by: gerald.thornbrugh at oracle.com

! src/os/linux/vm/os_linux.cpp

Changeset: 42863137168c
Author:    acorn
Date:      2013-09-16 17:57 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42863137168c

8024647: Default method resolution with private superclass method
Reviewed-by: kamg, minqi

! src/share/vm/classfile/defaultMethods.cpp

Changeset: 921967020b3b
Author:    acorn
Date:      2013-09-16 15:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/921967020b3b

Merge


Changeset: 621eda7235d2
Author:    minqi
Date:      2013-09-16 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/621eda7235d2

7164841: Improvements to the GC log file rotation
Summary: made changes to easily identify current log file in rotation. Parameterize the input with %t for time replacement in file name.
Reviewed-by: ccheung, tschatzl, tamao, zgu
Contributed-by: yumin.qi at oracle.com

! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp

Changeset: 535973ddf22c
Author:    minqi
Date:      2013-09-16 18:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/535973ddf22c

Merge


Changeset: 88d6b9a1c27c
Author:    mseledtsov
Date:      2013-09-17 20:09 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/88d6b9a1c27c

8016029: test runtime/6878713/Test6878713.sh failed
Summary: Rewrote test in Java; updated the test condition to reflect latest changes in the source
Reviewed-by: dholmes, ctornqvi

- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
+ test/runtime/ClassFile/OomWhileParsingRepeatedJsr.java
+ test/runtime/ClassFile/testcase.jar

Changeset: 6f45933aef35
Author:    mseledtsov
Date:      2013-09-17 20:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f45933aef35

7149464: [TESTBUG] Test runtime/7020373/Test7020373.sh failed to clean up files after test
Summary: Re-wrote in Java, this also eliminated temporary result file; set upper limit on malloc'd memory
Reviewed-by: dcubed, dholmes, ccheung

- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar
+ test/runtime/ClassFile/JsrRewriting.java
+ test/runtime/ClassFile/JsrRewritingTestCase.jar

Changeset: 41e6ae9f6dd7
Author:    zgu
Date:      2013-09-18 12:52 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41e6ae9f6dd7

Merge

- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar

Changeset: 8e94527f601e
Author:    bpittore
Date:      2013-09-11 20:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8e94527f601e

8024007: Misc. cleanup of static agent code
Summary: Minor cleanup of static agent code from 8014135
Reviewed-by: dcubed, sspitsyn

! src/os/windows/vm/os_windows.cpp
! src/share/vm/prims/jvmti.xml
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp

Changeset: de88570fabfc
Author:    dholmes
Date:      2013-09-11 00:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de88570fabfc

8024256: Minimal VM build is broken with PCH disabled
Reviewed-by: coleenp, twisti

! make/excludeSrc.make
! src/share/vm/gc_implementation/shared/allocationStats.hpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/utilities/yieldingWorkgroup.hpp

Changeset: 4c9d415db1c5
Author:    dholmes
Date:      2013-09-11 23:49 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c9d415db1c5

Merge


Changeset: b1491b0303ee
Author:    bdelsart
Date:      2013-09-13 07:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b1491b0303ee

Merge


Changeset: 10efeefa6485
Author:    dholmes
Date:      2013-09-13 21:36 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10efeefa6485

8024505: [TESTBUG] update test groups for additional tests that can't run on the minimal VM
Reviewed-by: coleenp, hseigel

! test/TEST.groups

Changeset: cc5b40a76049
Author:    bdelsart
Date:      2013-09-18 21:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc5b40a76049

Merge

! src/share/vm/runtime/thread.cpp

Changeset: 7944aba7ba41
Author:    ehelin
Date:      2013-08-12 17:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7944aba7ba41

8015107: NPG: Use consistent naming for metaspace concepts
Reviewed-by: coleenp, mgerdin, hseigel

! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/arrayOop.hpp
! src/share/vm/oops/instanceOop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryService.cpp
+ test/gc/arguments/TestCompressedClassFlags.java
- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
+ test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
! test/gc/metaspace/TestMetaspaceMemoryPool.java
! test/gc/metaspace/TestMetaspacePerfCounters.java
! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java
! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java
! test/runtime/CompressedOops/CompressedKlassPointerAndOops.java

Changeset: 440edcf30231
Author:    mgerdin
Date:      2013-09-11 08:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/440edcf30231

8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47
Summary: The code for reading compressed klass pointers in the sa-agent on Mac used readCompOopAddress instead of readCompKlassAddress, this is wrong but has been hidden because compressed oops and compressed klasses has used the same base address in the past.
Reviewed-by: sla, jmasa
Contributed-by: stefan.johansson at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java

Changeset: f7bc2ab5f659
Author:    tschatzl
Date:      2013-09-11 10:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7bc2ab5f659

8016825: Large pages for the heap broken on Windows for compressed oops
Summary: Correctly pass the requested base address for the heap to the OS function to reserve memory.
Reviewed-by: brutisso, stefank

! src/os/windows/vm/os_windows.cpp

Changeset: ff218fdb30ba
Author:    tschatzl
Date:      2013-09-11 10:19 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff218fdb30ba

8021823: G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs
Summary: Correctly calculate the initialization value for the shift between object start and bitmap bit in the G1 mark bitmaps.
Reviewed-by: tonyp

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
+ test/gc/TestObjectAlignment.java

Changeset: 040895ec3920
Author:    tschatzl
Date:      2013-09-11 12:03 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/040895ec3920

Merge


Changeset: 24e87613ee58
Author:    mgerdin
Date:      2013-09-11 09:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24e87613ee58

8009561: NPG: Metaspace fragmentation when retiring a Metachunk
Summary: Use best-fit block-splitting freelist allocation from the block freelist.
Reviewed-by: jmasa, stefank

! src/share/vm/memory/metaspace.cpp

Changeset: 6608fa23708f
Author:    mgerdin
Date:      2013-09-11 06:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6608fa23708f

Merge


Changeset: 40136aa2cdb1
Author:    tschatzl
Date:      2013-09-11 16:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40136aa2cdb1

8010722: assert: failed: heap size is too big for compressed oops
Summary: Use conservative assumptions of required alignment for the various garbage collector components into account when determining the maximum heap size that supports compressed oops. Using this conservative value avoids several circular dependencies in the calculation.
Reviewed-by: stefank, dholmes

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp
+ test/gc/arguments/TestUseCompressedOopsErgo.java
+ test/gc/arguments/TestUseCompressedOopsErgoTools.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: b82260e84582
Author:    tschatzl
Date:      2013-09-11 18:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b82260e84582

Merge


Changeset: d6c266999345
Author:    ehelin
Date:      2013-09-12 10:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d6c266999345

8023476: Metaspace capacity > reserved
Reviewed-by: stefank, hseigel, mgerdin

! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp

Changeset: c4c768305a8f
Author:    stefank
Date:      2013-09-12 10:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4c768305a8f

8024638: Count and expose the amount of committed memory in the metaspaces
Reviewed-by: brutisso, ehelin

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp

Changeset: 335b388c4b28
Author:    stefank
Date:      2013-09-13 22:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/335b388c4b28

8024651: Remove the incorrect usage of Metablock::overhead()
Reviewed-by: brutisso, mgerdin, coleenp, jmasa

! src/share/vm/memory/metablock.cpp
! src/share/vm/memory/metablock.hpp
! src/share/vm/memory/metaspace.cpp

Changeset: 9e11762cee52
Author:    stefank
Date:      2013-09-13 22:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e11762cee52

8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize
Reviewed-by: jwilhelm, brutisso, tschatzl

! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp
! src/share/vm/memory/collectorPolicy.cpp
+ test/gc/metaspace/TestMetaspaceSizeFlags.java
! test/testlibrary/OutputAnalyzerTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java

Changeset: 8227700da288
Author:    stefank
Date:      2013-09-13 22:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8227700da288

8024751: Fix bugs in TraceMetadata
Reviewed-by: jmasa, brutisso

! src/share/vm/memory/metaspace.cpp

Changeset: 8c5e6482cbfc
Author:    stefank
Date:      2013-09-13 22:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c5e6482cbfc

8024752: Log TraceMetadata* output to gclog_or_tty instead of tty
Reviewed-by: brutisso, mgerdin, coleenp

! src/share/vm/memory/metaspace.cpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp

Changeset: 9cb63cd234a0
Author:    shade
Date:      2013-09-13 07:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9cb63cd234a0

8024671: G1 generates assert error messages in product builds
Reviewed-by: brutisso, tschatzl

! src/share/vm/gc_implementation/g1/g1CardCounts.cpp
! src/share/vm/gc_implementation/g1/g1CardCounts.hpp

Changeset: 884ed7a10f09
Author:    tschatzl
Date:      2013-09-16 09:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/884ed7a10f09

Merge

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 23ae5a04724d
Author:    tschatzl
Date:      2013-09-16 10:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23ae5a04724d

8024396: VM crashing with assert(!UseLargePages || UseParallelOldGC || use_large_pages) failed: Wrong alignment to use large pages
Summary: Loosen wrong assert for UseParallelOldGC to UseParallelGC
Reviewed-by: stefank, brutisso

! src/share/vm/memory/universe.cpp
+ test/gc/arguments/TestAlignmentToUseLargePages.java

Changeset: f9b58dbeab91
Author:    tschatzl
Date:      2013-09-16 13:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9b58dbeab91

Merge


Changeset: 17deed6716af
Author:    tschatzl
Date:      2013-09-17 12:04 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/17deed6716af

8024914: Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp
Summary: Incorrect usage of idx_t where bm_word_t is appropriate.
Reviewed-by: tschatzl, brutisso
Contributed-by: Dan Horak 

! src/share/vm/utilities/bitMap.inline.hpp

Changeset: 5767996b7b7b
Author:    jwilhelm
Date:      2013-09-17 14:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5767996b7b7b

8024884: Test name changed, test list not updated
Summary: Updated the test list with the new test name.
Reviewed-by: brutisso, ehelin

! test/TEST.groups

Changeset: fac394091d73
Author:    jwilhelm
Date:      2013-09-18 00:08 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fac394091d73

Merge


Changeset: 73d0d0218068
Author:    ehelin
Date:      2013-09-17 20:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73d0d0218068

8024718: Metaspace performance counters and memory pools should report the same data
Reviewed-by: stefank, dholmes, coleenp

! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/metaspaceCounters.hpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryPool.hpp
! src/share/vm/services/memoryUsage.hpp
! test/gc/metaspace/TestMetaspaceMemoryPool.java
! test/gc/metaspace/TestMetaspacePerfCounters.java
+ test/gc/metaspace/TestPerfCountersAndMemoryPools.java
! test/testlibrary/com/oracle/java/testlibrary/InputArguments.java

Changeset: 2f426063daea
Author:    tschatzl
Date:      2013-09-18 10:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f426063daea

8024662: gc/arguments/TestUseCompressedOopsErgo.java does not compile.
Summary: Fix compilation error and use of an outdated VM option in the test
Reviewed-by: stefank, jwilhelm

! test/gc/arguments/TestUseCompressedOopsErgoTools.java

Changeset: 9044964f9163
Author:    tschatzl
Date:      2013-09-18 13:18 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9044964f9163

8024669: Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9
Summary: After changes in 8010722 the ergonomics for calculating the size of the heap that supports zero based compressed oops changed. This lead to the VM actually using zero based compressed oops. Due to low default HeapBaseMinAddress, the OS mapping in the application image at the same address, and limitations of the malloc implementation on Solaris this resulted in very little C heap available for the VM. So the VM immediately gives a native OOME when the machine has lots of physical memory (>=32G). The solution is to increase the HeapBaseMinAddress so that the VM has enough C heap.
Reviewed-by: kvn, brutisso

! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp

Changeset: 719e886d4f72
Author:    tschatzl
Date:      2013-09-18 15:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/719e886d4f72

Merge


Changeset: 06ae47d9d088
Author:    tschatzl
Date:      2013-09-19 09:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06ae47d9d088

Merge

! src/os/linux/vm/os_linux.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp
- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java

Changeset: 179cd89fb279
Author:    tschatzl
Date:      2013-09-19 09:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/179cd89fb279

Merge

! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
! test/TEST.groups

Changeset: 8c83625e3a53
Author:    adlertz
Date:      2013-09-12 23:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c83625e3a53

8024646: Remove LRG_List container, replace it with GrowableArray
Summary: We already have GrowableArray, use it instead of LRG_List
Reviewed-by: kvn

! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/coalesce.hpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/live.hpp

Changeset: 3a4e6c929bf3
Author:    twisti
Date:      2013-09-12 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a4e6c929bf3

8024275: During CTW: assert(sig_bt[member_arg_pos] == T_OBJECT) failed: dispatch argument must be an object
Reviewed-by: kvn, vlivanov

! src/share/vm/classfile/classLoader.cpp

Changeset: 591b49112612
Author:    twisti
Date:      2013-09-12 18:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/591b49112612

Merge


Changeset: 01b268b3080a
Author:    vlivanov
Date:      2013-09-13 04:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01b268b3080a

8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log)
Reviewed-by: twisti, kvn, sla

! src/share/tools/LogCompilation/README
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/ostream.cpp

Changeset: 69f26e8e09f9
Author:    twisti
Date:      2013-09-13 16:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69f26e8e09f9

8024760: add more types, fields and constants to VMStructs
Reviewed-by: kvn, coleenp

! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! src/share/vm/gc_implementation/g1/ptrQueue.hpp
! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ae3e68933caf
Author:    adlertz
Date:      2013-09-17 05:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae3e68933caf

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 22194f27fbfb
Author:    ctornqvi
Date:      2013-09-17 16:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22194f27fbfb

8014905: [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk
Summary: Change JDKToolFinder to look in compile.jdk if the executable cannot be found in test.jdk
Reviewed-by: dholmes, hseigel

! test/TEST.groups
! test/gc/TestVerifyDuringStartup.java
! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java

Changeset: 2c98370f2611
Author:    ctornqvi
Date:      2013-09-17 23:12 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c98370f2611

Merge


Changeset: 6d7eba360ba4
Author:    anoll
Date:      2013-09-17 08:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d7eba360ba4

8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation
Summary: Increase interpreter size for x86 template interpreter
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/templateInterpreter_x86.hpp

Changeset: a4788ba67e20
Author:    adlertz
Date:      2013-09-17 16:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a4788ba67e20

Merge


Changeset: b2e698d2276c
Author:    drchase
Date:      2013-09-13 22:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2e698d2276c

8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation
Summary: Enhance method resolution and resulting data structures, plus some refactoring.
Reviewed-by: twisti, acorn, jrose

! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciField.hpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciSymbol.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp
! src/share/vm/oops/fieldStreams.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/fieldDescriptor.cpp
! src/share/vm/runtime/fieldDescriptor.hpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/reflectionUtils.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 67bae56fdd69
Author:    jrose
Date:      2013-09-17 20:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/67bae56fdd69

Merge


Changeset: ab274453d37f
Author:    anoll
Date:      2013-09-18 07:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab274453d37f

8022883: Assertion failed: sweptCount >= flushedCount + markedCount + zombifiedCount
Summary: Provide correct number of visited nmethods to Tracing
Reviewed-by: kvn, iveresov

! src/share/vm/runtime/sweeper.cpp

Changeset: 04cbe2026912
Author:    rbackman
Date:      2013-09-18 09:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04cbe2026912

Merge


Changeset: 2795dff62b6c
Author:    iveresov
Date:      2013-09-18 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2795dff62b6c

8023542: Test java/io/File/CheckPermission.java fails due to unfinished recursion (java.lang.StackOverflowError) when JIT'ed code (-client,-server) is running
Summary: Move null check before klass reference materialization in checkcast
Reviewed-by: kvn, roland

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: da051ce490eb
Author:    adlertz
Date:      2013-09-19 18:01 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da051ce490eb

Merge

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/ostream.cpp
! test/TEST.groups

Changeset: 566db1b0e6ef
Author:    amurillo
Date:      2013-09-20 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/566db1b0e6ef

Merge

- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar

Changeset: bf13c3da3d11
Author:    amurillo
Date:      2013-09-20 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf13c3da3d11

Added tag hs25-b51 for changeset 566db1b0e6ef

! .hgtags

Changeset: c81dd5393a5e
Author:    tbell
Date:      2013-09-25 12:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c81dd5393a5e

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: fff4842215d1
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fff4842215d1

Added tag jdk8-b109 for changeset c81dd5393a5e

! .hgtags



From aleksej.efimov at oracle.com  Sat Sep 28 14:54:34 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Sat, 28 Sep 2013 18:54:34 +0400
Subject: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH
	NODE LIST OF LENGTH =1 IN JAXP
In-Reply-To: <5244811E.3040207@oracle.com>
References: <5238449D.50509@oracle.com> <523B6A7D.3080501@oracle.com>
	<5242C4AE.4060305@oracle.com> <5244811E.3040207@oracle.com>
Message-ID: <5246EDAA.3080006@oracle.com>

Joe,
Thank you for a suggestion. But I modified it a little bit:

      public Node item(int index) {
          if (m_iter != null) {
-            int node;
+            int node = 0;
              int count = m_cachedNodes.size();
  
              if (count > index) {
                  node = m_cachedNodes.elementAt(index);
                  return m_dtm.getNode(node);
              } else if (m_last == -1) {
-                while (((node = m_iter.next()) != DTMAxisIterator.END)
-                           && count <= index) {
+                while (count <= index
+                        && ((node = m_iter.next()) != DTMAxisIterator.END)) {
                      m_cachedNodes.addElement(node);
                      count++;
                  }


We need a value assigned to 'node' to avoid compilation error with 
uninitialized 'node' variable. But this value doesn't mean nothing (let 
it be 0) because for the first while loop iteration the second "&&" 
condition will be always executed (we can reach the while loop only when 
"count<=index" - the outer if-else condition). The test passes with this 
new version.
As the result - new webrev: 
http://cr.openjdk.java.net/~aefimov/8024707/webrev.01/ 


Best Regards,
Aleksej

On 09/26/2013 10:46 PM, huizhe wang wrote:
> Hi Aleksej,
>
> From your tests, it appears that the getLength() method was 
> implemented correctly, and that the bug is not in the call to 
> m_iter.next(), but it should not be called again once the count is > 
> index.  So that fix would be to move the conditions around such that:
>     public Node item(int index) {
>         if (m_iter != null) {
>             int node;
>             int count = m_cachedNodes.size();
>
>             if (count > index) {
>                 node = m_cachedNodes.elementAt(index);
>                 return m_dtm.getNode(node);
>             } else if (m_last == -1) {
> -                while (((node = m_iter.next()) != DTMAxisIterator.END)
> -                           && count <= index) {
> +                while (count <= index
> +                           && ((node = m_iter.next()) != 
> DTMAxisIterator.END)) {
>                     m_cachedNodes.addElement(node);
>                     count++;
>                 }
>                 if (node == DTMAxisIterator.END) {
>                     m_last = count;
>                 } else {
>                     return m_dtm.getNode(node);
>                 }
>             }
>         }
>         return null;
>     }
>
> Thanks,
> Joe
>
>
> On 9/25/2013 4:10 AM, Aleksej Efimov wrote:
>> Hi Joe,
>> Your suggestion about getLength() brings to mine attention the 
>> following behavior of unmodified JDK:
>> If we slightly modify a TestFunc class [1] in such manner:
>>
>>     public static Node test( NodeList list ) {
>>                  Node ret = list.item(0);
>>                  System.err.println(list.getLength());
>>                  return ret;
>>     }
>>
>> And add more elements to in.xml:
>> inp1_1inp1_2inp1_3
>>
>> The test will fails:
>>
>>     2
>>     Transformation completed. Result:>     encoding="UTF-8"?>inp1_2
>>     Exception in thread "main" java.lang.RuntimeException: Incorrect
>>     transformation result
>>         at XSLT.main(XSLT.java:49)
>>
>> As you can see the length of 2 is incorrect value and the 'inp1_1' 
>> element is ignored. But If we do another one change to test function 
>> - first get the length() and then get the item:
>>
>>     public static Node test( NodeList list ) {
>>     	    System.err.println(list.getLength());
>>                  Node ret = list.item(0);
>>                  return ret;
>>     }
>>
>> The test will pass:
>>
>>     3
>>     Transformation completed. Result:>     encoding="UTF-8"?>inp1_1
>>
>> This behavior tells that item() method incorrectly caches the nodes 
>> (The method called first - do the caching). But the caching of nodes 
>> is done in correct way by getLength() function, but its according to 
>> the test results. Currently, I'm trying to understand why it's 
>> working in such way in a view of source code.
>>
>> -Aleksej
>>
>>
>>
>> [1] 
>> http://cr.openjdk.java.net/~aefimov/8024707/jdk/test/javax/xml/jaxp/parsers/8024707/TestFunc.java 
>> 
>>
>> On 09/20/2013 01:19 AM, huizhe wang wrote:
>>> Hi Aleksej,
>>>
>>> Looks like the getLength() method has the same problem.
>>>
>>> Joe
>>>
>>> On 9/17/2013 5:01 AM, Aleksej Efimov wrote:
>>>> Hi Everyone,
>>>>
>>>> There is a bug [1] in JAXP about transformation of one-item sized 
>>>> node list:
>>>> When the length of nodelist which is passed to a XSLT extension 
>>>> function is 1, the node gotten from the node list becomes null.
>>>> New test illustrates this issue [2]. Full webrev with proposed fix 
>>>> can be found here: [3].
>>>>
>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707
>>>> [2] 
>>>> http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java
>>>> [3] http://cr.openjdk.java.net/~aefimov/8024707/
>>>>
>>>> Best regards,
>>>> Aleksej
>>>
>>
>



From eric.mccorkle at oracle.com  Sat Sep 28 21:37:59 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Sat, 28 Sep 2013 21:37:59 +0000
Subject: hg: jdk8/tl/langtools: 8025413: NPE in Type.java due to recent change
Message-ID: <20130928213806.D7FF462BD2@hg.openjdk.java.net>

Changeset: 84161510f257
Author:    emc
Date:      2013-09-28 13:46 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84161510f257

8025413: NPE in Type.java due to recent change
Summary: isCompound throws a NPE for noType and other types.  Made it return a reasonable result instead.
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/code/Type.java
+ test/tools/javac/processing/model/type/InheritedAP.java



From joe.darcy at oracle.com  Mon Sep 30 06:31:00 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 29 Sep 2013 23:31:00 -0700
Subject: RFR: 8007072: Update Core Reflection for Type Annotations to
	match latest spec
In-Reply-To: <20130917095324.GD368@jfranck-desktop.jrpg.bea.com>
References: <20130917095324.GD368@jfranck-desktop.jrpg.bea.com>
Message-ID: <52491AA4.6090509@oracle.com>

Hi Joel,

Sorry for the belated review. The changes look good other than the 
"AnnotaetdType" typo in the GetAnnotatedReceiverType.java test.

Thanks,

-Joe

On 9/17/2013 2:53 AM, Joel Borggren-Franck wrote:
> Hi,
>
> Here is an update to the javadoc and implementation of reflection for
> type annotations.
>
> The biggest change is an update to the javadoc of Class and Executable
> to match return types of the getGeneric* functions. That is, when
> getGenericFoo returns an empty array getAnnotatedFoo should return an
> empty array. Likewise for null.
>
> Also the javadoc wording is updated to better match the style of
> existing docs, for example type names in {@code }.
>
> Change is actually quite small:
>
> http://cr.openjdk.java.net/~jfranck/8007072/webrev.00/
>
> Two of the three bugs fixed:
>
> https://bugs.openjdk.java.net/browse/JDK-8007072
> https://bugs.openjdk.java.net/browse/JDK-8024915
>
> Please review.
>
> cheers
> /Joel



From joe.darcy at oracle.com  Mon Sep 30 06:56:13 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 29 Sep 2013 23:56:13 -0700
Subject: RFR: 8009719: core reflection should get type annotation data
	from the VM lazily
In-Reply-To: <20130923140018.GG15298@jfranck-desktop.jrpg.bea.com>
References: <20130921142647.GA9897@jfranck-desktop.jrpg.bea.com>
	<20130923140018.GG15298@jfranck-desktop.jrpg.bea.com>
Message-ID: <5249208D.6000800@oracle.com>

Hi Joel,

Libraries portion of the changeset looks fine.

Cheers,

-Joe

On 9/23/2013 7:00 AM, Joel Borggren-Franck wrote:
> Hi all,
>
> Updated webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.02/
>
> Adds Field.c to make/java/java/FILES_c.gmk (old build)
> Renames parameter in Field.c from method to field
>
> Thanks for the suggestions/fixes!
>
> cheers
> /Joel
>
> On 2013-09-21, Joel Borggren-Franck wrote:
>> Hi
>>
>> A while ago [1] I introduced an extra field in to j.l.r.Method,
>> j.l.r.Constructor, and j.l.r.Field in order to support reflection for
>> type annotations. These fields were intended to be removed later, they
>> were there to make the coordination between VM and libraries easier when
>> implementing reflection for type annotations.
>>
>> This change removes the fields. Reflection for type annotations simply
>> get the bytes from the vm lazily when it needs them. Because reflection
>> for type annotations is suspected to be fairly uncommon and not
>> performance critical no caching is done. This can be changed later.
>>
>> The vm side of things were pushed a while back [2], this is the JDK side
>> of the changes.
>>
>> This is a refactoring, all current annotation and type annotation tests
>> pass after this change.
>>
>> Webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.01/
>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8009719
>>
>> Also including build-dev since I needed to update the mapfiles. To my
>> knowledge I have updated both the old and the new build.
>>
>> Please review
>>
>> cheers
>> /Joel
>>
>> [1] : http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d977f61af5e
>> [2] : http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1916ca1dec2f



From joel.franck at oracle.com  Mon Sep 30 10:18:26 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Mon, 30 Sep 2013 10:18:26 +0000
Subject: hg: jdk8/tl/jdk: 8007072: Update Core Reflection for Type Annotations
	to match latest spec; ...
Message-ID: <20130930101915.B7DFC62BF4@hg.openjdk.java.net>

Changeset: 15955d335cd0
Author:    jfranck
Date:      2013-09-30 11:18 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15955d335cd0

8007072: Update Core Reflection for Type Annotations to match latest spec
8022324: j.l.Class.getAnnotatedInterfaces() for array type returns wrong value
8024915: j.l.r.Executable.getAnnotatedReceiverType() should return null for static methods
Summary: Update javadoc and implementation of reflection for type annotations to match latest spec
Reviewed-by: darcy

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/AnnotatedArrayType.java
! src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java
! src/share/classes/java/lang/reflect/AnnotatedType.java
! src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java
! src/share/classes/java/lang/reflect/AnnotatedWildcardType.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java
! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java
+ test/java/lang/annotation/typeAnnotations/GetAnnotatedInterfaces.java
+ test/java/lang/annotation/typeAnnotations/GetAnnotatedReceiverType.java
! test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java



From joel.franck at oracle.com  Mon Sep 30 10:32:42 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Mon, 30 Sep 2013 10:32:42 +0000
Subject: hg: jdk8/tl/jdk: 8009719: core reflection should get type annotation
	data from the VM lazily
Message-ID: <20130930103258.2996262BF5@hg.openjdk.java.net>

Changeset: 89174cddaec8
Author:    jfranck
Date:      2013-09-30 12:19 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89174cddaec8

8009719: core reflection should get type annotation data from the VM lazily
Summary: Remove typeAnnotations field from Method, Constructor, and Field, update  Executable and Field to fetch data on demand.
Reviewed-by: darcy, erikj

! make/java/java/FILES_c.gmk
! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/javavm/export/jvm.h
! src/share/native/java/lang/reflect/Executable.c
+ src/share/native/java/lang/reflect/Field.c



From staffan.larsen at oracle.com  Mon Sep 30 10:58:55 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Mon, 30 Sep 2013 10:58:55 +0000
Subject: hg: jdk8/tl/jdk: 8023492: jfr.jar gets loaded even though it's not
	used
Message-ID: <20130930105923.23E3F62BF6@hg.openjdk.java.net>

Changeset: cceaad499685
Author:    sla
Date:      2013-09-30 12:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cceaad499685

8023492: jfr.jar gets loaded even though it's not used
Reviewed-by: erikj, mgronlun

! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java



From joel.franck at oracle.com  Mon Sep 30 11:49:01 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Mon, 30 Sep 2013 13:49:01 +0200
Subject: RFR: 8009719: core reflection should get type annotation data
	from the VM lazily
In-Reply-To: <5240656A.8010906@oracle.com>
	
	<5249208D.6000800@oracle.com>
Message-ID: <20130930114900.GA1969@jfranck-desktop.jrpg.bea.com>

 Erik, Joe, Robert,

 Thanks for the reviews, just pushed this to TL

 cheers
 /Joel


From joel.franck at oracle.com  Mon Sep 30 13:38:50 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Mon, 30 Sep 2013 13:38:50 +0000
Subject: hg: jdk8/tl/jdk: 8012923: [parfait] File Descriptor Leak in
	jdk/src/windows/demo/jvmti/hprof/hprof_md.c
Message-ID: <20130930133924.3D7BB62BFD@hg.openjdk.java.net>

Changeset: ede1fd12e0da
Author:    allwin
Date:      2013-09-30 14:28 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ede1fd12e0da

8012923: [parfait] File Descriptor Leak in jdk/src/windows/demo/jvmti/hprof/hprof_md.c
Reviewed-by: chegar, sla, sspitsyn, mgronlun

! src/windows/demo/jvmti/hprof/hprof_md.c



From taras.ledkov at oracle.com  Fri Sep 27 12:01:12 2013
From: taras.ledkov at oracle.com (taras ledkov)
Date: Fri, 27 Sep 2013 16:01:12 +0400
Subject: Review: demo extension methods (it is illustrates the feature default
	method usage)
Message-ID: <52457388.4000308@oracle.com>

Hi guys,

We want to push our demo code for extension methods feature
Could you please review this code?
http://cr.openjdk.java.net/~anazarov/extension-methods/webrev0.0/

-- 
With best regards,
Taras Ledkov
Mail-To: taras.ledkov at oracle.com
skype: taras_ledkov
Phone: 7(812)3346-157


From alexandre.iline at oracle.com  Fri Sep 27 13:38:18 2013
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Fri, 27 Sep 2013 06:38:18 -0700
Subject: Review: demo extension methods (it is illustrates the feature
	default method usage)
In-Reply-To: <52457388.4000308@oracle.com>
References: <52457388.4000308@oracle.com>
Message-ID: <52458A4A.3050603@oracle.com>

Taras,

It is yet an open question as to whether we are to publish demos with 
the NetBeans project and tests or just the code.

Until that is decided I suggest you only provide for the review the code 
which is the actual demo code.

Thank you.

Shura

On 9/27/13 5:01 AM, taras ledkov wrote:
> Hi guys,
>
> We want to push our demo code for extension methods feature
> Could you please review this code?
> http://cr.openjdk.java.net/~anazarov/extension-methods/webrev0.0/
>



From taras.ledkov at oracle.com  Mon Sep 30 12:30:49 2013
From: taras.ledkov at oracle.com (taras ledkov)
Date: Mon, 30 Sep 2013 16:30:49 +0400
Subject: Review: demo extension methods (it is illustrates the feature default
	method usage)
In-Reply-To: <52457388.4000308@oracle.com>
References: <52457388.4000308@oracle.com>
Message-ID: <52496EF9.9090007@oracle.com>

Hi guys,

We want to push our demo code for extension methods feature
Could you please review this code?
http://cr.openjdk.java.net/~anazarov/extension-methods/webrev.00/


-- 
With best regards,
Taras Ledkov
Mail-To: taras.ledkov at oracle.com
skype: taras_ledkov
Phone: 7(812)3346-157


From huizhe.wang at oracle.com  Mon Sep 30 17:23:46 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 30 Sep 2013 10:23:46 -0700
Subject: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH
	NODE LIST OF LENGTH =1 IN JAXP
In-Reply-To: <5246EDAA.3080006@oracle.com>
References: <5238449D.50509@oracle.com> <523B6A7D.3080501@oracle.com>
	<5242C4AE.4060305@oracle.com> <5244811E.3040207@oracle.com>
	<5246EDAA.3080006@oracle.com>
Message-ID: <5249B3A2.60604@oracle.com>

Aleksej,

The change looks good.

Thanks,
Joe

On 9/28/2013 7:54 AM, Aleksej Efimov wrote:
> Joe,
> Thank you for a suggestion. But I modified it a little bit:
>       public Node item(int index) {
>           if (m_iter != null) {
> -            int node;
> +            int node = 0;
>               int count = m_cachedNodes.size();
>   
>               if (count > index) {
>                   node = m_cachedNodes.elementAt(index);
>                   return m_dtm.getNode(node);
>               } else if (m_last == -1) {
> -                while (((node = m_iter.next()) != DTMAxisIterator.END)
> -                           && count <= index) {
> +                while (count <= index
> +                        && ((node = m_iter.next()) != DTMAxisIterator.END)) {
>                       m_cachedNodes.addElement(node);
>                       count++;
>                   }
> We need a value assigned to 'node' to avoid compilation error with 
> uninitialized 'node' variable. But this value doesn't mean nothing 
> (let it be 0) because for the first while loop iteration the second 
> "&&" condition will be always executed (we can reach the while loop 
> only when "count<=index" - the outer if-else condition). The test 
> passes with this new version.
> As the result - new webrev: 
> http://cr.openjdk.java.net/~aefimov/8024707/webrev.01/ 
> 
>
> Best Regards,
> Aleksej
>
> On 09/26/2013 10:46 PM, huizhe wang wrote:
>> Hi Aleksej,
>>
>> From your tests, it appears that the getLength() method was 
>> implemented correctly, and that the bug is not in the call to 
>> m_iter.next(), but it should not be called again once the count is > 
>> index.  So that fix would be to move the conditions around such that:
>>     public Node item(int index) {
>>         if (m_iter != null) {
>>             int node;
>>             int count = m_cachedNodes.size();
>>
>>             if (count > index) {
>>                 node = m_cachedNodes.elementAt(index);
>>                 return m_dtm.getNode(node);
>>             } else if (m_last == -1) {
>> -                while (((node = m_iter.next()) != DTMAxisIterator.END)
>> -                           && count <= index) {
>> +                while (count <= index
>> +                           && ((node = m_iter.next()) != 
>> DTMAxisIterator.END)) {
>>                     m_cachedNodes.addElement(node);
>>                     count++;
>>                 }
>>                 if (node == DTMAxisIterator.END) {
>>                     m_last = count;
>>                 } else {
>>                     return m_dtm.getNode(node);
>>                 }
>>             }
>>         }
>>         return null;
>>     }
>>
>> Thanks,
>> Joe
>>
>>
>> On 9/25/2013 4:10 AM, Aleksej Efimov wrote:
>>> Hi Joe,
>>> Your suggestion about getLength() brings to mine attention the 
>>> following behavior of unmodified JDK:
>>> If we slightly modify a TestFunc class [1] in such manner:
>>>
>>>     public static Node test( NodeList list ) {
>>>                  Node ret = list.item(0);
>>>                  System.err.println(list.getLength());
>>>                  return ret;
>>>     }
>>>
>>> And add more elements to in.xml:
>>> inp1_1inp1_2inp1_3
>>>
>>> The test will fails:
>>>
>>>     2
>>>     Transformation completed. Result:>>     encoding="UTF-8"?>inp1_2
>>>     Exception in thread "main" java.lang.RuntimeException: Incorrect
>>>     transformation result
>>>         at XSLT.main(XSLT.java:49)
>>>
>>> As you can see the length of 2 is incorrect value and the 'inp1_1' 
>>> element is ignored. But If we do another one change to test function 
>>> - first get the length() and then get the item:
>>>
>>>     public static Node test( NodeList list ) {
>>>     	    System.err.println(list.getLength());
>>>                  Node ret = list.item(0);
>>>                  return ret;
>>>     }
>>>
>>> The test will pass:
>>>
>>>     3
>>>     Transformation completed. Result:>>     encoding="UTF-8"?>inp1_1
>>>
>>> This behavior tells that item() method incorrectly caches the nodes 
>>> (The method called first - do the caching). But the caching of nodes 
>>> is done in correct way by getLength() function, but its according to 
>>> the test results. Currently, I'm trying to understand why it's 
>>> working in such way in a view of source code.
>>>
>>> -Aleksej
>>>
>>>
>>>
>>> [1] 
>>> http://cr.openjdk.java.net/~aefimov/8024707/jdk/test/javax/xml/jaxp/parsers/8024707/TestFunc.java 
>>> 
>>>
>>> On 09/20/2013 01:19 AM, huizhe wang wrote:
>>>> Hi Aleksej,
>>>>
>>>> Looks like the getLength() method has the same problem.
>>>>
>>>> Joe
>>>>
>>>> On 9/17/2013 5:01 AM, Aleksej Efimov wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> There is a bug [1] in JAXP about transformation of one-item sized 
>>>>> node list:
>>>>> When the length of nodelist which is passed to a XSLT extension 
>>>>> function is 1, the node gotten from the node list becomes null.
>>>>> New test illustrates this issue [2]. Full webrev with proposed fix 
>>>>> can be found here: [3].
>>>>>
>>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707
>>>>> [2] 
>>>>> http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java
>>>>> [3] http://cr.openjdk.java.net/~aefimov/8024707/
>>>>>
>>>>> Best regards,
>>>>> Aleksej
>>>>
>>>
>>
>



From Lance.Andersen at oracle.com  Mon Sep 30 18:31:29 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 30 Sep 2013 14:31:29 -0400
Subject: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH NODE
	LIST OF LENGTH =1 IN JAXP
In-Reply-To: <5249B3A2.60604@oracle.com>
References: <5238449D.50509@oracle.com> <523B6A7D.3080501@oracle.com>
	<5242C4AE.4060305@oracle.com> <5244811E.3040207@oracle.com>
	<5246EDAA.3080006@oracle.com> <5249B3A2.60604@oracle.com>
Message-ID: <4A721C02-7C84-42FC-8AF3-8ADC4B69956D@oracle.com>

+1
On Sep 30, 2013, at 1:23 PM, huizhe wang wrote:

> Aleksej,
> 
> The change looks good.
> 
> Thanks,
> Joe
> 
> On 9/28/2013 7:54 AM, Aleksej Efimov wrote:
>> Joe,
>> Thank you for a suggestion. But I modified it a little bit:
>>      public Node item(int index) {
>>          if (m_iter != null) {
>> -            int node;
>> +            int node = 0;
>>              int count = m_cachedNodes.size();
>>                if (count > index) {
>>                  node = m_cachedNodes.elementAt(index);
>>                  return m_dtm.getNode(node);
>>              } else if (m_last == -1) {
>> -                while (((node = m_iter.next()) != DTMAxisIterator.END)
>> -                           && count <= index) {
>> +                while (count <= index
>> +                        && ((node = m_iter.next()) != DTMAxisIterator.END)) {
>>                      m_cachedNodes.addElement(node);
>>                      count++;
>>                  }
>> We need a value assigned to 'node' to avoid compilation error with uninitialized 'node' variable. But this value doesn't mean nothing (let it be 0) because for the first while loop iteration the second "&&" condition will be always executed (we can reach the while loop only when "count<=index" - the outer if-else condition). The test passes with this new version.
>> As the result - new webrev: http://cr.openjdk.java.net/~aefimov/8024707/webrev.01/ 
>> 
>> Best Regards,
>> Aleksej
>> 
>> On 09/26/2013 10:46 PM, huizhe wang wrote:
>>> Hi Aleksej,
>>> 
>>> From your tests, it appears that the getLength() method was implemented correctly, and that the bug is not in the call to m_iter.next(), but it should not be called again once the count is > index.  So that fix would be to move the conditions around such that:
>>>    public Node item(int index) {
>>>        if (m_iter != null) {
>>>            int node;
>>>            int count = m_cachedNodes.size();
>>> 
>>>            if (count > index) {
>>>                node = m_cachedNodes.elementAt(index);
>>>                return m_dtm.getNode(node);
>>>            } else if (m_last == -1) {
>>> -                while (((node = m_iter.next()) != DTMAxisIterator.END)
>>> -                           && count <= index) {
>>> +                while (count <= index
>>> +                           && ((node = m_iter.next()) != DTMAxisIterator.END)) {
>>>                    m_cachedNodes.addElement(node);
>>>                    count++;
>>>                }
>>>                if (node == DTMAxisIterator.END) {
>>>                    m_last = count;
>>>                } else {
>>>                    return m_dtm.getNode(node);
>>>                }
>>>            }
>>>        }
>>>        return null;
>>>    }
>>> 
>>> Thanks,
>>> Joe
>>> 
>>> 
>>> On 9/25/2013 4:10 AM, Aleksej Efimov wrote:
>>>> Hi Joe,
>>>> Your suggestion about getLength() brings to mine attention the following behavior of unmodified JDK:
>>>> If we slightly modify a TestFunc class [1] in such manner:
>>>> 
>>>>    public static Node test( NodeList list ) {
>>>>                 Node ret = list.item(0);
>>>>                 System.err.println(list.getLength());
>>>>                 return ret;
>>>>    }
>>>> 
>>>> And add more elements to in.xml:
>>>> inp1_1inp1_2inp1_3
>>>> 
>>>> The test will fails:
>>>> 
>>>>    2
>>>>    Transformation completed. Result:>>>    encoding="UTF-8"?>inp1_2
>>>>    Exception in thread "main" java.lang.RuntimeException: Incorrect
>>>>    transformation result
>>>>        at XSLT.main(XSLT.java:49)
>>>> 
>>>> As you can see the length of 2 is incorrect value and the 'inp1_1' element is ignored. But If we do another one change to test function - first get the length() and then get the item:
>>>> 
>>>>    public static Node test( NodeList list ) {
>>>>    	    System.err.println(list.getLength());
>>>>                 Node ret = list.item(0);
>>>>                 return ret;
>>>>    }
>>>> 
>>>> The test will pass:
>>>> 
>>>>    3
>>>>    Transformation completed. Result:>>>    encoding="UTF-8"?>inp1_1
>>>> 
>>>> This behavior tells that item() method incorrectly caches the nodes (The method called first - do the caching). But the caching of nodes is done in correct way by getLength() function, but its according to the test results. Currently, I'm trying to understand why it's working in such way in a view of source code.
>>>> 
>>>> -Aleksej
>>>> 
>>>> 
>>>> 
>>>> [1] http://cr.openjdk.java.net/~aefimov/8024707/jdk/test/javax/xml/jaxp/parsers/8024707/TestFunc.java 
>>>> 
>>>> On 09/20/2013 01:19 AM, huizhe wang wrote:
>>>>> Hi Aleksej,
>>>>> 
>>>>> Looks like the getLength() method has the same problem.
>>>>> 
>>>>> Joe
>>>>> 
>>>>> On 9/17/2013 5:01 AM, Aleksej Efimov wrote:
>>>>>> Hi Everyone,
>>>>>> 
>>>>>> There is a bug [1] in JAXP about transformation of one-item sized node list:
>>>>>> When the length of nodelist which is passed to a XSLT extension function is 1, the node gotten from the node list becomes null.
>>>>>> New test illustrates this issue [2]. Full webrev with proposed fix can be found here: [3].
>>>>>> 
>>>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707
>>>>>> [2] http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java
>>>>>> [3] http://cr.openjdk.java.net/~aefimov/8024707/
>>>>>> 
>>>>>> Best regards,
>>>>>> Aleksej
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From pbenedict at apache.org  Mon Sep 30 19:11:39 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 30 Sep 2013 14:11:39 -0500
Subject: Review: demo extension methods (it is illustrates the feature default
	method usage)
Message-ID: 

ArrayIterator's javadoc uses a "smart" apostrophe which translates into a
sequence of crazy ascii characters.

-- 
Cheers,
Paul


From mike.duigou at oracle.com  Mon Sep 30 20:48:13 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 30 Sep 2013 13:48:13 -0700
Subject: RFR: JDK-8025686 : (s) Update jdk repo netbeans projects to support
	NetBeans 7.4 for Java 8 support
Message-ID: <43DF08F8-4558-43AD-BADD-9085563C1AD9@oracle.com>

Hello all;

When JDK-8006709 (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cff8d7768d72) was pushed it changed the default source level for the jdk project NetBeans projects to 1.8. This was a reasonable change since at this point there was already a small amount of Java 8 "-source 1.8" code in the jdk repo. Since that time the amount of source has increased. This change meant, unfortunately, that it was no longer possible to use a release version of netbeans as 7.3 did not support Java 8 source. Users wanting to use the jdk projects had to use either special lambda builds of NetBeans or the nightly dev builds. 

NetBeans 7.4 will support Java 8 source. This changeset adjusts the projects so that they are recognized by NetBeans. The same change also works with NetBeans dev and lambda builds.

http://cr.openjdk.java.net/~mduigou/JDK-8025686/0/webrev/

In addition to updating the projects this change also adjusts the location where classes would be written (assuming that compilation from within NetBeans wasn't broken--it is currently broken). This change is incomplete in that it doesn't properly understand the SPEC variable from the new makefiles but at least it prevents writing output to the repo directory. This will be further cleaned up in JDK-8016210 (https://bugs.openjdk.java.net/browse/JDK-8016210)

Cheers,

Mike

From naoto.sato at oracle.com  Mon Sep 30 21:17:30 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 30 Sep 2013 14:17:30 -0700
Subject: RFR: 8016110: Japanese char (MS932) 0x5C cannot be used as an
	argument when quoted
In-Reply-To: <523CC538.2040301@oracle.com>
References: <523CC538.2040301@oracle.com>
Message-ID: <5249EA6A.4050600@oracle.com>

Hello,

I took over the responsibility of this bug, as it relates to i18n. Here 
is the updated webrev:

http://cr.openjdk.java.net/~naoto/8016110/webrev.03/

Please review.

Naoto


On 9/20/13 2:59 PM, Kumar Srinivasan wrote:
> Hi Naoto, Sherman, Akhil,
>
> Can you please review this:
> http://cr.openjdk.java.net/~ksrini/8016110/webrev.0
>
> Bug:
> http://bugs.sun.com/view_bug.do?bug_id=8016110
>
> The code was provided by IBM, I wrote up the test.
>
> Thanks
> Kumar
>
>



From mike.duigou at oracle.com  Mon Sep 30 21:27:26 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 30 Sep 2013 14:27:26 -0700
Subject: RFR: 8025067: (xs) Arrays.parallelPrefix may fail to throw NPE for
	null op
Message-ID: 

Hello all;

This changeset fixes a small corner case where Arrays.parallelPrefix (all variants) failed to throw NPE if the operation was null. If the array or range was empty then op was never examined. The solution in this patch is to add an an explicit Objects.requireNonNull(op) check.

http://cr.openjdk.java.net/~mduigou/JDK-8025067/0/webrev/

Cheers,

Mike

From mike.duigou at oracle.com  Mon Sep 30 21:29:03 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 30 Sep 2013 14:29:03 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: <3A32F64F-000A-492D-A120-4883FFA7BB25@oracle.com>
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	<8811C5FD-389A-4FF8-9157-F1DEFD4C9A9F@oracle.com>
	<3A32F64F-000A-492D-A120-4883FFA7BB25@oracle.com>
Message-ID: <6EC7D9CC-7D3B-4193-B83A-02EEDCDB4F31@oracle.com>

Ping!

(still need a Reviewer on this issue)

Mike

On Sep 16 2013, at 15:49 , Mike Duigou wrote:

> Ping!
> 
> (still need a reviewer on this)
> 
> Mike
> 
> On Sep 4 2013, at 11:44 , Mike Duigou wrote:
> 
>> Hello all;
>> 
>> I have updated the proposed changeset for this issue. I have moved the note to the interface documentation for Collection and Map and made it more general:
>> 
>>> Some collection operations which perform recursive traversal of the
>>> collection may fail with an exception for self-referential instances where
>>> the collection directly or indirectly contains itself. This includes the
>>> {@code clone()}, {@code equals()}, {@code hashCode()} and {@code toString()}
>>> methods. Implementations may optionally handle the self-referential scenario,
>>> however most current implementations do not do so.
>> 
>> The webrev is at:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-7057785/1/webrev/
>> 
>> Mike
>> 
>> On Aug 27 2013, at 19:06 , Mike Duigou wrote:
>> 
>>> Hello all;
>>> 
>>> Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is:
>>> 
>>>> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances.
>>> 
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/
>>> 
>>> Cheers,
>>> 
>>> Mike
>> 
> 



From jason.uh at oracle.com  Mon Sep 30 21:46:35 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Mon, 30 Sep 2013 21:46:35 +0000
Subject: hg: jdk8/tl/jdk: 7122707: Security Providers need to have their
	version numbers updated for JDK8
Message-ID: <20130930214659.3E71962C1B@hg.openjdk.java.net>

Changeset: d0de46a2cbd0
Author:    ascarpino
Date:      2013-09-19 11:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d0de46a2cbd0

7122707: Security Providers need to have their version numbers updated for JDK8
Reviewed-by: xuelei

! src/macosx/classes/apple/security/AppleProvider.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
! src/share/classes/com/sun/security/sasl/Provider.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java
! src/share/classes/sun/security/ec/SunEC.java
! src/share/classes/sun/security/jgss/SunProvider.java
! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
! src/share/classes/sun/security/pkcs11/SunPKCS11.java
! src/share/classes/sun/security/provider/MD4.java
! src/share/classes/sun/security/provider/Sun.java
! src/share/classes/sun/security/provider/VerificationProvider.java
! src/share/classes/sun/security/rsa/SunRsaSign.java
! src/share/classes/sun/security/smartcardio/SunPCSC.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! src/windows/classes/sun/security/mscapi/SunMSCAPI.java
+ test/java/security/Provider/ProviderVersionCheck.java



From jason.uh at oracle.com  Mon Sep 30 21:51:52 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Mon, 30 Sep 2013 21:51:52 +0000
Subject: hg: jdk8/tl/jdk: 8004283:
	test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failing
	intermittently
Message-ID: <20130930215204.66E4162C1C@hg.openjdk.java.net>

Changeset: 2434e79fc41f
Author:    ascarpino
Date:      2013-09-18 14:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2434e79fc41f

8004283: test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failing intermittently
Reviewed-by: vinnie

! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh



From jason.uh at oracle.com  Mon Sep 30 21:52:52 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Mon, 30 Sep 2013 21:52:52 +0000
Subject: hg: jdk8/tl/jdk: 8009438: sun/security/pkcs11/Secmod tests failing on
	Ubuntu 12.04
Message-ID: <20130930215304.225C562C1D@hg.openjdk.java.net>

Changeset: e4c897b33cb7
Author:    ascarpino
Date:      2013-09-02 09:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4c897b33cb7

8009438: sun/security/pkcs11/Secmod tests failing on Ubuntu 12.04
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs11/Secmod.java



From henry.jen at oracle.com  Mon Sep 30 22:00:56 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 30 Sep 2013 15:00:56 -0700
Subject: RFR: 8025067: (xs) Arrays.parallelPrefix may fail to throw NPE
	for null op
In-Reply-To: 
References: 
Message-ID: <9D6FBBCA-A61B-477F-9ED9-20987E4756DA@oracle.com>

Looks good to me.

Cheers,
Henry

On Sep 30, 2013, at 2:27 PM, Mike Duigou  wrote:

> Hello all;
> 
> This changeset fixes a small corner case where Arrays.parallelPrefix (all variants) failed to throw NPE if the operation was null. If the array or range was empty then op was never examined. The solution in this patch is to add an an explicit Objects.requireNonNull(op) check.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8025067/0/webrev/
> 
> Cheers,
> 
> Mike



From kumar.x.srinivasan at oracle.com  Mon Sep 30 22:30:39 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 30 Sep 2013 15:30:39 -0700
Subject: RFR: 8016110: Japanese char (MS932) 0x5C cannot be used as an
	argument when quoted
In-Reply-To: <5249EA6A.4050600@oracle.com>
References: <523CC538.2040301@oracle.com> <5249EA6A.4050600@oracle.com>
Message-ID: <5249FB8F.8000508@oracle.com>

Hi Naoto,

Looks good, consider it reviewed by me, and a big thanks for picking 
this up.

Kumar

> Hello,
>
> I took over the responsibility of this bug, as it relates to i18n. 
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8016110/webrev.03/
>
> Please review.
>
> Naoto
>
>
> On 9/20/13 2:59 PM, Kumar Srinivasan wrote:
>> Hi Naoto, Sherman, Akhil,
>>
>> Can you please review this:
>> http://cr.openjdk.java.net/~ksrini/8016110/webrev.0
>>
>> Bug:
>> http://bugs.sun.com/view_bug.do?bug_id=8016110
>>
>> The code was provided by IBM, I wrote up the test.
>>
>> Thanks
>> Kumar
>>
>>
>



From mike.duigou at oracle.com  Mon Sep 30 22:39:07 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 30 Sep 2013 15:39:07 -0700
Subject: RFR: 8025067: (xs) Arrays.parallelPrefix may fail to throw NPE
	for null op
In-Reply-To: <9D6FBBCA-A61B-477F-9ED9-20987E4756DA@oracle.com>
References: 
	<9D6FBBCA-A61B-477F-9ED9-20987E4756DA@oracle.com>
Message-ID: 

After posting the webrev I decided that an update to the regression test was going to be necessary. Here's the updated webrev including additional unit tests. Unfortunately I had to cut-and-paste some "library" code for exception checking. The "library" code will need to be cleaned up eventually.

http://cr.openjdk.java.net/~mduigou/JDK-8025067/1/webrev/

Mike

On Sep 30 2013, at 15:00 , Henry Jen wrote:

> Looks good to me.
> 
> Cheers,
> Henry
> 
> On Sep 30, 2013, at 2:27 PM, Mike Duigou  wrote:
> 
>> Hello all;
>> 
>> This changeset fixes a small corner case where Arrays.parallelPrefix (all variants) failed to throw NPE if the operation was null. If the array or range was empty then op was never examined. The solution in this patch is to add an an explicit Objects.requireNonNull(op) check.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8025067/0/webrev/
>> 
>> Cheers,
>> 
>> Mike
> 



From henry.jen at oracle.com  Mon Sep 30 23:13:23 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 30 Sep 2013 16:13:23 -0700
Subject: RFR: 8025067: (xs) Arrays.parallelPrefix may fail to throw NPE
	for null op
In-Reply-To: 
References: 
	<9D6FBBCA-A61B-477F-9ED9-20987E4756DA@oracle.com>
	
Message-ID: <5FA24890-15C2-4DEB-A38B-3259060B005D@oracle.com>

The test itself looks good.

Like you said, the cut-n-paste code need some cleanup, you didn't need those no-message version and the array version of assertThrows.

Cheers,
Henry


On Sep 30, 2013, at 3:39 PM, Mike Duigou  wrote:

> After posting the webrev I decided that an update to the regression test was going to be necessary. Here's the updated webrev including additional unit tests. Unfortunately I had to cut-and-paste some "library" code for exception checking. The "library" code will need to be cleaned up eventually.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8025067/1/webrev/
> 
> Mike
> 
> On Sep 30 2013, at 15:00 , Henry Jen wrote:
> 
>> Looks good to me.
>> 
>> Cheers,
>> Henry
>> 
>> On Sep 30, 2013, at 2:27 PM, Mike Duigou  wrote:
>> 
>>> Hello all;
>>> 
>>> This changeset fixes a small corner case where Arrays.parallelPrefix (all variants) failed to throw NPE if the operation was null. If the array or range was empty then op was never examined. The solution in this patch is to add an an explicit Objects.requireNonNull(op) check.
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8025067/0/webrev/
>>> 
>>> Cheers,
>>> 
>>> Mike
>> 
> 



From joe.darcy at oracle.com  Mon Sep 30 23:22:52 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Sep 2013 16:22:52 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: <6EC7D9CC-7D3B-4193-B83A-02EEDCDB4F31@oracle.com>
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	<8811C5FD-389A-4FF8-9157-F1DEFD4C9A9F@oracle.com>
	<3A32F64F-000A-492D-A120-4883FFA7BB25@oracle.com>
	<6EC7D9CC-7D3B-4193-B83A-02EEDCDB4F31@oracle.com>
Message-ID: <524A07CC.20305@oracle.com>

Hi Mike,

Looks good to go back; cheers,

-Joe

On 9/30/2013 2:29 PM, Mike Duigou wrote:
> Ping!
>
> (still need a Reviewer on this issue)
>
> Mike
>
> On Sep 16 2013, at 15:49 , Mike Duigou wrote:
>
>> Ping!
>>
>> (still need a reviewer on this)
>>
>> Mike
>>
>> On Sep 4 2013, at 11:44 , Mike Duigou wrote:
>>
>>> Hello all;
>>>
>>> I have updated the proposed changeset for this issue. I have moved the note to the interface documentation for Collection and Map and made it more general:
>>>
>>>> Some collection operations which perform recursive traversal of the
>>>> collection may fail with an exception for self-referential instances where
>>>> the collection directly or indirectly contains itself. This includes the
>>>> {@code clone()}, {@code equals()}, {@code hashCode()} and {@code toString()}
>>>> methods. Implementations may optionally handle the self-referential scenario,
>>>> however most current implementations do not do so.
>>> The webrev is at:
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-7057785/1/webrev/
>>>
>>> Mike
>>>
>>> On Aug 27 2013, at 19:06 , Mike Duigou wrote:
>>>
>>>> Hello all;
>>>>
>>>> Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is:
>>>>
>>>>> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances.
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/
>>>>
>>>> Cheers,
>>>>
>>>> Mike



From naoto.sato at oracle.com  Mon Sep 30 23:16:30 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 30 Sep 2013 23:16:30 +0000
Subject: hg: jdk8/tl/jdk: 8016110: Japanese char (MS932) 0x5C cannot be used
	as an argument when quoted
Message-ID: <20130930231651.7E3BB62C1E@hg.openjdk.java.net>

Changeset: b4c259743371
Author:    naoto
Date:      2013-09-30 16:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4c259743371

8016110: Japanese char (MS932) 0x5C cannot be used as an argument when quoted
Reviewed-by: ksrini, akhil

! src/windows/bin/cmdtoargs.c
+ test/tools/launcher/I18NArgTest.java