[RNG] Scope of "Commons RNG"

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Gilles Sadowski
On Thu, 29 Sep 2016 14:41:11 +0300, Artem Barger wrote:

> On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes
> <[hidden email]>
> wrote:
>
>> A good question is - if rng-core changes - would the other modules
>> need to change as well? If not, then there's not a big reason why
>> they
>> need to be together in the same project (but we would end up with
>> Commons Commons Components..)
>>
>
> ​I think other modules will be somehow dependent on rng-core, so
> change
> in core will require additional release of the module.​

Wrong!

See previous post(s).

Gilles

>
> Best regards,
>                       Artem Barger.


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
Le 29/09/2016 à 12:23, Gilles a écrit :

>> And multiple projects would hypothetically ease one migration every five
>> years?
>
> This would happen for _every_ release.

How do you come to this conclusion? We are talking about an incompatible
update, the kind of update that forces to change the name of the base
package and the Maven GAV. This doesn't happen for every release.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
Le 29/09/2016 à 13:59, Gilles a écrit :

> What you are arguing here is that if "some-lib" is
> upgraded, then the JDK must change version too!
>
> Does that (extreme) comparison make the issue clearer?

No, because it isn't comparable to our situation. rng-core and rng-utils
are developed by the same team and target the same field (random number
generation and its direct applications). The JDK and "some-lib" are
completely unrelated.


> I agree that the mixing of versions, even if allowed,
> is not the best choice; that's why I've argued from the
> outset that such loosely coupled modules must in fact
> be different components!
>
> The result will be that, indeed, users must choose from
> compatible versions.  Anything new under the Sun?

As mentioned by Stian this is how work httpcore and httpclient, and this
can be confusing and error prone. If the modules are all aligned on the
same version the users have only one version to update (typically with a
Maven/Gradle property) and there is no risk of version mismatch.


> Can we please go away from the monolithic culture (and
> look at what other libraries do, and at what IIUC the
> JDK is going to do in the next major release)?

By definition a modular structure isn't monolithic, that's exactly what
other libraries do. And it isn't incompatible with the Java 9 modules.


> It seems like the number of components were a limited
> resource.  This kind of conversation is truly wasting
> valuable time that could have been better spent in setting
> up "rng-utils".
>
> It seems like folks here are happy to make things more
> complex than they intrinsically are.

Let's talk about complexity. Separate projects mean:
- Extra work for the infra team to setup the project
- Users must carefully pick the compatible versions for the projects
- JIRA reports are likely to be mixed (RNG issues reported in RNGUTILS
and vice versa)
- Extra release management work
- Extra project maintenance (parent and dependencies updates, etc)
- Extra filter rules to setup for the people subscribed to the ML
- No immediate Jenkins feedback if a rng-core change breaks rng-utils

That doesn't look easier than one multi-module project to me.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
Le 29/09/2016 à 14:01, Gilles a écrit :

>> ​I think other modules will be somehow dependent on rng-core, so change
>> in core will require additional release of the module.​
>
> Wrong!
>
> See previous post(s).

Actually Artem is right. Changes in rng-core are likely to be used in
rng-utils. For example the typed factory that you wanted to move to
rng-utils would have to be updated every time a new random number
generator is added to rng-core. New methods added to RandomSource or
UniformRandomProvider could also be useful to rng-utils classes.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] java.util.Random vs independent interface

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
Le 28/09/2016 à 14:59, Gilles a écrit :

> This will lead to unexpected behaviour.
> For example, calling "setSeed" on the returned "Random" instance,
> will have no effect.
>
> This will generate bug reports that can't be fixed without
> resorting to very ugly workaround that have nothing to do with
> the RNG functionality.

I agree the setSeed method is embarrassing when java.util.Random is
considered as an interface, but we can simply choose to ignore it and
throw an UnsupportedOperationException. I don't think reseeding a
generator is a common use case anyway.

If we compare the public API of java.util.Random and
UniformRandomProvider they mostly share the same methods, minus setSeed
(and nextGaussian but that's another story). The only reason justifying
the existence of UniformRandomProvider is the removal of setSeed. I
don't think removing this method is important enough to sacrifice the
compatibility with java.util.Random.

I agree that in an ideal world the JDK should provide a well defined
random interface that could be extended to fulfill any need. Or we could
adopt a NIH attitude, vow to design purity, and define our own. But
that's not a pragmatic choice. java.util.Random is already used in the
wild, and the smart move is to leverage its ubiquity.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
Le 28/09/2016 à 15:28, Gilles a écrit :

> Conversely, using "SecureRandom" in place of a deterministic
> RNG is only useful in toy applications since the main feature
> (of non-secure RNGs) one usually needs is reproducibility.

I guess the Tomcat developers will love hearing they are building a toy
application :)

https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170


> [1] Even the Java architects have indirectly acknowledged that,
>     by having a new random-related class _NOT_ extend "Random"
>     (allowing them to drop all the cruft brought by it).

Are you referring to java.security.SecureRandomSpi not extending
java.util.Random? This is merely a mechanism allowing to plug extra
implementations, the whole security package is designed around this
concept. But users only deal with SecureRandom, which extends Random.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Fri, 30 Sep 2016 09:49:52 +0200, Emmanuel Bourg wrote:

> Le 29/09/2016 à 14:01, Gilles a écrit :
>
>>> ​I think other modules will be somehow dependent on rng-core, so
>>> change
>>> in core will require additional release of the module.​
>>
>> Wrong!
>>
>> See previous post(s).
>
> Actually Artem is right. Changes in rng-core are likely to be used in
> rng-utils. For example the typed factory that you wanted to move to
> rng-utils would have to be updated every time a new random number
> generator is added to rng-core. New methods added to RandomSource or
> UniformRandomProvider could also be useful to rng-utils classes.

