On Thu, 6 Aug 2026 15:11:56 GMT, Andy Goryachev <[email protected]> wrote:
> There seems to be a problem with the fix. Using the test program > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/TestAutoResizeLastColumn.java > > follow the steps: > > * resize the first column slightly > > * double click on the last column > > * observed: the columns are resized wildly. expected: columns should not > get resized. > > Yes, there was a problem.. JTable still sometimes treats a later layout as if it were the first layout Basically there are 2 cases 1. First layout: JTable should read preferredWidth values and create real column widths. 2. Later layout: JTable should preserve the user’s current column widths. If the table width changed, only the last column should absorb the difference. JTable may run layout again during editing/validation. At that point the width/preferredWidth values can still look like a case where preferred widths should be reapplied, even though this is no longer initial layout so JTable did the wrong thing user resized first column -> JTable stores new preferred/current widths double-click cell -> layout runs -> code thinks "maybe initial layout" -> preferred widths are applied again -> columns jump/rescale unexpectedly so I have introduced a flag `columnWidthsInitialized` false = real column widths have not been established yet true = JTable already did its first width layout so now the logic is If AUTO_RESIZE_LAST_COLUMN and widths are not initialized: [using default width of 75] apply preferred widths once If AUTO_RESIZE_LAST_COLUMN and widths are already initialized: do not reapply preferred widths only adjust last column by table-width delta ------------- PR Comment: https://git.openjdk.org/jdk/pull/31704#issuecomment-5213422770
