Looks ok to me, will take care of it in standalone project.
Thanks Miran On 08/02/16 17:20, Chris Hegarty wrote:
Receiving some feedback off list, this code needs to be able to run on older releases, so the new Thread constructor, added in JDK 9, should be accessed reflectively. Webrev updated in-place: http://cr.openjdk.java.net/~chegar/8148861/ -Chris. On 8 Feb 2016, at 10:52, Chris Hegarty <chris.hega...@oracle.com> wrote:Miran, JDK-8056152 added a new constructor to java.lang.Thread for constructing Threads that do not inherit inheritable thread-local initial values. All usages of sun.misc.ManagedLocalsThread in the base module were also replaced with this new constructor. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it, where applicable. If all usages are replaced, then sun.misc.ManagedLocalsThread can be removed. The following patch, along with 'hg rm ThreadHelper.java', should be sufficient. It will remove the dependency on an internal JDK API, but adds a new dependency on Java SE 9. Is this OK, or does this code need to access the new Java SE 9 constructor using refection? diff --git a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java --- a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java +++ b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java @@ -108,7 +108,8 @@ } public Thread newThread(Runnable r) { - Thread t = ThreadHelper.createNewThread(r); - t.setName(namePrefix + threadNumber.getAndIncrement()); + Thread t = new Thread(null, r, namePrefix + threadNumber.getAndIncrement(), 0, false); t.setName(namePrefix + threadNumber.getAndIncrement()); if (!t.isDaemon()) { t.setDaemon(true); Complete webrev: http://cr.openjdk.java.net/~chegar/8148861/ Is is possible, when agreed, to get this small change pushed upstream ? -Chris.
