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

Difference between revisions of "Java9/ModularityOptions"

(Solution discussion)
(Use cases)
Line 37: Line 37:
 
*** [SH]: How close does "require static" come to expressing test dependencies?
 
*** [SH]: How close does "require static" come to expressing test dependencies?
 
**** [NL]: I *think* this is exactly the alternative mentioned above with "could the same be expressed in module-info.java syntax".
 
**** [NL]: I *think* this is exactly the alternative mentioned above with "could the same be expressed in module-info.java syntax".
*** [NL]: I think that ideally Eclipse should do what other IDEs do (do they treat test sources as "real non-modules", which adds reads for everything?). If not, allow to specify in the UI read edges (can be done directly in the classpath).
+
*** [NL]: I think that ideally Eclipse should do what other IDEs do (do they treat test sources as "real non-modules", which adds reads for everything?). Maybe have every source folder its own module - I think this is best. If not, allow to specify in the UI read edges (can be done directly in the classpath).
 
* How does the request interact with the distinction main/test sources?
 
* How does the request interact with the distinction main/test sources?
 
** [NL]: main sources are can do everything in module-info so they are fine. Test sources are restricted by module-info, but cannot change it, so they need a way to express their special needs.
 
** [NL]: main sources are can do everything in module-info so they are fine. Test sources are restricted by module-info, but cannot change it, so they need a way to express their special needs.

Revision as of 21:06, 15 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
          • [NL]: We need to be careful here: the test folder cannot define its own module-info, but it's still restricted by the project's module-info, so "is not a module" is confusing. Projects which are "not modules" (and converted to the automatic module) read everything, which is a solution for test folders.
        • Hence we need a way to express that M1 comes in two variants, with / without test source & test dependencies.
          • [NL]: This is a possibility, or at least a way to think about it.
        • 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!
          • [NL]: It could also need --add-exports from the module it reads to itself if the module being read does not export the needed packages by itself. This is already possible in the UI.
      • [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.
        • [NL]: You can add the readability edges in module-info directly, but this means that you will need Eclipse-specific module-info files because it's the only IDE that treats test folders this way. As things stand, whether the case is a full modular world or a migration world, the problem of test folders still needs to be solved.
      • [SS] My vote will be to use module-info.java for all named modular dependencies.
      • [SH]: How close does "require static" come to expressing test dependencies?
        • [NL]: I *think* this is exactly the alternative mentioned above with "could the same be expressed in module-info.java syntax".
      • [NL]: I think that ideally Eclipse should do what other IDEs do (do they treat test sources as "real non-modules", which adds reads for everything?). Maybe have every source folder its own module - I think this is best. If not, allow to specify in the UI read edges (can be done directly in the classpath).
  • How does the request interact with the distinction main/test sources?
    • [NL]: main sources are can do everything in module-info so they are fine. Test sources are restricted by module-info, but cannot change it, so they need a way to express their special needs.

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?

[SS] If we want to test with different implementations before adopting, it might help but I feel it is good to have but not a blocker.

  • 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.
[SS] What about the usage of --upgrade-module-path for the application module path?

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
      • [NL]: Isn't this how limit-module is expressed? If so, there will be a runtime issue as mentioned in the bug.
    • 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

Solution discussion

  • Build Path > Modular Options
  • Not in Build Path.

Defining the main class

Solution discussion

  • Build Path > Source
  • Build Path > Modular Options

Back to the top