Getting FileSystemNotFoundException from ZipFileSystemProvider when creating a path to a resource

I have a Maven project and inside a method I want to create a path for a directory in my resources folder. This is done like this:

try {
	final URI uri = getClass().getResource("/my-folder").toURI();
	Path myFolderPath = Paths.get(uri);
} catch (final URISyntaxException e) {
	...
}

The generated URI looks like jar:file:/C:/path/to/my/project.jar!/my-folder.

The stacktrace is as following:

Exception in thread "pool-4-thread-1" java.nio.file.FileSystemNotFoundException
	at com.sun.nio.zipfs.ZipFileSystemProvider.getFileSystem(ZipFileSystemProvider.java:171)
	at com.sun.nio.zipfs.ZipFileSystemProvider.getPath(ZipFileSystemProvider.java:157)
	at java.nio.file.Paths.get(Paths.java:143)

The URI seems to be valid. The part before ! points to the generated jar-file and the part after it to my-folder in the root of the archive. I have used this instructions before to create paths to my resources. Why am I getting an exception now?

You need to create the file system before you can access the path within the zip like

final URI uri = getClass().getResource("/my-folder").toURI();
Map<String, String> env = new HashMap<>(); 
env.put("create", "true");
FileSystem zipfs = FileSystems.newFileSystem(uri, env);
Path myFolderPath = Paths.get(uri);

This is not done automatically.

See http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html

If you intend to read the resource file, you can directly use getClass.getResourceAsStream. This will set up the file system implictly. The function returns null if your resource could not be found, otherwise you directly have an input stream to parse your resource.

Expanding on @Uwe Allner 's excellent answer, a failsafe method to use is

private FileSystem initFileSystem(URI uri) throws IOException
{
	try
	{
		return FileSystems.getFileSystem(uri);
	}
	catch( FileSystemNotFoundException e )
	{
		Map<String, String> env = new HashMap<>();
		env.put("create", "true");
		return FileSystems.newFileSystem(uri, env);
	}
}

Calling this with the URI you are about to load will ensure the filesystem is in working condition. I always call FileSystem.close() after using it:

FileSystem zipfs = initFileSystem(fileURI);
filePath = Paths.get(fileURI);
// Do whatever you need and then close the filesystem
zipfs.close();

In addition to @Uwe Allner and @mvreijn:

Be careful with the URI. Sometimes the URI has a wrong format (e.g. "file:/path/..." and correct one would be "file:///path/...") and you cant get a proper FileSystem.
In this case it helps that the URI is created from the Path's toUri() method.

In my case I modified initFileSystem method a little bit and used in non exceptional cases the FileSystems.newFileSystem(uri, Collections.emptyMap()). In exceptional case the FileSystems.getDefault() is used.

In my case it was also necessary to catch the IllegalArgumentException to handle the case with Path component should be '/'. On windows and linux the exception is caught but the FileSystems.getDefault() works. On osx no exception happens and the newFileSystem is created:

private FileSystem initFileSystem(URI uri) throws IOException {
    try {
        return FileSystems.newFileSystem(uri, Collections.emptyMap());
    }catch(IllegalArgumentException e) {
        return FileSystems.getDefault();
    }
}