Adding Doug Lea.
On 11/02/2015 12:51 AM, Paul Sandoz wrote:
On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hega...@oracle.com> wrote:
Adding native methods to 166 classes will introduce another form of dependency
on the platform that i would prefer to avoid.
Right. And I suspect that the separate distributable of 166, outside of the
Java Platform, would not want to have to carry a separate platform specific
native library.
Yes.
Right and for that reason jsr166 distribution would not want to have to
know whether to use Thread or Unsafe.
But I don't see any reason why we couldn't move the implementation from unsafe.cpp to
jvm.cpp and invoke via a native method implementation of LockSupport. It would still be
just as "unsafe" of course.
Can you think of any reasons, beyond that of "don't touch the core classes",
why we cannot copy this functionality over to java.lang.{*, Thread} ?
Would you be thinking of making the changes public, i.e. new standard API on
java.lang.Thread ?
Yes, j.l.Thread seems like the ideal location :-)
I don't see any point in moving it to Thread now. The public supported
API already exists in LockSupport. As I said you'd have to deprecate it
in 9 with an intent to remove in 10 - assuming you are even allowed to
do that.
The issue is not LockSupport versus Thread, but the use of Unsafe.
David
Paul.
