Paul,
> Good point, a 'streaming provider' for File could do this.
> Also in the
> case of File it may be possible for the runtime to perform
> asynchronous
> writing (essentially tell the kernel to do the writing). Not sure if
> that is possible today with NIO though... but would be cool to do :-)
>
> Do you think File should be a supported type for this JSR?
Absolutely.
> > Why do you need a specific support for 2) in the API?
>
> Ease of use, development, maintenance, readability.
Not sure I agree.
> > It would be easy to
> > create a custom Representation<T> subclass that would
> carefully optimize the
> > access to the wrapped T instance.
> >
>
> I agree it can be done but IMHO it is unnecessary work for
> developers. We can make it easier for them.
Easier seems to definitely depend on the point of view :)
Best regards,
Jerome