Extensive global synchronizations

[lightoze]

These global synchronizations around resource-intensive code should be avoided:
https://github.com/jcabi/jcabi-xml/blob/master/src/main/java/com/jcabi/xml/XSLDocument.java#L275
https://github.com/jcabi/jcabi-xml/blob/master/src/main/java/com/jcabi/xml/XSDDocument.java#L168
https://github.com/jcabi/jcabi-xml/blob/master/src/main/java/com/jcabi/xml/XSDDocument.java#L184

[yegor256]

@lightoze this is on purpose, because DOM is not thread-safe, but we promise that our classes are thread-safe.

[lightoze]

Let's look at XLSDocument case first. You create local TransformerFactory and Transformer instances, so you should not worry about them. DOM itself is a potential source of a problem (when the same document is used in concurrent transformations), but in this case synchronization should be on xml, xml.node() or whatever.

[yegor256]

The problem is that creating a local instance of Transformer doesn't make it thread safe :( I believe it's full of static properties inside.

[lightoze]

Do you want to say that it's impossible to run two concurrent XSL transformations inside the same JVM?That's ridiculous.
Transformer documentation says clearly: An object of this class may not be used in multiple threads running concurrently. Different Transformers may be used concurrently by different threads.

[yegor256]

Yes, that's exactly what I'm saying and I have a test that proves it. Take a look: https://github.com/jcabi/jcabi-xml/blob/master/src/test/java/com/jcabi/xml/XSLDocumentTest.java#L72-L98

Try to remove synchronization and run mvn clean test and you will see what happens.

[lightoze]

Just did exactly what you suggested - the test is not failing with removed synchronization. Can you reproduce it yourself now?
Tested with JRE 1.8.0_31 and 1.7.0_76