[text] 1.0 release progress.

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[text] 1.0 release progress.

Rob Tompkins
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 and making more progress on the best pattern after the 1.0 release.

Regarding TEXT-42: '[XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?’, I think we should minimally include something in the javadoc directly stating that with the string '\"' and the output will be '\\\”’ and to be careful using the method from a security perspective. I think maximally we should implement a distinct method that accommodates ECMA script escaping with security being the primary focus of the method, but it feels like this could wait to be included down the road.

For the other tickets, they did not seem to me to be quite as pressing as these, but I’m open to ensuring whatever gets resolved prior to releasing. I mainly just want a second set of eyes on the list of Jira’s before proceeding.

Cheers and happy new year,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[text] TEXT-36 (Was: [text] 1.0 release progress)

Gilles Sadowski
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).

> 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.

Regards,
Gilles

>
> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Jörg Schaible
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Bernd Eckenfels
Hello,
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.

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




On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Bernd Eckenfels
Sorry I meant *uniform* distribution

Gruss
Bernd





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










Hello,
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.

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




On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]











Reply | Threaded
Open this post in threaded view
|

Re: [text] 1.0 release progress.

garydgregory
In reply to this post by Rob Tompkins
We could add the dep for a 1.1 or 2.0 release but removing the dep would be
more painful for users that end up depending on it. The question is: how
much benefit do we really get for TEXT from a dep on RNG.

Gary

On Dec 30, 2016 6:40 AM, "Rob Tompkins" <[hidden email]> 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 and making more progress on the
> best pattern after the 1.0 release.
>
> Regarding TEXT-42: '[XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?’,
> I think we should minimally include something in the javadoc directly
> stating that with the string '\"' and the output will be '\\\”’ and to be
> careful using the method from a security perspective. I think maximally we
> should implement a distinct method that accommodates ECMA script escaping
> with security being the primary focus of the method, but it feels like this
> could wait to be included down the road.
>
> For the other tickets, they did not seem to me to be quite as pressing as
> these, but I’m open to ensuring whatever gets resolved prior to releasing.
> I mainly just want a second set of eyes on the list of Jira’s before
> proceeding.
>
> Cheers and happy new year,
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Gilles Sadowski
In reply to this post by Jörg Schaible
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?

>
> 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...

Regards,
Gilles

>
>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Gilles Sadowski
In reply to this post by Bernd Eckenfels
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"
> <[hidden email]> 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"
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Bernd Eckenfels
Hello,
You suggested to use UniformRandomProvider in TEXT-36.
I suggest to use j.u.Random because it is a common (interface like) type which is easy to provide any alternative random provider you would want (on protected method to implement) - just like InputStream is a commonly subtyped base class.
In a lot of situations people will be happy with j.u.R or they can use SecureRandom (which also implements j.u.R), 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.

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




On Fri, Dec 30, 2016 at 7:11 PM +0100, "Gilles" <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Jörg Schaible
In reply to this post by Gilles Sadowski
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. 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.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Gilles Sadowski
In reply to this post by Bernd Eckenfels
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"
> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Gilles Sadowski
In reply to this post by Jörg Schaible
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.

Obviously!

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".

Regards,
Gilles

>
> Cheers,
> Jörg
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Gilles Sadowski
On Fri, 30 Dec 2016 23:05:25 +0100, Gilles wrote:

> 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.
>
> Obviously!
>
> 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".

I've just read
 
https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

IIUC (now), we can provide all the bridges in a non-modular
component...
If you prefer it to a modular setup, that's fine for me too.

Gilles

>
> Regards,
> Gilles
>
>>
>> Cheers,
>> Jörg
>>
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Bernd Eckenfels
In reply to this post by Gilles Sadowski
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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Jörg Schaible
In reply to this post by Gilles Sadowski
Gilles wrote:

> On Fri, 30 Dec 2016 23:05:25 +0100, Gilles wrote:
>> 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.
>>
>> Obviously!
>>
>> 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".
>
> I've just read
>  
> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
>
> IIUC (now), we can provide all the bridges in a non-modular
> component...

That's what I would have done here.

> If you prefer it to a modular setup, that's fine for me too.


Seems overkill to me.

But it's just my opinion.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Gilles Sadowski
In reply to this post by Bernd Eckenfels
On Sat, 31 Dec 2016 00:00:16 +0000 (UTC), Bernd Eckenfels wrote:
> The issues of the j.u.Random implementation are only for the default
> implementation,

Not true, unfortunately (more than one example in the document).

> if you provide a different algorithm (from
> Securearandom or any distribution from RNG) you can avoid it (if
> needed)

As you know, "java.util.Random" is not an interface. This fact alone
should make people suspicious of using it as such.
Moreover since Java 1.0, there has been some adjustments in what
is considered good programming practice.

I'd be interested to see another library based on a similar design
as JDK's "Random": this leads back to a question which I asked in
this forum more than one year ago...


