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.
.....

Ravi,
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?
Bijesh

class superParent{ ... public class superThis extends superParent { int a; public superThis(){ super(); this.a=5; System.out.println("In Child constructor, a="+a); } .... }
Can somebody throw some light on this?

Swati,
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.
Bijesh
[ 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
Bijesh

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.
class Reader extends Thread { Calculator c; public Reader(Calculator calc) { c = calc; } public void run() { synchronized(c) { try { System.out.println("Waiting for calculation..."); c.wait(); } catch (InterruptedException e) {} } System.out.println("Total is: " + c.total); } public static void main(String [] args) { Calculator calculator = new Calculator(); new Reader(calculator).start(); new Reader(calculator).start(); new Reader(calculator).start(); try{ Thread.sleep(20); //Sleep to make sure the above //threads are all in wait() } catch (InterruptedException e) {} //new Calculator(calculator).start(); Reader2 rd = new Reader2(calculator); rd.start(); } } class Reader2 extends Thread { Calculator c; public Reader2(Calculator calc) { c = calc; } public void run() { synchronized(c) { try { for(int i=0;i<100;i++) { // DO nothing } //c.notify(); //-->A //c.notifyAll(); //-->B //c.start(); //-->C } finally{} } } } class Calculator extends Thread { public Calculator(){}; public void run() { System.out.println("---------->"); } }
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.
Bijesh

Does someone have an answer to this? I've been waiting to see it answered by the gurus.
Bijesh

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!

Firstly,
/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
char c3 = ; char c4 = ;
So ur code above is equivalent to the one below:
public class Test002 extends Super { public static void main(String args[]) { char c1 = '<%1>'; char c2 = '<%2>'; char c3 = ; char c4 = ; } } NOTE: <%1> - whatever \u00AA represents <%2> - whatever \u00DD represents
and hence the compile error.

I have an applet which uses the drawImage method. There is a ImageObserver implementation with the following:
public boolean imageUpdate(Image image, int i, int j, int k, int l, int i1) { if((i & 0x20) != 0) allBitsReceived = true; if((i & 0xc0) != 0) { System.out.println("*** Image load error! ***"); allBitsReceived = true; } return !allBitsReceived; }
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?
Bijesh
P.S. The code is not mine. So I have no idea what is being attempted here.

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
Bijesh

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-
1. class Reader extends Thread { ... 8. public void run() { 9. synchronized(c) { 10. try { 11. System.out.println("Waiting for calculation..."); 12. c.wait(); 13. } catch (InterruptedException e) {} 14. } 15. System.out.println("Total is: " + c.total); 16. } 17. 18. public static void main(String [] args) { 19. Calculator calculator = new Calculator(); 20. calculator.start(); 21. new Reader(calculator).start(); 22. new Reader(calculator).start(); 23. new Reader(calculator).start(); 24. } 25. }
and the Calculator class
27. class Calculator extends Thread { 28. int total; 29. 30. public void run() { 31. synchronized(this) { 32. for(int i=0;i<100;i++) { 33. total += i; 34. } 35. notifyAll(); 36. } 37. } 38. }

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
public class Test { String s = "Test"; public static void main(String argv[]){ Test t = new Test(); System.out.println(t.s); method1(t); System.out.println(t.s); String s1 = "Test"; System.out.println(s1); method2(s1); System.out.println(s1); } public static void method1(Test t) { t.s = "Welcome"; } public static void method2(String s) { s = "This is weird"; } } Output: ------- Test Welcome Test Test
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.
TIA,
Bijesh

IMHO the answer is TRUE. An interface type cannot be implicitly converted to a class-type.
For e.g. code below will not compile
public interface Interface1 { } public class Implementor implements Interface1 { public Implementor() { } public static void main(String[] args) { Implementor implementor = null; Interface1 interfac = new Implementor(); implementor = interfac; } }
U get a compile error on line "implementor = interfac;" But it would compile if changed to "implementor = (Implementor)interfac;"
Am I right?
Bijesh

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?
Bijesh

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
import java.io.File; import java.io.IOException; public class Test { public Test() { } public static void main(String [] s) throws IOException { File file = new File("../teststuff.htm"); System.out.println(file.getAbsolutePath()); System.out.println(file.getCanonicalPath()); file = new File("d:\\teststuff.htm"); System.out.println(file.getAbsolutePath()); System.out.println(file.getCanonicalPath()); } }
Output is as follows
---------------------
D:\Program Files\JDEV_905\jdev\bin\..\teststuff.htm
D:\Program Files\JDEV_905\jdev\teststuff.htm
d:\teststuff.htm
D:\teststuff.htm