In this issue, we have a detailed article on Strings in Java and .NET.

Please send suggestions, corrections and comments to techlet@durasoftcorp.com.

using System;

namespace Sample
{
	class Test
	{
		[STAThread]
		static void Main(string[] args)
		{
			double val1 = 22.25;
			double val2 = 0.89;

			Console.WriteLine(val1.ToString() + " & " + val2.ToString());
		}
	}
}

Send your response to techlet@durasoftcorp.com, and you may become the winner of this year's TechLet special prize.

The following code does not compile. Make minimal change (one word) to fix it. Explain the reason why Java compiler insists on this change?

public class Test
{
	public static void call(Test obj)
	{
		new Thread(new Runnable()
		{
			public void run()
			{
				obj.doSomething(); // Perform in a new thread.
			}
		}
		).start();
	}

	public void doSomething() 
	{ // does some thing...
	}
}

Answer!

Thanks to those who wrote to use with a response to this quiz. Your names have been entered for the year end drawing!

Of course, the change that needs to be made to the code is to add the word "final" to the parameter of the call method as in: public static void call(final Test obj).

There is more than one answer to this question. One of the correct answers came from Ken. He writes, "This is because the method call can could change the object that obj points at (change the reference). This would mean that the obj.doSomething() would be calling on the wrong object... Setting it final prevents this change. It does not prevent the programmer from altering the contents of obj, which would need to be made thread safe. This also lets the JRE optimize the thread environment to depend on the object references not changing between threads.."

Ken is right on the money. Another way to look at this would be to see that the reference "obj" is a local variable within the call method and is on the stack for the method invocation. It goes out of scope as soon as the method ends and the stack is unwound. It gets sticky if some other thread needs this reference on the call's stack! This problem is avoided by each inner class object making a copy of the reference. Essentially, the object of the anonymous inner class (that implements Runnable) will hold a copy of the obj reference. Of course, if copies of reference is made by inner class, it would not make sense (should I say mathematically?) to change these references in the call method. Declaring the reference final imposes this semantic constraint.