User-accessible JavaInfo constructor doesn't allow changing module_flags_info

[timothyg-stripe]

Description of the feature request:

The user-accessible JavaInfo constructor runs _javainfo_init, which does not allow customizing module_flags_info. This means that it's impossible to replicate some of the semantics of java_info_for_compilation that would be useful for third party rulesets (like rules_scala), like:

1. It's impossible to make add_exports and add_opens attributes for a third-party rule
2. It's impossible to merge in runtime_deps' add_exports and add_opens, since _javainfo_init only merges the module flags for deps and exports.

A few ways to resolve this are:

1. The proper fix (IMO):
   1. Add some options to the JavaInfo constructor, like add_exports and add_opens (for "direct" rule attributes).
   2. Change the behavior of JavaInfo constructor so that add_exports and add_opens are merged for runtime_deps in addition to just deps & exports. This is IMO the right thing to do anyway, and reduces the delta between JavaInfo and java_info_for_compilation, though it changes some user-visible behavior and probably requires an --[no]incompatible_ flag.
2. Provide a factory function for JavaInfo that simply wraps a module_flags_info. Then, users can call java_common.merge([JavaInfo(…), java_common.wrap_module_flags_info(…)]).
3. Loosen java_common.merge input validation to allow JavaInfo-lookalikes rather than strictly JavaInfo objects. Then we can create a fake JavaInfo with module_flags_info set correctly, and call java_common.merge to legitimize it.
4. Expose _java_common_internal.wrap_java_info to users so that they can legitimize their JavaInfo lookalikes.

I'm happy to provide a patch. Please let me know which approach seems the most reasonable.

cc @hvadehra @cushon

Which category does this issue belong to?

Java Rules, Rules API

What underlying problem are you trying to solve with this feature?

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[timothyg-stripe]

I've made two PRs that implement approach 1 above:

• Add add_exports & add_opens parameters to JavaInfo constructor #20036. This solves most of the issue.
• Add --incompatible_java_info_merge_runtime_module_flags #20037, which changes the behavior of JavaInfo constructor to be more like java_info_for_compilation.

[iancha1992]

@timothyg-stripe awesome! can you actually resubmit this one, timothyg-stripe#1 against the bazelbuild repo instead of your own, so that we can assign and review it?