-
Bug
-
Resolution: Fixed
-
P3
-
alpha
-
None
-
1.0fcs
-
generic
-
solaris_2.6
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2113042 | alpha | J. Duke | P3 | Closed | Fixed | alpha |
FileDataSource:
Javadoc for getContentType():
/**
* This method returns the MIME type of the data in the for of a
* string. The semantics of this call are to first search the
* per instance MIME Types registry and then check the system default
* registry returning the result of the first successful query.
*
* @return the MIME Type
*/
Actually, this lies. The per instance FileTypeMap if any, is queried, and the result
returned. There's no code that falls through to the system default registry when a
instance regitry is provided. In fact,
the api for FileTypeMap.getContentType doesn't encompass the idea of an 'unsucsessful'
query, since it returns 'application/octet-stream' when no mapping is available.
I assume that it's the documentation that should be corrected.
(While your're at it, note: "...in the for of a string.")
Javadoc for getContentType():
/**
* This method returns the MIME type of the data in the for of a
* string. The semantics of this call are to first search the
* per instance MIME Types registry and then check the system default
* registry returning the result of the first successful query.
*
* @return the MIME Type
*/
Actually, this lies. The per instance FileTypeMap if any, is queried, and the result
returned. There's no code that falls through to the system default registry when a
instance regitry is provided. In fact,
the api for FileTypeMap.getContentType doesn't encompass the idea of an 'unsucsessful'
query, since it returns 'application/octet-stream' when no mapping is available.
I assume that it's the documentation that should be corrected.
(While your're at it, note: "...in the for of a string.")
- backported by
-
JDK-2113042 javadoc for getContentType doesn't match actual behavior
-
- Closed
-