How to monitor progress (JProgressBar) with FileChannels transferFrom() method?

Question

I need a little help with the JProgressBar component. My program copies files from one place to another using java.nio FileChannels. The actual copy method is transferFrom().

I've got two questions now.

1. How to I monitor the transfer progress of FileChannels? All tutorials I've found use the conventional java.io InputStreams and increase the progress int while looping through the inputstream.

2. My copy methods (the FileChannel methods) are encapsulated in a separate method that is invoked by other methods that iterate though source and destination folders and then invoke the FileChannel methods for each file.

How do I implement a ProgressBar for the complete copy mechanism?

Well I should have read the FAQ a little earlier, so I guess I have to edit my initial post instead of commenting the answers, right?

Ok this is what I've done so far. Just as jambjo suggested (thanks by the way), the transferFrom() method is now looped. BTW: Is there a preferable chunk size, or does it depend on the granularity of my progress bar just as EJP said?

Here is my code snippet:

while (position < size) {
 position += destination.transferFrom(source, position, chunkSize);
 current =  (position/size)*100;
 System.out.println(current);
}

Unfortunately the 'current' value stays 0 within the loop and I've got no idea why. Am I missing something?

Thanks again jambjo! I really appreciate your input! Now that the progress monitoring of a single file works, let's address my second problem.

---

I'd like, no I have to, monitor progress of not only a single file, but rather a bunch of files. My main copy methods iterates through various directories and copies appropriate files by invoking the actual transfer method. So the copy methods don't transfer files, they are just selecting files for the actual transfer method.

Raze

if position and size are integer types (int or long), the integer division position/size will always be 0, if size is greater than position. (int)(100.*position/size) will probably do what you want. – Sever

Answer 1

There is no way to monitor the progress of a single invokation of transferFrom, but since you can pass it offset and length parameters, you can implement your own loop around it and update the progress bar between suitable sized chunks of data.

Sever

Yes but this solution will affect the performance of the NIO API, won't it? In this case, there is no point using it. Peter should probably use the IO API. – Table

@Maxbester: If the chunks are reasonably sized (large chunks preferred), the performance difference should be negligible. – Sever

You could execute transferFrom in its own thread then monitor it's progress from your main (blocked) thread... It should be the best of both worlds – Talebearer

Answer 2

I realize I'm resurrecting a very old thread here but I came across it in my googling today, so...

If you want to monitor progress it's better as EJP suggests to let the system deal with the chunk size so it can optimize the transfer. The way to monitor is to write a wrapper class for ReadableByteChannel that you use to pass progress messages whenever its read method is called. Here's an example:

package download.progress.example;

import java.io.FileOutputStream;
import java.io.IOException;
import java.net.HttpURLConnection;
import java.net.URL;
import java.nio.ByteBuffer;
import java.nio.channels.Channels;
import java.nio.channels.ReadableByteChannel;

public class DownloadProgressExample {
    public static void main( String[] args ) {
        new Downloader( "/tmp/foo.mp3", "http://example.com/bar.mp3" );
    }

    private interface RBCWrapperDelegate {
        // The RBCWrapperDelegate receives rbcProgressCallback() messages
        // from the read loop.  It is passed the progress as a percentage
        // if known, or -1.0 to indicate indeterminate progress.
        // 
        // This callback hangs the read loop so a smart implementation will
        // spend the least amount of time possible here before returning.
        // 
        // One possible implementation is to push the progress message
        // atomically onto a queue managed by a secondary thread then
        // wake that thread up.  The queue manager thread then updates
        // the user interface progress bar.  This lets the read loop
        // continue as fast as possible.
        public void rbcProgressCallback( RBCWrapper rbc, double progress );
    }

    private static final class Downloader implements RBCWrapperDelegate {
        public Downloader( String localPath, String remoteURL ) {
            FileOutputStream        fos;
            ReadableByteChannel     rbc;
            URL                     url;

            try {
                url = new URL( remoteURL );
                rbc = new RBCWrapper( Channels.newChannel( url.openStream() ), contentLength( url ), this );
                fos = new FileOutputStream( localPath );
                fos.getChannel().transferFrom( rbc, 0, Long.MAX_VALUE );
            } catch ( Exception e ) {
                System.err.println( "Uh oh: " + e.getMessage() );
            }
        }

        public void rbcProgressCallback( RBCWrapper rbc, double progress ) {
            System.out.println( String.format( "download progress %d bytes received, %.02f%%", rbc.getReadSoFar(), progress ) );
        }

        private int contentLength( URL url ) {
            HttpURLConnection           connection;
            int                         contentLength = -1;

            try {
                HttpURLConnection.setFollowRedirects( false );

                connection = (HttpURLConnection) url.openConnection();
                connection.setRequestMethod( "HEAD" );

                contentLength = connection.getContentLength();
            } catch ( Exception e ) { }

            return contentLength;
        }
    }

    private static final class RBCWrapper implements ReadableByteChannel {
        private RBCWrapperDelegate              delegate;
        private long                            expectedSize;
        private ReadableByteChannel             rbc;
        private long                            readSoFar;

        RBCWrapper( ReadableByteChannel rbc, long expectedSize, RBCWrapperDelegate delegate ) {
            this.delegate = delegate;
            this.expectedSize = expectedSize;
            this.rbc = rbc;
        }

        public void close() throws IOException { rbc.close(); }
        public long getReadSoFar() { return readSoFar; }
        public boolean isOpen() { return rbc.isOpen(); }

        public int read( ByteBuffer bb ) throws IOException {
            int                     n;
            double                  progress;

            if ( ( n = rbc.read( bb ) ) > 0 ) {
                readSoFar += n;
                progress = expectedSize > 0 ? (double) readSoFar / (double) expectedSize * 100.0 : -1.0;
                delegate.rbcProgressCallback( this, progress );
            }

            return n;
        }
    }
}

Fascista

Very nice. Yes, the thread was old but I also found it by googling and your solution is really useful. – Zenia

This will work, but be aware that if you use a wrapping ReadableByteChannel as a replacement for a FileChannel as the source channel in FileChannel#transferFrom(...), you circumvent potential optimizations in the API implementation. Oracle's JVM e.g. uses FileChannel.map to access data from the source channel instead of ReadableByteChannel.read. – Sever

Answer 3

... although that would be completely beside the point of using transferTo() in the first place, which is to hand the copying off to the kernel as much as possible. Either you want to do that or you want to see progress. You have to choose. At least you have to choose how much granularity you want in the progress display.

Homeroom

No. You are right that the main advantage of the transfer* methods in FileChannel is to do the copying at the lowest possible level, but there's no reason why copying an entire file should be performing much better than copying smaller chunks at a time. – Sever

Err, yes there is, that's why the API exists. If the kernel doesn't have to reschedule the processes, re-map the memory, etc, itcan do a much more efficient copy. The larger the chunks the better. – Homeroom