Yes, it will be much harder to audit that the correct constructor
has been used, so it needs to be a reviewer checklist item.
-phil.
On 4/3/16, 9:49 AM, Sergey Bylokhov wrote:
The fix looks fine, but we will need to use correct Thread
constructor, it will not easy tracked unlike the usage of separate class.
On 03.04.16 18:24, Chris Hegarty wrote:
On 1 Apr 2016, at 23:19, Phil Race <philip.r...@oracle.com> wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8147544
Fix: http://cr.openjdk.java.net/~prr/8147544/
Your changes look ok to me. Thanks for doing this Phil.
-Chris.
ManagedLocalThreads is now superseded by a standard
constructor on java.lang.Thread :-
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc
The various places in JDK that use the internal API need to migrate
to this.
This fix addresses all (I hope) such usages in java.desktop.
I had to invent names for threads in numerous places since
the required constructor insists on one.
Most uses install a Runnable but in about 4 cases we need to extend
Thread.
In those cases I added a comment, and in some cases a private no-args
constructor() to try to guard against anyone coming along later and
accidentally
adding & calling a wrong super-class constructor.
JPRT has been used to verify the build on all platforms and I am
in the process of running some sanity checks on the major
platforms to make sure nothing unexpected happens but
in general real testing of all of these changes is going to only happen
with a nearly full test run, so the earlier the better to get the
changes in.
-phil.
