Community
Participate
Working Groups
build I20050322 + Jdtcore head JavaCore#CODEASSIST_FORBIDDEN_REFERENCE_CHECK and JavaCore#CODEASSIST_DISCOURAGED_REFERENCE_CHECK options have been added. If these options are enabled non accessible types will not be proposed by completion. If these options are disabled non accessible types will be proposed but will be less relevant than other completion. JavaCore#CODEASSIST_FORBIDDEN_REFERENCE_CHECK replace the old option JavaCore#CODEASSIST_ACCESS_RESRICTION_CHECK. These new options need to be show inside the code assist preferences.
These options are not inside build I20050322
Values for these options will be probably changed (see bug 90612). I will inform you when this API will be really ready.
There is finally only one option: CODEASSIST_HIDE_RESTRICTED_REFERENCES. /* * CODEASSIST / Hide Proposals for Restricted Completions * When value is "never", never hide proposals for restricted completions. * When value is "error", hide proposals for restricted completions if insertion of these completions would create a compile error. * When value is "warning", hide proposals for restricted completions if insertion of these completions would create a compile error or warning. * To configure the severity of restrictions, "org.eclipse.jdt.core.compiler.problem.forbiddenReference" * option must be used for forbidden reference and "org.eclipse.jdt.core.compiler.problem.discouragedReference" * option must be used for discouraged reference. * - option id: "org.eclipse.jdt.core.codeComplete.restrictionsCheck" * - possible values: { "never", "error", "warning" } * - default: "error" */ public static final String CODEASSIST_HIDE_RESTRICTED_REFERENCES;
This is time permitting for M7 (might get moved to RC1)
added for M7. Wording needs to be improved.
appoved for M7 candidate build
Fixed > 20050510. The preferences now read: [ ] Present proposals in alphabetical order [ ] Hide proposals not visible in the invocation context Hide restricted references of this severity: {Do not hide, Error, Warning} Also added a link from 'restricted references' to the problems & warnings page.
While the current approach is powerful it is strange from a user point of view. I would expect that code assist restrictions are connected to the access rules 'forbidden' and 'discouraged' without having some other preferences in-between. In addition, this currently workspace-only preference produces different results since it depends on project specific compiler preferences. Without saying how the preference in JDT Core should I'd like to have something like this in the UI: [ ] Hide forbidden restricted API [ ] Hide discourage restricted API or: Hide restricted API: [ no | discouraged | forbidden | discouraged and forbidden ] We need another iteration on this one.
If you do as say in comment 8, some problem will occur when two project does not have the same compiler options. example: Project P: - contains a class p.X Project P1: - P is on the classpath with an acces rule "p/*" - usage of a forbidden reference is an error Project P2: - P is on the classpath with an acces rule "p/*" - usage of a forbidden reference is not error (ignore) The global code assist options "Hide forbidden restricted API" is enabled. If you perform a code assist inside P1 then X would not be proposed. That's seems correct because X would create a compile error. If you perform a code assist inside P2 then X would not be proposed. But why X would not be proposed because the user decided that forbidden reference is not an error ? So in this case code assist would not be able to propose a valid code that could be directly written by the user. That's why the JDT/Core options is based on error severity instead of restriction kind.
To reiterate: please enter a separate defect. We will not change this for M7, but may polish this during RC1. The intent of the current story is to centralize the severity control in one location, and have codeassist simply check the severity of compiler to determine the filtering semantics. So in brief, if user decides forbidden is only a warning, then why should codeassist need extra config to hide it ? Now I understand that presenting this in UI is non trivial.
>The intent of the current story is to centralize the severity control in one >location, and have codeassist simply check the severity of compiler to >determine the filtering semantics. You got it! I fully agree that this is a desired direction but this is an orthogonal feature which makes sense for all compiler/code style errors warnings since this would catch stuff like: - warnings/errors created for deprecation - warnings/errors created for auto-boxing - warnings/errors access restrictions - ... To just use this pattern for access restrictions is not a good idea. We can investigate in 3.2 whether we offer filtering based on compiler errors and warnings. In addition if a project specifies to not show any errors and warnings for the restriction (let's assume shared via CVS) but you'd still like to filter restricted API you cannot do so with the current approach. >We will not change this for M7, but may polish this during RC1. If we cannot agree on a solution for M7 we will have to remove the UI for M7 and wait for RC1. The current solution is confusion for the user, especially when there are project specific settings.
Philippe and I discussed this and we agreed on the following: we leave the current preference UI which is based on warnings/errors in for M7 as a temporary solution so that people can start to play with it and test the feature. For RC1 there will be JDT Core option(s) that allow to hide/filter based on the access restriction type (none, forbidden, discouraged, forbidden or discouraged) (see bug 94403) and the preference UI will surface those. Marking this one as fixed.
verified in I20050513-0010 that the options shows up and has the expected result on the proposed completions.
