• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Given effectively final ...

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... has the following class :



... gone from being effectively immutable to immutable ?

Thanks
 
Marshal
Posts: 69411
276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No.
 
Campbell Ritchie
Marshal
Posts: 69411
276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It wasn't immutable in the first place.
 
Saloon Keeper
Posts: 12008
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And it's still not immutable.
 
Ranch Hand
Posts: 127
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe not the right way to reply, but: Can someone explain to me what's asked here and why the answer is "no, cause it wasn't final to begin with"?
As far as I know anything without explicit access modifier becomes default to what's often called package private. So I'm aware that at any given point in time the two members could be modified by not just subclasses but any class within the same package. But the compiler has no way to know it. So, is this the reason as to why it can't be even effectively final as the compiler can't verify that there's no external manipulation possible?
 
Michael Farragher
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Ok - the above should have been my class
 
Campbell Ritchie
Marshal
Posts: 69411
276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please remind yourself of the requirements for immutability.
 
Stephan van Hulst
Saloon Keeper
Posts: 12008
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bob Winter wrote:why the answer is "no, cause it wasn't final to begin with"?


Campbell answered that it wasn't immutable to begin with, not that it wasn't final to begin with. Which it isn't either, but it matters to be precise.

I think the question is roughly: Here is a class that is effectively immutable. Whether a class is "effectively immutable" or "immutable" depends on whether the fields of the class are final. Since Java 8, variables can be "effectively final". Does that mean that this class has gone from "effectively immutable" to "immutable"?

Our answer to that question is "no", because the question wrongly assumes that the class was effectively immutable to start with, which it isn't because of two reasons:

  • The fields are not private, meaning they can be mutated from another class in the same package.
  • The getters can be overridden to return different values.

  • However, even IF the fields were private and were only returned from methods that can not be overridden, the answer would still be "no", because the qualifier "effectively final" only applies to local variables and not to fields.

    Finally, I think the question is meaningless because as far as I know the terms "immutable" and "effectively immutable" don't have any fixed and clear definitions from authoritative sources. The distinction between the two terms doesn't seem to serve any purpose. In conclusion, I think a better answer than "no" is "who cares?".
     
    Master Rancher
    Posts: 3537
    39
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:However, even IF the fields were private and were only returned from methods that can not be overridden, the answer would still be "no", because the qualifier "effectively final" only applies to local variables and not to fields.


    I'd like to build a bit more on this.  It may sound like this is just a semantic argument.  But in fact, if a field is "effectively final" (it's private with no methods to change it) but the field is not actually marked final, then there are almost always ways that it's still "mutable" under certain conditions.  In particular if you use such an object in a multithreaded environment, it's possible that some threads will observe the field in its uninitialized state - meaning null, or zero.  (Or false.). Even if you code looks like that field must have been initialized in the constructor, and never changed anywhere else.  The compiler and JVM are allowed to re-order some of the operations in your code, in ways that make perfect sense in a single-threaded environment, but which can create surprising side effects in a multi-threaded environment.  If you want an immutable object, you need to make the fields final, period.  (Among other requirements; this isn't a complete discussion, just emphasizing the one point.). There is no such thing as an effectively final field, because without final, other threads may see it as null or zero.
     
    Campbell Ritchie
    Marshal
    Posts: 69411
    276
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Yes, I thought “effectively final” applied to local variables and not to fields.
    Even if the fields were final, that class wouldn't be immutable because it is possible to subclass it and change its state some way or other.
     
    Mike Simmons
    Master Rancher
    Posts: 3537
    39
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:Yes, I thought “effectively final” applied to local variables and not to fields.


    Yes, as Stephan noted.  I was expanding on why that's the case.

    Campbell Ritchie wrote:Even if the fields were final, that class wouldn't be immutable because it is possible to subclass it and change its state some way or other.


    Right, but I didn't think it necessary to repeat what was already well-addressed in Stephan's post.  I agree with everything he said.
     
    I wish to win the lottery. I wish for a lovely piece of pie. And I wish for a tiny ad:
    Devious Experiments for a Truly Passive Greenhouse!
    https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
      Bookmark Topic Watch Topic
    • New Topic