RFR: 8277817: java/awt/dnd/BadSerializationTest/BadSerializationTest.java failed: ClassNotFoundException: com.apple.laf.AquaImageFactory$SystemColorProxy [v9]

[Phil Race]

On Fri, 10 Dec 2021 17:03:49 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change updates the serialized objects used by `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` using a similar approach to the previous fix in [JDK-8039082](https://bugs.openjdk.java.net/browse/JDK-8039082).
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more missing calls to LookAndFeel.uninstallColors

Whilst there might well be some need to do something to make sure uninstallUI() is doing its job entirely/properly,
I am not sure that I'd want to push such a change as the resolution to this failing test.

Better to start afresh with a new bug with an appropriate synopsis and then write some new tests that verify the UI is uninstalled on all the Swing components as you cycle though available L&Fs per-platform.

And since the problem clearly exists in older versions of JDK (even if not exposed by the recent change in JDK 18),
then how would we resolve it there since clearly the new API can't be backported.

And perhaps new API isn't actually needed ? Are there other options ?

And as I wrote before, the failing test is not 100% valid since Swing's specification says :

"Warning: Serialized objects of this class will not be compatible with future Swing releases.
The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing."

"Same version" could be interpreted as "Swing in JDK N", or "Swing in JDK N on 'specific platform'"
But either way, it isn't valid to check in a serialized form from Swing version N and have *any* expectation that it will run on N+1, which is what this test does.
Yes, it can be argued that this test can/will fail even between platforms on the same version, but (1) I'm questioning whether
even that serialization was intended and (2) the test is not limiting itself to that scenario.

I did not understand the "special JDK" answer as to why this test needs to have a checked in serialized form on disk at all.
If we can't do that, I think we should scrap the test or find a different way to do whatever it intends to verify.
We should not be treating it as a test of uninstalling UI - it is a mere accident that this cropped up.

I see Alexey wrote much the same above ..

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

PR: https://git.openjdk.java.net/jdk/pull/6603