<AWT Dev> [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7
anthony.petrov at oracle.com
Tue Aug 28 09:44:15 PDT 2012
Thanks. I've reviewed your new fix already. Note that someone else from
Swing team must also take a look at it to make sure it's OK.
On 8/28/2012 8:25 PM, Anton Litvinov wrote:
> Hello Anthony,
> Thank you for the review and additional information concerning the
> process of handling GraphicsConfiguration in AWT package. But I decided
> to fix this issue from side of Swing package. A corresponding review
> request was sent to "swing-dev at openjdk.java.net" e-mail alias.
> Thank you,
> On 27.08.2012 18:53, Anton Litvinov wrote:
>> Hello Anthony,
>> Thank you for the review. I would like to clarify that this issue is
>> an escalation.
>> After working on this bug I came to a conclusion that a reason of this
>> bug is the fact that updateGraphicsData() method of not completely
>> deserialized container is called during deserialization process. In
>> this case the situation is the following:
>> 1. readObject() method of JPanel is called.
>> 1.1. readObject() method of JFrame is called during deserialization of
>> JPanel's subcomponents, since they depend on JFrame through
>> PropertyChangeSupport field.
>> 1.2. initDeserializedWindow of JFrame as java.awt.Window is called and
>> leads to subsequent calls to updateGraphicsData() of all subcomponents
>> including that JPanel in step 1, which was not executed completely yet.
>> Deferring of updateGraphicsData() method could be a solution, but how
>> can this be done technically? Also is there a guarantee that no logic,
>> which executes after updateGraphicsData() and before the end of
>> deserialization, relies on the results of updateGraphicsData() method?
>> This issue is reproducible on JDK 8 too, but since it was originally
>> escalated on JDK 7 it should be fixed on JDK 7 first and then fixed in
>> JDK 8.
>> Concerning a name of a directory containing the test, I am a new
>> employee and I do not know the exact naming conventions. But before
>> doing this I searched for existing tests and found many directories
>> created in 2012 whose names contain bug numbers. I am ready to apply
>> what ever name is better. I do not think that the test case can be
>> written without Swing package, because it is related to certain
>> escalation and I do not have right to change the original test case
>> provided with escalation significantly.
>> Thank you,
>> On 27.08.2012 16:56, Anthony Petrov wrote:
>>> Also, I suggest to name the test directory/filename with a
>>> human-readable name (just like all the other tests in AWT area do).
>>> BTW, since this is an AWT test, do we actually have to use Swing
>>> there? Can we make it an AWT-only test?
>>> best regards,
>>> On 08/27/12 16:49, Anthony Petrov wrote:
>>>> Hi Anton,
>>>> After deserialization completes, the components in the 'component'
>>>> collection must all share the same graphics configuration as its parent
>>>> container (which is being deserialized). While your fix resolves the
>>>> NPE, it doesn't yet sets up the child components with the correct
>>>> graphics configuration after the 'component' collection has been
>>>> populated which children during deserialization. I think we should
>>>> probably add a deferred call to updateGraphicsData() somewhere at the
>>>> readObject() method.
>>>> Also, should this issue be fixed for JDK 8 first, and then ported back
>>>> to JDK 7u?
>>>> best regards,
>>>> On 08/24/12 21:36, Anton Litvinov wrote:
>>>>> Please review the following fix for a bug.
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
>>>>> Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00
>>>>> For details on this bug please look at "Evaluation" field on a web
>>>>> of this bug. The provided webrev contains both a fix and a
>>>>> unit-test. Also before publishing this webrev all unit-test from the
>>>>> "java.awt" and
>>>>> "javax.swing" swing related to serialization and usage of
>>>>> "GraphicsConfiguration" class were run and no negative changes were
>>>>> observed comparing the results of tests' runs on JDK with and without
>>>>> patch represented by this webrev.
>>>>> Thank you,
More information about the awt-dev