8234071: JTable.AUTO_RESIZE_LAST_COLUMN acts like AUTO_RESIZE_ALL_COLUMNS

[prsadhuk]

When a JTable is resized with JTable.setAutoResizeMode set to AUTO_RESIZE_LAST_COLUMN then it behaves exactly as if I specified AUTO_RESIZE_ALL_COLUMNS.
This is because when JTable.doLayout tries to resize the columns, it checks which column to resize by calling getResizingColumn and in absence of any column info, it resizes all, so during setAutoResizeMode the resizing column needs to be set, which is being done for AUTO_RESIZE_LAST_COLUMN in this fix.
No regression test is provided as it can be easily checked with SwingSet2->JTable(demo)->Autoresize mode (set to "Last Column")

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8234071: JTable.AUTO_RESIZE_LAST_COLUMN acts like AUTO_RESIZE_ALL_COLUMNS (Bug - P4)

Reviewers

• Phil Race (@prrace - Reviewer)
• Abhishek Kumar (@kumarabhi006 - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/20107/head:pull/20107
$ git checkout pull/20107

Update a local copy of the PR:
$ git checkout pull/20107
$ git pull https://git.openjdk.org/jdk.git pull/20107/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 20107

View PR using the GUI difftool:
$ git pr show -t 20107

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/20107.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back psadhukhan! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@prsadhuk This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8234071: JTable.AUTO_RESIZE_LAST_COLUMN acts like AUTO_RESIZE_ALL_COLUMNS

Reviewed-by: prr, abhiscxk

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 138 new commits pushed to the master branch:

• 02be7b8: 8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation
• bbc79a5: 8333768: Minor doc updates to java.lang.{Float, Double}
• 245c086: 8332600: javac uses record components source position during compilation
• 5f7b007: 8336346: Fix -Wzero-as-null-pointer-constant warnings in jvmciJavaClasses.cpp
• 4a73ed4: 8330144: Revise os::free_memory()
• 35df48e: 8335860: compiler/vectorization/TestFloat16VectorConvChain.java fails with non-standard AVX/SSE settings
• 7bf5313: 8335480: Only deoptimize threads if needed when closing shared arena
• 1b83bd9: 8336661: Parallel: Remove stacks_empty assert in PSScavenge::invoke
• 72297d2: 8317720: RISC-V: Implement Adler32 intrinsic
• 21a6cf8: 8336587: failure_handler lldb command times out on macosx-aarch64 core file
• ... and 128 more: https://git.openjdk.org/jdk/compare/b9d8056d5c1528198ad373f9b4a09547e2fcabd6...master

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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@prsadhuk The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[prrace]

Isn't LAST_COLUMN is meant to be different than specifying a particular column ?
Suppose the app specified the resizing column and expects it to be unchanged after changing mode back to a previous mode ?
If the app changes the mode would it really expect now a particular column to be specified ?
Is a specific test going to be hard ?
No one actually routinely manually tests this in SwingSet, and we don't do integration testing any more.

[mlbridge]

Webrevs

• 02: Full - Incremental (6aa07353)
• 01: Full - Incremental (a441f380)
• 00: Full (0122fc75)

[prsadhuk]

Isn't LAST_COLUMN is meant to be different than specifying a particular column ? Suppose the app specified the resizing column and expects it to be unchanged after changing mode back to a previous mode ? If the app changes the mode would it really expect now a particular column to be specified ? Is a specific test going to be hard ? No one actually routinely manually tests this in SwingSet, and we don't do integration testing any more.

As per the JTableHeader.setResizingColumn spec,
Application code will not use this method explicitly, it is used internally by the column sizing mechanism
so app will/should not specify the resizing column directly so I guess it's alright to expect this will not get changed..
I also tested with different autoresize modes and it works fine.

Regarding test, I am not able to think of any automated way to test this, so if it can be manual, then I thought it will be as good to test it out through SwingSet2 since manual tests also is run only during ATR...

[kumarabhi006]

I have a doubt for auto resize property, similar behavior is holding true for AUTO_RESIZE_NEXT_COLUMN .
If the user set the mode to AUTO_RESIZE_NEXT_COLUMN, all columns are of same width and resized on expanding of container window. As per the spec ( AUTO_RESIZE_NEXT_COLUMN: Use just the column after the resizing column. This results in the "boundary" or divider between adjacent cells being independently adjustable.) only the next column should be resized not all the columns.

Is it the correct behavior ? If not, shouldn't AUTO_RESIZE_NEXT_COLUMN also needs to be handle along with AUTO_RESIZE_LAST_COLUMN ?
or
user implementation needs to be changed to handle this mode ?

Otherwise current fix is working as expected for AUTO_RESIZE_LAST_COLUMN.

[prsadhuk]

Check added to guard against the possibility of DefaultTableColumnModel.getColumn , which according to spec, can throw AIOBE
if columnIndex is out of range: (columnIndex < 0 || columnIndex >= getColumnCount())

[prsadhuk]

I have a doubt for auto resize property, similar behavior is holding true for AUTO_RESIZE_NEXT_COLUMN . If the user set the mode to AUTO_RESIZE_NEXT_COLUMN, all columns are of same width and resized on expanding of container window. As per the spec ( AUTO_RESIZE_NEXT_COLUMN: Use just the column after the resizing column. This results in the "boundary" or divider between adjacent cells being independently adjustable.) only the next column should be resized not all the columns.

Is it the correct behavior ? If not, shouldn't AUTO_RESIZE_NEXT_COLUMN also needs to be handle along with AUTO_RESIZE_LAST_COLUMN ? or user implementation needs to be changed to handle this mode ?

Otherwise current fix is working as expected for AUTO_RESIZE_LAST_COLUMN.

Not sure about the spec you are referring to?
I see https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/javax/swing/JTable.html#AUTO_RESIZE_NEXT_COLUMN
When a column is adjusted in the UI, adjust the next column the opposite way.

It seems to behave similarly with and without this fix, although it may not be what the spec is demanding..It is not similar to LAST_COLUMN spec so cannot be handled along with it..I guess it's a separate issue, if it is one...

[kumarabhi006]

Not sure about the spec you are referring to? I see https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/javax/swing/JTable.html#AUTO_RESIZE_NEXT_COLUMN When a column is adjusted in the UI, adjust the next column the opposite way.

I was referring to the description of AUTO_RESIZE_NEXT_COLUMN in doLayout API.

It seems to behave similarly with and without the fix, although it may not be what the spec is demanding.

Yeah, that's what I was trying to say that changes may be required for AUTO_RESIZE_NEXT_COLUMN as it is not as per spec.

It is not similar to LAST_COLUMN spec so cannot be handled along with it..I guess it's a separate issue, if it is one...
Ok.

[kumarabhi006]

Conditions can be combined

if (mode == JTable.AUTO_RESIZE_LAST_COLUMN && columnModel.getColumnCount() > 0) {

[prsadhuk]

I was referring to the description of AUTO_RESIZE_NEXT_COLUMN in doLayout API.

"boundary" or divider between adjacent cells being independently adjustable
I guess this is happening...You can resize each column independently by the "divider" between 2 columns (i.e., by dragging the divider left or right, you can see columns can be resize independently)

[prsadhuk]

@prrace Need your re-review please..I guess skara is modified to ask for reapproval after PR change (added AIOBE check)

[kumarabhi006]

Looks good to me.

[prsadhuk]

/integrate

[openjdk]

Going to push as commit 902bada.
Since your change was applied there have been 143 commits pushed to the master branch:

• 1b9270a: 8328723: IP Address error when client enables HTTPS endpoint check on server socket
• 330e520: 8028127: Regtest java/security/Security/SynchronizedAccess.java is incorrect
• 39f4476: 8334772: Change Class::signers to an explicit field
• 902c2af: 8336585: BoundAttribute.readEntryList not type-safe
• b44632a: 8336588: Ensure Transform downstream receives upstream start items only after downstream started
• 02be7b8: 8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation
• bbc79a5: 8333768: Minor doc updates to java.lang.{Float, Double}
• 245c086: 8332600: javac uses record components source position during compilation
• 5f7b007: 8336346: Fix -Wzero-as-null-pointer-constant warnings in jvmciJavaClasses.cpp
• 4a73ed4: 8330144: Revise os::free_memory()
• ... and 133 more: https://git.openjdk.org/jdk/compare/b9d8056d5c1528198ad373f9b4a09547e2fcabd6...master

Your commit was automatically rebased without conflicts.

[openjdk]

@prsadhuk Pushed as commit 902bada.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.