Talk:Final (Java)

This page was all wrong about final variables.

First, they are not like "const" in C++ since in that language a const field is limited not only to not being reassigned, but there is the additional limitation that only const methods can called on it and it can only be passed as the const argument of other methods.

Second, (non-static) inner classes can freely access any field of the enclosing class, final or not.

Final Local Variables and Arguments

Arguments and local variables can also be declared final. I'm not entirely sure how it works, but I think it should be included in this article.

Thejoshwolfe (talk) 07:53, 21 November 2008 (UTC)

• the same applies to local variables (and function arguments) as to class fields: They must be assigned to at most once (and must be assigned to before being used). Arguments are already assigned when the function body entered. 78.102.120.26 (talk) 06:53, 5 March 2009 (UTC)
• "C++ const is a soft guideline and it can easily be overridden by the programmer" - that's terrible advice, since it implies altering values would be fine like that without mentioning the rapid descent into the realm of undefined behaviour

--144.124.46.39 (talk) 17:45, 12 September 2011 (UTC)

• • I noticed that and removed it immediately. The author definitely did not know what he was talking about. Unsuspected (talk) 15:46, 11 October 2011 (UTC)
  • Please explain. It is well known that code can simply cast away const. Just do an Internet search on "c cast away const". I've heard C/C++ compiler architects say this and that const is just a programmer documentation convenience. This wasn't stated as advice as in what is good style or recommended. It's how the feature works in the C/C++ languages. I will reinstate that sentence. Ramses89 (talk) 18:05, 16 April 2013 (UTC)

Blank final

Anybody want to add something about blank finals? Otherwise I'll add it at the end of next week when I will have a lot more time.Smallman12q (talk) 02:08, 4 July 2010 (UTC)

final and inner classes

I think the content of this section is slightly misleading. If a variable is declared final within a method, isn't it then permanently available to an *instance* of the private inner class, not statically to the class? This section makes that ambiguous at best, particularly the statement: "the original variable is gone but the inner class's private copy persists in the class's own memory". Am I right? — Preceding unsigned comment added by Esilverberg (talk • contribs) 14:01, 22 April 2014 (UTC)

final variable section style

The section on the final variable says:

It is considered good practice to represent final primitive type variables in all uppercase, using underscore to separate words.

This does not match the reference which states:

Names representing constants (final variables) must be all uppercase using underscore to separate words.

As mentioned in in the sentence immediately preceding the questionable one:

Unlike the value of a constant, the value of a final variable is not necessarily known at compile time

The two sentences are in conflict when the reference is taken into account. I have rectified this, though it is a rather sweeping change. Furthemore, I have edited out the part about only primitatves follow this style as it is not uncommon to see objects have this style too (Color.RED and BigDecimal.ZERO (both objects - not primitives) being two quick examples)--Shagie (talk) 01:13, 30 May 2013 (UTC)

Comparison with C# readonly

There's a section comparing "final" to C++ "const". How about a section comparing it to "readonly" in C#? RenniePet (talk) 14:33, 31 July 2013 (UTC)

Final variables: Debugging Help

Would it be worth it to also note in the article that if a String is defined as static when you mouse over the variable you can see the string literal to which it's been assigned? Mfelzani (talk) 19:01, 26 November 2013 (UTC)