Interfaces...

[Rémi Forax]

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. **

Rémi

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.
>
> Cheers,
> Carson
>
> -----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:
>   
>> All
>>
>>  
>>
>> 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,
>>
>>  
>>
>> java.nio.file.Path
>>
>>  
>>
>> 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 
>> processes.)
>>
>>  
>>
>> The package will be a lot more flexible if you make this simple
>>     
> change.
>   
>>  
>>
>> Cheers,
>> Carson
>>
>>     
> Given that Path, FileSystem and FileStore for example are abstract with 
> all methods also abstract, this is already possible.
>
> Mark Thornton
>
>