RFR: 4797982: Setting negative size of JSplitPane divider leads to unexpected results.

[Prasanta Sadhukhan]

On Fri, 22 Jul 2022 20:19:02 GMT, Phil Race <prr at openjdk.org> wrote:

> What are the "unexpected results" of < 0 ?

Normally, JSplitPane is expected to show 2 components either horizontally or vertically depending on if it is VERTICAL_SPLIT or HORIZONTAL_SPLIT but in case of -ve size, it only shows 1 component which might be construed as unexpected. KeyPress in 1st component if it's JTextArea seems to get lost as nothing is shown.

> Should it perhaps be 1 ?

It could have 3 cases
- set to 0 (it will not have any visible divider)
- set to 1 (it will have least visible divider)
- just return
I initially thought setting it to 0 as by default, the "dividerSize" variable is 0

but now, I think 3rd option of "just return" should be better as then it will fallback to default SplitPane.dividerSize value as L&F set it to some default value like
in Metal L&F it is 10 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L1371
in Aqua, it is 9 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java#L847
in Basic L&F, it is 7 
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1342

so if we set divider size to -ve and then call getDividerSize() it will return the default L&F specific divider size.

> we need a CSR

Canyou please clarify why? Is it because we are changing the behavior?
But, I guess, all bug fix(es) change the code to "correct" behavior and here also, we are rectifying the behavior without changing any spec/signature. 
I thought a CSR would have been needed if we had returned IAE. Here, I guess we are changing the implementation detail. Should I raise CSR for implementation detail?

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

PR: https://git.openjdk.org/jdk/pull/9566