This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I have no Threads explicitly in this program, but I've heard that when there is a GUI,
the JVM automatically sets up Threads.
There is a text field on the GUI that calls the methods I've listed. The actionEvent
method looks like this:
checkAndRecord() alters the value of lastProbIndex, but not firstProbIndex, and
returns a boolean.
moveIt() changes the value of firstProbIndex, and then calls setFinalIndex().
setFinalIndex changes the value of lastProbIndex to 1, as expected. But according to the
command line output, the value is 1, but then when the program starts setFinalIndex(),
the value is 0.
The most fishy thing I see here is the checkAndRecord() method, which might change the
value of lastProbIndex to 0 if it does not finish running before moveIt() is called.
But is it possible for the program to start moveIt() before checkAndRecord() finishes?
author and iconoclast
try using 'this' keyword for those fields as they are class variables.
Joined: Oct 12, 2005
I finally figured out what the problem was with this program.
When I was looking at the code carefully one more time I stumbled upon this line:
This was a line inside of my method. So when the System.out.println() commands inside
this method were referencing lastProbIndex, they were referencing the local variable,
and the System.out.println() commands elsewhere in the program were referencing the
class variable. And the class variable lastProbIndex was not really being set to equal
I did not know that the compiler would let you get away with having a local variable and
a class variable have the same name.
By the way, what does 'volatile' mean? You don't have to explain if you could just direct
me to some web page that explains it.
Thank you everyone for your help!
Joined: Oct 13, 2005
Yes, the compiler will allow local variables and fields with the same names. Just think, in some languages (I think C++ is one) you can have local variables in inside blocks with the same name as local variables in outside blocks.
You are probably experienced enough to use an IDE; most of them will warn you if you try using local variables and fields with the same names.
When you have a value, it starts off life in your RAM, then it is moved to the cache on your CPU for processing. Then it is moved into a register, then it is processed, and moved back via the cache to the RAM. So you can have three copies of the variable, and they might not be the same value, or even more than three copies if you have multi-level cache, as most recent chips do.
When the JVM requires the value of that variable, it picks whichever value it thinks most appropriate. In a single-threaded application, the JVM "knows" the history of the values and can find the most recent.
But in a multi-threaded application a thread will start with the copy in RAM, because it doesn't "know" there are any other copies. This might however be an out of date value.
If you label a field volatile, that insists the JVM update the copy in RAM immediately, so other threads find an up to date value there.