Reputation: 3207
i'm kinda digging in java and I just stopped by using packages. Honestly I think the way it works is stupid, why I write it here is because I'm stupid idiot and it is quite possible that i'm wrong and it has something to it and in that case I want to know about it.
OK, the deal is: Why is there a keyword "package" ?(I know what should it do, i'm questioning the need of it's existence)
As I found out, if you define some class as part of a package, say the name of the package is A, and the class is imported in some other class and you want to compile the class with javac, you have to move the class from package A to a directory of the same name.
Why bother with writing "package" at the beginning of every class if in the end you will need to create a special dir for it? Why is the filesystem by itself not sufficient to group those classes? Why can't it work like #include in C? Javac doesn't produce any binaries anyway so why make it more complex than that? As I see it the keyword package alone does nothing except it makes you write more complex build xmls...
Upvotes: 1
Views: 391
Reputation: 45453
actually, you can put the java files anywhere you want. as long as the file names are fed to
javac file...
they will be compiled, no matter what directory they are in.
when Java was designed in 1995, there's a legitimate concern that the hierarchical file system might not be the only media where java sources are saved on. so java sources must be self-contained and contain package declaration. This concern is modestly justified today in some use cases.
Upvotes: 2
Reputation: 81154
You're not an idiot. The requirement for source and class files to follow a certain directory structure on the file system hasn't been the most popular thing.
One justification for it is that, as you say, Java applications aren't compiled into a binary. As such, at runtime, classes need to be loaded ad-hoc (as they are referenced). You generally do this by supplying a classpath. If we didn't have the rigid directory structure, the class loader would have to look at every single class file to see if it were the right one. Having a consistent structure makes look-ups incredibly efficient.
Now to your question...the other direction. Why if we have that file structure do we need the package statement at the top? The truth is, while we mostly adhere to the file structure, it isn't strictly necessary. You can make a custom classloader that does not expect class files to follow that hierarchal structure (or even be files!), just as you can make a compiler that doesn't require the same rigid structure. Because of this, the class itself must be compiled with a concept of what its fully qualified name is.
If it bothers you, you're probably not taking advantage of the utilities that an IDE would provide. I haven't manually written a package ...
statement in years, my IDE inserts it for me.
Upvotes: 2
Reputation: 24419
Storing Java classes in a filesystem is only one way to go. The Java Language Specification allows for storage in a database as well:
http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.2.2
Upvotes: 5
Reputation: 4793
I think it is helpful to a developer to visually see the
package com.company.module;
at the top of each file. Otherwise the developer would need to look at the folder hierarchy, which is more difficult to visualize.
Upvotes: 4
Reputation: 1083
Packages are normal folders in your source directory. Packages help you distribute your project into smaller chunks which serve different things.
Let's take a small graphical project for adding orders. You could separate your project into 3 packages:
When you maintain your code later, you will easily navigate through the whole process. Packages are necessary when your code grows up to more than 5 classes (if you download some open source project, most of them have hundreds or thousands of files distributed in subfolders).
Upvotes: 0