Review Request: JDK-7142921,(fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04
dan.xu at oracle.com
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:
>> I have added a comment to UnixFileSystemProvider.chain and remove its
>> "protected" keyword. The new webrev is at,
>> http://cr.openjdk.java.net/~dxu/7142921/webrev.01/. Thanks!
> I found time to do a very quick pass over MimeTypesFileTypeDetector.java.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nio-dev