A small java.io bugfix

[Dalibor Topic]

Hi,

attached you'll find a patch for current CVS version
of Kaffe. This one fixes:

* kaffe/libraries/javalib/java/io/BufferedReader.java

The default size of the buffered reader did not match
Sun's. The JDK 1.2 documentation doesn't say anything
about it besides 

"The buffer size may be specified, or the default size
may be used. The default is large enough for most
purposes."

On the other hand I found a reference in "The Java
Class Libraries, Second Edition, Vol 1", at p 193,
saying:

"There are two forms of the constructor for
*BufferedReader*. The first form constructs for the
reader *in* a buffered reader that has the default
buffer size of 8K characters."

So I fixed that ...

* kaffe/libraries/javalib/java/io/Reader.java

method mark(int readAheadLimit): 

According to The Java Class Libraries, Second Edition,
Vol. 1, the method mark(int readAheadLimit) in the
class Reader should throw an IOError in the default
implementation. Our version doesn't do anything, so of
course it doesn't throw the required IOException.

I also made it throw the IOException with the same
message as Sun's JDK 1.2 does.

method read():

There is a possible race condition when two threads
use the same Reader and both try to read() at the same
time. Imagine the following situation:

A class PseudoReader inherits form Reader and
implements the abstract methods close() and read(char
[], int, int)

In its read implementation, it uses locking based on
the inherited class variable lock, while it writes
character into the buffer, so that's alright.

Thread A calls read(), which in turn calls
read(single, 0, 1), and gets character 'a' stored into
inherited class variable single, but gets interrupted
after it has released the lock and before it could
return from the function read(char [], int, int)

Thread B goes into action and calls read() on the same
PseudoReader, and gets character 'b' stored into
single. It returns 'b' happyly. The inherited class
variable single[0] == 'b' now.

Thread A continues and returns from the read function
as well. Unfortunately, its call to read() returns
'b', which is wrong. (According to JDK 1.2 behaviour,
and "The Java Class Libraries, Second Edition, Vol 1"
documentation for Reader.lock)

method ready():

It should return false by default and not true,
according to JDK 1.2 behaviour, and "The Java Class
Libraries, Second Edition, Vol 1".

method reset():

I've made it throw the same message the JDK does.

method skip(long n):

skip did not block until some characters are
available.

* kaffe/libraries/javalib/java/lang/Thread.java
method toString():

fixed it to produce the string in the same format the
JDK does.

Appropriate regression tests are in the works.

happy checking in,
dali

=====
"Success means never having to wear a suit"
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: application/x-unknown
Size: 3002 bytes
Desc: diff
Url : http://kaffe.org/pipermail/kaffe/attachments/20000110/b5f87213/attachment-0003.bin