commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [JCI] Moving fam module to Commons IO
Date Wed, 07 Nov 2007 17:53:49 GMT

On 07.11.2007, at 04:54, Niall Pemberton wrote:

> On Oct 21, 2007 7:12 AM, Mario Ivankovits <mario@ops.co.at> wrote:
>> Hi!
>>
>>>> Maybe it would make more sense to do these changes in commons- 
>>>> jci-fam
>>>> first and then move that to a new commons-fam?
>>>>
>>>
>>> Sounds reasonable, although I still think IO is a better home for  
>>> fam
>>> than a separate component.
>> In any case, it would be creat if the code is built in a way that  
>> makes
>> it possible to plug VFS in there too. The VFS fam is far from being
>> perfect :-(
>
> I'm not sure how this would be possible - since we would need to
> abstract away from java.io.File - which is exactly what VFS does. For
> me theres value in a "closer to the metal" impl. that just deals with
> java.io.File and an abstract VFS version.


Well, one thought would be to use generics. The JCI monitor expects a  
very simple interface that both the native java.io.File and the VFS  
abstraction share. (see FilesystemAlterationObserverImpl.MonitorFile)

      private interface MonitorFile {
          long lastModified();
          MonitorFile[] listFiles();
          boolean isDirectory();
          boolean exists();
          String getName();
      }

The problem here is that in java you need to explicitly implement an  
interface to be compatible with the interface (not just implement the  
methods described through it). So while this would work

  public FilesystemAlterationListener<E extends MonitorFile> {
    onFileChange(E file)
    ...
  }

  public class FAM<E extends MonitorFile> {
   ...
  }

and VFS could just implement the MonitorFile  
interface ...java.io.File cannot (although it actually does). I fear  
the only way to share the same code would be

  a) through reflection
  b) have VFS extend the java.io.File class. But I guess we already  
agreed in the "compress" thread that is not really a good idea.
  c) use the interface in the Listener

     public FilesystemAlterationListener<E extends MonitorFile> {
       onFileChange(MonitorFile file) {
          File f = (File) file.getImpl(); // UGLY!!
       }
       ...
     }

     but that sucks as you cannot get to the actual implementation  
easily.


Thoughts?

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message