JDK-4408059 : File should be made abstract to allow modeling platform-specific filesystem semantics
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2001-01-25
  • Updated: 2009-02-16
  • Resolved: 2009-02-16
Related Reports
Duplicate :  
JDK-4313887 - New I/O: Improved filesystem interface
Relates :  
JDK-4125893 - FileSystem class to encapsulate the abilities and limitations of a platform
Description
Name: boT120536			Date: 01/24/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

java.io.File should be made to implement a 'FileInterface' (or other suitable
name), and functions should return this type to allow environments modeling
filesystem semantics to fit in tranparently. While 'File' would be a more
suitable name, perhaps with the current file moving to 'FileImpl', this
wouldn't be feasible, given that it would require modications to existing
applications (given the lack of a Factory/SPI for File's).

Likewise, a getInputStream() and getOutputStream() should be added, eliminating
the user's need to directly instancsiate a File{In|Out}putStream (just as is
done with Socket and Process).

By allowing simple subclassing of File and encapsulating the creation of
streams, alternate backends could be integrated into existing applications with
ease. Apparent applications would be a JDBC-backed interface to heirarchically
stored BLOB's, or a transparent interface to the FTP procotocol. With the
availablity of SMB client packages, the added benefit should be clear.
(Review ID: 115515) 
======================================================================
Comments
EVALUATION This feature has been addressed by the new file system API defined by JSR-203.
16-02-2009
WORK AROUND Name: boT120536 Date: 01/24/2001 Create an alternate interface in private namespace, with a frontend to the existing java.io.File, and extending to other applications as needed. This would be only marginally useful, given that it would not accomodate methods already expecting a java.io.File. Overriding all of java.io.File would be impractical, giving its many native ties, and lack of default constructor; futher, the fact that stream creation is externalized makes the discussion purely academic. ======================================================================
11-06-2004
EVALUATION A new filesystem API along these lines is slated for the 1.5 release. -- ###@###.### 2002/4/25
04-10-0191