On Fri, Feb 5, 2010 at 3:15 PM, sebb <seb...@gmail.com> wrote: > I'm hopefully near to finding a version of nextLong(long) that > distributes the numbers better. > There's no such functionality in Random (even in Java 6) so that might > even be a useful addition for Lang3. > > But there are some other aspects of RandomUtils and JVMRandom classes > that seem plain wrong in the current 2.4 release: > > RandomUtils.nextInt() returns a number in the range [0,Integer.MAX_VALUE) > > however > > RandomUtils.nextInt(Random) returns a number in the range > [Integer.MIN_VALUE,Integer.MAX_VALUE] > > (unless Random is JVMRandom of course) > > Similarly for nextLong(). > > This is not documented for 2.4 and seems like an accident of the > original implementation, rather than a conscious design decision. I've > added some Javadoc to trunk to document the current behaviour, but I > am now wondering whether it would be OK to fix the behaviour so it > agrees with the 2.4 Javadoc?
I would say fix the javadoc rather than change the behaviour > Also, given that JVMRandom now relies on a static copy of Random, it > would be trivial to implement some of the missing functionality, such > as: > > public static void nextBytes(byte[]); > public static synchronized double nextGaussian(); > > with corresponding changes to the instance methods in JVMRandom. > > Should this be done, or is it better to leave the methods unimplemented? I think we should only be adding new features that are also going into the trunk. Since RandomUtils & JVMRandom have been deleted from trunk then I don't think we should do this. Niall --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