Regards,
Gilles

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
>
>
> On Fri, Dec 30, 2016 at 10:50 PM +0100, "Gilles"
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Rob Tompkins
Based on all the discussion and that RNG isn’t currently included in the pom, this feels like a great 1.1 forward topic because . I’m going to mark the Jira as 1.X as opposed to 1.0.

Regarding getting this in, like I said before I’m indifferent. I think though that this fits into the RERO area. Also, if we feel that releasing with “RandomStringGenerator” in place restricts this conversation too much. I’m ok with removing it and going out in a later release with it in once we are settled on what it’s API should be.

Does anyone have any comments on TEXT-42, or should I just mark that as due for a later release?

Cheers,
-Rob


> On Dec 30, 2016, at 9:06 PM, Gilles <[hidden email]> wrote:
>
> On Sat, 31 Dec 2016 00:00:16 +0000 (UTC), Bernd Eckenfels wrote:
>> The issues of the j.u.Random implementation are only for the default
>> implementation,
>
> Not true, unfortunately (more than one example in the document).
>
>> if you provide a different algorithm (from
>> Securearandom or any distribution from RNG) you can avoid it (if
>> needed)
>
> As you know, "java.util.Random" is not an interface. This fact alone
> should make people suspicious of using it as such.
> Moreover since Java 1.0, there has been some adjustments in what
> is considered good programming practice.
>
> I'd be interested to see another library based on a similar design
> as JDK's "Random": this leads back to a question which I asked in
> this forum more than one year ago...
>
>
> Regards,
> Gilles
>
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>>
>>
>>
>>
>> On Fri, Dec 30, 2016 at 10:50 PM +0100, "Gilles"
>> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Gilles Sadowski
On Sat, 31 Dec 2016 12:01:34 -0500, Rob Tompkins wrote:
> Based on all the discussion and that RNG isn’t currently included in
> the pom, this feels like a great 1.1 forward topic because .

[...] because ... ?

> I’m going
> to mark the Jira as 1.X as opposed to 1.0.

Wrt the issue of providing different sources of randomness, I
had reached the conclusion that Jörg's proposal was the common
(or, perhaps, majority) ground.
[Hence, that the custom interface and bridges would be implemented.]

> Regarding getting this in, like I said before I’m indifferent.

If I may insist ;-), we should be wary to provide a functionality
whose applications are unknown, and could thus be crippled in a
way extremely difficult to pinpoint, due to the fact which Bernd
emphasized a couple of posts ago:

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

IOW, by their nature, applications that use RNGs could look like
they work properly even when they don't.

I don't know whether applications of [TEXT] could be subject to
a bug caused by some RNG weakness, but since no technical (i.e.
Java-centric) argument seems convincing for this audience, I'll
suggest that you listen to the voice of experts, by reading just
the first two paragraphs of the last section of this document
(titled "Recommendations"):
   http://www.colostate.edu/~pburns/monte/rngreport.pdf

> I
> think though that this fits into the RERO area. Also, if we feel that
> releasing with “RandomStringGenerator” in place restricts this
> conversation too much. I’m ok with removing it and going out in a
> later release with it in once we are settled on what it’s API should
> be.

That seems a reasonable thing to do.
The more so that I'm suspicious of the Javadoc saying that
"RandomStringBuilder [...] instances are immutable and
thread-safe".
But that's another issue.


Regards (and Happy New Year),
Gilles

>
> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

sebb-2-2
The job of TEXT is to use the provided random source to generate the
text output.
TEXT should make it easy to use any implementation that provides the
range of input values it needs.
The choice of random source is up to the user; they are the only ones
who know what sort of randomness is needed.

The traditional way to provide the source would be to use an
interface, but this is unfortunately lacking.

There seem to be two ways round this:
- use j.u.Random instead
- define a new interface and provide bridge code

Both have disadvantages.

I'm wondering if a reflection-based approach would be better?
e.g. the user has to provide an instance of the class containing the
method(s) needed by TEXT.

This is effectively an implicit interface defined by the code.
So it can be applied to any existing implementation that already
provides the method(s).

Obviously this also has some disadvantages, but could eliminate the
need for bridge code.
The method name(s) could be user-defined to cover the case where
different random impls used different names for the same
functionality.


On 31 December 2016 at 18:38, Gilles <[hidden email]> wrote:

