Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link

Bijesh Krishnadas

Ranch Hand
+ Follow
since Aug 08, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Bijesh Krishnadas

Originally posted by RaviKumar Golagani:
Hi Swati,
But they both can be in the same constructor, just make sure that super() must be the first statement to be placed in the constructor, or else it may throw a compile time error.

I think u misunderstand. super() and this() cannot be present in the same constructor. In swati's code we don't have super() and this() in the same constructor. We have only super(), this is used just as an object.
Use of both super() and this() are restricted by the condition that they can be used only as the first statement of a constructor. Both cannot be the first statement at the same time and so cannot be used together in the same constructor.
Am I making this too confusing?

Can somebody throw some light on this?

u cannot use super( <args> ) and this( <args> ) within the same constructor.
NOTE: super( <args> ) invokes a constructor in the parent and this( <args> ) is used to invoke another constructor within the same class.
In your code above u access the super() constructor invocation and the this object (not the constructor call). perfectly legal.
[ March 19, 2004: Message edited by: Bijesh Krishnadas ]
[ March 19, 2004: Message edited by: Bijesh Krishnadas ]
run() is a non-abstract method in Thread. Which is why u dont need to override the method in your class
I have a hypothesis here:
1) If the object being synchronised(syncObj) is a thread by itself, then merely running this object's thread to completion does something similar to notifyAll()
below is the research I did.

Running the code as is results in all Reader threads waiting forever.
Running with line A uncommented wakes up exactly one thread.
Running with line B uncommented wakes up all threads.
Running with line C uncommented wakes up all threads.
So wat say ppl? Is this another weird but true or does the JLS actually talk about this.
Gurus, ur thoughts, plzzz.
Does someone have an answer to this? I've been waiting to see it answered by the gurus.

Originally posted by fethi makhlouf:

char c2 = '\u00DD';
char c3 = '\u000D';
char c4 = '\u000A';

can somone tell me why c1 and c2 are valid values wheras c3 and c4 are not!

/u000d represents carriage return
/u000a represents new line
Now the first thing that the compiler does is convert the unicode into the respective characters. This happens, I guess, even before the actual compilation process starts.
So the c3 and c4 lines when passed to the compiler would look like this

So ur code above is equivalent to the one below:

and hence the compile error.
I have an applet which uses the drawImage method. There is a ImageObserver implementation with the following:

The applet works perfectly with JRE 1.3, but fails to load the background image in JRE 1.4.
Also in 1.4 the console shows the message "*** Image load error! ***"
Are there any known incompatibility between JRE 1.3 and 1.4?
P.S. The code is not mine. So I have no idea what is being attempted here.
18 years ago
There is no implicit conversion of
> Interface type into implementing class
nor of
> super-class type into sub-class.
Explicit conversion will compile but runs the risk of ClassCastException if improper casting is done

Originally posted by CH Lee:

each InSync will have their own (StringBuffer letter)? Am I right? This is because StringBuffer is not defined as static or anything. Whenever an object (InSync) is created, they will have their own copy of letter. If this is the case, there is no necessity to use synchronise at all?

Each InSync object will have its own reference variable, correct. But each of those variables refers to the same object cos we are passing the same reference into the constructors. And so there is a need to synchronise. Probably the terminology I used is incorrect, but I guess u shuld get the general idea.
I guess the best example to use synchronization would be the Producer-Consumer problem.... That will make it clear where such a situation would be useful. Look her for Jyoti's example :
Jyoti's Page
Okie I got it figured out...
From Java Tutorial on Sun:

In Java methods, arguments are passed by value. When invoked, the method receives the value of the variable passed in. When the argument is of primitive type, pass-by-value means that the method cannot change its value. When the argument is of reference type, pass-by-value means that the method cannot change the object reference, but can invoke the object's methods and modify the accessible variables within the object.

So method2() was trying to change the reference of the String object and this change will not be available outside of the method... Pretty simple, huh?
I hope I am right here. If u notice the "calculator" thread is started first, acquires a lock on the object, excecutes and does a notifyAll. The Reader threads start after this, print the message and do a wait(). Therefore the calculator issues a notifyAll(), even before any of the Reader threads have issued a wait(), and hence has no effect.
Hope it is right and clear to you.

Originally posted by scjp-to-be:
hello everyone-

and the Calculator class

I just got confused. I thought changes made to an object passed to a method are reflected outside the method, i.e. the method actually receives a copy of the reference (not object).
Here sName is an object, then why doesn't the change get reflected.
Consider code below

When the change to Test object in method1 is seen outside the method, why doesn't the same thing happen with the String object. I know I am missing something very simple here but cannot figure it out.
IMHO the answer is TRUE. An interface type cannot be implicitly converted to a class-type.
For e.g. code below will not compile

U get a compile error on line "implementor = interfac;" But it would compile if changed to "implementor = (Implementor)interfac;"
Am I right?

Originally posted by narasimha rao bandlamudi:

2. When you say, p1.anotherMethod() - anotherMethod() is non-static, hence it will be invoked from the run time type of the object, which is nothing but new Child(), hence anotherMethod() from the Child class will be invoked and the output is Child -- anotherMethod.
When you call aMethod() from anotherMethod() from Child class, actually it will be resolved to - this.aMethod(), and this will refer the object on which anotherMethod() is called which is nothing but new Child(), hence aMethod() of Child class will be invoked, hence the output, Child -- aMethod.

In other words within a non-static method (here anotherMethod), the current object(this) will not be considered as the Parent object holding the Child reference, but as a genuine Child object...
Get what I mean??? And if u do, am I right?
From J2SE 1.3.1 API Specs

A canonical pathname is both absolute and unique. The precise definition of canonical form is system-dependent. This method first converts this pathname to absolute form if necessary, as if by invoking the getAbsolutePath() method, and then maps it to its unique form in a system-dependent way. This typically involves removing redundant names such as "." and ".." from the pathname, resolving symbolic links (on UNIX platforms), and converting drive letters to a standard case (on Win32 platforms).

See the following code

Output is as follows
D:\Program Files\JDEV_905\jdev\bin\..\teststuff.htm
D:\Program Files\JDEV_905\jdev\teststuff.htm