Hi David,<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The original code is rather strange. The static field will be default initialized to zero, the AppContext constructor will increment it to 1, then the static block explicitly sets it to one.<br>

It would be cleaner/clearer if the field were declared and initialized before the static block.<br></blockquote><div>Agreed. Please find the modified patch at: <a href="http://cr.openjdk.java.net/~ceisserer/7080700/webrev.04/">http://cr.openjdk.java.net/~ceisserer/7080700/webrev.04/</a><br>
 <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
That&#39;s an uninteresting case from a data-race perspective though because the counter is only ever written once.<br></blockquote><div>In the constructor the non-atomic increment can cause a missed update and therefor cause numAppContexts to become 1 or even 0, which could trigger that logic unintentionally.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
However I now wonder about how often this gets called in a Swing app? If this is a frequent call then the overhead of the atomic might be significant. Perhaps the Swing folk should be evaluating this change as well? </blockquote>
<div>Did some benchmarks,  and at least on x86 AtomicInteger.get() performs identical to a volatile field read.<br><br><br>Thanks, Clemens<br></div>