Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Nigel Wade Newsgroups: comp.lang.java.programmer Subject: Re: CLI Java Glitch Date: Thu, 23 Jun 2011 15:18:57 +0100 Lines: 65 Message-ID: <96h0aiFf86U1@mid.individual.net> References: <4dffe2ea$0$57121$c30e37c6@exi-reader.telstra.net> <96dvubFalpU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net DIBwgSFxNjazZu2vtNximQKPrIoiBNDjViRHvfSSYN34+GWJOk Cancel-Lock: sha1:jrHJOl1rmAmtkmfaSykloLVqLGY= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5575 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