Difference between revisions of "Java9/ModularityOptions"

Revision as of 17:14, 4 August 2018

Oxygen.1a brought initial support to configure new options as defined in JEP 261 (beware, we have been told that the JEP contains outdated information).

The new UI extending the Java Build Path configuration does not yet cover all possible & desirable use cases. This page collects the open issues and discusses how we can support everything in a maximally consistent way.

When discussing integration in the Java Build Path configuration, will this be picked up by launch configurations automatically, or is more needed also in JDT/Debug?

--add-reads

What's missing?

• bug 526831
• --add-reads my.mod=XXX
  • sepecial case --add-reads my.mod=ALL_UNNAMED

So far, --add-reads can only be applied to a module on which the current project depends, but not on the current module itself.

Use cases

Why is this relevant / what is the user trying to achieve by this option?

• Does it make a difference whether reading named or unnamed modules?
  • Yes, module-info cannot say "reads ALL_UNNAMED".
• Do we still need to support named modules?
  • Yes, for test code. See bug 526963.
    • [SH]: Let me check if I can construct a user story for this (correct me if I'm wrong):
      • A project defines a module M1
      • Additionally, it has a test source folder, that depends on module M2
      • M1 should not require M2, ergo "reads" is not a property of the project but of the test folder
      • The test folder is not a module, so it cannot require anything
      • Hence we need a way to express that M1 comes in two variants, with / without test source & test dependencies.
      • Question: Is this issue limited to "reads" or would the test variant possibly need other directives, too?
        • Export packages to test folders of downstream projects? My guess: yes!
        • Declare service consumption? My guess: yes!
    • [SH]: If the above bullet is a true rendition of the issue at hand, could the same be expressed in module-info.java syntax, rather than as directives on the build path? Reason for asking: I see explicitly tweaking "Modularity Details" mainly as a tool during migration towards modules - in a perfect modular world none of this would be needed - whereas different main / test dependencies is a part of good software engineering, designed to stay.
    • [SH]: How close does "require static" come to expressing test dependencies?
• How does the request interact with the distinction main/test sources?

Solution discussion

• Where in the UI should this option be represented?
  • Is it a property of a source folder?
    • How do we handle multiple source folders per project?
  • Is it a property of the project?
    • If so, which part of the Build Path dialogs best represents "the project"?
• What should be the gestures / dialogs etc. to define this?

--patch-module

What's missing?

• bug 529923, see also bug 525716
• --patch-module other.mod=third.location

So far, --patch-module can only declare that the current project patches an existing module on which it declares a dependency.

In bug 529923 it is argued that we should also support the case where one dependency (a non-modular(?) jar, project ...) patches another module on the build path.

Use cases

Why is this relevant / what is the user trying to achieve by this option?

• What kind of locations can be declared as patching another module?
  • JEP 261 speaks of a "filesystem path name of a module definition", but then if a module-info is found there, a warning is raised and the file ignored.
• Would we even need the option to declare some external code to patch the current module?
• How does the request interact with the distinction main/test sources?

Solution discussion

• Where in the UI should this option be represented?
• What should be the gestures / dialogs etc. to define this?

--upgrade-module-path

• mentioned in bug 532283#c4

Use case

Replace a system module with a custom variant of the same name.

Solution discussion

• User's intention could already be expressed like this:
  • exclude the given module from the "Contents" of the JRE node on the Java Build Path
  • add the replacement to the module path
• If that is too implicit, a warning could be given requiring the user to add a flag "yes I mean to replace a system module"
• Alternatively, Upgrade Modulepath could be added as a third node below Classpath & Modulepath

Even if the user doesn't explicitly say "upgrade-module-path" this option could be synthesized behind the scenes (for launching).

--add-opens

• not a build time concept but bug 531127 argues that the Java Build Path might still be an intuitive location

Defining the main class

• bug 528955