RFR: 8346107: Generators: testing utility for random value generation

[theoweidmannoracle]

On Wed, 18 Dec 2024 11:50:50 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> What I'm thinking of doesn't involve any generics. I'm talking about specialMinFrequency, specialMaxFrequency, specialCountDown and the logic in next* to decide whether to provide a special value or not now. This is independent from whether float or double is used, as far as I can tell.
>
> Ok. I suppose I could factor this out into some extra class and extra file.
> But is that worth it? Then I need to still somehow route all that logic through the constructor, and `nextDouble`. I think in the end I have more code and more abstractions, I don't yet see how that is worth it.
> 
> Maybe you had a better idea in mind that I did not yet think of ;)

To be more clear, without generics:


abstract class FloatingGenerator {
      // specialCountDown detemines in how many iterations we generate the next special value.
     private final int specialMinFrequency;
     private final int specialMaxFrequency;
     private int specialCountDown;

    // .. constructor ...

     protected final bool shouldUseSpecial() {
         specialCountDown--;
         if (specialCountDown <= 0) {
             specialCountDown = RANDOM.nextInt(specialMinFrequency, specialMaxFrequency);
             return true;
         } else {
             return false;
         }  
     }
}


Then in SpecialDoubleGenerator:


     @Override
     public double nextDouble() {
         if (shouldUseSpecial()) {
             int r = RANDOM.nextInt(VALUES.length);
             return VALUES[r];
         } else {
             return backgroundGenerator.nextDouble();
         }
     }


If you make FloatingGenerator generic, though, of course, and rename the methods from nextDouble and nextFloat to just next for the generators, then everything except for the list of special values itself could be moved into FloatingGenerator. That would result in very clean code in my opinion. If you need to adjust the logic for special selection later, with the current approach, that requires changes in multiple locations, which in my experience, ultimately leads to inconsistencies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22716#discussion_r1890113620