File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes About Non Static Final Methods/Variables Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "About Non Static Final Methods/Variables" Watch "About Non Static Final Methods/Variables" New topic
Author

About Non Static Final Methods/Variables

Mahesh Karehonna
Greenhorn

Joined: Apr 02, 2013
Posts: 6
If i create "final Non-Static methods/variables" in class, are these methods/variables will be having multiple copies in memory each time i create a new objects for this class...?
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Welcome to the ranch Mahesh.

Each object will maintain a copy of it's own instance variables when it gets created on the heap using the new operator and constructor.

The methods are loaded on the stack as and when you invoke them using object.methodName(). I don't think there is any such thing as all objects having a copy of the method.


~ Mansukh
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mansukhdeep Thind wrote:The methods are loaded on the stack as and when you invoke them using object.methodName().


No they're not. Methods live in the method area, which is part of the heap. They're not copied to the stack. That would be pointless.

I don't think there is any such thing as all objects having a copy of the method.


Correct. There's only on copy of a method, regardless of whether or not it's static and/or final.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Jeff Verdegan wrote:
Mansukhdeep Thind wrote:The methods are loaded on the stack as and when you invoke them using object.methodName().


No they're not. Methods live in the method area, which is part of the heap. They're not copied to the stack. That would be pointless.


OK. Can you provide some literature on the parts of the heap and what they are used for? I had not heard of this term method area before.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mansukhdeep Thind wrote:
OK. Can you provide some literature on the parts of the heap and what they are used for? I had not heard of this term method area before.


JVM Spec 2.5. Run-Time Data Areas
surlac surlacovich
Ranch Hand

Joined: Mar 12, 2013
Posts: 296

Jeff Verdegan wrote:Methods live in the method area, which is part of the heap.

This is something different from Heap Regions (New/Young Region, Old/Tenured Region, Permanent Region), right?

Thanks for the link to the doc.
Mahesh Karehonna
Greenhorn

Joined: Apr 02, 2013
Posts: 6
Thanks to all of you for your valuable replies..

As i studied, whenever we create Instance variable for the class using "new" then all the non-static members of the class will be loaded into heap. So if we create "N" number of instance variables then "N" number of times non-static members will be loaded into the heap[reserved for that particular instance variable], But Static members will be having only one copy w.r.t to class irrespective of the number of objects created, so they are common shared items to all the object.

Now, if i make a non-static member as a final, then does these members also loaded each time when we create instance variable...?

Note: I assume that Non-static final members of class are equal to static members of the class since we cant change/modify them.

Correct me if i am wrong.

Thanks
Mahesh
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7024
    
  16

Mahesh Karehonna wrote:Now, if i make a non-static member as a final, then does these members also loaded each time when we create instance variable...?

Well, if you mean "every time we create an instance" (variable or otherwise), then the answer is: Yes.

But I think you're obsessing far too much about where they're created. The fact is: they are created, and you use them just like you would any other value or method. Unless you actually need this information for something like the SCJP exam, it really is irrelevant.

Far more important is to know WHY you create static and final fields and methods. And of the two, I'd say that final is probably the more important to know about (and vastly underused by most programmers - especially beginners); static tends to take care of itself.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Artlicles by Winston can be found here
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36453
    
  15
Too difficult a question for “beginning”. Moving discussion.

I always thought methods and static members lived in the Class<T> object and instance fields in the Foo object on the heap. Have a look in the BCEL manual, and see whether that helpd.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Mahesh wrote: Now, if i make a non-static member as a final, then does these members also loaded each time when we create instance variable...?


Marking a reference variable as final means that it will always point to the same object.

Marking an instance method as final means that you can not override it in future in a sub class of the current class.

Marking a class as final means you cannot extend that class in future.

Marking a primitive variable as final implies that the value it is holding can not be changed in future. It becomes a compile - time constant.

