Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #5436 > unrolled thread

CLI Java Glitch

Back to article view | Back to comp.lang.java.programmer

Contents

  CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-20 14:24 -0700
    Re: CLI Java Glitch Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-20 14:48 -0700
    Re: CLI Java Glitch Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-20 18:49 -0300
    Re: CLI Java Glitch Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-20 22:09 +0000
      Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-21 10:16 +1000
        Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-21 22:49 +0100
          Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-21 15:11 -0700
            Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-21 16:37 -0700
              Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-21 17:54 -0700
                Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 20:58 -0400
                  Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-21 18:14 -0700
                    Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:19 -0400
                      Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-22 19:45 -0700
                        Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 23:17 -0400
                          Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-22 20:25 -0700
                            Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 23:38 -0400
                              Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-07-23 09:09 -0700
                    Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-07-22 18:41 +1000
                      Re: CLI Java Glitch Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-25 11:25 +0000
              Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-06-22 09:02 -0700
                Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 10:12 -0700
                  Re: CLI Java Glitch Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-22 10:39 -0700
            Re: CLI Java Glitch Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-22 09:50 -0700
            Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-22 19:44 +0100
              Re: CLI Java Glitch Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 12:31 -0400
                Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-23 23:04 +0100
                  Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-23 21:40 -0700
                  Re: CLI Java Glitch Michael Wojcik <mwojcik@newsguy.com> - 2011-06-24 09:43 -0400
            Re: CLI Java Glitch Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 12:24 -0400
              Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-23 14:32 -0700
              Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-06-24 09:12 -0700
                Re: CLI Java Glitch Bent C Dalager <bcd@pvv.ntnu.no> - 2011-06-24 22:49 +0000
                  Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-26 20:29 -0700
          Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-21 16:29 -0700
          Re: CLI Java Glitch Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-06-22 11:54 +0100
            Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 10:16 -0700
              Re: CLI Java Glitch Patricia Shanahan <pats@acm.org> - 2011-06-22 11:06 -0700
                Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 11:46 -0700
                  Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 12:50 -0700
                    Re: CLI Java Glitch Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-06-23 15:23 +0100
                      Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-23 08:58 -0700
                    Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-06-24 08:58 -0700
                      Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-24 11:36 -0700
                  Re: CLI Java Glitch Paul Cager <paul.cager@googlemail.com> - 2011-06-22 14:45 -0700
                  Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-22 23:29 +0100
                    Re: CLI Java Glitch Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-22 18:08 -0700
                    Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-23 23:20 +0100
                      Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-24 10:28 +1000
                        Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-25 22:58 +0100
                          Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-26 20:31 -0700
                    Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-06-24 09:00 -0700
                  Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:33 -0400
                  Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:38 -0400
                  Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:41 -0400
            Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-22 20:00 +0100
              Re: CLI Java Glitch Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-06-23 15:18 +0100
            Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:29 -0400
          Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-23 11:40 +1000
            Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-23 20:21 +1000
            Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-23 09:00 -0700
              Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-24 10:24 +1000
      Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-21 22:52 +0100
    Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 19:11 -0400
      Re: CLI Java Glitch Lew Bloch <lewisbloch@google.com> - 2011-06-20 16:25 -0700
        Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 19:45 -0400
          Re: CLI Java Glitch Lew Bloch <lewisbloch@google.com> - 2011-06-20 18:28 -0700
          Ping: Lew Bloch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 23:26 -0400
            Re: Ping: Lew Bloch Lew Bloch <lewisbloch@google.com> - 2011-06-21 10:25 -0700
              Re: Ping: Lew Bloch Jeff Higgins <jeff@invalid.invalid> - 2011-06-21 14:36 -0400
        Re: CLI Java Glitch Patricia Shanahan <pats@acm.org> - 2011-06-20 17:02 -0700
          Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 20:37 -0400
            Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 20:44 -0400
              Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-21 22:45 +0100
    Re: CLI Java Glitch Roedy Green <see_website@mindprod.com.invalid> - 2011-06-20 16:55 -0700
      Re: CLI Java Glitch Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-20 20:44 -0400
        Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-20 19:26 -0700
        Re: CLI Java Glitch Paul Cager <paul.cager@googlemail.com> - 2011-06-21 02:34 -0700
          Re: CLI Java Glitch Silvio <silvio@moc.com> - 2011-06-21 16:50 +0200
          Re: CLI Java Glitch "Gavino" <invalid@invalid.invalid> - 2011-06-21 21:35 +0200
        Re: CLI Java Glitch Roedy Green <see_website@mindprod.com.invalid> - 2011-06-21 11:59 -0700
          Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-21 13:03 -0700
            Re: CLI Java Glitch BGB <cr88192@hotmail.com> - 2011-06-21 14:21 -0700
        Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:45 -0400
    Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-20 19:29 -0700
    Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-21 22:42 +0100
      Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-21 14:48 -0700
      Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:47 -0400
    Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-21 21:52 -0400
      Re: CLI Java Glitch Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-22 07:56 -0300
        Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-22 08:02 -0400
          Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 10:18 -0700
            Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-22 15:01 -0400
              Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 12:54 -0700
            Re: CLI Java Glitch Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-22 18:52 -0300
              Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:50 -0400
            Re: CLI Java Glitch Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 15:13 -0400

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#5528

