Community
Participate
Working Groups
Build ID: I20070621-1340 With p(Integer i) { } { int j; p(j); } I get an autoboxing warning at p(j) and the quick fix allows me to "add @SurpressWarning boxing' It would be nice if quick fix would also offer "explicit conversion to Integer" which would change j into Integer.valueOf(j), i.e. in the above example after choosing that quick fix I would get p(Integer i) { } { int j; p(Integer.valueOf(j)); } Dependency on Bug #128883: If you really implement the clean up action asked for in Bug #128883 then my request becomes void as it would handle this case too.
For compiler compliance <=1.4 this could be offered as a quick assist?
> For compiler compliance <=1.4 this could be offered as a quick assist? With Java <= 1.4, "p(Integer i) { } { int j; p(j); }" has a compile error, so you could only offer a quick *fix* to convert the call to "p(new Integer(j));" A quick *assist* would be interesting for Java >= 1.5 with the autoboxing warning disabled.
*** Bug 278518 has been marked as a duplicate of this bug. ***
*** Bug 328991 has been marked as a duplicate of this bug. ***
Is there any way to increase the priority of this? Just wondering, since it seems to have been around for a while, and I would think it's a pretty easy fix. Thanks, ~Scott
(In reply to comment #5) > Is there any way to increase the priority of this? The easiest way to get something is to provide a patch, especially since you think it's easy to do ;-)
Fair enough. I'll look at this. However, given that I'm not experienced in eclipse's internal workings, my assessment could be incorrect that it's easy to do. Did you have insight in this?
(In reply to comment #7) > Fair enough. I'll look at this. However, given that I'm not experienced in > eclipse's internal workings, my assessment could be incorrect that it's easy to > do. Did you have insight in this? No, sorry. Maybe Markus can give some.
An entry point to see how a similar quick fix / clean up is implemented: org.eclipse.jdt.internal.ui.text.correction.LocalCorrectionsSubProcessor.addUnnecessaryCastProposal(..). The same implementation should also be used to implement the multi-fix (so that you can fix several problems of the same category at once) and the clean up (bug 128883). See also references to org.eclipse.jdt.internal.corext.fix.CleanUpConstants.REMOVE_UNNECESSARY_CASTS to see how this is hooked up into the clean up infrastructure. The new clean up should go to the Code Style tab.
Ok, I think I have this working fairly well. I want to polish it up a bit before I post a patch. Specifically, I was wondering about strings. I have a string "valueOf" that's defined in my quick fix operation, and I'm not sure if I should externalize it. It seems like something that probably shouldn't be changed by a user without recompiling, so is it acceptable to leave it as a constant declaration, or should I place it in a preferences file somewhere?
(In reply to comment #10) > I have a string "valueOf" Can you give more details why/where you need it? > It seems like something that probably shouldn't be > changed by a user without recompiling, so is it acceptable to leave it as a > constant declaration Correct. Only translatable strings must be externalized.
> Can you give more details why/where you need it? Sure. Perhaps I'm doing this a bit incorrectly. I have the following in the AutoboxToExplicitConversionOperation.rewriteAST() method: Expression expr = (Expression)(placeholder); MethodInvocation me = fSelectedNode.getAST().newMethodInvocation(); SimpleName qualifier = fSelectedNode.getAST().newSimpleName( fWrapper.getSimpleName()); SimpleName name = fSelectedNode.getAST().newSimpleName("valueOf"); So, the last SimpleName call seems like it's kind of hard-coded. I'm really just wondering if this is acceptable, or if there is a better way to do it.
Also, I'm having a bit of trouble with the clean up section. I have it wired up in the code style tab, and can choose the option to automatically convert. When I hit 'Next', though, it doesn't actually register the IProblem. The code I am using to test is: public static void main(String args[]) { Integer i = 32; System.out.println("Integer: " + i); } What it finds for an IProblem when I run the CleanUp menu and select my new option and set a breakpoint in PotentialProgrammingProblemsCleanUp.createFix (I accidentally put it in here before I read what you said about putting it in the CodeStyle tab. I'm trying to get it to work first, then I'll move it over to the CodeStyle tab) is simply the problem about the non-externalized strings. I feel like I haven't quite hooked it up correctly, as the compiler doesn't seem to be returning the desired problems to the CleanUp logic. Can you give me some advice about how to get the compiler to return a selection of problems that I am desiring checking for?
(In reply to comment #12) > > Can you give more details why/where you need it? > > Sure. Perhaps I'm doing this a bit incorrectly. I have the following in the > AutoboxToExplicitConversionOperation.rewriteAST() method: > > Expression expr = (Expression)(placeholder); > MethodInvocation me = fSelectedNode.getAST().newMethodInvocation(); > SimpleName qualifier = fSelectedNode.getAST().newSimpleName( > fWrapper.getSimpleName()); > SimpleName name = fSelectedNode.getAST().newSimpleName("valueOf"); > > So, the last SimpleName call seems like it's kind of hard-coded. I'm really > just wondering if this is acceptable, or if there is a better way to do it. Yes, that's OK. Just make sure it's marked with //$NON-NLS-1$
(In reply to comment #13) > Can you give > me some advice about how to get the compiler to return a selection of problems > that I am desiring checking for? Sounds like your implementation of AbstractCleanUp#getRequirements() doesn't include the compiler option. See e.g. how UnnecessaryCodeCleanUp#getRequirements() builds a map with the JavaCore.COMPILER_PB_* option.
