[concurrency-interest] ThreadLocal.getIfPresent()

Peter Levart peter.levart at gmail.com
Thu Jun 7 03:16:37 EDT 2018



On 06/07/18 07:24, James Roper wrote:
> On Thu, 7 Jun 2018 at 05:28, Peter Levart via Concurrency-interest 
> <concurrency-interest at cs.oswego.edu 
> <mailto: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?

Yes, if that library doesn't expose the ThreadLocal API to the user 
directly, it could simply rename the conflicting method internally. Even 
if it does expose ThreadLocal API directly, there are four cases:

1 - It exposes a ThreadLocal subtype with public boolean isPresent() 
method: the users of that API are already aware of the semantics of that 
method - introducing ThreadLocal.isPresent does not break them
2 - It exposes a ThreadLocal type, but internally uses a subtype with 
public boolean isPresent() method: internal code is already aware of the 
semantics of that method - introducing ThreadLocal.isPresent does not 
break it
3 - It exposes a ThreadLocal subtype with public but 
override-incompatible isPresent() method (say: int isPresent()): this is 
binary compatible, but source incompatible. This is the only case with 
no easy way out as both the library and the clients of that library 
would have to be upgraded at the same time to be compiled with newer JDK.
4- It exposes a ThreadLocal type, but internally uses a subtype with 
override-incompatible or linkage-incompatible isPresent() method: the 
library can fix internal wiring without braking public API

So case 3 is the only really incompatible case. Which is highly 
unlikely, because of the java beans naming convention. A no-arg instance 
method called isXyz() typically has boolean return type.

Regards, Peter

>
>     The risk can be avoided entirely with a static method taking a
>     ThreadLocal instance. But static method is not so nice-looking
>     when called... :-(
>
>
>
>     Peter
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> -- 
> *James Roper*
> /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...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180607/eef5614f/attachment.html>


More information about the Concurrency-interest mailing list