On Wed, 22 Jun 2011 09:02:25 -0700 (PDT), lewbloch
<lewbloch@gmail.com> wrote:

[snip]

>If you're going to call this "nitpicking", you need to support the
>evaluation with evidence and reasoning.  Unfortunately, the point is
>both valid and important, so you won't be able to support calling it
>"nitpicking".

     Sure, I can.  It was quite clear what was being referred to.  The
pedanticism was unnecessary; there was no real danger of confusion.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5531

On 6/22/2011 10:12 AM, Gene Wirchenko wrote:
> On Wed, 22 Jun 2011 09:02:25 -0700 (PDT), lewbloch
> <lewbloch@gmail.com>  wrote:
>> If you're going to call this "nitpicking", you need to support the
>> evaluation with evidence and reasoning.  Unfortunately, the point is
>> both valid and important, so you won't be able to support calling it
>> "nitpicking".
>
>       Sure, I can.  It was quite clear what was being referred to.  The
> pedanticism was unnecessary; there was no real danger of confusion.

Not really. The operating system performs a lot of actions that deal 
with strings. If the operating system itself were case insensitive, 
there would be no distinction between `a' and `A' pretty much anywhere 
in the entire stack. Instead, the only limitation here is that the 
filesystem will happily return a file named `A.txt' when you asked for 
`a.txt'. If you really want to get pedantic, note that the filesystem 
knows the difference between `A.txt' and `a.txt' (i.e., it can preserve 
case). It just chooses to treat them as equivalent for the purposes of 
stat'ing the file.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#5526

