Clock as ThreadLocal

[pmihalcin]

Hi Michael, This usage of Clock as ThreadLocal is very interesting.

From my perspective, advantage of using it this way doesn't force you to pass Clocks in methods and have it as a @Bean I'm not sure how it is aligned with DDD side of things.. isn't it some kind of global state?

How would you summarize positive and negative aspects of using it in such way? Are there any other situations you would use ThreadLocal for?

Thanks a lot for any feedback, Patrik

[michael-simons]

Hi Patrik,

I see exactly the same advantage as you do: I didn't want to pass it around in any way. It is indeed some kind of global state but immutable state. True, it's changeable, but that would defy it's intended usage. The state is used as an internal reference regarding what is "now."

Positive aspect is: Keeping the surface of things as small as possible.

Negative aspect is: Would be hard to move such an implementation into a reactive application, as there would be no ThreadLocal. Depending on the framework used, one would have to do this with a context provided by the framework.

TBH: I probably have used ThreadLocal about 4 or 5 times the last 10 years. Too much "high-level" programming. Stuff like SecurityContextHolder in Spring Security is based on it and other stuff like that, so I probably have used it several times more, but indirect.

Thanks a lot for your feedback and question. Much appreciated. Michael.