This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Run-time constants and compile-time constant Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Run-time constants and compile-time constant" Watch "Run-time constants and compile-time constant" New topic
Author

Run-time constants and compile-time constant

Jumjum Reddy
Greenhorn

Joined: Jul 12, 2008
Posts: 2
Can you tell me what is the exact difference between run-time constants and compile-time constants.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39053
    
  23
Welcome to JavaRanch

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

int a = 1 + 2 * 3;
String c = "Campbell";

"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 ]
Jumjum Reddy
Greenhorn

Joined: Jul 12, 2008
Posts: 2
Thanks for the reply to the question. I am sorry for the wrong usage of terminology.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39053
    
  23
You're welcome. No need to be sorry.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19697
    
  20

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3016
    
  10
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.
Amit Ghorpade
Bartender

Joined: Jun 06, 2007
Posts: 2716
    
    6

it just makes sense if you want to use the term "constant".

But then it would imply a compile time constant. In general terms when we say constant we mean a known value. For unknown (runtime/variable) values we use the term variable.

So I think Campbell and Rob justify the term runtime constant although the term might not exist formally.


SCJP, SCWCD.
|Asking Good Questions|
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3016
    
  10
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.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19697
    
  20

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.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3016
    
  10
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.
Amit Ghorpade
Bartender

Joined: Jun 06, 2007
Posts: 2716
    
    6

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.
Graeme Byers
Ranch Hand

Joined: Apr 16, 2004
Posts: 127
Heavy stuff guys !

If this fatuous distinction means anyting , here is its meaning :

"Variables" declared in interfaces are constants : they must be set to a value when they are declared and can never, ever, anywhere be changed.
Interface variables are implicitly final and public.

There are also variables in classes marked final. They can have their value set when declared or later (so less restrictive than interface variables), but once set can never etc.

Like this :

interface interfaceable {
// double CONSTANT_PI ; // Compile error
double CONSTANT_PI = 3.14 ;
}
public class GBTestT implements interfaceable {
public static void main (String[] args) {
final int finalField ;
finalField = 1 ;
// finalField = 2 ;
System.out.println (CONSTANT_PI) ;
}
}
Amit Ghorpade
Bartender

Joined: Jun 06, 2007
Posts: 2716
    
    6

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
Graeme Byers
Ranch Hand

Joined: Apr 16, 2004
Posts: 127
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.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3016
    
  10
[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.
Amit Ghorpade
Bartender

Joined: Jun 06, 2007
Posts: 2716
    
    6

Originally posted by Mike Simmons
But again, "runtime constant" is never properly defined anyway, so there's no real way to resolve disagreements on this point.


I agree
But although the ambiguity wont be resolved so easily, I think such discussion definitely gives a direction to think.
Ronald Schild
Ranch Hand

Joined: Jun 09, 2008
Posts: 117
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.

Just a personal view.


Java hobbyist.
Amit Ghorpade
Bartender

Joined: Jun 06, 2007
Posts: 2716
    
    6

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
 
GeeCON Prague 2014
 
subject: Run-time constants and compile-time constant