Java package

Package Definition

A package is a collection of related classes.
It helps Organize your classes into a folder structure and make it easy to locate and use them.
More importantly,It helps improve re-usability.

Syntax:-

package <package_name>;

Package declaration

The first statement, other than comments, in a Java source file, must be the package declaration.
Following the optional package declaration, you can have import statements, which allow you to specify classes from other packages that can be referenced without qualifying them with their package.

Default package. Altho all Java classes are in a directory, it's possible to omit the package declaration. For small programs it's common to omit it, in which case Java creates what it calls a default package. Sun recommends that you do not use default packages.

Example of using package

Example1 : Creating the package:

package p1;
class c1{
       public void m1(){
          System.out.println("Method m1 of Class c1");
   }
  public static void main(String args[]){
     c1 obj = new c1();
     obj.m1();
  }
}

Example 2 : Creating the sub packages:

package p1.p2;
class c2{

    public void m2(){
      System.out.println("Method m2 of Class c2");
    }
    public static void main(String args[]){
      c2 obj = new c2();
      obj.m2();
  }
}

Compiling the above Classes

When a class is placed in a package the class file must be located in a sub-directory under one of the directories listed in the CLASSPATH. The sub-directory structure must map exactly onto the package name.
Given a CLASSPATH=/lib the above class must reside in one of:

./p1 

/lib/p1

Or  in case of example2 :

./p1/p2

or /lib/p1/p2

The javac compiler creates class files in the current directory by default, even if they are specified as belonging to a package. To get around this, use the -d flag to the compiler . Which will create the necessary directories under the /lib directory, if your classpath is /lib.

Take example1, Save the file as Demo.java.
Compile the file as,

javac – d . Demo.java

Run the code as
java p1.c1

Taking example2:
Save the file as Demo2.java.
Compile the file as

javac – d . Demo2.java

Run the code as

java p1.p2.c2

Importing a package

To create an object  of a class (bundled in a package), in your code, you have to use its fully qualified name.
Ex.

java.awt.event.actionListner object = new java.awt.event.actionListner();

But , it could become tedious to type in the long dot-separated package path name for every class you want to use. Instead it is recommended you use the import statement.

Syntax

import <package_name>;

Once imported , you can use the class without mentioning its fully qualified name.

import java.awt.event.*; // * signifies all classes in this package
import javax.swing.JFrame // here only the JFrame class is imported
//Usage
JFrame f = new JFrame; // without fully qualified name.

To import package

// Using packages created in earlier assignment
package p3;
import p1.*; //imports classes only in package p1 and NOT  in the sub-package p2
 
class c3{
  public   void m3(){
     System.out.println("Method m3 of Class c3");
  }
  public static void main(String args[]){
    c1 obj1 = new c1();
    obj1.m1();
    p1.p2.c2 obj2 = new p1.p2.c2();
    obj2.m2();
  }
}

Save the file as Demo2.java . Compile the file using the command
javac –d .Demo2.java

Execute the code using the command
java p3.c3

Packages - points to note:

• To avoid naming conflicts packages are given names of the domain name of the company in reverse Ex :  com.guru99. com.microsoft, com.infosys etc.
• When a package name is not specified , a class is into the default package (the current working directory) and the package itself is given no name. Hence you were able to execute assignments earlier.
• While creating a package, care should be taken that the statement for creating  package must be written before any other import statements
• When importing packages with * format, only classes in that packages are imported and not sub packages.

java.lang.NoClassDefFoundError in java

This is normally a CLASSPATH problem. Try resetting the CLASSPATH, and/or make sure all third party JAR's are actually present in the correct locations. In some rare cases you will get this problem when the JVM has problems loading a third party jar due to version incompatibilities.

To set classpath in java, just see how to reset it. Following links may be useful to read:

• Path and classpath in java
• Determining current value of classpath
• Setting classpath in windows

Subtyping in Generics

Before starting on subtyping in Generics, let's first understand what is covariance.
See - What is covariance, contravariance and invariance?

In Java, as in other object-oriented typed languages, hierarchies of types can be built:

 

In Java, a subtype of a type T is either a type that extends T or a type that implements T (if T is an interface) directly or indirectly. Since "being subtype of" is a transitive relation, if a type A is a subtype of B and B is a subtype of C, then A will be a subtype of C too. In the figure above:

• FujiApple is a subtype of Apple.
• Apple is a subtype of Fruit.
• FujiApple is a subtype of Fruit.

