Using edtFTPj on an "intent" system (from Tao Grou

Question

I want to send some files from a mobile device (OS: Windows CE.net) via FTP and Java. Therefor i look for a suitable little package and found edtFTPj. The JVM is build in the intent system supplied with the device.

intent supports PJAE 1.2, which is based upon the JDK 1.1.8 API.

Hence i unfortunately get the same problems discussed in earlier threads http://www.enterprisedt.com/forums/viewtopic.php?t=90 and http://www.enterprisedt.com/forums/viewtopic.php?t=88. I agree to MrBlobby's opinion, that you should change a couple of lines to make the code compatible to Java 1.1. Your one HTTP-download-site says about the edtFTPj versions:

They should work for most versions of Java, although 1.1.x may need some tweaking.

But this tweaking isn't necessary at all! For version 1.4.0 you need the following accommodations:

• FTPClient.java (line 1633)

              lines.addElement(line);

• FTPClient.java (line 1648)

                  lines.copyInto(result = new String[lines.size()]);

  The suggestion from MrBlobby can not be compiled (and is to complicated)!
• Logger.java (line 221)

              Appender a = (Appender)appenders.elementAt(i);

• Logger.java (line 297)

                  Appender a = (Appender)appenders.elementAt(i);

There is no reason not to do it, because it is completely compatible!

Further accommodations must be made because of the "java.io.UnsupportedEncodingException". I think there is no spezification that requests the support of special Encodings from a JVM implementation. Well, FTP may use "US-ASCII". Furthermore it is always a good idea to use a constant instead to hard code this String twice. But so we can use a variable and change it in case of necessity. In addition the Streams should fallback to the system default Encoding if "US_ASCII" is not available. My suggestion:

• FTPControlSocket.java (line 195)

       private void initStreams()
           throws IOException {
  
           // input stream
           InputStream is = controlSock.getInputStream();
           InputStreamReader isr;
           // output stream
           OutputStream os = controlSock.getOutputStream();
  
           try {
               isr = new InputStreamReader(is, Encoding);
               writer = new OutputStreamWriter(os, Encoding);
           }
           catch (UnsupportedEncodingException ex) {
               isr = new InputStreamReader(is);
               writer = new OutputStreamWriter(os);
           }
           reader = new BufferedReader(isr);
       }

• FTPControlSocket.java (add)

  import java.io.UnsupportedEncodingException;
  
     /**
      * The Encoding of the reader/writer of the control stream
      */
     public static String Encoding = "US-ASCII";

Further improvements
I am using eclipse and turned on many warnings. So i saw immediately your old mistake concering the unused argument "controlPort" in a constructor of FTPClient. But then there are ugly warnings concerning the unused fields "cvsId". If they are private the make no sense at all. Make them public or write the CVS information in the JavaDoc. I think than it is more useful.

Regards

Answer 1

We'll look at enabling 1.1.x support for 1.4.1

The cvsId is there so that jar files can be interrogated for the version number of each file - which can be quite useful.

But then there are ugly warnings concerning the unused fields "cvsId". If they are private the make no sense at all. Make them public or write the CVS information in the JavaDoc. I think than it is more useful.

Regards

Answer 2

Just for more info: the Unix 'what' command searches for @(#) in a file, so you can use the 'what' command to find out what versions of classes are in your jar file.

That's why cvsId is in our classes.

We'll look at enabling 1.1.x support for 1.4.1

The cvsId is there so that jar files can be interrogated for the version number of each file - which can be quite useful.

But then there are ugly warnings concerning the unused fields "cvsId". If they are private the make no sense at all. Make them public or write the CVS information in the JavaDoc. I think than it is more useful.

Regards