<AWT Dev> [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7

Anthony Petrov 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.

best regards,

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,
> Anton
> 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,
>> Anton
>> 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,
>>> Anthony
>>> 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,
>>>> Anthony
>>>> On 08/24/12 21:36, Anton Litvinov wrote:
>>>>> Hello,
>>>>> 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 
>>>>> page
>>>>> of this bug. The provided webrev contains both a fix and a 
>>>>> corresponding
>>>>> 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,
>>>>> Anton

More information about the awt-dev mailing list