Hi Artem,
Thank you for review.
I have added the comment to JIRA.
As for the test. Even if Toolkit.setDesktopProperty() were called using
reflection, it seems to me, such test wouldn't be indicative, because
even before the fix both contexts had a chance to be updated correctly.
The bug has stochastic nature and requires that the event scheduling on
both EDTs happens roughly at the same time. It's hard to make this
deterministic.
--Semyon
On 4/28/2016 6:04 PM, Artem Ananiev wrote:
Hi, Semyon,
On 4/21/16 4:22 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8046031
webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
Under the Windoew LnF when the native Windows theme is changed some java
frames remains unchanged if there are several application contexts. The
thing is the DesktopProperty#updatePending flag that prevents to run
more then one UI update operation is shared between different
applications contexts while they may be updated with the property change
concurrently from different EDT threads so they may loose the update.
To avoid this mutual interference the updatePending is moved from the
global to the application context scope.
could you add this evaluation to bug comments, please? At a glance,
the fix looked flawed to me, but then in email discussion you proved
it's fine, so the details are worth adding to the bug. For example,
it's far from trivial to understand, why updatePending is shared
between different DefaultProperties (globally in VM before the fix,
and within the current AppContext after the fix).
The test would require to write native code so the issue is labeled
noreg-hard.
Does it really require native code? A test can create two app
contexts, one desktop property, call its updateUI() in both EDTs, and
check that it's executed twice.
Thanks,
Artem
--Semyon
