cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject 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
Date Mon, 03 Jan 2005 13:44:10 GMT
On Lun, 3 de Enero de 2005, 3:58, Sylvain Wallez dijo:
> wrote:
>>Author: antonio
>>Date: Sun Jan  2 13:26:59 2005
>>New Revision: 123903
>>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.

View raw message