[wildfly-dev] Re: Progress toward WildFly support for JDK 17 -- Avoiding JPMS problems

On Mon, Jun 7, 2021 at 5:18 AM Jean Francois Denise <jdenise(a)redhat.com&gt; wrote: > On 6/4/21 9:30 PM, Brian Stansberry wrote: > > Cody Lerum made me aware of a pain point in this area -- bootable jar. > > We use our standard launch scripts (e.g. [1]) to make setting the needed > JPMS settings easy for users doing traditional launches, but with bootable > jar the expectation is 'java -jar' would be used. > > Of course even on SE 8 people may have non-trivial args to java, and not > just 'java -jar'. But we'll need to be sure our bootable jar docs cover > what's needed for SE 16+. > > [1] > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/com... > > I have logged https://issues.redhat.com/browse/WFCORE-5451 to evolve the > WildFly Bootable JAR doc. > Thanks! Here and the JIRA is a good place to figure out what we want to say about these things. I somewhat do that in code comment in common.sh (see link above). I think it's useful to document something about why various things are needed, at least for ones where a slimmed server might not need something. But any language like that would need to have a clear N.B. that it's possible and --add-exports or --add-opens may be needed for something other than what's listed. I doubt we'd start testing with anything other than the full set, so such documentation could fall out of date. > > On Tue, Jun 1, 2021 at 2:38 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> >> >> On Mon, May 31, 2021 at 10:44 AM Richard Opalka <ropalka(a)redhat.com&gt; >> wrote: >> >>> Helo, >>> >>> Comments inlined: >>> >>> On Thu, May 27, 2021 at 9:44 PM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> For the last month we've been focusing quite a bit of energy toward >>>> seeing 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 internal packages. >>> >>>> >>>> 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 >>>> [1]. Richard Opalka did a lot of good analysis of what JPMS-related VM >>>> launch settings we need for WF to work properly; see [2] and [3]. 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 topics: >>>> >>> 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 >>> org.jboss.as.host.controller.jvm.JvmType . >>> 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 >>> parameters? >>> 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? >>> >> >> The key requirement is that each HC (DC or otherwise) is independently >> configurable, and each server is as well. A domain mode server doesn't have >> to run on the same VM as its HC, so we cannot force HC-level settings (e.g. >> stuff from common.sh) onto the servers. >> >> The various 'jvm' config settings in domain.xml/host.xml let users >> customize these things (or any other JVM launch setting) on a per-server >> basis. JvmType provides a kind of simple ease-of-use thing. Otherwise we'd >> have to have standard config blocks per JVM type in the standard config >> files we ship, and then users (and our own testsuite) would have to be >> taught to use them. >> >> It is clunky that there is no way to turn off applying those defaults >> though. >> >> >>>> 1) The ClassReflectionIndex[4] 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 >>>> with interceptors. >>>> >>> >>>> Is there anything we can do about this? Any intelligence we can apply >>>> to avoid doing unnecessary opening? (See [5] 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. >>> >> >> Thanks; that's a good point. >> >>> >>>> >>>> 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. >>> >>>> >>>> >>>> [1] >>>> https://nipafx.dev/five-command-line-options-hack-java-module-system/ >>>> [2] https://issues.redhat.com/browse/WFCORE-5406 >>>> [3] https://github.com/wildfly/wildfly-core/pull/4591 >>>> [4] >>>> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... >>>> [5] https://github.com/wildfly/wildfly/pull/14303 >>>> >>>> >>>> Best regards, >>>> Brian >>>> _______________________________________________ >>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>> >>> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> > > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > He/Him/His > > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s