XStream
  1. XStream
  2. XSTR-84

System.identityHashCode() not unique

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.1
    • Component/s: Core
    • Labels:
      None

      Description

      ---- From Quartz or someone ----

      Bad news, go read carefuly the javadoc about System.identityHashcode(),
      it doesn't garanty the unicity of it. It is more unique than hashode(), but not totally unique.

      Which implies 2 design flaws:

      1-
      whenever an object is garbage collected, it memory address is available and his identity hashcode
      (mostly implemented with memory address) will be reused. If you dispose of a xml-ized object while
      more are created, the id will not be unique.

      2-
      the identity hashcode is certainly not unique on a 64 bit platform, with ram over 4 gigs.
      the memory address is 64 bits, and 64 bit jvm will be forced to give 32 int for identity hashcode.
      Even IdentityHashMap uses the generic buckets iteration whenever hashcode are ==. You must do the
      same.

      code piece example in converters:

      public void convertAnother(Object item) {
      Integer id = new Integer(System.identityHashCode(item));
      if (parentObjects.contains(id))

      { throw new CircularReferenceException(); }

      parentObjects.add(id);
      Converter converter = converterLookup.lookupConverterForType(item.getClass());
      converter.marshal(item, writer, this);
      parentObjects.remove(id);
      }

        People

        • Assignee:
          Unassigned
          Reporter:
          Joe Walnes
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: