Unsafe.park/unpark, j.u.c.LockSupport and Thread

Paul Sandoz paul.sandoz at oracle.com
Wed Feb 11 10:43:22 UTC 2015


On Feb 11, 2015, at 11:04 AM, David Holmes <david.holmes at oracle.com> wrote:

> Paul,
> 
> I appreciate the issue with discontinuing use of Unsafe but this churn to the public APIs seems unwarranted. Would we have done it differently from day one? Sure. Does that mean we should change it all now? Not without a very good reason. And I'm on the fence there.
> 

Fair enough, i am less conservative than yourself on this matter :-)


> The fact that LockSupport needs access to Thread internals is something that modules could actually resolve :) - though I'm not up to date on the interaction of module access and package access.
> 

In this case 166 is imported into the base module. We don't want modules sitting on top of the platform to depend on internal platform classes, ideally we want to reduce the internal coupling between platform modules (via the use of qualified exports), and ideally the less Unsafe usage within the base module the better.

The particulars of 166 development and usage, in that it gets imported into the platform but also used on top of the platform, make this a tricky balancing act.


> Let's see what Doug thinks of all this too.
> 

Yes.

Paul.



More information about the core-libs-dev mailing list