• Post Reply Bookmark Topic Watch Topic
  • New Topic

static final VS final  RSS feed

 
Ioanna Katsanou
Ranch Hand
Posts: 131
1
Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand that when declaring a constant the right way to do this is:


static declares that this is a class variable and it is the same for all the instances of a class.
final declares that this variable is a constant and it must be initialized one time and then it cannot change value.

what is the difference with


? since tis variable cannot change value isn't it the same for all instances too?
 
Dave Tolls
Ranch Foreman
Posts: 3068
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the latter case you would end up with a CONSTANT field for each instance of the class in question.
In the former case there would only be the one.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If it is not static, then for each instance of the class that contains the constant a separate copy of the constant is created, which takes up memory. This is unnecessary, since the value of the constant is going to be the same for each instance anyway. So, you should make it static to avoid making an unnecessary copy of the constant for each instance of the class.

Ioanna Katsanou wrote:? since tis variable cannot change value isn't it the same for all instances too?

The value of the constant is going to be the same for all instances, but for each instance a separate location in memory is reserved to store this value.
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is customary to put constants into a utility class. You get one instance of each of the static fields irrespective of how many instances of the class there are, so who needs instances? So you give the class a private empty constructor (see link above) and make each of the fields public:-Warning: once a constant always a constant. If you declare a non‑private constant which is a compile‑time constant, and use it elsewhere, that constant must keep the same value for ever.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note that it's probably worth making the name of such a utility class reflect the fact that it's a collection of related constants, like name it TemperatureConstants. Be careful to keep these kinds of classes cohesive. The last thing you want to do is make a class that's the dumping ground of all your application constants. A class named ApplicationConstants is almost always bad. Constant utility classes like this should be specific to ONE group of related constants, not many unrelated groups of related constants. Check out this Wikipedia article to learn more about the design considerations and motivations behind Campbell's example.

Notice also that Campbell's example has a private constructor. This prevents anyone from creating instances from outside of this class itself. A private constructor is the Java idiom for saying "This class wasn't designed to be instantiated by client code."

 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is quite a good Wikipedia article. I don't quite understand this part of it however:-
That Wikipedia page wrote:Note however, the changes do nothing to improve the cohesion of the Constants class nor prevent the accidental silent modification of a constant's value, so static imports should not be considered to be a panacea.
It also fails to notice that static imports of their Constants class will fail to compile because the Constants class does not have a declared package name.
The JLS section in the link above wrote:The name must be qualified (§6.5.5.2), or a compile-time error occurs.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:I don't quite understand this part of it however:-
That Wikipedia page wrote:Note however, the changes do nothing to improve the cohesion of the Constants class nor prevent the accidental silent modification of a constant's value, so static imports should not be considered to be a panacea.

It has to do with these statements made earlier in the article:
In general, collecting system constants into classes independent of behaviour might create a poor object-oriented design because it is often a sign of low cohesion...

Use of this pattern has a few other downsides:
...
6. Unless a developer checks any implemented interfaces when adding a constant to a class, or does so but makes a typo in the new constant's name, the value of a constant can be silently changed. Consider Example 2 below.

Putting the values into a separate class by themselves still makes them independent of behavior (or behaviour, if you prefer ) so you still have low cohesion.

It also fails to notice that static imports of their Constants class will fail to compile because the Constants class does not have a declared package name.
The JLS section in the link above wrote:The name must be qualified (§6.5.5.2), or a compile-time error occurs.

Would it compile if all the code is in the default package? I haven't tried.
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:. . . Would it compile if all the code is in the default package? I haven't tried.
Older versions of the JLS said it is a compile time error to import classes from the unnamed package, so I would expect it wouldn't compile. I think that might have been permissible in very early versions, before I took up computing again.
Yes, here is the Java7 version of the JLS:-
That Java7 JLS page wrote:A type in an unnamed package (§7.4.2) has no canonical name, so . . . (a) types in an unnamed package cannot be imported, . . . As such, §7.5.1, §7.5.2, §7.5.3, and §7.5.4 all require a compile-time error on any attempt to import a type (or static member thereof) in an unnamed package.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Also, as a side note to this topic, both of these examples are compile time constants. So, neither actually takes any memory space -- as it is hard coded into the code that uses these constants.

So, in that case, the static version only has a slight advantage, in that you don't actually need an instance to use the constant value.

Henry
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!