Is Java Case Sensitive???? Prove It

[j2vdk]

java is case sensitive means, then y does the below code gets compile time error,,,,[ if any syntax error, dont take it, please see the main concept alone]

class c{
c(){
System.out.println("c");
}
}

class C extends c{
C(){
System.out.println("bc");
}
}

class a{
public static void main(String ar[]){
new C();
}
}

note: here i'm using two classes other than main class, with same letter , but one is small 'c', and other is caps 'C',,, this is case sensitive. the program gets compiled correctly, but y it gets an run time error?????.

please get me an answer as soon as possible,,,,

Thanks for reading it,,,,



y many are viewing the post, but no replying,,,,,,,,,,,,Is my question correct or all u dont know de answr,, no wrong in it, i want to all your suggestion ,,,, express your ideas,,, lets explore these questions... bcoz i too was challenged by this question, so help me,,,,

[serjant]

What error do you get,i ceated three class in three different files,and it compiled and ran without any error and got the output:

Code:

c
bc

[j2vdk]

y creating seperate file for each class,,,,, keep entire code in single notepad,,, i saved it as case.java,,,,,,,
got compiled correctly,,,
if run means,i get this error....




D:\>javac case.java

D:\>java a
Exception in thread "main" java.lang.NoClassDefFoundError: c (wrong name: C)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknow n Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(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)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknow n Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(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)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at a.main(case.java:15)

D:\>

[j2vdk]

thank you replying me, with an answer,,,

but can u tell how can we write each class in seperate file,, an how execute in this case, so tat i can try it,,

[ProjectKaiser]

Funny.

On Windows XP, FAT32, Eclipse it gives compilation time error:
Class file collision: A resource exists with a different case: /server/bin/misc/java_forums/C.class.

On FreeBSD 6.3-STABLE example compiles and runs well.

Code:

> java a
c
bc

I think it is potentially dangerous to give identical case insensitive names to few classes in the same package. Java is somehow system-dependent here, since it puts classes to files and it may come to hell as soon as not all filesystems are case-sensitive.

[ProjectKaiser]

One more note - when I copypaste code to Eclipse it starts to rebuild entire worspace. Wow.

[Norm]

Quote:

"main" java.lang.NoClassDefFoundError: c (wrong name: C)

That looks like an OS that is not case sensitive, like windows.
You can NOT have the files: c.class and C.class in the same folder!

[ProjectKaiser]

Indeed, Norm, you are right. Say it compiles first class "c" then class "C". File c.class gets overrided and oops - class "C" can not be instantiated anymore, since it is inherited from "c".

[Eranga]

Quote:

Originally Posted by ProjectKaiser

Indeed, Norm, you are right. Say it compiles first class "c" then class "C". File c.class gets overrided and oops - class "C" can not be instantiated anymore, since it is inherited from "c".

Yep, this is the correct reason. Simply files are replaced from another. This is not a good choice actually. So in naming conventions, don't use same class names depend on case sensitivity. Avoid all the time.

But one thing I'm not sure, in Linux is this happened. I'll check it later, because I think it wont happen in UNIX systems.

[ProjectKaiser]

Above I gave results from FreeBSD 6.3.
Isn't it UNIX ?

[Eranga]

Hmm, so it's not work at all. Anyway the best thing is avoid same cases in naming.

[j2vdk]

java is platform independent.. right....

then how can u give this answer,,,

[j2vdk]

Quote:

Originally Posted by Norm

That looks like an OS that is not case sensitive, like windows.
You can NOT have the files: c.class and C.class in the same folder!

u said-"tat looks like OS", cant underswtand this ...

if im giving names as c and C then it wont work, are u saying this??


suppose i give names cat & CAT as clas names- i get same error while executing,,,, but gets compiled...



TRY THIS::::: and tell me.... y im asking u is,i was asked this question an cant find the solution....anyway thanx for replying...

