JDK-4963875 : RFE: Reduction of space used by instances of java.util.BitSet
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2003-12-04
  • Updated: 2017-05-16
  • Resolved: 2005-03-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6 b29Fixed
Related Reports
Relates :  

Name: rmT116609			Date: 12/04/2003

Line 985 in file BitSet.java (method clone()) is:

        result.bits = new long[bits.length];

It should be changed to:

        result.bits = new long[unitsInUse];

It is not necessary to allocate more space than required. In the current
version, the unused space is never de-allocated.
(Incident Review ID: 229199) 

EVALUATION Sounds reasonable as long as it is acceptable that a cloned BitSet could have a different size() value than the one it was cloned from. Unfortunately for historical reasons size() returns the actual storage space rather than the logical size of a BitSet. This could be a compatibility issue. ###@###.### 2003-12-04 It is a bug in the original spec that size() was exposed, and a further bug that clone() was spec'ed to return a BitSet of the same size as its evil twin. It's hard for me to imagine someone depending on s.size() == s.clone().size() but who knows? It's also a good idea to shrink our BitSets occasionally automatically, as well as to provide an explicit trimToSize(). ###@###.### 2005-1-27 02:58:03 GMT