RFR of 8129632: (fs) Files.probeContentType returns null on Mac OS X
Alan Bateman
Alan.Bateman at oracle.com
Mon Jun 29 10:32:15 UTC 2015
On 26/06/2015 19:34, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8129632
> Patch: http://cr.openjdk.java.net/~bpb/8129632/webrev.00/
>
> Summary:
>
> 1) Added OS X-specific UTIFileTypeDetector using Uniform Type Identifiers to map file extensions to content types.
> 2) Modified MacOSXFileSystemProvider to return a chain of MimeTypesFileTypeDetector followed by UTIFileTypeDetector.
> 3) Moved getExtension() up from MimeTypesFileTypeDetector to parent class AbstractFileTypeDetector.
> 4) Extended content type detection in Basic test to some other common file extensions.
>
> The jdk_nio regression tests including the one modified by this patch passed on all the usual platforms.
>
This mostly looks good.
In NioLibrary.gmk then you probably should split the
LDFLAGS_SUFFIX_macosx line to avoid the long line.
The protected static method in sun.nio.fs.AbstractFileTypeDetector is a
bit inconsistent. Can you change this to be final and change the comment
so that it's consistent with the other final method.
Are you confident that the update test and the image types will pass
everywhere? We've had to dial-down the tests in this area because there
is no guarantee that all test machines will the mappings. Also in the
delete then you can use Files.delete(file). For Windows then
startingWith("Windows") is commonly used.
The comments in UTIFileTypeDetector.c need to be cleaned up before this
is pushed. I don't think you need to reference MacOSXPreferencesFile.m
as it's only a tiny amount of duplication. Bets to keep these /* */
style to be consistent with the other code.
-Alan.
More information about the nio-dev
mailing list