Re: A strange behaviour of a File property

On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:


     My active involvement started in the late 1980's and continued
through the mid-1990's. After I left the company in 1998, they
re-engaged me as an out-of-hours independent contractor to do yet
a little more maintenance work. So I guess the time range was
between 1.5-2.5 decades ago. VMS' development, of course, did not
end when my involvement with it ceased.

     Still, my principal point is not about support of "dinosaur
systems," but that even the most modern systems we know today will
eventually be dinosaurs. The File class offers an abstraction,
which File.pathSeparatorChar promptly breaches: "Java refuses to
support any system whose file names do not consist of sequences
of component names separated by a single distinguished character."
Given that File offers ways to assemble and disassemble file names
without this knowledge, was exposing the knowledge a bright idea?
Is a programmer better off using that exposed implementation, or
sticking to the higher-level abstraction?

     <Falling into a prophetic trance>: The year 2014 will see the
introduction of a brand-new paradigm for thinking about persistent
storage, one in which names cannot be so trivially encoded. By 2017,
systems based on this new scheme will have swept away all the naive
file-naming notions of Unix, MS-DOS, VMS, AIX, and VM; even URI's
will be on their way out. Will Java be part of the problem, or part
of the solution?

--
Eric Sosman
esosman@ieee-dot-org.invalid