RFR : 8017566 : Backout 8000450 - Cannot access to com.sun.corba.se.impl.orb.ORBImpl

[Seán Coffey]

Mandy,

>
> Looks fine to me.   I agree that we should back it out for 7u40. I 
> would think we want to leave the change in jdk8 and continue the 
> investigation and resolving the JCK failures for jdk8.  Is that what 
> you are thinking?  If so, we don't need to back it out from jdk8. 
I was hoping to back out the fix for both jdk7u40 and jdk8. The setup to 
reproduce is quite simple (modify package list in java.security) and I 
think it's not necessary to have JCK failures in jdk8 for the short to 
medium term as a result.

regards,
Sean.

On 12/07/2013 22:37, Mandy Chung wrote:
>
> On 7/12/2013 9:14 PM, Seán Coffey wrote:
>> The recent 8000450 has caused issue for JCK testing and some RMI/JMX 
>> testing also.The CORBA package interaction between org.omg, 
>> com.sun.corba.se.spi, javax.rmi and other packages into 
>> com.sun.corba.se.impl classes needs better analysis and won't be 
>> complete for 7u40.
>>
>> It's rare to have security manager installed with CORBA app but we 
>> need to cater for it. The JCK testsuite tests this scenario but it 
>> doesn't have sufficient privileges in the stack when launching the 
>> CORBA server during test setup phase. None the less, it's something 
>> the JDK code should handle. The structure of the CORBA packages and 
>> users of it needs to be better scoped out. For now, I propose 
>> reversing the change for both jdk8 and jdk7u40.
>>
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8000450.7u40/webrev/
>>
> Looks fine to me.   I agree that we should back it out for 7u40. I 
> would think we want to leave the change in jdk8 and continue the 
> investigation and resolving the JCK failures for jdk8.  Is that what 
> you are thinking?  If so, we don't need to back it out from jdk8.
>
> Mandy
>
>> regards,
>> Sean.
>