Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4669305

NetworkFile class (or similar) to support WebDAV, FTP, CVS, etc

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 1.4.0
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_2000

      Description

      Name: nt126004 Date: 04/16/2002


      FULL PRODUCT VERSION :
      java version "1.4.0-rc"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
      Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)


      FULL OPERATING SYSTEM VERSION :
      Microsoft Windows 2000 [Version 5.00.2195]

      ADDITIONAL OPERATING SYSTEMS :

      All that have JVM implementations


      A DESCRIPTION OF THE PROBLEM :
      Although local files are generally read from/written to
      with java.io.File and networked files (other than NFS/UNC
      files) are read from/written to via classes in java.net and
      InputStreams/OutputStreams, these classes are not fully
      capable of providing high-level access to certain file
      storage protocols and strategies. In particular:

      - WebDAV
      - FTP
      - CVS, VSS, etc.

      These are special cases, but with a lot in common, and some
      more "value-added" features that you don't see in java.io
      or java.net at present. In particular (for a lot of them):

      - remote filesystem exploration

      - version control, including rollbacks, enumerating
      differences between versions, etc. (not FTP)

      - "check-in" and "check-out" using various authentification
      schemes (access control, access locking)

      - common file operations, such as reading, writing, getting
      or setting metadata (such as file size)... these are
      available generally with java.io.File, but not with
      java.net classes (this also applies to remote filesystem
      exploration)

      These are just examples, obviously other features become
      apparent by looking at what each protocol/system offers.

      Where required, authentification could be implemented using
      JAAS or some other API if necessary (now that it's in the
      standard APIs).

      I would suggest that this is implemented using a service
      provider interface, so that some of the above are
      available "as standard", some as optional implementations,
      and also as that leaves the way clear for other future
      implementations. This also means that "rich network
      protocols" (such as WebDAV, CVS, et al. with version
      control, access control, et al.) can share a common API.

      If a SPI interface is used to implement the above, the main
      interface could also be used to query whether an underlying
      implementation supports a particular feature (such as
      version control, which FTP does not support).

      This bug can be reproduced always.

      CUSTOMER WORKAROUND :
      Handling this at a low level using java.io and java.net...
      or writing classes to drive external client software (using
      Runtime.exec()).
      (Review ID: 145463)
      ======================================================================

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                alanb Alan Bateman
                Reporter:
                nthompsosunw Nathanael Thompson (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: