RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray

[Sergey Bylokhov]

On Mon, 23 May 2022 21:11:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> We probably can extract this to the separate cleanup, the resulted code is smaller and faster.
>> PS I have added a link to my previous message, accidentally hit submit button.
>
> I'm sure I've used this pattern
> return icons.toArray(EMPTY_TRAY_ARRAY);
> in code that runs often and may be performance sensitive, so I don't see anything weird about it.
> OTOH I am not sure this code is anything that needs super-optimising .. we seem to have gone down that discussion route because it was the justification for the change.
> 
> BTW the shiplev article, which I skimmed must be suggesting that the array initialisation must be faster if it is on the array it allocates itself because of the APIs used .. but as he also notes things can change.
> 
> Anyway this is mildly interesting discussion but no one will ever, ever be able to measure a difference when it used here since it is probably 0.0001 % of the work ...

It also has a functional implication, in the old code  the "size" on a Vector is called outside of the lock. So the resulted array after "icons.toArray" can be bigger than the number of icons. This is similar to this:
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/classes/javax/sound/midi/Sequence.java#L281
I think that race can even be triggered by the new test.

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

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