Josh Bloch writes,

"In 1.4, we added methods nextSetBit(int) and nextClearBit(int).  This was  customer  as far as it went.  We should also have added previousSetBit(int) and previousClearBit(int).  

The reason this is a reasonable RFE is that it's MUCH slower to code these methods up from the outside as you don't have access to the words that make up bit set, so you have to operate a bit at a time, range-checking the bit index each time.  The resulting method is probably 100 times as slow as it should be.  (I haven't timed it, so don't believe this estimate.)"
Posted Date : 2006-04-10 05:12:43.0

N/A

A reasonable suggestion
Posted Date : 2006-04-10 05:12:43.0

Totally agree. almost word for word, infact.

bug_id=6505531

If the maximum size of the BitSet is known at instantiation, a workaround while we wait for 6410729 is to create a class with two BitSets, with one being the inverse of the other.  Define those set manipulation operations in which you are interested to update both BitSets. Then the previousSetBit and previousClearBit operations can be defined by means of nextSetBit and nextClearBit on the inverse BitSet.

Replace all occurrences of "inverse" in my previous post with "reverse". That is the bits in the 2nd set are maintained in reverse order of the 1st set.

I have posted an implementation of this on the jdk-collaboration dev forum at
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=19753

No-one seems to be monitoring the forum, so maybe I've got the wrong idea about the way to contribute.