[jcifs] Re: Abstract File(File, SmbFile) and enhanced Servlet
Rolf.Breuning at t-online.de
Tue Jun 1 18:38:28 GMT 2004
I agree that the best solution would be an interface, enhanced by one
real object which holds a dictionary of schemes (smb:// file:// ...) and
factories and thus allows to create instances of the various kinds of
This, however, is - a Eric stated - more an extension unconnected to
jcifs. It needs much thinking off what such a kind of abstract file
really is, the java.io.File class may be a good start, but as you see
from the "canonical name" and the "directory / file / other smb entity"
consideration, java.io.File is not quite enough. I personally would like
to see such a thing in Java, but I am not in a position to start a Java
Community Extension proposal, which would be the best thing to get to a
That is why I proposed an abstract class with inner classes: I don't
forsee that it is easy to solve the large problem, thus I proposed a
"minimal invasive" addition to jcifs, an here the abstract class has the
advantage of being a 1 file solution. Adding further capsules is
possible though in fact that is only an idea. I don't see the
inheritance here as a big issue, because you will want any other
potential file class in any case remain in their domain and only to have
One might have small objections against the generic proxy approach
because of performance, but most probably for the file interface that is
not that important - it indeed reminds me of the nice things one could
do in Smalltalk using #doesNotUnderstand: :-)
So IMHO we end up with some possible solutions:
1. Integrate the abstract class in jcifs.
2. Integrate the generic solution in jcifs.
3. Strive for some larger solution
I forsee that 3. is a very tedious, but I'm not that experienced in
freeware creating / handling, may be you can give your ideas on that.
If 3. is too big I still would like to see a solution for jcifs be it 1
or 2 or a combination. But that would then most probably remain a pure
jcifs related solution.
>> Ahh, ok. I thought that was Rolfs post. I'll have to look at each
>> and compare. Would it be benifical for SmbFile to implement a "File"
> Possibly; but this would typically be done as part of a larger
> framework (i.e., a provider implementing some framework's interface,
> using jCIFS as the backing implementation). Defining a "file"
> interface just to have SmbFile implement it is somewhat limited in
> use, since java.io.File etc. doesn't implement the interface. If an
> external application/framework already supplies such an interface for
> providers, it would be typically be more appropriate to implement a
> wrapper for both SmbFile and java.io.File. This is effectively what
> both of the code samples do; define an interface (or in Rolf's case,
> an abstract class), then define implementations for SmbFile and
> This is useful functionality (I've looked at doing similar extensions
> for Davenport, to allow pluggable filesystem providers); it would just
> typically reside in a layer "above" jCIFS. But if others would find
> it useful, I don't have any problem with it. IMHO, an interface
> provides more flexibility than an abstract class (as it doesn't take
> up the single inheritance slot). But either is okay by me, as long as
> it doesn't break existing functionality (naturally).
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the jcifs