Bugzilla – Full Text Bug Listing
| Summary: | [quick fix] Wrong quick fix suggested to eliminate synthetic class warning | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Palmer Eldritch <the.ubik> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P4 | CC: | markus.kell.r, noopur_gupta, srikanth_sankaran |
| Version: | 4.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
Pass to UI for comment. Pass back if we have our finger in the pie somewhere. The quick fix suggests to change the visibility of 'InnerNode' as the warning is shown at 'InnerNode'. Hence, similar to all other cases where this warning is displayed at the problem node, here the node to be updated is considered as 'InnerNode' instead of 'Node'.
If the warning is shown at 'Node', then the quick fix should suggest to change the visibility of 'Node', which will solve the issue:
private final class InnerNode extends Node {}
^^^^
If the problem location cannot be changed then this case has to be handled separately in the quick fix. See: ModifierCorrectionSubProcessor#addNonAccessibleReferenceProposal
I think the problem locations are as good as they can be. When there's no explicit constructor, the type name serves as a stand-in.
We need special processing for IProblem.NeedToEmulateConstructorAccess for all four cases (implicit/explicit constructor present in super/sub-class). Note that ModifierCorrectionSubProcessor#addNonAccessibleReferenceProposal is used in many different situations, so be careful not to break other scenarios.
More examples:
public class Tree<K, V> {
private abstract class Node {
private Node() {}
}
private final class InnerNode extends Node {}
private final class InnerNode2 extends Node {
public InnerNode2() {
foo();
}
}
private static void foo() {}
}
Note that "private" on nested classes is a very special beast. Here, it's enough to make the constructor non-private. That doesn't make sense, but that's how it is.
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. |
Copy paste this in a file with synthetic warnings enabled public class Tree<K, V> { private abstract class Node {} private final class InnerNode extends Node {} } You will receive > Access to enclosing constructor Tree<K,V>.Node() is emulated by a synthetic accessor method The quick fix suggested is to change visibility of InnerNode to package - once applied it produces : public class Tree<K, V> { private abstract class Node {} final class InnerNode extends Node {} } which displays the exact same warning and same quick fix which when applied is a noop naturally Eclipse Java EE IDE for Web Developers. Version: Luna M7 Release (4.4.0M7) Build id: 20140508-1440