(This is cut-and-pasted from an API change proposal that was floated for 1.2.
A consensus wasn't reached in time, so I dropped it and changed it into this
RFE. When this comes up, for JDK 2.0 or beyond, I would like to be involved
in any discussions to make sure we don't end up hurting HotJava in the process
of fixing this. bill.foote@eng, June 6 '97)



Problem:

    The ftp: and file: protocol handlers have hard-wired knowledge of
    HotJava. They use HotJava icons for displaying directories (via
    the doc: protocol, and some hotjava.* system properties).

Requestor:

    Bill Foote

Proposed API change:

    Add this method to java.net.URLConnection:

/**
* Associates a directory listing generator with this connection. If
* this connection represents a directory, the generator can be used
* to produce application-specific HTML.
* Not all connection types support reading directories (ftp: and
* file: do, http: does not).
*/
public void setDirectoryListingGenerator(DirectoryListingGenerator g) {
}
    
    And add this interface:

package java.net;

public interface DirectoryListingGenerator {

public void addDirectory(OutputStream out, String name);

public void addFile(OutputStream out, String name);

}

Implementation:

    Change sun.net.www.protocol.file.FileURLConnection and
    sun.net.www.protocol.ftp.FtpURLConnection so that their default
    behavior is to produce simple HTML with no images. Add the ability
    to associate a directory listing generator with a java.net.URLConnection
    instance; this instance would be ignored by other flavors of URLConnection.

    HotJava (and other clients) would simply keep a singleton instance of
    (an implementation of) DirectoryListingGenerator, and associate it
    with each connection.

Risk assessment:

    Low. It's a change that simply inverts dependencies so that the JDK
    does not have hard-wired knowledge of HotJava.

Testing impact:

    Tests would have to be written for the JCK. On the other hand, we
    _don't_ have to test for the counter-intuitive behavior of the
    current JDK, where references to a hidden API (i.e. the system
    properties hotjava.file.iconheight et al).

Documentation impact:

    The javadoc documentation should suffice.