RFR: 8224261: JProgressBar always with border painted around it [v3]
Abhishek Kumar
abhiscxk at openjdk.org
Tue Nov 21 17:34:28 UTC 2023
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
More information about the client-libs-dev
mailing list