Re: Relationship between filename and classname
Prasoon wrote:
Hi I am new to java.I [sic] want to know is there any specific reason for
the class-name in java [sic] being same as the file-name????
I know that we can save the file with a different name than the class-
name except when the class is public....but during execution we have
to give the name of the class......
But why in most of the cases file-name is same as class-name.????
Is there any specific reason for the same or just the designers of
java said so that's why????
As others have pointed out, it is a convention, albeit a nearly
universal one.
The reason for the convention is organizational convenience. Because
directory structure parallels package structure and class names match
file names, it's easier to keep track of packages and classes on a
file system than if they didn't match.
Package.class: com.lewscanon.foo.Foo
directory/file: com/lewscanon/foo/Foo.class
Note that directories are relative to the class path, that is, to one
entry in the classpath. Thus if I were to execute (on Linux/
Solaris/...):
java -classpath /opt/projects:/usr/jcode:. com.lewscanon.foo.Foo
then the class would be in the first one found of the locations:
/opt/projects/com/lewscanon/foo/Foo.class
/usr/jcode/com/lewscanon/foo/Foo.class
./com/lewscanon/foo/Foo.class
The source code tree would have a cognate structure, with Foo.java
instead of Foo.class.
/home/lew/projects/foo/src/com/lewscanon/foo/Foo.java
The Javadocs for Class#getResource() and getResourceAsStream() touch
on this.
The rule of thumb is that a dot (.) in the package is a slash (/) in
the path.
Other relevant conventions are that packages have names in all lower
case, and class names start with an upper-case letter and have mixed
(camel) case, the first letter of each compound word part being
capitalized and the rest lower case.
Bear in mind that packages are not hierarchical. Packages are
namespaces, and there is no inherent connection between packages with
common name parts. That is, package com.lewscanon.foo.bar is not
inherently related to package com.lewscanon.foo except
psychologically.
--
Lew