Here and in the other post, you are totally oblivious to my POV.

The potential target audience of the component which I proposed
does not need what I called "rng-utils".
[In particular, they don't need the factory you want to use place
of the one I've coded.]
The target audience is those applications that would need a RNG
implemented in Java. Period.

In that use-case, the complexity is what you create by forcing
the "rng-core" version (of a limited-scope library, which is a
good thing) to step in sync with the changes in "rng-utils" (a
non-limited library, which is not a bad thing per se, but
definitely _more_ complex to manage).

Gilles

>
> Emmanuel Bourg
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:

> Le 29/09/2016 à 13:59, Gilles a écrit :
>
>> What you are arguing here is that if "some-lib" is
>> upgraded, then the JDK must change version too!
>>
>> Does that (extreme) comparison make the issue clearer?
>
> No, because it isn't comparable to our situation. rng-core and
> rng-utils
> are developed by the same team and target the same field (random
> number
> generation and its direct applications). The JDK and "some-lib" are
> completely unrelated.

"some-lib" uses the JDK

just as

"rng-utils" uses "rng-core"

The comparison is adequate, if you consider the examples I've given
(avoiding upgrades when no code change happened).

>> I agree that the mixing of versions, even if allowed,
>> is not the best choice; that's why I've argued from the
>> outset that such loosely coupled modules must in fact
>> be different components!
>>
>> The result will be that, indeed, users must choose from
>> compatible versions.  Anything new under the Sun?
>
> As mentioned by Stian this is how work httpcore and httpclient, and
> this
> can be confusing and error prone. If the modules are all aligned on
> the
> same version the users have only one version to update (typically
> with a
> Maven/Gradle property) and there is no risk of version mismatch.

I don't deny that tools such as maven or ivy can download a new
version automatically.
Nevertheless, I envision that "rng-core" will change at much slower
pace that "rng-utils", many such upgrades will download the exact
same code.

Also, contrarily to what Artem suggested, I also envision that
most of "rng-core" will change in a compatible way (e.g. add
new RNG implementations), so that "rng-utils" does not need to
be released in sync.

Yes, for some time, users of the syntactic sugar factory won't
be able to use it in order to instantiate the new RNG. So what?
[How is that different from a library sticking to Java 6, and
thus cannot use the features of Java 8?]

>> Can we please go away from the monolithic culture (and
>> look at what other libraries do, and at what IIUC the
>> JDK is going to do in the next major release)?
>
> By definition a modular structure isn't monolithic, that's exactly
> what
> other libraries do. And it isn't incompatible with the Java 9
> modules.

I'm all for modular structure, but against unnecessary dependence
of release cycles.
They are two different things.

In the examples you gave, I could certainly trust you that a
release cycle dependency exist.
I don't see that in my vision of "rng-core" and "rng-utils".

>> It seems like the number of components were a limited
>> resource.  This kind of conversation is truly wasting
>> valuable time that could have been better spent in setting
>> up "rng-utils".
>>
>> It seems like folks here are happy to make things more
>> complex than they intrinsically are.
>
> Let's talk about complexity. Separate projects mean:
> - Extra work for the infra team to setup the project

Thanks to all people giving time!

INFRA people will create this repository when it suits them.

Then I (and you) will save huge amounts of time because we
won't have to fight over what goes where, thanks to well-scoped
components and separation of concern.

> - Users must carefully pick the compatible versions for the projects

Same as any application does already.

> - JIRA reports are likely to be mixed (RNG issues reported in
> RNGUTILS
> and vice versa)

Perhaps.
I'll move them. OK? ;-)

> - Extra release management work

I'll do it. OK?

> - Extra project maintenance (parent and dependencies updates, etc)

I'll do it. OK?

> - Extra filter rules to setup for the people subscribed to the ML

Go complain to the PMC.
[I'm all for separate MLs, as people have been recurrently
proposing.]

> - No immediate Jenkins feedback if a rng-core change breaks rng-utils

I'm not sure I got that one.
If it means to copy the new "rng-core" over to some place for use
by the build of "rng-utils", can't this be done by a "post-build"
script?

> That doesn't look easier than one multi-module project to me.

You are mixing tools issues (which we can address as I just did
above) with principle: Whether "rng-core" and "rng-utils" are
sufficiently interdependent to make them part of a single
codebase.  If not (my POV), then managing them together is
more complex (because there is factually more ways to break
something).

If that is not obvious to you, but are willing to trust other
members here (me in this case), you could agree to make the
experiment! :-)
Then when we see more code, more users, more contributors,
more opinions, and we see that there is merit in merging the
two components, we'll just do it.
[And I'll apologize to the INFRA people for the time they wasted
in setting up the project.]

Deal?


Gilles

> Emmanuel Bourg
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Brent Worden-2
On Fri, Sep 30, 2016 at 10:02 AM, Gilles <[hidden email]>
wrote:

> On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
>
>>
>>  - No immediate Jenkins feedback if a rng-core change breaks rng-utils

>
> I'm not sure I got that one.
> If it means to copy the new "rng-core" over to some place for use
> by the build of "rng-utils", can't this be done by a "post-build"
> script?


The lack of immediate feedback is the same risk we have with other commons
components being dependencies of other projects, Apache or otherwise.  I
think with the level that commons projects are policed through unit tests,
code reviews, backwards compatibility checks, and release candidate reviews
this risk is mitigated to a very acceptable level.

In the past when the commons project changes did cause unintended upstream
problems, I feel we have done a good job reacting in a timely fashion to
address these issues and make process improvements if warranted.  I do see
how we'd be any different, or need to be any different, with these two
components.

If this is something we want more risk mitigation, we could set up both
components in Gump.



> If that is not obvious to you, but are willing to trust other
> members here (me in this case), you could agree to make the
> experiment! :-)
> Then when we see more code, more users, more contributors,
> more opinions, and we see that there is merit in merging the
> two components, we'll just do it.
> [And I'll apologize to the INFRA people for the time they wasted
> in setting up the project.]
>
>
> Gilles
>
>
I was just thinking the same thing.  Let's try one way and see it works to
satisfaction.  If it does, great.  If it proves to be burdensome or the
benefits are not realized, we can try another approach.

Another thing I was thinking if we wanted to test drive the multi-project
route, what about setting up rng-utils in the sandbox?  Process-wise it
would be a lot like a proper project thus, giving us the opportunity to see
how it would actually function.  One benefit of using the sandbox is that
the work can begin immediately as it does not require infrastructure
changes.

Brent
Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

garydgregory
Hi All,

[Note my careful use of the terms "project", "component", and "module"]

Pardon my jumping in late... If some of this is leading to more than one
commons-rng component within Apache Commons, I would be against that; Maven
modules are a perfect match for this concept.

Please allow me to relate my experience with Apache Log4j 2 where we have
one project with 26 modules (granted there are 8 non-production modules:
samples and benchmarks). For most releases, there are interesting and
significant changes in only one module (log4j-core). A Log4j 2 release
means a release of all modules and a guarantee that all modules work
together (of course).

Another example is Apache HttpComponets where there are several components
and some components have several modules. This is not a trivial environment
to set up as a project developer (unless I made a mess of my own personal
set up, not unlikely! ;-)

So far, Commons-RNG is a small and focused component related in theme to
Commons-Math but these are not dependent on each other, so we have to keep
that explanation clear.

I would think that it would be better to have modules potentially come,
morph, go, within one component.

3c,
Gary


On Fri, Sep 30, 2016 at 8:45 AM, Brent Worden <[hidden email]>
wrote:

> On Fri, Sep 30, 2016 at 10:02 AM, Gilles <[hidden email]>
> wrote:
>
> > On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
> >
> >>
> >>  - No immediate Jenkins feedback if a rng-core change breaks rng-utils
>
> >
> > I'm not sure I got that one.
> > If it means to copy the new "rng-core" over to some place for use
> > by the build of "rng-utils", can't this be done by a "post-build"
> > script?
>
>
> The lack of immediate feedback is the same risk we have with other commons
> components being dependencies of other projects, Apache or otherwise.  I
> think with the level that commons projects are policed through unit tests,
> code reviews, backwards compatibility checks, and release candidate reviews
> this risk is mitigated to a very acceptable level.
>
> In the past when the commons project changes did cause unintended upstream
> problems, I feel we have done a good job reacting in a timely fashion to
> address these issues and make process improvements if warranted.  I do see
> how we'd be any different, or need to be any different, with these two
> components.
>
> If this is something we want more risk mitigation, we could set up both
> components in Gump.
>
>
>
> > If that is not obvious to you, but are willing to trust other
> > members here (me in this case), you could agree to make the
> > experiment! :-)
> > Then when we see more code, more users, more contributors,
> > more opinions, and we see that there is merit in merging the
> > two components, we'll just do it.
> > [And I'll apologize to the INFRA people for the time they wasted
> > in setting up the project.]
> >
> >
> > Gilles
> >
> >
> I was just thinking the same thing.  Let's try one way and see it works to
> satisfaction.  If it does, great.  If it proves to be burdensome or the
> benefits are not realized, we can try another approach.
>
> Another thing I was thinking if we wanted to test drive the multi-project
> route, what about setting up rng-utils in the sandbox?  Process-wise it
> would be a lot like a proper project thus, giving us the opportunity to see
> how it would actually function.  One benefit of using the sandbox is that
> the work can begin immediately as it does not require infrastructure
> changes.
>
> Brent
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Matt Sicker
In reply to this post by Emmanuel Bourg-3
I thought he meant that if your code works with either Random or
SecureRandom, you're doing it wrong. They both have very different use
cases, and the fact that SecureRandom extends Random contributes to the
confusion.

On 30 September 2016 at 08:02, Emmanuel Bourg <[hidden email]> wrote:

> Le 28/09/2016 à 15:28, Gilles a écrit :
>
> > Conversely, using "SecureRandom" in place of a deterministic
> > RNG is only useful in toy applications since the main feature
> > (of non-secure RNGs) one usually needs is reproducibility.
>
> I guess the Tomcat developers will love hearing they are building a toy
> application :)
>
> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/
> java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>
>
> > [1] Even the Java architects have indirectly acknowledged that,
> >     by having a new random-related class _NOT_ extend "Random"
> >     (allowing them to drop all the cruft brought by it).
>
> Are you referring to java.security.SecureRandomSpi not extending
> java.util.Random? This is merely a mechanism allowing to plug extra
> implementations, the whole security package is designed around this
> concept. But users only deal with SecureRandom, which extends Random.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Fri, 30 Sep 2016 15:02:40 +0200, Emmanuel Bourg wrote:
> Le 28/09/2016 à 15:28, Gilles a écrit :
>
>> Conversely, using "SecureRandom" in place of a deterministic
>> RNG is only useful in toy applications since the main feature
>> (of non-secure RNGs) one usually needs is reproducibility.
>
> I guess the Tomcat developers will love hearing they are building a
> toy
> application :)

A complete misinterpretation of my sentence.

If an application requires a cryptographically secure generator,
then using (i.e. allowing a user to choose) a deterministic one
might incur a vulnerability.

If an application must generate reproducible results, then
allowing a cryptographically secure generator is a useless
feature.

