Re: CLI Java Glitch
On Tue, 21 Jun 2011, Peter Duniho wrote:
On 6/21/11 2:49 PM, Tom Anderson wrote:
On Tue, 21 Jun 2011, Esmond Pitt wrote:
On 21/06/2011 8:09 AM, Martin Gregorie wrote:
The Java language system does case-sensitive comparisons between class
names and the files that contain them when checking that a class name
matches the file name that contains it
Nitpicking, but it doesn't really do that, does it. It opens a .class
file of the name the user specified, loads the class(es) it contains,
and tries to find the classname it was looking for among those
classes. It doesn't explicitly compare the filename and the classname.
The operating system gave it HelloWorld.class in response to
'helloworld.class' because that's how the OS file system happened to
work.
The way Java does this at the moment means that 'java helloworld', where
there is no class 'helloworld', does different things on Windows
depending on whether there is a class HelloWorld, hElLoWoRlD,
HelloworlD, etc.
That seems pretty shoddy to me. If you're a case-sensitive program
running on a case-insensitive operating system, i think it falls on you
to pay special attention to case in your dealings with that system:
Speaking of "shoddy", some might consider it "shoddy" to call the
_operating system_ "case-insensitive" when in fact it's the _file
system_ that is case-insensitive.
It would certainly have been better to say file system rather than
operating system, i agree. However, the file system is part of the
operating system. If the operating system's file system is
case-insensitive when dealing with file paths, then the operating system
is case-insensitive when dealing with file paths. I don't think my
phrasing is incorrect.
Where my precision did lapse was in saying "a case-insensitive operating
system" rather than "an operating system which is case-insensitive when
dealing with file paths". You're quite right that this means something
much broader - even when applied to just the file system, where you might
or might not have case sensitivity around device IDs, disk labels, user
names, etc.
when java opens a class file, it ought to check that the name of the
file it's opened actually has the right case, and if it doesn't,
discard it, and act as if it had got a file not found error from the
operating system.
I don't believe that the error comes from the operating system. The
error comes from opening a file that matches (according to the rules of
the file system) the name that was given, which succeeds (i.e. no
error), but then failing to find a correctly-named class in that file.
The error itself comes from Java, not from the operating system nor even
the file system.
Er, yes. I am suggesting that Java *pretend* that it came from the
operating system. That it treat "asked for foo.class, got Foo.class" the
same as "asked for foo.class, it wasn't found".
And frankly, I don't see how Java can do any better than that. Even on
a given OS, the file system itself may or may not be case-insensitive.
The best Java can do is ask the file system to open the file that the
user specified (exactly as the user specified it), and then if that
succeeds to then look for the same-named class.
If the OS has a system call to retrieve the name of a file attached to an
open file descriptor, and that returns the name in the case with which it
was created, then it can easily do better - after opening the file, it
could check that it's really the file it asked for. I believe Windows has
such a call (or calls - it's a bit messy):
http://stackoverflow.com/questions/65170/how-to-get-name-associated-with-open-handle
If the OS doesn't have such a call, then it can still be done, by
determining the directory name of the path, listing that directory, and
looking for a case-sensitive match for the filename. This is rather more
dubious, because it could get slow in very large directories.
tom
--
It is a formal cultural policy to show unreasonable bias towards any
woman who is both attractive and weird.