thomas

Thanks Paul for responding. If I type a and then CTRL-Z, I get the same lines as you i.e. all lines one would normally expect. But when I type a, then press ENTER and then type CTRL-Z, I see the following lines on the screen:
1st echo - 97
2nd echo - 97
1st echo - 13
2nd echo - 13
1st echo - 10
2nd echo - 10
2nd echo - -1
You see, I am missing the first echo for -1. But when I direct the output to a file as follows
java test > file.txt
then I get all the echos correctly
1st echo - 97
2nd echo - 97
1st echo - 13
2nd echo - 13
1st echo - 10
2nd echo - 10
1st echo - -1
2nd echo - -1
Could it be that the input and output are getting mixed up in some way when both show up in your DOS window?

When I run the following code and type CTRL-Z (on Windows PC), then System.in.read() should return -1 and System.out.println("1st echo - " + i) and
System.out.println("2nd echo - " + i) should echo it on the screen. This is the way things happen if CTRL-Z is the first thing I type after running the program. If I type CTRL-Z after typing some other input, then I do NOT get the first echo! Can somebody explain? Thanks in advance!
<PRE>
import java.io.*;
public class test {
public void run() {
int i = 0;
try { while (i!=-1) {
i = System.in.read();
System.out.println("1st echo - " + i);
System.out.println("2nd echo - " + i);
}
} catch(IOException ioe) { System.out.println("caught IOException"); }
}
public static void main(String[] args) {
new test().run();
}
}
</PRE>

Mukesh, that was a nice summary on threads. There is one thing I want to bring up.
<Q>I/O operation � if an executing thread calls any method which requires some input stream to be responded, then the thread waits for such input and hence is blocked. Any such blocking of thread will ensures that it releases the lock.</Q>
Is that true? I think blocking for I/O does not release any locks that are held. Try the following code for example.
<CODE>
import java.io.*;
public class r implements Runnable {
static byte[] b = new byte[0];
String name;
r(String name) { this.name = name; }
public void run() {
synchronized (b) {
for (int count=0; count<10; count++) System.out.println(name + count);
int i = 0;
try { while (i!=-1) {
i = System.in.read();
System.out.println(name + i);
}
} catch(IOException ioe) { System.out.println(name + "IOException"); }
}
}
public static void main(String[] args) {
Thread t1 = new Thread(new r("first thread - "));
t1.start();
Thread t2 = new Thread(new r("second thread - "));
t2.start();
}
}
</CODE>
When you run this code, the first thread prints 0 to 9 and then blocks for I/O. But it does not relinquish the lock. If it did, the second thread would have printed 0 to 9 immediately after the first thread prints 9. But in fact, the second thread prints 0 to 9 only after the first thread completes I/O.
Note:- Press the end of file indicator (CTRL-Z on PCs) to stop reading from System.in
Do all agree ?

Sampath:
The point is that the code below does NOT compile with JDK 1.2
<pre>
char charExpression;
final byte b = 0x41;
charExpression = b;
</pre>
The compiler says that an explicit cast is neeed on the third line. Now, could you compile this OK? If you are using JDK, what version are you using?

[This message has been edited by thomas (edited September 20, 2000).]
[This message has been edited by thomas (edited September 20, 2000).]

The following code gives a compiler error saying return inside static initializer. But there are no static initializers in the code!
<pre>
public class test {
int i;
{
int i = 1;
if (i==2) return;
else i = 2;
}
public static void main(String[] args) {
new test();
}
}
</pre>
I assume this is a case of incorrect diagnostics. Should have said instance initializer instead of static initializer! I am using JDK 1.2 on Win 98.

JLS first edition says that during assignment a narrowing primitive conversion is allowed provided:

• The expression is a constant expression of type int.


• The type of the variable is byte, short, or char.


• The value of the expression (which is known at compile time, because it is a constant expression) is representable in the type of the variable.

In JLS second edition, the first condition is amended to read:

• The expression is a constant expression of type byte, short, char or int.

So a compiler based on JLS 1st ed. should scream at both the assignment and the switch, and a compiler based on JLS 2nd ed. should have no problem with either.
My JDK 1.2 compiler screams at the assignment (when cast is omitted) but passes the switch!
Now Jim, you said the assignment without a cast compiled OK. So presumably you are using a more recent compiler and this confusion does not exist. Is that right? Are you using JDK 1.3?
How about Michael and Mapraputa?


[This message has been edited by thomas (edited September 20, 2000).]

IMHO the answer is Set

I am curious if there is an inconsistency between the JLS and JDK with respect to the switch statement OR if it is some inconsistency in my understanding.

The JLS says that in a switch statement, the constant expression in the case label should be assignable to the type of the integral expression appearing after the switch keyword.
But in the following code, the integral expression is of type char and the case label value is of type byte. This code compiles and runs without a hitch eventhough values of type byte CANNOT be assigned to variables of type char without an explicit cast!
<CODE>
public class swicht {
public static void main(String[] args) {
char charExpression = 0x41;
final byte b = 0x41;
switch (charExpression) {
default:
System.out.println("default");
break;
case b:
System.out.println("byte - " + b);
break;
}
charExpression = (char)b; // explicit cast needed
System.out.println("charExpression - " + charExpression);
}
}</CODE>
Is there an inconsistency between the specification and the JDK implementation here? I am using JDK 1.2 on Win98. Pls help.

What is the difference between PrintStream and PrintWriter classes?
Both have a number of print() methods which convert the argument to a string and print it based on the character encoding of the underlying platform.
It is my understanding that Stream classes in general do not convert their output to the encoding of the underlying platform, where as Writer classes do. But PrintStream appears to be an exception. If that is the case, what way does it differ from a PrintWriter ?
Thanks in advance.

Sanjeet:
static methods ARE inherited like instance methods. The discussion has been about what happens when a sub class defines a method with the same signature as a static method in the super class.

trinity:
This has been discussed on this forum many times. Do a search. You will find some good discussions by Jim, Maha, Ajith and others.

If you define a method in a sub class which has the same signature as a static method in the super class, the compiler enforces the following conditions:
1. The sub class method also has to be static
2. The return type of the sub class method should be the same as that of the super class method
The second condition is similar to one enforced for overriding instance methods. But if you create an instance of the subclass and invoke the static method, the method which gets invoked depends on the reference type. This is shown in the following code:

public class a {
static void staticMethod() {
System.out.println("static method in class a");
}
public static void main(String[] args) {
b b1 = new b();
b1.staticMethod();
a b2 = new b();
b2.staticMethod();
}
}
public class b extends a {
static void staticMethod() {
System.out.println("static method in class b");
}
public static void main(String[] args) {
b b1 = new b();
b1.staticMethod();
a b2 = new b();
b2.staticMethod();
}
}
The output is:

static method in class b
static method in class a
This behavior is entirely different from overriding. Hence, static methods are NOT overridden.
Do you agree?

nito:
Usually it is the repaint() method that you call from your application. The repaint() method in turn calls update(Graphics g) which in turn calls paint(Graphics g).
If you want to call the update(Graphics g) method directly, you will need to first get a reference to the graphics context and pass it as a parameter.
On the other hand, when you call the repaint() method, AWT takes care of getting a reference to the appropriate graphics context and passing it along to the update(Grahics g) method.
This is one reason to use the repaint() method instead of the update(Graphics g) method.

[This message has been edited by thomas (edited August 19, 2000).]

avn:
When you remove the static modifier from the super class method, the code still prints
super
Please check.