commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <>
Subject Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Date Fri, 30 Dec 2016 17:30:17 GMT
Sorry I meant *uniform* distribution


On Fri, Dec 30, 2016 at 5:58 PM +0100, "Bernd Eckenfels" <> wrote:

I am somewhat unclear, why would you require a random distribution (Interface). Is there no
better more generic Interface in RNG-API? Having said that I still think j.u.Random is fine
- but if not maybe a byte or int Provider would be better than a specific interface for the
random source.


On Fri, Dec 30, 2016 at 5:04 PM +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.

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.

>> and making more
>> progress on the best pattern after the 1.0 release.
> API decisions must be made before a major release.
> The best pattern is the above (IMHO, and as per Jochen's note):
> higher flexibility and higher correctness.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message