marking / not marking any of the above as final has no relation to the area of the JVM memory in which they will be loaded. (i.e. unless Jeff, Campbell or Winston know something that I don't, which is the case most of the times.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36453
    
  15
Mansukhdeep Thind wrote: . . . It becomes a compile - time constant. . . .
Not necessarily. It says this in the Calendar class documentation:-
Calendar rightNow = Calendar.getInstance();
Now try this:-That is not a compile‑time constsnt
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7024
    
  16

Mansukhdeep Thind wrote:Marking a reference variable as final means that it will always point to the same object.

Or no object.

Marking an instance method as final means that you can not override it in future in a sub class of the current class.
Marking a class as final means you cannot extend that class in future.

Actually, not quite true, because you can always remove final later on. What you CANNOT do is add it after the fact.

Therefore, I always define classes, methods and fields as final, unless I know in advance that they shouldn't be.

Winston
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
Winston Gutkowski wrote:Actually, not quite true, because you can always remove final later on. What you CANNOT do is add it after the fact.

Umm, sure you can. IF you have sufficient control of the client code, such that you either know that no one has overridden the method, or you can fix the overriding code yourself (or expect it to be fixed by others).

In some environments (e.g. if you have external clients outside your company), that may be impossible; in others, it can be trivially easy. I've usually experienced the latter.

Which is not to say that I don't agree it's a good idea to make things final when possible - I do. But failure to make something final is not necessarily an unrecoverable error.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7024
    
  16

Mike Simmons wrote:Umm, sure you can...

OK, maybe I should have said: "What you cannot do is SIMPLY add it after the fact.".

Fact is: they're both design decisions - presumably taken with hindsight - one has no (or darn well shouldn't have any) consequences; t'other is one that requires a LOT of thought, and possibly work.

Winston
surlac surlacovich
Ranch Hand

Joined: Mar 12, 2013
Posts: 296

Mahesh Karehonna wrote:
Now, if i make a non-static member as a final, then does these members also loaded each time when we create instance variable...?

Suppose you initialize this final var in constructor, the value can be different for every instance of the class, so I think yes, these members loaded each time.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

surlac surlacovich wrote:
Mahesh Karehonna wrote:
Now, if i make a non-static member as a final, then does these members also loaded each time when we create instance variable...?

Suppose you initialize this final var in constructor, the value can be different for every instance of the class, so I think yes, these members loaded each time.


If you do this, the value of the instance variable is still going to be the same for all instances of the class. Yes, all these instances will have their own copy of this final variable.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Campbell Ritchie wrote:
Mansukhdeep Thind wrote: . . . It becomes a compile - time constant. . . .
Not necessarily. It says this in the Calendar class documentation:-
Calendar rightNow = Calendar.getInstance();
Now try this:-That is not a compile‑time constsnt


Yes Campbell, you are indeed correct. rightNow and milliseconds are not compile-time constants. In fact they are final variables as described here in Henry's post.

To be a variable that is a compile time constant, the variable needs to be...

declared as final
have a primative or String type
initialized (on the same line as the declaration)
assigned to a compile time constant expression

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mansukhdeep Thind wrote:
surlac surlacovich wrote:
Mahesh Karehonna wrote:
Now, if i make a non-static member as a final, then does these members also loaded each time when we create instance variable...?

Suppose you initialize this final var in constructor, the value can be different for every instance of the class, so I think yes, these members loaded each time.


If you do this, the value of the instance variable is still going to be the same for all instances of the class.


No. Each object's value of that instance variable will only be the same if you set them all to be the same. That's what it means to be an instance variable--each instance has its own copy, totally independent of all the others.




Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

OK Jeff. Then why to make it final? What is the purpose of marking an instance variable , which could have different values for different instances of the class, as final? What is it's significance then? I might as well say :



and then do the same what you are doing. What is the practical scenario where marking a primitive as final will be useful to my class' objects? Does that mean that once initialized, value stored in x can not be modified?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
Mansukhdeep Thind wrote:Does that mean that once initialized, value stored in x can not be modified?


