Re: BitSet vs BigInteger (false Android doc)

From:

Lew <lewbloch@gmail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 6 Sep 2011 14:51:46 -0700 (PDT)

Message-ID:

<b19a0af2-c9a5-4367-bfc4-ae16c95fee6d@glegroupsg2000goo.googlegroups.com>

Jan Burse wrote:

Patricia Shanahan schrieb:

conversions. The combination of the comment in question and reading the
code shows that they did not take that path. Instead, they always
convert for bit manipulation and advise use of BitSet instead.

The Android comment can be corrected as follows:
"It is adviced [sic] to use BitSet if only positive bit patterns
come into play and if it is possible to use inline modifications."

The Android comment is not incorrect to begin with.

But the comment should maybe also include a warning, that using
objects with inline modifications can lead to more programming
errors. Reasons are for example that the objects are now mutable
and thus various side effects can occur. Here is an example:

Hashtable tab = new Hashtable();

'Hashtable'? Really?

     BitSet bits = new BitSet();
     tab.put(bits,"A");
     bits.flip(3);

The above will result in a slightly broken hashtable. Although

This is an example of the general principle that a mutable key in a 'Map' can mess things up, if you change the key while the 'Map' holds it. It hardly requires a warning in every mutable class's Javadocs.

the entries in a hashtable do store the hash once it is computed.
But the following code will not work as expected:

Enumerated en=tab.keys();

'Enumerated'? Really?

     while (en.hasMoreElements()) {
        BitSet bits=en.nextElement();
        System.out.println("key="+bits+", value="+tab.get(bits));
     }

But I guess you all know about these dangers.

Anyone familiar with the dangers of mutable keys in a 'Map' knows at least something about these dangers.

--
Lew