It's refreshing to watch someone talking about programming topics in such relaxing manner and surroundings. Feels so different from the majority of other dev channels and conference talks. That's what java is all about - no hurry, steady improvement. Some other java champions also get it (ones like Adam Bien and Sebastian Daschner). And this video makes me want to grab a cup of coffee myself too. Thanks.
Nice talk. I was playing with ScopedValues and I found that the scoped values are not automatically accessible from child threads. Only Child threads from StructuredTaskScope seems to be able to access the ScopedValue of the parent. When i looked at the code, StructuredTaskScope class does seem to capture all ScopedValue of parent and manually pass it to children of StructuredTaskScope. Its probably because the StructuredTaskScope block is guaranteed to end before the scoped value scope ends. Otherwise the scoped value would be accessible even after the ScopedValue block ends.
Thanks for the explanation! Looking forward to seeing how this will mix & match with the current MDC objects that are currently used to pass valued for logging frameworks, if they can be used there. I hadn't thought that ThreadLocal was for security reasons, I had always thought it was to be able to pass values to code that were not direclty in the call chain, hence no parameters prepared to pass them, so, good to know.
Nice feature to come. How will a scoped value behave when using a thread pool executor ? You spawn the tasks from your context but the threads they run on are created out of those bounds. Should we then care about how an executor work ?
Thanks for the great explanation of both ThreadLocal and ScopedValue APIs. I can't help but notice similarity between ScopedValue APIs and various Mapped Diagnostic Context APIs provided by java logging frameworks like SLF4J/Log4j. I assume that is a deliberate design choice/inspiration here?
I think he mentioned it's more like "methodLocal". It sounds like it's only scoped to a method. So, it sounds like it's not a replacement for ThreadLocal
public class ScopedValueHolder { private static final ScopedValue foo = ScopedValue.newInstance(); public static ScopedValue getFoo() { return foo; } } Something like this for example? If i'm understanding correctly the video it's exactly like ThreadLocal, it's just that outside the designated scope you won't see any value.
@@TheHeartOfTheEvil If it's static and final, why not simply make it public and skip the method altogether? Unless you want to log/control usage... ¯\_(ツ)_/¯ The difference with ThreadLocal is that they are immutable and there is no set or indiscriminate copy when spawning a new thread, you can just bound them for a method call with where, so no set/remove either.
You can write it in that way if you want. But unless you have bound a null value to your KEY (not sure it's a great idea!), KEY.get() cannot return null. If KEY is unbound KEY.get() throws a NoSuchElementException.
Hi @Java, first thank you Jose for a great lecture, a question if I may, one of the main reason for a spring developer to use threadLocal is the infamous ObjectMapper with its heavy constructor, so by wrapping the OM in TL var the servlet threads will have it and will not need to re-build it every time, how would you achieve the same effect with a ScopeValue variable? Keep in mind OM can be access from multiple locations during the rest call
just fyi: ObjectMapper is thread-safe and does not require a ThreadLocal at all. From the docs: "Mapper instances are fully thread-safe provided that ALL configuration of the instance occurs before ANY read or write calls."
I hope the world has so much coffee that we can always see you and benefit from your knowledge.🌻
😂Thank you!
It's refreshing to watch someone talking about programming topics in such relaxing manner and surroundings. Feels so different from the majority of other dev channels and conference talks. That's what java is all about - no hurry, steady improvement. Some other java champions also get it (ones like Adam Bien and Sebastian Daschner). And this video makes me want to grab a cup of coffee myself too. Thanks.
Wow, I was not aware this TH-cam channel exists. Great content! Thank you for your work!
Glad you enjoy it!
I really like the format of these. I haven't chatted about coding in a coffee shop since before Covid and I miss it!
Very illustrative examples around the 16th min. Many thanks!
Nice talk. I was playing with ScopedValues and I found that the scoped values are not automatically accessible from child threads. Only Child threads from StructuredTaskScope seems to be able to access the ScopedValue of the parent. When i looked at the code, StructuredTaskScope class does seem to capture all ScopedValue of parent and manually pass it to children of StructuredTaskScope. Its probably because the StructuredTaskScope block is guaranteed to end before the scoped value scope ends. Otherwise the scoped value would be accessible even after the ScopedValue block ends.
Wonderful explanation even non native english users can understand very clearly.
Thanks for that.
Thanks for the explanation! Looking forward to seeing how this will mix & match with the current MDC objects that are currently used to pass valued for logging frameworks, if they can be used there.
I hadn't thought that ThreadLocal was for security reasons, I had always thought it was to be able to pass values to code that were not direclty in the call chain, hence no parameters prepared to pass them, so, good to know.
Awesome as always!
Thank you! Cheers!
Thanks for this great insight José !
Glad you enjoyed it!
Nice presentation ! Thought it was InheritableThreadLocal that got copied when making a child thread and not ThreadLocal. Isn’t it ?
I'm curious to know how this is implemented. Does it look at the call stack to determine if the ScopedValue is accessible?
Where can one buy this cup?
Loom is cool but what I am most excited about is Valhalla (and Panama second).
Is ScopedValue analogous to the Reader Monad in Haskell?
Nice feature to come.
How will a scoped value behave when using a thread pool executor ?
You spawn the tasks from your context but the threads they run on are created out of those bounds.
Should we then care about how an executor work ?
Thanks for the great explanation of both ThreadLocal and ScopedValue APIs. I can't help but notice similarity between ScopedValue APIs and various Mapped Diagnostic Context APIs provided by java logging frameworks like SLF4J/Log4j. I assume that is a deliberate design choice/inspiration here?
Kinda confusing - how can this ScopedValue be used across different classes? (as we are using TthreadLocal right now)
I think he mentioned it's more like "methodLocal". It sounds like it's only scoped to a method.
So, it sounds like it's not a replacement for ThreadLocal
Public static field in a common class i guess?
But not sure if that is the best use case for it.
public class ScopedValueHolder {
private static final ScopedValue foo = ScopedValue.newInstance();
public static ScopedValue getFoo() {
return foo;
}
}
Something like this for example? If i'm understanding correctly the video it's exactly like ThreadLocal, it's just that outside the designated scope you won't see any value.
@@TheHeartOfTheEvil If it's static and final, why not simply make it public and skip the method altogether? Unless you want to log/control usage... ¯\_(ツ)_/¯
The difference with ThreadLocal is that they are immutable and there is no set or indiscriminate copy when spawning a new thread, you can just bound them for a method call with where, so no set/remove either.
12:30 shouldn't it be "ABC".equals(KEY.get()) instead?
You can write it in that way if you want. But unless you have bound a null value to your KEY (not sure it's a great idea!), KEY.get() cannot return null. If KEY is unbound KEY.get() throws a NoSuchElementException.
Hi @Java, first thank you Jose for a great lecture, a question if I may, one of the main reason for a spring developer to use threadLocal is the infamous ObjectMapper with its heavy constructor, so by wrapping the OM in TL var the servlet threads will have it and will not need to re-build it every time, how would you achieve the same effect with a ScopeValue variable? Keep in mind OM can be access from multiple locations during the rest call
just fyi: ObjectMapper is thread-safe and does not require a ThreadLocal at all.
From the docs: "Mapper instances are fully thread-safe provided that ALL configuration of the instance occurs before ANY read or write calls."
seemed too complicated somehow
10:50 - 11:00 :
How much blood does this man have in his coffee?
why threadlocal are global variables? As i understand global is static in java but threadlocal not static!
ScopedValue is great!
Very informative presentation. Thanks for publishing.
💚💙💛💜🧡❤❤🩹