Ethan Atkins 8518c4b4fd Place scalatest framework jar in its own classloader ... Closing the ManagedClassLoader generated by test can cause nonlocal effects because the jdk shares some JarFile resources across multiple URLClassLoaders. As a result, if one classloader is trying to load a resource and the classloader is closed, it might cause the resource loading to fail (see https://github.com/sbt/sbt/issues/5262). This can be fixed by moving the scalatest framework jar (and its dependencies) into an additional classloader layer that sits between the scala library loader and the rest of the test dependencies. In addition to adding the new layer, I reworked the ReverseLookupClassLoader to use its dependent classloader to find resources that may below it in the classloading hierarchy rather than constructing an entirely new classloader for resources. After this change, I was able to run test in the repro project: https://github.com/rjmac/sbt-5262 1000 times with no failures. Note that the repro is sensitive to the jdk used. I could not reproduce with jdk11 but I could typically induce a failure within 20 or so runs with jdk8. I benchmarked this change with https://github.com/eatkins/scala-build-watch-performance and performance was roughly the same as 1.3.4 with turbo mode and about 200-250ms faster in non-turbo mode (which can be explained by the time to load the scalatest classes).		2019-12-06 11:41:44 -08:00
..
src	Place scalatest framework jar in its own classloader	2019-12-06 11:41:44 -08:00
NOTICE	Add, configure & enforce file headers	2017-10-05 09:03:40 +01:00