On 02/22/2016 12:11 PM, mark.reinh...@oracle.com wrote:
2016/1/28 9:25 -0800, g...@azul.com:
This thread seems to have "hopped away" to the concurrency-interest
list in mid-Dec-2015. This posting is intended to capture a summary of
reasoning and some of the discussion there so that we have it in the
record in core-libs-dev. Mostly by including the contents of several
posts in the continuations of the original thread.
See thread continuations here:
http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14576
and here:
http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14580
Summary:
...
Thanks for the summary.
I still don't buy the argument that this method belongs in j.l.Runtime.
To say that this method should go there because it's an instruction to
the run-time system is pretty weak. I agree with Vitaly [1] that if
that's the threshold for adding methods to the Runtime class then lots
of other stuff belongs there as well, including much of what's now in
java.lang.Thread and java.util.concurrent and, arguably, anything else
related to interacting with the environment in which the application
runs (file and network I/O, process manipulation, etc.).
This thread-related method really belongs in either java.lang.Thread or
java.util.concurrent.LockSupport. j.l.Thread already has plenty of
expert-level static methods related to the current thread, one of which
(Thread::yield) is even a hint, just like this one. j.u.c.LockSupport
is even more obviously intended for expert users and hence may be the
best choice, but I could live with either one.
I agree, and I would also point out (perhaps redundantly?) that there
was talk on concurrency-interest of possibly relocating or replicating
the park/unpark statics into j.l.Thread, which further strengthens the
idea that Thread is the best place for things like this.
--
- DML
