Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Java

Posted by Roy Korenblit
Roy Korenblit
1,209 Points

Immutable fields.

Hello!

When Craig explained about immutable fields at the beginning of the video, he noted that the value cannot be changed after initialization. In the "Java Objects" course we learned about the "final" keyword in java, that is used to determine that a filed is in fact a "constant". In the video, we declare the fields - author, description and creationDate, which we don't want to be changed after initialization. Now, my question is, why Craig isn't using the "final" keyword when declaring the member fields?

Thanks for the help!

Steve Hunter
Steve Hunter
57,712 Points

Hi Roy,

Can you link to the video so I can get some context on why Craig doesn't want those three fields changing.

Thanks,

Steve.

Roy Korenblit
Roy Korenblit
1,209 Points

https://teamtreehouse.com/library/java-data-structures/getting-there/class-review Java Data Structures - Class Review. Sorry for the inconvenience.

2 Answers

Craig Dennis
STAFF
Craig Dennis
Treehouse Teacher
Craig Dennis
Craig Dennis
Treehouse Teacher

Great question Roy Korenblit !

Yes, I totally should be using final when I declare these variables! Wonderful eye on that and great instincts. This course originally was built on top of an older course that didn't introduce final. So as a student at this point, I couldn't talk about it, or expect you to know about it. You'll see later in this course that I introduce final as if it is the first time you might've seen it. I've refreshed Java Objects based on student feedback, decided to promote final as a concept. I am in the process of updating this course as well and will make note of this! Thanks!

The not adding setters is simply conveying that it is nobody's business outside of the class itself. Because you don't expose the ability to change it, by method access levels, no one can actually change it. To fully convey that it is immutable the final keyword is the way to go. Again, great instincts!

Roy Korenblit
Roy Korenblit
1,209 Points

Thank you very very much Craig Dennis , Steve Hunter. I was a little bit confused but now i got it and ready to advance with the course!

Steve Hunter
Steve Hunter
57,712 Points
Steve Hunter
Steve Hunter
57,712 Points

Thanks for the link, Roy.

I think that the access rights of setting a member variable as private and being 'immutable' are different. However, private member variables are immutable to anyone/thing outside of that class/object. They are capable of change only if you write the code to change them whilst they are not strictly immutable but they aren't exposed outside of the instance.

Happy to be corrected, Craig Dennis - I'll shout you on Twitter too ...

Steve.

Roy Korenblit
Roy Korenblit
1,209 Points

Thank you very much for the explanation Steve.

Just to be sure, the author, description and creationDate fields aren't actually immutable, but they cannot be changed outside of the class? and if i wanted them to actually be immutable, i would have to add to "final" keyword in order to set the fields as constants?

Steve Hunter
Steve Hunter
57,712 Points

They aren't immutable because of the lack of other code. If you added a setter method, that method could change the member variable's value without having to change how that variable is written. So making the variable (an immutable variable?) private doesn't give it the same properties as a final one. But without adding a setter method the distinction is wholly immaterial - there's no way to change its value without a way of accessing it.

Similarly, a final variable/constant constantly points at the same object. If you change the object, the constant still points at the same object, i.e. it is constant, but the value that object holds can change.

Java folk get very shouty about these (unnecessary) distinctions - have a look here.

Where we are here these things really don't matter - there's enough confusing stuff we need to know without getting embroiled in the fun stuff like this! :smile:

Steve.