Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: CLI Java Glitch

Reply
Thread Tools

Re: CLI Java Glitch

 
 
Joshua Cranmer
Guest
Posts: n/a
 
      06-23-2011
On 6/22/2011 3:29 PM, Tom Anderson wrote:
> Was this in English or German (or something else)? I don't know
> German, but i've been told that case is much more significant in
> German than in English.


A classic bash.org quote:
> Capitalization is the difference between "I helped my uncle Jack off
> a horse" and "I helped my uncle jack off a horse"


--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
 
 
 
Esmond Pitt
Guest
Posts: n/a
 
      06-23-2011
On 22/06/2011 7:49 AM, Tom Anderson wrote:
> when java opens a class file, it ought to check that the name of the file
> it's opened actually has the right case


How? How can it get the name of the file it has just opened?
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      06-23-2011
Esmond Pitt <(E-Mail Removed)> writes:
>On 22/06/2011 7:49 AM, Tom Anderson wrote:
>>when java opens a class file, it ought to check that the name of the file
>>it's opened actually has the right case

>How? How can it get the name of the file it has just opened?


The spelling of an entry can be obtained in an
operating-system dependent manner. For example, under
Microsoft® Windows:

>dir /B abcde

aBcdE

That is, we have learned that the case of the file
known to us as »abcde« is really »aBcdE«. (A Java
implementation might use a system call instead of
»dir /B«.)

It also might help to lock the file to avoid it being
replaced by another file (e.g., as via

del abcde
echo >aBCDe

) during the process.

 
Reply With Quote
 
Esmond Pitt
Guest
Posts: n/a
 
      06-23-2011
On 23/06/2011 12:01 PM, Stefan Ram wrote:
>
> The spelling of an entry can be obtained in an
> operating-system dependent manner. For example, under
> Microsoft® Windows:


That assumes that the file hasn't been renamed between opening and
running 'dir', or the other way around. As a solution to this
non-existent problem it doesn't convince. What would be required, if
anything was a method that turned an fd into a filename. Is there one?
Or are we really expecting the JVM to run external processes or scan
directories every time the JVM opens a .class file? to no purpose when
what it already does addresses the issue entirely?
 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      06-23-2011
On 22/06/11 20:00, Tom Anderson wrote:
> On Wed, 22 Jun 2011, Nigel Wade wrote:
>
>> 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?

>
> To clarify, i meant that it does different things in these three
> situations:
>
> (1) helloworld exists
> (2) HelloWorld, hElLoWoRlD, HelloworlD, or similar exists
> (3) no class case-insensitively called helloworld exists
>
> I think that cases (2) and (3) should do the same thing. Or, as you
> describe 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.

>
> Now, this is where i think i've gone wrong. Back when i used Windows,
> java did *not* do the same thing in cases (2) and (3). For the
> nonexistent file in (3), it would throw a NoClassDefFoundError. But for
> the misnamed file in (2), it would throw something else - a
> ClassFormatError, i think.
>
> It seems that this has been fixed without me noticing, and i failed to
> interpret Gene's original post correctly. If this is the case, then i
> withdraw my complaint entirely!
>
> tom
>


Well, I was testing on Windows 7 with NTFS (that's the only Windows
system I have to hand, I don't normally use Windows). It may well be
different on other version of Windows, or with vFAT.

--
Nigel Wade


 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      06-23-2011
On 22/06/11 20:50, Gene Wirchenko wrote:
> On 22 Jun 2011 19:45:02 GMT, http://www.velocityreviews.com/forums/(E-Mail Removed)-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

 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      06-23-2011
On Thu, 23 Jun 2011 15:23:26 +0100, Nigel Wade <(E-Mail Removed)>
wrote:

>On 22/06/11 20:50, Gene Wirchenko wrote:
>> On 22 Jun 2011 19:45:02 GMT, (E-Mail Removed)-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


I have already posted a solution. It is not anarchy. On a
case-insensitive filesystem:
search for filename
How many?
0: throw not found
1: run it regardless of case
2+: Is one of them a case match?
Yes: run that one
No: throw ambiguous name

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


See above. That would be ambiguous. I had not thought of the
path, but would not mind seeing a slightly longer startup by running
through all of the directories. Run the first exact case match if
there is one. If not, run the first match in a directory. If there
is more than one case-insensitive match in a directory, throw an
error.

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


It is not randomly substituting, just disregarding case.

>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


Boy, do you ever exaggerate to make your case.

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      06-23-2011
On Thu, 23 Jun 2011 11:40:38 +1000, Esmond Pitt
<(E-Mail Removed)> wrote:

>On 22/06/2011 7:49 AM, Tom Anderson wrote:
>> when java opens a class file, it ought to check that the name of the file
>> it's opened actually has the right case

>
>How? How can it get the name of the file it has just opened?


How can it open a file without the filename? Just keep that
name.

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      06-23-2011
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
 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      06-23-2011
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: CLI Java Glitch Jeff Higgins Java 8 07-22-2011 09:50 PM
Re: CLI Java Glitch Tom Anderson Java 2 07-22-2011 09:47 PM
Re: CLI Java Glitch Roedy Green Java 9 07-22-2011 09:45 PM
Re: CLI Java Glitch Jeff Higgins Java 9 06-21-2011 09:45 PM
Re: CLI Java Glitch Stefan Ram Java 2 06-21-2011 07:43 AM



Advertisments