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.
