JDK-4039759 : java.io.File: Need more robust way to deal with file types across platforms
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.0.2
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_95
  • CPU: x86
  • Submitted: 1997-03-18
  • Updated: 2000-03-10
  • Resolved: 2000-03-10
Related Reports
Duplicate :  

Name: mc57594			Date: 03/18/97

1. Currently I see no way to save a file as a specific type on the MacOS.  If I have a file of type "Text/Plain" (MIME seems to be the best way to describe file types), each OS has a different way of noting the files type.  It would be nice if there were a method in the File class to save a file as a given MIME type

2. Along the same lines, it would be nice if the File class had a method to return a legal file name (or File object) given a proposed name.  For example, if I wanted to name a file "one: cat/dog\mouse" it would fail on different OSes for different reasons: a Mac would only need to hack out the colon, where windows would also need to eliminate the slashes.  Also, each OS has a different max_length for a file name, this method would also deal with that problem.  This method should also have a flag that would decide if, give an a directory, the file name needed to be unique.

3. Would be nice if the FilenameFilter class had a non-abstract method which filtered files based on MIME content-types (provided by the programmer).

4. There seems to be no way to find out the type of the file after reading it.  In Win32 you can guess based on the Extension, but on the Mac this doesn't work.  Could a property be added to the File class that would do this independant of the OS? (Please use MIME content-types for this).
company -  , email - ###@###.###

WORK AROUND Name: mc57594 Date: 03/18/97 I've written some of the classes mentioned above for Win32, but there doesn't seem to be a way to deal with them on the Mac. ======================================================================

EVALUATION This issues will be addressed as part of the New I/O work. -- mr@eng 2000/3/9