Difference between Package and Directory in Java

Question

In a Java Project, does keeping all the .java files in the same folder mean they are in the same package?

What is the difference in making a Package for our project compared to keeping all the project files in one folder?

This thread doesn't really address my question.

Solution 1

There is a relationship between package and directory, but it's one that you must maintain. If you have a class that's in "mypackage1.mypackage2", that means that the java command is going to expect to find it in a directory structure named "mypackage1\mypackage2" (assuming "backwards" Windows notation), with that directory structure further embedded in a directory (let's call it "myjava") whose name is in the classpath (or else is directly in the "current directory").

So your Java class (which internally says package mypackage1.mypackage2;) is in, say, "\Users\myName\myjava\mypackage1\mypackage2\", and you place "\Users\myName\myjava" in the class path, or else you have your current directory set to "\Users\myName\myjava".

If you mix this up, either the class will not be found at all, or you will get an error something like the ever-nebulous "NoClassDefFoundError".

As to why one would use packages (and directories), the reason has to do with "name space" and "separation of concerns" (look those up). Java would be much harder to keep straight if there were no packages and all the "java.lang", "java.io", "sun.misc", et al classes were together. First off, one would have to use name "prefixes" to keep them straight and avoiding name conflicts. And much of the logical grouping would be lost.

With your own projects you don't need to use packages for simple little programs you write for yourself, but if you write something you might give to someone else it's polite to use a package such as "myname.myproject" (substituting your name and project of course), so the person you give it to can combine it with others without name conflicts.

In large applications you'll find using further levels of separation helps you keep the functions straight, so you know where everything is. It also discourages you from "crossing the boundary" between different functional areas, so you don't get unrelated logic entertwined.

Eclipse (if you use that) kind of muddles the issue a bit because it "wants" to provide directory and package names and will sometimes (but not always) keep them in sync.

Solution 2

• Packages provide logical namespace to your classes..

• And these packages are stored in the form of directory levels (they are converted to nested directories) to provide physical grouping (namespace) to your classes..

Also, note that the physical namespace has to be in accordance with the logical namespace.. You can't have your class with package com.demo, under directory structure : - \com\demo\temp\, it has to be under \com\demo\, and this directory is added to the classpath so that your classes is visible to JVM when it runs your code..

Suppose you have following directory structure: -

A
|
+-- Sample.java(contains Demo class under package B)
|
+-- Outer.java(contains Demo class - no package)
|
+--B
|    |
|   +-- Demo.class
|
+--C
|    |
|   +-- Abc.class
|
+-- Demo.class

Suppose, your class Abc.class and Demo.class (under directory A), isn't define under any package, whereas your class Demo.class (under directory B) is defined under package B. So, you need to have two directories in your classpath: - \A(for two classes: - Demo.class and B.Demo.class) and \A\C(for class Abc.class)..

• Classes under different package can use same name. That is why there won't be any conflict between the two Demo.class defined above.. Because they are in different packages. That is the whole point of dividing them into namespaces.. This is beneficial, because you will not run out of unique names for your classes..

Solution 3

Understanding the class loader subsystem is will answer your query.

With reference to Inside JVM by Bill Venners

Given a fully qualified type name, the primordial class loader must in some way attempt to locate a file with the type's simple name plus ".class". Hence, JVM searches a user-defined directory path stored in an environment variable named CLASSPATH. The primordial loader looks in each directory, in the order the directories appear in the CLASSPATH, until it finds a file with the appropriate name: the type's simple name plus ".class". Unless the type is part of the unnamed package, the primordial loader expects the file to be in a subdirectory of one the directories in the CLASSPATH. The path name of the subdirectory is built from the package name of the type. For example, if the primordial class loader is searching for class java.lang.Object, it will look for Object.class in the java\lang subdirectory of each CLASSPATH directory.

Comments

[gigadot]

googling your title gives this link stackoverflow.com/questions/9510932/…

[jaymeht]

i do not understand.kindly clarify.!

[A.H.]

This means, that the question has been asked already and that you should lookup this and similar questions first.

[jaymeht]

i know that, but the answer of the question already asked is not understandable to me.

[Hot Licks]

Yeah, I thought the answers to that other question kinda sucked.

[jaymeht]

So lets say i have a .java file in the folder \java\limbo\ which requires to use a class(another.java file) from other file which is also in the same \java\limbo\ place, at the beginning of both the files i have package limbo; written but when i compile i get a ClassNotFound Error for the fist file which requires the second class in the same folder, how that?

[Hot Licks]

@jtnks -- When compiling you must be set up with a valid class path, just as when running the java command. For your scenario, cd \java and then run javac limbo\MyClass.java. This puts both classes in their proper locations with regard to their package names and the directory structure.

[jaymeht]

Thanks a lot @HotLicks.. its working all fine and now its all packaged nicely too.!!

[Hot Licks]

@Jtnks -- Just wait until you try to put it all into a jar file! You'll revisit this whole issue squared!

[nbro]

I am not sure, but classes within the same packages could live in different directories. Have a look at this article: docs.oracle.com/javase/8/docs/technotes/tools/windows/…. Section: Class Path and Package Names: ...An interesting consequence of the package specification mechanism is that files that are part of the same package can exist in different directories. The package name is the same for each class, but the path to each file might start from a different directory in the class path....

[Hot Licks]

@Xenomorph - Might start from a different directory in the class path. You might have classes for package a.b in dir1, dir2, and dir3 in the class path, but there must be an a\b directory in each of those directories.

[nbro]

@HotLicks So, you are saying that even though we can find classes that belong to the same package in different directories, in each of these different directories, we will always find a subdirectory tree representing our package?

[Hot Licks]

@Xenomorph - That's the general idea. When you look for class x.y.Z, each directory in the class path is searched for x\y\Z.class.