commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Date Fri, 30 Dec 2016 22:05:25 GMT
On Fri, 30 Dec 2016 20:00:50 +0100, Jörg Schaible wrote:
> Hi Gilles,
> Gilles wrote:
>> On Fri, 30 Dec 2016 17:03:56 +0100, Jörg Schaible wrote:
>>> Gilles wrote:
>>>> Hi.
>>>> On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote:
>>>>> Hello all,
>>>>> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira
>>>>> tickets before proceeding with the release, but I wanted to check
>>>>> to
>>>>> see if anyone else has any opinions on what work needs to be
>>>>> completed
>>>>> before the release.
>>>>> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively
>>>>> indifferent here, I just want some other’s to weigh in as to 
>>>>> their
>>>>> thoughts before deciding to leave in the dependency
>>>> I don't follow.
>>>> Currently, there is no dependency towards RNG.
>>>> Personally, I'm in favour of an API that "advertizes" and 
>>>> recommends
>>>> usage of its RNG sibling component.  [As [TEXT] is, admittedly, a
>>>> high-level component (and it already depends on [LANG]).]
>>>> However a consensual proposal would be to define a custom 
>>>> interface
>>>> (see JIRA discussion), and define the API around it.
>>>> [TEXT] should be made "multimodule"; it could then provide bridges
>>>> (cf. JIRA comment) in separate modules:
>>>>   * commons-text-core (algos)
>>>>   * commons-text-commons-rng-bridge (from
>>>> "o.a.c.rng.UniformRandomProvider")
>>>>   * commons-text-jdk-bridge (from "java.util.Random")
>>>> The dependency towards Commons RNG thus becomes optional.
>>>> But application developers have to explicitly choose an
>>>> implementation (which is good).
>>> You can achieve something similar by declaring commons-rng as
>>> optional. If
>>> you introduce an API for the random functionality and one
>>> implementation is
>>> based on commons-rng, any user will have to declare this dependency
>>> on his
>>> own if he like to use this implementation.
>> I don't follow; do you suggest something like letting the JVM throw
>> "ClassNotFoundException" at runtime?
> Yes, that's the consequence. Therefore it has to be a specific
> implementation that depends on rng and not the RandomStringUtils 
> class
> itself. Have a look at the POM of vfs core. The dependencies for 
> *all*
> provider specific implementations are optional.
> Such a setup might also fit for this case.
>>> We have a similar setup in vfs where you have to declare jsch as
>>> dependency
>>> on your own if you want SSH support for the protocol in use.
>> Isn't it similar to what I proposed? [I.e. declare a dependency on
>> the "commons-text-*-bridge" if one wants to use its contents.
>> Or I don't follow...
> RNG is no longer optional for commons-text if that interface is used 
> in a
> method signature of RandomStringUtils.


FTR: I'm +1 for a hard dependency on "Commons RNG".

The bridge is an alternate solution to satisfy those who (rather
mysteriously) would prefer to offer the possibility to use a bad
algorithm. ;-)

> However, if commons-text has its own
> minimal abstraction layer, we can use the optional declaration and 
> avoid a
> multi-project setup just for a single implementation.

The modular setup is done once, whereas IIUC, every app developer
will be forced to implement his own version of the bridge code.
IMO, that's not "user-friendly".


> Cheers,
> Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message