CLI Java Glitch
Gene Wirchenko
Given
class HelloWorld
{
public static void main(String[] args)
{
System.out.println("Hello, world!");
}
}
is there any way around the following?
C:\cbs2dev\test>java helloworld
Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
(wrong nam
e: HelloWorld)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: helloworld. Program will exit.
C:\cbs2dev\test>java HelloWorld
Hello, world!
Most commands in a Windows system are case-insensitive so any are
liable to be typed that way.
I find it weird that it does apparently know the correct name and
includes it in the error message.
Sincerely,
Gene Wirchenko
Joshua Cranmer
> Most commands in a Windows system are case-insensitive so any are
> liable to be typed that way.
>
> I find it weird that it does apparently know the correct name and
> includes it in the error message.
Java classes are case-sensitive; the argument to java is not a file to
run but a class whose main method should be called. It is roughly
equivalent to arguing that, since Windows is case-insensitive, `echo Hi'
and `echo hi' should both print out the same thing.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Arved Sandstrom
The commands might be, but the arguments often are not. "HelloWorld" is
an argument.
> I find it weird that it does apparently know the correct name and
> includes it in the error message.
It'll help you out if a class can be found that is, say, wrong only in
case. If you were to try "helloworld2", for example, it wouldn't
nominate "HelloWorld". It doesn't actually "know" the correct name,
obviously, but it can make a brainless stab at it to help you out.
AHS
Martin Gregorie
> 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 |
Jeff Higgins
> Dear Java'ers:
>
> Given
>
> class HelloWorld
> {
> public static void main(String[] args)
> {
> System.out.println("Hello, world!");
> }
> }
>
> is there any way around the following?
>
> C:\cbs2dev\test>java helloworld
maybe a wrapper script
Lew Bloch
That would not help in this case. Think about the problem and you
will see why.
OK, I'll tell you why. Wrapper scripts don't help in the face of
egregious error.
Perhaps you should be specific with your suggestion. "Maybe a wrapper
script" is about as useful as advice as "maybe a program to help
you". Could you elucidate precisely what sort of "wrapper script" you
have in mind, and precisely how you believe it would help, and
precisely how that would ameliorate egregious error?
--
Lew
Jeff Higgins
What error?
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>C:\cbs2dev\test>java helloworld
>Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
>(wrong nam
see http://mindprod.com/jgloss/helloworld.html
Java is case sensitive. Case matters.
--
Roedy Green Canadian Mind Products
http://mindprod.com
One of the great annoyances in programming derives from the irregularity
of English spelling especially when you have international teams.
I want to find a method or variable, but I don't know precisely
how its is spelled or worded. English is only approximately phonetic.
Letters are randomly doubled. The dictionary often lists variant spellings.
British, Canadian and American spellings differ.I would like to see an
experiment where variable names were spelled in a simplified English, where
there were no double letters.I also think you could add a number of rules
about composing variable names so that a variable name for something would
be highly predictable. You would also need automated enforcement of the
rules as well as possible.
Patricia Shanahan
I can see a couple of ways a script could help:
1. Create a helloworld.bat script (I'm assuming, given the wish to
ignore case, that this is MS-Windows specific) that runs the java
command with the correct spelling of the class name. Users who run the
script could ignore case.
2. Create a general script, javaignorecase.bat, that takes the same
parameters as the java command. It would scan the class path for
classes. If it found one that matches its class name argument ignoring
case, it would run the java command substituting the actual class name
for its class name argument and passing through the rest of the
arguments unchanged.
Personally, I don't like things that ignore case, but that is a far from
universal view.
Patricia
Esmond Pitt
>
> 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.
Jeff Higgins
>
> 1. Create a helloworld.bat script (I'm assuming, given the wish to
> ignore case, that this is MS-Windows specific) that runs the java
> command with the correct spelling of the class name. Users who run the
> script could ignore case.
>
> 2. Create a general script, javaignorecase.bat, that takes the same
> parameters as the java command. It would scan the class path for
> classes. If it found one that matches its class name argument ignoring
> case, it would run the java command substituting the actual class name
> for its class name argument and passing through the rest of the
> arguments unchanged.
I was going to call mine javaci, but this may fall into the egrigulous
category, not sure.
Jeff Higgins
> I was going to call mine javaci, but this may fall into the egrigulous
> category, not sure.
Oops, ungrinulous. ;)
Eric Sosman
> On Mon, 20 Jun 2011 14:24:53 -0700, Gene Wirchenko<ge...@ocis.net>
> wrote, quoted or indirectly quoted someone who said :
>
>> C:\cbs2dev\test>java helloworld
>> Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
>> (wrong nam
>
> see http://mindprod.com/jgloss/helloworld.html
>
> Java is case sensitive. Case matters.
Any bets on when we'll see a font-sensitive programming language?
(Actually, I've already seen one, in a very weak sense. It was a
C compiler that completely ignored reverse-video characters in its
input -- and that emitted reverse-video error messages directly into
the source it was compiling. Convenient for one particular use case,
but not what you'd call "scalable" ...)
--
Eric Sosman
eso...@ieee-dot-org.invalid
Lew Bloch
> Lew Bloch wrote:
>> Jeff Higgins wrote:
>>> 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?
>
>>>> C:\cbs2dev\test>java helloworld
>
>>> maybe a wrapper script
>
>> That would not help in this case. Think about the problem and you
>> will see why.
>
>> OK, I'll tell you why. Wrapper scripts don't help in the face of
>> egregious error.
>
>> Perhaps you should be specific with your suggestion. "Maybe a wrapper
>> script" is about as useful as advice as "maybe a program to help
>> you". Could you elucidate precisely what sort of "wrapper script" you
>> have in mind, and precisely how you believe it would help, and
>> precisely how that would ameliorate egregious error?
>
> What error?
>
The error the OP made. Duhh.
Now, how about responding to the request for details instead of
continuing with vague, indirect, fairly unhelpful responses?
--
Lew
Gene Wirchenko
I can see why. I took a couple of courses of COBOL. When
viewing compilation listings, it was very tempting to start
correcting.
I ended up writing a program that converted a compilation listing
back to source. A few people did doubletakes when they saw me editing
the compilation listing. And I did help one fellow student recover
his source when he had accidentally deleted that instead of the
listing.
Sincerely,
Gene Wirchenko
Gene Wirchenko
wrote:
>Gene Wirchenko <ge...@ocis.net> writes:
>>class HelloWorld
>>>java helloworld
>
> Can't you see?
Yes, I can. How about you? Did you miss this line near the end?
C:\cbs2dev\test>java HelloWorld
After all, it was the whole point of my post.
I made the case error precisely once. It is easy to do. I
mainly run my program from within the IDE where I need not type the
classname.
Sincerely,
Gene Wirchenko
Jeff Higgins
I'm sorry, I use Thunderbird and eternal-september
and for some reason I can see that you have replied
but I cannot see the body of your message or reply to it.
I've retrieved some context from Google Groups and
copy/pasted, and will reply to it here.
Jeff Higgins wrote:
> Lew Bloch wrote:
>> Jeff Higgins wrote:
>>> 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?
>>>> C:\cbs2dev\test>java helloworld
>>> maybe a wrapper script
>> That would not help in this case. Think about the problem and you
>> will see why.
>> OK, I'll tell you why. Wrapper scripts don't help in the face of
>> egregious error.
>> Perhaps you should be specific with your suggestion. "Maybe a wrapper
>> script" is about as useful as advice as "maybe a program to help
>> you". Could you elucidate precisely what sort of "wrapper script" you
>> have in mind, and precisely how you believe it would help, and
>> precisely how that would ameliorate egregious error?
> What error?
The error the OP made. Duhh.
Now, how about responding to the request for details instead of
continuing with vague, indirect, fairly unhelpful responses?
No, thanks. I'll await a request from the OP for clarification.
Paul Cager
> Any bets on when we'll see a font-sensitive programming language?
Wasn't Algol-68 font-sensitive? I seem to remember that reserved words
were required by the language spec to be *bold*. Of course you
couldn't do bold on punched cards so compilers had conventions such as
using single quotes in place of boldened text.
Silvio
Yes, the language spec used bold for keywords. The implementation we
used on an IBM370 used upper-case instead.
Lew Bloch
> Lew wrote:
>> Now, how about responding to the request for details instead of
>> continuing with vague, indirect, fairly unhelpful responses?
>
> No, thanks. I'll await a request from the OP for clarification.
>
It'll be interesting to see how the OP can clarify your point, but all
right. I'll grab some popcorn and a beer; this should be fun.
--
Lew
Jeff Higgins
I'll grab some popcorn and a beer; this should be fun.
Roedy Green
someone who said :
> Any bets on when we'll see a font-sensitive programming language?
Regexes would be a heck of a lot simpler if the expressions were font
or colour sensitive. You would use one colour for data and one for
commands. Instead of \n you would type that see echoed some sort of
single-width newline glyph.
Gavino
news:2e1f5478-2fe1-412e...@e21g2000vbz.googlegroups.com...
>Wasn't Algol-68 font-sensitive? I seem to remember that reserved words
>were required by the language spec to be *bold*. Of course you
>couldn't do bold on punched cards so compilers had conventions such as
>using single quotes in place of boldened text.
That's right. In the Algol 68 jargon, the different conventions were known
as "stropping regimes".
http://en.wikipedia.org/wiki/Algol68#Program_representation
Gene Wirchenko
<see_w...@mindprod.com.invalid> wrote:
>On Mon, 20 Jun 2011 20:44:04 -0400, Eric Sosman
><eso...@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
>someone who said :
>
>> Any bets on when we'll see a font-sensitive programming language?
>
>Regexes would be a heck of a lot simpler if the expressions were font
>or colour sensitive. You would use one colour for data and one for
>commands. Instead of \n you would type that see echoed some sort of
>single-width newline glyph.
Huh? Which is the data, and which is the commands? It is all
characters to be parsed.
Sincerely,
Gene Wirchenko
BGB
presumably, the editor would insert some sort of markup or annotations,
and the compiler would parse these.
the issue though would be to avoid being overly slowed down by the types
of user-interface design issues which plague traditional HTML WYSIWYG
editors...
hmm... source code as HTML, and using Mozilla/SeaMonkey Composer as the
text editor...
imagine the fun...
Tom Anderson
> Dear Java'ers:
>
> Given
>
> class HelloWorld
> {
> public static void main(String[] args)
> {
> System.out.println("Hello, world!");
> }
> }
>
> is there any way around the following?
>
> C:\cbs2dev\test>java helloworld
> Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
> (wrong nam
> e: HelloWorld)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(Unknown Source)
> at java.lang.ClassLoader.defineClass(Unknown Source)
> at java.security.SecureClassLoader.defineClass(Unknown Source)
> at java.net.URLClassLoader.defineClass(Unknown Source)
> at java.net.URLClassLoader.access$000(Unknown Source)
> at java.net.URLClassLoader$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> Could not find the main class: helloworld. Program will exit.
Yes:
http://fedoraproject.org/get-fedora
I'm serious. Your operating system is broken. Get one that isn't.
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
Tom Anderson
Gregarious?
Gene Wirchenko
<tw...@urchin.earth.li> wrote:
[snip]
>Yes:
>
>http://fedoraproject.org/get-fedora
>
>I'm serious. Your operating system is broken. Get one that isn't.
I do not nuke mosquitos. If I switched operating systems every
time that something did not work quite as I wanted, I would waste a
lot of time.
Sincerely,
Gene Wirchenko
Tom Anderson
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 Anderson
> 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.
Peter Duniho
> 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.
And even Unix variants can often be found using case-insensitive file
systems, just as Windows can often be found using case-sensitive file
systems (though probably less frequently than the case-insensitive/Unix
scenario, since the Windows ecosystem is generally more homogeneous).
> 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.
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.
Short of making Java a case-insensitive language (which seems
impractical at this point, whether or not anyone might have thought that
a good idea from the outset), I don't see how Java could improve on the
situation. 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.
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 :) ).
Pete
Gene Wirchenko
<tw...@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
Gene Wirchenko
<NpOeS...@NnOwSlPiAnMk.com> 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
Peter Duniho
> On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
> <NpOeS...@NnOwSlPiAnMk.com> 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.
I have been known to nitpick, but making a distinction between operating
system and file system is far from that.
> [...]
> Search for the name in the case-insensitive filesystem.
You've already got a problem right there, since it's not really up to
Java to decide whether it's dealing with a case-sensitive file system or
not. It shouldn't care.
> if number of files found=0
> throw file not found
> else if number of files found=1
> run the file found (regardless of case)
And you've got a problem there too: the name provided by the user is a
_Java_ name, and the language _is_ case-sensitive. It's an
implementation error for Java to behave in a case-insensitive way.
> else
> {
> Is one of the filename a match case-sensitively?
> if yes
> run that matching file
> else
> throw ambiguous name
> }
See above.
Jeff Higgins
> Dear Java'ers:
>
> Given
>
> class HelloWorld
> {
> public static void main(String[] args)
> {
> System.out.println("Hello, world!");
> }
> }
>
> is there any way around the following?
>
> Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
> (wrong nam
> e: HelloWorld)
It seems so far the consensus for a "way around" is
some variation on the theme of "wrapper script".
Nigel Wade
> 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.
Arved Sandstrom
happy to leave things as is.
Joe Average Computer User doesn't normally open up a terminal or a
command prompt and run Java commands. So this is really a discussion
about making a simple thing easier for _techie_ types. I don't think it
warrants the effort, and in some ways it introduces problems where none
existed before. Simplify the issue for some programmers on some systems;
complicate it for other programmers on other systems. I don't agree.
AHS
Jeff Higgins
I read the OP as wanting to make a simple thing easier for_Gene
Wirchenko_. Others seem to be addressing a request to "fix" the java
executable. Maybe Lew is right; we must be precise, precise, precise!
lewbloch
> On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
>
>
> [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
Joshua Cranmer
> 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
Gene Wirchenko
<lewb...@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
Gene Wirchenko
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
Gene Wirchenko
<je...@invalid.invalid> wrote:
[snip]
>I read the OP as wanting to make a simple thing easier for_Gene
>Wirchenko_. Others seem to be addressing a request to "fix" the java
>executable. Maybe Lew is right; we must be precise, precise, precise!
Of course I want to make it easier for myself! That is why most
of use who use computers use computers.
Look at it this way. If Java were being spec'ed right now, would
you have an objection to what I propose? Why not make it easier?
Sincerely,
Gene Wirchenko
Joshua Cranmer
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.
Patricia Shanahan
...
> 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
Tom Anderson
> 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.
Gene Wirchenko
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
Jeff Higgins
> On Wed, 22 Jun 2011 08:02:25 -0400, Jeff Higgins
> <je...@invalid.invalid> wrote:
>
> [snip]
>
>> I read the OP as wanting to make a simple thing easier for_Gene
>> Wirchenko_. Others seem to be addressing a request to "fix" the java
>> executable. Maybe Lew is right; we must be precise, precise, precise!
>
> Of course I want to make it easier for myself! That is why most
> of use who use computers use computers.
That is why I proposed a personal solution.
> Look at it this way. If Java were being spec'ed right now,
The behavior under discussion has been specified and is implemented and
can now only be re-specified and implemented.
> would you have an objection to what I propose?
Yes because it would break a lot of others stuff.
Why not make it easier?
Back to the personal solution.
Tom Anderson
> 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!
Gene Wirchenko
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
Gene Wirchenko
<je...@invalid.invalid> wrote:
>On 06/22/2011 01:18 PM, Gene Wirchenko wrote:
[snip]
>> Look at it this way. If Java were being spec'ed right now,
>
>The behavior under discussion has been specified and is implemented and
>can now only be re-specified and implemented.
>
>> would you have an objection to what I propose?
>
>Yes because it would break a lot of others stuff.
What stuff?
"If Java were being spec'ed right now", then nothing would get
broken.
[snip]
Sincerely,
Gene Wirchenko
Paul Cager
> On Wed, 22 Jun 2011 11:06:38 -0700, Patricia Shanahan <p...@acm.org>
> wrote:
> >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.
My preference is to retain the current situation where the 'java'
command consistently rejects a wrong classname. I prefer consistent
behaviour over the ability to type the class name without pressing the
shift key (in most cases).
Your preference, I believe, is the opposite.
I don't think either of us should present our personal preference as
being "more helpful to more users" without being reasonably certain
that we speak for the majority of users.
Arved Sandstrom
If I were spec'ing Java right now, I'd be muckling onto some C# ideas as
far as packaging and structure go: folder and file names don't have to
match namespace names or class names, and partial class/interface
definitions (and partial methods for that matter) are available.
AHS
Tom Anderson
> The word �Cuban� means �related to Cuba�,
> while �cuban� means �related to cubes�.
I don't believe it does - i've never heard that word before - but i will
certainly use it to mean that in future.
> When I made a case-related mistake in a dictation exercise
> in school, the teacher marked that as an error and gave me a
> worse grade, which in turn helped me to learn the language.
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.
tom
--
drink beer and forget about gods. -- derslangerman
Joshua Cranmer
> 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"
Esmond Pitt
> 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?
Esmond Pitt
>
> 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?
Nigel Wade
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
Nigel Wade
> On 22 Jun 2011 19:45:02 GMT, r...@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
Gene Wirchenko
wrote:
>On 22/06/11 20:50, Gene Wirchenko wrote:
>> On 22 Jun 2011 19:45:02 GMT, r...@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
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
Gene Wirchenko
How can it open a file without the filename? Just keep that
name.
Sincerely,
Gene Wirchenko
Michael Wojcik
> 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
Michael Wojcik
>
> 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.
Gene Wirchenko
<mwo...@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
Tom Anderson
> 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!
Tom Anderson
> Tom Anderson <tw...@urchin.earth.li> writes:
>>> The word �Cuban� means �related to Cuba�,
>>> while �cuban� means �related to cubes�.
>> I don't believe it does - i've never heard that word before - but i will
>> certainly use it to mean that in future.
>
> http://mathworld.wolfram.com/CubanPrime.html
> http://en.wikipedia.org/wiki/Cuban_prime
>
> http://en.wikipedia.org/wiki/Cuban_hip_hop
> http://en.wikipedia.org/wiki/Cuban_Revolution
I'm aware of the use of Cuban to mean 'pertaining to Cuba'. I was not
previously aware of the use of the word 'cuban' in relation to certain
primes related to cubic numbers - interesting! However, i am still not
aware of any *other* uses of cuban in connection with cubes, and i suspect
the name is a humorous idiosyncracy of this Cunningham chap who defined
them. I had a look for the paper where he did so, but i can't even find a
citation, let alone a copy. In normal use, you use 'cubic' as the
adjective for cubes; i think mathematicians and laymen alike would correct
you if you said 'cuban'.
> http://en.wikipedia.org/wiki/Capitonym
In English, we do capitalise proper nouns, it's true. The examples in that
list that aren't proper nouns are highly dubious.
>>> When I made a case-related mistake in a dictation exercise in school,
>>> the teacher marked that as an error and gave me a worse grade, which
>>> in turn helped me to learn the language.
>>
>> Was this in English or German (or something else)?
>
> in German.
>
>> I don't know German, but i've been told that case is much more
>> significant in German than in English.
>
> There are more words beginning with an uppercase letter (I
> am thinking of nouns, which always begin with an uppercase
> letter), so one can find more examples of minimal pairs.
>
> OTOH, �I� is written in uppercase in English, while the
> corresponding German word is not.
Oh, that's just a modern typesetting fad. It's not intrinsically
uppercase.
Esmond Pitt
Misses the point completely. The point at issue is whether the name in
the file system matches the name that you opened.
Esmond Pitt
> Oh, that's just a modern typesetting fad. It's not intrinsically uppercase.
This statement doesn't really mean anything. *All* uppercase is a
'typesetting fad'; nothing is intrinsically uppercase. Or lowercase.
Peter Duniho
> 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
Michael Wojcik
>
> Look at it this way. If Java were being spec'ed right now, would
> you have an objection to what I propose? Why not make it easier?
Yes, because it misunderstands the nature of what the java executable
is doing in that use case (as I noted in another message, which I
believe was posted after you wrote the one I'm quoting here, so you
won't have seen it).
When you run "java foo", you are asking the java executable to create
a JVM instance, load a class named "foo", instantiate it, find its
"main" method, and execute it.
As it happens, on most OSes, when the java executable is asked to load
a class and is not given any other information about where that class
resides, it searches a configurable list of filesystem locations for a
file with the same name as the class, plus the extension ".class". It
is conceivable that in environments where this doesn't make sense, a
java executable, or its equivalent, could do something else to load
the named class.
You are *not* telling the java executable to open the file "foo.class"
and muck about in it, trying to find some class with a main method to
execute.
Your proposal sets the cart before the horse.
Michael Wojcik
> 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.
lewbloch
> Stefan Ram wrote:
>> 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.
>
Spouting aphorisms is not rebuttal.
--
Lew
lewbloch
> 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
lewbloch
> Was this in English or German (or something else)? I don't know German,
> English.
>
Case matters in English, too. Perhaps you think it doesn't matter in
English so much because you flout it.
--
Lew
Gene Wirchenko
>> � � �Correlation is not causation.
I was not rebutting. I was stating that your statement did not
prove your point.
C might be successful in spite of it being case-sensitive. Or
that might be a total disconnect from its success.
Sincerely,
Gene Wirchenko
Bent C Dalager
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 - b...@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Tom Anderson
YOU KNOW YOURE QUITE RIGHT THIS MAKES MY LIFE SUBSTANTIALLY EASIER THANKS
ONCE AGAIN MR PITT
TOM
--
space, robots, pirates, vikings, ninjas, medieval castles, dinosaurs,
cities, suburbia, holiday locations, wild west, the Arctic, airports,
boats, racing cars, trains, Star Wars, Harry Potter, Spider-Man, Batman,
SpongeBob SquarePants, Avatar: The Last Airbender and more
Gene Wirchenko
<b...@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
Gene Wirchenko
<tw...@urchin.earth.li> wrote:
>On Fri, 24 Jun 2011, Esmond Pitt wrote:
>
>> On 24/06/2011 8:20 AM, Tom Anderson wrote:
>>> Oh, that's just a modern typesetting fad. It's not intrinsically uppercase.
>>
>> This statement doesn't really mean anything. *All* uppercase is a
>> 'typesetting fad'; nothing is intrinsically uppercase. Or lowercase.
>
>YOU KNOW YOURE QUITE RIGHT THIS MAKES MY LIFE SUBSTANTIALLY EASIER THANKS
>ONCE AGAIN MR PITT
EVENBEFORETHENTHEREWERENOSPACESBETWEENWORDS
Sincerely,
Gene Wirchenko
Arne Vajhøj
> On 6/21/11 4:37 PM, Gene Wirchenko wrote:
>> On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
>> <NpOeS...@NnOwSlPiAnMk.com> 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.
>
> I have been known to nitpick, but making a distinction between operating
> system and file system is far from that.
That is true.
But it is not correct in the sense of being complete that it is the
file system that is case insensitive.
It is the file system and the command interpreter (shell in
*nix terminology).
Not all command are actual executables.
Arne
Peter Duniho
> [...]
>> I have been known to nitpick, but making a distinction between operating
>> system and file system is far from that.
>
> That is true.
>
> But it is not correct in the sense of being complete that it is the
> file system that is case insensitive.
>
> It is the file system and the command interpreter (shell in
> *nix terminology).
Huh? Inasmuch as the file system can be accessed, and case-sensitivity
observed, without a command interpreter, I don't see why you are
dragging the command interpreter into it.
There are lots of other things on a computer besides the file system
that might or might not be case-sensitive, and you may even have trouble
working with a case-sensitive file system if those things are not. But
I don't see how that's relevant here, where it's the case-sensitivity of
the file system that is at issue.
Pete
Arne Vajhøj
The topic is the original posters expectation of case insensitivity
of commands because of the OS (Windows) being case insensitive.
That has a lot to with the command interpreter.
Arne
Arne Vajhøj
> 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?
>
> 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.
The argument is a class name not a file name.
And even on Windows you can have helloworld, HelloWorld and hELLOwORLD.
Classpath is not restricted to current directory.
You can have each of the above class files in different directories
or jar files.
>> 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 Java cannot do this. On a case-insensitve OS/filesystem it simply
> may not be possible for a file to exist called HelloWorld.class.
It does not need to.
OpenVMS with an ODS-2 disk system has all uppercase file names.
You write:
java "HelloWorld"
and Java find 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>".
Yes.
> 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.
Yes.
Arne
Arne Vajhøj
> While I am at it, I find the Java error for not finding a program
> to be rather verbose for little use.
It very specifically tell what the problem is.
The exception is very useful.
The gotcha is that understanding the exception requires some
knowledge about Java classes, classpath, classloaders, interaction
with file system etc..
It is not beginner friendly.
In two years you will consider the exception text very logical.
Arne
Arne Vajhøj
> 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.
Actually it did in your case. The java command on Windows
do lookup files case insensitive.
But you get an error if the Java byte code in the file does
not contain the class name you specified.
And Java class name are case sensitive on all platforms.
Arne
Arne Vajhøj
> 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.
C/C++, Java, C# : case sensitive
PHP : mix of case sensitive and case insensitive
VB.NET : case insensitive
3.5 out of 5 in my book.
Arne
Arne Vajhøj
> On 6/20/2011 7:55 PM, Roedy Green wrote:
>> On Mon, 20 Jun 2011 14:24:53 -0700, Gene Wirchenko<ge...@ocis.net>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> C:\cbs2dev\test>java helloworld
>>> Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
>>> (wrong nam
>>
>> see http://mindprod.com/jgloss/helloworld.html
>>
>> Java is case sensitive. Case matters.
>
> Any bets on when we'll see a font-sensitive programming language?
It will not happen as long as source code is expected to be
Unicode or earlier text.
Arne
Arne Vajhøj
> On Mon, 20 Jun 2011, 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?
>>
>> C:\cbs2dev\test>java helloworld
>> Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
>> (wrong nam
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClassCond(Unknown Source)
>> at java.lang.ClassLoader.defineClass(Unknown Source)
>> at java.security.SecureClassLoader.defineClass(Unknown Source)
>> at java.net.URLClassLoader.defineClass(Unknown Source)
>> at java.net.URLClassLoader.access$000(Unknown Source)
>> at java.net.URLClassLoader$1.run(Unknown Source)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.URLClassLoader.findClass(Unknown Source)
>> at java.lang.ClassLoader.loadClass(Unknown Source)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>> at java.lang.ClassLoader.loadClass(Unknown Source)
>> Could not find the main class: helloworld. Program will exit.
>
> Yes:
>
> http://fedoraproject.org/get-fedora
He would get a different exception, but still an exception, so ...
Arne
Arne Vajhøj
> If I were spec'ing Java right now, I'd be muckling onto some C# ideas as
> far as packaging and structure go: folder and file names don't have to
> match namespace names or class names, and partial class/interface
> definitions (and partial methods for that matter) are available.
The Java package structure source code structure dependency can be a bit
cumbersome to work with, but it does what I assume it was created for.
You can always find the source code (within the project). With the
free style you have to cross your fingers that the developer actually
followed a reasonable practice.
Partial classes are great for generated code. But there are not
much tradition in the Java world for having IDE's generate code
based on WYSIWYG.
Arne
Peter Duniho
> The topic is the original posters expectation of case insensitivity
> of commands because of the OS (Windows) being case insensitive.
>
> That has a lot to with the command interpreter.
Since a different command interpreter, or a complete lack of one, would
not have changed the behavior the OP was complaining about, I really
don't see how.
But if you want to keep talking about the command interpreter, please
feel free to do so. Fine by me.
Arne Vajhøj
> On 7/22/11 2:19 PM, Arne Vajhøj wrote:
>> The topic is the original posters expectation of case insensitivity
>> of commands because of the OS (Windows) being case insensitive.
>>
>> That has a lot to with the command interpreter.
>
> Since a different command interpreter, or a complete lack of one, would
> not have changed the behavior the OP was complaining about, I really
> don't see how.
It has lot to do with peoples expectations.
And the problem was not in the file system either, so why did you bring
that up when you have that view on what is relevant?
Arne
Peter Duniho
> [...]
> that up when you have that view on what is relevant?
I didn't "bring it up". I was simply responding to the claim that the
OS was case-insensitive (which it's not).
Inasmuch as there's a "problem" at all, I'd say it's "in the file
system". That is, the file system is not using the same rules as Java
to identify the object. Of course, it's not really a problem. It's
just the way it is. But the file system is at least involved in the issue.
In any case, I'm sure you'd be happy to go back and forth all day on the
topic, but I've explained myself as much as I care to. I don't see why
you felt a need to comment on my post, especially a full month after it
was made, but if you think there's still more to be said, please feel
free to carry on without me.
Pete
Arne Vajhøj
> On 7/22/11 8:17 PM, Arne Vajhøj wrote:
>> [...]
>> And the problem was not in the file system either, so why did you bring
>> that up when you have that view on what is relevant?
>
> I didn't "bring it up". I was simply responding to the claim that the OS
> was case-insensitive (which it's not).
That was not very good. It is some part of the OS that er
case insensitive.
But claiming that it is the file system is just as bad. Because
there are other parts that are also case insensitive.
> Inasmuch as there's a "problem" at all, I'd say it's "in the file
> system". That is, the file system is not using the same rules as Java to
> identify the object. Of course, it's not really a problem. It's just the
> way it is. But the file system is at least involved in the issue.
No file system will fix the problem.
Different file systems just result in different exceptions.
I am pretty sure that OP would not have been much happier with
the other exception.
> In any case, I'm sure you'd be happy to go back and forth all day on the
> topic, but I've explained myself as much as I care to. I don't see why
> you felt a need to comment on my post, especially a full month after it
> was made, but if you think there's still more to be said, please feel
> free to carry on without me.
It could be the same reason that you commented on the OS being
case-insensitive.
It was simply totally misleading.
And since neither Java nor CMD nor Win32 NTFS changed during
that month, then that should not be a reason not to comment.
Arne
lewbloch
Truth should neither go out of fashion nor have a statute of
limitations. Not only the systems you mention, but Usenet haven't
gone away. Usenet posts are permanent, and old for far, far longer
than they're new. Some future reader will benefit from both your
comments for far, far longer than a month from now. If there are
facts to add, it's never too late.
So you go right on ahead and comment whenever you deem it relevant.
--
Lew