57

I'm currently working my way through the book "Teach Yourself Android Application Development in 24 Hours" published by Sams. I'm relatively new to Java, Android or otherwise. I have a very solid background in ActionScript 3, which has enough similarities with Java that the language itself isn't hard to grasp, but I do still have some questions about the rationale behind some of the code samples in the book. For example, here's a function that comes with the sample code for Hour 9:

private void processScores(final TableLayout scoreTable, 
      XmlResourceParser scores) throws IOException, XmlPullParserException{

In this function signature, the authors have declared the scoreTable argument as final. I'm a little puzzled as to why they did this. It wouldn't cross my mind to even attempt to assign a new value to the function argument scoreTable (it's considered a bad practice in ActionScript). Further, I haven't actually seen anyone do this in any of the real-world Java I've examined or ported into AS3.

Is there something specific about Android development that makes it a necessity to sometimes declare certain function arguments as final?

Why is the TableLayout object declared final, but not the XmlResourceParser?

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
scriptocalypse
  • 4,942
  • 2
  • 29
  • 41

1 Answers1

89

There are two main reasons you might want to mark an argument final. First, if you're planning on using the argument in an anonymous inner class, then you must mark it final so that it can be referenced in that class. This is actually a pretty common use case for marking arguments final.

The other common reason to mark arguments final is to prevent yourself from accidentally overwriting them. If you really don't want to change the arguments, then perhaps you should mark them final so that if you actually do, you'll get the error at compile-time rather than finding out at runtime that your code has a bug.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
  • Thank you, I definitely did not know this requirement in regards to anonymous inner classes. So then would it be safe to infer based on the fact that only TableLayout object is declared final that this function is using it strictly as a guard against careless coding? Why would it be more special in this case than the XmlResourceParser? Or are these only questions that the book authors might know the answers to? – scriptocalypse Feb 08 '11 at 06:28
  • @scriptocalypse- You know, I'm not sure. I would guess it's for the anonymous inner class case, since otherwise you're right and it makes more sense to mark them both final. I can't speak for the authors, though; perhaps you could contact them or the publisher? – templatetypedef Feb 08 '11 at 06:33
  • 4
    Actually the `anonymous inner class case` itself is a very good reason. In Android I find myself often using `OnClickListener` and `AsyncTask` classes and the ability to reuse these variables directly within them comes in handy. Another link for review: http://developer.android.com/guide/practices/design/performance.html#myths. – Sebastian Roth Feb 08 '11 at 07:02
  • How about optimization? Does the final keyword help with that? And what about Object arguments marked as final? You can still edit change their fields, iirc. – MrSnowflake Feb 01 '12 at 10:06
  • @MrSnowflake it's funny you ask about optimization. I've read in a couple of places that final references have a faster access time than non-final references in the context of an Android application. I have not benchmarked this at all, however. – scriptocalypse Mar 04 '12 at 22:23
  • I got stunk by this, and took me a day to figure out that I was assigning null onto itself. – Chad Jul 09 '13 at 23:38
  • 1
    Note that it seems that `final` arguments are not prevented from being modified internally, unlike C++ `const` arguments. – Erik Kaplun Nov 26 '13 at 18:11
  • @ErikAllik- Are you sure about that? Can you provide a reference for that? – templatetypedef Nov 26 '13 at 18:34
  • @ErikAllik In C++ one can use const in many ways: `const object * ptr_to_const_obj`, `object const * const_ptr_to_obj` (it's what Java final references are like), or even `const object const * const_ptr_to_const_obj`. – Krzysztof Jabłoński Dec 06 '13 at 08:58
  • yeah, I knew that; not sure why you pointed these things out. – Erik Kaplun Dec 16 '13 at 19:27
  • @ErikAllik I think he pointed it out because you noted that final arguments are not prevented from being modified internally, which made it sound like you were surprised that Java final references are like a const pointer to a non-const object in C++, rather than a pointer to a const object. You also said "unlike C++ const arguments" however the noted behaviour is in fact just like some C++ const arguments, as Krzysztof Jabłoński pointed out. – Lorne Laliberte Feb 11 '14 at 22:06
  • When an object is "const" in C++, then you can only call "const" methods on it and "const" methods. Which is different from Java, where you can call a setter on a final object. – vdolez Aug 26 '15 at 12:38