Every Java type will also be subtype of Object.

Every subtype A of a type B may be assigned to a reference of type B:

Apple a = ...;

Fruit f = a;

Subtyping a generic types -  Invariance of Generic types

Parametrized types and Arrays

Subtyping of Generic Types - Parametrized Type Invariance

If a reference of an Apple instance can be assigned to a reference of a Fruit, as seen above, then what's the relation between, let's say, a List<Apple> and a List<Fruit>? Which one is a subtype of which? More generally, if a type A is a subtype of a type B, how does C<A> and C<B> relate themselves?

Surprisingly, the answer is: in no way. In more formal words, the subtyping relation between generic types is invariant.

Eg.

List<Apple> apples = new ArrayList<>();

List<Apple> foulApples = apples; //fine 

Collection<Apple> greenApples = apples; //fine again

However this is not fine:

List<Apple> apples = new ArrayList<>();

List<Fruit> fruits = apples;//Error

and so does the following:

List<Apple> apples;

List<Fruit> fruits = ...;

apples = fruits;

But why? Is an apple is a fruit, a box of apples (a list) is also a box of fruits.

In some sense, it is, but types (classes) encapsulate state and operations. What would happen if a box of apples was a box of fruits?

List<Apple> apples = ...;

List<Fruit> fruits = apples;

fruits.add(new Strawberry());

If it was, we could add other different subtypes of Fruit into the list and this must be forbidden.

The other way round is more intuitive: a box of fruits is not a box of apples, since it may be a box (List) of other kinds (subtypes) of fruits (Fruit), such as Strawberry.


So what if they were covariant?

Please go through the comments to see what is the problem:

List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(122));
List<Object> lo = li; // Problem starts here
Object num = lo.get(0); // Nothing wrong with this
lo.add("Bang!"); // This would be OK through
// lo but what about li

Integer i = li.get(1); // ClassCastException

Advantage of Generics

Pretty much the same way, methods and constructors can be generic if they declare one or more type variables.

public static <T> T getFirst(List<T> list)

This method will accept a reference to a List<T> and will return an object of type T.

Examples

You can take advantage of generics in both your own classes or the generic Java library classes.

Type Safety When Writing...

In the following code snippet, for example, we create an instance List<String> of populate it with some data:

List<String> str = new ArrayList<String>();
str.add("Hello ");
str.add("World.");

If we tried to put some other kind of object into the List<String>, the compiler would raise an error:

str.add(1); // won't compile

... and When Reading

If we pass the List<String> reference around, we're always guaranteed to retrieve a String object from it:

String myString = str.get(0);

Iterating

Many classes in the library, such as Iterator<T>, have been enhanced and made generic. The iterator() method of the interface List<T> now returns an Iterator<T> that can be readily used without casting the objects it returns via its T next() method.


for (Iterator<String> iter = str.iterator(); iter.hasNext();) {
  String s = iter.next();
  System.out.print(s);
}

Using foreach

The for each syntax takes advantage of generics, too. The previous code snippet could be written as:

for (String s: str) {
  System.out.print(s);
}

that is even easier to read and maintain.

Autoboxing and Autounboxing

The autoboxing/autounboxing features of the Java language are automatically used when dealing with generics, as shown in this code snippet:

List<Integer> ints = new ArrayList<Integer>();
ints.add(0);
ints.add(1);
      
int sum = 0;
for (int i : ints) {
  sum += i;
}

Writing Generic interface

A class or an interface is generic if it has one or more type variable. Type variable are delimited by angle brackets and follow the class (or the interface) name:

public interface List<T> extends Collection<T> {

  ...

}

Roughly speaking, type variables act as parameters and provide the information the compiler needs to make its checks.

Many classes in the Java library, such as the entire Collections Framework, were modified to be generic. The List interface we've used in the first code snippet, for example, is now a generic class. In that snippet, box was a reference to a List<Apple> object, an instance of a class implementing the List interface with one type variable: Apple. The type variable is the parameter that the compiler uses when automatically casting the result of the get method to an Apple reference.

In fact, the new generic signature or the get method of the interface List is:

T get(int index);

The method get returns indeed an object of type T, where T is the type variable specified in the List<T> declaration.

The Generics Facility

The generics facility introduced the concept of type variable. A type variable, according to the Java Language Specification, is an unqualified identifier introduced by:

• Generic class declarations.
• Generic interface declarations.
• Generic method declarations and constructors