On Mon, 21 Oct 2019 10:19:05 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
> On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger <rlich...@openjdk.org> > wrote: > >> By using the collection itself as synchronization lock we achieve behaviour >> that matches java.util.Collections classes. >> >> I've create test cases that fail with the current way of synchronizing on a >> separate object. >> >> I've removed unused constructors. >> >> ---------------- >> >> Commits: >> - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for >> copying/iterating >> - 8ecf3545: JDK-8232524 fixed. >> >> Changes: https://git.openjdk.java.net/jfx/pull/17/files >> Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8232524 >> Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod >> Patch: https://git.openjdk.java.net/jfx/pull/17.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17 > > You have many whitespace errors in your patch that will need to be fixed > before `git jcheck` will pass. When you fix them, you can just push a new > commit. > > As an aside, you have uncovered a bug in the Skara PR bot where the > server-side jcheck fails to complete if there are more than 50 errors. See > [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). > You have many whitespace errors in your patch that will need to be fixed > before `git jcheck` will pass. When you fix them, you can just push a new > commit. I'm trying to setup skara tools so that I can check changes before committing in the future. > > As an aside, you have uncovered a bug in the Skara PR bot where the > server-side jcheck fails to complete if there are more than 50 errors. See > [SKARA-135](https://bugs.openjdk.java.net/browse/SKARA-135). OMG, hope I didn't break things ;-) PR: https://git.openjdk.java.net/jfx/pull/17
