RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() [v6]

[Prasanta Sadhukhan]

On Wed, 20 Dec 2023 16:58:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > > But I do have another suggestion that actually might have been the best thing to do all those years ago. Keep the over-ride as the default behaviour, and document it better. But if the app calls setMaximumSize or setMinimumSize() then honour it like you are supposed to. I suspect very few apps actually call these since they are complete no-ops today. If we do that, then yes, you'll still see differences if you do call those APIs and forgot about it because it didn't make a difference.
> > > 
> > > 
> > > Do you mean this way https://openjdk.github.io/cr/?repo=jdk&pr=15325&range=01#sdiff-0-src/java.desktop/share/classes/javax/swing/JScrollBar.java what I had done in the initial iteration? I guess that change will still show the above problem during frame resize, where scrollbars are not rigid
> > 
> > 
> > This is how I understand Phil's comment.
> 
> As I understand Phil's comment, he suggests using the implementation that you used in the first iteration of this fix:
> 
> https://github.com/openjdk/jdk/blob/31bbdee8ea71f43eb4863af50b398170a7b81ed2/src/java.desktop/share/classes/javax/swing/JScrollBar.java#L762-L772
> 
> That is we preserve the current behaviour of `getMinimumSize()` and `getMaximumSize()` methods in `JScrollBar`, yet if `setMinimumSize()` or `setMaximumSize()` is called, the corresponding `get-` methods return the set value and thus they follow the contract specified in `JComponent`.
> 
> @prrace, could you confirm, please?
> 

I already mentioned to him in this comment https://github.com/openjdk/jdk/pull/15325#issuecomment-1818768822
that moving back to initial fix iteration will cause the same problem as you mentioned https://github.com/openjdk/jdk/pull/15325#issuecomment-1796167220 which is the same what we observed when we removed these 2 getXXX methods (which was mentioned in hmuller comment) so if we are OK with the change in behaviour as compared to current, then removing these 2 methods may be considered as compared to moving to 1st iteration of this fix...

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1873589422