On Tue, 21 Nov 2023 17:12:44 GMT, Alexey Ivanov <[email protected]> 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
