| Windows | GNU / Linux | OS X |
|---|---|---|
 |
 |
There is a (reasonably) well-known bug in the JVM, that the URL classloader does not release its jars
the various attempts to workaround the bug are limited.
This project provides a monkey patch to java.net.URLClassLoader which fixes the problem at its heart: by avoiding the use of persistent JarFiles which hold onto file handles.
We use a Java Agent to Retransform java/net/URLClassLoader so that all new instances of sun/misc/URLClassPath instead create our fommil/URLClassPath - a clean implementation of the same API.
A caveat is that the system URLClassLoader will use the sun/misc implementation, however any user-created URLClassLoaders will use the fommil implementation.
Whereas the sun/misc implementation is overly general in the kinds of URLs that it can load (it was designed for the infobahn and makes unsubstantiated readability / performance trade-offs), the fommil implementation is stateless and simple.
I personally encounter problems in the context of Scala development:
and there is a somewhat related resource management bug in scalac:
This manifests as a memory leak in sbt on all platforms, but on Windows it is particularly bad because the OS uses read-write locks on file handles and the file cannot be deleted, moved or changed. A catastrophic consequence is that compilations silently fail on Windows when using exportJars.
Download the latest stable release from
and add it to your java process as -javaagent:/path/to/class-monkey-1.7.1-assembly.jar. You must not rename the file or it will not work.
Specifically for scala usage, you can add this flag to your SBT_OPTS or add this to your project's .sbtopts
-J-javaagent:/home/fommil/.sbt/class-monkey-1.7.1-assembly.jar