Import only attr.Attributed or attr.*, use the simple name Attributed for
attr.Attributed, and use the full name of lingua.Attributed.•
Do the converse: import lingua.Attributed or lingua.*, use the simple name
Attributed for lingua.Attributed, and use the full name of attr.Attributed.•
Import all of both packagesattr.* and lingua.*and use the fully qualified names
attr.Attributed and lingua.Attributed in your code. (If a type with the same name
exists in two packages imported on demand, you cannot use the simple name of either type.)•
It is an error to import a specific type that exists as a top-level (that is non-nested) type within the current
source file. For example, you can't declare your own Vector class and import java.util.Vector. Nor
can you import the same type name from two different packages using two single type imports. As noted
above, if two types of the same name are implicitly imported on demand, you cannot use the simple type
name but must use the fully qualified name. Use of the simple name would be ambiguous and so result in a
compile-time error.
18.3. Package Access
You have two options when declaring accessibility of top-level classes and interfaces within a package:
package and public. A public class or interface is accessible to code outside that package. Types that are
not public have package scope: They are available to all other code in the same package, but they are
hidden outside the package and even from code in subpackages. Declare as public only those types needed
by programmers using your package, hiding types that are package implementation details. This technique
gives you flexibility when you want to change the implementationprogrammers cannot rely on
implementation types they cannot access, and that leaves you free to change them.
A class member that is not declared public, protected, or private can be used by any code within the
package but is hidden outside the package. In other words, the default access for an identifier is "package"
except for members of interfaces, which are implicitly public.
Fields or methods not declared private in a package are available to all other code in that package. Thus,
classes within the same package are considered "friendly" or "trusted." This allows you to define application
frameworks that are a combination of predefined code and placeholder code that is designed to be overridden
by subclasses of the framework classes. The predefined code can use package access to invoke code intended
for use by the cooperating package classes while making that code inaccessible to any external users of the
package. However, subpackages are not trusted in enclosing packages or vice versa. For example, package
identifiers in package dit are not available to code in package dit.dat, or vice versa.
Every type has therefore three different contracts that it defines:
- The public contract, defining the primary functionality of the type.
- The protected contract, defining the functionality available to subtypes for specialization purposes.
The package contract, defining the functionality available within the package to effect cooperation
between package types.
•
All of these contracts require careful consideration and design.
18.3.1. Accessibility and Overriding Methods
A method can be overridden in a subclass only if the method is accessible in the superclass. If the method is
not accessible in the superclass then the method in the subclass does not override the method in the superclass
even if it has the same signature. When a method is invoked at runtime the system has to consider the
accessibility of the method when deciding which implementation of the method to run.