开发FTP不要使用sun.net.ftp.ftpClient

转自：http://cai21cn.iteye.com/blog/700188

在开发一个web应用过程中，需要开发一个服务使用ftp功能将数据传输一个网外的ftp服务器。最初使用sun.net.ftp.ftpClient类，但是遇到问题，在网内测试没有问题，向网外传时报告失败。开发环境如下： 
web服务：tomcat 5.5.28 
OS平台：Linux 5 
java: 1.5 
失败报告：port命令失败，试试用pasv代替。代码如下：

1. TelnetOutputStream os = null;
2. FileInputStream in =null;
3. try {
4. logger.debug("开始上传文件"+sourceFile);
5. java.io.File file_in = new java.io.File(sourceFile);
6. in = new FileInputStream(file_in);
7. //ftpClient.sendServer("TYPE I \r\n");
8. //ftpClient.sendServer("PASV \r\n" );
9. //logger.debug("发送TYPE I 和　PASC命令");
10. // 命名文件,将文件名编码转为utf-8,否则中文文件名上载后为乱码文件名
11. //os = ftpClient.put(new String(targetFile.getBytes("UTF-8")));
12. os = ftpClient.put(targetFile);
13. logger.debug("创建"+targetFile+" 成功");
14. byte[] bytes = new byte[4096];
15. int c;
16. while ((c = in.read(bytes)) != -1) {
17. os.write(bytes, 0, c);
18. }
19. } catch (IOException e) {
20. logger.error(e.getMessage());
21. return 0;
22. } finally {
23. if (in != null) {
24. in.close();
25. }
26. if (os != null) {
27. os.close();
28. }
29. }

代码在os = ftpClient.put(targetFile)这句出错，这样的代码在网上都很常见，但大约可以肯定的是许多的人只是拷贝复制下来构造一篇博文，并没有真正实践过。 
　　试着给服务器发送PASV命令也不行。查看ftpClient的源代码，发现ftpClient在上载数据前首先尝试PASV模式，如PASV模式失败再使用PORT模式。通过TelnetOutputStream os = null此句代码，推测是否使用了telent功能，调整两边的路由器防火墙功能，折腾半死，程序失败依旧。 
　　鉴于源代码使用telnetoutputStream,又没有控制传输模式的方法和命令，最后只好弃用sun.net.ftp.ftpClient，使用org.apache.commons.net.ftp.FTPClient类开发调试成功。部分代码如下：

1. public boolean uploadFile(String fileName, String newName)
2. throws IOException {
3. boolean flag = false;
4. InputStream iStream = null;
5. try {
6. iStream = new FileInputStream(fileName);
7. ftpClient.enterLocalPassiveMode();
8. logger.debug("Set pasv return code:"+ftpClient.getReplyCode());
9. flag = ftpClient.storeFile(newName, iStream);
10. logger.debug("upload file return code:"+ftpClient.getReplyCode());
11. } catch (IOException e) {
12. logger.debug("upload error:"+ftpClient.getReplyCode());
13. flag = false;
14. return flag;
15. } finally {
16. if (iStream != null) {
17. iStream.close();
18. }
19. }
20. return flag;
21. }

　　最后，找到java的老巢去，发现在java 1.5的文档里，有这样一段话：

Why Developers Should Not Write Programs 
That Call 'sun' Packages 
The classes that Sun includes with the Java 2 SDK, Standard Edition, fall into package groups java.*, javax.*, org.* and sun.*. All but the sun.* packages are a standard part of the Java platform and will be supported into the future. In general, packages such as sun.*, that are outside of the Java platform, can be different across OS platforms (Solaris, Windows, Linux, Macintosh, etc.) and can change at any time without notice with SDK versions (1.2, 1.2.1, 1.2.3, etc). Programs that contain direct calls to the sun.* packages are not 100% Pure Java. In other words:

The java.*, javax.* and org.* packages documented in the Java 2 Platform Standard Edition API Specification make up the official, supported, public interface. 
    If a Java program directly calls only API in these packages, it will operate on all Java-compatible platforms, regardless of the underlying OS platform.

The sun.* packages are not part of the supported, public interface. 
    A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.

For these reasons, there is no documentation available for the sun.* classes. Platform-independence is one of the great advantages of developing in the Java programming language. Furthermore, Sun and our licensees of Java technology are committed to maintaining backward compatibility of the APIs for future versions of the Java platform. (Except for code that relies on serious bugs that we later fix.) This means that once your program is written, the class files will work in future releases. 
　　具体URL：http://java.sun.com/products/jdk/faq/faq-sun-packages.html 
　　真是为在sun.net.ftp上浪费掉的时间懊恼不已。 
　　留文于此，希望广大朋友们在开发过程中少走弯路。 
　　PS到处拷贝粘帖赚文章的“专业技术作家”!

---------------------------------

目前官方文章已经改写为：

Why Developers Should Not Write Programs  
That Call 'sun' Packages

The java.*, javax.* and org.* packages documented in the Java Platform Standard Edition API Specification make up the official, supported, public interface. 
If a Java program directly calls only API in these packages, it will operate on all Java-compatible platforms, regardless of the underlying OS platform.

The sun.* packages are  not part of the supported, public interface.  
A Java program that directly calls into sun.* packages is  not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.

Each company that implements the Java platform will do so in their own private way. The classes in sun.* are present in the JDK to support Oracle's implementation of the Java platform: the sun.* classes are what make the Java platform classes work "under the covers" for Oracle's JDK. These classes will not in general be present on another vendor's Java platform. If your Java program asks for a class "sun.package.Foo" by name, it may fail with ClassNotFoundError, and you will have lost a major advantage of developing in Java.

Technically, nothing prevents your program from calling into sun.* by name. From one release to another, these classes may be removed, or they may be moved from one package to another, and it's fairly likely that their interface (method names and signatures) will change. (From Oracle's point of view, since we are committed to maintaining the Java platform, we need to be able to change sun.* to refine and enhance the platform.) In this case, even if you are willing to run only on Oracle's implementation, you run the risk of a new version of the implementation breaking your program.

In general, writing java programs that rely on sun.* is risky: those classes are not portable, and are not supported.