Thanks Ian, good to know. Aside: Jesse reinvented your locks down at the shapefile level.
Jody
--- Begin Message ---> Also notice a couple doses of code duplication (well interface > duplication). - CollectionEvent and FeatureEvent (and listeners) Right, these were to allow, among other things, the index implementation to readjust when the collection changed. More on that. > I noticed that Ian's FeatureList and FeatureIndex implementations are > exactly what I had intended to implement .... > ... well close. I had not intended to make FeatureIndex public api if I > could help it, and was going to pakage up Selection as a FeatureList > based on applying a Filter to a FeatureCollection. > > Ian there does not exist any implementations of this (that I could > find), if you don't mind can I pick up the idea and run with it? Can't remember if anything other than a simple prototype existed, but I couldn't find anything. The only interesting feature I had was the addition of a many-readers/one-writer mutex for FeatureCollection. This allowed, amongst other things, atomic listener notification so that associated indexes would not rebuild themselves on each modification. Something along the lines of: CollectionLock lock = collection.lock(); lock.writeAccess(new Runnable() { public void run() { // modify collection } }); or lock.enterWriteAccess(); try { // modify } finally { lock.exitWriteAccess(); } Where any events are fired after the writeAccess. Sorry don't have more. -Ian
--- End Message ---
