EVALUATION
###@###.### 2001-09-18
It is not a requirement to maintain compatibility with beta releases.
This change (marking PolicyQualifierInfo 'final) was made in order to
prevent subclasses from overriding the immutability contract of this
class.
I'd be interested in knowing why you need to implement a subclass
of PolicyQualifierInfo and whether you considered alternative design
techniques such as composition.
======================================================================
Thanks for your response on the issue. According to [your] saying,
immutability contract might be a good reason to 'final' the class
java.security.cert.PolicyQualifierInfo
but it makes the class unapplicable in that the class provisioned only one
unfriendly constructor:
public PolicyQualifierInfo(byte[] encoded) throws IOException;
Instead of having a whole bunch of encoded octets of a PolicyQualifierInfo,
there are cases to construct a PolicyQualifierInfo directly either from a
CPS
Uri string or an object of User Notice. And since the class was 'final'ed, I
can't do it without a workaround of messy codes.
As an security implementor using 'SUN'-provider, I would like make my
implementation as close to SUN's as possible, especially those interfaces
and classes provided by SUN, to make our implementation interoperable.
The best resolution of PolicyQualifierInfo, in my opinion, is to make it an
interface, so that users can use it to interface each other easily. But
since
in beta 1 it was defined to be class, we figured out a workaround to extend
from it and still remained the interoperability. Now, it is 'final'ed and we
will
have to change the design framework without gaining any benifit from it.
This is all we concern about.
-- Alex (report submitter)
###@###.### 2001-09-25
###@###.### 2003-07-23
Proposal is to make class non-final which will allow subclasses to extend
it, and mark existing methods final to preserve the immutability contract.
|
Java