cgross at guidewire.com
Mon Jun 22 14:44:38 PDT 2009
Of course there are tradeoffs. I still think that an interface, coupled with a solid base class for the 90% use cases, is the right thing. If someone doesn't extend the base class because there implementation is sufficiently different, then they *should* have to think about the new method. I regard that as a feature of interfaces, not a shortcoming.
Anyway, I'm sure you all know all this. I'm just registering my random-guy-on-teh-internets opinion: I'd like interfaces. At the same time, an abstract class is a huge step forward from the old library.
I'll go away now.
From: Rémi Forax [mailto:forax at univ-mlv.fr]
Sent: Monday, June 22, 2009 1:21 PM
To: Carson Gross
Cc: Mark Thornton; nio-dev at openjdk.java.net
Subject: Re: Interfaces...
Interfaces are not really future proof,
at least until we have extension methods,
you can't add a new method to an interface without breaking
the backward compatibility.
By example, Reader is an abstract class defined in 1.1,
this had allowed read(CharBuffer) to be introduced in 1.5. **
Carson Gross a écrit :
> Ah, right. Didn't catch that. I'd still advocate for an interface, so
> you don't have to corner yourself in an inheritance hierarchy.
> Still, infinitely better than File.
> -----Original Message-----
> From: Mark Thornton [mailto:mthornton at optrak.co.uk]
> Sent: Monday, June 22, 2009 12:43 PM
> To: Carson Gross
> Cc: nio-dev at openjdk.java.net
> Subject: Re: Interfaces...
> Carson Gross wrote:
>> I'm not on list, so feel free to ignore me, but I'd like to ask that
>> you consider extracting interfaces for the core classes in the nio2
>> library. For example,
>> should have a corresponding interface, with the same methods at Path,
>> so that people can write code against the interface, rather than the
>> implementation. This would facilitate testing against a file system,
>> a notoriously touchy problem when dealing with disks, and would give
>> people the opportunity to provide innovative implementations of the
>> interface (e.not-so-g. putting up a path-based representation of
>> The package will be a lot more flexible if you make this simple
> Given that Path, FileSystem and FileStore for example are abstract with
> all methods also abstract, this is already possible.
> Mark Thornton
More information about the nio-dev