In Java class names are supposed to be case sensitive, so Java shouldn't have a problem with it. The problem should come from case-insenstive file systems, many linuxes not included.
-
1Why would you want to do something that would make your code not portable? I am also not sure if the resulting *.class files can be put in a JAR safely - does ZIP support file names differing only in case? Won't it just break on some platform? Not to mention that this would break Java naming conventions as they are quite strict about case in class names (every word capitalized). – Sergei Tachenov Jan 29 '11 at 15:52
3 Answers
I tried this on Linux, and I could create different classes with same name but different capitalization and use them. As I have no Windows-machine, I can't test how this would work (or if it works at all) in Windows (or any other OS for that matter), but I would not encourage naming classes like this.

- 15,875
- 5
- 38
- 52
-
1I have just tried it on Linux and then put compiled classes into a JAR and copied it to Windows. Some archive viewers see only one of the class files inside, but JVM runs the application fine. – Sergei Tachenov Jan 29 '11 at 16:17
What are you talking about?
The class name is not derived from the filename but from the contents of the file (i.e. the class name as it appears in the file).
Whether the filesystem or OS treat filenames as case insensitive is irrelevant.

- 489,969
- 99
- 883
- 1,009
-
It is relevant if the class is public because most Java implementation force the file name to be the same as the (only allowed) public class name in it, plus ".java". – Sergei Tachenov Jan 29 '11 at 15:49
-
@Sergey - So, if you name your class `MyClass`, the filename will _have_ to be `MyClass`, regardless of filesystem/OS case sensitivity rules. Yes, it _could_ be `myclass` in a case insensitive system, but then it won't work. – Oded Jan 29 '11 at 15:51
-
@Oded - I think they're getting at what happens if you have both myClass and MyClass with a case-insensitive filesystem -- you wouldn't be able to have both files in the same directory. – Andrew Coleson Jan 29 '11 at 15:58
-
@Andrew - I see. It's bad design in any case, to have classes of the same name with different casing. – Oded Jan 29 '11 at 16:01
-
@Oded - technically the filesystem is included only while resolving the file name (jar entry/ etc), implementing your own classloader allows you to keep the classdata wherever you please – bestsss Jan 29 '11 at 16:07
-
@bestsss - So you agree that filesystem/OS case sensitivity is irrelevant? – Oded Jan 29 '11 at 16:08
-
If a custom classloader is used, it's another story of course. Didn't think of that. – Sergei Tachenov Jan 29 '11 at 16:18
-
@Oded - it's an implementation detail of the compiler at best, iirc java.net.URLClassLoader even allow different cases. While defining classes in the VM the source file is lost (there is Package for security issues) – bestsss Jan 29 '11 at 16:19
-
@Sergey Tachenov: loading from a custom URL (like applet for instance) doesn't mean there are real 'files' on the server. – bestsss Jan 29 '11 at 16:20
You can't by official naming convention. You must name your class using CamelCase, starting with a Uppercase.
In Linux you can do it, but it's a very bad idea. Your resulting code/classes will not be portables.
And you will found problems with source control tools, IDE's, another OSes, some JVMs, etc.
For example: you can use non-english (utf8) characters for your classes. I have seem classes with Spanish names (with characters like ñ, Ñ, á, à, etc). Soon or later it will be a problem, because not every filesystems works with utf8 (some uses ansi-like, ascii, or something else). Very long names can be trouble too. Some filesystems have limits on name length like ISO-9660 filesystems, some FAT versions, etc.
Stay in the safe path :)

- 1,155
- 6
- 16