RFR: 8224261: JProgressBar always with border painted around it [v3]

[Abhishek Kumar]

On Tue, 21 Nov 2023 17:12:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Do they need to be? I mean you can do everything on EDT, even throw the exception from there. 
>> 
>> Yeah, everything can be done on EDT but what is the advantage of that?
>> I mean as per current test, swing UI components are accessed on EDT and then the comparison is done on main thread. 
>> 
>> Curious to know what we achieve extra by doing the way you suggested above?
>
>> > Do they need to be? I mean you can do everything on EDT, even throw the exception from there.
>> 
>> Yeah, everything can be done on EDT but what is the advantage of that?
> 
> Less code, all the variables are local in one method, no need to care about any synchronisation whatsoever.
> 
>> I mean as per current test, swing UI components are accessed on EDT and then the comparison is done on main thread.
>> 
>> Curious to know what we achieve extra by doing the way you suggested above?
> 
> What do we achieve by separating painting and comparing?
> 
> There's no way that's the only right one. Both do the same. Yet a single test-method which does everything is easier to understand: set look-and-feel, get a progress bar, paint it with and without border and, finally, compare the images. I'm always for this style.
> 
> When dealing with multiple threads you have to pass objects between threads; to do so, you store them as static fields — it somewhat complicates the data flow.
> 
> However, there's still one advantage to this — a clearer exception about the failure.

Sounds good.
Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400938186