Upcoming 23.0.1 Release
by Brian Stansberry
It's coming up on a month since WildFly 23, so it's time to do a 23.0.1.
I'd like to tag it next Wed April 7 and have it available for download on
April 8.
We've been porting a number of fixes to the 23.x branch over the last few
weeks. Component leads -- if there are further critical fixes that need to
go into 23.0.1 that haven't gone into 23.x yet, please get JIRAs and PRs
filed ASAP and reply here noting those. I'd like to get things merged by
Monday at the latest.
We've already integrated WildFly Core 15.0.1 into 23.x so I do not
anticipate further changes coming through core.
Best regards,
Brian
5 years
WildFly on JDK16+
by Richard Opalka
Hello Brian, Scott and others,
According to [1] JEP 396 [2] JDK 16 changed default
mode of global config option '--illegal-access'
from mode 'permit' to mode 'deny'. This means that
code on the class path cannot use reflection to access
the non-public elements of java.* packages, and all
elements of sun.* and other internal packages,
for packages that existed in JDK 8 - see complete list [3].
The 'permit', 'warn', and 'debug' modes of the
'--illegal-access' option are still supported and they work.
These modes still allow us to choose relaxed strong encapsulation.
The problem is it is expected a future JEP will remove
the '--illegal-access' option entirely. When this will happen
it will not be possible to open all of the JDK 8 packages
via a single command-line option. It will still be possible
to use the '--add-opens' command-line option to open specific packages.
As preparation for the removal of the '--illegal-access' option
this option was deprecated for removal as part of JEP 396 effort [2].
As a consequence, specifying that option to the java launcher
causes a deprecation warning being issued.
There are two possibilities how to address JDK 16+ regressions:
A) Use '--illegal-access=permit'
- Pros:
* No need to collect all required '--add-opens' for every jar
- Cons:
* Will issue warning about 'being deprecated option' on the commandline
* It is very dangerous because such default opens all JDK
(not just some) internal packages to all code on the classpath
* When '--illegal-access' will be removed we will need to go B) either
way
B) Use only '--add-opens' options to open only identified packages
- Pros:
* No warning about deprecated '--illegal-access' option will be issued
* It is more secure - only required JDK packages will be open for
reflection
for code on the classpath
* No problem will pop up when '--illegal-access' option will be
eliminated
from future JDK
* Documenting all necessary '--add-opens' will give us better insight to
potentially dangerous code in some libraries
- Cons:
* Some (but meaningful) effort is needed to collect and identify all
needed '--add-opens' clauses
In my opinion we should go B) way and open only what is necessary. What do
you think guys?
This also opens the question whether all WildFly subprojects shouldn't be
tested with JDK16+?
Rio
PS: All that has been said above doesn't apply to the 'sun.misc' package.
This package still is and will always be exported by the
'jdk.unsupported' module
and thus it is and will always be accessible from classpath code
(including reflection access).
[1] http://openjdk.java.net/projects/jdk/16/
[2] https://openjdk.java.net/jeps/396
[3] https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-denied-by-default
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropalka(a)redhat.com
5 years
RESTEasy Branch Renaming Announcement
by Wei Nan Li
The RESTEasy project will rename its GitHub 'master' branch by this
Friday (April 9, 2021). In particular, the 'master' branch will be
renamed to 'main', and the `main` branch will be set as the default
branch for Pull Requests.
Any already submitted PRs targeting the 'master' branch will
automatically be
redirected to the 'main' branch. For the local
environment, developers should
do a fetch of the project from GitHub,
and the 'main' branch will be fetched.
And all existing work against the 'master' branch should be migrated
to 'main' branch, and when you open a PR it will default to main. Here
are the steps to take locally:
- Do a git fetch upstream to get the 'main' branch
- rebase your working branch from the main branch(to get the latest
commit from upstream)
- Do the Pull Request workflow as usual(push to forked repo / create
Pull Request), and Github will use 'main' branch to create the Pull
Request by default.
In addition, all new PRs will by default target 'main' instead of 'master'.
For more details on the Github branch renaming, here's the document
for reference:
- https://docs.github.com/en/github/administering-a-repository/renaming-a-b...
--
Cheers,
Wei Nan | JBoss
5 years
OpenJDK 17 Early Access build 16 is now available
by Rory O'Donnell
Hi David & Richard,
*OpenJDK 17 Early Access build 16 is now available at
**http://jdk.java.net/17* <http://jdk.java.net/17>
* These early-access , open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>
* Schedule (proposed)
o 2021/06/10 Rampdown Phase One
o 2021/07/15 Rampdown Phase Two
o 2021/08/05 Initial Release Candidate
o 2021/08/19 Final Release Candidate
o 2021/09/14 General Availability
* Features:*Heads-up on an important Candidate JEP
*
o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
<https://openjdk.java.net/jeps/403>*
o successor to JEP 396: Strongly Encapsulate JDK Internals by
Default <https://openjdk.java.net/jeps/396>
o strongly encapsulate all internal elements of the JDK by default
o exception for Critical Internal APIs such as /sun.misc.Unsafe/
* JEPs targeted to JDK 17, so far:
o JEP 356: Enhanced Pseudo-Random Number Generators
<https://openjdk.java.net/jeps/356>
o JEP 382: New macOS Rendering Pipeline
<https://openjdk.java.net/jeps/382>
o JEP 391: macOS/AArch64 Port <https://openjdk.java.net/jeps/391>
o JEP 398: Deprecate the Applet API for Removal
<https://openjdk.java.net/jeps/398>
* Release Notes are available at http://jdk.java.net/17/release-notes
<http://jdk.java.net/17/release-notes>
* Changes in recent builds that maybe of interest:
o Build 16
+ JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
device throws FileSystemException: "nul: Incorrect function"
(win)
# Reported by Apache Ant
o Build 15
+ JDK-8263575: Conflict between JDK rpms and OL8 Modularity
prevents dnf install/updates
o Build 14
+ JDK-8262277: URLClassLoader.getResource throws undocumented
IllegalArgumentException
+ JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
conversion with a sign character
*Project Loom Early-Access Build: **Build 17-loom+5-191*
<http://jdk.java.net/loom/>*(2021/3/19)*
* 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 produced for the purpose of gathering feedback. Use
for any other purpose is at your own risk.
* Please send feedback via e-mail to loom-dev(a)openjdk.java.net
<mailto:loom-dev@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>.
*Quality Report for March 2021 was published here [1]*.
* Thanks to everyone who contributed by creating features or
enhancements, logging bugs, or downloading and testing the
early-access builds.
*Worth reading - **The Arrival of Java 16!
<https://inside.java/2021/03/16/the-arrival-of-java16/>*
* JDK 16 Migration guide -
https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
* #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
respond to this *tweet
<https://twitter.com/Sharat_Chander/status/1368978627816136707>*.
* Oracle Developer Live event - Individual sessions:
1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
https://youtu.be/1acKCBbd6f4 <https://youtu.be/1acKCBbd6f4>
2. *Java Language Futures: Spring 2021* (Gavin Bierman):
https://youtu.be/K9SVV0XNIP8 <https://youtu.be/K9SVV0XNIP8>
3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael
Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o
<https://youtu.be/CVE4bWvuD3o>
4. *Learn Java 16 with IntelliJ IDEA *(Trisha Gee[JetBrains])*:
*https://youtu.be/1hyWJTjxeGM <https://youtu.be/1hyWJTjxeGM>**
5. *How Records Can Improve Serialization* (Julia Boes, Chris
Hegarty): https://youtu.be/44D8M6ZxuLU
<https://youtu.be/44D8M6ZxuLU>
6. *Vector API: SIMD Programming in Java* (Paul Sandoz, Sandhya
Viswanathan[Intel]): https://youtu.be/VYo3p4R66N8
<https://youtu.be/VYo3p4R66N8>
7. *Your Guide to OpenJDK Development* (Jesper Wilhelmsson):
https://youtu.be/bHcKTYy_Nec <https://youtu.be/bHcKTYy_Nec>
8. *Project Skara: Migrating OpenJDK to Git and GitHub* (Erik
Duveblad, Robin Westberg): https://youtu.be/-pBgplk7fVk
<https://youtu.be/-pBgplk7fVk>
9. *Monitoring and Troubleshooting Tools in the JDK* (Poonam
Parhar): https://youtu.be/mcfubUmbZhQ <https://youtu.be/mcfubUmbZhQ>
10. *Fast and Efficient Microservices for Java with GraalVM* (Alina
Yurenko): https://youtu.be/_eRD6qJqtNw
<https://youtu.be/_eRD6qJqtNw>
11. *Accelerating Productivity with Micronaut and Java Records*
(Graeme Rocher): https://youtu.be/RoNeoXQBs9w
<https://youtu.be/RoNeoXQBs9w>
12. *Scalable Microservices for Java using Helidon and Coherence CE*
(Dmitry Aleksandrov, Aleks Seović): https://youtu.be/WTL0Zbjzveo
<https://youtu.be/WTL0Zbjzveo>
13. *Cross-Platform User Interfaces, Developed with Java & OpenJFX
Project* (Johan Vos [Gluon]): https://youtu.be/7eytbaBMm5o
<https://youtu.be/7eytbaBMm5o>
Rgds,Rory
[1]
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+Mar...
<https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+Mar...>
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
5 years