Yes, that's what final means.

You could accomplish nearly the same thing by making the field private and simply not giving it any setters. However it would not be guaranteed to be immutable when seen by multiple threads - it's possible for other threads to observe the value to be null, rather than the initialized value. No, it doesn't make sense; it's jut the way things are. This loophole goes away when you use final - a final field really is final, even under multithreading. Plus, it's a concise, clear way to express your intent.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Mike Simmons wrote:
Mansukhdeep Thind wrote:Does that mean that once initialized, value stored in x can not be modified?


Yes, that's what final means. ...... However it would not be guaranteed to be immutable when seen by multiple threads - it's possible for other threads to observe the value to be null, rather than the initialized value.


How can other threads observe the value of an initialized instance variable of an object as null? if I initialize x to , say, 10, and x is not marked as final of course, then tell me a scenario when another thread may falsely view its value as null?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
It's discussed in JLS 17.5. As I said, no, it doesn't make sense; it's jut the way things are.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Mike Simmons wrote:It's discussed in JLS 17.5. As I said, no, it doesn't make sense; it's jut the way things are.


That was helpful Mike. Thanks a pile.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mansukhdeep Thind wrote:OK Jeff. Then why to make it final? What is the purpose of marking an instance variable , which could have different values for different instances of the class, as final? What is it's significance then?


So that it can be initialized when the object is created, but not changed after that, so, for example, we can make immutable objects. Consider the trivial example of Integer. I haven't looked at the code, but if you do, I bet you'll see private final int value; which gets set when the Integer is created. We can't change the Integer's value after that.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mike Simmons wrote:
You could accomplish nearly the same thing by making the field private and simply not giving it any setters. However it would not be guaranteed to be immutable when seen by multiple threads - it's possible for other threads to observe the value to be null, rather than the initialized value.


You can fix that with volatile or synchronized.

The real value is that by marking it as final you are indicating a design decision, that can be easily understood by anybody who reads the code in the future, and that is enforced by the compiler.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Jeff Verdegan wrote:
Mansukhdeep Thind wrote:OK Jeff. Then why to make it final? What is the purpose of marking an instance variable , which could have different values for different instances of the class, as final? What is it's significance then?


So that it can be initialized when the object is created, but not changed after that, so, for example, we can make immutable objects. Consider the trivial example of Integer. I haven't looked at the code, but if you do, I bet you'll see private final int value; which gets set when the Integer is created. We can't change the Integer's value after that.


You mean having a look at the Integer class? Correct?
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Jeff Verdegan wrote:
Mike Simmons wrote:
You could accomplish nearly the same thing by making the field private and simply not giving it any setters. However it would not be guaranteed to be immutable when seen by multiple threads - it's possible for other threads to observe the value to be null, rather than the initialized value.


You can fix that with volatile or synchronized.

The real value is that by marking it as final you are indicating a design decision, that can be easily understood by anybody who reads the code in the future, and that is enforced by the compiler.


Hmm. So, properly designed application is the need.

I never understood this volatile identifier properly though. Could you explain Jeff? Is it similar to synchronize?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mansukhdeep Thind wrote:
You mean having a look at the Integer class? Correct?


Yes. java.lang.Integer. The source is in src.zip in the JDK download.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mansukhdeep Thind wrote:
I never understood this volatile identifier properly though. Could you explain Jeff?


Every read and write of a volatile variable goes against the single main copy. Threads are not allowed to have their own local copies.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
Jeff Verdegan wrote:
Mike Simmons wrote:
You could accomplish nearly the same thing by making the field private and simply not giving it any setters. However it would not be guaranteed to be immutable when seen by multiple threads - it's possible for other threads to observe the value to be null, rather than the initialized value.


You can fix that with volatile or synchronized.

