Avoid flooding temp dir with DLLs on Windows
- Dominant language
- Java
- Stars
- 1.4k
- Forks
- 326
- Avg merge
- 16h 22m
- Merged PRs (30d)
- 17
Description
On Windows, DLLs are still in memory when terminating the JVM, thus deleting the temporary DLL file via `File.deleteOnExit` doesn't work. So each time an application using Conscrypt with an embedded DLL is started, it is copied to a new DLL in the temp directory which never gets deleted except when someone does it manually.
The problem is discussed in more detail here, in the context of JNA: https://github.com/tensorflow/tensorflow/issues/18397
But there are workarounds. For example, [java-native/jssc](https://github.com/java-native/jssc) uses [scijava/native-lib-loader](https://github.com/scijava/native-lib-loader) to load native libraries.
`native-lib-loader` first tries to load the library from the path specified by the `java.library.path` system property, and only if that fails it uses the library embedded in the JAR. This allows to copy the DLL to a known path and specifying that path as `java.library.path` to avoid creating temp files.
While we managed to automate this using Maven, it doesn't work for Conscrypt, because Conscrypt preferably loads from its JAR and only if that fails it falls back to `java.library.path`. To work around that, we would have to remove the native libraries from the Conscrypt-JAR, but we would like to avoid messing with the JARs if possible.
So if Conscrypt would change the loading strategy to the one used by `native-lib-loader`, everything would be fine.
Note that avoiding to copy the DLL (roughly 2.6 MB) would also benefit performance, although that is not the main issue here.
That being said, this is just a workaround suggestion, but I am open to other solutions as well.
The goal is to avoid flooding the temp directory while keeping the Conscrypt JAR as is.
**System information**
OS: Windows 10 Pro [Version 10.0.18363.1198], 64 bit
Java: AdoptOpenJDK 11.0.9+11
Contributor guide
Assessment
This issue has not been assessed yet.