On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov <mgrigo...@apache.org> wrote:
> Hi Tomcat team, > > The following tests fail on JDK 16 b28: > Ok, so I installed JDK 16 and tested. No issues overall, nice ! About this particular one however, the proper exceptions are now caught and everything (so it's "ok") but it's not possible to make the functionality work anymore by default. So the executor and its threads are still hanging, causing the assertions to fail [as well as the traces when stopping the blocked threads]. Should we relax module security somehow to allow the fields setAccessible(true) to work again ? [that doesn't sound like a great plan to me ...] Rémy > > [concat] Testsuites with failed tests: > [concat] > > TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.APR.txt > [concat] > > TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO.txt > [concat] > > TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO2.txt > [concat] > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.APR.txt > [concat] > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO.txt > [concat] > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO2.txt > > > with this reason: > > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make > field final java.util.concurrent.ThreadPoolExecutor > java.util.concurrent.ThreadPoolExecutor$Worker.this$0 accessible: module > java.base does not "opens java.util.concurrent" to unnamed module @80503 > at > > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357) > at > > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) > at > java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177) > at java.base/java.lang.reflect.Field.setAccessible(Field.java:171) > at > > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads(WebappClassLoaderBase.java:1798) > at > > org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1622) > at > > org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1554) > at > org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:461) > at > org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) > > Regards, > Martin > > On Sun, Dec 13, 2020 at 7:08 PM Rory O'Donnell <rory.odonn...@oracle.com> > wrote: > > > Hi Mark, > > > > *Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] . > > * > > > > *Please advise if you find any issues while testing the latest Early > > Access builds.* > > > > * Schedule for JDK 16 > > o *2020/12/10 Rampdown Phase One* > > o 2021/01/14 Rampdown Phase Two > > o 2021/02/04 Initial Release Candidate > > o 2021/02/18 Final Release Candidate > > o 2021/03/16 General Availability > > * Release Notes [2] > > > > OpenJDK 16 Early Access build 28**is now available at > > http://jdk.java.net/16 > > > > * Features - the overall feature set is frozen. No further JEPs will > > be targeted to this release. > > * Significant Integrations in b28: > > o *Integrated JEP 396: **Strongly Encapsulate JDK Internals by > > Default <https://openjdk.java.net/jeps/396>** > > * > > + Strongly encapsulate all internal elements of the JDK by > > default, except for critical internal APIs > > <https://openjdk.java.net/jeps/260#Description> such as > > |sun.misc.Unsafe|. > > + Allow end users to choose the relaxed strong encapsulation > > that has been the default since JDK 9. > > o Integrated JEP 397: Sealed Classes (Second Preview) > > <https://openjdk.java.net/jeps/397> with this release. > > + Enhance the Java programming language with sealed classes > > and interfaces > > <https://cr.openjdk.java.net/~briangoetz/amber/datum.html>. > > + Refines JEP 360 <https://openjdk.java.net/jeps/360> which > > was delivered in JDK 15 as a preview feature. > > > > * These early-access , open-source builds are provided under the GNU > > General Public License, version 2, with the Classpath Exception > > <http://openjdk.java.net/legal/gplv2+ce.html>. > > * Changes in recent builds that maybe of interest: > > o Build 28 > > + JDK-8256299: JEP 396: Strongly Encapsulate JDK Internals by > > Default > > + JDK-8166596: TLS support for the EdDSA signature algorithm > > + JDK-8256718: Old tracing flags are now obsolete and must be > > replaced with unified logging > > o Build 27 > > + JDK-8159746: (proxy) Support for default methods > > + JDK-8254631: Better support ALPN byte wire values in SunJSSE > > > > Project Loom Early-Access: *Build 16-loom+9-316 > > <http://jdk.java.net/loom/>* (2020/11/30) - based on JDK-16+25 > > <https://github.com/openjdk/jdk/releases/tag/jdk-16%2B25> > > > > * These early-access builds are provided under the GNU General Public > > License, version 2, with the Classpath Exception > > <http://openjdk.java.net/legal/gplv2+ce.html> > > * These builds are intended for developers looking to "kick the tyres" > > and provide feedback on using the API or by sending bug reports. > > * Please send feedback via e-mail to loom-...@openjdk.java.net > > <mailto:loom-...@openjdk.java.net>. To send e-mail to this address > > you must first subscribe to the mailing list > > <http://mail.openjdk.java.net/mailman/listinfo/loom-dev>. > > > > Rgds, Rory > > > > [1] > > > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-December/004991.html > > [2] https://jdk.java.net/16/release-notes > > > > >
