RFR: 8224261: JProgressBar always with border painted around it [v3]
Alexey Ivanov
aivanov at openjdk.org
Tue Nov 21 17:16:11 UTC 2023
On Tue, 21 Nov 2023 16:47:10 GMT, Abhishek Kumar <abhiscxk 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?
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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400918028
More information about the client-libs-dev
mailing list