Re: svn commit: r123903 - in cocoon/branches/BRANCH_2_1_X/src: blocks/batik/java/org/apache/cocoon/components/transcoderblocks/batik/ java/org/apache/cocoon/components/url blocks/fop/java/org/apache/cocoon/components/rendererblocks/fop/java/o rg/apache/cocoon/serialization blocks/portal/java/org/apache/cocoon/portal/implblocks/portal/java/org /apache/cocoon/portal/pluto blocks/scratchpad/java/org/apache/cocoon/generationjava/org/apache/coc oon/components/classloader java/org/apache/cocoon/generationjava/org/apache/cocoon/xml/dom

[Antonio Gallardo <ag...@agssa.net>]

On Lun, 3 de Enero de 2005, 3:58, Sylvain Wallez dijo:
> antonio@apache.org wrote:
>
>>Author: antonio
>>Date: Sun Jan  2 13:26:59 2005
>>New Revision: 123903
>>
>>URL: http://svn.apache.org/viewcvs?view=rev&rev=123903
>>Log:
>>Set static variable as final
>>
>>
>
> Why should all static variables be final? This is necessary for public
> constants, but not for internal variables. Although this changes nothing
> for variables initialized when declared (e.g. "private static Map map =
> new HashMap()").

Thanks for reviewing the code. :-D

No "private" variables were changed. I am assuming that you were talking
about "protect" variables....

What I understand is:
A "final reference" (as are all the committed cases) means we cannot
rebind the variable to a new object. While is posible to change his
internal values using the object methods.

I agree, this is less useful than a final applied on a primitive, but we
cannot said this don't change nothing at all. It adds a new restriction
that IMHO is a little bit better. ;-)

> it IMO reduces readability when the initialization involves several
steps in a static block as below:

Agreed, please review the new commit using "blank final".

Best Regards,

Antonio Gallardo.