KotlinSymbolProcessingExtension leaks files due to URLClassLoader not being closed

[pablobaxter]

ksp/compiler-plugin/src/main/kotlin/com/google/devtools/ksp/KotlinSymbolProcessingExtension.kt

Lines 86 to 95 in 1ca8ca1

	} else {
	val processingClasspath = options.processingClasspath
	val classLoader =
	URLClassLoader(processingClasspath.map { it.toURI().toURL() }.toTypedArray(), javaClass.classLoader)
	ServiceLoaderLite.loadImplementations(SymbolProcessorProvider::class.java, classLoader).filter {
	(options.processors.isEmpty() && it.javaClass.name !in options.excludedProcessors) ||
	it.javaClass.name in options.processors
	}
	}

In the above code for KotlinSymbolProcessingExtension, a URLClassLoader is created but never closed, which leads to a file leak as described here: https://youtrack.jetbrains.com/issue/KT-72172/File-Leak-occurring-in-Kotlin-Daemon

What is happening in this line is that the URLClassLoader holds references to the underlying open files in the URLs, and each time the loadProviders() function is called, it creates a new URLClassLoader, which uses new URL objects, which open new file descriptors. These are closed when URLClassLoader.close() is called, but it never is, and remain open until that class loader is garbage collected.

However, if the class loader is closed once the SymbolProcessorProvider classes are loaded, the compiler will fail later on when it tries to load the classes that extend SymbolProcessor, since the class loader that loaded the provider is now closed. The fix I am working on for the Kotlin compiler (JetBrains/kotlin#5372) is passing in a Disposable and registering a new disposable with the one passed in as the parent, so that it's closed when the compiler is done. However, to fix it in KSP, would require more changes.

I'm unsure if there is a different approach for KSP in closing this class loader, but currently it leads to a situation where the number of open files continues to grow in each new run.