Community
Participate
Working Groups
Created attachment 285764 [details] Screenshot showing unnecessary code recommendations Currently, when a code suggestion is requested without any context on how it might be used (i.e. simply typing "A" in a method and then requesting code suggestions for it), most suggestions are simply unnecessary for basically all users except JDK developers: Countless jdk.internal, org.graalvm, or com.sun classes get suggested, even though basically no one will ever use them in their project unless they are developing on the JDK internally. So, it would be nice if the user could define package prefixes that will automatically get excluded when requesting code suggestions. Default values for users should be: - jvm. - org.graalvm. - com.sun. - sun. - … (if anyone has more suggestions, please add.) By using this approach, any user can define themselves what packages they never want recommended. Whatever the internal algorithm used may be, implementing this should not be a huge performance decrease, in the best case it even speeds up searching for code recommendations.
The screenshot provides useful suggestions up until AtomicLong. Any suggestion below is simply irrelevant for all use cases. Beyond what it is visible, MANY more irrelevant suggestions are shown. The "AboutEvent" from java.awt.desktop is the first (somewhat) relevant suggestion again. After counting I can honestly say that there are (exactly) 100 irrelevant suggestions inbetween. That is simply frustrating.
If you check Eclipse Java preferences, there was a possibility to filter out such packages. Not saying the bug is irrelevant, just to reduce your frustration. And I agree, many packages should be excluded by default.
(In reply to Andrey Loskutov from comment #2) > If you check Eclipse Java preferences, there was a possibility to filter out > such packages. Not saying the bug is irrelevant, just to reduce your > frustration. Prefereneces > Java > Type Filters. > And I agree, many packages should be excluded by default. Yes, we should look at excluding some by default via the above preferences. Bug 511443 can be referred for some points to consider while changing the defaults.
Thanks, found it. > See Preferences > Java > Type Filters. Well, close enough, found it under > Preferences > Java > Appearance > Type Filters I agree too that the default values are definitively missing here and will be of great importance to be automatically inserted. I do have to say however that placing this option as part of "Appearance" is a little bit misleading, I would have rather expected it in "Code style", "Compiler" or "Editor"…
After some testing, adding the following default values seems the most sensible: - com.sun.* - jdk.* - org.graalvm.* - sun.* (- java.rmi.*) - this one will be controversial as there are people that use it but I'd say most Java projects do not use it.
java.awt is my personal favorite to exclide, because it has java.awt.List that constantly collides with java.util.List and because of that automatic imports are nkt working. Beside this, java.awt is mostly irrelevant today.
(In reply to Leon Hofmeister from comment #5) > - com.sun.* > - jdk.* > - org.graalvm.* > - sun.* +1 (In reply to Andrey Loskutov from comment #6) > java.awt is my personal favorite to exclide, because it has java.awt.List > that constantly collides with java.util.List and because of that automatic > imports are nkt working. Beside this, java.awt is mostly irrelevant today. +1 There is a risk, though. Would it be possible to add an entry to Content Assist that reminds people about active filters? Perhaps only if the proposals are empty?
(In reply to Andrey Loskutov from comment #6) > it has java.awt.List > that constantly collides with > java.util.List > and because of that automatic > imports are nkt working. Bug 573028 would be maybe a better approach than simply exclude it by default. The code-complete/suggest is sadly a bit to "dumb" in certain situations and could benefit from adding some heuristics (I was told IntelliJ is doing some good work in that area recently), e.g. with simply take into account: - what is already used in this class - what is used in other classes in the current project+dependent ones - what has the user chosen before - what is compatible in the given context
(In reply to Gunnar Wagenknecht from comment #7) > There is a risk, though. Would it be possible to add an entry to Content > Assist that reminds people about active filters? Perhaps only if the > proposals are empty? I would find it most natural to have something like google/amazon/whatever function: Your search result in no hits, but the following items are filtered and might contain something useful... That would require content-assist to have a flag that tells it is a filtered item that is only shown if nothing else matches (or in an extra list below the normal completions).
"io.micrometer.shaded." could be added to the defaults as well. This is a common use case for anyone using Spring Boot, or other popular frameworks that depend on Micrometer.
(In reply to Christoph Laeubrich from comment #9) > (In reply to Gunnar Wagenknecht from comment #7) > > There is a risk, though. Would it be possible to add an entry to Content > > Assist that reminds people about active filters? Perhaps only if the > > proposals are empty? > > I would find it most natural to have something like google/amazon/whatever > function: > > Your search result in no hits, but the following items are filtered and > might contain something useful... > > That would require content-assist to have a flag that tells it is a filtered > item that is only shown if nothing else matches (or in an extra list below > the normal completions). This can be handled in a separate bug based on the need. The above approach with a flag might be useful. Currently, there's a link to the type filters preference page on the Content Assist preference page which can act as a hint for the users.
(In reply to Leon Hofmeister from comment #4) > I do have to say however that placing this option as part of "Appearance" is > a little bit misleading, I would have rather expected it in "Code style", > "Compiler" or "Editor"… See bug 84472.
In reply to Leon Hofmeister from comment #5) > - com.sun.* > - jdk.* > - org.graalvm.* > - sun.* +1 Is the above list controversial? If not I suggest to start with this and discuss the other proposals like awt in a separate bug.
IMHO the proposals discussed here should likely be ranked lower (low relevance because not accessible by rules of JPMS). I filed bug 575064 as a general enhancement. Type filters could be seen as a poor-man's quick solution.
(In reply to Stephan Herrmann from comment #14) > IMHO the proposals discussed here should likely be ranked lower (low > relevance because not accessible by rules of JPMS). I filed bug 575064 as a > general enhancement. > > Type filters could be seen as a poor-man's quick solution. See also bug 48736.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/184251
Created attachment 286975 [details] Type filters - defaults (In reply to Eclipse Genie from comment #16) > New Gerrit change created: > https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/184251 This adds the defaults as shown in the screenshot. If a workspace has already defined type filters then this fix will not touch the enabled/disabled state of those existing type filters. It will just add the additional defaults from the above list. Also, the defaults are added only once so that the users have a way to opt-out if they don't want the new filters. This is handled in a way similar to bug 511443.
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/184251 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=40f7464d3fb782edf064f26c47068667b230c26d
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/184364
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/184364 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=67cf97d6b815f89d5779902c5de34e270d8294ea
Verified in I20210824-0600.
I really like to reopen this due to the 'java.awt.*' default enabled. Even though there are some cases (e.g. the list) where it could be annoying, but I really think this is a general issue of content assist not being context-sensitive/smart enough, this prevent usage of other useful classes from awt (e.g. BufferedImage, Colors and alike) and even prevents auto complete for constant field using this classes.
(In reply to Christoph Laeubrich from comment #22) > I really like to reopen this due to the 'java.awt.*' default enabled. > Even though there are some cases (e.g. the list) where it could be annoying, > but I really think this is a general issue of content assist not being > context-sensitive/smart enough, this prevent usage of other useful classes > from awt (e.g. BufferedImage, Colors and alike) and even prevents auto > complete for constant field using this classes. Christoph, please create new bug for this, especially if it is about "general issue of content assist not being smart enough". This one has code already merged and should be kept closed.
(In reply to Andrey Loskutov from comment #23) > Christoph, please create new bug for this, especially if it is about > "general issue of content assist not being smart enough". This one has code > already merged and should be kept closed. I could try to came up with a new bug, but the actual issue is that the code change here cause something a normal user could interpret as a regression (code completion suddenly does not work for any awt class), while from the comments the exclusion was meant to fix another problem (content assist not smart enough) so I'm not sure if the context of this bug would be more suitable...
The default file filter for the org.graalvm.* namespace severely impacts the usage of GraalVM user-facing APIs. I've filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=576708 to track this.
was there yet another change? we have failing tests with M2 again
java.awt.* -> java.awt.List
(In reply to Christian Dietrich from comment #27) > java.awt.* -> java.awt.List See bug 576549
