On Wed, 28 Feb 2018 08:56:07 -0700, Gary Gregory wrote:
On Wed, Feb 28, 2018 at 6:35 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
Hello.
On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
Hi,
In the course of working through my pull request for adding new
LANG
functionality on top of the StopWatch class, the issue has been
raise as
to
if this functionality is ‘common’ or should
be placed in a more specialized commons-xxxx component.
We would like to take the discussion to the list for this, and see
what
everyone thinks.
The StackWatch provides for tracking nested timings backed by
StopWatch.
You can start the watch, and start and stop multiple timings
through the
call stack. Each timing is named and tag and has it’s own time.
You can visit all the timings, perhaps using the tags to filter
when you
are done. Please see the PR/Jira for more details. You should
look at
both, since the review has been split between the two.
If not LANG, then where? The commons-testing component has been
mentioned. But this code is not ‘test’ code explicitly. In my use
case (
I wrote this for the Apache Metron project and thought it might be
useful
here) it would not be test code, in the sense that it would be used
in
‘test’ scope in mvn. Rather it would be deployed in production, in
a
REPL,
and perhaps in other runtime components.
Part of what makes a good component is that it does not dictate
how and where applications should use it.
The name "Testing" does not imply that its contents must be used
within "test" scope.
A utility such as "StackWatch" could be another tool to integrate
in a unit test suite (e.g. to generate a more fine-grained timing
report than Junit does). Hence the module in which "StackWatch"
will belong is to become a dependency of modules that target
specific test framework (and that is true whether the former is
defined within "Testing" or in another component).
I would not want to pull in junit
or other dependencies with any component containing it.
+1
Must be ensured by proper granularity of the modular design.
If we put it in commons-testing ( which already has sub-modules
which are
geared towards junit ) it may be confusing, even if the module is
explicit
about purpose and keeping out junit dependent code ( or other
testing
code).
Why would it be confusing? The module will stand out on its own
(artefact/description/doc/web site) and be more visible than yet
another class in the already too large "Commons Lang".
Also, besides the StackWatch, what else would go into the new target
component? Would StopWatch move as well for example?
+1
But creating a new component for two small classes can reasonably
be argued as overkill.
FTR: I was asked to collect the sampling utilities within a
module of "Commons RNG" even though it could have warranted its
own component (being a plain "client" of the core functionality
of [RNG]). In the present case, "StackWatch" would belong to
"core" utilities of "Testing" that are pulled (along with other
dependencies by the more specific modules.
I would ask all of us to step back for a moment and consider the big
picture.
+1
Specifically, what do you consider the mandate or guidelines for
Commons
Lang to be? For me, this is code that should or could have been in
the JRE
in java.lang or java.util. Looking ahead to Java 9, Commons Lang
should
likely only depend on java.base (it does today but this should be
enforced
with the Maven JDeps Plugin IMO.)
+1
If you look at StringUtils, you can then see how this class has grown
into
a giant. You can also then see why other related code like a fancier
String.replace() could creep in as StrSubstitutor and friends. Should
variable interpolation have been in the JRE? Debatable, but it would
be
useful on top of Properties and ResourceBundle, one might argue; also
handy
for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
rightly IMO
-- have deprecated StrSubstitutor in Commons Lang in favor or its new
home
in Commons Text, where is has evolved further.
Package "java.text" is in module "java.base".
Revise the naming? ;-)
In my view, StopWatch and now StackWatch, do not belong in the JRE or
Commons Lang. It should sit slightly above that level.
I agree, but to be consistent, many things should be deprecated
before the next release of [Lang].
Where, is the
question.
It depends on the intended use-cases. Currently, I lack imagination
and see it fitting in [Testing].
Commons Testing for Stop/StackWatch does not seen quite right to me.
I
could see a new Commons Timing
Tentative description/scope?
or a more general Commons Measurement;
Too vague and/or too broad:
https://en.wikipedia.org/wiki/Measurement
with
a mandate NOT to overlap with Joda-Time and java.time.
Feature at hand is more about timer[1] than about date and
time manipulation.
The discussion should avoid implicit meanings. [We've been
there with opinions about "math" or "random" purely based
on a "name".]
Regards,
Gilles
[1] https://docs.oracle.com/javase/9/docs/api/java/util/Timer.html
Gary
Gilles
https://issues.apache.org/jira/browse/LANG-1373
<https://issues.apache.org/jira/browse/LANG-1373?page=com.
atlassian.jira.plugin.system.issuetabpanels%3Acomment-
tabpanel&focusedCommentId=16377279#comment-16377279>
https://github.com/apache/commons-lang/pull/311
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
