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.
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.)
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.
In my view, StopWatch and now StackWatch, do not belong in the JRE
or
Commons Lang. It should sit slightly above that level. Where, is the
question.
Commons Testing for Stop/StackWatch does not seen quite right to me.
I
could see a new Commons Timing or a more general Commons
Measurement; with
a mandate NOT to overlap with Joda-Time and java.time.
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
>>
>
>
