[9] RFC on 8080369: (fs) Files.probeContentType returns null

[Brian Burkhalter]

Please comment at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8080369
Patch:	http://cr.openjdk.java.net/~bpb/8080369/webrev.00/

This patch addresses only the Mac OS X implementation. It provides a fix by deriving the MIME type using Uniform Type Identifiers (UTIs) based on the file extension. The original implementation based on a user.home/.mime.types file is chained before the UTI-based implementation.

This is not a request for review yet as I have a couple of questions about the present form of the patch, and because a new test might be needed. The questions I have are:

1) Should the old and new approaches be chained in Mac OSXFileSystemProvider.getFileTypeDetector() or should the UTI-based implementation simply replace the old implementation? I don’t myself see any reason to keep the old version as it is essentially non-functional.

2) The file extension is passed to and returned from the native layer as a Java string. Might it be better to use some other approach, for example using a NativeBuffer as in the Linux MagicFileTypeDetector?

Note that the issue was originally filed against the Windows implementation. Testing showed that the failure was likely due to an entry missing from the Windows registry. The original submitter was queried to verify whether the same situation obtained on the machine where they observed the problem. In the absence of a contradictory response from them, the Windows portion of the issue is evaluated as “Not an Issue.”

Thanks,

Brian