This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: FileDescriptor suggestion [Was: FYI: Patch: java nio file locking]
Michael Koch wrote:
The problem with FileDescriptor is that it should not extend another new
class/implement another new interface. And you cannot subclass it
because its final. There is no really good design possible. The only
bad things we can do is to add private or package-private methods/fields.
Right:
public final class FileDescriptor {
private final gnu.java.nio.channels.FileChannelImpl channel;
...
}
FileDescriptor is used for network stuff too. Making it a wrapper for
FileChannel would be far away from good design as heaven is from hell.
I disagree. You're just stating this, without giving any reason.
I dont know what SUN intended with this class or how they implement
stuff (and I dont wanna know either). The only clean way I can think of
is put the implementations (for Posix, Win32, etc) into a new class
(probably located in gnu/java/io or so) and then use this from
java.io and java.nio.
That's exactly what I'm proposing, except I'm proposing to call it
gnu.java.nio.channels.FileChannelImpl, with subclasses FileChannelPosix,
FileChannelWin32 etc, and have FileChannelImpl inherit from FileChannel.
int in java is always 32 bit. Even on 64-bit systems.
> In contrary to C.
Out of curiosity, do you know of a target (that we're likely to support
for GCJ) where is C int is 64 bits? long is 64 bits on 64-bit systems,
but my impression is that the consensus is that int is 32 bits.
--
--Per Bothner
per@bothner.com http://per.bothner.com/