Creating and Using Packages
To make types easier to find and use, to avoid naming conflicts, and to control access, programmers bundle groups of related types into packages.
Definition: A package is a grouping of related types providing access protection and name space management. Note that types refers to classes, interfaces, enumerations, and annotation types. Enumerations and annotation types are special kinds of classes and interfaces, respectively, so types are often referred to in this lesson simply as classes and interfaces.
Definition: A package is a grouping of related types providing access protection and name space management. Note that types refers to classes, interfaces, enumerations, and annotation types. Enumerations and annotation types are special kinds of classes and interfaces, respectively, so types are often referred to in this lesson simply as classes and interfaces.
The types that are part of the Java platform are members of various packages that bundle classes by function: fundamental classes are in java.lang
, classes for reading and writing (input and output) are in java.io
, and so on. You can put your types in packages too.
Suppose you write a group of classes that represent graphic objects, such as circles, rectangles, lines, and points. You also write an interface, Draggable
, that classes implement if they can be dragged with the mouse.
//in the Draggable.java file
public interface Draggable {
...
}
//in the Graphic.java file
public abstract class Graphic {
...
}
//in the Circle.java file
public class Circle extends Graphic
implements Draggable {
. . .
}
//in the Rectangle.java file
public class Rectangle extends Graphic
implements Draggable {
. . .
}
//in the Point.java file
public class Point extends Graphic
implements Draggable {
. . .
}
//in the Line.java file
public class Line extends Graphic
implements Draggable {
. . .
}
You should bundle these classes and the interface in a package for several reasons, including the following:
- You and other programmers can easily determine that these types are related.
- You and other programmers know where to find types that can provide graphics-related functions.
- The names of your types won't conflict with the type names in other packages because the package creates a new namespace.
- You can allow types within the package to have unrestricted access to one another yet still restrict access for types outside the package.
The types that are part of the Java platform are members of various packages that bundle classes by function: fundamental classes are in
java.lang
, classes for reading and writing (input and output) are in java.io
, and so on. You can put your types in packages too.Draggable
, that classes implement if they can be dragged with the mouse.//in the Draggable.java file public interface Draggable { ... } //in the Graphic.java file public abstract class Graphic { ... } //in the Circle.java file public class Circle extends Graphic implements Draggable { . . . } //in the Rectangle.java file public class Rectangle extends Graphic implements Draggable { . . . } //in the Point.java file public class Point extends Graphic implements Draggable { . . . } //in the Line.java file public class Line extends Graphic implements Draggable { . . . }
Creating a Package
To create a package, you choose a name for the package (naming conventions are discussed in the next section) and put a package
statement with that name at the top of every source file that contains the types (classes, interfaces, enumerations, and annotation types) that you want to include in the package.
The package statement (for example, package graphics;
) must be the first line in the source file. There can be only one package statement in each source file, and it applies to all types in the file.
Note: If you put multiple types in a single source file, only one can be public
, and it must have the same name as the source file. For example, you can define public class Circle
in the file Circle.java
, define public interface Draggable
in the file Draggable.java
, define public enum Day
in the fileDay.java
, and so forth.
You can include non-public types in the same file as a public type (this is strongly discouraged, unless the non-public types are small and closely related to the public type), but only the public type will be accessible from outside of the package. All the top-level, non-public types will be package private.
If you put the graphics interface and classes listed in the preceding section in a package called graphics
, you would need six source files, like this:
//in the Draggable.java file
package graphics;
public interface Draggable {
. . .
}
//in the Graphic.java file
package graphics;
public abstract class Graphic {
. . .
}
//in the Circle.java file
package graphics;
public class Circle extends Graphic
implements Draggable {
. . .
}
//in the Rectangle.java file
package graphics;
public class Rectangle extends Graphic
implements Draggable {
. . .
}
//in the Point.java file
package graphics;
public class Point extends Graphic
implements Draggable {
. . .
}
//in the Line.java file
package graphics;
public class Line extends Graphic
implements Draggable {
. . .
}
If you do not use a package
statement, your type ends up in an unnamed package. Generally speaking, an unnamed package is only for small or temporary applications or when you are just beginning the development process. Otherwise, classes and interfaces belong in named packages.
Creating a Package
package
statement with that name at the top of every source file that contains the types (classes, interfaces, enumerations, and annotation types) that you want to include in the package.The package statement (for example,
package graphics;
) must be the first line in the source file. There can be only one package statement in each source file, and it applies to all types in the file.Note: If you put multiple types in a single source file, only one can be
public
, and it must have the same name as the source file. For example, you can define public class Circle
in the file Circle.java
, define public interface Draggable
in the file Draggable.java
, define public enum Day
in the fileDay.java
, and so forth.You can include non-public types in the same file as a public type (this is strongly discouraged, unless the non-public types are small and closely related to the public type), but only the public type will be accessible from outside of the package. All the top-level, non-public types will be package private.
graphics
, you would need six source files, like this://in the Draggable.java file package graphics; public interface Draggable { . . . } //in the Graphic.java file package graphics; public abstract class Graphic { . . . } //in the Circle.java file package graphics; public class Circle extends Graphic implements Draggable { . . . } //in the Rectangle.java file package graphics; public class Rectangle extends Graphic implements Draggable { . . . } //in the Point.java file package graphics; public class Point extends Graphic implements Draggable { . . . } //in the Line.java file package graphics; public class Line extends Graphic implements Draggable { . . . }
package
statement, your type ends up in an unnamed package. Generally speaking, an unnamed package is only for small or temporary applications or when you are just beginning the development process. Otherwise, classes and interfaces belong in named packages.Packages – points to note:
1
2
3
| // not allowed import package p1.*; package p3; |
1
2
3
| //correct syntax package p3; import package p1.*; |
the java.lang package is imported by default for any class that you create in Java. You can study it more in detail here.
The java API is very extensive , contains classes which can perform almost all your programming tasks right from Data Structure Manipulation til Networking. More often than not , you will be using API files in your code. You can see the API documentation here.
Naming a Package
With programmers worldwide writing classes and interfaces using the Java programming language, it is likely that many programmers will use the same name for different types. In fact, the previous example does just that: It defines a
This works well unless two independent programmers use the same name for their packages. What prevents this problem? Convention.
Companies use their reversed Internet domain name to begin their package names—for example,
Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example,
Packages in the Java language itself begin with
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore. For example:
Rectangle
class when there is already a Rectangle
class in the java.awt
package. Still, the compiler allows both classes to have the same name if they are in different packages. The fully qualified name of each Rectangle
class includes the package name. That is, the fully qualified name of the Rectangle
class in the graphics
package isgraphics.Rectangle
, and the fully qualified name of the Rectangle
class in the java.awt
package isjava.awt.Rectangle
.This works well unless two independent programmers use the same name for their packages. What prevents this problem? Convention.
Naming Conventions
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.Companies use their reversed Internet domain name to begin their package names—for example,
com.example.mypackage
for a package named mypackage
created by a programmer at example.com
.Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example,
com.example.region.mypackage
).Packages in the Java language itself begin with
java.
or javax.
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore. For example:
Domain Name | Package Name Prefix |
---|---|
hyphenated-name.example.org | org.example.hyphenated_name |
example.int | int_.example |
123name.example.com | com.example._123name |
No comments:
Post a Comment