<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Jep506 on Devops Monk</title><link>https://devops-monk.com/tags/jep506/</link><description>Recent content in Jep506 on Devops Monk</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 10 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://devops-monk.com/tags/jep506/index.xml" rel="self" type="application/rss+xml"/><item><title>Scoped Values (JEP 506): The Final ThreadLocal Replacement</title><link>https://devops-monk.com/tutorials/java25/scoped-values/</link><pubDate>Sun, 10 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/java25/scoped-values/</guid><description>The ThreadLocal Problem ThreadLocal has been the standard way to pass contextual data through a call chain without polluting method signatures since Java 1.2. Every Java developer has seen it used for things like:
Web request context (user ID, correlation ID, tenant ID) Database transaction binding Security principal propagation Logging MDC (Mapped Diagnostic Context) Here is the classic pattern:
public class RequestContext { // ThreadLocal stores one value per thread private static final ThreadLocal&amp;lt;String&amp;gt; CURRENT_USER = new ThreadLocal&amp;lt;&amp;gt;(); public static void set(String userId) { CURRENT_USER.</description></item></channel></rss>