Um, yes, if for some reason you wanted to ignore the obvious choice of using final, you could do something else, sure. Having a volatile unchanging variable seems counter-intuitive to me though. But I guess that's just an extension of the silliness of calling it a "variable".
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mike Simmons wrote:
Jeff Verdegan wrote:
Mike Simmons wrote:
You could accomplish nearly the same thing by making the field private and simply not giving it any setters. However it would not be guaranteed to be immutable when seen by multiple threads - it's possible for other threads to observe the value to be null, rather than the initialized value.


You can fix that with volatile or synchronized.

Um, yes, if for some reason you wanted to ignore the obvious choice of using final, you could do something else, sure. Having a volatile unchanging variable seems counter-intuitive to me though. But I guess that's just an extension of the silliness of calling it a "variable".


I wasn't advocating those in place of final. I was merely pointing out that making sure other threads see the value isn't the reason we make something final. It is a fortunate side-effect of being final that all threads will see that value by the time they get a reference to the object, but it's not why we make it final.
surlac surlacovich
Ranch Hand

Joined: Mar 12, 2013
Posts: 296

Jeff Verdegan wrote:I was merely pointing out that making sure other threads see the value isn't the reason we make something final.

Am I correct that this is a feature of Java Memory Model? I mean that threads can see old (cached) value if one doesn't use volatile modifier.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

surlac surlacovich wrote:
Jeff Verdegan wrote:I was merely pointing out that making sure other threads see the value isn't the reason we make something final.

Am I correct that this is a feature of Java Memory Model? I mean that threads can see old (cached) value if one doesn't use volatile modifier.


Yes. Entering and exiting synchronized blocks and methods also forces a thread to read from or write to the main copy.

Outside of those situations and a few others dealing with constructors and whatnot, threads are free to have their own local copies of shared variables. This allows frequently used values to be placed in on-chip caches that are faster to access than main memory, but can result in what our program thinks of as a single variable having multiple values simultaneously, or not going through the value transitions we expect it to. Volatile and synchronization (as well as some of the constructs in java.util.concurrent) are how we prevent that from happening when it matters.
surlac surlacovich
Ranch Hand

Joined: Mar 12, 2013
Posts: 296

Thanks Jeff.

Mike Simmons wrote:
But failure to make something final is not necessarily an unrecoverable error.

It's a good practice in concurrent programs, you see final variable in code and you know it is safe (no trouble with caching, affecting other threads, etc.), it's just easy to read and understand.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
Which is another reason why, as I said, I think it's a good practice to make things final when possible. Obviously. But that has nothing to do with the point I was replying to where you quoted me.
surlac surlacovich
Ranch Hand

Joined: Mar 12, 2013
Posts: 296

Yep, I wanted to confirm that it's not a error to not use final keyword but it would be better to use it wherever you can.
One more question, where final instance variables stored? I expect it to be in heap, somewhere in segment of code, but I'm not sure.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

surlac surlacovich wrote:where final instance variables stored? I expect it to be in heap, somewhere in segment of code, but I'm not sure.


Stored in the heap as part of the object, just as if they were non-final. Although I think if one is a compile-time constant, its value is just inlined when compiling.
surlac surlacovich
Ranch Hand

Joined: Mar 12, 2013
Posts: 296

Jeff Verdegan wrote:... Although I think if one is a compile-time constant, its value is just inlined when compiling.

Yes, that is the interesting topic. How to determine if the variable will be converted to compile-time constant? For example if I initialize final var in constructor, compiler won't inline it, because the value is determined in run-time, am I right?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

surlac surlacovich wrote:For example if I initialize final var in constructor, compiler won't inline it, because the value is determined in run-time, am I right?


Correct.

The rules are spelled out in the JLS. I think somebody may have even provided a link above. Roughly speaking, you have to assign the value in the declaration, and the value must be composed of one or more primitive literals and/or String literals and/or other compile-time constants, combined with appropriate operators for that type.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: About Non Static Final Methods/Variables
 
Similar Threads
Static Hiding
Inner Classes
Head First Java Chapter 15 problem
Final fields(Static & Instance)
static members