«

On 2011-11-12 01:38:55 +0000, Eric Sosman said:

> On 11/11/2011 11:25 AM, Andreas Leitgeb wrote:
>> <> wrote:
>>> public class Main {
>>> public static void main(String[] args){
>>> File f = new File("."); // try to change the path
>>
>> ...
>>
>>> for(int i=0; i<content.length; i++){
>>> file_array[i] = new File("." + "\\" + content[i]);
>>
>> First of all, did you change the path also here?
>> or better: define a variable and use it in both spots.
>>
>> Second, hardcoding "\\" is the worst approach at assembling a
>> file name from components. See the docu for File class for
>> a static field that contains the appropriate separator char
>> for the current platform. For test code, "/" is often good
>> enough (even on Windows).
>
> Even better is to forgo the silly string-bashing and let File
> figure it out:
>
> File parentDir = ...;
> File childFile = new File(parentDir, "child");

You don't need that, either, if all you're doing is enumerating
directory contents like the OP. File exposes a method for obtaining the
entries of a directory *as File objects* already, so reconstructing
File objects from the base names and parent directory is pretty much
wasted effort.

Have a look at the listFiles() method.

-o

Owen Jacobson wrote:
> Eric Sosman said:
....
>> Even better is to forgo the silly string-bashing and let File
>> figure it out:
>>
>> File parentDir = ...;
>> File childFile = new File(parentDir, "child");
>
> You don't need that, either, if all you're doing is enumerating
> directory contents like the OP. File exposes a method for obtaining the
> entries of a directory *as File objects* already, so reconstructing
> File objects from the base names and parent directory is pretty much
> wasted effort.
>
> Have a look at the listFiles() method.
>
> -o

When quoting him, you left out the part of Eric's post that said:
> (In the O.P.'s specific case, using listFiles() instead of list()
> would simplify things a good deal.)

--
Lew

On 11/13/2011 3:50 PM, Andreas Leitgeb wrote:
> Eric Sosman<> wrote:
>> Speaking as a person who wrote code that tried to mediate
>> between VMS ("structured") file names and Unix ("just glob it") paths,
>> I am here to tell you that there are many subtle traps. Version numbers
>> inevitably got garbled, if not "in translation" then "in manipulation"
>> on the other side of the fence. The fact that the parent directory of
>>
>> SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
>> was
>> SYS$DISK:[USERS.ERIC]PROJECT.DIR;1
>>
>> baffled innumerable Unixoid programs that thought they could just "take
>> everything before the rightmost separator" to get the parent's name.
>> Anybody who thinks the mapping is half a day's work has got another
>> think coming -- and weeks of unplanned labor, too. I've got the scars.
>
> I'm still wondering, how this effort was even worth it.

In hindsight, you're right. We should have just ditched the
VMS port of our product on the grounds that the platform was too
ugly and/or baroque and/or expensive and/or unfamiliar.

But, alas! We allowed ourselves to be influenced by the market,
instead of holding to our ideological purity. The fact that VMS was
the second most popular platform for our product (in one quarter it
actually took the top spot) caused the bean counters to insist that
we support it. Stupid bean counters!

> Dinosaur systems [...]

Note that Unix is even older than VMS.

--
Eric Sosman
d

Eric Sosman <> wrote:
> On 11/13/2011 3:50 PM, Andreas Leitgeb wrote:
>> Eric Sosman<> wrote:
>>> [...] baffled innumerable Unixoid programs that thought they could just
>>> "take everything before the rightmost separator" to get the parent's name.
>>> Anybody who thinks the mapping is half a day's work has got another
>>> think coming -- and weeks of unplanned labor, too. I've got the scars.
>> I'm still wondering, how this effort was even worth it.
> In hindsight, you're right. We should have just ditched the
> VMS port of our product on the grounds that the platform was too
> ugly and/or baroque and/or expensive and/or unfamiliar.
> But, alas! We allowed ourselves to be influenced by the market,
> instead of holding to our ideological purity. The fact that VMS was
> the second most popular platform for our product (in one quarter it
> actually took the top spot) caused the bean counters to insist that
> we support it. Stupid bean counters!

(I appreciate good irony)

How recent was your porting activity? (months, years or decades?)

>> Dinosaur systems [...]
> Note that Unix is even older than VMS.
Yeah, it's also older than OS/2...

On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
> [... concerning VMS ...]
>
> How recent was your porting activity? (months, years or decades?)

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
d

Eric Sosman <> wrote:
> On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
>> [... concerning VMS ...]
>> How recent was your porting activity? (months, years or decades?)
> [ Answer: essentially last century ]
Do you think, the same management would make
that decisions again nowadays for nowadays'
marketshare of VMS?

Anyway, I agree that using the abstraction that File provides
is principially better than doing one's own path-arithmetics.
I also agree, that providing the pathSeparator impedes the
abstraction.

But then again, if that weren't there, then those who don't
hardcode "\\", anyway, would probably query the OS, and do a
short if-elseif-chain for the OS's they know of to pick some
pathSeparator, or construct some File("a","b"), and somehow
(heuristically) extract the pathSeparator from that.

Sometimes, abstraction also gets into your way: how would you
model a relative path that starts with going one or more levels
up? I think to remember that MacOS (before 10) didn't have
such a concept. Did(/does) VMS?

> <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?

A very good argument. I doubt, however, that even those using the
current File API in the cleanest possible way, will necessarily be
fit for those future filesystem changes.

On 11/15/2011 9:17 AM, Andreas Leitgeb wrote:
> Eric Sosman<> wrote:
>> On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
>>> [... concerning VMS ...]
>>> How recent was your porting activity? (months, years or decades?)
>> [ Answer: essentially last century ]
> Do you think, the same management would make
> that decisions again nowadays for nowadays'
> marketshare of VMS?

Would they decide to sell product on one of the most popular
platforms in their ecosystem? I hope so!

Would they decide to drop a platform because it would mostly
disappear within, oh, sixty-plus financial quarters? I hope not!

> Anyway, I agree that using the abstraction that File provides
> is principially better than doing one's own path-arithmetics.
> I also agree, that providing the pathSeparator impedes the
> abstraction.

> Sometimes, abstraction also gets into your way: how would you
> model a relative path that starts with going one or more levels
> up?

File child = ...;
File parent = child.getParent();
File grandparent = parent.getParent();
...

> I think to remember that MacOS (before 10) didn't have
> such a concept. Did(/does) VMS?

Can't answer for MacOS. In VMS, sure: A file or directory was
either at the topmost level of its file system or it was contained
in a parent directory, and you could find the parent, and so on.

>> <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?
>
> A very good argument. I doubt, however, that even those using the
> current File API in the cleanest possible way, will necessarily be
> fit for those future filesystem changes.

True: Java has lots of other built-in limitations that make it
unsuitable or at least uncomfortable for "advanced" (or even "large")
files. I guess the Java answer is "We'll pretend the super-files are
databases and make you go through adapters to get at them ..."

</smiley></rant> Oh, did I forget to open these?

--
Eric Sosman
d

Eric Sosman <> wrote:
> On 11/15/2011 9:17 AM, Andreas Leitgeb wrote:
>> Eric Sosman<> wrote:
>>> On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
>>>> [... concerning VMS ...]
>>>> How recent was your porting activity? (months, years or decades?)
>>> [ Answer: essentially last century ]
>> Do you think, the same management would make
>> that decisions again nowadays for nowadays'
>> marketshare of VMS?
> Would they decide to sell product on one of the most popular
> platforms in their ecosystem?

If it is that, I'd finally be curious about what ecosystem
it is.

>> Sometimes, abstraction also gets into your way: how would you
>> model a relative path that starts with going one or more levels
>> up?

Not sure if your answer was covered by the <smilie>-tag,
or whether my question was indeed unclear.

If in a VMS-shell you're curently in directory
data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n]foo.dir
and wanted to access the file
data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n.bar]xyz.txt
would you need to specify the complete path to xyz.txt, or
is there some syntactic pendant to "../bar/xyz.txt" in VMS?

On 11/16/2011 7:14 AM, Andreas Leitgeb wrote:
>[...]
> If in a VMS-shell you're curently in directory
> data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n]foo.dir
> and wanted to access the file
> data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n.bar]xyz.txt
> would you need to specify the complete path to xyz.txt, or
> is there some syntactic pendant to "../bar/xyz.txt" in VMS?

