Re: New jtreg test about StackWalker's JDK-8147039 and JDK-8156073: qword decoding from frame locals

Hi Fabio, Thanks for contributing the test. I created a JBS issue for this new regression test: https://bugs.openjdk.java.net/browse/JDK-8158879 We will look into JDK-8156073 before including this regression test. Mandy > On Jun 6, 2016, at 3:06 PM, Fabio Tudone

Re: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior.

Hello, The test 45 void testAnnotationWithLambda() { 46 Method[] methods = AnnotationWithLambda.MethodsWithAnnotations.class.getDeclaredMethods(); 47 for (Method method : methods) { 48 assertEquals(1, method.getDeclaredAnnotations().length); 49

New jtreg test about StackWalker's JDK-8147039 and JDK-8156073: qword decoding from frame locals

Hi, I'd like to contribute a jtreg test (attached) that highlights StackWalker issues about decoding qword (i.e. "long" and "double") frame locals and being able to read frame locals consistently in every situation, in particular regardless of the execution mode. The test is a single Java

Re: Proposal: java.lang.reflect.Proxy and default methods

Hi Peter, Thanks for the proposal. This feature has been lacking. When this subject was brought, I also have similiar thought to provide a way in Proxy class for InvocationHandler to invoke a default method (but of course no time to put into it). I appreciate your contribution and good work.

Re: Math.round optimization, and round to int

>As Andrew's other comment notes, the performance details can be >processor and platform specific so discerning small performance >differences really needs to be data-driven. Then here is some data for my configuration (Jdk8u92/Win7/Core i7 4770S): // arg = 123456.789: Benchmark  

Re: handling the deprecations introduced by early access builds 116 and 118 of jdk 9

Thanks for that response, Stuart. One comment inline... On 5/31/16 5:34 PM, Stuart Marks wrote: On 5/30/16 11:48 AM, Richard Hillegas wrote: Dalibor Topic recommended that I post this feedback on core-libs-dev. This is my feedback after ameliorating the deprecation warnings which surfaced

Re: [9] RFR: 8146156: Inconsistent default locale in string formatter methods

+ 1 On 06/02/2016 05:03 PM, Naoto Sato wrote: Hi, Please review the proposed fix to this issue: https://bugs.openjdk.java.net/browse/JDK-8146156 The fix is located at: http://cr.openjdk.java.net/~naoto/8146156/webrev.00/ The fix is to use the default locale for formatting where applicable.

Re: [8u-dev] Request for Review & Approval to backport: 8073542: File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c

Could someone please help review this simple backport? Thanks in advance, Ivan On 29.05.2016 21:08, Ivan Gerasimov wrote: As this has to be re-reviewed, sending the request to net-dev list as well. On 27.05.2016 16:46, Ivan Gerasimov wrote: Hello! I'd like to backport the fix to

[jdk9] RFR: 8158802: com.sun.jndi.ldap.SimpleClientId produces wrong hash code

Hello! It was noticed that objects of an internal class SimpleClientId that are equal (in terms of equals() method) can have different hash codes. This happens when the password is represented with an array, so passwd.hashCode() produces unique value even when the content is same. Some minor

Re: Math.round optimization, and round to int

Hello, As a general comment, the Java microbenching version of "Pics or it didn't happen" should be "jmh or it isn't faster" ;-) As Andrew's other comment notes, the performance details can be processor and platform specific so discerning small performance differences really needs to be

Re: Math.round optimization, and round to int

Hi, On 05/06/16 19:17, Jeff Hain wrote: > > While playing around with Math.round(double) code, > I found out that > > if (longBits < 0) { > r = -r; > } > > can be replaced with: > > long bitsSignum = (((longBits >> 63) << 1) + 1); // 2*0+1 = 1, or 2*-1+1 = -1 > r *= bitsSignum; > >

Re: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior.

Gentle reminder!! On 6/3/2016 11:40 AM, shilpi.rast...@oracle.com wrote: Thanks Vladimir and Joel!! Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.04/ Added restriction for synthetic methods as well. On 6/2/2016 5:04 PM, Vladimir Ivanov wrote: On 6/2/16 12:02 AM, Joel

Re: RFR[9]:MethodHandles.dropArgumentsToMatch(...) non-documented IAE

Looks good -Sundar On 6/6/2016 12:16 PM, Michael Haupt wrote: > Hi Shilpi, > > CCC approval is in. My review is lower-case, so another one is needed ere I > can sponsor the push. > > Best, > > Michael > >> Am 02.06.2016 um 14:53 schrieb Michael Haupt : >> >> Hi

Re: RFR[9]:MethodHandles.dropArgumentsToMatch(...) non-documented IAE

Hi Shilpi, CCC approval is in. My review is lower-case, so another one is needed ere I can sponsor the push. Best, Michael > Am 02.06.2016 um 14:53 schrieb Michael Haupt : > > Hi Shilpi, > > lower-case thumbs up. Please obtain CCC approval for this change. > >