-
Bug
-
Resolution: Fixed
-
P2
-
6
-
b97
-
generic
-
generic
CR 6228412 resulted in a non-source-compatible change to the
signatures of some methods in several javax.security.sasl interfaces
and classes. The "props" parameter of these methods was changed from
Map<String, ?> to Map<? super String, ?>.
This change should probably be undone: it causes a source incompatibility
between Tiger and Mustang, and will be a hindrance to Mustang migration.
There have been several instances of Mustang early adopters
getting tripped up over this including JPMorgan, a heavy user of
server-side Java. This issue appeared in a recent presentation from
JPMorgan on a slide entitled: "J2SE Weaknesses: Generics example":
They wrote:
In J2SE 5.0, SaslServerFactory has the following method...:
SaslServer createSaslServer(..., Map<String, ?> props, ...)
In J2SE 6.0 that method now has the following signature:
SaslServer createSaslServer(..., Map<? super String, ?> props, ...)
- Due to erasure cannot implement both methods in the same class...
hard to get code to compile on both 5.0 and 6.0
- Eventually came up with workaround of removing generic declarations
For another report of the same issue see
http://forums.java.net/jive/thread.jspa?threadID=15229&tstart=0
The Description of 6228412 says:
In J2SE 5.0, the props argument to javax.security.sasl.Sasl.createSaslClient
was changed from Map to Map<String, ?>. Unfortunately, this means that the
common use of passing a Properties object (e.g., from System.getProperties)
no longer compiles.
Although correct, that change in 5.0 was made *before* the SASL API
ever shipped as part of the Java Platform. When the Platform APIs
were being generified the consequences of this change were weighed,
and a consensus reached that the generic signature should use String
(and thus not allow Properties objects without a cast to raw Map). It
was understood that users of the SASL optional package in J2SE 1.4
who used Properties objects would unfortunately need to deal with this
source incompatibility.
Whether or not the right choice was made then, given that Tiger shipped with
"String", it is too late to apply a fix that creates a new incompatibility --
one between Tiger and Mustang.
signatures of some methods in several javax.security.sasl interfaces
and classes. The "props" parameter of these methods was changed from
Map<String, ?> to Map<? super String, ?>.
This change should probably be undone: it causes a source incompatibility
between Tiger and Mustang, and will be a hindrance to Mustang migration.
There have been several instances of Mustang early adopters
getting tripped up over this including JPMorgan, a heavy user of
server-side Java. This issue appeared in a recent presentation from
JPMorgan on a slide entitled: "J2SE Weaknesses: Generics example":
They wrote:
In J2SE 5.0, SaslServerFactory has the following method...:
SaslServer createSaslServer(..., Map<String, ?> props, ...)
In J2SE 6.0 that method now has the following signature:
SaslServer createSaslServer(..., Map<? super String, ?> props, ...)
- Due to erasure cannot implement both methods in the same class...
hard to get code to compile on both 5.0 and 6.0
- Eventually came up with workaround of removing generic declarations
For another report of the same issue see
http://forums.java.net/jive/thread.jspa?threadID=15229&tstart=0
The Description of 6228412 says:
In J2SE 5.0, the props argument to javax.security.sasl.Sasl.createSaslClient
was changed from Map to Map<String, ?>. Unfortunately, this means that the
common use of passing a Properties object (e.g., from System.getProperties)
no longer compiles.
Although correct, that change in 5.0 was made *before* the SASL API
ever shipped as part of the Java Platform. When the Platform APIs
were being generified the consequences of this change were weighed,
and a consensus reached that the generic signature should use String
(and thus not allow Properties objects without a cast to raw Map). It
was understood that users of the SASL optional package in J2SE 1.4
who used Properties objects would unfortunately need to deal with this
source incompatibility.
Whether or not the right choice was made then, given that Tiger shipped with
"String", it is too late to apply a fix that creates a new incompatibility --
one between Tiger and Mustang.
- relates to
-
JDK-6228412 incompatible change to Sasl.createSaslClient
- Resolved