JDK-4379535 : File, FileInputStream, FileOutputStream, RandomAccessFile factories for platform dependent behavior
  • 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: 2000-10-16
  • 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: rmT116609			Date: 10/16/2000


java version "1.3.0"

This request is probably addressed to future versions of JDK.

This would be very convenient to have custom factories to implement the
alternative functionality of filesystem-related classes. Some time ago I was
experimenting with emulating the filesystem over JDBC database connection. Files
were stored in a database as BLOBs (or emulated BLOBs), file streams
functionality together with directory search functionality were implemented
using appropriate SQL statements and proper query results interpretation. In the
same time, the database provided a consistent storage for all data, thus
enabling access to file objects in alternative (not only file-stream-oriented)
ways. A database is not the only illustration: sometimes it would be useful to
access FTP and HTTP-accessible storages transparently like they were regular
files.

Of course, new applications always may be designed with these aspects in mind
(to use a database as a primary storage, or use URIs to identify file-like
objects). However existing applications like javac and other tools supplied with
JDK seem to have file I/O access methods hardcoded without any possibility to
access, say, Java sources stored in other way than in a particular filesystem.
Also in some cases it is just easier to interpret data objects as named files.
(Review ID: 110864) 
======================================================================
Comments
EVALUATION JSR-203 defines a service provider interface for requirements such as this. For the specific request, the submitter could implement SeekableByteChannel and define a class with factory methods to open channels to the required entities.
16-02-2009
WORK AROUND Name: rmT116609 Date: 10/16/2000 The easiest workaround may be implementing File, FileInputStream, FileOutputStream (and possibly RandomAccessFile) to work with resources whose URI scheme is "file:". For directory operations of File class a special scheme "dir:" may be implemented. Something similar may also be implemented for RandomAccessFile. Default implementation of these URI schemes (URL protocols) may map all the operations directly to the existing legacy filesystem of the underlying OS. An application may specify alternative URL protocol implementation packages (via the system property "java.protocol.handler.pkgs" as it was in JDK1.1). By redefining the implementation of appropriate URL protocols, an application, on behalf of its developers, may transparently change the default file objects access methods. In the same time, default implementation will be compatible with existing JDK versions. Speaking strictly, this is not a "Factory" mechanism, however acting like a factory. I tried to implement this approach using alternative open-source Java runtime implementation (Kaffe). However, directory operations in the File.class were implemented directly with issuing SQL statements. As a result, it became possible to "cheat" the KJC compiler to access Java source files really stored in the database just like those were stored in a regular filesystem. Of course, this worked slower than the regular filesystem access (although I undertook no attempts to make it faster, I only wanted to find out that the solution works). Additional advantage of this was pure Java implementation of the filesystem access (therefore independent of the OS). ======================================================================
11-06-2004
EVALUATION Will be addressed in the forthcoming new filesystem API. -- ###@###.### 2002/3/21 A new JNDI File System Provider can address some of the functionality requested in this RFE. ###@###.### 2005-07-15 06:24:19 GMT
03-10-0187