Runtime constant is not a term we use often, but compile-time constant is. The official Java definition of constants is in the Java Language Specification (here). A compile-time constant is something whose exact value the compiler can work out without trying to run the program. So in the statements
"Campbell", 1, 2, 3, 2*3 and 1+2*3 are compile-time constants; you can look at one line only and work out their values;
This sets up the value of i and it is fixed for the life of the object at runtime. You might call that a runtime constant, but it isn't (as far as I know) an officially approved Java term. [ July 12, 2008: Message edited by: Campbell Ritchie ]
Joined: Jul 12, 2008
Thanks for the reply to the question. I am sorry for the wrong usage of terminology.
Another example of a runtime constant is java.util.Collections.EMPTY_SET. It's declaration is (in Java 6):
This EmptySet object is only created when the class is loaded.
Compiler constants can also only be primitives or String literals. Anything that creates a new object, or uses the non-fixed result of a method (e.g. System.getProperty(...)) is always a runtime constant since its value isn't known until the JVM is started.
But there's still no real definition of runtime constant. If someone wanted to use the term anyway, I would say that it can really only be applied to primitive types or immutable objects, for example. But this hasn't been stated anywhere that I'm aware of - it just makes sense if you want to use the term "constant". I think it would be better, however, to simply not use that term in an area it hasn't been defined.
Hm, I don't follow you at all here, Amit. Evidently some people do want to use the term "constant" to apply to things that are not compile-time constants. While I think this is a bad idea (in Java) and just leads to confusion, I also think that if one is going to use the term this way, the value in question should at least be primitive or an immutable object type, as well as final. That's what I was saying above.
I don't see why it matters whether the value is "known" or not. For example, offhand I don't know the value of WindowConstants.DISPOSE_ON_CLOSE. I could look it up, but it doesn't matter to me. But it is a compile-time constant nonetheless. In other cases I can easily have a non-constant field whose value I do know. So I don't think your distinction between known and unknown values makes much sense here.
I think Amit means known to the compiler, not known to the developer. The compiler knows what the value will always be, and actually replace it in byte code. The constant field name is for developers only, so we don't have to write 1 all the time, and forget what 1 actually means.
Joined: Mar 05, 2008
Well, I suppose he could just be restating the obvious about what it means to be a compile-time constant - but then he says "So I think Campbell and Rob justify the term runtime constant although the term might not exist formally." Hunh? If he's just talking about what the compiler knows, then the preceding text was just talking about compile-time constants, and he hasn't said anything at all about runtime constants. His "so" seems to indicate otherwise, that his known/unknown distinction is somehow applicable to so-called runtime constants. Which the compiler doesn't know, and therefore aren't constants, right? Which leads us right back to: the term "runtime constant" makes no sense.
Additionally, the JLS does clearly use the term "variable" even when the value is a compiler-time constant. Math.PI is both a variable and a constant - the terms are not mutually exclusive terms, as they are defined in the JLS. Certainly, other definitions are possible, and the terms are often used differently in other programming languages. But that's not the terminology used in Java's documentation.
I think Amit means known to the compiler, not known to the developer.
Yes Rob got me right here. I meant the compiler.
Originally posted by Mike Simmons His "so" seems to indicate otherwise, that his known/unknown distinction is somehow applicable to so-called runtime constants. Which the compiler doesn't know, and therefore aren't constants, right? Which leads us right back to: the term "runtime constant" makes no sense.
Looks like I failed to express my view, let me give another try. As already stated by Rob, a compile time constant is one whose value is known by the compiler at compile time, so that during code optimization phase it can directly use that known value instead of the variable(its address). Now by a runtime constant(this term is the root of all confusions ) I mean that a variable whose value is assigned at runtime unlike any other variable and after assignment it remains constant. So the compiler cannot optimize this type of a variable. Rob has already given such an example.
Now this can be thought to be analogous to method calls and runtime polymorphic method calls.(But this only analogous and does not mean I am saying both are same concepts )
But that's not the terminology used in Java's documentation.
I am not relating this with any language specification but with the generic compiler and only for a reference, the Java language.
Hi Graeme, I think the discussion is more about runtime constants .
And we dont put code tags that way, its
this way. Hope this helps
Joined: Apr 16, 2004
Again, this distinction is fatuous , just verbage , explains nothing. The only sense that can be made of it is this : Interface "variables" are 'compile time constants' since the compiler will flag them if they are not set when declared.
Some final "variables" are 'compile time constants' - the ones which are initialised when they are declared. Their value is known at compile time.
Final "variables" , not initialised when declared, are 'run time constants' since their value may only be known when the program is run - set from the command line, perhaps.
Joined: Mar 05, 2008
[Graeme]: Interface "variables" are 'compile time constants' since the compiler will flag them if they are not set when declared.
No - the term "compile-time constant" is well defined, and does not apply to all interface fields. Many interface fields arep compile-time constants, but they don't have to be. Consider:
The reference will not change, but the object it references is mutable. That's legal in an interface, but hardly a constant - and definitely not a compile-time constant, which by definition can be only a primitive value or String.
It's also possible to initialize an interface field using a method - e.g., to read the value from a file or database. This, again, would not be a compile-time constant.
[Graeme]: Some final "variables" are 'compile time constants' - the ones which are initialised when they are declared. Their value is known at compile time.
Again, being initialized when they are declared does not necessarily imply it's a compile-time constant.
[Graeme]: Final "variables" , not initialised when declared, are 'run time constants' since their value may only be known when the program is run - set from the command line, perhaps.
And I still think this is insufficient - a final variable referring to a mutable object (like a StringBuffer) is not a "constant" in my book, even if the reference itself never changes. But again, "runtime constant" is never properly defined anyway, so there's no real way to resolve disagreements on this point.
I personally dislike the term 'runtime constant'. A compile time constant variable will always be the same unless its code is modified.
String x = "abc" ;
"abc" is a compile time constant and will always be the same String literal. No matter how many times you compile the code, "abc" will always be "abc" and nothing else.
final static objextX x = loadX() ;
Saying that objectX is a runtime constant is only valid up to a certain point. The variable itself will not change once assigned, which is during class initialization. That is, unless you stop the program and run it again. It is very unlikely that x will have the same value. So the value of x can not be determined by a formula that resolves in the same value every time. We could say that x is a runtime constant because it remains constant during the 'time it runs (or exists)', but we cannot say that this time is fixed, because this is also up to the implementation of the class loader that loaded the class. This possibly results in x having different values for the duration of the runtime that utilizes this class (rare situations) and because of this I feel that 'runtime constant' is not a good term to use.
Also, using unoffical terms can lead to confusing situations.
This possibly results in x having different values for the duration of the runtime that utilizes this class (rare situations) and because of this I feel that 'runtime constant' is not a good term to use.
Yes although the term is not good to use, you'll still find it in some context. So I think we must rely on our own understanding rather than dictionary meaning
Also, using unoffical terms can lead to confusing situations.
As I said above it has lead to confusion, and everyone thinks his view is right