Recent builds of Merlin b57 have failed when the IDLJ compiler generates
a truncated output file. The failure is intermittent. We've seen it
on Solaris Sparc builds (mostly 64-bit, but there's one report on 32-bit)
and Linux builds, but not on x86 or Windows. Not a likely combination,
but this could be a coincidence.

The part of the build that fails is:

>>>Recursively making sources all @ Wed Mar 21 02:46:22 PST 2001 ...
gnumake[5]: Entering directory `/net/mersparc/usr/re/jdk/jdk1.4/ws/make/com/sun/corba/se/sources'
../../../../../../build/solaris-sparc/bin/java -classpath "../../../../../../build/solaris-sparc/classes:" com.sun.tools.corba.se.idl.toJavaPortable.Compile -td ../../../../../../build/solaris-sparc/gensrc -i ../../../../../../build/solaris-sparc/gensrc/com/sun/corba/se/ActivationIDL -fall -oldImplBase -pkgPrefix ActivationIDL com.sun.corba.se ../../../../../../src/share/classes/com/sun/corba/se/ActivationIDL/activation.idl

The generated file that gets truncated is
gensrc/com/sun/corba/se/ActivationIDL/_ServerManagerStub.java

% tail -4 _ServerManagerStub.java
    } catch (org.omg.CORBA.portable.ApplicationException $ex) {
       $in = $ex.getInputStream ();
       String _id = $ex.getId ();
       if (_id.equals ("IDL:Ac

The last line of _ServerManagerStub.java was generated by
com.sun.tools.corba.se.idl.toJavaPortable.MethodGen.writeStubBody().
On line 598 it calls:
        stream.println ("(_id.equals (\"" + exc.repositoryID ().ID () + "\"))");
where stream is a PrintWriter created in this way (according to kenc):
  The relevant bit of code to look at is
  com.sun.tools.corba.se.idl.GenFileStream, which extends PrintWriter.
  This class constructs its superclass PrintWriter by passing it a
  CharArrayWriter. The overridden close method then writes the
  character array from the CharArrayWriter to a file using a FileWriter.

You can see that the file is truncated in mid-String.
They call close() but not flush(), and do not use auto-flush,

The size of the truncated output file is 8192, a multiple of 1024.

There's been some speculation that NIO is involved.

kbr has seen similar behavior in a different context.