Community
Participate
Working Groups
As of M5, bug 53773 adds a new compiler option to ignore/warn/raise errors upon assignments to parameters. The default value for this is ignore. The user may tune this as explained in bug 53773, but the option should ultimately surface into the compiler preferences.
Ok I will add the option. What is exactly bad when assigning a parameter?
(In reply to comment #1) I'm nto the originator or bug 53773, so take my words for my personal opinion only please. I personally believe that assigning to parameters is error prone in long methods, except in the case where the parameter needs some transformation that does not affect its semantics. What I mean is that, close to the end of the method body, if the parameter has been reused for convenience only in some intervening deeper block, you may get something else than what you expect, that is the value the caller passed in. Now, purists would say that long methods are bad style anyway! Another case where warning on such assignments can help is with programmers coming from languages in which assigning to parameters effectively changes the argument's value in the caller's code (then the warning reminds them that, in effect, the argument is left unchanged even if they assign to it). At least Pascal and C++ have parameters by reference (and by value), and my recollection may be wrong (haven't read a line of Pascal for fifteen years) but only 'var' parameters can be assigned to in Pascal, the compiler complaining for the others. The use of final for parameters, while enforcing the rule, hence doing a better job than a warning that can be disabled, looks odd and will do so until people get used to it. Moreover, it precludes the case in which you want to reuse the parameter (and accept to go with a warning) for a transformed value that matches the parameter semantics (aka fileName = fileName.replace('\\', '/')). Proponents of a clean separation of API and implementation code would also object that making a parameter final impacts the method signature, that is the interface, whereas it only has an interest for the implementor. But I'm afraid that interface separation is not the strongest feature of Java anyway... All in all, I would probably not have asked for this warning, but I can see why others asked, and I'd support their views. Even if for performance reasons we tend not to follow that rule anyway (see Philippe's comment in bug 53773). Again, my personal views only.
This is codestyle diagnostic. I would categorize this warning in the same box as: discouraging from using fields directly (rather use getter/setter) or prefixing field names with 'f' ... Nothing we will use for ourselves (for perf reasons), but some may be religious about it.
Thanks Maxime for your comments. Note that parameter modifiers are not part of the methods signature. You can override foo(final int i) with foo(int i) or the other way around. Not to be confused with C++'s const. Why I spoke up (as a wrote in bug 53773): Every new option adds complexity to core's and UI's code and documentation. That's bad for us but also for novice users that are overwhelmed with options. I think we should focus on options we are really convinced of. We better invest in a powerful reconcile/build participant infrastructure and let clients write and expertiment with extra plugins that implement the hunderts of personal, exotic and nice-to-have requests.
preference added > 20060117
