commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <e...@zusammenkunft.net>
Subject Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Date Sat, 31 Dec 2016 00:00:16 GMT
The issues of the j.u.Random implementation are only for the default implementation, if you
provide a different algorithm (from Securearandom or any distribution from RNG) you can avoid
it (if needed)

Gruss
Bernd
-- 
http://bernd.eckenfels.net




On Fri, Dec 30, 2016 at 10:50 PM +0100, "Gilles" <gilles@harfang.homelinux.org> wrote:










On Fri, 30 Dec 2016 18:22:37 +0000 (UTC), Bernd Eckenfels wrote:
> Hello,
> You suggested to use UniformRandomProvider in TEXT-36.
> I suggest to use j.u.Random because it is a common (interface like)

I know that already.
To advance the discussion, could you please comment on the issues
in the document I referred to below?

> type which is easy to provide any alternative random provider you
> would want (on protected method to implement)

See document.

> - just like InputStream
> is a commonly subtyped base class.

Comparison is not reason.
Perhaps "InputStream" is not as flawed as "Random"...

> In a lot of situations people will be happy with j.u.R

I bet that in the majority of those cases, they are happy
because they don't know better (a variation on "security
through obscurity").  I was among them a year ago.

Anyways my proposal takes care of people who'd insist on getting
randomness from "Random"; they'll choose the corresponding bridge,
with the knowledge that an LCG generator fails ~70 tests of
uniformity whereas state-of-the-art RNG algorithms fail 1 or 2
(see reports in RNG's user guide).

> or they can
> use SecureRandom (which also implements j.u.R),

Yet another flaw of old JDK's design decisions...
Anyways, the bridge allows this equally well.

> but if the need more
> control over the RNG or the distribution they can easily adjust. No
> multi-module or optional dependency is needed for that.
> And the RNG->j.u.Random bridge can be provided in RNG for other uses 
> as well.

I already wrote that such a bridge exists (see Javadoc of RNG's
"commons-rng-simple" module).
It is a sub-par solution.
There is no reason to stick to java.util.Random.

Where is the problem with a modular component?
This will be transparent to the average user (who, by the way,
wouldn't care less if there were a mandatory dependency on
Commons RNG).
For those who want more control of dependencies, it also won't
be a problem to state explicitly which bridge they want to use.


Gilles

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
>
>
> On Fri, Dec 30, 2016 at 7:11 PM +0100, "Gilles"
>  wrote:
>
>
>
>
>
>
>
>
>
>
> On Fri, 30 Dec 2016 17:30:17 +0000 (UTC), Bernd Eckenfels wrote:
>> Sorry I meant *uniform* distribution
>>
>> Gruss
>> Bernd
>>
>>
>>
>>
>>
>> On Fri, Dec 30, 2016 at 5:58 PM +0100, "Bernd Eckenfels"
>>  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hello,
>> I am somewhat unclear, why would you require a random distribution
>> (Interface).
>
> Who said?
>
>> Is there no better more generic Interface in RNG-API?
>
> Have you had a look at
>
> 
> http://commons.apache.org/proper/commons-rng/commons-rng-client-api/index.html
> ?
>
>> Having said that I still think j.u.Random is fine
>
> Have you read
>
> 
> http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
> ?
>
> Why use a poor algorithm when using a better one is as easy?
>
>> - but if not maybe a
>> byte or int Provider would be better than a specific interface for
>> the
>> random source.
>
> I don't follow.
> How do you define this "Provider" if not with an interface?
>
> Gilles
>
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>>
>>
>>
>>
>> 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.
>>
>> Cheers,
>> Jörg
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org







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