On Thu, 29 Aug 2024 12:42:49 GMT, Alexey Ivanov <[email protected]> wrote:
>>> > One slight concern is that, does GTKStockIcon has any role to play with >>> > synchronized block? >>> >>> Sorry, I didn't understand what do you mean. >> >> I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering >> does that make any difference or need for the map to be synchronized? I also >> came across Immutable Maps which are inherently thread safe. If ICONS_MAP >> are immutable one, then Synchronized block is definitely redundant. > >> > > One slight concern is that, does GTKStockIcon has any role to play with >> > > synchronized block? >> > >> > >> > Sorry, I didn't understand what do you mean. >> >> I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering >> does that make any difference or need for the map to be synchronized? > > In fact, `synchronized` block around `ICONS_MAP.get` had no effect. > > To be correct, the value for `ICONS_MAP` had to be assigned inside a > `synchronized` block too. Otherwise, it is not thread-safe. > >> I also came across Immutable Maps which are inherently thread safe. If >> ICONS_MAP are immutable one, then Synchronized block is definitely redundant. > > Effectively, `ICONS_MAP` is an immutable map. It's initialised in a static > initialiser and is never modified afterwards. > > As far as I can tell, `GTKStockIcon` objects stored in the map aren't > modified either. > > Thus, the entire structure is immutable and is thread-safe without additional > synchronisation. > @aivanov-jdk I guess `Maps.of` can't be used here because there are few > elements put inside a map after `tk.checkGtkVersion(3, 10, 0)` condition… It's possible to use `Map.of` if you put the condition as a conditional operator to each value. Yet it would make the intention less clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2321574112
