JDK-5056707 : Generification conflict: Properties vs. javax.naming.spi.ObjectFactory
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2004-06-03
  • Updated: 2004-07-21
  • Resolved: 2004-07-21
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 Availability Release.

To download the current JDK release, click here.
Other
5.0 b59Fixed
Related Reports
Relates :  
JDK-5064052 - unnecessary bridge methods interfere with some generics retrofitting
Relates :  
JDK-6613858 - ObjectName Constructor declaration breaks Properties() argument in 1.6
Relates :  
JDK-6368455 - (props) Properties should extend Hashtable not Hashtable
Description
There is a conflict between the generification of java.util.Properties
and javax.naming.spi.ObjectFactory.  Properties is a Hashtable<Object,Object>
but ObjectFactory.getObjectInstance takes a Hashtable<String,?> as its parameter.  Thus, an existing client that passes a Properies will no longer
compile.

Perhaps Properties should implement Hashtable<String,String>

Perhaps ObjectFactory.getObjectInstance should take a Hashtable<? super String,?>
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-rc FIXED IN: tiger-rc INTEGRATED IN: tiger-b59 tiger-rc
03-08-2004
SUGGESTED FIX I believe the right fix is to make Properties extend Hashtable<String,String> or Hashtable<String,Object>, and fix any J2SE code that breaks because of this by casting to Hashtable before adding a non-String key. Existing clients will continue to compile and run just fine using -source 1.4, and can make similar adjustments to their code - either start obeying the contract or add casts - to compile in -source 1.5. Another possibility, if the Hashtable is not modified by ObjectFactory, is to use the type Hashtable<? super String,?> instead of Hashtable<String,?> in ObjectFactory. If this is possible then it is a simple, correct, and maximally compatible solution to the problem. ###@###.### 2004-06-03 It is indeed the case that the Hashtable is unmodified by ObjectFactory: "The name and environment parameters are owned by the caller. The implementation will not modify these objects...." ###@###.### 2004-06-17
17-06-2004
EVALUATION I'd love to change properties to extend Hashtable<String, String> but to do so would be incompatible since people have taken advantage of the unfortunate fact that Properties extends Hashtable rather than contains one. Users often call put directly with non String objects. ###@###.### 2004-06-03 Even if we change Properteis to extend Hashtable<String,String> such clients would continue to compile and run in -source 1.4, and could compile with only trivial changes in -source 1.5. ###@###.### 2004-06-03 The best fix for this bug would be to revise java.util.Properties to extend Hashtable<String,String>, as suggested, but doing that in a binary-compatible way first requires that 5064052 (unnecessary bridge methods interfere with some generics retrofitting) be fixed. -- ###@###.### 2004/6/16 Unfortunately it proved impossible to revise java.util.Properties to extend Hashtable<String,String> since that would have introduced a subtle binary incompatibility. The relevant APIs have instead been revised to accept arguments of type Hashtable<?,?> rather than their current, more-specific types. -- ###@###.### 2004/7/16
07-12-0182