FTP provides the basic the functionality necessary to implement your own FTP client. It extends org.apache.commons.net.TelnetClient simply because it saves the writing of extra code to handle the FTP control connection which always remains open during an FTP session and uses the Telnet protocol. Aggregation would require writing new wrapper methods and wouldn't leverage the functionality already present in org.apache.commons.net.SocketClient.

To derive the full benefits of the FTP class requires some knowledge of the FTP protocol defined in RFC 959. However, there is no reason why you should have to use the FTP class. The FTPClient class, derived from FTP, implements all the functionality required of an FTP client. The FTP class is made public to provide access to various FTP constants and to make it easier for adventurous programmers (or those with special needs) to interact with the FTP protocol and implement their own clients. A set of methods with names corresponding to the FTP command names are provided to facilitate this interaction.

You should keep in mind that the FTP server may choose to prematurely close a connection if the client has been idle for longer than a given time period (usually 900 seconds). The FTP class will detect a premature FTP server connection closing when it receives a FTPReply.SERVICE_NOT_AVAILABLE response to a command. When that occurs, the FTP class method encountering that reply will throw an FTPConnectionClosedException . FTPConectionClosedException is a subclass of IOException and therefore need not be caught separately, but if you are going to catch it separately, its catch block must appear before the more general IOException catch block. When you encounter an FTPConnectionClosedException , you must disconnect the connection with disconnect() to properly clean up the system resources used by FTP. Before disconnecting, you may check the last reply code and text with getReplyCode , getReplyString , and getReplyStrings . You may avoid server disconnections while the client is idle by periodicaly sending NOOP commands to the server.

Rather than list it separately for each method, we mention here that every method communicating with the server and throwing an IOException can also throw a MalformedServerReplyException , which is a subclass of IOException. A MalformedServerReplyException will be thrown when the reply received from the server deviates enough from the protocol specification that it cannot be interpreted in a useful manner despite attempts to be as lenient as possible.