Review Request: JDK-7142921,(fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04

Dan Xu dan.xu at
Tue Nov 27 17:26:34 PST 2012


Thanks for your comments on MimeTypesFileTypeDetector.

One concern about not using META-INF/mimetypes.default in resources.jar 
is that we may not be able to support Mac platform. As Mike mentioned 
yesterday, the system mime types file, /private/etc/apache2/mime.types, 
was not present in Mountain Lion (10.8). Then, we have to use the 
fallback mime types file. And the .mime.types in user's home directory 
is not a sure thing. I am not sure whether we can rely on that. Thanks!


On 11/27/2012 06:35 AM, Alan Bateman wrote:
> On 27/11/2012 00:53, Dan Xu wrote:
>> Hi,
>> I have added a comment to UnixFileSystemProvider.chain and remove its 
>> "protected" keyword. The new webrev is at, 
>> Thanks!
>> -Dan
> I found time to do a very quick pass over
> In terms of diagnosability then I think it would be hard for 
> developers to understand how the file type is obtained when there are 
> so many ways to do. To that end it's probably best if 
> MimeTypesFileTypeDetector didn't uses META-INF/mimetypes.default, that 
> resource file is included in rt.jar because it is used by the Java 
> Activation Framework, itself used by JAX-WS and is essentially 
> invisible to users.
> On ~/.mime.types then we have choice, use it as a fallback in 
> MimeTypesFileTypeDetector so let the provider create two 
> MimeTypesFileTypeDetector instances, one for the system mime.types 
> files, one for the user file. I don't have a preference but the latter 
> would make the FileTypeDetector a bit simpler.
> In the implProbeContentType method it only support UnixPath but this 
> FileTypeDetector should be independent of the Path type.
> It looks like it tries a case-insensitive search after a 
> case-sensitive search but file extensions are case sensitive on 
> Solaris and Linux, I realize this will need special handing on Mac.
> loadFile/parse are a bit messy in that try-with-resources is being 
> combined with an explicit call to close. Given that the mime.types 
> file is likely to be quite small then a possible choice is 
> Files.readAllLines and that would save you some of this.
> That's all I have for now.
> -Alan

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the nio-dev mailing list