[java] Fix ClassCastException in UnnecessaryLocalBeforeReturn

[jsotuyod]

• This fixes [java] UnnecessaryLocalBeforeReturn: ClassCastException in switch case with local variable returned #219

[jsotuyod]

@adangel I think we should consider several changes to this rule. Please let me know what you think and We can add issues to track each individually.

1. This should probably be moved from the design ruleset to the unnecessary ruleset.
2. We should probably drop the requirement for the declaration and the return being in consecutive lines, and simply check the number of uses of the variable being > 1. This also means no need for the current assert lookup.
3. Given that we actually do item 2, this rule could be expanded to all "unnecessary" variables, not just return statements. We could add a property to allow such variables if declared as final. The Java code will produce an extra store / load instruction in bytecode, but being final, the JIT will remove them and effectively be the same for long running processes.

[adangel]

@jsotuyod

1. yes - I myself first searched this rule first in the unnecessary ruleset. This would be a change for master branch / 5.6.x, to avoid surprises if the rule suddenly pops up / disappears.

2. This definitely makes sense and would be an enhancement for 5.5.x

3. I would see this for the master branch (maybe even for 5.5.x, too). We could basically create a successor rule "UnnecessaryLocal" and retire "UnnecessaryLocalBeforeReturn". Sounds like the DeadStore rule from FindBugs...

[jsotuyod]

3. Yes, but without the false positives introduced by javac:

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives

http://findbugs.sourceforge.net/bugDescriptions.html#DLS_DEAD_LOCAL_STORE

Doing 2 and 3 makes no sense if both are merged into 5.5.5 and we retire UnnecessaryLocalBeforeReturn. Being 5.5.5 a bug fixing release I'd not be comfortable retiring a rule in it. Either we leave it as deprecated for a while (5.6.0 or 5.7.0?), or we should do only item 2 for 5.5.5 and the new rule for 5.6.0.