Packages are naming structures designed to organize classes according to function. Also, they are used to distinguish two classes that have the same name. For example, java.util.Date != java.sql.Date.
To put a class in a package, you simply add the package statement to your class. The class should be located within a directory structure that mirrors your package structure. So for com.me.www, you should have a 'com' and 'me' and 'www' directory on your file system that the class should be located in.
A package is a convenient way to organize groups of related classes, and in development, you should organize your application files into packages too. Packages make it easier to locate and use the class files and help you control access to class data at run time.
Packages help you to add structure and organization to your applications. Whenever you create applications you usually don't have all your code in one file. You'll write a class that uses other classes(objects) among other things to accomplish a task.
Packages enable you to organize your classes so that you can package similar objects together. By putting the "package somePackageName;" at the top of your class source file, you are stating that the class belongs to the somePackageName package.
If you also put the same "package somePackageName;" at the top of another class source file, you are also including that class in the same package as the other one.
Later, in another java program, you can import the somePackageName package and be able to use both of the objects(classes) in your program.
Packages can also include other things like interfaces, which is another discussion.
1. Why packages: Because you and I may both create a class with the same name. For example, Element or Document. Packages give us, and the people who use our classes, a way to distinguish between the classes. When you specify a class using the package name AND the class name, you are said to be using the "fully qualified" class name. As Anthony mentioned, "java.util.Date" is one way to specify the fully qualified name of that particular class, and that is a different class from "java.sql.Date" even though the class names are both "Date".
2. You probably already know how to use classes that are in packages. For example, the Vector class is in the package java.util and you can specify a Vector two ways:
a: put an import statement at the top of the file:
import java.util.Vector; ...
Vector v = new Vector();
b: specify the fully qualified name:
java.util.Vector v = new java.util.Vector();
3. What if you are defining your own class and you want to put it in a package? Then you need to do two things: a: put the package statement as the first line of your code (only comments or blank lines can come before a package statement) b: create a folder structure that mirrors the package statement
For example, if your package is com.josenavarro.coolapp and your class is named MyApp then you would have this folder structure:
com (folder) josenavarro (folder inside com) coolapp (folder inside josenavarro) MyApp.class (compiled java class inside coolapp folder)
If you are using an IDE then it might create the folder structure for you, but if you are using the Java SDK then you need to compile the class and then create the folder structure and put the class in the appropriate place.
4. Once you have created the folder structure you can use the jar utility to create a jar file. This is optional but makes sense if you have lots of classes in your folder structure.
5. You probably noticed that a lot of package names look like www addresses, but backwards. The reason for this is that companies (and people) who create classes want to ensure that their package name is unique (so their classes don't potentially conflict with someone else's) and one way to get a unique package name is to take your registered domain and use it as the start of all your package names.
So if your company domain is mycompany.com and you have some customer projects and some internal projects, you might consider package names such as:
However, there's something that's not working for me :S
If I include no package to a couple .javas I have been working on (first class actually calls the other one), everything compiles normally. However, if I add the packages, I get a compilation error that the second class can't be found (I have compiled it already).
Does the package have to be in the CLASSPATH so that it can work?
See the concept of java classpath is very simple, but if u dont understand that i always creates the problem.
The simple concept of class path is that what ever class u want to use should be in class path. That could be a class file, zip file, jar file, or a folder.
The Folder part is the one of the key parts while development. What you should do is to set the current working folder as classpath and save ur classes/java files in packages in refrence to thi working folder.
Everything will work fine and after some time you will find that the world is so beautiful. [ July 02, 2004: Message edited by: Sandeep Jindal ]
Packages mean different things to different folks - no surprise there.
At one end of the spectrum, you can just use packages as folders for organizing your code in some way that makes it easier for you to navigate. Like, I know where to look for a Swing component because I put them all in the myswingcomponents package.
At the other end, packages can be formal units for build or deployment, maybe at a component or sub-component level. This view is of interest if you shrink-wrap a library for others to use, or manage package dependencies carefully with a goal of having certain stable, abstract packages that never or rarely change.
Robert Martin has put together a set metrics to measure package "goodness". See his "Agile Software Development" book for details. Or see Clarkware.com for a brief, free introduction to the metrics and a tool JDepends that you can use to measure your own code.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi