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" <gil...@harfang.homelinux.org> wrote: On Fri, 30 Dec 2016 18:22:37 +0000 (UTC), Bernd Eckenfels wrote: > Hello, > You suggested to use UniformRandomProvider in TEXT-36. > I suggest to use j.u.Random because it is a common (interface like) I know that already. To advance the discussion, could you please comment on the issues in the document I referred to below? > type which is easy to provide any alternative random provider you > would want (on protected method to implement) See document. > - just like InputStream > is a commonly subtyped base class. Comparison is not reason. Perhaps "InputStream" is not as flawed as "Random"... > In a lot of situations people will be happy with j.u.R I bet that in the majority of those cases, they are happy because they don't know better (a variation on "security through obscurity"). I was among them a year ago. Anyways my proposal takes care of people who'd insist on getting randomness from "Random"; they'll choose the corresponding bridge, with the knowledge that an LCG generator fails ~70 tests of uniformity whereas state-of-the-art RNG algorithms fail 1 or 2 (see reports in RNG's user guide). > or they can > use SecureRandom (which also implements j.u.R), Yet another flaw of old JDK's design decisions... Anyways, the bridge allows this equally well. > but if the need more > control over the RNG or the distribution they can easily adjust. No > multi-module or optional dependency is needed for that. > And the RNG->j.u.Random bridge can be provided in RNG for other uses > as well. I already wrote that such a bridge exists (see Javadoc of RNG's "commons-rng-simple" module). It is a sub-par solution. There is no reason to stick to java.util.Random. Where is the problem with a modular component? This will be transparent to the average user (who, by the way, wouldn't care less if there were a mandatory dependency on Commons RNG). For those who want more control of dependencies, it also won't be a problem to state explicitly which bridge they want to use. Gilles > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > > > > On Fri, Dec 30, 2016 at 7:11 PM +0100, "Gilles" > wrote: > > > > > > > > > > > On Fri, 30 Dec 2016 17:30:17 +0000 (UTC), Bernd Eckenfels wrote: >> Sorry I meant *uniform* distribution >> >> Gruss >> Bernd >> >> >> >> >> >> On Fri, Dec 30, 2016 at 5:58 PM +0100, "Bernd Eckenfels" >> wrote: >> >> >> >> >> >> >> >> >> >> >> Hello, >> I am somewhat unclear, why would you require a random distribution >> (Interface). > > Who said? > >> Is there no better more generic Interface in RNG-API? > > Have you had a look at > > > http://commons.apache.org/proper/commons-rng/commons-rng-client-api/index.html > ? > >> Having said that I still think j.u.Random is fine > > Have you read > > > http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html > ? > > Why use a poor algorithm when using a better one is as easy? > >> - but if not maybe a >> byte or int Provider would be better than a specific interface for >> the >> random source. > > I don't follow. > How do you define this "Provider" if not with an interface? > > Gilles > >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> >> >> >> On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible" >> wrote: >> >> >> >> >> >> >> >> >> >> >> Gilles wrote: >> >>> Hi. >>> >>> On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote: >>>> Hello all, >>>> >>>> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira >>>> tickets before proceeding with the release, but I wanted to check >>>> to >>>> see if anyone else has any opinions on what work needs to be >>>> completed >>>> before the release. >>>> >>>> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively >>>> indifferent here, I just want some other’s to weigh in as to their >>>> thoughts before deciding to leave in the dependency >>> >>> I don't follow. >>> Currently, there is no dependency towards RNG. >>> >>> Personally, I'm in favour of an API that "advertizes" and >>> recommends >>> usage of its RNG sibling component. [As [TEXT] is, admittedly, a >>> high-level component (and it already depends on [LANG]).] >>> >>> However a consensual proposal would be to define a custom interface >>> (see JIRA discussion), and define the API around it. >>> >>> [TEXT] should be made "multimodule"; it could then provide bridges >>> (cf. JIRA comment) in separate modules: >>> >>> * commons-text-core (algos) >>> * commons-text-commons-rng-bridge (from >>> "o.a.c.rng.UniformRandomProvider") >>> * commons-text-jdk-bridge (from "java.util.Random") >>> >>> The dependency towards Commons RNG thus becomes optional. >>> But application developers have to explicitly choose an >>> implementation (which is good). >> >> You can achieve something similar by declaring commons-rng as >> optional. If >> you introduce an API for the random functionality and one >> implementation is >> based on commons-rng, any user will have to declare this dependency >> on his >> own if he like to use this implementation. >> >> We have a similar setup in vfs where you have to declare jsch as >> dependency >> on your own if you want SSH support for the protocol in use. >> >>>> and making more >>>> progress on the best pattern after the 1.0 release. >>> >>> API decisions must be made before a major release. >>> >>> The best pattern is the above (IMHO, and as per Jochen's note): >>> higher flexibility and higher correctness. >> >> Cheers, >> Jörg >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
