The issue of FileDescriptor's has come up again. Here are the facts:
-- java.io.FileDescriptor is final
-- java.io.FileDescriptor has no public constructor that can create a valid
object
This is necessary to prevent malicious applications from creating
FileDescriptors for arbitrary native fd's. However, parts of the standard
class library need to create them. Specifically:
-- java.net.SocketImpl and java.net.DatagramSocketImpl have methods that
return an instance of FileDescriptor
-- java.lang.Process has methods that return {Input,Output} streams to
read/write to the subprocess which would most easily be implemented by new
FileInputStream(new FileDescriptor(fd)). Without this that class needs to
re-create its own read/write infrastructure. Not good.
I seem to recall that I once figured out a way to accomodate this in the
library itself. Now I am not so sure. I think that we will need to add a
mechanism for doing this to the VM integration layer. Or add another
(non-standard) FileDescriptor constructor and an associated Permission
("createFileDescriptor", for example) that would do things in the library.
The latter is probably the easiest way, though would bring us out of
conformance with the spec.
Ideas? Comments? I'd like to resolve this soon.
--
Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
