Suggestion for Interface where "ProgressBar" can pick up the progress state.

[pfeiferd]

At the moment the design for the ProgressBar-Library is such that the ProgressState must actively be changed by calling library code - either implicitly via some wrapper or by using stepBy(), stepTo() etc.
However, in some cases it might be more performant and easier if the ProgressBar would pick up the changing progress state right before rendering from some source that must implement a corresponding interface like:

public interface GSProgressUpdate {
    public long current();
    public long max();
}

In some cases this is more efficient than actively updating the progress state via stepBy(), stepTo(), since GSProgressUpdate would only be consulted right before rendering. I was able to implement this as a sort of "workaround" without changing existing library code. But it would be nicer if such an approach was already integrated in the library as an option. Here is a renderer that uses the above give interface:

private static class GSProgressBarRenderer extends DefaultProgressBarRenderer {
        private final GSProgressUpdate progressUpdate;
        private ProgressBar progressBar;

        protected GSProgressBarRenderer(String unitName, GSProgressUpdate progressUpdateProvider) {
            super(ProgressBarStyle.ASCII, unitName, 1, false, null, null, true, GSProgressBarRenderer::linearEta);
            this.progressUpdate = progressUpdateProvider;
        }

        public void setProgressBar(ProgressBar progressBar) {
            this.progressBar = progressBar;
        }

        @Override
        public String render(ProgressState progress, int maxLength) {
            if (progressUpdate != null) {
                progressBar.maxHint(progressUpdate.max());
                progressBar.stepTo(progressUpdate.current());
            }
            return super.render(progress, maxLength);
        }

        static Optional<Duration> linearEta(ProgressState progress) {
            if (progress.getMax() <= 0 || progress.isIndefinite()) return Optional.empty();
            else if (progress.getCurrent() - progress.getStart() == 0) return Optional.empty();
            else return Optional.of(
                        progress.getElapsedAfterStart()
                                .dividedBy(progress.getCurrent() - progress.getStart())
                                .multipliedBy(progress.getMax() - progress.getCurrent())
                );
        }
    }

Creating a matching progress bar in the context of this workaround as follows:

public static ProgressBar newGSProgressBar(String task, int updateIntervalMillis, String unitName, GSProgressUpdate progressUpdate, Log log) {
        GSProgressBarRenderer renderer = new GSProgressBarRenderer(unitName, progressUpdate);
        ProgressBarBuilder progressBarBuilder = new ProgressBarBuilder().
                setTaskName(task).setUpdateIntervalMillis(updateIntervalMillis).
                setUnit(unitName, 1).setRenderer(renderer).setMaxRenderedLength(100).continuousUpdate();
        if (log != null && log.isInfoEnabled()) {
            progressBarBuilder.setConsumer(new DelegatingProgressBarConsumer(log::info));
        }
        ProgressBar progressBar = progressBarBuilder.build();
        renderer.setProgressBar(progressBar);
        return progressBar;
    }

[ctongfei]

Thanks @pfeiferd ! Sorry, but I failed to understand how this is more performant: In the status quo, render is only called when an event happened (certain duration passed), and at that time ProgressState is being queried. ProgressState::stepTo is a very fast call, it is essentially just setting a long.

[pfeiferd]

It matters if you loop over a huge set of files (like 1 TB in total size). Also if something like an InputStream Wrapper (from your library) that counts bytes is already implemented outside your framework, the suggested interface makes it easy to integrate it without adding another delegating inputstream (thereby avoiding "your" delegating InputStream Wrapper altogether). Maybe other people have needs for this added flexibility that I cannot think of. It would not cause much complexity in your code, yet offer more flexibility for such needs.
Another point is hat the computation of max() and current() maybe expensive (as suggested above) - not from your side but from the caller's side! So, the caller cannot afford to compute the n for ProgressBar.stepBy(n) or stepTo(n) too often, best as rarely as really needed by the progress bar (i.e. just every second...). So it would be good if this compuation was done as rarely as possible - i.e. when needed for rendering. This can be achieved by above suggested interface / approach.

[ctongfei]

Then it would be up to the user to call stepBy more infrequently?

[pfeiferd]

But then, the burden to know when to call stepBy() "infrequently" is up to your API's user. I think, the easiest way for your library's users, is to offer them a callback that is called right before rendering. Because that is the only time when the progress info is needed, and only the progress bar itself knows when to render. (It is also common way to handle such things for most UI-related libraries. I.e., essentially, the TabelCellRenderer for JTables in Swing works this way.) My suggestion from further up still stands:

public interface GSProgressUpdate {
public long current();
public long max();
}

and the adjusted render method for your default renderer (such as in code further up):

    public String render(ProgressState progress, int maxLength) {
        if (progressUpdate != null) {
            progressBar.maxHint(progressUpdate.max());
            progressBar.stepTo(progressUpdate.current());
        }
        return super.render(progress, maxLength);
    }