harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-6043) [classlib] [security] UnresolvedPermission.equals(Object) doesn't works well
Date Sun, 14 Dec 2008 18:18:32 GMT
2008/12/13 Kevin Zhou <zhoukevin83@gmail.com>:
> Alexey wrote,
>> One must make defensive copy when setting array properties - plain
> assigment of array reference is unsafe.
> Yes, this assigment of arry reference is unsafe. But no spec says that the
> array of certificates in a UnresovledPermission need to be thread-safe.
> If we add a lock to guarantee its safe, how about the other methods which
> access to targetCerts array. Do we need to make them safe too?

I did not mean thread safety here, rather internal object integrity.
BTW, API spec directly says: "The signer certificates are copied from
the array. Subsequent changes to the array will not affect this
The same precautions are already in place where needed.

>>Looking on the test source, I'd rather consider this as non-bug difference.
> I think this is different behaviors between RI and HARMONY of determining
> certificate equality?
> The previous implementation of HARMONY uses PolicyUtils.matchSubSet method
> which behaves differently from RI.
> I think we'd better follow RI's behaviors on this.
This is better only if RI's behaviour is logical and consistent or
became widely adapted feature. This is not the case here. E.g.,
throwing NPE on equals() invocation is always considered bad practice,
etc. Moreover, I wonder if RI is compliant with spec which says: "To
determine certificate equality, this method only compares actual
signer certificates. "
So I suggest to rollback the patch and mark the issue "non-bug difference".


View raw message