JDK-4503627 : Make class java.security.cert.PolicyQualifierInfo non-final
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 1.4.0
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2001-09-17
  • Updated: 2017-05-16
  • Resolved: 2003-08-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
Other
5.0 tigerFixed
Related Reports
Relates :  
Description

Name: bsT130419			Date: 09/17/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

The class java.security.cert.PolicyQualifierInfo is 'final'ed in beta 2,
which become unapplicable for applications of jdk1.4 beta 1 that implemented
own PolicyQualifierInfo classes extending from it.
I see no reason to 'final' the class java.security.cert.PolicyQualifierInfo,
please change it back to the one defined in beta 1.
(Review ID: 131855) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b16
2004-06-14

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.
2003-07-23