class cat{
cat(){
System.out.println("cat");
}
}
class CAT extends cat{
CAT(){
System.out.println("CAT");
}
}
class a{
public static void main(String ar[]){
new CAT();
}
}

[j2vdk]

Quote:

Originally Posted by ProjectKaiser

Funny.

On Windows XP, FAT32, Eclipse it gives compilation time error:
Class file collision: A resource exists with a different case: /server/bin/misc/java_forums/C.class.

On FreeBSD 6.3-STABLE example compiles and runs well.

Code:

> java a
c
bc

I think it is potentially dangerous to give identical case insensitive names to few classes in the same package. Java is somehow system-dependent here, since it puts classes to files and it may come to hell as soon as not all filesystems are case-sensitive.

java is platform independent.. right....

then how can u give this answer,,,

[j2vdk]

Quote:

Originally Posted by Eranga

Yep, this is the correct reason. Simply files are replaced from another. This is not a good choice actually. So in naming conventions, don't use same class names depend on case sensitivity. Avoid all the time.

But one thing I'm not sure, in Linux is this happened. I'll check it later, because I think it wont happen in UNIX systems.

i wont use normally,, but i was questioned like this,,, cant find solution... so please tell the reason for runtime error

[masijade]

Java is case sensitive, but classes will be compiled and each one stored as a file. If the OS, then, is not case sensitive when it comes to the file system, then, if the classes are in the same package (therefore in the same directory), it will not work, because during compilation one class (whichever of the two is compiled last) will overwrite the other.

[masijade]

Quote:

Originally Posted by j2vdk

java is platform independent.. right....

then how can u give this answer,,,

Java is "platform independent". I.E., code written on one machine, will run on every other machine for which a JVM (a java installation) exists. There are some limitations, however.

The above can be one of them. If, however, the files were compiled on an OS that is case sensitive and packed into a jarfile, that jarfile can then be used on an OS that is not case sensitive, because the Classes will be contained within the jarfile and, therefore, not contingent on the OS filesystems case sensitivity.

Another limitation is the use of Runtime.exec() or ProcessBuilder. If you use those, there is a 99.9999999999999% chance that the code is not platform independent. This can be gotten around, somewhat, by placing the commands to use in properties files (or something to that effect) and having one for each OS, as long as you are displaying the output of the commands, or executing a function. If the program tries to evaluate what the command produces, then much more work would need to be done to accomplish any kind of platform independence for that sort of thing. (A plugin architecture for that portion, maybe.)

[masijade]

Quote:

Originally Posted by Eranga

Hmm, so it's not work at all. Anyway the best thing is avoid same cases in naming.

He said the following:

Quote:

On FreeBSD 6.3-STABLE example compiles and runs well.

[j2vdk]

Quote:

Originally Posted by masijade

Java is case sensitive, but classes will be compiled and each one stored as a file. If the OS, then, is not case sensitive when it comes to the file system, then, if the classes are in the same package (therefore in the same directory), it will not work, because during compilation one class (whichever of the two is compiled last) will overwrite the other.

dont misunderstand me- one doubt----

im writing this program in single notepad, named case.java,,,, if i compile it i get single .class file, ie. case.class file,,,,

so only one .class file present,,,, how c.class and C.class will overwrite thennn
thanx for replying,,,,

[masijade]

Quote:

Originally Posted by j2vdk

dont misunderstand me- one doubt----

im writing this program in single notepad, named case.java,,,, if i compile it i get single .class file, ie. case.class file,,,,

so only one .class file present,,,, how c.class and C.class will overwrite thennn
thanx for replying,,,,

I already answered this for you in your other thread.

You have three class definitions (not classes) in a single java (i.e. source code) file. When this file is compiled, each of the compiled classes created from those class definitions, as they are compiled, will be placed into their own class (i.e. byte code/compiled/binary/however you want to refer to them) file. Therefore, one java source code file and three compiled binary class files.