Clearly this is due JVM locking issues either in your JVM implementation, or rather, in the way you are deploying your cobertura JAR.
Jenkins can spawn up alot of JVM threads, and if cobetura is on your global classpath, its possible that some weird collisions are happening.
I assume, ultimately, that this should be attributed to a minor bug in cobertura (unless the complex corbertura file locking is solving some other more important problem).
According to the source code for Cobertura’s FileLock (cobertura/src/main/java/net/sourceforge/cobertura/util/FileLocker.java), there are some issues around multiple JVM’s loading up the Cobertura jar.
To solve, make sure there is only one copy and one app launching and using Corbetura.
The reason your VM implementation fixed it, most likely, is that you’ve decreased the amount of variability in the way cobetrura can be loaded. Also maybe you are restarting your VM with higher frequency then your jenkins server.
In our jenkins corbertura builds, we just use the maven plugin and this seems to work fine without issue (but then again, we are not using java 1.7, nor are we using Play).