>
>
> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>
>
>> [1] Even the Java architects have indirectly acknowledged that,
>>     by having a new random-related class _NOT_ extend "Random"
>>     (allowing them to drop all the cruft brought by it).
>
> Are you referring to java.security.SecureRandomSpi not extending
> java.util.Random?

No, "SplittableRandom".

Gilles

> This is merely a mechanism allowing to plug extra
> implementations, the whole security package is designed around this
> concept. But users only deal with SecureRandom, which extends Random.
>
> Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Gilles Sadowski
In reply to this post by Matt Sicker
On Fri, 30 Sep 2016 11:34:10 -0500, Matt Sicker wrote:
> I thought he meant that if your code works with either Random or
> SecureRandom, you're doing it wrong. They both have very different
> use
> cases, and the fact that SecureRandom extends Random contributes to
> the
> confusion.

Indeed.
[I should have read the thread up to the top before duplicating your
answer.]


Regards,
Gilles

> On 30 September 2016 at 08:02, Emmanuel Bourg <[hidden email]>
> wrote:
>
>> Le 28/09/2016 à 15:28, Gilles a écrit :
>>
>> > Conversely, using "SecureRandom" in place of a deterministic
>> > RNG is only useful in toy applications since the main feature
>> > (of non-secure RNGs) one usually needs is reproducibility.
>>
>> I guess the Tomcat developers will love hearing they are building a
>> toy
>> application :)
>>
>> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/
>> java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>>
>>
>> > [1] Even the Java architects have indirectly acknowledged that,
>> >     by having a new random-related class _NOT_ extend "Random"
>> >     (allowing them to drop all the cruft brought by it).
>>
>> Are you referring to java.security.SecureRandomSpi not extending
>> java.util.Random? This is merely a mechanism allowing to plug extra
>> implementations, the whole security package is designed around this
>> concept. But users only deal with SecureRandom, which extends
>> Random.
>>
>> Emmanuel Bourg
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Gilles Sadowski
In reply to this post by Brent Worden-2
On Fri, 30 Sep 2016 10:45:47 -0500, Brent Worden wrote:

> On Fri, Sep 30, 2016 at 10:02 AM, Gilles
> <[hidden email]>
> wrote:
>
>> On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
>>
>>>
>>>  - No immediate Jenkins feedback if a rng-core change breaks
>>> rng-utils
>
>>
>> I'm not sure I got that one.
>> If it means to copy the new "rng-core" over to some place for use
>> by the build of "rng-utils", can't this be done by a "post-build"
>> script?
>
>
> The lack of immediate feedback is the same risk we have with other
> commons
> components being dependencies of other projects, Apache or otherwise.
> I
> think with the level that commons projects are policed through unit
> tests,
> code reviews, backwards compatibility checks, and release candidate
> reviews
> this risk is mitigated to a very acceptable level.
>
> In the past when the commons project changes did cause unintended
> upstream
> problems, I feel we have done a good job reacting in a timely fashion
> to
> address these issues and make process improvements if warranted.  I
> do see
> how we'd be any different, or need to be any different, with these
> two
> components.
>
> If this is something we want more risk mitigation, we could set up
> both
> components in Gump.
>
>
>
>> If that is not obvious to you, but are willing to trust other
>> members here (me in this case), you could agree to make the
>> experiment! :-)
>> Then when we see more code, more users, more contributors,
>> more opinions, and we see that there is merit in merging the
>> two components, we'll just do it.
>> [And I'll apologize to the INFRA people for the time they wasted
>> in setting up the project.]
>>
>>
>> Gilles
>>
>>
> I was just thinking the same thing.  Let's try one way and see it
> works to
> satisfaction.  If it does, great.  If it proves to be burdensome or
> the
> benefits are not realized, we can try another approach.
>
> Another thing I was thinking if we wanted to test drive the
> multi-project
> route, what about setting up rng-utils in the sandbox?  Process-wise
> it
> would be a lot like a proper project thus, giving us the opportunity
> to see
> how it would actually function.  One benefit of using the sandbox is
> that
> the work can begin immediately as it does not require infrastructure
> changes.

Good.
Let's start solving problems, real or perceived.

Gilles

> Brent


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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Gilles Sadowski
In reply to this post by Stian Soiland-Reyes
Hi.

On Thu, 29 Sep 2016 11:48:29 +0100, Stian Soiland-Reyes wrote:
> Having all modules in the project have the same <version> is just a
> convention.

That's not what I've been told.
Anyways, I agree that interdependent modules _of the same project_
should preferably share the same version number.

> It could make sense to increment the rng-core module more slowly,
> while still allowing it in the build.
>
> For instance:
>
> commons-rng 1.2.0 could include:
>   rng-core 1.1.2 (nothing actually changed, but we can't re-deploy
> 1.1.1)
>   rng-utils 1.2.0 (new method)
>
> This is a very OSGi-way of doing it - but it will confuse lots of
> users as you know have three different version numbers and couldn't
> do
> ${rng.version}.  For example - see how httpclient and httpcore have
> split apart version-wise - this can be confusing for many as you
> generally have to upgrade them together as close friends.

Confusing it is.
That's why my preferred option, by far, is to consider that
"rng-core" and "rng-utils" are independent projects, and that
"rng-utils" depends on "rng-core", in the same way that it
will depend on the JDK.

This would also reflect the separation of concern and the
quite possibly different developers teams.
This is a fairly sensitive issue: experience has shown that in
Commons Math, several parts of the library had, de facto, become
the personal turf of a single developer.

I believe that "component" implies an idea of strong integration
(down to the implementation level).

