Unlike C++, in Java, we cannot have just function declarations in the class and definitions outside of the class. Why is it so?
Is it to emphasize that a single file in Java should contain only one class and nothing else?
The difference between C++ and Java is in what the languages consider their smallest unit of linkage.
Because C was designed to coexist with assembly, that unit is the subroutine called by an address. (This is true of other languages that compile to native object files, such as FORTRAN.) In other words, an object file containing a function
C++, despite all of its additional fanciness, works the same way. The compiler shoehorns namespaces, classs and methods/members/etc. into this convention by flattening the contents of classes into single names that are mangled in a way that makes them unique. For example, a method like
Java is a different beast that lives in an insulated world with its own object file format, the
If you haven't figured it out already, all of this safety comes with a tradeoff: anything you link to a Java program has to be Java. (By "link," I mean anytime something in one class file refers to something in another.) You can link (in the native sense) to native code using JNI, but there's an implicit contract that says that if you break the native side, you own both pieces.
Java was big and not particularly fast on the available hardware when it was first introduced, much like Ada had been in the prior decade. Only Jim Gosling can say for sure what his motivations were in making the class Java's smallest unit of linkage, but I'd have to guess that the extra complexity that adding free floaters would have added to the runtime might have been a deal-killer.
I believe the answer is, per Wikipedia, that Java was designed to be simple and object oriented. Functions are meant to operate on the classes they are defined in. With that line of thinking, having functions outside of a class doesn't make sense. I am going to leap to the conclusion that Java doesn't allow it because it didn't fit with pure OOP.
A quick Google search for me didn't yield much on Java language design motivations.
The real question is what would be the merit of continuing to do things the C++ way and what was the original purpose of the header file? The short answer is that the header file style allowed for quicker compile times on large projects in which many classes could potentially reference the same type. This is not necessary in JAVA and .NET due to the nature of the compilers.
See this answer here: Are header files actually good?
A Java file represents a class. If you had a procedure outside the class, what would the scope be? Would it be global? Or would it belong to the class that Java file represents?
Presumably, you put it in that Java file instead of another file for a reason - because it goes with that class more than any other class. If a procedure outside a class was actually associated with that class, then why not force it to go inside that class where it belongs? Java handles this as a static method inside the class.
If an outside-class procedure were allowed, it would presumably have no special access to the class whose file it was declared in, thus limiting it to a utility function that doesn't change any data.
The only possible down-side to this Java limitation is that if you truly have global procedures that are not associated with any class, you end up making a MyGlobals class to hold them, and import that class in all your other files that use those procedures.
In fact, the Java importing mechanism needs this restriction in order to function. With all the API's available, the java compiler needs to know exactly what to compile and what to compile against, thus the explicit import statements at the top of the file. Without having to group your globals into an artificial class, how would you tell the Java compiler to compile your globals and not any and all globals on your classpath? What about namespace collision where you have a doStuff() and someone else has a doStuff()? It would not work. Forcing you to specifiy MyClass.doStuff() and YourClass.doStuff() fixes these issues. Forcing your procedures to go inside MyClass instead of outside it only clarifies this restriction and does not impose additional restrictions on your code.
Java got a number of things wrong - serialization has so many little warts that it is almost too difficult to be useful (think SerialVersionUID). It can also be used to break singletons and other common design patterns. The clone() method on Object should be split into deepClone() and shallowClone() and be type-safe. All the API classes could have been made immutable by default (the way they are in Scala). But the restriction that all procedures must belong to a class is a good one. It serves primarily to simplify and clarify the language and your code without imposing any onerous restrictions.
I think it's an artifact of the class loading mechanism. Each class file is a container for a loadable object. There is no place "outside" of class files.
I think most of the people who answered and their voters have misunderstood the question. It reflects that they don't know C++.
"Definition" and "Declaration" are words with a very specific meaning in C++.
The OP does not mean to change the way Java works. This is a question purely about syntax. I think it is a valid question.
In C++ there are two ways to define a member function.
First way is the Java way. Just put all code inside the braces:
Both programs are the same. The function
Jonathan Henson is right that this is an artifact of the way headers work in C++: it allows you to put declarations in the header file and implementations in a separate .cpp file so your program doesn't violate the ODR (One Definition Rule). But it has merits outside of that: it allows you to see the interface of a large class at a glance.
In Java you can approximate this effect with abstract classes or interfaces, but those cannot have the same name as the implementation class, which makes it rather clumsy.
C#, which is very similar to Java, does have this kind of feature through the use of partial methods, except that partial methods are exclusively private.
Partial Methods: http://msdn.microsoft.com/en-us/library/6b0scde8.aspx
Partial Classes and Methods: http://msdn.microsoft.com/en-us/library/wa80x488.aspx
I don't see any reason why Java couldn't do the same, but it probably just comes down to whether there is a perceived need from the user base to add this feature to the language.
Most code generation tools for C# generate partial classes so that the developer can easily add manually written code to the class in a separate file, if desired.
C++ requires that the entire text of class be compiled as part of every compilation unit which uses any members thereof or produces any instances. The only way to keep compile times sane is to have the text of the class itself contain--to the extent possible--only those things which are actually necessary to its consumers. The fact that C++ methods are often written outside the classes that contain them is a really nasty vile hack motivated by the fact that requiring the compiler to process the text of every class method once for every compilation unit where the class is used would lead to totally insane build times.
In Java, compiled class files contain, among other things, information which is largely equivalent to a C++ .h file. Consumers of the class can extract all the information they need from that file, without having to have the compiler process the .java file. Unlike C++, where the .h file contains information which is made available to both the implementations and clients of the classes contained therein, the flow in Java is reversed: the file the clients use isn't a source file used in the compilation of the class code, but is instead produced by the compiler using information the class code file. Because there is no need to divide class code between a file containing information clients need and a file containing implementation, Java doesn't allow for such a split.
I think part of it is that Java is very much a protectionist language that concerns itself with usage on large teams. Classes can't be overwritten or redefined. You have 4 levels of access modifiers that define very specifically how methods can and can't be used. Everything is strong/statically typed to protect devs from type mismatch hijinx caused by others or themselves. Having classes and functions as your smallest units makes it a lot easier to reinvent the paradigm of how to go about architecting an app.
At the end of the day though, they're both popular general use languages so there is a bit of a philosophical argument there. My biggest personal beef with Java and C# is that I've never seen or worked with a legacy codebase where the majority of the devs seemed to have understood the value of basic OOP. When you come into the game having to wrap everything in a class, perhaps it's just easier to assume you're doing OOP rather than function spaghetti disguised as massive chains of 3-5 line classes.