You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Rory O'Donnell <ro...@oracle.com> on 2020/12/13 16:39:32 UTC
JDK 16 is in Rampdown Phase One
Hi Martin,
*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 Tue, Dec 15, 2020 at 10:09 AM Emond Papegaaij <em...@gmail.com>
wrote:
> Hi,
>
> Before we go that way, please do some performance tests. We've seen
>
This code is used as a fallback when the class cannot be found in the
webapp class loader. I.e. very rarely.
> very bad performance in StackWalker, especially when it is called many
> times over. This may have improved in more recent JDKs, but in Java 11
> the overhead was so significant that a single StackWalker call in a
> log call would kill the server slowly over time:
> https://issues.redhat.com/browse/LOGMGR-263
>
> Best regards,
> Emond
>
> On Tue, Dec 15, 2020 at 8:45 AM Martin Grigorov <mg...@apache.org>
> wrote:
> >
> > Hi Chris,
> >
> > Thank you for your advices!
> >
> > On Mon, Dec 14, 2020 at 6:11 PM Chris Hegarty <ch...@oracle.com>
> > wrote:
> >
> > >
> > > > On 14 Dec 2020, at 10:03, Rory O'Donnell <ro...@oracle.com>
> > > wrote:
> > > >
> > > > ...
> > > > On 14/12/2020 09:45, Martin Grigorov wrote:
> > > >> Hi Rory,
> > > >>
> > > >> Apache Wicket build and tests are OK with JDK 16 b28 for both
> aarch64
> > > and
> > > >> x86_64 (Ubuntu 20.10)!
> > > >>
> > > >> I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
> > > >> maven-surefire-plugin's JVM arguments because it seems this plugin
> does
> > > not
> > > >> use the (automatic) module name of the Maven project and the JDK
> sees
> > > it as
> > > >> unnamed.
> > > >> And because of this Wicket was not able to install its hooks into
> Java
> > > >> Serialization API.
> > > >>
> > > >>
> > >
> https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzNApXj5k$
> > >
> > > Opening the `java.io` package will of course work, but requires all
> > > deployments of Wicket to do so. Maybe there is a better alternative.
> > >
> > >
> > Actually there is no problem.
> > The unit tests were failing because of 'module java.base does not "opens
> > java.io" to unnamed module'.
> > It seems maven-surefire-plugin does not use the Maven module's
> (automatic)
> > module name while running the tests and the JVM sees it as "unnamed".
> > So, I've added the exception to maven-surefire-plugin's JVM args:
> >
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L1086-L1097
> > If I deploy a .war file to a web container like Apache Tomcat then there
> is
> > no such exception at runtime. I haven't verified but I guess all is fine
> > due to the Automatic-Module-Name in META-INF/MANIFEST.MF (
> >
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L989-L1004
> > )
> >
> >
> > > I see that `org.apache.wicket.serialize.java.JavaSerializer` is using
> > > `setAccessible(true)` to access the private static method
> > > `latestUserDefinedLoader` in `java.io.ObjectInputStream`. There is a
> > > straightforward way of implementing similar functionality with the
> > > standard java.lang.StackWalker API. If you do this, then the
> > > `--add-opens` can probably be dropped.
> > >
> >
> > I will try to improve this with your suggestion!
> >
> > But the problem I solved was for
> >
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/wicket-core/src/main/java/org/apache/wicket/core/util/objects/checker/CheckingObjectOutputStream.java#L251-L282
> > Here Wicket uses Reflection for ObjectStreamClass and ObjectStreamField
> to
> > be able to pinpoint which member field of a Java object is not
> Serializable
> > for debugging purposes.
> >
> >
> > >
> > > Here is an example of such:
> > >
> > > static {
> > > PrivilegedAction<StackWalker> pa1 =
> > > () ->
> > > StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> > > PrivilegedAction<ClassLoader> pa2 =
> > > () -> ClassLoader.getPlatformClassLoader();
> > > STACKWALKER = AccessController.doPrivileged(pa1);
> > > PLATFORM_LOADER = AccessController.doPrivileged(pa2);
> > > }
> > >
> > > /**
> > > * Returns the first non-null and non-platform class loader (not
> > > counting
> > > * class loaders of generated reflection implementation classes)
> up the
> > > * execution stack, or the platform class loader if only code from
> the
> > > * bootstrap and platform class loader is on the stack.
> > > */
> > > private static ClassLoader latestUserDefinedLoader() {
> > > return STACKWALKER.walk(s ->
> > > s.map(StackWalker.StackFrame::getDeclaringClass)
> > > .map(Class::getClassLoader)
> > > .filter(Objects::nonNull)
> > > .filter(cl -> !PLATFORM_LOADER.equals(cl))
> > > .findFirst()
> > > .orElse(PLATFORM_LOADER));
> > > }
> > >
> > > Remove the PrivilegedAction / doPrivileged stuff if not interested in
> > > running with a security manager enabled.
> > >
> > > Let me know if I can do anything further to help.
> > >
> > > -Chris.
> > >
> > >
>
Re: JDK 16 is in Rampdown Phase One
Posted by Emond Papegaaij <em...@gmail.com>.
Hi,
Before we go that way, please do some performance tests. We've seen
very bad performance in StackWalker, especially when it is called many
times over. This may have improved in more recent JDKs, but in Java 11
the overhead was so significant that a single StackWalker call in a
log call would kill the server slowly over time:
https://issues.redhat.com/browse/LOGMGR-263
Best regards,
Emond
On Tue, Dec 15, 2020 at 8:45 AM Martin Grigorov <mg...@apache.org> wrote:
>
> Hi Chris,
>
> Thank you for your advices!
>
> On Mon, Dec 14, 2020 at 6:11 PM Chris Hegarty <ch...@oracle.com>
> wrote:
>
> >
> > > On 14 Dec 2020, at 10:03, Rory O'Donnell <ro...@oracle.com>
> > wrote:
> > >
> > > ...
> > > On 14/12/2020 09:45, Martin Grigorov wrote:
> > >> Hi Rory,
> > >>
> > >> Apache Wicket build and tests are OK with JDK 16 b28 for both aarch64
> > and
> > >> x86_64 (Ubuntu 20.10)!
> > >>
> > >> I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
> > >> maven-surefire-plugin's JVM arguments because it seems this plugin does
> > not
> > >> use the (automatic) module name of the Maven project and the JDK sees
> > it as
> > >> unnamed.
> > >> And because of this Wicket was not able to install its hooks into Java
> > >> Serialization API.
> > >>
> > >>
> > https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzNApXj5k$
> >
> > Opening the `java.io` package will of course work, but requires all
> > deployments of Wicket to do so. Maybe there is a better alternative.
> >
> >
> Actually there is no problem.
> The unit tests were failing because of 'module java.base does not "opens
> java.io" to unnamed module'.
> It seems maven-surefire-plugin does not use the Maven module's (automatic)
> module name while running the tests and the JVM sees it as "unnamed".
> So, I've added the exception to maven-surefire-plugin's JVM args:
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L1086-L1097
> If I deploy a .war file to a web container like Apache Tomcat then there is
> no such exception at runtime. I haven't verified but I guess all is fine
> due to the Automatic-Module-Name in META-INF/MANIFEST.MF (
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L989-L1004
> )
>
>
> > I see that `org.apache.wicket.serialize.java.JavaSerializer` is using
> > `setAccessible(true)` to access the private static method
> > `latestUserDefinedLoader` in `java.io.ObjectInputStream`. There is a
> > straightforward way of implementing similar functionality with the
> > standard java.lang.StackWalker API. If you do this, then the
> > `--add-opens` can probably be dropped.
> >
>
> I will try to improve this with your suggestion!
>
> But the problem I solved was for
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/wicket-core/src/main/java/org/apache/wicket/core/util/objects/checker/CheckingObjectOutputStream.java#L251-L282
> Here Wicket uses Reflection for ObjectStreamClass and ObjectStreamField to
> be able to pinpoint which member field of a Java object is not Serializable
> for debugging purposes.
>
>
> >
> > Here is an example of such:
> >
> > static {
> > PrivilegedAction<StackWalker> pa1 =
> > () ->
> > StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> > PrivilegedAction<ClassLoader> pa2 =
> > () -> ClassLoader.getPlatformClassLoader();
> > STACKWALKER = AccessController.doPrivileged(pa1);
> > PLATFORM_LOADER = AccessController.doPrivileged(pa2);
> > }
> >
> > /**
> > * Returns the first non-null and non-platform class loader (not
> > counting
> > * class loaders of generated reflection implementation classes) up the
> > * execution stack, or the platform class loader if only code from the
> > * bootstrap and platform class loader is on the stack.
> > */
> > private static ClassLoader latestUserDefinedLoader() {
> > return STACKWALKER.walk(s ->
> > s.map(StackWalker.StackFrame::getDeclaringClass)
> > .map(Class::getClassLoader)
> > .filter(Objects::nonNull)
> > .filter(cl -> !PLATFORM_LOADER.equals(cl))
> > .findFirst()
> > .orElse(PLATFORM_LOADER));
> > }
> >
> > Remove the PrivilegedAction / doPrivileged stuff if not interested in
> > running with a security manager enabled.
> >
> > Let me know if I can do anything further to help.
> >
> > -Chris.
> >
> >
Re: JDK 16 is in Rampdown Phase One
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Dec 15, 2020 at 9:49 AM Maxim Solodovnik <so...@gmail.com>
wrote:
> On Tue, 15 Dec 2020 at 14:45, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi Chris,
> >
> > Thank you for your advices!
> >
> > On Mon, Dec 14, 2020 at 6:11 PM Chris Hegarty <ch...@oracle.com>
> > wrote:
> >
> > >
> > > > On 14 Dec 2020, at 10:03, Rory O'Donnell <ro...@oracle.com>
> > > wrote:
> > > >
> > > > ...
> > > > On 14/12/2020 09:45, Martin Grigorov wrote:
> > > >> Hi Rory,
> > > >>
> > > >> Apache Wicket build and tests are OK with JDK 16 b28 for both
> aarch64
> > > and
> > > >> x86_64 (Ubuntu 20.10)!
> > > >>
> > > >> I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
> > > >> maven-surefire-plugin's JVM arguments because it seems this plugin
> > does
> > > not
> > > >> use the (automatic) module name of the Maven project and the JDK
> sees
> > > it as
> > > >> unnamed.
> > > >> And because of this Wicket was not able to install its hooks into
> Java
> > > >> Serialization API.
> > > >>
> > > >>
> > >
> >
> https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzNApXj5k$
> > >
> > > Opening the `java.io` package will of course work, but requires all
> > > deployments of Wicket to do so. Maybe there is a better alternative.
> > >
> > >
> > Actually there is no problem.
> > The unit tests were failing because of 'module java.base does not "opens
> > java.io" to unnamed module'.
> > It seems maven-surefire-plugin does not use the Maven module's
> (automatic)
> > module name while running the tests and the JVM sees it as "unnamed".
> > So, I've added the exception to maven-surefire-plugin's JVM args:
> >
> >
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L1086-L1097
> > If I deploy a .war file to a web container like Apache Tomcat then there
> is
> > no such exception at runtime. I haven't verified but I guess all is fine
> > due to the Automatic-Module-Name in META-INF/MANIFEST.MF (
> >
> >
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L989-L1004
> > )
> >
> >
> According to catalina.out
> Tomcat9 adds "--add-opens=jva.base/java.io=ALL-UNNAMED"
>
> as well as many others ....
>
This may explain why it worked here with wicket-examples.war.
But without this Tomcat itself does not work.
Tomcat team just added java.util to the list :
https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486
, https://markmail.org/message/yyztogbheteyensv
>
>
> >
> > > I see that `org.apache.wicket.serialize.java.JavaSerializer` is using
> > > `setAccessible(true)` to access the private static method
> > > `latestUserDefinedLoader` in `java.io.ObjectInputStream`. There is a
> > > straightforward way of implementing similar functionality with the
> > > standard java.lang.StackWalker API. If you do this, then the
> > > `--add-opens` can probably be dropped.
> > >
> >
> > I will try to improve this with your suggestion!
> >
> > But the problem I solved was for
> >
> >
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/wicket-core/src/main/java/org/apache/wicket/core/util/objects/checker/CheckingObjectOutputStream.java#L251-L282
> > Here Wicket uses Reflection for ObjectStreamClass and ObjectStreamField
> to
> > be able to pinpoint which member field of a Java object is not
> Serializable
> > for debugging purposes.
> >
> >
> > >
> > > Here is an example of such:
> > >
> > > static {
> > > PrivilegedAction<StackWalker> pa1 =
> > > () ->
> > > StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> > > PrivilegedAction<ClassLoader> pa2 =
> > > () -> ClassLoader.getPlatformClassLoader();
> > > STACKWALKER = AccessController.doPrivileged(pa1);
> > > PLATFORM_LOADER = AccessController.doPrivileged(pa2);
> > > }
> > >
> > > /**
> > > * Returns the first non-null and non-platform class loader (not
> > > counting
> > > * class loaders of generated reflection implementation classes) up
> > the
> > > * execution stack, or the platform class loader if only code from
> > the
> > > * bootstrap and platform class loader is on the stack.
> > > */
> > > private static ClassLoader latestUserDefinedLoader() {
> > > return STACKWALKER.walk(s ->
> > > s.map(StackWalker.StackFrame::getDeclaringClass)
> > > .map(Class::getClassLoader)
> > > .filter(Objects::nonNull)
> > > .filter(cl -> !PLATFORM_LOADER.equals(cl))
> > > .findFirst()
> > > .orElse(PLATFORM_LOADER));
> > > }
> > >
> > > Remove the PrivilegedAction / doPrivileged stuff if not interested in
> > > running with a security manager enabled.
> > >
> > > Let me know if I can do anything further to help.
> > >
> > > -Chris.
> > >
> > >
> >
>
>
> --
> Best regards,
> Maxim
>
Re: JDK 16 is in Rampdown Phase One
Posted by Maxim Solodovnik <so...@gmail.com>.
On Tue, 15 Dec 2020 at 14:45, Martin Grigorov <mg...@apache.org> wrote:
> Hi Chris,
>
> Thank you for your advices!
>
> On Mon, Dec 14, 2020 at 6:11 PM Chris Hegarty <ch...@oracle.com>
> wrote:
>
> >
> > > On 14 Dec 2020, at 10:03, Rory O'Donnell <ro...@oracle.com>
> > wrote:
> > >
> > > ...
> > > On 14/12/2020 09:45, Martin Grigorov wrote:
> > >> Hi Rory,
> > >>
> > >> Apache Wicket build and tests are OK with JDK 16 b28 for both aarch64
> > and
> > >> x86_64 (Ubuntu 20.10)!
> > >>
> > >> I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
> > >> maven-surefire-plugin's JVM arguments because it seems this plugin
> does
> > not
> > >> use the (automatic) module name of the Maven project and the JDK sees
> > it as
> > >> unnamed.
> > >> And because of this Wicket was not able to install its hooks into Java
> > >> Serialization API.
> > >>
> > >>
> >
> https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzNApXj5k$
> >
> > Opening the `java.io` package will of course work, but requires all
> > deployments of Wicket to do so. Maybe there is a better alternative.
> >
> >
> Actually there is no problem.
> The unit tests were failing because of 'module java.base does not "opens
> java.io" to unnamed module'.
> It seems maven-surefire-plugin does not use the Maven module's (automatic)
> module name while running the tests and the JVM sees it as "unnamed".
> So, I've added the exception to maven-surefire-plugin's JVM args:
>
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L1086-L1097
> If I deploy a .war file to a web container like Apache Tomcat then there is
> no such exception at runtime. I haven't verified but I guess all is fine
> due to the Automatic-Module-Name in META-INF/MANIFEST.MF (
>
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L989-L1004
> )
>
>
According to catalina.out
Tomcat9 adds "--add-opens=jva.base/java.io=ALL-UNNAMED"
as well as many others ....
>
> > I see that `org.apache.wicket.serialize.java.JavaSerializer` is using
> > `setAccessible(true)` to access the private static method
> > `latestUserDefinedLoader` in `java.io.ObjectInputStream`. There is a
> > straightforward way of implementing similar functionality with the
> > standard java.lang.StackWalker API. If you do this, then the
> > `--add-opens` can probably be dropped.
> >
>
> I will try to improve this with your suggestion!
>
> But the problem I solved was for
>
> https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/wicket-core/src/main/java/org/apache/wicket/core/util/objects/checker/CheckingObjectOutputStream.java#L251-L282
> Here Wicket uses Reflection for ObjectStreamClass and ObjectStreamField to
> be able to pinpoint which member field of a Java object is not Serializable
> for debugging purposes.
>
>
> >
> > Here is an example of such:
> >
> > static {
> > PrivilegedAction<StackWalker> pa1 =
> > () ->
> > StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> > PrivilegedAction<ClassLoader> pa2 =
> > () -> ClassLoader.getPlatformClassLoader();
> > STACKWALKER = AccessController.doPrivileged(pa1);
> > PLATFORM_LOADER = AccessController.doPrivileged(pa2);
> > }
> >
> > /**
> > * Returns the first non-null and non-platform class loader (not
> > counting
> > * class loaders of generated reflection implementation classes) up
> the
> > * execution stack, or the platform class loader if only code from
> the
> > * bootstrap and platform class loader is on the stack.
> > */
> > private static ClassLoader latestUserDefinedLoader() {
> > return STACKWALKER.walk(s ->
> > s.map(StackWalker.StackFrame::getDeclaringClass)
> > .map(Class::getClassLoader)
> > .filter(Objects::nonNull)
> > .filter(cl -> !PLATFORM_LOADER.equals(cl))
> > .findFirst()
> > .orElse(PLATFORM_LOADER));
> > }
> >
> > Remove the PrivilegedAction / doPrivileged stuff if not interested in
> > running with a security manager enabled.
> >
> > Let me know if I can do anything further to help.
> >
> > -Chris.
> >
> >
>
--
Best regards,
Maxim
Re: JDK 16 is in Rampdown Phase One
Posted by Martin Grigorov <mg...@apache.org>.
Hi Chris,
Thank you for your advices!
On Mon, Dec 14, 2020 at 6:11 PM Chris Hegarty <ch...@oracle.com>
wrote:
>
> > On 14 Dec 2020, at 10:03, Rory O'Donnell <ro...@oracle.com>
> wrote:
> >
> > ...
> > On 14/12/2020 09:45, Martin Grigorov wrote:
> >> Hi Rory,
> >>
> >> Apache Wicket build and tests are OK with JDK 16 b28 for both aarch64
> and
> >> x86_64 (Ubuntu 20.10)!
> >>
> >> I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
> >> maven-surefire-plugin's JVM arguments because it seems this plugin does
> not
> >> use the (automatic) module name of the Maven project and the JDK sees
> it as
> >> unnamed.
> >> And because of this Wicket was not able to install its hooks into Java
> >> Serialization API.
> >>
> >>
> https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzNApXj5k$
>
> Opening the `java.io` package will of course work, but requires all
> deployments of Wicket to do so. Maybe there is a better alternative.
>
>
Actually there is no problem.
The unit tests were failing because of 'module java.base does not "opens
java.io" to unnamed module'.
It seems maven-surefire-plugin does not use the Maven module's (automatic)
module name while running the tests and the JVM sees it as "unnamed".
So, I've added the exception to maven-surefire-plugin's JVM args:
https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L1086-L1097
If I deploy a .war file to a web container like Apache Tomcat then there is
no such exception at runtime. I haven't verified but I guess all is fine
due to the Automatic-Module-Name in META-INF/MANIFEST.MF (
https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/pom.xml#L989-L1004
)
> I see that `org.apache.wicket.serialize.java.JavaSerializer` is using
> `setAccessible(true)` to access the private static method
> `latestUserDefinedLoader` in `java.io.ObjectInputStream`. There is a
> straightforward way of implementing similar functionality with the
> standard java.lang.StackWalker API. If you do this, then the
> `--add-opens` can probably be dropped.
>
I will try to improve this with your suggestion!
But the problem I solved was for
https://github.com/apache/wicket/blob/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef/wicket-core/src/main/java/org/apache/wicket/core/util/objects/checker/CheckingObjectOutputStream.java#L251-L282
Here Wicket uses Reflection for ObjectStreamClass and ObjectStreamField to
be able to pinpoint which member field of a Java object is not Serializable
for debugging purposes.
>
> Here is an example of such:
>
> static {
> PrivilegedAction<StackWalker> pa1 =
> () ->
> StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> PrivilegedAction<ClassLoader> pa2 =
> () -> ClassLoader.getPlatformClassLoader();
> STACKWALKER = AccessController.doPrivileged(pa1);
> PLATFORM_LOADER = AccessController.doPrivileged(pa2);
> }
>
> /**
> * Returns the first non-null and non-platform class loader (not
> counting
> * class loaders of generated reflection implementation classes) up the
> * execution stack, or the platform class loader if only code from the
> * bootstrap and platform class loader is on the stack.
> */
> private static ClassLoader latestUserDefinedLoader() {
> return STACKWALKER.walk(s ->
> s.map(StackWalker.StackFrame::getDeclaringClass)
> .map(Class::getClassLoader)
> .filter(Objects::nonNull)
> .filter(cl -> !PLATFORM_LOADER.equals(cl))
> .findFirst()
> .orElse(PLATFORM_LOADER));
> }
>
> Remove the PrivilegedAction / doPrivileged stuff if not interested in
> running with a security manager enabled.
>
> Let me know if I can do anything further to help.
>
> -Chris.
>
>
Re: JDK 16 is in Rampdown Phase One
Posted by Chris Hegarty <ch...@oracle.com>.
> On 14 Dec 2020, at 10:03, Rory O'Donnell <ro...@oracle.com> wrote:
>
> ...
> On 14/12/2020 09:45, Martin Grigorov wrote:
>> Hi Rory,
>>
>> Apache Wicket build and tests are OK with JDK 16 b28 for both aarch64 and
>> x86_64 (Ubuntu 20.10)!
>>
>> I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
>> maven-surefire-plugin's JVM arguments because it seems this plugin does not
>> use the (automatic) module name of the Maven project and the JDK sees it as
>> unnamed.
>> And because of this Wicket was not able to install its hooks into Java
>> Serialization API.
>>
>> https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzNApXj5k$
Opening the `java.io` package will of course work, but requires all
deployments of Wicket to do so. Maybe there is a better alternative.
I see that `org.apache.wicket.serialize.java.JavaSerializer` is using
`setAccessible(true)` to access the private static method
`latestUserDefinedLoader` in `java.io.ObjectInputStream`. There is a
straightforward way of implementing similar functionality with the
standard java.lang.StackWalker API. If you do this, then the
`--add-opens` can probably be dropped.
Here is an example of such:
static {
PrivilegedAction<StackWalker> pa1 =
() -> StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
PrivilegedAction<ClassLoader> pa2 =
() -> ClassLoader.getPlatformClassLoader();
STACKWALKER = AccessController.doPrivileged(pa1);
PLATFORM_LOADER = AccessController.doPrivileged(pa2);
}
/**
* Returns the first non-null and non-platform class loader (not counting
* class loaders of generated reflection implementation classes) up the
* execution stack, or the platform class loader if only code from the
* bootstrap and platform class loader is on the stack.
*/
private static ClassLoader latestUserDefinedLoader() {
return STACKWALKER.walk(s ->
s.map(StackWalker.StackFrame::getDeclaringClass)
.map(Class::getClassLoader)
.filter(Objects::nonNull)
.filter(cl -> !PLATFORM_LOADER.equals(cl))
.findFirst()
.orElse(PLATFORM_LOADER));
}
Remove the PrivilegedAction / doPrivileged stuff if not interested in
running with a security manager enabled.
Let me know if I can do anything further to help.
-Chris.
Re: JDK 16 is in Rampdown Phase One
Posted by Rory O'Donnell <ro...@oracle.com>.
Thanks for the update Martin!
On 14/12/2020 09:45, Martin Grigorov wrote:
> Hi Rory,
>
> Apache Wicket build and tests are OK with JDK 16 b28 for both aarch64 and
> x86_64 (Ubuntu 20.10)!
>
> I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
> maven-surefire-plugin's JVM arguments because it seems this plugin does not
> use the (automatic) module name of the Maven project and the JDK sees it as
> unnamed.
> And because of this Wicket was not able to install its hooks into Java
> Serialization API.
>
> https://urldefense.com/v3/__https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzNApXj5k$
>
> Regards,
> Martin
>
>
> On Mon, Dec 14, 2020 at 10:18 AM Rory O'Donnell <ro...@oracle.com>
> wrote:
>
>> Thanks Martin!
>>
>> On 14/12/2020 07:46, Martin Grigorov wrote:
>>
>> Hi Rory,
>>
>> Unfortunately this build breaks Wicket's usage of Serialization API.
>> public void writeObject(Object streamObj) is not called for some reason
>> and Wicket cannot intercept the calls.
>> I will investigate further and update you once I have more details.
>>
>> Martin
>>
>> On Sun, Dec 13, 2020 at 6:39 PM Rory O'Donnell <ro...@oracle.com>
>> wrote:
>>
>>> Hi Martin,
>>>
>>> *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
>>> https://urldefense.com/v3/__http://jdk.java.net/16__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzz8xGXJ30$
>>> <https://urldefense.com/v3/__http://jdk.java.net/16__;!!GqivPVa7Brio!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVawXwBerI$>
>>>
>>> * 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
>>> <https://urldefense.com/v3/__http://jdk.java.net/loom/__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzzbYcJ6Hk$
>>> <https://urldefense.com/v3/__http://jdk.java.net/loom/__;!!GqivPVa7Brio!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVa9hN1DjU$>>*
>>> (2020/11/30) - based on JDK-16+25
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/releases/tag/jdk-16*2B25__;JQ!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzz1NZPlxw$
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/releases/tag/jdk-16*2B25__;JQ!!GqivPVa7Brio!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVadyzHEbw$>
>>> * 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://urldefense.com/v3/__https://jdk.java.net/16/release-notes__;!!GqivPVa7Brio!OG8UiKWp8imcsbWbsHgnGZT9g23KrXftUL9elEebSECla8O_rUMab08gGqzz70EfRzI$
>>> <https://urldefense.com/v3/__https://jdk.java.net/16/release-notes__;!!GqivPVa7Brio!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVatRPbLl0$>
>>>
>>>
>> --
>> Rgds, Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA, Dublin, Ireland
>>
>>
--
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,
Apache Wicket build and tests are OK with JDK 16 b28 for both aarch64 and
x86_64 (Ubuntu 20.10)!
I had to add --add-opens=java.base/java.io=ALL-UNNAMED to
maven-surefire-plugin's JVM arguments because it seems this plugin does not
use the (automatic) module name of the Maven project and the JDK sees it as
unnamed.
And because of this Wicket was not able to install its hooks into Java
Serialization API.
https://github.com/apache/wicket/commit/b269b6dcc6a7642c5b5211cae60c7fa24dd7e7ef
Regards,
Martin
On Mon, Dec 14, 2020 at 10:18 AM Rory O'Donnell <ro...@oracle.com>
wrote:
> Thanks Martin!
>
> On 14/12/2020 07:46, Martin Grigorov wrote:
>
> Hi Rory,
>
> Unfortunately this build breaks Wicket's usage of Serialization API.
> public void writeObject(Object streamObj) is not called for some reason
> and Wicket cannot intercept the calls.
> I will investigate further and update you once I have more details.
>
> Martin
>
> On Sun, Dec 13, 2020 at 6:39 PM Rory O'Donnell <ro...@oracle.com>
> wrote:
>
>> Hi Martin,
>>
>> *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!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVawXwBerI$>
>>
>> * 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/
>> <https://urldefense.com/v3/__http://jdk.java.net/loom/__;!!GqivPVa7Brio!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVa9hN1DjU$>>*
>> (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!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVadyzHEbw$>
>> >
>>
>> * 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
>> <https://urldefense.com/v3/__https://jdk.java.net/16/release-notes__;!!GqivPVa7Brio!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVatRPbLl0$>
>>
>>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>
Re: JDK 16 is in Rampdown Phase One
Posted by Rory O'Donnell <ro...@oracle.com>.
Thanks Martin!
On 14/12/2020 07:46, Martin Grigorov wrote:
> Hi Rory,
>
> Unfortunately this build breaks Wicket's usage of Serialization API.
> public void writeObject(Object streamObj) is not called for some
> reason and Wicket cannot intercept the calls.
> I will investigate further and update you once I have more details.
>
> Martin
>
> On Sun, Dec 13, 2020 at 6:39 PM Rory O'Donnell
> <rory.odonnell@oracle.com <ma...@oracle.com>> wrote:
>
> Hi Martin,
>
> *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!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVawXwBerI$>
>
> * 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!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVa9hN1DjU$>>*
> (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!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVadyzHEbw$>>
>
> * 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!Liyl4H4TnxuGbjQuoffXZTV8fQWjpvwYd6e9fjqL1y5xoX5B-5hePKfQDAVatRPbLl0$>
>
--
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,
Unfortunately this build breaks Wicket's usage of Serialization API.
public void writeObject(Object streamObj) is not called for some reason and
Wicket cannot intercept the calls.
I will investigate further and update you once I have more details.
Martin
On Sun, Dec 13, 2020 at 6:39 PM Rory O'Donnell <ro...@oracle.com>
wrote:
> Hi Martin,
>
> *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
>
>