"Commons RNG" should not attempt to become "a framework that
produces random numbers", foremost because that is too vague a
definition for a "component".
Another reason is that it is too ambitious for non-experts (as all
the readers here are, AFAICT).
And yet another is that it exists already:
   https://www.random.org/

"rng-utils" could very well depend on other libraries, if the
intention is really to provide extended support to non-Java and
non-Commons-RNG implementations.

What is called "rng-core" here would just happen to provide
pure-Java implementations (and the minimal set of utilities that
is now implemented), and the "UniformRandomProvider" interface.

>
>
> Another alternative would be a more careful hand-holding where
> rng-core stays versioned at 1.1.1 in the pom.xml until it changes,
> but
> then this is very hard to verify as you must make sure it is truly
> exactly the same as "the other 1.1.1". (And you would have to
> manually
> prune the "newer 1.1.1" from Nexus staging repository - if it even
> would allow you to upload a duplicate version).

This is fragile indeed.

>
>
> I would not recommend the option of 'partial module releases' - I've
> seen some Apache projects try to do this, but it leads to a very
> complicated picture for downstream as you then potentially have to
> build many different such "patch releases" to get all the modules. It
> also complicates our download/source pages a lot.

Agreed.

Two separate components would not suffer from that problem.
The release notes of "rng-utils" will mention the minimum
version of "rng-core" compatible with it, as it does for
the minimum version of the JDK.

It is of course possible that a release of "rng-core" could
trigger the release of "rng-utils", but only if the latter
would be broken by the former.

Breaking can only happen if
  * methods are removed to the "UniformRandomProvider" interface,
  * methods are added to the "UniformRandomProvider" interface,
  * the name "UniformRandomProvider" is changed,
  * the name "RandomSource" is changed,
  * methods of "RandomSource" are removed,
  * the external representation of the "RandomSource.State" is
    modified.

I do not foresee any circumstance where any of those would
happen.

However, extend the scope of "Commons RNG" (e.g. to implementations
that would require adding methods in "UniformRandomProvider"), and
all bets are off...

> The simplest is to always increase the modules together - as we won't
> generally bump major.  It does mean perceived incompatibility if appA
> uses rng-core 1.1.0 and friends; while a newer version of its
> dependencyB now uses rng-core 1.2.0 - and it could look like an
> upgrade is required even if rng-core 1.2.0 is line by line the same
> as
> rng-core 1.1.0

This is what I find unnecessary disturbing for user of
"rng-core" (i.e. all those applications who need a PRNG
in order use it in a specific way not covered by "rng-utils",
or those applications who want to minimize their dependencies
for whatever reasons).

For separate components, this disturbance does not happen.
Hence I find it a better solution.

>
> A good question is - if rng-core changes - would the other modules
> need to change as well?

Absolutely not (bugs notwithstanding).
It's exactly like when there is a new Java version, not all
libraries _need_ to use it (obviously none need to).

"rng-utils" can choose when it wants to release a version
that will use all the features of "rng-core".
This could happen if there is some ongoing work in "rng-utils"
that would better be completed before releasing the next version.

It is certainly acceptable that, for some period of time, a
new RNG implementation in "rng-core" will not be supported
by some of the (syntactic sugar) methods of "rng-utils".

Then again, it is not expected that "rng-core" will change
often, once most PRNGs have been implemented.

> If not, then there's not a big reason why they
> need to be together in the same project

My point indeed. ;-)

> (but we would end up with
> Commons Commons Components..)

There you lost me.

> BTW - we'll face a similar issue in Commons RDF where we shouldn't
> have to increase the version of the commons-rdf-api module when
> nothing has changed

This is indeed what I want to avoid if possible.

> - but would be forced to do so if we add a public
> method in one of the other modules (e.g. in the Jena integration) and
> release them all together.

Do I understand correctly that any "vendor" will force a re-release of
the common interface, whenever they touch their own code, and force a
"no-op" release of all the other vendors' library to keep the versions
the same?

Are there functionalities which a vendor might provide that does not
exist in "commons-rdf-api" and be used by applications?
If not, I'm not sure that the situation is comparable.

Gilles

>
>
> On 29 September 2016 at 11:23, Gilles <[hidden email]>
> wrote:
>> On Thu, 29 Sep 2016 12:06:36 +0200, Emmanuel Bourg wrote:
>>>
>>> Le 28/09/2016 à 15:58, Gilles a écrit :
>>>
>>>>> Multi-module projects are quite common and the case you mention
>>>>> isn't
>>>>> unusual.
>>>>
>>>>
>>>> Please show an example.
>>>
>>>
>>> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
>>> There is no lack of examples. Multi-module projects routinely
>>> publish
>>> new releases with some of their modules unmodified.
>>
>>
>> You noted several weeks ago that a Commons component cannot
>> release modules with different version numbers.
>>
>> The problem is not multi-module; it is two codebases (core
>> and utils) having completely independent release cycles.
>>
>> Users should be able to stick with "core-1.0", as long as
>> there is no change in that module, not forced to upgrade
>> to a "core-1.1" because a new release of "utils-1.1" was
>> performed.
>>
>>>
>>>
>>>> With modules, the problem I see is (as I already evoked it):
>>>>
>>>> At time t0, publish
>>>>    * rng-core v1.1
>>>>    * rng-utils v1.1
>>>>
>>>> Some time later, a weakness or bug that cannot be fixed
>>>> in backwards-compatible way is identified in "rg-utils".
>>>> Hence publish
>>>>    * rng-core v2.0
>>>>    * rng-utils v2.0
>>>>
>>>> Due to the package change, users that do NOT use "rng-utils" have
>>>> to either modify all their code because of the package name change
>>>> (although the implementation has not changed one bit) or continue
>>>> to use a now unsupported v1.1.
>>>
>>>
>>> True, but that's a very rare case, and there are other ways to
>>> mitigate
>>> what you perceive as an issue. If we decide in a couple of years to
>>> rework rng-utils in a backward incompatible way, we can rename or
>>> split
>>> it. For example let say we realize its scope isn't well defined or
>>> it
>>> gets too big, we could extract a "rng-variate" module and rename
>>> the
>>> remaining one to "rng-tools". This would not affect the users of
>>> rng-core.
>>
>>
>> Forced upgrade for no reason would not be a rare case:
>> Add a feature in "utils" and you force users of "core" to upgrade.
>> And the converse is also true.
>>
>>>
>>>> Just to spare one vote every two years?
>>>
>>>
>>> And multiple projects would hypothetically ease one migration every
>>> five
>>> years?
>>
>>
>> This would happen for _every_ release.
>>
>> Gilles
>>
>>
>>>
>>> Emmanuel Bourg
>>>
>>>
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG")

