commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [DISCUSS] new component for timing?
Date Wed, 28 Feb 2018 16:48:45 GMT
On Wed, 28 Feb 2018 08:56:07 -0700, Gary Gregory wrote:
> On Wed, Feb 28, 2018 at 6:35 AM, Gilles 
> <gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message