On Tue, 22 Apr 2025 21:09:58 GMT, Jeremy Wood <d...@openjdk.org> wrote:
>> This PR changes how the BorderLayout positions components when they don't >> fit inside a container. >> >> This should have no effect on BorderLayouts that match or exceed their >> preferred size. >> >> (The name of this PR/ticket is a little misleading: this in no way relates >> to `component.getMinimumSize()`.) >> >> Here is part of a comment in that ticket that sums up what this PR is trying >> to fix: >>> Instead of the South Component being placed partially offscreen as Windows >>> does, it is often placed on top of the North Component. Indeed, >>> BorderLayout.layoutContainer() always places the South Component flush with >>> the bottom of the Container and does not check if the Container is smaller >>> than the minimum size, or if the North and South Components overlap. >> >> Previously child components could: >> A. be assigned negative (x,y) coordinates >> B. be assigned negative widths or heights >> C. overlap other child components >> D. be assigned dimensions that don't fit inside the target container >> >> This PR will instead constrain certain values. Now child components may be >> given a width/height of zero pixels, but they should never show the 4 >> behaviors stated above. >> >> We encountered this basic problem last week at work (we could end up with a >> component with a negative height). Our work-around was more complex than >> this PR: we wrote a modified BorderLayout that would switch to using >> `component.getMinimumSize()` when the preferred size wouldn't fit. IMO that >> is a better option all-around, but it is dangerously invasive for an OpenJDK >> proposal. I'm happy to discuss that idea further, though, if anyone here >> disagrees. > > Jeremy Wood has updated the pull request incrementally with six additional > commits since the last revision: > > - Update > test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> > - Update > test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> > - Update > test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> > - Update > test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> > - Update > test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> > - Update > test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> The client team spent some time discussing this today. There are a lot of concerns about this. It is well intentioned and the behaviour may be odd but - applications (of which there are tens of thousands) can be very sensitive to layout manager behaviour. BorderLayout is so widely used that probably every Java UI app worth using uses it. We think it almost certain that some applications will be broken, perhaps as a result of a bug in their code they didn't realise they had, such as attempts to compensate for this which will then behave differently. - how will we test it ? I ran all our automated tests and they pass, but they are toy apps and maybe aren't even going to fail even if the UI lays out wrong. Even if they did something that matters. We would need real world + manual testing. - The spec says preferred size is what layout uses. I don't know how unique that is but I didn't spot the same in the other basic layout managers - GridBagLayout explicitly says it looks at pref/min/max. BorderLayout only says preferred - - I also looked at the history. JDK 1.4.2 (2003 ?) is the release I looked at and I see no bug fixes in BorderLayout between then and now. Tweaks to conform to new policies and new API methods in 1.5 .. but that's all. So BorderLayout has behaved the same for a quarter of a century. Should we touch it now ? So I'd prefer to not do this, even if it is valid fix, and the bar for accepting it would be high - Lots of real world testing - from BIG apps, like Intellij, Netbeans - A way to disable the change for the likely broken apps. - A probable spec. change, so it will never be backported (should not happen regardless) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24772#issuecomment-2829328797
