only one PUBLIC CLASS per source file..... But Why..?
Lets say i have ten java classes and i want all of them to be public. It implies(according to java) that i need to declare each of them in a different source file. But that is so irritating. Why is it so strictly compulsory..? Will it be a problem if i have al my public classes in the same source file..? According to java syntax, YES it is a problem... but what is the logical problem....? ( Is it that just because the java guys wanted the file name to be the same as that of the public class they decided to have just one public class per source file.. I dont think thats the reason...)
Sorry for the lengthy question...
Some one please help....
Ten public classes, ten files. Why is such a bigproblem?Message was edited by: J@A@V@A
Ten public classes, ten files. Why is such a big problem?
> Is it that just because the java guys wanted the file name to be the
> same as that of the public class they decided to have just one public
> class per source file.. I dont think thats the reason...
Looks like it's the reason (although it is not a restriction of the language) :
[url=http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.6]JLS?.6 Top Level Type Declarations[/url]
[...]
When packages are stored in a file system, the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as .java or .jav) if either of the following is true:
- The type is referred to by code in other compilation units of the package in which the type is declared.
- The type is declared public (and therefore is potentially accessible from code in other packages).
This restriction implies that there must be at most one such type per compilation unit. This restriction makes it easy for a compiler for the Java programming language or an implementation of the Java virtual machine to find a named class within a package; for example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory.
yes i agree having ten public classes in ten different files is not such a big deal... but i want to know what is the funda behind having just one public class per source file...
Portability, modularity, readability, memory and so on...
> ( Is it that just
> because the java guys wanted the file name to be the
> same as that of the public class they decided to have
> just one public class per source file.. I dont think
> thats the reason...)
it isn't mandated by the language, but so far most (all?) JVMs and compilers make the restriction, because it makes their job easier. there are a few lengthy threads about this in the forum history. god knows how you'd find them, though
> Portability, modularity, readability, memory and so> on...how are they affected by this?
When you modofy something you recompile just a small class not a 20 public class file. The JVM load in memory only the classes that are needed. It's much easier to read a n lines code that a 20xn line code...
> The JVM load in> memory only the classes that are needed. Ten classes in one file will still be compiled into ten different classes so the VM still only loads the classes that it needs.Kaj
But maybe it needs only nine...
> But maybe it needs only nine...As I said. The VM is reading the class files, and not the source files. The class files are not related to the source files so the VM doesn't care if you had one or ten source files.Kaj
It has in fact an impact on (developer's) memory... where did I put that class?
Supposing i have a project that must use 5 classes: A,B,C,D,E.And in another file F i want to use just A and B. If all A,B,C,D,E are declared in one file the JVM will load the entire file(with all 5).If the classes are in separated files the JVM will only load A,B.
> Is it that just
> because the java guys wanted the file name to be the
> same as that of the public class they decided to have
> just one public class per source file.. I dont think
> thats the reason...)
I think the reason is that when Java was developed the people involved came from a classical shell environment, like say Unix. It also shows very much in how hard a Java installation can be and how hard it is to deploy Java efficiently.
This really is a compiler restriction not a language restriction. A compiler could easily split up a Java source file into any number of .class files. This is for example how inner classes are treated.
But I guess this "one public top-level class (interface or enum) per source file" rule was introduced and then just stuck. It's not likely to change though. For maximum portability among compilers it's best to abide with it.
> Supposing i have a project that must use 5 classes:
> A,B,C,D,E.
>
> And in another file F i want to use just A and B. If
> all A,B,C,D,E are declared in one file the JVM will
> load the entire file(with all 5).
> If the classes are in separated files the JVM will
> only load A,B.
> So...
No you are wrong.
Place A, B,C,D,E in Example.java (don't make the classes public). Compile Example.java and you will get A.class, B.class, C.class, D.class, E.class.
Do you now see that the number of source files isn't related to number of classes? The VM is loading the .class files, and will only load those that are referenced.
Kaj
kajbja at 2007-7-21 20:16:20 >
> But I guess this one public top-level class
> (interface or enum) per source file rule was
> introduced and then just stuck. It's not likely to
> change though.
I actually like the rule since it makes it much easier to navigate when you have 100+ classes. (Hell it's even easier to navigate one public class per source when you have 10 classes)
Kaj
kajbja at 2007-7-21 20:16:20 >
> > But I guess this one public top-level class
> > (interface or enum) per source file rule was
> > introduced and then just stuck. It's not likely to
> > change though.
>
> I actually like the rule since it makes it much
> easier to navigate when you have 100+ classes. (Hell
> it's even easier to navigate one public class per
> source when you have 10 classes)
I don't know. It could be as easy to keep all classes of say a package on the same .class file. Then the IDE could split them up so you got one class in each edit buffer creating the impression they were held separately.
But I've never had a problem with this rule. My only interest in this question is that this rule isn't defined by the language and I think we agree on that.
kajbja at 2007-7-21 20:16:20 >
> I don't know. It could be as easy to keep all classes
> of say a package on the same .class file.
Do you mean source file?
> Then the
> IDE could split them up so you got one class in each
> edit buffer creating the impression they were held
> separately.
But that would require that you use something else than e.g. notepad or vi.
>
> But I've never had a problem with this rule. My only
> interest in this question is that this rule isn't
> defined by the language and I think we agree on that.
Yes we do.
kajbja at 2007-7-21 20:16:20 >
It becames such an automatism for me (declaring each class in it's file) and it's very strange when i think to declare 10 classes in the same file. It look's ugly
> > Then the
> > IDE could split them up so you got one class in each
> > edit buffer creating the impression they were held
> > separately.
>
> But that would require that you use something else
> than e.g. notepad or vi.
Not necessarily. Without this "one class - one file" rule you could keep the whole Java source of say a package in one textfile and conveniently edit it in notepad.
A more advanced IDE could provide a more advanced programmers model detaching the Java language elements from how they're stored on file. Then you could have an option as to how you'd like to export your application source to the filesystem.
It's not a big problem but I think the time now may be right for Java compilers to lift this restriction. I mean you could still impose this restriction on yourself if you want.
> It's not a big problem but I think the time now may
> be right for Java compilers to lift this restriction.
> I mean you could still impose this restriction on
> yourself if you want.
I think that would lead to systems that are hard to maintain. Most beginners would pick up that bad habit. (It would be a bad habit till there are tools that would support what you described above)
kajbja at 2007-7-21 20:16:20 >
The point is, it allows the source for a given class to be found by a compiler or a debugger. For example when you compile a single class the compiler will search for source files for external references that might not have been compiled, or have later modified times than the coresponding class files and compiles them too.
When a debugger halts at a statement it can (given the right source path) find the source of the breakpoint and display it,
> The point is, it allows the source for a given class
> to be found by a compiler or a debugger.
This is the shell command view. Still it's only marginally harder to first build a symbol table of where all language elements belonging to a program are located in the file system (if it's not even done already).
And it's something a Java dedicated IDE does anyway for sure.
> > The point is, it allows the source for a given
> class
> > to be found by a compiler or a debugger.
>
> This is the shell command view. Still it's only
> marginally harder to first build a symbol table of
> where all language elements belonging to a program
> are located in the file system (if it's not even done
> already).
>
> And it's something a Java dedicated IDE does anyway
> for sure.
indeed they do. the way eclipse models your code in-memory is incredibly flexible, could easily cope with multiple public classes per source file, if you switched off the rule that disallowed it. and the code editor can show only part of the source, such as the current method - as you found earlier this year by mistake - getting it to focus on one class at a time would be easy enough
> I think the reason is that when Java was developed
> the people involved came from a classical shell
> environment, like say Unix.
Nope.
C (and Unix) itself came from the same bunch of people from a "classical shell environment" and this restriction does not apply to C (nor to C++).
Whether seen from a "classical shell environment" or clicking, pointing, dragging, dropping all the time, the Java compiler can do its job (including some dependence checks) easier if the source file's path name can be deduced from its package/class name.
> It also shows very much
> in how hard a Java installation can be and how hard
> it is to deploy Java efficiently.
Nope. Compiling stuff is something different from installing or deploying it.
> It becames such an automatism for me (declaring each
> class in it's file) and it's very strange when i
> think to declare 10 classes in the same file. It
> look's ugly
I had to look that up:
any reaction that occurs automatically without conscious thought or reflection (especially the undirected behavior seen in psychomotor epilepsy)
Careful you don't swallow your tongue next time!
> Lets say i have ten java classes and i want all of
> them to be public. It implies(according to java) that
> i need to declare each of them in a different source
> file. But that is so irritating. Why is it so
> strictly compulsory..? Will it be a problem if i
> have al my public classes in the same source file..?
The problem is you'll have to scroll. Very baaad. It is way faster to clic or tab the next editor thumb in your favorite Java source file editor.
