Professional Documents
Culture Documents
Contents
• Overview
• Examples
• How the Java Compiler Finds Files
• The CLASSPATH environment variable
Overview
• Every class is part of some package.
• All classes in a file are part of the same package.
• You can specify the package using a package declaration:
package name ;
as the first (non-comment) line in the file.
• Multiple files can specify the same package name.
• If no package is specified, the classes in the file go into a special unnamed package (the
same unnamed package for all files).
• If package name is specified, the file must be in a subdirectory called name (i.e., the
directory name must match the package name).
• You can access public classes in another (named) package using:
package-name.class-name
You can access the public fields and methods of such classes using:
package-name.class-name.field-or-method-name
You can avoid having to include the package-name using:
import package-name.*;
or
import package-name.class-name;
at the beginning of the file (after the package declaration). The former imports all of the
classes in the package, and the second imports just the named class. You must still use:
class-name
to access the classes in the packages, and
class-name.field-or-method-name
to access the fields and methods of the class; the only thing you can leave off is the
package name.
Examples
Assume that you are working in a directory called Javadir, and that you create four files, whose
contents are shown below.
file 1
package ListPkg;
public class List { ... }
class ListNode {...}
file 2
package ListPkg;
public class NoNextItemException { ... }
file 3
public class Test { ... }
class Utils { ... }
file 4
class Test2 { ... }
Here are the directories and file names you must use:
• File 1 must be in a subdirectory named ListPkg, in a file named List.java.
• File 2 must also be in the ListPkg subdirectory, in a file named
NoNextItemException.java.
• File 3 must be in a file named Test.java (in the Javadir directory).
• File 4 can be in any .java file (in the Javadir directory).
And here are the classes that can be accessed by the code in each file:
• Files 1 and 2:
○ The code in the first two files (ListPkg/List.java and
ListPkg/NoNextItemException.java) can access the classes defined in the same
package (List, ListNode, and NoNextItemException). (No access was specified
for those classes, so they get the default, package access.)
○ The code in files 1 and 2 cannot access class Test, even though it is a public class.
The problem is that Test is in an unnamed package, so the code in the ListPkg
package has no way to import that package, or to name class Test.
○ The code in files 1 and 2 cannot access classes Utils and Test2, because they have
default (package) access, and are in a different package.
• Files 3 and 4:
○ The code in file 3 (Test.java) can access classes ListPkg.List,
ListPkg.NoNextItemException, Test, Utils, and Test2 (the first two because they
are public classes in a named package, and the last three because they are in the
same, unnamed package, and have either public or package access). Note
however, that if the code in Test.java uses the class Test2, and that class is not in a
file called Test2.java, then the file that contains class Test2 must be compiled
first, or else the class will not be found.
○ The code in file 4 (the file that contains class Test2) can access the same classes
as the code in file 3 (Test.java).
Here's a summary of the example:
File Contents Directory/FileName Can Access
package ListPkg;
public class List
List, ListNode,
{...} ListPkg/List.java
class ListNode NoNextItemException
{...}
package ListPkg;
public class List, ListNode,
ListPkg/NoNextItemException.java
NoNextItemException NoNextItemException
{...}
public class Test ListPkg.List,
{...} Test.java ListPkg.NoNextItemException,
class Utils {...} Test, Utils, Test2
ListPkg.List,
class Test2 {...} any-name.java ListPkg.NoNextItemException,
Test, Utils, Test2
java.util
java.util.AbstractCollection<E>
java.util.AbstractList<E>
java.util.Vector
All Implemented Interfaces:
Cloneable, List, Serializable, RandomAccess, Collection
Direct Known Subclasses:
Stack, LinkVector, DConnector
The {@code Vector} class implements a growable array of objects. Like an array, it
contains components that can be accessed using an integer index. However, the
size of a {@code Vector} can grow or shrink as needed to accommodate adding
and removing items after the {@code Vector} has been created.
Each vector tries to optimize storage management by maintaining a {@code capacity} and a
{@code capacityIncrement}. The {@code capacity} is always at least as large as the vector size;
it is usually larger because as components are added to the vector, the vector's storage increases
in chunks the size of {@code capacityIncrement}. An application can increase the capacity of a
vector before inserting a large number of components; this reduces the amount of incremental
reallocation.
The iterators returned by this class's iterator and listIterator methods are fail-fast: if the vector is
structurally modified at any time after the iterator is created, in any way except through the
iterator's own remove or add methods, the iterator will throw a
ConcurrentModificationException . Thus, in the face of concurrent modification, the iterator fails
quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined
time in the future. The Enumerations returned by the elements method are not fail-fast.
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking,
impossible to make any hard guarantees in the presence of unsynchronized concurrent
modification. Fail-fast iterators throw {@code ConcurrentModificationException} on a best-
effort basis. Therefore, it would be wrong to write a program that depended on this exception for
its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
As of the Java 2 platform v1.2, this class was retrofitted to implement the List interface, making
it a member of the Java Collections Framework. Unlike the new collection implementations,
{@code Vector} is synchronized.
Also see:
Collection
List
ArrayList
LinkedList
since: JDK1.0 -
final Vector.ListI
An optimized version of AbstractList.ListItr
class tr
Field Summary
protected elementData The array buffer into which the components of
Object[] the vector are stored. The capacity of the vector
is the length of this array buffer, and is at least
large enough to contain all the vector's
elements.
Any array elements following the last element in the
Vector are null.
serial:
protected int capacityIncre The amount by which the capacity of the vector
ment is automatically incremented when its size
becomes greater than its capacity. If the
capacity increment is less than or equal to zero,
the capacity of the vector is doubled each time
it needs to grow.
serial:
modCount
Constructor:
public Vector()
{
this(10);
}
Constructs an empty vector so that its internal data array has size {@code
10} and its standard capacity increment is zero.
Parameters:
Parameters:
since: 1.2 -
Parameters:
This method is identical in functionality to the add(E) method (which is part of the List
interface).
This method is identical in functionality to the #get(int) method (which is part of the
List interface).
E elementData(int index)
{
return (E) elementData[index];
}
If the current capacity of this vector is less than {@code minCapacity}, then its capacity
is increased by replacing its internal data array, kept in the field {@code elementData},
with a larger one. The size of the new data array will be the old size plus {@code
capacityIncrement}, unless the value of {@code capacityIncrement} is less than or
equal to zero, in which case the new capacity will be twice the old capacity; but if this
new size is still smaller than {@code minCapacity}, then the new capacity will be
{@code minCapacity}.
The index must be a value greater than or equal to {@code 0} and less than or equal to
the current size of the vector. (If the index is equal to the current size of the vector, the
new element is appended to the Vector.)
This method is identical in functionality to the add(int, E) method (which is part of the
List interface). Note that the {@code add} method reverses the order of the parameters,
to more closely match array usage.
This method is identical in functionality to the #clear method (which is part of the List
interface).
The index must be a value greater than or equal to {@code 0} and less than the current
size of the vector.
This method is identical in functionality to the #remove(int) method (which is part of the
List interface). Note that the {@code remove} method returns the old value that was
stored at the specified position.
The index must be a value greater than or equal to {@code 0} and less than the current
size of the vector.
This method is identical in functionality to the set(int, E) method (which is part of the
List interface). Note that the {@code set} method reverses the order of the parameters,
to more closely match array usage. Note also that the {@code set} method returns the
old value that was stored at the specified position.
The semantics of the List returned by this method become undefined if the backing list
(i.e., this List) is structurally modified in any way other than via the returned List.
(Structural modifications are those that change the size of the List, or otherwise perturb
it in such a fashion that iterations in progress may yield incorrect results.)
If the Vector fits in the specified array with room to spare (i.e., the array has more
elements than the Vector), the element in the array immediately following the end of the
Vector is set to null. (This is useful in determining the length of the Vector only if the
caller knows that the Vector does not contain any null elements.)