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
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 application
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
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
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 cou
