Hi David & Richard,
*Per the JDK 16 schedule , we are in Rampdown Phase One* * .
*Please advise if you find any issues while testing the latest Early
* 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 
OpenJDK 16 Early Access build 28**is now available at
* 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
+ Strongly encapsulate all internal elements of the JDK by
default, except for critical internal APIs
<https://openjdk.java.net/jeps/260#Description> such as
+ 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
+ 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
* Changes in recent builds that maybe of interest:
o Build 28
+ JDK-8256299: JEP 396: Strongly Encapsulate JDK Internals by
+ 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
* These early-access builds are provided under the GNU General Public
License, version 2, with the Classpath Exception
* 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(a)openjdk.java.net
<mailto:firstname.lastname@example.org>. To send e-mail to this address
you must first subscribe to the mailing list
For anyone who tags components that come in via WildFly Core now may be a
good time to try setting up a job using Kabir's new snapshot-ci tool to run
through both the WildFly Core and WildFly testsuites.
Coverage doesn't presently 100% match our PR CI as we have many different
profiles but does still run way more than running the default builds
The following is an example of how I kicked of a job testing our 1.x branch
of WildFly Elytron against the latest WildFly Core and WildFly:
It is very quick to take an existing issue and copy the contents and adapt
to your own projects. In my example I used the upstream branches of all
three repos to try it out but all of these could just as easily have been
my own topic branches being used for feature development.
Now that I have set up a build I will definitely try and do this
regularly at least a day or two before we plan to tag WildFly Elytron to
better check of any unintended side effects in advance.
I have been thinking at a possible evolution of Galleon channels and
feature-pack dependencies. This has an impact at the architectural
level, and you could think that it is not an idea to follow. That is an
early idea to acquire feedback...
Having a single FP artifact that contains its channel (current) when we
want to define multiple channels (20, 21, 22, ...) seems not right. When
designing an FP one has not the ability to select the wildfly channel he
wants to depend on. He will express the dependency on
org.wildfly:wildfly-galleon-pack:22.0.0.Final that is implicitly the
default channel. This is perhaps not a common use-case, depending on
the latest wildfly is perhaps what we want.
The idea would be to be able to build an FP per channel per release.
Using a classifier to identify the channel.
As an example, to support 2 channels (default and 22) we would create 2
FP artifacts: org.wildfly:wildfly-galleon-pack:22.0.0.Final,
The Galleon channel would be evolved to contain the classifier to
identify the correct FP artifact, so GA+classifier+version range (and
It would not change the syntax of the FPL, we would still use
wildfly@community-universe:22, under the hood, the
org.wildfly:wildfly-galleon-pack:22:22.0.1.Final would be retrieved with
all dependencies properly bound to the correct channels. To properly
bind the dependencies to the channel we want we need more metadata.
A new XML file to express the channels we want to build FP for is
introduced. This file contains mapping of the dependencies producers to
the channels to use. This new XML file would be used when building a
feature-pack. Would look like something like:
At the end of the build we would have 3 FP built, one for the channel
'current', one for the channel 22 and one for 22.0. Exactly the same
bits, except the dependency that contains a classifier. The default
channel would be used the way it is today (present in the
wildfly-feature-pack-build.xml file), no need to have an entry for it in
the new xml file.
When designing a FP that depend on wildfly, one would then be able to
select the channel he wants to depend on by selecting the GAV (+
classifier). User could benefit from this feature and deploy multiple FP
So one could then do:
install myfp:latest (that depends on latest wildfly).
install myfp:1.0 (that depends on channel 22 of wildfly).
install myfp:2.0 (that depends on channel 23 of wildfly).
Something we would not be able to do (and can't do today is):
install myfp:2.0 (that depends on channel 23 of wildfly).
Although the myfp:2.0 would work on the latest widfly, there is no
relationship (order) between "current" and 23 channel, so we can't
identify that the installation is valid. Perhaps we need another
evolution there (compatible channels?).
So more artifacts, more constraints but seems to bring clearer