JDK-4213570 : java.util.BitSet.size() is not 100% backward-compatible from 1.2 to 1.1.x
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 1999-02-22
  • Updated: 2019-09-05
  • Resolved: 1999-02-22
Related Reports
Relates :  
Description
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. 

---

Comments
EVALUATION The size method (introduced in 1.0) was woefully underspecified. Any program assuming *ANYTHING* about the returned value was operating on dangerous ground. The returned value could, for example, differ between platforms. Repeatedly or'ing two BitSets could cause the value returned by this method to grow without bound (even though the logical contents of the result never changed). Simply put, the method was useless. Unfortunately, it was impossible to fix the behavior in a manner consistent with the old (broken) spec, so we added a new, precisely specified method (length) that returns useful information that cannot vary from implementation to implementation. This new method effectively takes the place of the size method. joshua.bloch@Eng 1999-02-22
22-02-1999