On Thu, May 27, 2021 at 9:44 PM Brian Stansberry <
For the last month we've been focusing quite a bit of energy
what it will take for WildFly to run well on the upcoming JDK 17. This post
is one of two I plan. This one is an attempt to start a discussion around a
couple topics; the other will be more of a status update.
Status summary is things are progressing well, no show-stoppers so far,
but plenty more to do. More on that in the other post....
WF 23 runs well on SE 13. We want to get to 17. The key barriers are:
1) SE 14 dropped the java.security.acl package.
2) SE 15 introduced hidden classes (JEP 371)
3) SE 16 strongly encapsulated JDK internals by default (JEP 396)
SE 17 will eliminate global --illegal-access command line option (JEP 403)
so explicit enumeration
of --add-opens and --add-exports will be the only possibility to open JDK
The discussion points relate to #3. WildFly does quite a lot reflection
stuff, plus we have some use cases where end users may want to use internal
JDK classes. SE 16 locks this down. For a good primer on the basic things
SE allows us when we need things to be made available, see . Richard
Opalka did a lot of good analysis of what JPMS-related VM launch settings
we need for WF to work properly; see  and . It's not a huge set,
which is nice.
But, it's not complete, because it doesn't account for user applications.
If application code requires additional deep reflection, then additional VM
launch settings will be needed. I think that's ok in general; we provide
hooks for users to add things to the JAVA_OPTS flags that are passed to
java. But the less users need to do that the better. Hence the discussion
AFAIR there are two places where modular jdk params must be specified.
One place is shell scripts (common.sh(.bat), etc) and second place is
That is a minor problem. We should configure these params either in shell
scripts or in config files but not in Java code.
The problematic part is also how to propagate (configure) modular jdk
1) Should we have just one global place where modular jdk params will be
specified (e.g. common.sh(.bat)) and propagated ( e.g. domain -> host
controller(s) -> server(s) )?
2) Or should users be able to specify modular jdk params for each entity
like domain, server, host controller?
Maybe that is already supported via standard configuration?
1) The ClassReflectionIndex constructor iterates over all fields and
methods in a class and marks them as accessible. For any class that is used
as an EE component type, *as well its superclasses*, a ClassReflectionIndex
is created. This means if an application uses some JDK class as a
superclass (ignore Object, which gets some special handling that makes it
not a problem in this discussion), then that superclass's package is going
to need to be opened. We have no way to know what superclasses our users'
component might have, so we can't open them up in for them as part of our
standard launch args.
My general understanding is we do this in order to allow things like
injection of values into fields or wrapping calls to non-public methods
Is there anything we can do about this? Any intelligence we can apply
avoid doing unnecessary opening? (See  for a very specific example of
such a thing.)
Or is this maybe not a big problem? We already need to open the java.util
package for other reasons, so EE component based on classes in that package
won't have a problem.
There are many utility classes in various JDK packages, e.g.
* Readable or Runnable in java.lang.
* Closeable or Flushable in java.io.
We do open all these packages already so maybe it will be sufficient for
our users too without need to open other packages.
2) There are cases where our configuration allows users to specify a class
to use as the impl of interface, as an instruction for the server to
instantiate an instance and use it. Examples include NamingContext and
java.security.Policy impls. In some cases well known examples of those
interfaces are internal JDK classes.
Should we identify likely cases of these things and proactively include
those packages in our server launch --add-opens set? My general instinct is
no, but there may be cases where my instincts are wrong.
I would also say no. Few of the answers will be obvious after a successful
100% TCK run.