james at lightbend.com
Thu Jun 7 01:24:36 EDT 2018
On Thu, 7 Jun 2018 at 05:28, Peter Levart via Concurrency-interest <
concurrency-interest at cs.oswego.edu> wrote:
> I think the risk is not so big because ThreadLocal instances are typically
> not publicly exposed. They are usually encapsulated and code accessing them
> "knows" the semantics of the isPresent() method if such method exists in a
> subclass. There is a danger though that such method on an existing subclass
> is not public and not private which would break binary link-ability if such
> public method was added to ThreadLocal...
So what you're saying is if, for example, a popular open source library
uses ThreadLocal, it's likely to be an internal thing, and so the libraries
public API would be completely unimpacted by changes to ThreadLocal. So, if
there was a binary compatibility issue, that open source library would
break with JDK X, but could easily fix it without breaking their own API.
Is that right?
The risk can be avoided entirely with a static method taking a ThreadLocal
> instance. But static method is not so nice-looking when called... :-(
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
*Senior Developer, Office of the CTO*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest