views:

97

answers:

1

I've an unexpected trouble calling put on an old-school hashtable. What's going on here?

Welcome to Scala version 2.8.0.final (Java HotSpot(TM) Client VM, Java 1.6.0_21).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import com.ibm.mq._                 
import com.ibm.mq._

scala> MQEnvironment.properties                                                    
res1: java.util.Hashtable[_, _] = {}

scala> res1.put("transport", "MQSeries")
<console>:10: error: type mismatch;
 found   : java.lang.String("transport")
 required: ?0 where type ?0
       res1.put("transport", "MQSeries")
            ^

PS, the question still stands as is, but I have a nasty workaround:

scala> new java.util.Hashtable[String, String]
res10: java.util.Hashtable[String,String] = {}

scala> res10.put("transport", "MQSeries")      
res11: String = null

scala> MQEnvironment.properties = res10

scala> MQEnvironment.properties        
res13: java.util.Hashtable[_, _] = {transport=MQSeries}
+4  A: 

That properties interface appears to be one of those old-school APIs that pre-date Java generics. Those underscores in java.util.HashTable[_, _] are shorthands for existential types, the first of which (the key type) corresponds to the ?0 appearing in the diagnostic. These old Java "raw" types are an unfortunate, visible seam in Scala's Java interoperability, albeit one that usually shows up only in very old APIs.

Randall Schulz
It's generally "ok" to cast these to AnyRef values as needed. It would be handy if all these "bad" generic methods were documented and the compiler could have an option to correct them for you.
jsuereth