2014-04-23 0:43 GMT+04:00 Mark Thomas <ma...@apache.org>:
> On 22/04/2014 21:35, Konstantin Kolinko wrote:
>> 2014-04-23 0:30 GMT+04:00 Mark Thomas <ma...@apache.org>:
>>> On 22/04/2014 21:21, Christopher Schultz wrote:
>>>
>>>> Before posting, I checked just so I wouldn't embarrass myself. It
>>>> worked just fine. My guess is that you changed the implementation
>>>> to throw an exception after removing the 'final' which then makes
>>>> the 'final' legal again.
>>>
>>> I don't see any variation that includes final that compiles.
>>>
>>> Option 1:
>>>
>>> int final fipsModeState;
>>> try {
>>> fipsModeState = SSL.fipsModeGet();
>>> } catch (Exception e) {
>>> throw new IllegalStateException(e);
>>> }
>>>
>>>
>>> This failure looks correct to me since it should be illegal to change
>>> the value of a final variable after it has been declared.
>>
>> 1. s/ declared / assigned /
>>
>> 2. The syntax is
>> final int fipsModeState;
>>
>> ;)
>
> Doh!
>
> No objection to the final being restored, it is good practice to use
> final when possible.
>
> It isn't something that has been used much elsewhere in the Tomcat code
> base. Is there much benefit to going through and adding it everywhere it
> could be used? If I recall correctly, the UCDetector plugin can flag up
> all the places where this can be done and probably add them as well.
I think that it does not change the generated byte code, thus no real
difference.
It is good from documentation point of view (to express you intention
to do not change the variable).
If one goes pedantic way, I have seen code where 'final' was added to
all parameters of every method. I do not like that code style.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
