Oliver Wong

thanks...then using "final" is really a good practice that every java
programmer should know....

btw, any comment on the style of static class as above?

Or, to put that another way, it's a waste of time when used for a parameter or
local variable.

If you don't want to change the value of a local variable, then don't change
it...

True, and that /is/ a valid and important use.

   -- chris

In Java, whether or not a parameter is "final" is of no interest
whatsoever to the caller of the method:

- A method can never change the in-parameters themselves (as seen by
the caller), whether or not the parameter is declared as "final". That
is, all parameters are always passed by value, none are passed by
reference.

- A method can always change the contents of any object whose
reference is passed to it, whether or not the object reference
parameter is declared as "final". (*)

The "final"-ness of a parameter is only relevant to the internal
implementation of the method itself. I personally consider it an
unfortunate quirk of the language that this information is exposed to
client code.

Personally, I would have preferred all parameters to be defined by the
JLS to always be final. It would do away with the above quirk and it's
generally not such a good idea to start altering the method's
parameters anyway (in my experience, this is most often indicative of
some sort of bug and tends to make for less maintainable code even
when it is not).

* - Assuming the class involved is mutable, of course.

Cheers
    Bent D

 I am starting to build a grand repository here:

http://www.purl.org/stefan_ram/pub/ram-jar

 This repository has been reformatted to a more common style
 for the convenience of others, while I internally use my
 personal style.

 In Usenet-Postings I use my personal style, because
 reformatting would be too much effort.

 A rationale for this style:

   Indentation within Braces

     An indentation of just one space often is too small to be
     seen clearly, because the natural width and form of
     characters often varies by an amount that is not very much
     smaller than a space. Therefore, the indentation should
     amount to at least two positions. In order not to waste
     horizontal spaces, an indentation of exactly two positions
     is chosen. This means, that the left position of the next
     level is two larger than the position of the directly
     enclosing level.

     Indentation by two positions within a block

{ ++x;
 ++x; }
^ ^
0 2

     Bad   A small indentation by one position is not always
     visible clearly

{++x;
++x; }

     Good   The indentation by two positions is visible clearly

{ ++x;
 ++x; }

     Bad   A large indentation by more than two positions wastes
     horizontal space with no additional benefit

{    ++x;
    ++x; }

   Spaces within braces

     In mathematics, there are often no spaces at the inner
   side of parentheses or braces in expressions, but spaces
     are used indeed at the inner side of braces in set
     notation, when the braces contain a description (not when
     they contain a list).

     Spaces in set notation

{ x  | x  > 2 }

     This style is adopted here: One space is written at the
     inner side of braces.

     Spaces at the inner side of parentheses within a block

{ ++x; }

     This style is consistent with the indentation by two
     positions, because only using this style, corresponding
     parts of two lines have the same position.

     Bad   No space after the first brace, the two statements are
     misaligned

{++x;
 ++x; }

     Good   One space after the first brace, the two statements
     are properly aligned

{ ++x;
 ++x; }

     Bad   Two spaces after the first brace, the two statements
     are misaligned

{  ++x;
 ++x; }

     There are some exceptions to this rule: No spaces are used
     within empty braces "{}" and between two or more closing
     braces of the same direction "}}", except, when the first
     one of them is part of an empty pair "{} }" (an empty pair
     of braces if treated like a single non-braces character).

   Unified rules for all Brackets

     For simplicity and uniformity, the rules from above apply
     to all kinds of brackets, including parentheses, braces
     (curly brackets), square brackets, and angle brackets.

     Spaces within parentheses and square brackets

{ y = f( x )+ g() + a[ 2 ]; }

     Binary operators are surrounded by a space, but the space
     is omitted, when there already is a space on the other
     side of a sequence of bracket directly beside the
     operator: By this rule " )+" is written instead of " ) +".

   Representation of the Syntactical Structure

     A method declaration in Java consists of a head and a
     body. The following representation shows this structure:

     Good formatting according to the structure

void alpha() // head
{ beta(); }  // body

     The following formatting is misleading, because the line
     break does not match the structural break:

     Bad   line break within the body

void alpha() { // head and the beginning of the body
 beta(); }  // the rest of the body

     This formatting also would make no sense for blocks within
     blocks. So it is often not used for such blocks. Therefore
     even the adopters of this style can not use it uniformly.

   Left Braces Look Like "bullets"

     There is a well known style to publish lists in typography
     using bullets sticking out on the left, looking like this:

     Common list representation with bullets in typography

o This is the first point
 of this list, it is written
 here just as an example.

o Here is another entry

o This is another example given
 just as an example to show
 an example

     The braces of the beginnings of blocks stand out on the
     left just the same, when the formatting being described
     here is used, so they look quite naturally as
     beginning-of-a-block markers, when one is used to the
     typographical list notation:

     Left braces look like bullets to mark blocks

{ printf(); printf();
 printf(); printf(); printf();
 printf(); printf();   }

{ printf(); printf(); }

{ printf(); printf(); printf();
 printf(); printf();
 printf(); }

   Neutrality

     Someone wrote this C code:

     Code someone wrote

while( fgets( eingabe, sizeof eingabe, stdin ))
 if( sscanf( eingabe, "%d", &wert )!= 1 )
   fprintf( stderr, "Please enter a number!\n" );
 else
   summe += wert;

     It amazes me that I can add braces by my style conventions
     without the need to change the position of any character
     of the given code:

     The code from above plus braces

while( fgets( eingabe, sizeof eingabe, stdin ))
{ if( sscanf( eingabe, "%d", &wert )!= 1 )
 { fprintf( stderr, "Please enter a number!\n" ); }
 else
 { summe += wert; }}

Hmm, well, I've never done any work with applets, so I'll reserve
judgment.  It sounds to me like maybe class variables were used where
the should not have been, but I don't know the full story.