Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Re: CLI Java Glitch

 
 
Martin Gregorie
Guest
Posts: n/a
 
      06-20-2011
On Mon, 20 Jun 2011 14:24:53 -0700, Gene Wirchenko wrote:

> Dear Java'ers:
>
> Given
>
> class HelloWorld
> {
> public static void main(String[] args)
> {
> System.out.println("Hello, world!");
> }
> }
>
> is there any way around the following?
>

Nope: out it down to the non-intuitive ways some OSen handle file names.
There's a big difference between:

(1) an OS that stores a file name as input but does caseless name
comparisons when parsing a request to find a file (Windows from Win95
onwards)

and

(2) one that converts file names to, say, upper case when they're stored
and *then* does caseless comparisons. (DOS, Windows to 3.11)

or

(3) one that stores file names as entered and does case-sensitive
comparisons. (all UNIX family OSen)

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 or when the class-loader is
looking for a classfile, so it will behave as a person used to case 2 or
3 would expect, but you'd better get the case right if you're using a
case 1 OS.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
 
 
 
Esmond Pitt
Guest
Posts: n/a
 
      06-21-2011
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.
 
Reply With Quote
 
 
 
 
Tom Anderson
Guest
Posts: n/a
 
      06-21-2011
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: 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

--
No man ever steps in the same river twice, for it's not the same river
and he's not the same man. -- Heraclitus
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      06-21-2011
On Mon, 20 Jun 2011, Martin Gregorie wrote:

> On Mon, 20 Jun 2011 14:24:53 -0700, Gene Wirchenko wrote:
>
>> Dear Java'ers:
>>
>> Given
>>
>> class HelloWorld
>> {
>> public static void main(String[] args)
>> {
>> System.out.println("Hello, world!");
>> }
>> }
>>
>> is there any way around the following?
>>

> Nope: out it down to the non-intuitive ways some OSen handle file names.
> There's a big difference between:
>
> (1) an OS that stores a file name as input but does caseless name
> comparisons when parsing a request to find a file (Windows from Win95
> onwards)
>
> and
>
> (2) one that converts file names to, say, upper case when they're stored
> and *then* does caseless comparisons. (DOS, Windows to 3.11)
>
> or
>
> (3) one that stores file names as entered and does case-sensitive
> comparisons. (all UNIX family OSen)


Ahem. The UNIX-family MacOS X - possibly only when using HFS+ and FAT,
although i'm not sure - does case-wobbly comparisons. Case is preserved,
but i think it is ignored when paths are looked up. It's been a while
since i worked on OS X, so i forget the details.

tom

--
No man ever steps in the same river twice, for it's not the same river
and he's not the same man. -- Heraclitus
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      06-21-2011
On Tue, 21 Jun 2011 22:49:59 +0100, Tom Anderson
<(E-Mail Removed)> 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
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      06-21-2011
On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
<(E-Mail Removed)> wrote:

[snip]

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


Please do not nitpick.

[snip]

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


Quite so.

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


I do.

Search for the name in the case-insensitive filesystem.
if number of files found=0
throw file not found
else if number of files found=1
run the file found (regardless of case)
else
{
Is one of the filename a match case-sensitively?
if yes
run that matching file
else
throw ambiguous name
}

[snip]

>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


My suggestion would cover that ...

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

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      06-22-2011
Peter Duniho <(E-Mail Removed)> writes:
>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 ).


One could do something like this by wrapping every class file
into a jar file.

 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      06-22-2011
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.


 
Reply With Quote
 
lewbloch
Guest
Posts: n/a
 
      06-22-2011
On Jun 21, 4:37*pm, Gene Wirchenko <(E-Mail Removed)> wrote:
> On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
>
> <(E-Mail Removed)> wrote:
>
> [snip]
>
> >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.

>
> * * *Please do not nitpick.
>


That's not nitpicking, and success in engineering comes from attention
to detail.

It is a meaningful difference, file system vs. OS itself, therefore
not nitpicking. ALso, simply slapping a pejorative label like
"nitpicking" on a proposition doesn't make the proposition false or
even unimportant.

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

> [snip]


--
Lew
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      06-22-2011
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
 
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