Hi Petr,
On 5/22/2014 7:42 PM, Petr Pchelko wrote:
Please review a yet another AppContext fix:
https://bugs.openjdk.java.net/browse/JDK-8043393
The fix is available here:
http://cr.openjdk.java.net/~pchelko/9/8043393/webrev/
checkChange method is called on a Toolkit thread, but we are trying to convert
formats to flavors there.
The conversion needs to to use the SystemFlavorMap which is local to
AppContext. But really we can
avoid conversion and compare native formats.
This fix is not absolutely precise: in case we have several applets in one VM
and each applet have set it's own
different flavor mapping, it's possible (but highly unlikely) that a
notification would be delivered incorrectly.
By "delivered incorrectly", what do you mean exactly?
The crux of the fix is to get rid of a call to
formatArrayAsDataFlavorSet(). Do I understand correctly that the size()
of the returned Set<> may not be equal to the length of the formats
array passed as an argument to this method? Why could this happen?
Also, what is the order of longs stored in this array? Are we certain
it's always the same, and so the Arrays.equals() does the right thing?
Or should we sort the arrays first?
--
best regards,
Anthony
But fixing that imaginary bug would require enormous amount of changes in
Clipboard event delivery and will make
it way harder to modularize the DataTransfer system. So I believe that a simple
solution would work better here.
I can file a new P4 bug for the described scenario to address it after I finish
DataTransfer modularization.
With best regards. Petr.
