Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6458646

Incompatible change to Sasl API -- redux

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 6
    • Fix Version/s: 6
    • Component/s: security-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b97
    • CPU:
      generic
    • OS:
      generic

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              vinnie Vincent Ryan
              Reporter:
              sseligmasunw Scott Seligman (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: