Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Java9/ModularityOptions

< Java9
Revision as of 11:39, 19 July 2018 by Stephan.herrmann.berlin.de (Talk | contribs) (Solution discussion)

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?
    •  ?
  • 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?

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

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

Back to the top