Integrating Win32 changes

Sat Apr 1 00:00:00 GMT 2000

"Jon Beniston" <jb7216@bristol.ac.uk> writes:
> First up, you can't do new FileDescriptor(0) for setting up the standard i/o
> streams (as is done in java/io/FileDescriptor), should I have a new file
> Win32FileDescriptor.java or would it be best to implement a native function
> such as FileDescriptor::getStdHandle(int) for all ports.

There ware various alternative solutions to these kinds of problem:
(1) Make FileDescriptor be an abstract call, with (for example)
Win32FileDescriptor as a sub-class. The Java API doesn't allow that.
(2) Peer classes. Define FileDescriptorPeer an as abstract class,
and then sub-classes such as Win32FileDescriptorPeer. This is the
solution used by AWT. The disadvantage is extra overhead, because
each call to a FileDescriptor must then make a virtual call
to a FileDescriptorPeer.
(3) Conditional compilation or separate implementation files.
That is what we currently do any, and seems best.
I suggest keeping FileDescriptor.java, but adding natFileDescriptorWin32.cc,
like we already have natFileDescriptorEcos.cc and natFileDescriptorPosix.cc.
You need to hack configure.in the select the correct value of FILE_DESCRIPTOR.
(That means you probably need CygWin32 to *build* libgcj - but you don't
necessarily need it to *run* libgcj.)
The specific issue about Win32 FileDescriptor are not specified using
an int. I would do:
- // System's notion of file descriptor.
+ // System's notion of file descriptor (use one or both):
 private int fd;
+ private gnu.gcj.RawData handle;
and you can hang your windows-specific data structures off `handle'.
To initialize in, out and err, we should perhaps do:
 public static final FileDescriptor in;
 public static final FileDescriptor out;
 public static final FileDescriptor err;
 private static native init();
 static { init(); }
and have java::io::FileDescriptor::init() actually
allocate in, out, and err.
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/~per/