This time really adding Doug Lea :)

On 11/02/2015 11:43 AM, David Holmes wrote:
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.

Reply via email to