On 6/21/2011 3:11 PM, Peter Duniho wrote:
> If Java is deficient in any way here, I'd say it's the inability to
> specify the .class file name separately from the name of the class
> itself, specifically because of the potential for this mis-match of
> casing rules. But even that seems a stretch to me, especially since
> offering that option could encourage people naming their .class files
> something completely different than the class contained within
> (something I'd rather not see as a general practice :) ).

You can do that, if you write your own custom class loader.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#5533

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.

[toc] | [prev] | [next] | [standalone]

#5586

Tom Anderson wrote:
> 
> 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.

Often it isn't. Many OSes support multiple file systems. Some are
case-sensitive, some -insensitive.

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

Only true if the OS only supports filesystems of one type or the other.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5604

On Thu, 23 Jun 2011, Michael Wojcik wrote:

> Tom Anderson wrote:
>
>> 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.
>
> Often it isn't. Many OSes support multiple file systems. Some are 
> case-sensitive, some -insensitive.

And all are part of an 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.
>
> Only true if the OS only supports filesystems of one type or the other.

It might be case-insensitive at some times, and not at others (of for some 
paths - or some parts of some paths - and not others). You could say the 
same about a filesystem. It's still correct to speak of the 
case-sensitivity of an operating system when dealing with file paths.

tom

-- 
Yulava? Niob Yam!

[toc] | [prev] | [next] | [standalone]

#5627

On 6/23/11 3:04 PM, Tom Anderson wrote:
> On Thu, 23 Jun 2011, Michael Wojcik wrote:
>
>> Tom Anderson wrote:
>>
>>> 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.
>>
>> Often it isn't. Many OSes support multiple file systems. Some are
>> case-sensitive, some -insensitive.
>
> And all are part of an operating system!

I guess that depends on your point of view.  It's not worth arguing 
about, but suffice to say there are many of us that do not consider 
third-party OS add-ons, such as installable file systems, to be _part 
of_ the OS.

The OS depends on such things — file systems, video drivers, shell 
extensions, etc. — but they are not part of the OS per se any more than 
an application is part of the OS or your computer.

YMMV.

Pete

[toc] | [prev] | [next] | [standalone]

#5643

Tom Anderson wrote:
> On Thu, 23 Jun 2011, Michael Wojcik wrote:
> 
>> Tom Anderson wrote:
>>
>>> 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.
>>
>> Often it isn't. Many OSes support multiple file systems. Some are
>> case-sensitive, some -insensitive.
> 
> And all are part of an operating system!

There are user-mode filesystems. There are third-party filesystems. If
you want to call them "part of the operating system" I can't stop you,
but in that case it's a pretty vapid statement.

>>> 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.
>>
>> Only true if the OS only supports filesystems of one type or the other.
> 
> It might be case-insensitive at some times, and not at others (of for
> some paths - or some parts of some paths - and not others). You could
> say the same about a filesystem. It's still correct to speak of the
> case-sensitivity of an operating system when dealing with file paths.

Rubbish. It *might* be correct, if that case-sensitivity (or lack
thereof) is imposed by the OS. It needn't be, in which case it would
be incorrect.

A single-application embedded device might have no OS at all, just a
single vertical application that talks directly to the hardware. If
such a device stores data in files - chunks of data in persistent
storage, keyed by name - it could be case-sensitive or -insensitive,
without that being a property of "the OS" (since there wouldn't be any
OS).

An application running under an OS might implement its own filesystem
on top of OS files (what's sometimes called "compound files"). It
could be case-sensitive or -insensitive, and the OS would have no
bearing on that.

An OS could defer all path resolution to plug-in user-mode
filesystems, in which case it would have no influence on the case
sensitivity thereof.

And so on.


-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5587

Peter Duniho wrote:
> For better or worse, Java _is_ case-sensitive, which means
> that it definitely should be just as illegal for the user to specify
> "helloworld" as the class name when starting the program as it is for
> the programmer to specify "helloworld" as the class name when referring
> to it from code.

Agreed. And "case-insensitive" becomes problematic when you move
outside European alphabets, which is another argument against it. (If
I name a class using Japanese katakana characters, should I be able to
invoke it using the corresponding hiragana characters? That would seem
pretty silly - but where do we draw the line?)

> If Java is deficient in any way here, I'd say it's the inability to
> specify the .class file name separately from the name of the class
> itself, specifically because of the potential for this mis-match of
> casing rules.  But even that seems a stretch to me, especially since
> offering that option could encourage people naming their .class files
> something completely different than the class contained within
> (something I'd rather not see as a general practice :) ).

And in effect we already have this with JARs and other cases where the
class isn't loaded from a .class file in the local filesystem. There's
no need for a .jar file to have a name that corresponds to the main
class (and it typically won't). The same applies if I'm using a class
loader that fetches the class from a network resource, or out of a
database, or whatever.

"java foo", without other options, is a special case of invoking the
JVM and asking it to load a class and invoke its "main" method: it's
the case where that class happens to reside in a .class file with the
same name as the class. The "foo" argument is the name of the class,
and the "java" executable is inferring the file name from it. Not the
other way around.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5601

On Thu, 23 Jun 2011 12:24:06 -0400, Michael Wojcik
<mwojcik@newsguy.com> wrote:

>Peter Duniho wrote:
>> For better or worse, Java _is_ case-sensitive, which means
>> that it definitely should be just as illegal for the user to specify
>> "helloworld" as the class name when starting the program as it is for
>> the programmer to specify "helloworld" as the class name when referring
>> to it from code.
>
>Agreed. And "case-insensitive" becomes problematic when you move
>outside European alphabets, which is another argument against it. (If
>I name a class using Japanese katakana characters, should I be able to
>invoke it using the corresponding hiragana characters? That would seem
>pretty silly - but where do we draw the line?)

     Somewhere before the slippery slope?

     Just because it is difficult to implement something 100% does not
mean that there is no benefit to going for the easy, say, 80%.
[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5648

Michael Wojcik wrote:
> Agreed. And "case-insensitive" becomes problematic when you move
> outside European alphabets, which is another argument against it. (If

It's a problem in European languages, too. Should "GrossKopf" and
"GroßKopf" be considered the same class?  If not, to which one should
"GroSSKopf" correspond in a case-insensitive system?

Java sees these as three different identifiers.  How would a case-
insensitive system support a system with classes "GrossKopf",
"GroßKopf" and "GroSSKopf" all in the same package?

--
Lew

[toc] | [prev] | [next] | [standalone]

#5658

The below program creates two distinct files on the file system of my
OSX 10.6.7, one with a regular hyphen and one with the non-breaking
hyphen. Other OS/FS combinations may behave differently. Of course,
the two files look exactly the same. In my opinion this is a lot more
subtle than a case difference and just underscores that string
comparison is a very complicated topic. (This particular sort of
subtelty used to be phishing gold, but I believe browser vendors have
since implemented countermeasures against that.)

I can't offhand think of any characters that are legal in Java symbols
and that might also have similarly subtle issues.


import java.io.File;
import java.io.IOException;

public class TestCase
{
   public static void main(String[] args)
      throws IOException
   {
      File fileHyphen = new File("test-file.tmp");
      File fileNbrkHyphen = new File("test\u2011file.tmp");

      createFile(fileHyphen);
      createFile(fileNbrkHyphen);
   }

   static void createFile(File file)
      throws IOException
   {
      if (!file.createNewFile())
      {
         System.out.println("Could not create " + file);
      }
   }
}


$ javac TestCase.java
$ java TestCase
$ ls test*
test-file.tmp	test‑file.tmp
$ java TestCase
Could not create test-file.tmp
Could not create test?file.tmp

(not sure what I have misconfigured that bollocksed up the Unicode on
that last line)

Cheers,
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs

[toc] | [prev] | [next] | [standalone]

#5697

On Fri, 24 Jun 2011 22:49:40 +0000 (UTC), Bent C Dalager
<bcd@pvv.ntnu.no> wrote:

[snip]

>$ javac TestCase.java
>$ java TestCase
>$ ls test*
>test-file.tmp	test?file.tmp
>$ java TestCase
>Could not create test-file.tmp
>Could not create test?file.tmp
>
>(not sure what I have misconfigured that bollocksed up the Unicode on
>that last line)

     Maybe nothing.  The filename might have been created as you
expected but not display properly.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5498

On Tue, 21 Jun 2011 22:49:59 +0100, Tom Anderson
<twic@urchin.earth.li> wrote:

[snip]

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

     OP here.  Not on my system.

>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: 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.

     But that is about what happened!

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5518

On 21/06/11 22:49, 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.


Does it? What different thing does it do?

As far as a case-insensitive OS/filesystem is concerned, they would all
appear as the same file. If Java asked for any of those names from the
filesystem it would get the one file which did exist for any of the
class names. It would then look in that file for the class it required.
If the class did not exist in that file it would throw the
ClassNotFoundException. It cannot do anything else because the
OS/filesystem simply will not allow it.

Java actually throws ClassNotFoundException in all cases, on all OS,
just as it should. The only difference is that in a case-insensitive
filesystem Java actually opens the case-insensitive filename before it
discovers that it does not contain the class required. On case-sensitive
filesystems the correct case filename won't be found. The actual result
is the same in both cases, a ClassNotFoundException.

> 
> 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: 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.
> 
> tom
> 

But Java cannot do this. On a case-insensitve OS/filesystem it simply
may not be possible for a file to exist called HelloWorld.class.

Java is not doing anything wrong. The user is, in assuming that because
the OS/filesystem is case-insensitive that Java is also. The java
command syntax is "java <ClassName>" not "java <filename>". That class
name is case sensitive, no matter how brain dead the OS or filesystem.
If you ask Java to run the class helloworld when your class is actually
HelloWorld, you have asked it to do the wrong thing. Java is perfectly
correct in telling you this.

If you ask Java to run the class HelloWorld, it does so even on a
case-insensitive system such as that of the OP. Even if the file is
called helloworld.class Java still manages to do the right thing.

[toc] | [prev] | [next] | [standalone]

#5529

On Wed, 22 Jun 2011 11:54:02 +0100, Nigel Wade <nmw-news@ion.le.ac.uk>
wrote:

[snip]

>Java is not doing anything wrong. The user is, in assuming that because

     It is apparently acting per spec, but the spec is overly fussy
(IMO).

>the OS/filesystem is case-insensitive that Java is also. The java
>command syntax is "java <ClassName>" not "java <filename>". That class
>name is case sensitive, no matter how brain dead the OS or filesystem.
>If you ask Java to run the class helloworld when your class is actually
>HelloWorld, you have asked it to do the wrong thing. Java is perfectly
>correct in telling you this.

     And I, as the end user, am perfectly correct in calling this a
quality of implementation issue regarding user-friendliness.

     Being perfectly correct is not good enough when playing with
others who may well have other priorities.  When a program and a user
conflict over interface issues, I think that the user should be the
one to prevail.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5532

On 6/22/2011 10:16 AM, Gene Wirchenko wrote:
...
>       Being perfectly correct is not good enough when playing with
> others who may well have other priorities.  When a program and a user
> conflict over interface issues, I think that the user should be the
> one to prevail.

When dealing with a single-user program that makes sense.

Of course, javac and java are both used by many users. How do you
propose to let "the user" be the one to prevail, when there are
thousands of users with different backgrounds and interface expectations?

I find the case insensitivity of MS-Windows file names very
counter-intuitive. Does that mean MS-Windows should be changed so that
Patricia-as-the-user can prevail?

Patricia

[toc] | [prev] | [next] | [standalone]

#5534

On Wed, 22 Jun 2011 11:06:38 -0700, Patricia Shanahan <pats@acm.org>
wrote:

>On 6/22/2011 10:16 AM, Gene Wirchenko wrote:
>...
>>       Being perfectly correct is not good enough when playing with
>> others who may well have other priorities.  When a program and a user
>> conflict over interface issues, I think that the user should be the
>> one to prevail.
>
>When dealing with a single-user program that makes sense.
>
>Of course, javac and java are both used by many users. How do you
>propose to let "the user" be the one to prevail, when there are
>thousands of users with different backgrounds and interface expectations?

     Easy on this point.  Accepting case-insensitive filenames as
matching when there is no ambiguity is more helpful to more users than
throwing an error is.

     While I am at it, I find the Java error for not finding a program
to be rather verbose for little use.  It does not inform much more
than
          Bad command or filename.
or
         'q' is not recognized as an internal or external command,
         operable program or batch file.
do.

>I find the case insensitivity of MS-Windows file names very
>counter-intuitive. Does that mean MS-Windows should be changed so that
>Patricia-as-the-user can prevail?

     Maybe it should.  But even if I did not agree, I would not argue
against your expectations by calling them wrong.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5541

On 22 Jun 2011 19:45:02 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

[snip]

>  Programmers usually are grateful to get error reports as
>  soon as possible.

     We are even more grateful not to have something flagged as an
error when it is not, or when it need not be.

>  The most successful programming languages today are Java, C
>  and C++, all case-sensitive. There are case-insensitive
>  languages, but they are less successful. Implementations of
>  these successful and popular languages Java, C, and C++
>  actually throw error messages upon case errors.

     Correlation is not causation.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5576

On 22/06/11 20:50, Gene Wirchenko wrote:
> On 22 Jun 2011 19:45:02 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
> wrote:
> 
> [snip]
> 
>>  Programmers usually are grateful to get error reports as
>>  soon as possible.
> 
>      We are even more grateful not to have something flagged as an
> error when it is not, or when it need not be.

But in your original post it is an error. Java is case-sensitive and the
class you asked for does not exist. Therefore it has to be flagged as an
error.

If Java were to start guessing what you might have intended anarchy
would result. What if you wanted to run your class called deletefiles
(which prompts you before deleting any files), but Java wasn't able to
find that because you'd got your classpath wrong, or for some other
reason. But it did find a class called DeleteFiles (a similar class, but
it deletes everything without asking) so ran that for you instead. What
if the class it found had different constructors, or methods, and your
code crashed in strange and wonderful ways? Would you still think that
randomly substituting a class for something which was superficially
similar in name was a good idea?

Sloppy user thinking should not be encouraged. Whilst it may make the
user's life a little easier in some cases, that small benefit is grossly
outweighed when it blows up in their face

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web