New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
4797982: Setting negative size of JSplitPane divider leads to unexpected results. #9566
Conversation
|
Webrevs
|
@prsadhuk This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 857 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
@@ -424,6 +424,9 @@ public String getUIClassID() { | |||
@BeanProperty(description | |||
= "The size of the divider.") | |||
public void setDividerSize(int newSize) { | |||
if (newSize < 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the "unexpected results" of < 0 ?
Should it perhaps be 1 ?
And what about this ?
https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#setDividerSize(int)
And we need a CSR ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
So instead you propose to change from one un-specified behaviour to another un-specified behaviour ? It seems to me we should be updating javadoc to say what should happen. |
OK. javadoc clarified and CSR raised https://bugs.openjdk.org/browse/JDK-8290992 |
@@ -418,12 +418,18 @@ public String getUIClassID() { | |||
|
|||
/** | |||
* Sets the size of the divider. | |||
* @implNote Divider sizes < 1 are ignored. | |||
* {@code SplitPane.dividerSize} L&F specific value | |||
* will instead be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't the same as ignoring it. Suppose we do
setDividerSize(5);
setDividerSize(-1);
what is the value after both of these - per your ignoring code 5, but per your doc it will be whatever the default was before you started to change it.
I think it sufficient to say it will be ignored and drop the 2nd clause.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Modified javadoc and CSR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My apologies, but because I focused on the rest of it, I overlooked you had made this an implNote.
That seems odd. Do you really intend to imply that some other implementation of Java should be allowed
to do something with negative values ? If so that would be a compatibility issue ..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, actually I was thinking in that sense, as I was not sure if other impl. will allow -ve values and just wanted to mention that our impl dont.
But, I guess as you pointed, we should make it disallowed for all. Modified PR and CSR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, have some concerns with this change.
Why not allow zero divider size?
The look and feel could use an invisible 6px wide divider that partly overlaps the left and right components.
Then moving divider is still possible, but no divider is visible, which is often used in modern UI.
I actually plan to implement this for FlatLaf.
Sure, with current L&Fs it is not possible to move divider when dividerSize is zero,
but applications may still control the divider location with JSplitPane.setDividerLocation()
.
So it is possible that dividerSize zero is used in existing applications.
Why ignoring negative values?
Wouldn't it better to throw an IllegalArgumentException
to give the developer some feedback?
Isn't this common practice in Java?
There are several parameter checks in JSplitPane
and all throw IllegalArgumentException
.
E.g. JSplitPane.setResizeWeight(double)
We were not sure if -ve divider size can be used by third party implementation. It probably will be considered a compatibility issue as mentioned earlier. |
IAE is just too incompatible. The program would probably stop working if anyone is actually doing that. I didn't get why some effect like the "visibility" of the divider in some L&F should be allowed to over-rule the specified size. |
All look and feels initially set the divider size to what they need. This is done here: jdk/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java Lines 357 to 358 in eab4c0c
Each L&F uses its own divider size. jdk/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Line 1247 in 0a65e8b
Or Metal L&F uses jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java Line 1371 in d4b040f
So a L&F could also use divider size zero to implement an invisible divider.
If the application invokes L&Fs do not invoke jdk/src/java.desktop/share/classes/javax/swing/JSplitPane.java Lines 1059 to 1064 in 096bca4
|
@prrace Probably we could reinstate @implNote to the javadoc as I did earlier, to allow 3rd party L&F -ve divider size? |
@prsadhuk This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
/integrate |
Going to push as commit 2be3158.
Your commit was automatically rebased without conflicts. |
Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.
Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9566/head:pull/9566
$ git checkout pull/9566
Update a local copy of the PR:
$ git checkout pull/9566
$ git pull https://git.openjdk.org/jdk pull/9566/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 9566
View PR using the GUI difftool:
$ git pr show -t 9566
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9566.diff