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 <gil...@harfang.homelinux.org> 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" >> <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
