[GROOVY-10519] v9 ClassFinder closes existing FileSystems that it doesn't own

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.10, 4.0.0
• Fix Version/s: 4.0.1, 3.0.11
• Component/s: groovy-runtime
• Assignee: Paul King
• Reporter: John Engelman
• Created: 03/Mar/22 14:55
• Updated: 23/Jul/22 16:25
• Resolved: 05/Mar/22 03:30

Description

org.codehaus.groovy.vmplugin.v9.ClassFinder

private static FileSystem newFileSystem(URI uri) throws IOException {          
  try {            
    return FileSystems.newFileSystem(uri, Collections.emptyMap());        
  } catch (FileSystemAlreadyExistsException e) {            
    return FileSystems.getFileSystem(uri);        
  }    
}

private static Map<String, Set<String>> find(URI uri, String prefix, String packageName, boolean recursive) {        
  boolean wfs = "file".equals(uri.getScheme());        
  if (wfs) prefix = prefix.replace("/", File.separator);
  
  final String sepPatten = Pattern.quote(wfs ? File.separator : "/");          
  final int prefixElemCnt = prefix.trim().isEmpty() ? 0 : prefix.split(sepPatten).length;
  
  Map<String, Set<String>> result = new LinkedHashMap<>();        
  try (FileSystem fs = newFileSystem(uri)) {
    //...
  }
  //...
}

The current implementation of ClassFinder will close a FileSystem that was opened prior to loading Groovy classes. Specifically, if an application opens a FileSystem for a JAR on the classpath that contains Groovy classes and then subsequently loads a Groovy class contained within, then the underlying ZipFileSystem is closed by ClassFinder and the original application receives a java.nio.file.ClosedFileSystemException on subsequent operations.