sebb-2-2
In reply to this post by Gilles Sadowski
On 27 September 2016 at 12:22, Gilles <[hidden email]> wrote:

> Hi.
>
> On Tue, 27 Sep 2016 12:53:33 +0200, Emmanuel Bourg wrote:
>>
>> Le 27/09/2016 à 01:14, Gilles a écrit :
>>
>>>>> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
>>>>
>>>>
>>>> This should go in the ArrayUtils class of commons-lang, with a
>>>> java.util.Random parameter.
>>>
>>>
>>> I don't get that.
>>> The idea is to parameterize the utilities with a "UniformRandomProvider"
>>> instance.
>>
>>
>> My suggestion is to add two methods to ArrayUtils in commons-lang for
>> each primitive type and Object (and maybe a couple more if we want to
>> shuffle only a subset of the array):
>>
>>    ArraysUtils.shuffle(Object[] array)
>>    ArraysUtils.shuffle(Object[] array, java.util.Random rnd)
>
>
> I (strongly) suggest
>
>   ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider rnd)

Huh?

That would require LANG to depend on RNG.
I am against that.

>>
>> And if we want to shuffle with a random generator from commons-rng, we
>> simply convert the UniformRandomProvider into a java.util.Random using
>> the adapter:
>>
>>    RandomProvider rng = RandomSource.create(...);
>>    ArraysUtils.shuffle(array, new JDKRandomAdapter(rng));
>>
>> or
>>
>>    RandomProvider rng = RandomSource.create(...);
>>    ArraysUtils.shuffle(array, rng.asRandom());
>
>
> Similarly, we'd rather overload "shuffle" as follows
>
>   ArraysUtils.shuffle(Object[] array, java.util.Random rnd) {
>     shuffle(array, RandomUtils.asUniformRandomProvider(rnd));
>   }
>
> where "RandomUtils" is currently in CM (package "o.a.c.math4.random").
>
> It is not a matter of taste (cf. caveat in "o.a.c.math4.random.RngAdpator").
> The factory method "asUniformRandomProvider" creates an instance that
> redirects all the interface methods to their counterpart in "Random" (when
> they exist): sequence of any type is the same, whether the Random instance
> is wrapped or not.  "RngAdapter" however creates a "Random" instance where
> only 32-bits integers sequences are preserved.
>
> Moreover, the default RNG should be a good one, i.e. not "java.util.Random".
>
> But overall it would be much better to put all this in a new component
> and deprecate all of CL's "Random"-parameterized methods.
> It was noted (not only by me) that CL grew too big (and out of its original
> scope).  "RandomUtils" is relatively small (in Lang 3.4): now is a good
> opportunity to deprecate these few methods and those intended for 3.5
> and redirect users to a dedicated component.

+1

>
> Gilles
>
>
>> Emmanuel Bourg
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
|

[ALL] Get things moving with "random utilities" (Was: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG"))

Gilles Sadowski
Hi.

On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:

> [...]
>>
>> But overall it would be much better to put all this in a new
>> component
>> and deprecate all of CL's "Random"-parameterized methods.
>> It was noted (not only by me) that CL grew too big (and out of its
>> original
>> scope).  "RandomUtils" is relatively small (in Lang 3.4): now is a
>> good
>> opportunity to deprecate these few methods and those intended for
>> 3.5
>> and redirect users to a dedicated component.
>
> +1
>
>>
>> [...]

Within the context of a forthcoming release of "Commons RNG" and
identified shortcomings of the random-related utilities implemented
in "Commons Lang", e.g.:
   https://issues.apache.org/jira/browse/LANG-1196
   https://issues.apache.org/jira/browse/LANG-1254
I'm proposing to ask INFRA to create a new git repository, to become
the "Commons" home of random utilities, i.e. anything that _uses_ an
"external" source of randomness (as opposed to _implementations_
of (P)RNG algorithms, which is the scope of "Commons RNG").

Examples of utilities:
  * non-uniform deviates (to be extracted from "Commons Math")
  * extended tools, such as "numbers within a range" (to be
    extracted from "Commons Lang") and "quasi-random" generators
    (to be extracted from "Commons Math"),
  * string utilities (to be extracted from "Commons Math" and
    "Commons Lang"),
  * shuffling of primitive arrays and "List<T>" (to be extracted
    from "Commons Math"),
  * bridges between alternative APIs:
      - java.util.Random
      - java.util.SplittableRandom
      - UniformRandomProvider from "Commons RNG" (to be extracted
        from "Commons Math")
      - other Java libraries
  * wrappers around "external" sources of randomness, e.g. system
    devices (UNIX) and native libraries, and interface extensions
    needed to support them (streams, IO handling, etc.).

Given the variety of the above (non-exhaustive) list, it is
foreseen that the component will be "multi-modules"[1] in order
to let users depend only on what they need for their use-case.
[For example, an engineering application could need non-uniform
deviates (e.g. Gaussian-distributed sequences), but should not
be required to depend on the (orthogonal) development of string
generators or cryptographic features.]


Regards,
Gilles

[1] Help is most welcome to set this up.


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Get things moving with "random utilities" (Was: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG"))

Bruno P. Kinoshita-3
Hi Gilles,

Definitely interested in helping and learning more about random (number|string|object|etc) generators.

Are there any specific tasks that others can jump in and help with? Once the new component has been set up, I'd be happy in trying to work on code related to LANG-1196 and LANG-1254.

Cheers
Bruno

>________________________________
> From: Gilles <[hidden email]>
>To: [hidden email]
>Sent: Sunday, 16 October 2016 5:08 AM
>Subject: [ALL] Get things moving with "random utilities" (Was: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
>
>
>Hi.
>
>On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
>> [...]
>>>
>>> But overall it would be much better to put all this in a new
>>> component
>>> and deprecate all of CL's "Random"-parameterized methods.
>>> It was noted (not only by me) that CL grew too big (and out of its
>>> original
>>> scope).  "RandomUtils" is relatively small (in Lang 3.4): now is a
>>> good
>>> opportunity to deprecate these few methods and those intended for
>>> 3.5
>>> and redirect users to a dedicated component.
>>
>> +1
>>
>>>
>>> [...]
>
>Within the context of a forthcoming release of "Commons RNG" and
>identified shortcomings of the random-related utilities implemented
>in "Commons Lang", e.g.:
>  https://issues.apache.org/jira/browse/LANG-1196
>  https://issues.apache.org/jira/browse/LANG-1254
>I'm proposing to ask INFRA to create a new git repository, to become
>the "Commons" home of random utilities, i.e. anything that _uses_ an
>"external" source of randomness (as opposed to _implementations_
>of (P)RNG algorithms, which is the scope of "Commons RNG").
>
>Examples of utilities:
>  * non-uniform deviates (to be extracted from "Commons Math")
>  * extended tools, such as "numbers within a range" (to be
>    extracted from "Commons Lang") and "quasi-random" generators
>    (to be extracted from "Commons Math"),
>  * string utilities (to be extracted from "Commons Math" and
>    "Commons Lang"),
>  * shuffling of primitive arrays and "List<T>" (to be extracted
>    from "Commons Math"),
>  * bridges between alternative APIs:
>      - java.util.Random
>      - java.util.SplittableRandom
>      - UniformRandomProvider from "Commons RNG" (to be extracted
>        from "Commons Math")
>      - other Java libraries
>  * wrappers around "external" sources of randomness, e.g. system
>    devices (UNIX) and native libraries, and interface extensions
>    needed to support them (streams, IO handling, etc.).
>
>Given the variety of the above (non-exhaustive) list, it is
>foreseen that the component will be "multi-modules"[1] in order
>to let users depend only on what they need for their use-case.
>[For example, an engineering application could need non-uniform
>deviates (e.g. Gaussian-distributed sequences), but should not
>be required to depend on the (orthogonal) development of string
>generators or cryptographic features.]
>
>
>Regards,
>Gilles
>
>[1] Help is most welcome to set this up.
>
>
>
>---------------------------------------------------------------------
>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: [ALL] Get things moving with "random utilities"

Gilles Sadowski
Hello Bruno.

On Sat, 15 Oct 2016 20:57:04 +0000 (UTC), Bruno P. Kinoshita wrote:
> Hi Gilles,
>
> Definitely interested in helping and learning more about random
> (number|string|object|etc) generators.
>
> Are there any specific tasks that others can jump in and help with?

In the yet-to-be-named "Commons <random utilities>" component,
everything is up for grabs, from extracting the relevant bits
from "Math" and "Lang", to proposing an all-encompassing
framework (if people think they can achieve it...).
The scope is open-ended (or should be defined if there is a
willingness to impose some limit).

> Once the new component has been set up,

For this, we should start with settling on a name, so that INFRA
can create a repository with that name.

  * Random Utilities
  * Random Utils
  * Random Tools
  * ...

?

> I'd be happy in trying to work
> on code related to LANG-1196 and LANG-1254.

Thanks!

Regards,
Gilles


>
> Cheers
> Bruno
>>________________________________
>> From: Gilles <[hidden email]>
>>To: [hidden email]
>>Sent: Sunday, 16 October 2016 5:08 AM
>>Subject: [ALL] Get things moving with "random utilities" (Was: [lang]
>> Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
>>
>>
>>Hi.
>>
>>On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
>>> [...]
>>>>
>>>> But overall it would be much better to put all this in a new
>>>> component
>>>> and deprecate all of CL's "Random"-parameterized methods.
>>>> It was noted (not only by me) that CL grew too big (and out of its
>>>> original
>>>> scope).  "RandomUtils" is relatively small (in Lang 3.4): now is a
>>>> good
>>>> opportunity to deprecate these few methods and those intended for
>>>> 3.5
>>>> and redirect users to a dedicated component.
>>>
>>> +1
>>>
>>>>
>>>> [...]
>>
>>Within the context of a forthcoming release of "Commons RNG" and
>>identified shortcomings of the random-related utilities implemented
>>in "Commons Lang", e.g.:
>>  https://issues.apache.org/jira/browse/LANG-1196
>>  https://issues.apache.org/jira/browse/LANG-1254
>>I'm proposing to ask INFRA to create a new git repository, to become
>>the "Commons" home of random utilities, i.e. anything that _uses_ an
>>"external" source of randomness (as opposed to _implementations_
>>of (P)RNG algorithms, which is the scope of "Commons RNG").
>>
>>Examples of utilities:
>>  * non-uniform deviates (to be extracted from "Commons Math")
>>  * extended tools, such as "numbers within a range" (to be
>>    extracted from "Commons Lang") and "quasi-random" generators
>>    (to be extracted from "Commons Math"),
>>  * string utilities (to be extracted from "Commons Math" and
>>    "Commons Lang"),
>>  * shuffling of primitive arrays and "List<T>" (to be extracted
>>    from "Commons Math"),
>>  * bridges between alternative APIs:
>>      - java.util.Random
>>      - java.util.SplittableRandom
>>      - UniformRandomProvider from "Commons RNG" (to be extracted
>>        from "Commons Math")
>>      - other Java libraries
>>  * wrappers around "external" sources of randomness, e.g. system
>>    devices (UNIX) and native libraries, and interface extensions
>>    needed to support them (streams, IO handling, etc.).
>>
>>Given the variety of the above (non-exhaustive) list, it is
>>foreseen that the component will be "multi-modules"[1] in order
>>to let users depend only on what they need for their use-case.
>>[For example, an engineering application could need non-uniform
>>deviates (e.g. Gaussian-distributed sequences), but should not
>>be required to depend on the (orthogonal) development of string
>>generators or cryptographic features.]
>>
>>
>>Regards,
>>Gilles
>>
>>[1] Help is most welcome to set this up.
>>
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Get things moving with "random utilities"

garydgregory
To restate my opinion and that of others: It is not a good thing to end up
with components Commons Random A, Commons Random B, Commons Random C, and
so on. We already have a new Commons Random Something component. Related
code should be modules of that component.

Gary

On Tue, Oct 18, 2016 at 7:18 AM, Gilles <[hidden email]>
wrote:

> Hello Bruno.
>
> On Sat, 15 Oct 2016 20:57:04 +0000 (UTC), Bruno P. Kinoshita wrote:
>
>> Hi Gilles,
>>
>> Definitely interested in helping and learning more about random
>> (number|string|object|etc) generators.
>>
>> Are there any specific tasks that others can jump in and help with?
>>
>
> In the yet-to-be-named "Commons <random utilities>" component,
> everything is up for grabs, from extracting the relevant bits
> from "Math" and "Lang", to proposing an all-encompassing
> framework (if people think they can achieve it...).
> The scope is open-ended (or should be defined if there is a
> willingness to impose some limit).
>
> Once the new component has been set up,
>>
>
> For this, we should start with settling on a name, so that INFRA
> can create a repository with that name.
>
>  * Random Utilities
>  * Random Utils
>  * Random Tools
>  * ...
>
> ?
>
> I'd be happy in trying to work
>> on code related to LANG-1196 and LANG-1254.
>>
>
> Thanks!
>
> Regards,
> Gilles
>
>
>
>> Cheers
>> Bruno
>>
>>> ________________________________
>>> From: Gilles <[hidden email]>
>>> To: [hidden email]
>>> Sent: Sunday, 16 October 2016 5:08 AM
>>> Subject: [ALL] Get things moving with "random utilities" (Was: [lang]
>>> Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
>>>
>>>
>>> Hi.
>>>
>>> On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
>>>
>>>> [...]
>>>>
>>>>>
>>>>> But overall it would be much better to put all this in a new
>>>>> component
>>>>> and deprecate all of CL's "Random"-parameterized methods.
>>>>> It was noted (not only by me) that CL grew too big (and out of its
>>>>> original
>>>>> scope).  "RandomUtils" is relatively small (in Lang 3.4): now is a
>>>>> good
>>>>> opportunity to deprecate these few methods and those intended for
>>>>> 3.5
>>>>> and redirect users to a dedicated component.
>>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>>> [...]
>>>>>
>>>>
>>> Within the context of a forthcoming release of "Commons RNG" and
>>> identified shortcomings of the random-related utilities implemented
>>> in "Commons Lang", e.g.:
>>>  https://issues.apache.org/jira/browse/LANG-1196
>>>  https://issues.apache.org/jira/browse/LANG-1254
>>> I'm proposing to ask INFRA to create a new git repository, to become
>>> the "Commons" home of random utilities, i.e. anything that _uses_ an
>>> "external" source of randomness (as opposed to _implementations_
>>> of (P)RNG algorithms, which is the scope of "Commons RNG").
>>>
>>> Examples of utilities:
>>>  * non-uniform deviates (to be extracted from "Commons Math")
>>>  * extended tools, such as "numbers within a range" (to be
>>>    extracted from "Commons Lang") and "quasi-random" generators
>>>    (to be extracted from "Commons Math"),
>>>  * string utilities (to be extracted from "Commons Math" and
>>>    "Commons Lang"),
>>>  * shuffling of primitive arrays and "List<T>" (to be extracted
>>>    from "Commons Math"),
>>>  * bridges between alternative APIs:
>>>      - java.util.Random
>>>      - java.util.SplittableRandom
>>>      - UniformRandomProvider from "Commons RNG" (to be extracted
>>>        from "Commons Math")
>>>      - other Java libraries
>>>  * wrappers around "external" sources of randomness, e.g. system
>>>    devices (UNIX) and native libraries, and interface extensions
>>>    needed to support them (streams, IO handling, etc.).
>>>
>>> Given the variety of the above (non-exhaustive) list, it is
>>> foreseen that the component will be "multi-modules"[1] in order
>>> to let users depend only on what they need for their use-case.
>>> [For example, an engineering application could need non-uniform
>>> deviates (e.g. Gaussian-distributed sequences), but should not
>>> be required to depend on the (orthogonal) development of string
>>> generators or cryptographic features.]
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1] Help is most welcome to set this up.
>>>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
1234