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

java.util.BitSet.size() is not 100% backward-compatible from 1.2 to 1.1.x

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not an Issue
    • Icon: P3 P3
    • None
    • 1.2.0
    • core-libs
    • None
    • generic
    • generic

      I received the following email from a friend of mine, which documents some
      backward-compatibility problems with the java.util.BitSet class. The behavior
      of BitSet.size() appears to have changed between 1.1.x and 1.2.

      fred.ecks@Eng 1999-02-22

      ==============================================================================
      Date: Fri, 19 Feb 1999 17:06:16 -0500
      From: Russ Teasdale <###@###.###>
      To: Jeff Dunn <###@###.###>
      CC: fred.ecks@Eng

      > Wasn't there some sort of Java backwards-compatibility
      > bug that you were seeing? Can you send me a test case?

          Sure. Without belaboring the point, let me just snip from
      my thesis coding log. I used the BitSet class to store long binary
      "chromosomes" for use by the genetic algorithm that I employ in my
      thesis engine. See below.

      ------
      12_31_98:

      The engine was experimentally migrated to the JDK 1.2 libraries and JVM.

      Severe errors resulted. After a long manual debugging process, the source
      of the error was traced to changes made to the BitSet utility class.

      The changes in question were:

      The BitSet.size() method previously returned the canonical number of bits
      used in the set. Under JDK 1.2, it returns the number of bits used to store
      the canonical number. The new method length() performs the function which
      size() had previously performed.

      Under the previous version of BitSet, clearing a bit above the highest range
      in the set would result in the set growing to include that bit. It is not
      clear whether or not this behavior persists (test it). It can be surmised
      that this behavior does hold under 1.2 from runtime evidences. However, the
      length() function now returns only the index of the highest -set- bit. This
      can result in two chromosomes of supposedly identical canonical length being
      reported as different by sanity checking methods.

      Modifications have been made to Evolver and Processor classes to allow them to
      mimic the functionality which they had under the 1.1 JDK. The key modifications
      are to Processor.GetChromosome(). In particular, an artificial high-order bit
      is set in order to ensure proper reporting of the length of the chromosome.
      There are also extensive chromosome sanity checks which have been added.

      ---

            jjb Josh Bloch
            feckssunw Fred Ecks (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: