I’m working on a project that still uses JDK 8. The component I’m working on provides read-only access to local files for other components. Until now only resources from the default file system needed to be accessed. A new resource provider shall be added that provides access to class path resources, meaning files that are located in different jar files.

The overall use case is that different consumers require several configuration files initially and then maybe again at any time during runtime or never again. Atm it’s also not even hundreds of files. But I would like the look-up and access to be efficient, because at the end I cannot be sure know what a consumer does – if a file is read once by one/several consumer(s) or if a file will be read again and again by one/different consumer(s) because of bad practices.

Working with JAR files, nio.file.FileSystems and nio.file.Path is not what I usually do and I’ve looked up several things online. What I don’t understand is:
Can a (Zip)FileSystem remain open to ease further working with a Path instance and e.g. needed InputStreams? Or should it always be closed and “reloaded” when processing of a file is finally needed.

At the moment only ~3 JARs files will be accessed at all. But I would like good a solution that doesn’t need an justification like “Doesn’t matter, its just a small amount of open ZipFileSystems”.

I initially only a Path instance for a requested resource is created that than shall be used by the consuming components as needed – loading Properties, PropertiesResourceBundles, InputStreams. The Path is provided to the consumer using a wrapper like MyResource.
I don’t know if it relevant or TMI: I plan to retain a list of all MyResource to ease further access, because the look-up also involves different SPI services and handling duplicated resources where one ‘wins’ to be used depending on specific parameters and only the ‘winner’ will be provided to my consumers.

This is a rough draft of how a Path is created atm.

Path getResource(fileNameStr) {
  Path result = null;

  URI uri =  ClassLoader.getSystemResource(fileNameStr).toURI();

  Map<String, String> env = new HashMap<String, String>(); 
  env.put("create", "true");

  FileSystem zipfs = FileSystems.newFileSystem(uri);
  result = Paths.get(uri);

  // question: close zipfs or keep open?

  return result;
}

Depending on your answers to my question, it would be possible to add further support to MyResource if needed – getFileSystem, getInputStream, ... . Or an additional utility class could be provided that eases the access to the file represented by a Path instance, but I assume if that is needed, it would exist. Therefore I assume there must be an answer/process of working with (Zip)FileSystems I’m not understanding yet.

Thank you in advance for helping me to learn! 🙂