Community
Participate
Working Groups
Build ID: M20071023-1652 Steps To Reproduce: The following code is altered by the clean-up function to something that won't compile. The original: Integer a = 0; char b = (char)((int)a); Cleaned up: Integer a = 0; char b = (char)(a); But you can't convert an "Integer" object to a char directly. It's probably "best practice" to use the intValue() function of the Integer object, but using clean-up should not result in code that won't compile.
The clean up removes all casts which are flagged as unnecessary by the compiler. I guess the compiler is wrong here as the cast is not unnecessary but the compiler flags it as unnecessary. Moving to core
I guess your project is using 1.5 settings.
(In reply to comment #2) > I guess your project is using 1.5 settings. > If you are referring to the JRE/JDK I'm using it's sun-jdk-1.6.0.04 If you mean the compiler compliance level, it's set to 6.0 If you mean anything else, maybe, I have no idea
Indeed the cast is necessary. I wonder if a more general solution would also to stop treating cast as unnecessary as soon as they induce a boxing/unboxing conversion; e.g. Integer a = 0; int i = (int) a; // currently flagged as unnecessary For documentation purpose, we should allow user to document their boxing/unboxing operation explicitly, like we do for explicit casts of null values (which is good practice in general).
And maybe even go further as to stop signaling implicit boxing/unboxing when an explicit cast is speficied (i.e. it is no secret any longer).
Thinking more about it, I would rather address this very scenario with 2 casts nested in each other.
Created attachment 95498 [details] Proposed patch
Added AutoboxingTest#test153. Patch is unfortunately made bigger due to simultaneous code cleanup/reformatting. Real change was actually quite small.
Released for 3.4M7. Fixed
Verified for 3.4M7 using I20080427-2000
