How does the Date object update without recompiling the program in Java?
up vote
3
down vote
favorite
Example:
System.out.println(new Date());
Now obviously this is part of a larger program, but you can see what this does. Now, I run the compiler once, and then run the program. Then, without compiling the program again, I run it and the date updates. This might seem stupid but how does the date update without updating the bytecode?
From my understanding through what I have read the Java compiler takes my source code and compiles it to bytecode, which is saved in a class file. The JIT converts this code to machine code and it runs. However, wouldn't the state of the Date object stay the same? It obviously doesn't. I am just confused on how it changes.
java date instantiation
edited Nov 11 at 15:44
Mureinik
175k21124192
asked Nov 11 at 0:31
Caleb Suhy
297
|
show 2 more comments
up vote
3
down vote
favorite
Example:
System.out.println(new Date());
Now obviously this is part of a larger program, but you can see what this does. Now, I run the compiler once, and then run the program. Then, without compiling the program again, I run it and the date updates. This might seem stupid but how does the date update without updating the bytecode?
From my understanding through what I have read the Java compiler takes my source code and compiles it to bytecode, which is saved in a class file. The JIT converts this code to machine code and it runs. However, wouldn't the state of the Date object stay the same? It obviously doesn't. I am just confused on how it changes.
java date instantiation
edited Nov 11 at 15:44
Mureinik
175k21124192
asked Nov 11 at 0:31
Caleb Suhy
297
3
What do you think a compilation is?
– Fureeish
Nov 11 at 0:33
3
new Dateis evaluated when the code is run, not when it is compiled. Compiling doesn't work out the date and store it in your bytecode. It stores the instructions that include looking up the current date.
– khelwood
Nov 11 at 0:35
2
^^ Ah I see. I guess I just had the wrong idea about when it is evaluated. Thanks!
– Caleb Suhy
Nov 11 at 0:37
2
As you are learning, if you would like to check the bytecode generated from your example try this in your cmd, after you compiled your class:C:Test>javap -c C:TestYourCompiledClass.class C:TestYourBytecode.bc
– jhenrique
Nov 11 at 2:58
2
You shouldn’t use theDateclass. After years of bad experiences with it, its replacement came out when you were 10:java.time, the modern Java date and time API. Try for exampleSystem.out.println(LocalDate.now(ZoneId.systemDefault()));. The answer will be the same, though: a newLocalDateobject will be generated every time you run your program.
– Ole V.V.
Nov 11 at 6:42
|
show 2 more comments
up vote
3
down vote
favorite
up vote
3
down vote
favorite
Example:
System.out.println(new Date());
Now obviously this is part of a larger program, but you can see what this does. Now, I run the compiler once, and then run the program. Then, without compiling the program again, I run it and the date updates. This might seem stupid but how does the date update without updating the bytecode?
From my understanding through what I have read the Java compiler takes my source code and compiles it to bytecode, which is saved in a class file. The JIT converts this code to machine code and it runs. However, wouldn't the state of the Date object stay the same? It obviously doesn't. I am just confused on how it changes.
java date instantiation
edited Nov 11 at 15:44
Mureinik
175k21124192
asked Nov 11 at 0:31
Caleb Suhy
297
Example:
System.out.println(new Date());
Now obviously this is part of a larger program, but you can see what this does. Now, I run the compiler once, and then run the program. Then, without compiling the program again, I run it and the date updates. This might seem stupid but how does the date update without updating the bytecode?
From my understanding through what I have read the Java compiler takes my source code and compiles it to bytecode, which is saved in a class file. The JIT converts this code to machine code and it runs. However, wouldn't the state of the Date object stay the same? It obviously doesn't. I am just confused on how it changes.
java date instantiation
java date instantiation
edited Nov 11 at 15:44
Mureinik
175k21124192
asked Nov 11 at 0:31
Caleb Suhy
297
edited Nov 11 at 15:44
Mureinik
175k21124192
asked Nov 11 at 0:31
Caleb Suhy
297
edited Nov 11 at 15:44
Mureinik
175k21124192
edited Nov 11 at 15:44
Mureinik
175k21124192
edited Nov 11 at 15:44
Mureinik
175k21124192
175k21124192
asked Nov 11 at 0:31
Caleb Suhy
297
asked Nov 11 at 0:31
Caleb Suhy
297
asked Nov 11 at 0:31
Caleb Suhy
297
297
3
What do you think a compilation is?
– Fureeish
Nov 11 at 0:33
3
new Dateis evaluated when the code is run, not when it is compiled. Compiling doesn't work out the date and store it in your bytecode. It stores the instructions that include looking up the current date.
– khelwood
Nov 11 at 0:35
2
^^ Ah I see. I guess I just had the wrong idea about when it is evaluated. Thanks!
– Caleb Suhy
Nov 11 at 0:37
2
As you are learning, if you would like to check the bytecode generated from your example try this in your cmd, after you compiled your class:C:Test>javap -c C:TestYourCompiledClass.class C:TestYourBytecode.bc
– jhenrique
Nov 11 at 2:58
2
You shouldn’t use theDateclass. After years of bad experiences with it, its replacement came out when you were 10:java.time, the modern Java date and time API. Try for exampleSystem.out.println(LocalDate.now(ZoneId.systemDefault()));. The answer will be the same, though: a newLocalDateobject will be generated every time you run your program.
– Ole V.V.
Nov 11 at 6:42
|
show 2 more comments
3
What do you think a compilation is?
– Fureeish
Nov 11 at 0:33
3
new Dateis evaluated when the code is run, not when it is compiled. Compiling doesn't work out the date and store it in your bytecode. It stores the instructions that include looking up the current date.
– khelwood
Nov 11 at 0:35
2
^^ Ah I see. I guess I just had the wrong idea about when it is evaluated. Thanks!
– Caleb Suhy
Nov 11 at 0:37
2
As you are learning, if you would like to check the bytecode generated from your example try this in your cmd, after you compiled your class:C:Test>javap -c C:TestYourCompiledClass.class C:TestYourBytecode.bc
– jhenrique
Nov 11 at 2:58
2
You shouldn’t use theDateclass. After years of bad experiences with it, its replacement came out when you were 10:java.time, the modern Java date and time API. Try for exampleSystem.out.println(LocalDate.now(ZoneId.systemDefault()));. The answer will be the same, though: a newLocalDateobject will be generated every time you run your program.
– Ole V.V.
Nov 11 at 6:42
3
3
What do you think a compilation is?
– Fureeish
Nov 11 at 0:33
What do you think a compilation is?
– Fureeish
Nov 11 at 0:33
3
3
new Date is evaluated when the code is run, not when it is compiled. Compiling doesn't work out the date and store it in your bytecode. It stores the instructions that include looking up the current date.– khelwood
Nov 11 at 0:35
new Date is evaluated when the code is run, not when it is compiled. Compiling doesn't work out the date and store it in your bytecode. It stores the instructions that include looking up the current date.– khelwood
Nov 11 at 0:35
2
2
^^ Ah I see. I guess I just had the wrong idea about when it is evaluated. Thanks!
– Caleb Suhy
Nov 11 at 0:37
^^ Ah I see. I guess I just had the wrong idea about when it is evaluated. Thanks!
– Caleb Suhy
Nov 11 at 0:37
2
2
As you are learning, if you would like to check the bytecode generated from your example try this in your cmd, after you compiled your class:
C:Test>javap -c C:TestYourCompiledClass.class C:TestYourBytecode.bc– jhenrique
Nov 11 at 2:58
As you are learning, if you would like to check the bytecode generated from your example try this in your cmd, after you compiled your class:
C:Test>javap -c C:TestYourCompiledClass.class C:TestYourBytecode.bc– jhenrique
Nov 11 at 2:58
2
2
You shouldn’t use the
Date class. After years of bad experiences with it, its replacement came out when you were 10: java.time, the modern Java date and time API. Try for example System.out.println(LocalDate.now(ZoneId.systemDefault()));. The answer will be the same, though: a new LocalDate object will be generated every time you run your program.– Ole V.V.
Nov 11 at 6:42
You shouldn’t use the
Date class. After years of bad experiences with it, its replacement came out when you were 10: java.time, the modern Java date and time API. Try for example System.out.println(LocalDate.now(ZoneId.systemDefault()));. The answer will be the same, though: a new LocalDate object will be generated every time you run your program.– Ole V.V.
Nov 11 at 6:42
|
show 2 more comments
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
Compile-time versus Run-time
The Answer by Mureinik is correct. Objects defined in your code are constructed at run-time, not compile-time.
Compilation is like having an engineer review an architect’s plans for a building, and then writing out more detailed specifications. No building is yet built. We are now thoroughly ready to build, but have not actually built anything until “run-time” when the construction crew arrives on site.
In this metaphor, your source code is the architect’s drawings. The engineer’s more detailed specifications is the bytecode emitted by the Java compiler. The JVM running your app’s bytecode is the construction crew going to work on site.
Another way to think if it:
- Classes are determined at compile-time.
- Objects (instances) are determined at run-time.
java.time
Also, you should never use the Date class. That class and the other legacy date-time classes from the earliest versions of Java are terrible, riddled with poor design choices. They were supplanted years ago by the modern java.time classes.
The java.time classes use factory methods for instantiating rather than constructors and new.
Instant.now() // Capture current moment in UTC.
OffsetDateTime.now( ZoneOffset.UTC ) // Capture current moment in UTC.
ZonedDateTime.now( ZoneId.of( "Africa/Casablanca" ) ) // Capture current moment as seen though the wall-clock time used by the people of a particular region (a time zone).
LocalDate.of( 2018 , Month.JANUARY , 23 ) // A date-only value, without time-of-day and without time zone.
answered Nov 11 at 14:58
Basil Bourque
102k25353509
1
No constant available for Africa/Casablanca ?
– Koray Tugay
Nov 11 at 15:05
1
@KorayTugay No, no constants for time zones. Politicians around the world have shown an eagerness to frequently rename and redefine their respective time zone(s). The definitions are soft-coded by way of a tzdata file stored outside the compiled classes to facilitate manual updating. The tzdata file needs updating more often and more urgently than releases of the JVM and its library classes.
– Basil Bourque
Nov 11 at 15:20
1
@KorayTugay We have one constant, for UTC, an offset-from-UTC of zero hours-minutes-seconds:ZoneOffset.UTC. Example:OffsetDateTime.now( ZoneOffset.UTC )
– Basil Bourque
Nov 11 at 15:40
Yeah the only reason I was using the date class was due to the way the book I am reading is teaching classes. A little weird but Core Java is a pretty good book.
– Caleb Suhy
Nov 12 at 0:43
add a comment |
up vote
2
down vote
A Date object initialized with the no-arg constructor will access System.currTimeMilis() and use the current timestamp from the machine. In other words, the timestamp isn't "compiled into it", but instead it contains code that accesses the machine's clock and takes the timestamp from there each time the program is run.
answered Nov 11 at 6:50
Mureinik
175k21124192
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Compile-time versus Run-time
The Answer by Mureinik is correct. Objects defined in your code are constructed at run-time, not compile-time.
Compilation is like having an engineer review an architect’s plans for a building, and then writing out more detailed specifications. No building is yet built. We are now thoroughly ready to build, but have not actually built anything until “run-time” when the construction crew arrives on site.
In this metaphor, your source code is the architect’s drawings. The engineer’s more detailed specifications is the bytecode emitted by the Java compiler. The JVM running your app’s bytecode is the construction crew going to work on site.
Another way to think if it:
- Classes are determined at compile-time.
- Objects (instances) are determined at run-time.
java.time
Also, you should never use the Date class. That class and the other legacy date-time classes from the earliest versions of Java are terrible, riddled with poor design choices. They were supplanted years ago by the modern java.time classes.
The java.time classes use factory methods for instantiating rather than constructors and new.
Instant.now() // Capture current moment in UTC.
OffsetDateTime.now( ZoneOffset.UTC ) // Capture current moment in UTC.
ZonedDateTime.now( ZoneId.of( "Africa/Casablanca" ) ) // Capture current moment as seen though the wall-clock time used by the people of a particular region (a time zone).
LocalDate.of( 2018 , Month.JANUARY , 23 ) // A date-only value, without time-of-day and without time zone.
answered Nov 11 at 14:58
Basil Bourque
102k25353509
1
No constant available for Africa/Casablanca ?
– Koray Tugay
Nov 11 at 15:05
1
@KorayTugay No, no constants for time zones. Politicians around the world have shown an eagerness to frequently rename and redefine their respective time zone(s). The definitions are soft-coded by way of a tzdata file stored outside the compiled classes to facilitate manual updating. The tzdata file needs updating more often and more urgently than releases of the JVM and its library classes.
– Basil Bourque
Nov 11 at 15:20
1
@KorayTugay We have one constant, for UTC, an offset-from-UTC of zero hours-minutes-seconds:ZoneOffset.UTC. Example:OffsetDateTime.now( ZoneOffset.UTC )
– Basil Bourque
Nov 11 at 15:40
Yeah the only reason I was using the date class was due to the way the book I am reading is teaching classes. A little weird but Core Java is a pretty good book.
– Caleb Suhy
Nov 12 at 0:43
add a comment |
up vote
2
down vote
accepted
Compile-time versus Run-time
The Answer by Mureinik is correct. Objects defined in your code are constructed at run-time, not compile-time.
Compilation is like having an engineer review an architect’s plans for a building, and then writing out more detailed specifications. No building is yet built. We are now thoroughly ready to build, but have not actually built anything until “run-time” when the construction crew arrives on site.
In this metaphor, your source code is the architect’s drawings. The engineer’s more detailed specifications is the bytecode emitted by the Java compiler. The JVM running your app’s bytecode is the construction crew going to work on site.
Another way to think if it:
- Classes are determined at compile-time.
- Objects (instances) are determined at run-time.
java.time
Also, you should never use the Date class. That class and the other legacy date-time classes from the earliest versions of Java are terrible, riddled with poor design choices. They were supplanted years ago by the modern java.time classes.
The java.time classes use factory methods for instantiating rather than constructors and new.
Instant.now() // Capture current moment in UTC.
OffsetDateTime.now( ZoneOffset.UTC ) // Capture current moment in UTC.
ZonedDateTime.now( ZoneId.of( "Africa/Casablanca" ) ) // Capture current moment as seen though the wall-clock time used by the people of a particular region (a time zone).
LocalDate.of( 2018 , Month.JANUARY , 23 ) // A date-only value, without time-of-day and without time zone.
answered Nov 11 at 14:58
Basil Bourque
102k25353509
1
No constant available for Africa/Casablanca ?
– Koray Tugay
Nov 11 at 15:05
1
@KorayTugay No, no constants for time zones. Politicians around the world have shown an eagerness to frequently rename and redefine their respective time zone(s). The definitions are soft-coded by way of a tzdata file stored outside the compiled classes to facilitate manual updating. The tzdata file needs updating more often and more urgently than releases of the JVM and its library classes.
– Basil Bourque
Nov 11 at 15:20
1
@KorayTugay We have one constant, for UTC, an offset-from-UTC of zero hours-minutes-seconds:ZoneOffset.UTC. Example:OffsetDateTime.now( ZoneOffset.UTC )
– Basil Bourque
Nov 11 at 15:40
Yeah the only reason I was using the date class was due to the way the book I am reading is teaching classes. A little weird but Core Java is a pretty good book.
– Caleb Suhy
Nov 12 at 0:43
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Compile-time versus Run-time
The Answer by Mureinik is correct. Objects defined in your code are constructed at run-time, not compile-time.
Compilation is like having an engineer review an architect’s plans for a building, and then writing out more detailed specifications. No building is yet built. We are now thoroughly ready to build, but have not actually built anything until “run-time” when the construction crew arrives on site.
In this metaphor, your source code is the architect’s drawings. The engineer’s more detailed specifications is the bytecode emitted by the Java compiler. The JVM running your app’s bytecode is the construction crew going to work on site.
Another way to think if it:
- Classes are determined at compile-time.
- Objects (instances) are determined at run-time.
java.time
Also, you should never use the Date class. That class and the other legacy date-time classes from the earliest versions of Java are terrible, riddled with poor design choices. They were supplanted years ago by the modern java.time classes.
The java.time classes use factory methods for instantiating rather than constructors and new.
Instant.now() // Capture current moment in UTC.
OffsetDateTime.now( ZoneOffset.UTC ) // Capture current moment in UTC.
ZonedDateTime.now( ZoneId.of( "Africa/Casablanca" ) ) // Capture current moment as seen though the wall-clock time used by the people of a particular region (a time zone).
LocalDate.of( 2018 , Month.JANUARY , 23 ) // A date-only value, without time-of-day and without time zone.
answered Nov 11 at 14:58
Basil Bourque
102k25353509
Compile-time versus Run-time
The Answer by Mureinik is correct. Objects defined in your code are constructed at run-time, not compile-time.
Compilation is like having an engineer review an architect’s plans for a building, and then writing out more detailed specifications. No building is yet built. We are now thoroughly ready to build, but have not actually built anything until “run-time” when the construction crew arrives on site.
In this metaphor, your source code is the architect’s drawings. The engineer’s more detailed specifications is the bytecode emitted by the Java compiler. The JVM running your app’s bytecode is the construction crew going to work on site.
Another way to think if it:
- Classes are determined at compile-time.
- Objects (instances) are determined at run-time.
java.time
Also, you should never use the Date class. That class and the other legacy date-time classes from the earliest versions of Java are terrible, riddled with poor design choices. They were supplanted years ago by the modern java.time classes.
The java.time classes use factory methods for instantiating rather than constructors and new.
Instant.now() // Capture current moment in UTC.
OffsetDateTime.now( ZoneOffset.UTC ) // Capture current moment in UTC.
ZonedDateTime.now( ZoneId.of( "Africa/Casablanca" ) ) // Capture current moment as seen though the wall-clock time used by the people of a particular region (a time zone).
LocalDate.of( 2018 , Month.JANUARY , 23 ) // A date-only value, without time-of-day and without time zone.
answered Nov 11 at 14:58
Basil Bourque
102k25353509
edited Nov 11 at 16:28
answered Nov 11 at 14:58
Basil Bourque
102k25353509
answered Nov 11 at 14:58
Basil Bourque
102k25353509
answered Nov 11 at 14:58
Basil Bourque
102k25353509
102k25353509
1
No constant available for Africa/Casablanca ?
– Koray Tugay
Nov 11 at 15:05
1
@KorayTugay No, no constants for time zones. Politicians around the world have shown an eagerness to frequently rename and redefine their respective time zone(s). The definitions are soft-coded by way of a tzdata file stored outside the compiled classes to facilitate manual updating. The tzdata file needs updating more often and more urgently than releases of the JVM and its library classes.
– Basil Bourque
Nov 11 at 15:20
1
@KorayTugay We have one constant, for UTC, an offset-from-UTC of zero hours-minutes-seconds:ZoneOffset.UTC. Example:OffsetDateTime.now( ZoneOffset.UTC )
– Basil Bourque
Nov 11 at 15:40
Yeah the only reason I was using the date class was due to the way the book I am reading is teaching classes. A little weird but Core Java is a pretty good book.
– Caleb Suhy
Nov 12 at 0:43
add a comment |
1
No constant available for Africa/Casablanca ?
– Koray Tugay
Nov 11 at 15:05
1
@KorayTugay No, no constants for time zones. Politicians around the world have shown an eagerness to frequently rename and redefine their respective time zone(s). The definitions are soft-coded by way of a tzdata file stored outside the compiled classes to facilitate manual updating. The tzdata file needs updating more often and more urgently than releases of the JVM and its library classes.
– Basil Bourque
Nov 11 at 15:20
1
@KorayTugay We have one constant, for UTC, an offset-from-UTC of zero hours-minutes-seconds:ZoneOffset.UTC. Example:OffsetDateTime.now( ZoneOffset.UTC )
– Basil Bourque
Nov 11 at 15:40
Yeah the only reason I was using the date class was due to the way the book I am reading is teaching classes. A little weird but Core Java is a pretty good book.
– Caleb Suhy
Nov 12 at 0:43
1
1
No constant available for Africa/Casablanca ?
– Koray Tugay
Nov 11 at 15:05
No constant available for Africa/Casablanca ?
– Koray Tugay
Nov 11 at 15:05
1
1
@KorayTugay No, no constants for time zones. Politicians around the world have shown an eagerness to frequently rename and redefine their respective time zone(s). The definitions are soft-coded by way of a tzdata file stored outside the compiled classes to facilitate manual updating. The tzdata file needs updating more often and more urgently than releases of the JVM and its library classes.
– Basil Bourque
Nov 11 at 15:20
@KorayTugay No, no constants for time zones. Politicians around the world have shown an eagerness to frequently rename and redefine their respective time zone(s). The definitions are soft-coded by way of a tzdata file stored outside the compiled classes to facilitate manual updating. The tzdata file needs updating more often and more urgently than releases of the JVM and its library classes.
– Basil Bourque
Nov 11 at 15:20
1
1
@KorayTugay We have one constant, for UTC, an offset-from-UTC of zero hours-minutes-seconds:
ZoneOffset.UTC. Example: OffsetDateTime.now( ZoneOffset.UTC )– Basil Bourque
Nov 11 at 15:40
@KorayTugay We have one constant, for UTC, an offset-from-UTC of zero hours-minutes-seconds:
ZoneOffset.UTC. Example: OffsetDateTime.now( ZoneOffset.UTC )– Basil Bourque
Nov 11 at 15:40
Yeah the only reason I was using the date class was due to the way the book I am reading is teaching classes. A little weird but Core Java is a pretty good book.
– Caleb Suhy
Nov 12 at 0:43
Yeah the only reason I was using the date class was due to the way the book I am reading is teaching classes. A little weird but Core Java is a pretty good book.
– Caleb Suhy
Nov 12 at 0:43
add a comment |
up vote
2
down vote
A Date object initialized with the no-arg constructor will access System.currTimeMilis() and use the current timestamp from the machine. In other words, the timestamp isn't "compiled into it", but instead it contains code that accesses the machine's clock and takes the timestamp from there each time the program is run.
answered Nov 11 at 6:50
Mureinik
175k21124192
add a comment |
up vote
2
down vote
A Date object initialized with the no-arg constructor will access System.currTimeMilis() and use the current timestamp from the machine. In other words, the timestamp isn't "compiled into it", but instead it contains code that accesses the machine's clock and takes the timestamp from there each time the program is run.
answered Nov 11 at 6:50
Mureinik
175k21124192
add a comment |
up vote
2
down vote
up vote
2
down vote
A Date object initialized with the no-arg constructor will access System.currTimeMilis() and use the current timestamp from the machine. In other words, the timestamp isn't "compiled into it", but instead it contains code that accesses the machine's clock and takes the timestamp from there each time the program is run.
answered Nov 11 at 6:50
Mureinik
175k21124192
A Date object initialized with the no-arg constructor will access System.currTimeMilis() and use the current timestamp from the machine. In other words, the timestamp isn't "compiled into it", but instead it contains code that accesses the machine's clock and takes the timestamp from there each time the program is run.
answered Nov 11 at 6:50
Mureinik
175k21124192
answered Nov 11 at 6:50
Mureinik
175k21124192
answered Nov 11 at 6:50
Mureinik
175k21124192
answered Nov 11 at 6:50
Mureinik
175k21124192
175k21124192
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53244770%2fhow-does-the-date-object-update-without-recompiling-the-program-in-java%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
What do you think a compilation is?
– Fureeish
Nov 11 at 0:33
3
new Dateis evaluated when the code is run, not when it is compiled. Compiling doesn't work out the date and store it in your bytecode. It stores the instructions that include looking up the current date.– khelwood
Nov 11 at 0:35
2
^^ Ah I see. I guess I just had the wrong idea about when it is evaluated. Thanks!
– Caleb Suhy
Nov 11 at 0:37
2
As you are learning, if you would like to check the bytecode generated from your example try this in your cmd, after you compiled your class:
C:Test>javap -c C:TestYourCompiledClass.class C:TestYourBytecode.bc– jhenrique
Nov 11 at 2:58
2
You shouldn’t use the
Dateclass. After years of bad experiences with it, its replacement came out when you were 10:java.time, the modern Java date and time API. Try for exampleSystem.out.println(LocalDate.now(ZoneId.systemDefault()));. The answer will be the same, though: a newLocalDateobject will be generated every time you run your program.– Ole V.V.
Nov 11 at 6:42