• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Piet Souris
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
Bartenders:
  • Himai Minh
  • Carey Brown
  • Frits Walraven

OCP Java SE 11 Programmer I Study Guide (Sybex 815) Errata Chapter 6

 
Ranch Foreman
Posts: 650
14
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Before my OCPJP studies got interrupted, I was all bent out of shape over "effectively final", having gotten a related mock question wrong and thinking how dumb it was that "final" and "effectively final" are considered disjoint categories in the JLS, because I hardly saw any point of making that distinction.  I guess if something is "final" then we had better not re-assign to it or it won't compile any more, but if it is just "effectively final" that doesn't matter by itself unless someone makes use of it, for example in a local inner class or in a lambda.  Alright, I guess that is a reason to track the distinction all over the specification -- reassigning a final variable is always fatal to your compilation, whereas reassigning an effectively final variable usually makes no difference, except in the cases a lambda or local inner class tries to use it.  Wow, now that I calmed down I even agree.

I was wondering where I had gotten drummed into my head that ALL final variables were effectively final, rather than NONE of them, ever.
I was upset about getting the question wrong but my public defender appeared, read me the JLS and I went off to jail.

While reviewing, I found the offending source that misled me into thinking final variables were effectively final, it was the Sybex 815 book, Chapter 6.

Quoting from page 233 of Chapter 6 of the printed book:

Method parameters and local variables are allowed to be referenced if they are effectively final.  This means that the value of a variable doesn't change after it is set, regardless of whether it is explicitly marked as final.  If you aren't sure whether a variable is effectively final, add the final keyword.  If the code would still compile, the variable is effectively final.


First sentence: True but incomplete, they are also allowed to be referenced if final as well.

Second Sentence ("This means that the value of a variable doesn't change after it is set, regardless of whether it is explicitly marked as final."): No, final variables are not considered effectively final according to the JLS consistently, certification exams, and mock exam questions I already got wrong in the past.  I won't defend it beyond saying it is in the JLS and maybe I see why they make this hair-splitting distinction mused on at the top of the post.

Third sentence (" If you aren't sure whether a variable is effectively final, add the final keyword.  If the code would still compile, the variable is effectively final.") True but this only proves that final variables are not effectively final, because the following code will not compile:

jshell> final final int = 7
|  Error:
|  repeated modifier
|  final final int = 7;
|        ^


On page 237:

[The body of a lambda] can use any local variables or method parameters that are effectively final.
...
Exam Essentials:
...
Determine whether a variable can be used in a lambda body.
Local variables and method parameters must be effectively final to be referenced.  This means the code must compile if you were to add the final keyword to these variables.


Same comments.  The JLS wants us to consider final variables and effectively final variables two separate categories.  I already got another Sybex mock exam question wrong by forgetting that.  I won't fight the JLS (and for the first time today saw the distinction) but the 816 book makes very clear that effectively final and final are not the same thing.  Having this contrary description in the earlier chapter makes an already confusing situation more so.

p.s. I still love the book.  If I am fortunate enough to live a very, very long time I doubt I'll ever forget the definition of "effectively final" again...
 
Jesse Silverman
Ranch Foreman
Posts: 650
14
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Found the thread where others noted and I agreed with embarrassment how clear the first chapter of the 816 book (and corresponding chapter of the CSG no doubt) had been when I got the question wrong back in November:
https://coderanch.com/t/736559/certification/Sybex-Chapter-Review-Questions-Effectively

I wonder how important the distinction is for anyone not implementing Java themselves, but just using it.
Nevertheless, I prefer to stick to their terminology, so even if there are no certification questions covering it (only mock ones) I will continue to always try to "Talk about Java stuff like the JLS does".
 
Jesse Silverman
Ranch Foreman
Posts: 650
14
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Explanation for the Chapter's Question 13 also says:

Lambdas are only allowed to reference effectively final variables. You can tell the variable j is effectively final because adding a final keyword before it wouldn’t introduce a compile error.



Same False, True response as above.
 
Jesse Silverman
Ranch Foreman
Posts: 650
14
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I now see another reason to separate "effectively final" from final.
The "effectively final" concept does not apply to static or instance members of classes, interfaces or enums, whereas final applies to all of those.  Well except instance members of interfaces which don't exist.  All the others can be explicitly final but are never said to be "effectively final".

That leaves method, constructor and lambda parameters and variables as things that could be "effectively final".
 
author & internet detective
Posts: 40685
827
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see your point and have added it to the list of things to consider in the next edition.
 
reply
    Bookmark Topic Watch Topic
  • New Topic