-
Bug
-
Resolution: Fixed
-
P3
-
jfx14
-
b14
-
generic
-
generic
This is found while fixing JDK-8193286.
I fixedJDK-8193286 (which is bug due to incorrect implementation) and singled out this remaining issue as it involves a behavior change.
This is a bit of corner case - but, wrong behavior is observed for javafx.scene.control.SpinnerValueFactory.IntegerSpinnerValueFactory.
In this class, the behavior for increment() and decrement() is to increment or decrement value based on specified (amountToStepBy * number of steps)
If this (amountToStepBy * number of steps) is larger than Max-Min - and wrapAround property is set to True, then current implementation selects Max value in case of increment() and Min value in case of decrement().
Correct Behavior should be :
The since the wrapAround is set to true, eventhough the increment-by value is greater than Max-Min, we should wrap around and select a proper value between Min and Max (and NOT limit it to Max as in current implementation)
Same is for decrement() operation which selects Min in current implementation.
For example,
In SpinnerTest.java, test intSpinner_testWrapAround_increment_LargeStep()
min = 0
max = 10
initialValue = 5
amountToStepBy = 1
Test steps -
increment(1000)
increment(1000)
Current behaviour :
With these increments, the value selected is 10 - which is max value of the Spinner.
Expected behaviour -
Total numbers between max and min (both inclusive) = 11
Since we step from initialValue of 5
first increment(1000) - should result in (1000%11) = 10 steps - and select value 4 after wrapping around
second increment(1000) - should result in (1000%11) = 10 steps - and select value 3 after wrapping around
I fixed
This is a bit of corner case - but, wrong behavior is observed for javafx.scene.control.SpinnerValueFactory.IntegerSpinnerValueFactory.
In this class, the behavior for increment() and decrement() is to increment or decrement value based on specified (amountToStepBy * number of steps)
If this (amountToStepBy * number of steps) is larger than Max-Min - and wrapAround property is set to True, then current implementation selects Max value in case of increment() and Min value in case of decrement().
Correct Behavior should be :
The since the wrapAround is set to true, eventhough the increment-by value is greater than Max-Min, we should wrap around and select a proper value between Min and Max (and NOT limit it to Max as in current implementation)
Same is for decrement() operation which selects Min in current implementation.
For example,
In SpinnerTest.java, test intSpinner_testWrapAround_increment_LargeStep()
min = 0
max = 10
initialValue = 5
amountToStepBy = 1
Test steps -
increment(1000)
increment(1000)
Current behaviour :
With these increments, the value selected is 10 - which is max value of the Spinner.
Expected behaviour -
Total numbers between max and min (both inclusive) = 11
Since we step from initialValue of 5
first increment(1000) - should result in (1000%11) = 10 steps - and select value 4 after wrapping around
second increment(1000) - should result in (1000%11) = 10 steps - and select value 3 after wrapping around
- relates to
-
JDK-8331214 Doc: update spec for SpinnerFactory classes
- Resolved
-
JDK-8193286 IntegerSpinnerFactory does not wrap value correctly
- Resolved