> On Sat, 31 Dec 2016 12:01:34 -0500, Rob Tompkins wrote:
>>
>> Based on all the discussion and that RNG isn’t currently included in
>> the pom, this feels like a great 1.1 forward topic because .
>
>
> [...] because ... ?
>
>> I’m going
>> to mark the Jira as 1.X as opposed to 1.0.
>
>
> Wrt the issue of providing different sources of randomness, I
> had reached the conclusion that Jörg's proposal was the common
> (or, perhaps, majority) ground.
> [Hence, that the custom interface and bridges would be implemented.]
>
>> Regarding getting this in, like I said before I’m indifferent.
>
>
> If I may insist ;-), we should be wary to provide a functionality
> whose applications are unknown, and could thus be crippled in a
> way extremely difficult to pinpoint, due to the fact which Bernd
> emphasized a couple of posts ago:
>
>>>>> In a lot of situations people will be happy with j.u.R
>
>
> IOW, by their nature, applications that use RNGs could look like
> they work properly even when they don't.
>
> I don't know whether applications of [TEXT] could be subject to
> a bug caused by some RNG weakness, but since no technical (i.e.
> Java-centric) argument seems convincing for this audience, I'll
> suggest that you listen to the voice of experts, by reading just
> the first two paragraphs of the last section of this document
> (titled "Recommendations"):
>   http://www.colostate.edu/~pburns/monte/rngreport.pdf
>
>> I
>> think though that this fits into the RERO area. Also, if we feel that
>> releasing with “RandomStringGenerator” in place restricts this
>> conversation too much. I’m ok with removing it and going out in a
>> later release with it in once we are settled on what it’s API should
>> be.
>
>
> That seems a reasonable thing to do.
> The more so that I'm suspicious of the Javadoc saying that
> "RandomStringBuilder [...] instances are immutable and
> thread-safe".
> But that's another issue.
>
>
> Regards (and Happy New Year),
> Gilles
>
>>
>> [...]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-36 (Was: [text] 1.0 release progress)

Rob Tompkins
Regarding Gilles’ last comment asking on why I think we should hold off on putting this functionality in. It seems that we have a lively bit of discourse here over the different varieties of offering the consumer the best options as to how to provide a uniform randomness generator to TEXT. Thus I’m going to plan on doing a 1.1 release shortly following 1.0 that is dedicated to this work. Does anyone have any objections to that?

Cheers,
-Rob

> On Jan 2, 2017, at 8:31 AM, sebb <[hidden email]> wrote:
>
> The job of TEXT is to use the provided random source to generate the
> text output.
> TEXT should make it easy to use any implementation that provides the
> range of input values it needs.
> The choice of random source is up to the user; they are the only ones
> who know what sort of randomness is needed.
>
> The traditional way to provide the source would be to use an
> interface, but this is unfortunately lacking.
>
> There seem to be two ways round this:
> - use j.u.Random instead
> - define a new interface and provide bridge code
>
> Both have disadvantages.
>
> I'm wondering if a reflection-based approach would be better?
> e.g. the user has to provide an instance of the class containing the
> method(s) needed by TEXT.
>
> This is effectively an implicit interface defined by the code.
> So it can be applied to any existing implementation that already
> provides the method(s).
>
> Obviously this also has some disadvantages, but could eliminate the
> need for bridge code.
> The method name(s) could be user-defined to cover the case where
> different random impls used different names for the same
> functionality.
>
>
> On 31 December 2016 at 18:38, Gilles <[hidden email]> wrote:
>> On Sat, 31 Dec 2016 12:01:34 -0500, Rob Tompkins wrote:
>>>
>>> Based on all the discussion and that RNG isn’t currently included in
>>> the pom, this feels like a great 1.1 forward topic because .
>>
>>
>> [...] because ... ?
>>
>>> I’m going
>>> to mark the Jira as 1.X as opposed to 1.0.
>>
>>
>> Wrt the issue of providing different sources of randomness, I
>> had reached the conclusion that Jörg's proposal was the common
>> (or, perhaps, majority) ground.
>> [Hence, that the custom interface and bridges would be implemented.]
>>
>>> Regarding getting this in, like I said before I’m indifferent.
>>
>>
>> If I may insist ;-), we should be wary to provide a functionality
>> whose applications are unknown, and could thus be crippled in a
>> way extremely difficult to pinpoint, due to the fact which Bernd
>> emphasized a couple of posts ago:
>>
>>>>>> In a lot of situations people will be happy with j.u.R
>>
>>
>> IOW, by their nature, applications that use RNGs could look like
>> they work properly even when they don't.
>>
>> I don't know whether applications of [TEXT] could be subject to
>> a bug caused by some RNG weakness, but since no technical (i.e.
>> Java-centric) argument seems convincing for this audience, I'll
>> suggest that you listen to the voice of experts, by reading just
>> the first two paragraphs of the last section of this document
>> (titled "Recommendations"):
>>  http://www.colostate.edu/~pburns/monte/rngreport.pdf
>>
>>> I
>>> think though that this fits into the RERO area. Also, if we feel that
>>> releasing with “RandomStringGenerator” in place restricts this
>>> conversation too much. I’m ok with removing it and going out in a
>>> later release with it in once we are settled on what it’s API should
>>> be.
>>
>>
>> That seems a reasonable thing to do.
>> The more so that I'm suspicious of the Javadoc saying that
>> "RandomStringBuilder [...] instances are immutable and
>> thread-safe".
>> But that's another issue.
>>
>>
>> Regards (and Happy New Year),
>> Gilles
>>
>>>
>>> [...]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12