Future Education is an education consultancy and the best education service, provider. it founded in 2010. they have a very expert team. it has been working for last 10 yrs in education industires. they guide as a personal adviser and solving problems in education-related. like admission in top colleges, admission top courses, abroad study, etc. https://www.futeducation.com/
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
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.
Hello Brian, Scott and others,
According to  JEP 396  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 .
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 .
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'
* No need to collect all required '--add-opens' for every jar
* 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
B) Use only '--add-opens' options to open only identified packages
* No warning about deprecated '--illegal-access' option will be issued
* It is more secure - only required JDK packages will be open for
for code on the classpath
* No problem will pop up when '--illegal-access' option will be
from future JDK
* Documenting all necessary '--add-opens' will give us better insight to
potentially dangerous code in some libraries
* 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+?
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
and thus it is and will always be accessible from classpath code
(including reflection access).
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
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
Wei Nan | JBoss