Name: bsC130419			Date: 07/10/2001


java version "1.3.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_02)
Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode)



As more Java classes are implemented by various vendors, the probability that
the same class name is reused is very high. When this is the case, the java
language requires (i.e. forces) you to specify each class with its fully
qualified name.

For instance, if a class uses both java.lang.Object and org.omg.CORBA.Object
then it has use the fully-qualified names to prevent ambiguity.

  From a usability point, typing package and class name every time is very tedious
and error prone. Furthermore, if the name of a package changes, then a lot of
changes have to be made to the class where fully-qualified names are used.

In light of the above problems, I propose the use of 'aliases' - short
substitutes for long package names.

E.g.:

////////////////////////////////////
// before: file Abc.java

import org.omg.CORBA.*;

public class Abc {
   org.omg.CORBA.Object a;
   java.lang.Object b;
}

//////////////////////////////////////////
// after using aliases: file Abc.java

// alias 'corba' is a shortcut for 'org.omg.CORBA' (* is not included in alias)
import corba=org.omg.CORBA.*;
import jlang=java.lang.*;

public class Abc {
   corba.Object a; // much shorter and readable class names than before
   jlang.Object b;
}

/////////////

Detailed rules for aliases are:
1. Aliases may not have dots ('.'). This is because long names for aliases are
contrary to their purpose and to make aliases easier to distinguish from package
names.

2. Alias names are visible only in classes where they are defined.

3. Aliases can also be defined without using 'import' (in cases where using * in
 import is undesirable).

// Abc.java
alias corba=org.omg.CORBA;  // we don't want to use the import x.y.* syntax
alias jlang=java.lang;

public class Abc {
   corba.Object a;
   jlang.Object b;
}


4. Where aliases are not used to specify class names, the normal rules of import
apply.

// Abc.java
import corba=org.omg.CORBA.*;
import jlang=java.lang.*;

public class Abc {
   corba.Object a;
   jlang.Object b;
   Integer c;     // compiler picks java.lang.Integer using default rules
   Request req;   // compiler uses the 1st import to pick org.omg.CORBA.Request
}


5. 'import' statements *can't* use aliases to import specific classes.
There is not much benefit here to deviate from the regular java constructs.

According to this rule,

import java.util.List;
import java.util.Map;

*cannot* be replaced by:

alias jutil=java.util;
import jutil.List;
import jutil.Map;


6. Aliases are pure syntactic sugar and hence are not retrievable by any
introspection API . Aliases also don't affect the class file format (all trace
of aliases in the source files disappear in the compiled .class files).
(Review ID: 127751) 
======================================================================