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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
