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

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?

Defining the main class

Back to the top