You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rory O'Donnell <ro...@oracle.com> on 2020/12/13 17:06:14 UTC
JDK 16 is in Rampdown Phase One
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-dev@openjdk.java.net
<ma...@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
Re: JDK 16 is in Rampdown Phase One
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Dec 14, 2020 at 10:08 AM Rémy Maucherat <re...@apache.org> wrote:
> On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi Tomcat team,
> >
> > The following tests fail on JDK 16 b28:
> >
> > [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)
> >
>
> The changelog does say it's tightening up this sort of stuff, so I guess
> it's working just fine ! For now, I'll add the exception to the list of
> caught exceptions.
>
This fixed the old failure. Now it prints a WARNING with the same message
as before.
But the next problem is:
14-Dec-2020 08:41:48.999 INFO [main]
org.apache.catalina.core.StandardService.stopInternal Stopping service
[Tomcat]
Exception in thread "pool-1-thread-2" java.lang.IllegalMonitorStateException
at
java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175)
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006)
at
java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494)
at
java.base/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:831)
14-Dec-2020 08:41:49.000 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["http-nio-127.0.0.1-auto-1-37203"]
Exception in thread "pool-1-thread-4" java.lang.IllegalMonitorStateException
at
java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175)
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006)
at
java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494)
at
java.base/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:831)
Exception in thread "pool-1-thread-5" java.lang.IllegalMonitorStateException
at
java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175)
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006)
at
java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494)
at
java.base/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:831)
Exception in thread "pool-1-thread-3" java.lang.IllegalMonitorStateException
at
java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175)
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006)
at
java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494)
at
java.base/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:831)
Exception in thread "pool-1-thread-1" java.lang.IllegalMonitorStateException
at
java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175)
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006)
at
java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494)
at
java.base/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:831)
14-Dec-2020 08:41:49.046 INFO [main]
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
["http-nio-127.0.0.1-auto-1-37203"]
------------- ---------------- ---------------
Testcase: testTimerThreadLeak took 4.306 sec
FAILED
null
junit.framework.AssertionFailedError
at
org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.testTimerThreadLeak(TestWebappClassLoaderExecutorMemoryLeak.java:63)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Again the same test classes fail with this new error.
> Rémy
>
>
> >
> > Regards,
> > Martin
> >
> > On Sun, Dec 13, 2020 at 7:08 PM Rory O'Donnell <rory.odonnell@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-dev@openjdk.java.net
> > > <ma...@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
> > >
> > >
> >
>
Re: JDK 16 is in Rampdown Phase One
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov <mg...@apache.org>
wrote:
> Hi Tomcat team,
>
> The following tests fail on JDK 16 b28:
>
> [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)
>
The changelog does say it's tightening up this sort of stuff, so I guess
it's working just fine ! For now, I'll add the exception to the list of
caught exceptions.
Rémy
>
> Regards,
> Martin
>
> On Sun, Dec 13, 2020 at 7:08 PM Rory O'Donnell <ro...@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-dev@openjdk.java.net
> > <ma...@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
> >
> >
>
Re: JDK 16 is in Rampdown Phase One
Posted by Rory O'Donnell <ro...@oracle.com>.
Thanks Martin!
On 15/12/2020 15:35, Martin Grigorov wrote:
> Hi Rory,
>
> We added some --add-opens to Tomcat and now the build and tests pass
> with JDK 16 b28 on both x86_64 and aarch64, Ubuntu 20.04!
>
> https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486
> <https://urldefense.com/v3/__https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486__;!!GqivPVa7Brio!OnR8Q8bPA6rf9NITrgbTiU4j6936950KweOq43IDMdFU9xtWDG2awGCucKD-lA-X_Ng$>
> https://github.com/apache/tomcat/commit/61f4baf64c69c5fd738d34b6139eda4549258cea
> <https://urldefense.com/v3/__https://github.com/apache/tomcat/commit/61f4baf64c69c5fd738d34b6139eda4549258cea__;!!GqivPVa7Brio!OnR8Q8bPA6rf9NITrgbTiU4j6936950KweOq43IDMdFU9xtWDG2awGCucKD-Sgzupbo$>
> https://github.com/apache/tomcat/commit/0a2ee9b1ba7ded327c2aa2361cccff6a16cdef84
> <https://urldefense.com/v3/__https://github.com/apache/tomcat/commit/0a2ee9b1ba7ded327c2aa2361cccff6a16cdef84__;!!GqivPVa7Brio!OnR8Q8bPA6rf9NITrgbTiU4j6936950KweOq43IDMdFU9xtWDG2awGCucKD-k9xbzm4$>
>
> On Mon, Dec 14, 2020 at 9:52 AM Martin Grigorov <mgrigorov@apache.org
> <ma...@apache.org>> wrote:
>
> Hi Tomcat team,
>
> The following tests fail on JDK 16 b28:
>
> [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.odonnell@oracle.com <ma...@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
> <https://urldefense.com/v3/__http://jdk.java.net/16__;!!GqivPVa7Brio!OnR8Q8bPA6rf9NITrgbTiU4j6936950KweOq43IDMdFU9xtWDG2awGCucKD-98DvmIs$>
>
> * 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
> <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
> <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
> <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
> <https://cr.openjdk.java.net/~briangoetz/amber/datum.html>>.
> + Refines JEP 360 <https://openjdk.java.net/jeps/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
> <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/
> <https://urldefense.com/v3/__http://jdk.java.net/loom/__;!!GqivPVa7Brio!OnR8Q8bPA6rf9NITrgbTiU4j6936950KweOq43IDMdFU9xtWDG2awGCucKD-x5MQUtY$>>*
> (2020/11/30) - based on JDK-16+25
> <https://github.com/openjdk/jdk/releases/tag/jdk-16%2B25
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/releases/tag/jdk-16*2B25__;JQ!!GqivPVa7Brio!OnR8Q8bPA6rf9NITrgbTiU4j6936950KweOq43IDMdFU9xtWDG2awGCucKD-DPhGbgQ$>>
>
> * 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
> <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-dev@openjdk.java.net <ma...@openjdk.java.net>
> <mailto:loom-dev@openjdk.java.net
> <ma...@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
> <http://mail.openjdk.java.net/mailman/listinfo/loom-dev>>.
>
> Rgds, Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-December/004991.html
> <https://mail.openjdk.java.net/pipermail/jdk-dev/2020-December/004991.html>
> [2] https://jdk.java.net/16/release-notes
> <https://urldefense.com/v3/__https://jdk.java.net/16/release-notes__;!!GqivPVa7Brio!OnR8Q8bPA6rf9NITrgbTiU4j6936950KweOq43IDMdFU9xtWDG2awGCucKD-LgmMIxs$>
>
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
Re: JDK 16 is in Rampdown Phase One
Posted by Martin Grigorov <mg...@apache.org>.
Hi Rory,
We added some --add-opens to Tomcat and now the build and tests pass with
JDK 16 b28 on both x86_64 and aarch64, Ubuntu 20.04!
https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486
https://github.com/apache/tomcat/commit/61f4baf64c69c5fd738d34b6139eda4549258cea
https://github.com/apache/tomcat/commit/0a2ee9b1ba7ded327c2aa2361cccff6a16cdef84
On Mon, Dec 14, 2020 at 9:52 AM Martin Grigorov <mg...@apache.org>
wrote:
> Hi Tomcat team,
>
> The following tests fail on JDK 16 b28:
>
> [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 <ro...@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-dev@openjdk.java.net
>> <ma...@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
>>
>>
Re: JDK 16 is in Rampdown Phase One
Posted by Rémy Maucherat <re...@apache.org>.
On Tue, Dec 15, 2020 at 1:52 PM Martin Grigorov <mg...@apache.org>
wrote:
> Hi Rémy,
>
> On Mon, Dec 14, 2020 at 10:51 PM Mark Thomas <ma...@apache.org> wrote:
>
> > On 14/12/2020 11:06, Martin Grigorov wrote:
> > > On Mon, Dec 14, 2020 at 12:30 PM Rémy Maucherat <re...@apache.org>
> wrote:
> > >
> > >> On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov <mgrigorov@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 ...]
> > >>
> > >
> > > One can work it around by adding --add-opens=java.base/java.
> > > <http://java.io/>util.concurrent=ALL-UNNAMED to the JVM arguments
> > > I am not sure whether some module-info.java hackery can make it better.
> >
> > This is what we currently do:
> >
> > https://github.com/apache/tomcat/blob/master/bin/catalina.sh#L313
> >
> > (and the same for .bat). Looks like we need to add another entry there.
> >
>
> Your fix
> <
> https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486
> >
> does not solve the issue for me. Do the tests pass for you with JDK 16 b28
> ?
>
> diff --git build.xml build.xml
> index 2c2b532..2c1a54f 100644
> --- build.xml
> +++ build.xml
> @@ -220,7 +220,7 @@
> <property name="java9.test.option.3" value="-Dtest.3=3"/>
> <available classname="java.lang.reflect.InaccessibleObjectException"
> property="java9.test.option.4"
> - value="--add-opens=java.base/java.util=ALL-UNNAMED"/>
> +
> value="--add-opens=java.base/java.util.concurrent=ALL-UNNAMED"/>
> <property name="java9.test.option.4" value="-Dtest.4=4"/>
>
> ^^ this fixes them!
>
Bad luck, one needs java.uti, the other one java.util.concurrent.
OTOH, I have no idea why anyone cares ...
Rémy
Re: JDK 16 is in Rampdown Phase One
Posted by Martin Grigorov <mg...@apache.org>.
Hi Rémy,
On Mon, Dec 14, 2020 at 10:51 PM Mark Thomas <ma...@apache.org> wrote:
> On 14/12/2020 11:06, Martin Grigorov wrote:
> > On Mon, Dec 14, 2020 at 12:30 PM Rémy Maucherat <re...@apache.org> wrote:
> >
> >> On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov <mg...@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 ...]
> >>
> >
> > One can work it around by adding --add-opens=java.base/java.
> > <http://java.io/>util.concurrent=ALL-UNNAMED to the JVM arguments
> > I am not sure whether some module-info.java hackery can make it better.
>
> This is what we currently do:
>
> https://github.com/apache/tomcat/blob/master/bin/catalina.sh#L313
>
> (and the same for .bat). Looks like we need to add another entry there.
>
Your fix
<https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486>
does not solve the issue for me. Do the tests pass for you with JDK 16 b28 ?
diff --git build.xml build.xml
index 2c2b532..2c1a54f 100644
--- build.xml
+++ build.xml
@@ -220,7 +220,7 @@
<property name="java9.test.option.3" value="-Dtest.3=3"/>
<available classname="java.lang.reflect.InaccessibleObjectException"
property="java9.test.option.4"
- value="--add-opens=java.base/java.util=ALL-UNNAMED"/>
+
value="--add-opens=java.base/java.util.concurrent=ALL-UNNAMED"/>
<property name="java9.test.option.4" value="-Dtest.4=4"/>
^^ this fixes them!
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: JDK 16 is in Rampdown Phase One
Posted by Mark Thomas <ma...@apache.org>.
On 14/12/2020 11:06, Martin Grigorov wrote:
> On Mon, Dec 14, 2020 at 12:30 PM Rémy Maucherat <re...@apache.org> wrote:
>
>> On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov <mg...@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 ...]
>>
>
> One can work it around by adding --add-opens=java.base/java.
> <http://java.io/>util.concurrent=ALL-UNNAMED to the JVM arguments
> I am not sure whether some module-info.java hackery can make it better.
This is what we currently do:
https://github.com/apache/tomcat/blob/master/bin/catalina.sh#L313
(and the same for .bat). Looks like we need to add another entry there.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: JDK 16 is in Rampdown Phase One
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Dec 14, 2020 at 12:30 PM Rémy Maucherat <re...@apache.org> wrote:
> On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov <mg...@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 ...]
>
One can work it around by adding --add-opens=java.base/java.
<http://java.io/>util.concurrent=ALL-UNNAMED to the JVM arguments
I am not sure whether some module-info.java hackery can make it better.
>
> 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.odonnell@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-dev@openjdk.java.net
> > > <ma...@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
> > >
> > >
> >
>
Re: JDK 16 is in Rampdown Phase One
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov <mg...@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 <ro...@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-dev@openjdk.java.net
> > <ma...@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
> >
> >
>
Re: JDK 16 is in Rampdown Phase One
Posted by Martin Grigorov <mg...@apache.org>.
Hi Tomcat team,
The following tests fail on JDK 16 b28:
[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 <ro...@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-dev@openjdk.java.net
> <ma...@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
>
>