Community
Participate
Working Groups
I20071010-1200, also wrong in 3.3, was OK in 3.2.2 public class Try { STRING var; } - Organize Imports => was: adds import javax.print.DocFlavor$STRING; => expected: adds import javax.print.DocFlavor.STRING;
Most likely is bug 182179 the cause
verified in code that this is a dup of bug 182179 *** This bug has been marked as a duplicate of bug 182179 ***
Created attachment 81265 [details] Diff file between a fixed and non-fixed (3.3.1) version of OrganizeImportOperation This is a naive fix to the problem. It might not be entirely correct from API usage point of view, but it seems to work. Either include it, or fix the bug correctly, but don't let it lying.
As currently seems there is no activity for fixing the 182719, as it currently seems, they pretty much arrived to the conclusion that this is a feature and the caller of the buggy/feature-rich method should be doing the conversion from dollar-sign to dot, and that would lead to this bug not being fixed at all. Please fix this bug and don't wait for 182179. This is really a five-liner (see attached diff to a fix), don't let it lie low for months.
We have 18 references to TypeNameMatch.getFullyQualified and 21 to getTypeContainerName. I replaced them all with calls to our utility in JavaModelUtil to ease the users pain while we wait for JDT.Core to look at bug 182179. > 20071029
(In reply to comment #5) > We have 18 references to TypeNameMatch.getFullyQualified and 21 to > getTypeContainerName. > > I replaced them all with calls to our utility in JavaModelUtil to ease the > users pain while we wait for JDT.Core to look at bug 182179. Thank you, Martin.
Reopening to mark it as a dependent of the JDT/Core bug (as this requires a change in JDT/UI)
*** Bug 209146 has been marked as a duplicate of this bug. ***
*** Bug 212878 has been marked as a duplicate of this bug. ***
Let me congratulate the effectiveness of handling this bug and how you treat requests from users which take only an infinitely small effort from you (as the patch fixing it was already provided). There were at least a dozen users complaining about this bug on the bug tracker because THEY HAD ENCOUNTERED THIS BUG IN A SITUATION WHICH DISTURBED AND ADVERSELY AFFECTED THEIR PRODUCTIVITY (otherwise they wouldn't find it and wouldn't report it). A fix was provided for that than 4 months ago, yet you released a bugfix release (3.3.2) which did not included this bugfix. Instead of that you spent months debating how to fix this bug in a purist way sometimes later, several months in the future, if it would ever be fixed. Would it really have hurt you to fix the bug in a non-purist way in the 3.3.2 release, and then reopen the bug to make the purist change when you finally spend the effort to do something about it?
Robert, note that we added a workaround in the JDT.UI code 2 weeks after you reported the bug (comment 5). So no users were harmed by the long discussions. There are special rules of what goes in a maintenance build (3.3.2). This bug wasn't considered to be sever enough to qualify for a maintenance build fix.
(In reply to comment #11) > Robert, note that we added a workaround in the JDT.UI code 2 weeks after you > reported the bug (comment 5). So no users were harmed by the long discussions. > > There are special rules of what goes in a maintenance build (3.3.2). This bug > wasn't considered to be sever enough to qualify for a maintenance build fix. > May I ask what are those rules and what is then considered severe enough for a maintenance bug fix if this is not? Particularly, since I believe this bug was not present in earlier releases (although I might be wrong on that)... A mass organize imports should work as expected and should not create 90 compile errors of syntactically incorrect imports which was what I ended up with when I tried to upgrade to a new version of the Mysql NDB driver (which moved around static member classes) and do a mass organize import on my code. It took me a considerable amount of time just to go around and fix all those errors created by this bug, and I even were wary of ever using organize import in a single source file afterwards. If a fix for a bug such as this is not considered severe enough to be included in a maintenance build then I still feel my mail justified (only the target is slightly different) as the rules in my opinion are then worth reconsidering...
We concentrate on a limited number of a bugs for severe problem. From your description I now agree that we could have added this fix, but I think we didn't get any other bug reports for it. So it wasn't obvious to us how serious this bug is.
> we didn't get any other bug reports for it It seems that they ended up in JDT core and I wasn't aware of them.
Sorry Robert but we had no idea that you wanted it to be backported to 3.3.x. As Martin said, we didn't realize how important this bug was since this bug only has 2 duplicates only, none have votes, and all have a 'normal' severity.
(In reply to comment #15) > Sorry Robert but we had no idea that you wanted it to be backported to 3.3.x. > As Martin said, we didn't realize how important this bug was since this bug > only has 2 duplicates only, none have votes, and all have a 'normal' severity. > This bug was early on (before I submitted my patch) was marked as a duplicate of bug 182719. That bug has multitudes of duplicates marked. I looked at that, I also voted for THAT bug, and then asked that this be fixed, and provided the fix, because it was visible that no real progress was going on on that bug. If a bug is submitted against my product which is used by people every day, I don't expect that it would be accepted if I fix the bug in a development version from which the GA release would be several months later. If I did that, I would be fired, or if I contracted for that project the customer wouldn't give me more work. I filed the bug against 3.3.1 and not against 3.4M2 which was out, which I think indicates that I don't follow milestones eagerly. I provided the patch against 3.3.1. I pleaded that this bug be fixed and not delayed after bug 182719 is fixed. After these I did not assume that it is not clear without my explicitly saying so, that I hope that the fixed version would be released ASAP in a maintenance release and not as part of the new major release which is nowhere stable, and which is not really followed by major extensions at all because its API changes are probably too volatile, therefore probably it is not widely used.
*** Bug 232695 has been marked as a duplicate of this bug. ***
Created attachment 100889 [details] Screenshot
The problem happens with Eclipse 3.4 M7 again. If I read this bug report correct, it should have been fixed with M3. Screenshot attached. Build id: I20080502-0100 I cannot see there to change the status of this bug. Can someone please re-open it?
Sorry,I unintentionally used Eclipse 3.3. Please ignore my comment. 3.4 M7 works fine.
*** Bug 236965 has been marked as a duplicate of this bug. ***
