Java package
A Java package is a technique for organizing Java classes into namespaces similar to the modules of Modula, providing modular programming in Java.[1] Java packages can be stored in compressed files called JAR files, allowing classes to be downloaded faster as groups rather than individually. Programmers also typically use packages to organize classes belonging to the same category or providing similar functionality. A package provides a unique namespace for the types it contains. Classes in the same package can access each other's package-private and protected members.
Overview
In general, a package can contain the following kinds of types. A package allows a developer to group classes (and interfaces) together. These classes will all be related in some way – they might all have to do with a specific application or perform a specific set of tasks. The Java API is a collection of packages – for example, the javax.xml package. The javax.xml package and its subpackages contain classes to handle XML.
Using packages
In a Java source file, the package that this file's class or classes belong to is specified with the package keyword. This keyword is usually the first keyword in the source file.[2] At most one package declaration can appear in a source file.
package java.awt.event;
To use a package's classes inside a Java source file, it is convenient to import the classes from the package with an import declaration. The following declaration
import java.awt.event.*;
imports all classes from the java.awt.event package, while the next declaration
import java.awt.event.ActionEvent;
imports only the ActionEvent class from the package. After either of these import declarations, the ActionEvent class can be referenced using its simple class name:
ActionEvent myEvent = new ActionEvent();
Classes can also be used directly without an import declaration by using the fully qualified name of the class. For example,
java.awt.event.ActionEvent myEvent = new java.awt.event.ActionEvent();
does not require a preceding import declaration.
Note that if you do not use a package declaration, your class ends up in an unnamed package.[3][4] Classes in an unnamed package cannot be imported by classes in any other package.[5]
Package access protection
Public members and classes are visible everywhere and private members are visible only in the same class. Classes within a package can access classes and members declared with default (package-private) access as well as class members declared with the protected access modifier. Default (package-private) access is enforced when a class or member has not been declared as public, protected or private. By contrast, classes in other packages cannot access classes and members declared with default access. However, class members declared as protected can be accessed from the classes in the same package as well as classes in other packages that are subclasses of the declaring class.[6]
Creation of JAR files
JAR files are created with the jar command-line utility. The command
jar cf myPackage.jar *.class
compresses all .class files into the JAR file myPackage.jar. The 'c' option on the command line tells the jar command to "create new archive." The ' f ' option tells it to create a file. The file's name comes next before the contents of the JAR file.
Package naming conventions
Packages are usually defined using a hierarchical naming pattern, with some levels in the hierarchy separated by periods (., pronounced "dot"). Although packages lower in the naming hierarchy are often referred to as "subpackages" of the corresponding packages higher in the hierarchy, there is almost no semantic relationship between packages. The Java Language Specification establishes package naming conventions to avoid the possibility of two published packages having the same name. The naming conventions describe how to create unique package names, so that packages that are widely distributed will have unique namespaces. This allows packages to be separately, easily and automatically installed and catalogued.
In general, a package name begins with the top level domain name of the organization and then the organization's domain and then any subdomains, listed in reverse order. The organization can then choose a specific name for its package. Subsequent components of the package name vary according to an organization's own internal naming conventions.[7]
For example, if an organization in Canada called MySoft creates a package to deal with fractions, naming the package ca.mysoft.fractions distinguishes the fractions package from another similar package created by another company. If a German company named MySoft also creates a fractions package, but names it de.mysoft.fractions, then the classes in these two packages are defined in a unique and separate namespace.
Complete conventions for disambiguating package names and rules for naming packages when the Internet domain name cannot be directly used as a package name are described in section 7.7 of the Java Language Specification.[8]
Core packages in Java SE 6
| java.lang | — basic language functionality and fundamental types |
| java.util | — collection data structure classes |
| java.io | — file operations |
| java.math | — multiprecision arithmetics |
| java.nio | — the Non-blocking I/O framework for Java |
| java.net | — networking operations, sockets, DNS lookups, ... |
| java.security | — key generation, encryption and decryption |
| java.sql | — Java Database Connectivity (JDBC) to access databases |
| java.awt | — basic hierarchy of packages for native GUI components |
| javax.swing | — hierarchy of packages for platform-independent rich GUI components |
| java.applet | — classes for creating an applet |
The java.lang package is available without the use of an import statement.
Modules
In Java 9, "modules", a kind of collection of packages, are planned as part of Project Jigsaw; these were earlier called "superpackages" and originally planned for Java 7.
Modules will describe their dependencies in a module declaration which will be placed in a file named module-info.java at the root of the module’s source-file hierarchy. The JDK will be able to check them both at compile-time and runtime. The JDK itself will be modularized for Java 9.[9]
References
- ↑ James Gosling, Bill Joy, Guy Steele, Gilad Bracha, The Java Language Specification, Third Edition, ISBN 0-321-24678-0, 2005. In the Introduction, it is stated "Chapter 7 describes the structure of a program, which is organized into packages similar to the modules of Modula."
- ↑ "Managing Source and Class Files (From The Java Tutorials > Learning the Java Language > Packages)".
- ↑ articles with dead external links%5d%5d%5b%5bCategory:Articles with dead external links from March 2015%5d%5d "Creating a Package (The Java™ Tutorials > Learning the Java Language > Packages)" Check
|url=value (help). Java.sun.com. 2012-02-28. Retrieved 2013-09-15. - ↑ articles with dead external links%5d%5d%5b%5bCategory:Articles with dead external links from March 2015%5d%5d "Java SE Specifications" Check
|url=value (help). Java.sun.com. Retrieved 2013-09-15. - ↑ "Chapter 7. Packages". Docs.oracle.com. Retrieved 2013-09-15.
- ↑ http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
- ↑ Code Conventions for the Java Programming Language: 9. Naming Conventions
- ↑ http://docs.oracle.com/javase/specs/jls/se6/html/packages.html#7.7
- ↑ "JDK Module Summary". Oracle Corporation. 2015-10-23. Retrieved 2015-11-29.