Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

On Jun 6, 2014, at 1:17 AM, John Rose wrote: > Reviewed. > > This is not a requirement, but I would prefer (in general) to see less test > logic in ASM-generated bytecode and more in Java. I am guessing that the > invokeExact call could have been replaced by a simple weakly-typed invoke > c

Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

John, Paul, I always welcome valuable suggestions, so here's an update :-) http://cr.openjdk.java.net/~vlivanov/8032400/webrev.02/ IMO, the test is much cleaner now. Best regards, Vladimir Ivanov On 6/6/14 12:05 PM, Paul Sandoz wrote: On Jun 6, 2014, at 1:17 AM, John Rose wrote: Reviewed.

Re: RFR 8043954: Fix behavior difference of connect() for AIX

Hi Alan, On Fri, Jun 6, 2014 at 1:53 AM, Alan Bateman wrote: > On 05/06/2014 11:37, Jonathan Lu wrote: > > > If getsockopt(SO_ERROR) failed, I did not find any explicit docs about > the behavior. > but as I tested with some C code snippet, the value of sockopt_arg would > not be changed if ge

Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

On Jun 6, 2014, at 11:31 AM, Vladimir Ivanov wrote: > John, Paul, > > I always welcome valuable suggestions, so here's an update :-) > http://cr.openjdk.java.net/~vlivanov/8032400/webrev.02/ > > IMO, the test is much cleaner now. > Yes, I like it, easier to understand. Paul.

Re: RFR 8043954: Fix behavior difference of connect() for AIX

Hi Jonathan, I just wanted to let you know that I've build your changes on AIX 5..3 and 7.1. I've also run the jdk regression tests without specific issues. So thumbs up from me! Regards, Volker On Fri, Jun 6, 2014 at 12:03 PM, Jonathan Lu wrote: > Hi Alan, > > On Fri, Jun 6, 2014 at 1:53 AM,

Re: RFR 8043954: Fix behavior difference of connect() for AIX

On 06/06/2014 11:03, Jonathan Lu wrote: You are right! errno will be checked by other code if NET_Connect() failed, I've updated the patch, please help to review. http://cr.openjdk.java.net/~luchsh/JDK-8043954.3/ Thanks for the update,

Re: RFR 8043954: Fix behavior difference of connect() for AIX

Hi Alan, Volker, Thanks a lot! I've pushed the change. Best regards - Jonathan On Fri, Jun 6, 2014 at 8:27 PM, Volker Simonis wrote: > Hi Jonathan, > > I just wanted to let you know that I've build your changes on AIX 5..3 and > 7.1. > I've also run the jdk regression tests without specific

RFR: 8042789: org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader

Changes in the ORB loading in 8u5 causes incompatibility changes for some environments where a 3rd party plugin might be deployed over plugin. Some CORBA deployment installations have an incorrect expectation on finding the custom ORBSingleton class using the context classloader. Proper approac

Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

On Jun 6, 2014, at 3:25 AM, Paul Sandoz wrote: > > On Jun 6, 2014, at 11:31 AM, Vladimir Ivanov > wrote: > >> John, Paul, >> >> I always welcome valuable suggestions, so here's an update :-) >> http://cr.openjdk.java.net/~vlivanov/8032400/webrev.02/ >> >> IMO, the test is much cleaner now.

Re: RFR: 8042789: org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader

Hi Sean I think this makes sense and the change looks fine Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Jun 6, 2014, at 1:22 PM, Seán Coffey wrote:

Re: RFR: 8042789: org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader

On 06/06/2014 18:22, Seán Coffey wrote: Changes in the ORB loading in 8u5 causes incompatibility changes for some environments where a 3rd party plugin might be deployed over plugin. Some CORBA deployment installations have an incorrect expectation on finding the custom ORBSingleton class using

RFR: 8046085: (s) inserting null key into HashMap treebin fails

Hello all; This changeset corrects a problem inserting a null key into a HashMap that is using TreeBins. The root cause of the failure was diagnosed by Paul Sandoz and confirmed by Alan Bateman, Doug Lea and myself. I've prepared the changeset and a minimal test which reproduces the failure. j

Re: RFR: 8046085: (s) inserting null key into HashMap treebin fails

The change and test look good to me Mike. Typo? treeifiying -> treeifying. ;-) -Chris. > On 6 Jun 2014, at 20:54, Mike Duigou wrote: > > Hello all; > > This changeset corrects a problem inserting a null key into a HashMap that is > using TreeBins. The root cause of the failure was diagnosed