Resource loaders and null returns

[dmlloyd]

There's an ambiguity with ResourceLoader. When a resource is not found, findResource may return null. However, in some cases we're instead returning a Resource which may later fail with e.g. NoSuchFileException.

Specifically:

• In the JAR resource loader, we return a valid Resource if the relative resource path is a file in the JAR or is a directory that physically exists in the JAR. For directories that are not existent as entries in the JAR, null is returned, even though we may want to be able to iterate those "virtual" directories.
• In the Path resource loader, we return a Resource for any valid path even if the corresponding filesystem file or directory does not exist. Errors are checked when the resource is opened.
• In the URL resource loader, we return a Resource for any valid path. The resource only accesses the remote URL when content is requested. Directories are not supported by URLResourceLoader.

To fix this, at a minimum, the documentation should be updated to indicate that a Resource may be returned even if there is no resource. We might consider adding an exists() method to Resource.

Unfortunately I don't think it's realistic to alter the contract of findResource to never return null, because the return value is already being checked for null by all existing consumers. This altering findResource to always return a Resource even if we know the path is non-existent would probably not be a useful change to make.

[dmlloyd]

It might be a good idea to alter the filesystem resource loader so that if a file does not exist, null is returned. Obviously this is not a race-free check. It could be made race-free by opening the file early and automatically cleaning it up if the Resource is discarded; however, I think that it is likely that a Resource will be immediately used rather than cached, in which case the slight raciness could be OK. It would probably be better than having to hang on to e.g. WeakReference or Cleaner instances at any rate.

[dmlloyd]

Fixed with a combination of #367 and #369.