Paul, thanks. Looks good.
Test uses some impressive machinery, but I like what we did in jsr166 tck tests for similar sorts of tests: - rename latch to "done" - rename barrier to "threadsStarted" - rename "map" to "entry" or "e" - if a worker thread throws, make sure the test fails, e.g. by defining a "CheckedRunnable" or using a real ThreadPool that returns Futures that can be checked in the main thread. - do you really want to swallow the exception from barrier.await? But it's unfair to ask you to create a new jdk jtreg concurrency testlibrary when jsr166 maintainers failed to do so! On Mon, May 4, 2015 at 1:39 PM, Paul Sandoz <[email protected]> wrote: > On May 4, 2015, at 7:29 PM, Paul Sandoz <[email protected]> wrote: > >> There are still a number of differences, mostly cosmetic, between your > version of ConcurrentMap.java and jsr166 CVS (let's try hard to keep that > the "master" copy). > > > > Yeah, there are a bunch of cosmetic differences, i just tried to fix > some of the JavaDoc-like errors and may have slipped in some other cosmetic > things. Let me fully sync up ConcurrentMap from 166. > > > > Done, webrev updated in place. > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8078645-ConcurrentMap-views-removeIf/webrev/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java.sdiff.html > > Paul. >
