Implement StopWatch lap

[michaldo]

Example: StopWatch watch = StopWatch.createStarted(); sleep(30ms) watch.lap() // returns 30 sleep(10ms) watch.lap() // returns 10

[michaldo]

BTW, split has a bug: if stop watch is suspended and resumed, startTimeNanos is moved forward but stopTimeNanos not. For example:

watch.start()
watch.split()
watch.suspend()
sleep(100ms)
watch.resume()
watch.getSplitTime() // -100

IMHO split is overengineering. Instead of split()->getSplitTime()->unsplit() I can just call watch.getTime() when I need. I suggest delete split functionality at all.

BTW2, I suggest also drop reset, because buying brand new StopWatch cost nothing. BTW3, I suggest also drop a stop, because when StopWatch is done, caller just calls watch.getTime() and does not care StopWatch anymore. There is no battery nor thread inside the StopWatch, and stop is not needed.

[coveralls]

Coverage increased (+0.003%) to 94.978% when pulling 2b828299022c7f4f88cea54fabf2e05d53c3986e on michaldo:master into a1495290b931856840bf358dbfd551639081d227 on apache:master.

[garydgregory]

I think you need to explain in the class Javadoc how lap works, especially in contrast to split. What does it mean to lap a stopped watch, and such edge cases, and error states.

The whole class makes me wonder if we need to redo it in terms of java.time.Duration.

[michaldo]

@garydgregory, explanation how StopWatch works would be much more demanding task that implementing lap()!

The problem is that current StopWatch is good model how physical device works, but bad class to use in software development. It is over-complicated.

First problem is state diagram (life-cycle). As a software developer, I want stop watch to measure how long runs some piece of code. I want get time spent between start and stop point, without learning stopwatch states. Second problem is API. The difference between split and lap must be clarified because both exists. Split is overhead, because every time I need split stopwatch time, I can just call getTime().

I'm afraid that current StopWatch passed point of no return: bringing back to operability needs rebuild from scratch. I don't know if it is acceptable in commons-lang.

What do you think about creating new class, SimpleStopWatching with three methods:

static SimpleStopWatching.started();
SimpleStopWatching.getTime()
SimpleStopWatching.lap()

? That API is self-descriptive (I will add Javadoc of course), simple, without state diagram and functionally identical with StopWatch. For example suspend/resume can be implemented with two simple stop watched.

SimpleStopWatch will match commons-lang spirit: classes from the library are not a rocket science, but saves developer write few lines of code. SimpleStopWatch match commons-lang, StopWatch match joda-time