Removed object thread synchronization in Matcher.
The Flying Saucer layout/renderer appears to currently be single threaded in all demos and practical operation, but there's a lot of synchronization code that appears to be put in so that one day the engine may support multi-threaded operation (layout and rendering on different threads or incremental rendering). To this end, the authors appear to have wrapped objects that have state shared between the renderer and layout with synchronized delegates. The problem with this approach is that when put into a real multi-threaded context, these individual locking delegate objects will have many many deadlock conditions that will be impossible to unravel. We would need to take an almost godly level of consideration of the order of code that accesses these objects to avoid deadlock. In a single-threaded application, the synchronization blocks just slow everything down, and so I believe the synchronization code is practically useless at this point in time.
Developing practical multi-threaded applications that are simple to understand either centers around a well defined centralized locking mechanism, and/or a state copying/immutability design when handling shared state. It is better, I feel, to make sure object state is kept well contained and mostly immutable and single threaded, and then evolve that into a multi-threaded architecture in the future. So I'm removing the synchronization stuff where I find it for now.
Synchronizing over individual Elements in a DOM... That's just a crazy level of concurrent partitionality that's simply not practical for developers to write deadlock free code against! I understand the thought process behind writing code like this though because I have done similar stuff before I gained my experience writing concurrent systems.