Community
Participate
Working Groups
public class Tmp { static <T> T getValue() { return null; } public static void main(String[] args) { // String.valueOf((Object) getValue()); String.valueOf(getValue()); } } The above code calls String.valueOf(char[]), which is ok, since there are two candidate functions for a one-parameter Object call. When I want to change this call to String.valueOf(Object), I can add a cast in front of the getValue() call. But then, when cleaning up including “Remove unnecessary casts”, this cast is removed. It should stay though, since it is not unnecessary. In general, is it possible that the cleanup actions compare the bytecode of the cleaned up classes before and after the change, to make sure nothing essential has been changed?
Moving to UI for investigation.
String.valueOf((Object) getValue()) invokes the String.valueOf(Object) method, so the cast is actually unnecessary and should be removed by the clean up. String.valueOf(getValue()) in this example should also invoke String.valueOf(Object) method, which is the case when using JDK7. But it calls String.valueOf(char[]) if using JDK8. Looks like this is the issue that should be fixed. Moving back to JDT Core for analysis.
(In reply to Noopur Gupta from comment #2) > String.valueOf(getValue()) in this example should also invoke > String.valueOf(Object) method, which is the case when using JDK7. But it > calls String.valueOf(char[]) if using JDK8. Looks like this is the issue > that should be fixed. > > Moving back to JDT Core for analysis. This is the expected behavior according to bug 487118.
According to my understanding of “cleanup”, this should not be the expected behavior. In the example code given in the first comment, when I remove the "//", I, as the programmer, have decided that I want to call getValue(), then cast the returned value to Object, and then call String.valueOf(Object). Cleaning up code means to me that unnecessary syntactical elements are removed or beautified, and that the behavior of the code does not change. But when the cast is removed, the selected String.valueOf method changes, which is unexpected to me. Is there an general agreement on what “cleanup” means in the JDT context? Maybe it’s a different definition than mine.
(In reply to Roland Illig from comment #4) > But when the cast is removed, the selected String.valueOf method changes, > which is unexpected to me. Correct, this is an issue (after bug 487118). (In reply to Jay Arthanareeswaran from comment #3) > (In reply to Noopur Gupta from comment #2) > > String.valueOf(getValue()) in this example should also invoke > > String.valueOf(Object) method, which is the case when using JDK7. But it > > calls String.valueOf(char[]) if using JDK8. Looks like this is the issue > > that should be fixed. > > > > Moving back to JDT Core for analysis. > > This is the expected behavior according to bug 487118. Why is this not applicable to JDK7? For the clean up issue, adding a breakpoint at compilationUnit.getProblems() in: UnusedCodeFix.createCleanUp(CompilationUnit compilationUnit, boolean removeUnusedPrivateMethods, boolean removeUnusedPrivateConstructors, boolean removeUnusedPrivateFields, boolean removeUnusedPrivateTypes, boolean removeUnusedLocalVariables, boolean removeUnusedImports, boolean removeUnusedCast) shows that CompilationUnit.getProblems() returns: [Pb(181) Unnecessary cast from Object to Object] which results in the clean up removing the cast. CompilationUnit.getProblems() should not report the unnecessary cast problem in this case to fix this issue.
Sounds similar to the warning re redundant type arguments. In both cases the wrong warning enables a wrong quick fix.
Bulk move out of 4.8
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.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=573371
