OK, I get it now. I am just worried about making people change things
twice - first to a method that takes Duration rather than long and then to
another one that does the same thing but now has a different name. How
about leaving the 2.x names as is, not adding new methods with the same
Hi Phil,
There can get some ambiguity for me when I read code like (unless you know
the API inside and out and use it on the daily):
somePoolThing.getFooTime()
Some of our methods return a Duration and others an Instant, so there, I
think the type in the method name makes sense. Then, for a bit
I like changing the arguments to be Duration, but that has already been
done. What I am talking about is the method names, which is a second
change that I don't think is necessary. For example, unless I am missing
something, before this commit, we had setTimeBetweenEvctionRuns(Duration)
and
This will make it smoother to port to 3.0 where there will be no long time
APIs, the Duration type is used throughout (unless Instant is appropriate).
I have most of the deprecated methods removed locally and will push in a
day or two.
What remains:
- do we want to keep the JMX code?
- should 3.0
Why exactly do we need to s/Time/Duration in all of the method names?
Duration is a measure of time. I don't get why this is necessary and it
will force people to change (eventually). I was +1 to get rid of the
"millis" in the names, but this change seems needless to me. Also, there
are still
