Have a look at the patch I posted to MAHOUT-260. It ducks the injection question for now.
However, what's perhaps most interesting is that it makes tests fail! Some tests get different answers with the stock JDK rng. If we want to go in Drew's suggested direction, we have to decide what to do about seeds. We either need to define an 'RandomNumberGeneratorFactory' interface which takes seeds and return generators, or we want to inject Random objects and expect the injector to worry about constructing and dealing with seeds. On Sun, Jan 17, 2010 at 9:59 PM, Drew Farris <drew.far...@gmail.com> wrote: > I've used spring a great deal as well and generally look pretty > favorably upon it, but readily admit there are definite cons to it to. > > However, we can support the concept of injection without having to > commit to using one framework or another. Every class is instantiated > somewhere, so manual injection can be performed sans framework at that > point. Speaking specifically for this case, the contract would be that > anything that requires a RNG gets it injected by the class that > instantiates it instead of obtaining one through some method of its > own. > > There's a great series of posts that describe the advantages to this > approach when it comes to testability that's reachable from: > http://misko.hevery.com/2008/09/10/where-have-all-the-new-operators-gone/ > > This sort of injection strategy can be introduced steps across the > codebase using manual injection techniques and then as/if needed a > dynamic injection framwork can be folded in. It seems that plugging in > RNG's might be a good place to start. > > Drew > > On Sun, Jan 17, 2010 at 9:35 PM, Benson Margulies <bimargul...@gmail.com> > wrote: >> One moral equivalent of Spring is a String property with a >> fully-qualified class name which RandomUtils instantiates to get its >> RNG. Another is to actually inject the RNG object. Spring would get >> really tempting here. >> >> I've had an extended immersion in Spring via CXF, so I have a low >> threshold for introducing it. >> >> >> >> On Sun, Jan 17, 2010 at 9:24 PM, Drew Farris <drew.far...@gmail.com> wrote: >>> On Sun, Jan 17, 2010 at 9:10 PM, Sean Owen <sro...@gmail.com> wrote: >>>> There are already cases where code needs to control the seed (mostly >>>> to serialize/deserialize the exact state of an object). I don't think >>>> that's the issue per se? The issue is when an RNG lives beyond one >>>> test, and there are legitimate reasons that may be so. >>> >>> Ahh, ok, I wasn't really considering this. Would it be sufficient to >>> assign the RNG to a static field in the test class in this case? If it >>> needed to live across multiple classes, it could be public. >>> Nevertheless.. >>> >>>> I don't see how a getTestRandom() method fixes something... I can't >>>> call this in my non-test code, and then tests can't control those >>>> RNGs. The non-test code can't make this decision which is why they >>>> don't. I don't think this is the problem/solution but rather having a >>>> way to globally reset all RNGs. >>> >>> I suspect I'm missing something here because I don't understand how >>> randomness is used in the non-test code or specifically how the RNG's >>> are managed. I was (falsely, likely) assuming that the non-test code >>> didn't obtain the RNG itself but rather had it provided/injected by an >>> external source. In the context of a test, something from >>> getTestRandom() which uses a fixed seed could be injected, while in >>> production code something else would be. >>> >> >