Sorry; I don't remember. I *do* remember, though that there
is no such thing as being "in" a directory. VMS does not have a
Unix-oid notion of "current working directory," but instead has a
"default file specification." If you hand the system an incomplete
file name, the missing pieces are filled in from the DFS. Thus,
the resolution of incomplete names is a lexical operation, not a
"navigational" operation.

Usually this difference does not obtrude itself upon the user's
consciousness, but there are situations where it becomes important.
For example, the "data" in your example could be a "logical name"
with multiple translations: DISK1:[ANDREAS],DISK2:[READONLY], for
example. You could then tell javac to compile DATA:[.SOURCE]FOO.JAVA
and DATA:[.SOURCE]BAR.JAVA, and javac would happily find your locally-
modified DISK1:[ANDREAS.SOURCE]FOO.JAVA and the still-in-the-repository
DISK2:[READONLY.SOURCE]BAR.JAVA. It's something like the way a Unix
shell follows the PATH variable, except generalized for all files
instead of being limited just to executables.

... but note what this does to the notion of "current directory."
DATA:[.SOURCE]FOO.JAVA and DATA:[.SOURCE]BAR.JAVA have different
parent directories, DISK1:[ANDREAS] and DISK2:[READONLY], respectively.
The idea of being "in" a particular directory may not stand scrutiny.

--
Eric Sosman
d