Community
Participate
Working Groups
When bug 526054 is fixed, UI should create a consistent story for users: which modules are "visible"? When compiling an unnamed module, or when limit-modules is in use, IJavaProject#findPackageFragmentRoots(IClasspathEntry) does only answer those roots that correspond to modules observable in the given project. At ECE Dani said that all uses like Package Explorer and Open Type should actually see *all* modules (which would require replacing calls to findPackageFragmentRoots() with the (provisional) JavaModelAccess.getUnfilteredPackageFragmentRoots). I'm not convinced that this is the best option. First and foremost this is inconsistent with other containers from PDE and m2e, where only those dependencies are shown that are actually declared in places like MANIFEST.MF or pom.xml. To aggravate the situation, Java 9 has 3 levels of availability: - physically available in JDK - observable after filtering (default root modules or limit-modules) - accessible due to "requires". The main argument against working with a reduced set of modules was discoverability by operations like Open Type, completion etc. I wonder if we could enhance such operations similar to quick outline: - Ctrl+Shift+T: open type from modules already accessible to the current module - twice Ctrl+Shift+T: extend the search scope to all modules physically available For completion I'm not sure what's better: - ignore any filtering / lack of requires and let user fix the setup afterwards - rank proposals according to the level of availability With these options on the table, I'm proposing the following: * In the Build Path dialog: - show only observable modules (after filtering) * Module Contents dialog naturally shows all modules * Package/Project Explorer - show only modules read by the current module Since the last change may be undesired for some users/use cases, I could think of a preference that lets you choose among the three levels. Related question: How do we handle types with access restrictions in Open Type, completion etc.? Do we happily advise users to use types that they should not use, or do we have a means to hold back those types? (I haven't checked). One way or other: the UI must be consistent :)
ideally for 4.7.2, not sure that's feasible, though.
Obviously too late for 4.7.3, but ... @Dani, @Noopur, do you want to comment on this proposal / discuss it in your next call? (In reply to Stephan Herrmann from comment #0) > With these options on the table, I'm proposing the following: > * In the Build Path dialog: > - show only observable modules (after filtering) > * Module Contents dialog naturally shows all modules > * Package/Project Explorer > - show only modules read by the current module > > Since the last change may be undesired for some users/use cases, I could > think of a preference that lets you choose among the three levels. More details above.
(In reply to Stephan Herrmann from comment #2) > Related question: How do we handle types with access restrictions in Open > Type, completion etc.? Do we happily advise users to use types that they > should not use, or do we have a means to hold back those types? (I haven't > checked). Take a look at the 'Type Filters' preference page. I am definitely against filtering the Open Type dialog. I could imagine that for Content Assist, Quick Assist/Fix and other things we treat modules like bundles where the types are filtered and then we offer a Quick Fix to add the module. The problem is with modules that are part of the JDK: the behavior would change as types would not be found instead of finding the type and adding the import automatically. I'm not yet sure what visibility you mean with regards to the Package Explorer. Can you give an example?
(In reply to Dani Megert from comment #3) > (In reply to Stephan Herrmann from comment #2) > > Related question: How do we handle types with access restrictions in Open > > Type, completion etc.? Do we happily advise users to use types that they > > should not use, or do we have a means to hold back those types? (I haven't > > checked). > > Take a look at the 'Type Filters' preference page. Great, we could then add two more options: [X] Hide not-exported types [ ] Hide types from modules that are not read by the current module Defaults as indicated. If you still use a 'problematic' type, quick fix for the first would add --add-exports, quick fix for the latter would add 'requires'. > I'm not yet sure what visibility you mean with regards to the Package > Explorer. Can you give an example? I was thinking of the children of the JRE System Library node. This set could be large, medium or small: (1) All modules contained in JDK (2) Similar to (1) but with --limit-modules applied as a filter. (3) Only (the transitive closure of) those modules that are read by the current module. IMHO, (1) is just unnecessarily overwhelming. In particular (3) would much better resemble what we have in "* Dependencies" containers (PDE/Maven ...).
(In reply to Stephan Herrmann from comment #4) I think we have to distinguish between JDK modules and others. "others" should be treated like PDE treats bundles, i.e. only show what's specified. Also, types from those would not appear automatically, but there would be Quick Fixes to add the module. Open Type would show them. For JDK modules we would show all and content assist would show their types. We can then add a filter (off by default) to hide unused JDK modules in the explorers. > Great, we could then add two more options: > [X] Hide not-exported types > [ ] Hide types from modules that are not read by the current module The first option makes sense. The second one would be unnecessary in my opinion if we make the distinction between JDK and other modules. WDYT?
Moving it to M7.
