[kaffe] DataInputStream related merge

Jukka Santala jsantala at morphine.tml.hut.fi
Tue Oct 22 06:48:58 PDT 2002

On Tue, 8 Oct 2002, Dalibor Topic wrote:
> could you give pat's serialization patch a try and see
> how that works in your context?
> You can find the details at:
> http://www.kaffe.org/pipermail/kaffe/2002-September/008900.html

Well, I could, but that has nothing to do with XML parsing, so it doesn't
help with this problem...

> I switched DataInputStream to method b recently for
> that reason. I don't think going back to the previous
> version is a good idea, as it fixes one bug by
> introducing another.

Actually, the switch to method b fixed one bug by introducing another ;)
If there is a release to be soon (as one would hope), I hope that patch is
reversed until it can be fixed properly, since it introduces a real world

> It may be a bug in our HTTP handling code, for
> example. A small test could help me come up with a
> less invasive solution ;)

I tried to track out exactly what our code does, but unfortunately the
stream implementation is so deep inside the parsers I had to give up.
However, if you look at the source it's pretty obivious - skipNextLF is
local (and private) to DataInputStream, and thus cannot even be accessed
by anything else - including anything else based on FilterInputStream and
InputStream, which happen to be the base classes for almost all IO. The
safest and possibly best performing solution would be to maintain the flag
in native IO code, this might even somewhat offset the performance hit
from having to check the flag for all IO.

This is probably the minimal needed to tickle the problem:

import java.io.*;

public class InputStreamTest {
        static public void main (String args[]) {
                try {
                        StringBufferInputStream sbis =
                        DataInputStream dis = new DataInputStream(sbis);

                } catch (IOException ioe) {

/* Expected Output:

 -Jukka Santala

More information about the kaffe mailing list