Description Stephan Herrmann 2017-10-15 15:27:27 EDT

Follow-up from bug 522328

JEP 261 defines the reduced set of root modules only for the case when compiling an unnamed module. (Modular projects explicitly pull in any modules they require).

Our implementation correctly reflects this by asking isUnnamedModule() (inside JavaProject.computePackageFragmentRoots()).

Unfortunately, we're now inconsistent in two ways:

- isUnnamedModule() answers true during initialization of a NameEnvironment, even if the project is modular (is this a chicken-n-egg problem?).
   => Even in modular projects not all JDK modules are visible.

- JDT/UI's ModuleDialog uses org.eclipse.jdt.core.provisional.JavaModelAccess.defaultRootModules(Iterable<IPackageFragmentRoot>) even in a modular project.

These two quirks are consistent among each other: compilation and dialog speak the same language. OTOH, Package Explorer and even Build Path > Libraries still show the full JDK content.


When both quirks are fixed, the default from bug 522328 will no longer be used for modular projects.

It could still be interesting to use that default for a modular project, to test whether clients in an unnamed module would need any --add-module options.

This could, e.g., be achieved by a button: "Use default root modules like for unnamed modules", which would then populate the Contents sub-lists accordingly. Note, that also persisting limit-modules must be aware if current project is modular to compare against the appropriate default.