Why are filenames in Java the same as the public class name? [closed]

In Java, the name of the file should be the same as the name of the public class contained in that file. Why is this a limitation? What purpose does it serve?

Solution 1:

Java had an interesting approach: where giving a programmer a choice can only degrade the programming experience, remove the choice.

They did this in quite a few places. Filenames and packages for sure, but also not allowing multiple public classes in a file (never good), not allowing you to split classes between files (Damn hard to work with!), etc.

I really wish they had gone a few further. There is no reason for public variables: I've never needed one, nor have I ever seen a situation where some smart programmer thought one was needed and was actually right.

I also wouldn't mind seeing method/class size limitations, but this could get sketchy (it could easily be implemented by code checkers, the problem is typically that the companies that need the most help are the ones that don't know they need help and, therefore, don't use tools like code checkers).

This isn't stuff that matters to most small teams, but when your team grows and has multiple sites with consultants from India, China, and various other spots throughout the world, You'll start to appreciate the inflexibility.

In response to setters/getters comment:

Java beans were an abomination created by Borland to hack their GUI up, then retrofitted into Java.

Horrid idea--a distraction from OO programming--Getters and setters A) show too much of your implementation and B) make you think in terms of operating on data from another object rather than asking the other object to execute an operation for you. Bad hack for people who can't yet think in OO.

Getters are needed occasionally but shouldn't be added unless seen to be absolutely unavoidable.

Setters should be avoided at all costs. If you absolutely need to externally modify the state after an object is constructed, try to use the builder pattern and protect your setters from being called after any operation has been executed.

There are obviously exceptions to everything, and many "Getters" are actually critical object business logic, like String.length() which would be required no matter how String was implemented and isn't even implemented by just returning a property--a great case for a "Getter" if you even want to call it that.

Solution 2:

I was about to say, that it is simply a must. But I looked at the JLS, and it is not that strict. From the JLS's perspective, it is left to the compiler to choose whether to set such a restriction or not.

Practically spoken - common compilers do have that restriction, and, as other already explained, it's much easier for the compiler to find a compilation unit or for a classloader to find a class file with such a restriction in place.

Solution 3:

To be more specific, the filename should have the same name as the public class name in that file, which is the way to tell the JVM that this is what the entry point is for you.

Solution 4:

It is just the convention set by Sun, the makers of Java.
The purpose is organization; the reason is so that everyone who codes in Java will have a consistant way of naming files.

Solution 5:

Each public class must be in a file where the FileName matches the ClassName and a package where the Packagename represents the Directory structure, written in the dotted-form (slashes become dots, like com/example/app becomes com.example.app).

This convention is not random. The compiler has to be able to find the source files and the class loader has to be able to find the implementation. Matching package names and classnames makes this really simple and, more important, fast.

This convention does not apply to non-public classes. This is because non-public classes have a very limited visibility and can only be used within the package where they are defined. Thus, in both cases, the compiler and the runtime environment have already located the correct files.