<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 02/11/2022 00:03, Carter Kozak
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:d8605189-7a7b-469c-ac28-68ff218760ff@app.fastmail.com">
      
      <title></title>
      <style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
      <div>:<br>
        <div><br>
        </div>
      </div>
      <div>This is an interesting point. I'm not sure I understand why
        the introduction of virtual threads is the best place to make
        the ThreadLocal language feature configurable, but I'd
        appreciate additional context.<br>
      </div>
      <div>The JEP describes the motivation for the dynamic
        configuration of ThreadLocals, as well as an alternative
        (jep-429 scoped values), however the behavior seems (to an
        outsider) to oppose the higher-level design of virtual threads
        which are meant to be otherwise a drop-in replacement for
        platform threads. I'd much rather fail predictably (or in a way
        the compiler can warn me about) rather than when a legacy
        function compiled with jdk1.5 executes on a particular type of
        thread.<br>
      </div>
    </blockquote>
    <br>
    Virtual threads are not meant to be a drop-in replacement like this,
    you wouldn't want to end up pooling virtual threads. As I said, the
    question on whether we should continue to allow opt-out of thread
    locals when creating threads is an issue where more feedback is
    required. Right now, if you opt-out then then some code that using
    TLs will fail at run-time, which of course is not desirable. Another
    option on the table at the time was for TL.set (the only method that
    throws) to be a no-op so that TL.get always returns the initial
    value. Related is that the option to opt out of inheriting the
    initial value of inhertable-TLs has been there since Java 9.
    Inheritable TLs aren't widely used of course but it is an example of
    something related that is not limited to the thread kind.<br>
    <br>
    I don't think a warning at compile time is feasible here as
    libraries on the class or module path will be a mix of class file
    versions. The code that creates the threads may be a different
    library to code that is making a lot of use of TLs.<br>
    <br>
    -Alan<br>
  </body>
</html>