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

serialization oddity of X500Name

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: P5 P5
    • None
    • 1.4.0
    • security-libs
    • None

      Consider this:
          Principal p1 = new X500Principal("cn=foo");
          Principal p2 = new X500Name("cn=foo");
          Principal p3 = (Principal) new java.rmi.MarshalledObject(p2).get();
      (the last is just a way of serializing and then deserializing p2). The end
      result is
          p1.equals(p2) == false
          p2.equals(p1) == false
      which is expected but
          p1.equals(p3) == true
          p3.equals(p1) == false
      which is unexpected. The reason this happens is that p2 contains a null thisX500Name in the X500Principal superclass, but during deserialization the readObject method of X500Principal always creates a thisX500Name instance.

      (Of course, serialization of X500Name is problematic in the first place, since it's a sun.* class. But instances of it are returned by public methods of public classes, such as X509Certificate.)

            claisunw Charlie Lai (Inactive)
            bscheiflsunw Bob Scheifler (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: