Community
Participate
Working Groups
FUP from bug 518829: In the modular world, searching for a type by its qualified name no longer yields unique results. If a sought module is known, search should be able to consider only that module (or a set of modules - a module graph(?) for that matter).
An initial WIP gerrit at https://git.eclipse.org/r/112348 supports two kinds of module list a) <List of comma separated modules> : pack.X or b) Regex based list of modules (experimental) - the module name should start with 0 Examples available in JavSB9Tests. The mix of the above not supported - an alternate option is to give the choice of each element of the list to be a normal string or a pattern - should not end up in an overkill though. Module Graph input needs to be looked into to figure out how to support - mostly this would require a pre-proc stage since the input does not contain the closure info. The above gerrit is for TypeDeclarationPattern only but is a working version. @Stephan : Inputs welcome
New Gerrit change created: https://git.eclipse.org/r/112348
New Gerrit change created: https://git.eclipse.org/r/112346
New Gerrit change created: https://git.eclipse.org/r/112405
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/112405 (In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/112346 These are abandoned in favor of gerrit in comment 2, ie https://git.eclipse.org/r/#/c/112348/
(In reply to Manoj Palat from comment #5) > https://git.eclipse.org/r/#/c/112348/ The gerrit above enables a module name/a list of module names in a TypeDeclaration pattern Starting with the Javadoc changes of SearchPattern.createPattern(): Since 3.14 for Java 9, Type Declaration Patterns can have module names also embedded with the following syntax [moduleName1[,moduleName2,..]]:[qualification '.']typeName ['<' typeArguments '>'] Examples: ◦java.base:java.lang.Object ◦mod.one, mod.two:pack.X find declaration in the list of given modules. ◦:pack.X find in the unnamed module. To note that module name(s) and the type declaration pattern separated by a ':' character
Gerrit change https://git.eclipse.org/r/112348 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7b578e6c554f0780808d7dc0a5748e53798be2a7
(In reply to Eclipse Genie from comment #7) > Gerrit change https://git.eclipse.org/r/112348 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7b578e6c554f0780808d7dc0a5748e53798be2a7 > This commit left a new warning in the workspace. Manoj, can you please fix this?
(In reply to Jay Arthanareeswaran from comment #8) > (In reply to Eclipse Genie from comment #7) > > Gerrit change https://git.eclipse.org/r/112348 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7b578e6c554f0780808d7dc0a5748e53798be2a7 > > > > This commit left a new warning in the workspace. > Manoj, can you please fix this? yep- aware of that - unused variable - will be pushing another commit soon.
New Gerrit change created: https://git.eclipse.org/r/112628
(In reply to Manoj Palat from comment #6) > Since 3.14 for Java 9, Type Declaration Patterns can have module names also > embedded with the following syntax > [moduleName1[,moduleName2,..]]:[qualification '.']typeName ['<' > typeArguments '>'] > > Examples: > ◦java.base:java.lang.Object > ◦mod.one, mod.two:pack.X find declaration in the list of given modules. > ◦:pack.X find in the unnamed module. > > To note that module name(s) and the type declaration pattern separated by a > ':' character Why did you choose ':'? AFAICS most (all?) other situations use '/', e.g., in stack traces or JEP 261 options. Do type patterns accept binary syntax "java/lang/Object" (which would obviously a conflict)? Also, if ":pack.X" is too implicit for denoting unnamed module, you may consider using "ALL-UNNAMED/org.foo.Bar".
(In reply to Eclipse Genie from comment #10) > New Gerrit change created: https://git.eclipse.org/r/112628 (In reply to Stephan Herrmann from comment #11) > Why did you choose ':'? AFAICS most (all?) other situations use '/', e.g., > in stack traces or JEP 261 options. Do type patterns accept binary syntax > "java/lang/Object" (which would obviously a conflict)? > > Also, if ":pack.X" is too implicit for denoting unnamed module, you may > consider using "ALL-UNNAMED/org.foo.Bar". Thanks Stephan for the comments - Have incorporated both suggestions, added a few more test cases and the module graph based additions (list of module graphs actually) along with the above gerrit. Please note that now the Unnamed can be given implicitly as well with the explicit option as suggested. Now the relevant JavaDoc is modified as shown below - please let know if there are further comments. tia -----------snip------------- Since 3.14 for Java 9, Type Declaration Patterns can have module names also embedded with the following syntax [moduleName1[,moduleName2,..]]/[qualification '.']typeName ['<' typeArguments '>'] Unnamed modules can also be included and are represented either by an absence of module name implicitly or explicitly by specifying ALL-UNNAMED for module name. Module graph search is also supported with the limitTo option set to IJavaSearchConstants.MODULE_GRAPH. In the module graph case, the given type is searched in all the modules required directly as well as indirectly by the given module(s). Note that whitespaces are ignored in between module names. It is an error to give multiple module separators - in such cases a null pattern will be returned. Examples: ?java.base/java.lang.Object ?mod.one, mod.two/pack.X find declaration in the list of given modules. ?/pack.X find in the unnamed module. ?ALL-UNNAMED/pack.X find in the unnamed module. -----------snip------------- Under limitTo: -----------snip------------- MODULE_GRAPH: for types with a module prefix, will find all types present in required modules (directly or indirectly required) ie in any module present in the module graph of the given module. -----------snip-------------
(In reply to Manoj Palat from comment #12) > Examples: > ?java.base/java.lang.Object > ?mod.one, mod.two/pack.X find declaration in the list of given modules. > ?/pack.X find in the unnamed module. > ?ALL-UNNAMED/pack.X find in the unnamed module. > -----------snip------------- > To be read as the following: Examples: java.base/java.lang.Object mod.one, mod.two/pack.X find declaration in the list of given modules. /pack.X find in the unnamed module. ALL-UNNAMED/pack.X find in the unnamed module. The extra ? at the start was a contribution of editor (representing the item char)
Gerrit change https://git.eclipse.org/r/112628 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=8e405848a1fdb3ab38dabe1577508bb26c74fc36
New Gerrit change created: https://git.eclipse.org/r/112929
(In reply to Eclipse Genie from comment #15) > New Gerrit change created: https://git.eclipse.org/r/112929 A missed out case of simple types with modules - thanks Sasi for catching this - re-opening to address this with the above gerrit patch.
Gerrit change https://git.eclipse.org/r/112929 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=a678984d7982779ed3c443a9f934da63ceb684dd
search failing in one of the workspaces -needs further investigation -moving to M5
(In reply to Manoj Palat from comment #18) > search failing in one of the workspaces -needs further investigation -moving > to M5 getting a null binding for modules for the types in the failing workspace - under investigation
Created attachment 272206 [details] minimal workspace to reproduce the issue in prev comment Search for java.sql/java.sql.Driver in Type + Declaration with JRE search selected. The search will not return Driver declaration. Issue: Here the first project has compliance 1.8 though using the identical JRE 9 as of project second. When an openable is received at: JavaWorkspaceScope.packageFragmentRoot(String, int, String) line: 149 HandleFactory.getJarPkgFragmentRoot(String, int, String, IJavaSearchScope) line: 317 HandleFactory.createOpenable(String, IJavaSearchScope) line: 92 MatchLocator.locateMatches(SearchDocument[]) line: 1466 JavaSearchParticipant.locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor) line: 105 BasicSearchEngine.findMatches(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) line: 237 BasicSearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) line: 582 SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) line: 604 that of first comes up which a non-module-aware project . Consequently the ModuleBinding of the concerned type will not have the module name. and hence zero results. One option is to have multiple openables ?? in the works..
New Gerrit change created: https://git.eclipse.org/r/115292
Gerrit change https://git.eclipse.org/r/115292 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=527fe096a80b09ca7544d20eb9307c9c0523452e
Quick tests revealed the following issues I see a CCE when searching for module declarations named java.*. Another issue is that searching for type prefixed by module name returns types from non-modular JREs as well. For example, searching for java.base/Driver results in two matches, one from rt.jar and one from java.base module. I guess only one should show up. Will continue a little while longer and update if I see any others
Here's the stack trace of the CCE java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.classfmt.ModuleInfo cannot be cast to org.eclipse.jdt.internal.core.MemberElementInfo at org.eclipse.jdt.internal.core.Member.getNameRange(Member.java:351) at org.eclipse.jdt.ui.actions.FindOccurrencesInFileAction.getMember(FindOccurrencesInFileAction.java:140) at org.eclipse.jdt.ui.actions.FindOccurrencesInFileAction.selectionChanged(FindOccurrencesInFileAction.java:130)
Another thing that needs clarification is whether searching for a type declaration using the prefixed by module name pattern returns just types declared in that module or types visible in the context of that module. For example, if a project defining module mod.one has a jar on its build path (which is not a module) and if both declare a class named Driver (in different packages), if we search for mod.one/Driver, currently I see two results, one from the project and one from the jar, which is wrong
(In reply to Sasikanth Bharadwaj from comment #23) Thanks Sasi for testing out - my first response below > Quick tests revealed the following issues > > I see a CCE when searching for module declarations named java.*. This issue is due to a bug in the model tracked via bug 530024. > Another > issue is that searching for type prefixed by module name returns types from > non-modular JREs as well. For example, searching for java.base/Driver > results in two matches, one from rt.jar and one from java.base module. I > guess only one should show up. I get to see only one. need to investigate further/reproducible workspace for this > Will continue a little while longer and update if I see any others
Bulk move out of 4.9
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I am sure this is still relevant. Also see this PR that shows that some of the code introduced by this are unused. https://github.com/eclipse-jdt/eclipse.jdt.core/pull/1544
