Bugzilla – Full Text Bug Listing
| Summary: | [quick fix] Quickfix 'add unimplemented methods' doesn't find ambiguity | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Oly <oliver.dungey> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
Agree about the String. This is known. Better don't define a class String yourself... The final modifier is not part of the method signature, it's a method local attribute, it makes no sense to duplicate it in an overridden method. I didn't want to have a class called String as its a right pain: there are some technical reasons why I had to do this. You say its a known issue but is it one that will be addressed? As for the final: In my classes I like to make heavy use of final to express the intent not reasign the variable in the function. When I put it on an abstract methods arguments in a base class or inteface It is there for good practice and thats what I want people to implement when they put in their methods ..... it would be really good if the quick fix just took the method a bit more 'as is' rather than changing it. It won't be addressed for 3.1. We will see if it is a candidate for 3.2. It might be quite expensive to get this right, so we have to see if fixing a corner case is worth slowing down the normal use cases. We might want to think about a option 'make all new parameters/variable final by default', regardless if created by the override wizard, getter/setter wizard ect. I like your idea of a setting ... sort of a strict mode: I've always wanted a language that defaults to full lock down unless otherwise specified i.e. private final etc. I get fed up with correcting sloppy coding. I have a similiar problem. I have a class Map in my current package. Another class handles drawing the Map to a Graphics context. I create an inner class that extends Graphics (for testing) and then add unimplemented methods creates an import statement to java.util.Map. Easy enough for me correct but annoying 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. |
This is a pretty simple one: in my package I have a class called 'String'. I created a base abstract class with a method in it with the following signature: public abstract fromString(final java.lang.String stringValue); The qualification of String in the above signature is obviously to resolve ambiguity with my own class called String. I then created a class derived from my base class and used the quick fix to add the method signature for the above and it created a method: public fromString(String stringValue) {} Which doesn't work because it is the wrong 'String' and should be 'java.lang.String'. In addition it robbed the final keyword off the signature which is annoying. I am using build I20050513-1415