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.
JDK 6
6 b29Fixed
Related Reports
Relates :  
Description

Name: rmT116609			Date: 12/04/2003


A DESCRIPTION OF THE REQUEST :
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];
<<<


JUSTIFICATION :
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) 
======================================================================

Comments
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
27-01-2005