RFC on 8080369: (fs) Files.probeContentType returns null
Alan.Bateman at oracle.com
Tue Jun 23 21:26:49 UTC 2015
On 23/06/2015 22:03, Brian Burkhalter wrote:
> 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.
I think MimeTypesFileTypeDetector should be the first in the chain as
that makes it easy to override. This detector is more useful on Linux
and Solaris because it is setup to search /etc/mime.types too. On these
platforms then I think it's time to look at dropping the GNOME
> 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?
For OS X then I think your approach is okay.
> 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.”
If you want to create a new issue for the OS X issue then that should be
fine (I think what happened here is someone jumped on the bug without
realizing it was a Windows issue).
More information about the nio-dev