POC for a buildItem defining the add-opens needs

[Sanne]

POC for what's being discussed on:

• #dev > JVM parameters recommender

Essentially we need a way for each extension to declare which "add-opens" they need; we can generate the definition for the manifest, so that people can still simply invoke "java -jar app.jar".

However this doesn't resolve the need for setting the same properties during testing; during test execution I see no way to automatically apply the parameters as the JVM is already running - I'm not aware of cases in which we fork the JVM, should we?
We could consider checking if the matching parameters are being set, and if not log a clear message with suggestions?

I have a follow-up experiment to resolve some issues with Netty.

[Sanne]

Example usage by Netty cc/ @franz1981

• 0c050b9

[dmlloyd]

This should be two separate properties. Or maybe a set of packages to open. Plus the destination module as I said earlier.

[Sanne]

The problem is that the Jar's Manifest format doesn't allow to specify a destination module.

We could add it here as a hint for users of the new buildItem that they should specify it - in hope for us to being able to use it better in the future, but I'm concerned that since it won't have any effect there is no way to test that people are specifying the correct values.

Perhaps it's best to not have a misleading API and stick to offer what it can do?

[dmlloyd]

You're thinking only of what it can do, today, this week. But I already have a parallel branch which modularizes the application fully. I'd rather only maybe have to rework one or two mistakes than have to rework everything. The JAR manifest is an edge case in the greater scheme; it just happens to be the first case we've encountered.

[Sanne]

Ok then! Sounds great, I just wasn't sure if you were aware of these limitations - sounds like you are :)

[zakkak]

Just a note for consistency. There is JPMSExportBuildItem which we use in native-mode. IMHO we should use similar names for both the "export" and the "open" builditems, so I suggest using JPMSOpenBuildItem or renaming JPMSExportBuildItem accordingly.

[Sanne]

thanks @zakkak ! I see the SecurityProcessor also produces some JPMSExportBuildItem(s), looks like related to Fips:

• https://github.com/quarkusio/quarkus/blob/main/extensions/security/deployment/src/main/java/io/quarkus/security/deployment/SecurityProcessor.java#L449-L452

Shouldn't these also be applied to the Jar Manifest (and any other launcher we'll support) ?

[dmlloyd]

Just a note for consistency. There is JPMSExportBuildItem which we use in native-mode. IMHO we should use similar names for both the "export" and the "open" builditems, so I suggest using JPMSOpenBuildItem or renaming JPMSExportBuildItem accordingly.

This one needs to be revisited because it has several problems:

• It is clearly a global concept, so it should not be in the nativeimage subpackage.
• It includes GraalVM version information. This is just flat-out wrong; any version range predicate should be evaluated by the step producing the item. If the version is outside of the range, the item should not be produced.
• There is no destination module name.

IMO it might be easiest to deprecate JPMSExportBuildItem for removal and go to unified items like what I described.

[Sanne]

@dmlloyd agreed, I noticed the same limitations - clearly JPMSExportBuildItem was designed specifically for native-image. It begs for us to define some sort of "target JVM filter" that would address version ranges and platforms in a more generic way.

But before thinking of providing a more general solution I'd like to check if there's any need for this - as far as I can see that Fips Security Processor is the only user for "add exports" - so let's hear if that should be applied to JVM mode as well.

[dmlloyd]

But before thinking of providing a more general solution I'd like to check if there's any need for this - as far as I can see that Fips Security Processor is the only user for "add exports" - so let's hear if that should be applied to JVM mode as well.

The modular build requires at least one add-exports, and the current loom experiments also require one or maybe two add-exports.

"WAGNI" - We Are Going To Need It!

[zakkak]

JPMSExportBuildItem is also used in:

• quarkus/extensions/jdbc/jdbc-db2/deployment/src/main/java/io/quarkus/jdbc/db2/deployment/JDBCDB2Processor.java

  Line 177 in 52c39d3

  jpmsExports.produce(new JPMSExportBuildItem("java.base", "sun.security.action"));

• quarkus/core/deployment/src/main/java/io/quarkus/deployment/steps/NativeImageFeatureStep.java

  Lines 61 to 69 in 52c39d3

  	@BuildStep
  	void addExportsToNativeImage(BuildProducer<JPMSExportBuildItem> features) {
  	// required in order to access org.graalvm.nativeimage.impl.RuntimeClassInitializationSupport
  	// prior to 23.1 the class was provided by org.graalvm.sdk module and with 23.1 onwards, it's provided by org.graalvm.nativeimage instead
  	features.produce(new JPMSExportBuildItem("org.graalvm.sdk", "org.graalvm.nativeimage.impl", null,
  	GraalVM.Version.VERSION_23_1_0));
  	features.produce(new JPMSExportBuildItem("org.graalvm.nativeimage", "org.graalvm.nativeimage.impl",
  	GraalVM.Version.VERSION_23_1_0));
  	}

  (this is graalvm-related)

I agree with @dmlloyd on "WAGNI" :)

Shouldn't these also be applied to the Jar Manifest (and any other launcher we'll support) ?

It really depends on whether the code paths triggering the issue (i.e. accessing the encapsulated code) are reached at runtime or not. We have no tests triggering it in JVM-mode AFAIK and IIRC no-one digged deeper to see whether we could prune these code paths in native-mode.

[dmlloyd]

I'm not sure I'd depend on a test to determine whether something is needed. But maybe it's worth trying to craft one to trigger the issue?

[Sanne]

"WAGNI" - We Are Going To Need It!

very well, I know I can trust you on such feelings :)

This particular POC isn't linked to any specific issue or strategy yet (I was just exploring options), I guess I'll include the need for add-exports to be addressed by the same "thing" which is emerging here.