RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission

[Valerie Peng]

I looked at the tests and thought about it some more.
I agree that it makes sense to defer the check to post the security check.
Changes look fine.
Thanks,
Valerie

On 7/23/2014 9:51 AM, Valerie Peng wrote:
>
> Do you know which TCK tests fail? I want to check it out.
> Thanks,
> Valerie
>
> On 7/23/2014 1:15 AM, Seán Coffey wrote:
>> Valerie,
>>
>> I agree it's not ideal, but we're doing nothing different than what 
>> was performed in the old JDK releases...(i.e no check there either). 
>> I can't say if many applications would be impacted by the 
>> Card.disconnect change going into 8u20 but we should make best 
>> efforts to preserve the old legacy/buggy behaviour via the new 
>> sun.security.smartcardio.invertCardReset system property.
>>
>> If you disagree, we can launch a challenge against the TCK tests 
>> which are failing with this new property flag.
>>
>> regards,
>> Sean.
>>
>> On 23/07/2014 00:23, Valerie Peng wrote:
>>>
>>> Well, I see your point.
>>> However, I am a little concerned that the security check isn't being 
>>> performed in the old buggy impl.
>>> Is there any customer running into this, e.g. rely on the old 
>>> behavior with security manager enabled?
>>> Valerie
>>>
>>> On 7/22/2014 2:45 PM, Seán Coffey wrote:
>>>> A recent fix was introduced to preserve the behaviour of an old 
>>>> buggy implementation of smartcardio Card.disconnect :
>>>> https://bugs.openjdk.java.net/browse/JDK-8049250
>>>>
>>>> The old behaviour is not fully restored with this flag if a 
>>>> security manager lacking sufficient permissions is present. This 
>>>> could disrupt legacy applications which may wish to rely on the old 
>>>> behaviour. Some internal testing has also highlighted this.
>>>>
>>>> To enhance the 8049250 fix, I'm proposing we delay the boolean flip 
>>>> operation until post the security check.
>>>> http://cr.openjdk.java.net/~coffeys/webrev.8051614/webrev/
>>>> Bug report is not public due to internal links and servers being 
>>>> present in description.
>>>>
>>>> I'd like to get this into JDK 9 and 8u20.
>>>>
>>>> regards,
>>>> Sean.
>>