Classgraph holds lock on file

On windows i’m facing the issue, that ClassGraph seems to hold a lock on the scanned ressources. After the scanning i’m not able to delete files in the scanned directory.

I could not find any api, which would prevent this behavior. Maybe this is a bug?

public static void main(String[] args) throws IOException {
    ClassGraph classGraph = new ClassGraph()
            .overrideClasspath(new File("C:\\temp"))
            .verbose()
            .enableAllInfo();

    ClassInfoList info = getAllClasses(classGraph);
    System.out.println(info.size());
    
    File f = new File("C:\\temp\\org\\apache\\commons\\io\\comparator\\SizeFileComparator.class");
    Files.delete(f.toPath());
}

private static ClassInfoList getAllClasses(ClassGraph classGraph) {
    try (ScanResult result = classGraph.scan())
    {
      return result.getAllClasses();
    }
}

In this case Files.delete(f.toPath()) throws the following exception:

Exception in thread "main" java.nio.file.FileSystemException: C:\temp\org\apache\commons\io\comparator\ReverseComparator.class: The process cannot access the file because it is being used by another process.
	at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
	at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
	at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
	at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
	at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
	at java.nio.file.Files.delete(Files.java:1126)
	at ch.ivyteam.ivy.java.restricted.AnnotatedTypes.main(AnnotatedTypes.java:74)

verbose.log

[lukehutch]

@GedMarc please do not use Outlook to respond to GitHub messages – take a look at this issue in the web interface to see what it does to your messages. (Now that GitHub is owned by MS, hopefully they fix this…)

it is better to extract the code into its own classes than actually reference the module!!

In this case, that is impossible. The code called in sun.misc.Unsafe in JDK9+ (which I fully quoted a few responses back) is exactly the same as pre-JDK9, but generates an ugly un-suppressable reflective access warning on stderr in JDK9+. Only by having the JDK call that code for you in JDK9+ does the warning go away.

If you have to, which I really do strongly doubt, again can’t know for sure no internet, then make it transitive in moditect,

Make it transitive? All module “requires” statements are non-transitive due to strong encapsulation rules. Users of ClassGraph will not gain access to ClassGraph’s modular dependencies, which it sounds like is what you want.

it has to be placed in the base module somehow because of the effects on the JVM it has by just including it.

What effects?

requires static is a really brittle “solution”. The ability to unmap MappedByteBuffer instances would mysteriously fail in ClassGraph if the jdk.unsupported module didnt make it into the module graph in some other way (being required by some other module, added manually with --add-modules, drawn in by service binding, etc.).

They can’t remove all of jdk.unsupported for a long time, and they will have to provide alternatives before they do. In particular, database makers will need a way to manually unmap mapped buffers. Until that exists, this is unfortunately the best solution.

[lukehutch]

@johnou great find! I’ll add in that code. That should solve the problem for good.

Maybe I should re-enable mmap for Windows then, for directory-based classpath entries? It’s something like 10-15% faster than InputStream.