array in java

java.util Class ArrayListjava.lang.Object

java.util.AbstractCollection

java.util.AbstractList

java.util.ArrayList
All Implemented Interfaces:
Serializable, Cloneable, Iterable, Collection, List, RandomAccess
Direct Known Subclasses:
AttributeList, RoleList, RoleUnresolvedList
public class ArrayListextends AbstractListimplements List, RandomAccess, Cloneable, Serializable
Resizable-array implementation of the List interface. Implements all optional list operations, and permits all elements, including null. In addition to implementing the List interface, this class provides methods to manipulate the size of the array that is used internally to store the list. (This class is roughly equivalent to Vector, except that it is unsynchronized.)
The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.
Each ArrayList instance has a capacity. The capacity is the size of the array used to store the elements in the list. It is always at least as large as the list size. As elements are added to an ArrayList, its capacity grows automatically. The details of the growth policy are not specified beyond the fact that adding an element has constant amortized time cost.
An application can increase the capacity of an ArrayList instance before adding a large number of elements using the ensureCapacity operation. This may reduce the amount of incremental reallocation.
Note that this implementation is not synchronized. If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more elements, or explicitly resizes the backing array; merely setting the value of an element is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the list. If no such object exists, the list should be "wrapped" using the Collections.synchronizedList method. This is best done at creation time, to prevent accidental unsynchronized access to the list: List list = Collections.synchronizedList(new ArrayList(...));
The iterators returned by this class's iterator and listIterator methods are fail-fast: if list 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.
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 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.
This class is a member of the Java Collections Framework.
Since:
1.2
See Also:
Collection, List, LinkedList, Vector, Collections.synchronizedList(List), Serialized Form
Field Summary

Fields inherited from class java.util.AbstractList
modCount

Constructor Summary
ArrayList() Constructs an empty list with an initial capacity of ten.

ArrayList(CollectionE> c) Constructs a list containing the elements of the specified collection, in the order they are returned by the collection's iterator.

ArrayList(int initialCapacity) Constructs an empty list with the specified initial capacity.


Method Summary
boolean
add(E o) Appends the specified element to the end of this list.
void
add(int index, E element) Inserts the specified element at the specified position in this list.
boolean
addAll(CollectionE> c) Appends all of the elements in the specified Collection to the end of this list, in the order that they are returned by the specified Collection's Iterator.
boolean
addAll(int index, CollectionE> c) Inserts all of the elements in the specified Collection into this list, starting at the specified position.
void
clear() Removes all of the elements from this list.
Object
clone() Returns a shallow copy of this ArrayList instance.
boolean
contains(Object elem) Returns true if this list contains the specified element.
void
ensureCapacity(int minCapacity) Increases the capacity of this ArrayList instance, if necessary, to ensure that it can hold at least the number of elements specified by the minimum capacity argument.
E
get(int index) Returns the element at the specified position in this list.
int
indexOf(Object elem) Searches for the first occurence of the given argument, testing for equality using the equals method.
boolean
isEmpty() Tests if this list has no elements.
int
lastIndexOf(Object elem) Returns the index of the last occurrence of the specified object in this list.
E
remove(int index) Removes the element at the specified position in this list.
boolean
remove(Object o) Removes a single instance of the specified element from this list, if it is present (optional operation).
protected void
removeRange(int fromIndex, int toIndex) Removes from this List all of the elements whose index is between fromIndex, inclusive and toIndex, exclusive.
E
set(int index, E element) Replaces the element at the specified position in this list with the specified element.
int
size() Returns the number of elements in this list.
Object[]
toArray() Returns an array containing all of the elements in this list in the correct order.
T[]
toArray(T[] a) Returns an array containing all of the elements in this list in the correct order; the runtime type of the returned array is that of the specified array.
void
trimToSize() Trims the capacity of this ArrayList instance to be the list's current size.

Methods inherited from class java.util.AbstractList
equals, hashCode, iterator, listIterator, listIterator, subList

Methods inherited from class java.util.AbstractCollection
containsAll, removeAll, retainAll, toString

Methods inherited from class java.lang.Object
finalize, getClass, notify, notifyAll, wait, wait, wait

Methods inherited from interface java.util.List
containsAll, equals, hashCode, iterator, listIterator, listIterator, removeAll, retainAll, subList

Constructor Detail
ArrayListpublic ArrayList(int initialCapacity)
Constructs an empty list with the specified initial capacity.
Parameters:
initialCapacity - the initial capacity of the list.
Throws:
IllegalArgumentException - if the specified initial capacity is negative
ArrayListpublic ArrayList()
Constructs an empty list with an initial capacity of ten.
ArrayListpublic ArrayList(CollectionE> c)
Constructs a list containing the elements of the specified collection, in the order they are returned by the collection's iterator. The ArrayList instance has an initial capacity of 110% the size of the specified collection.
Parameters:
c - the collection whose elements are to be placed into this list.
Throws:
NullPointerException - if the specified collection is null.
Method Detail
trimToSizepublic void trimToSize()
Trims the capacity of this ArrayList instance to be the list's current size. An application can use this operation to minimize the storage of an ArrayList instance.
ensureCapacitypublic void ensureCapacity(int minCapacity)
Increases the capacity of this ArrayList instance, if necessary, to ensure that it can hold at least the number of elements specified by the minimum capacity argument.
Parameters:
minCapacity - the desired minimum capacity.
sizepublic int size()
Returns the number of elements in this list.
Specified by:
size in interface Collection<E>
Specified by:
size in interface List<E>
Specified by:
size in class AbstractCollection<E>
Returns:
the number of elements in this list.
isEmptypublic boolean isEmpty()
Tests if this list has no elements.
Specified by:
isEmpty in interface Collection<E>
Specified by:
isEmpty in interface List<E>
Overrides:
isEmpty in class AbstractCollection<E>
Returns:
true if this list has no elements; false otherwise.
containspublic boolean contains(Object elem)
Returns true if this list contains the specified element.
Specified by:
contains in interface Collection<E>
Specified by:
contains in interface List<E>
Overrides:
contains in class AbstractCollection<E>
Parameters:
elem - element whose presence in this List is to be tested.
Returns:
true if the specified element is present; false otherwise.
indexOfpublic int indexOf(Object elem)
Searches for the first occurence of the given argument, testing for equality using the equals method.
Specified by:
indexOf in interface List<E>
Overrides:
indexOf in class AbstractList<E>
Parameters:
elem - an object.
Returns:
the index of the first occurrence of the argument in this list; returns -1 if the object is not found.
See Also:
Object.equals(Object)
lastIndexOfpublic int lastIndexOf(Object elem)
Returns the index of the last occurrence of the specified object in this list.
Specified by:
lastIndexOf in interface List<E>
Overrides:
lastIndexOf in class AbstractList<E>
Parameters:
elem - the desired element.
Returns:
the index of the last occurrence of the specified object in this list; returns -1 if the object is not found.
clonepublic Object clone()
Returns a shallow copy of this ArrayList instance. (The elements themselves are not copied.)
Overrides:
clone in class Object
Returns:
a clone of this ArrayList instance.
See Also:
Cloneable
toArraypublic Object[] toArray()
Returns an array containing all of the elements in this list in the correct order.
Specified by:
toArray in interface Collection<E>
Specified by:
toArray in interface List<E>
Overrides:
toArray in class AbstractCollection<E>
Returns:
an array containing all of the elements in this list in the correct order.
See Also:
Arrays.asList(Object[])
toArraypublic T[] toArray(T[] a)
Returns an array containing all of the elements in this list in the correct order; the runtime type of the returned array is that of the specified array. If the list fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this list.
If the list fits in the specified array with room to spare (i.e., the array has more elements than the list), the element in the array immediately following the end of the collection is set to null. This is useful in determining the length of the list only if the caller knows that the list does not contain any null elements.
Specified by:
toArray in interface Collection<E>
Specified by:
toArray in interface List<E>
Overrides:
toArray in class AbstractCollection<E>
Parameters:
a - the array into which the elements of the list are to be stored, if it is big enough; otherwise, a new array of the same runtime type is allocated for this purpose.
Returns:
an array containing the elements of the list.
Throws:
ArrayStoreException - if the runtime type of a is not a supertype of the runtime type of every element in this list.
getpublic E get(int index)
Returns the element at the specified position in this list.
Specified by:
get in interface List<E>
Specified by:
get in class AbstractList<E>
Parameters:
index - index of element to return.
Returns:
the element at the specified position in this list.
Throws:
IndexOutOfBoundsException - if index is out of range (index <>= size()).
setpublic E set(int index, E element)
Replaces the element at the specified position in this list with the specified element.
Specified by:
set in interface List<E>
Overrides:
set in class AbstractList<E>
Parameters:
index - index of element to replace.
element - element to be stored at the specified position.
Returns:
the element previously at the specified position.
Throws:
IndexOutOfBoundsException - if index out of range (index <>= size()).
addpublic boolean add(E o)
Appends the specified element to the end of this list.
Specified by:
add in interface Collection<E>
Specified by:
add in interface List<E>
Overrides:
add in class AbstractList<E>
Parameters:
o - element to be appended to this list.
Returns:
true (as per the general contract of Collection.add).
addpublic void add(int index, E element)
Inserts the specified element at the specified position in this list. Shifts the element currently at that position (if any) and any subsequent elements to the right (adds one to their indices).
Specified by:
add in interface List<E>
Overrides:
add in class AbstractList<E>
Parameters:
index - index at which the specified element is to be inserted.
element - element to be inserted.
Throws:
IndexOutOfBoundsException - if index is out of range (index <> size()).
removepublic E remove(int index)
Removes the element at the specified position in this list. Shifts any subsequent elements to the left (subtracts one from their indices).
Specified by:
remove in interface List<E>
Overrides:
remove in class AbstractList<E>
Parameters:
index - the index of the element to removed.
Returns:
the element that was removed from the list.
Throws:
IndexOutOfBoundsException - if index out of range (index <>= size()).
removepublic boolean remove(Object o)
Removes a single instance of the specified element from this list, if it is present (optional operation). More formally, removes an element e such that (o==null ? e==null : o.equals(e)), if the list contains one or more such elements. Returns true if the list contained the specified element (or equivalently, if the list changed as a result of the call).
Specified by:
remove in interface Collection<E>
Specified by:
remove in interface List<E>
Overrides:
remove in class AbstractCollection<E>
Parameters:
o - element to be removed from this list, if present.
Returns:
true if the list contained the specified element.
clearpublic void clear()
Removes all of the elements from this list. The list will be empty after this call returns.
Specified by:
clear in interface Collection<E>
Specified by:
clear in interface List<E>
Overrides:
clear in class AbstractList<E>
addAllpublic boolean addAll(CollectionE> c)
Appends all of the elements in the specified Collection to the end of this list, in the order that they are returned by the specified Collection's Iterator. The behavior of this operation is undefined if the specified Collection is modified while the operation is in progress. (This implies that the behavior of this call is undefined if the specified Collection is this list, and this list is nonempty.)
Specified by:
addAll in interface Collection<E>
Specified by:
addAll in interface List<E>
Overrides:
addAll in class AbstractCollection<E>
Parameters:
c - the elements to be inserted into this list.
Returns:
true if this list changed as a result of the call.
Throws:
NullPointerException - if the specified collection is null.
See Also:
AbstractCollection.add(Object)
addAllpublic boolean addAll(int index, CollectionE> c)
Inserts all of the elements in the specified Collection into this list, starting at the specified position. Shifts the element currently at that position (if any) and any subsequent elements to the right (increases their indices). The new elements will appear in the list in the order that they are returned by the specified Collection's iterator.
Specified by:
addAll in interface List<E>
Overrides:
addAll in class AbstractList<E>
Parameters:
index - index at which to insert first element from the specified collection.
c - elements to be inserted into this list.
Returns:
true if this list changed as a result of the call.
Throws:
IndexOutOfBoundsException - if index out of range (index <> size()).
NullPointerException - if the specified Collection is null.
removeRangeprotected void removeRange(int fromIndex, int toIndex)
Removes from this List all of the elements whose index is between fromIndex, inclusive and toIndex, exclusive. Shifts any succeeding elements to the left (reduces their index). This call shortens the list by (toIndex - fromIndex) elements. (If toIndex==fromIndex, this operation has no effect.)
Overrides:
removeRange in class AbstractList<E>
Parameters:
fromIndex - index of first element to be removed.
toIndex - index after last element to be removed.


javadoc - The Java API Documentation Generator
Generates HTML pages of API documentation from Java source files. This document contains JavadocTM examples for Microsoft Windows.
CONTENTS
Reference Guide
Synopsis
Description
Processing of Source Files
Javadoc Doclets
Related Documentation
Terminology
Source Files
Class Source Code Files
Package Comment Files
Overview Comment File
Miscellaneous Unprocessed Files
Test Files and Template Files
Generated Files
Generated API Declarations
Documentation Comments
Commenting the Source Code
Automatic Copying of Method Comments
Javadoc Tags (@tag)
Where Tags Can Be Used
Options (-option)
Javadoc Options
Options Provided by the Standard Doclet
Command Line Argument Files
Running
Running Javadoc
Simple Examples
Documenting One or More Packages
Documenting One or More Classes
Documenting Both Packages and Classes
Real World Example
Command Line Example
Makefile Example
Troubleshooting
General Troubleshooting
Errors and Warnings
Environment
CLASSPATH
Troubleshooting
See Also
Reference Guide
SYNOPSIS
javadoc [ options ] [ packagenames ] [ sourcefilenames ] [ -subpackages pkg1:pkg2:... ] [ @argfiles ]
Arguments can be in any order. See processing of Source Files for details on how the Javadoc tool determines which ".java" files to process.
options
Command-line options, as specified in this document. To see a typical use of javadoc options, see Real-World Example.
packagenames
A series of names of packages, separated by spaces, such as java.lang java.lang.reflect java.awt. You must separately specify each package you want to document. Wildcards are not allowed; use -subpackages for recursion. The Javadoc tool uses -sourcepath to look for these package names. See Example - Documenting One or More Packages
sourcefilenames
A series of source file names, separated by spaces, each of which can begin with a path and contain a wildcard such as asterisk (*). The Javadoc tool will process every file whose name ends with ".java", and whose name, when stripped of that suffix, is actually a legal class name (see Identifiers). Therefore, you can name files with dashes (such as X-Buffer), or other illegal characters, to prevent them from being documented. This is useful for test files and template files The path that precedes the source file name determines where javadoc will look for the file. (The Javadoc tool does not use -sourcepath to look for these source file names.) Relative paths are relative to the current directory, so passing in Button.java is identical to ./Button.java. A source file name with an absolute path and a wildcard, for example, is /home/src/java/awt/Graphics*.java. See Example - Documenting One or More Classes. You can also mix packagenames and sourcefilenames, as in Example - Documenting Both Packages and Classes
-subpackages pkg1:pkg2:...
Generates documentation from source files in the specified packages and recursively in their subpackages. An alternative to supplying packagenames or sourcefilenames.
@argfiles
One or more files that contain a list of Javadoc options, packagenames and sourcefilenames in any order. Wildcards (*) and -J options are not allowed in these files.
DESCRIPTION
The JavadocTM tool parses the declarations and documentation comments in a set of Java source files and produces a corresponding set of HTML pages describing (by default) the public and protected classes, nested classes (but not anonymous inner classes), interfaces, constructors, methods, and fields. You can use it to generate the API (Application Programming Interface) documentation or the implementation documentation for a set of source files.
You can run the Javadoc tool on entire packages, individual source files, or both. When documenting entire packages, you can either use -subpackages for traversing recursively down from a top-level directory, or pass in an explicit list of package names. When documenting individual source files, you pass in a list of source (.java) filenames. Examples are given at the end of this document. How Javadoc processes source files is covered next.
Processing of source files
The Javadoc tool processes files that end in ".java" plus other files described under Source Files. If you run the Javadoc tool by explicitly passing in individual source filenames, you can determine exactly which ".java" files are processed. However, that is not how most developers want to work, as it is simpler to pass in package names. The Javadoc tool can be run three ways without explicitly specifying the source filenames. You can (1) pass in package names, (2) use -subpackages, and (3) use wildcards with source filenames (*.java). In these cases, the Javadoc tool processes a ".java" file only if it fulfills all of the following requirements:
· Its name, after stripping off the ".java" suffix, is actually a legal class name (see Identifiers for legal characters)
· Its directory path relative to the root of the source tree is actually a legal package name (after converting its separators to dots)
· Its package statement contains the legal package name (specified in the previous bullet)
Processing of links - During a run, the Javadoc tool automatically adds cross-reference links to package, class and member names that are being documented as part of that run. Links appear in several places:
· Declarations (return types, argument types, field types)
· "See Also" sections generated from @see tags
· In-line text generated from {@link} tags
· Exception names generated from @throws tags
· "Specified by" links to members in interfaces and "Overrides" links to members in classes
· Summary tables listing packages, classes and members
· Package and class inheritance trees
· The index
You can add hyperlinks to existing text for classes not included on the command line (but generated separately) by way of the -link and -linkoffline options.
Other processing details - The Javadoc tool produces one complete document each time it is run; it cannot do incremental builds -- that is, it cannot modify or directly incorporate results from previous runs of the Javadoc tool. However, it can link to results from other runs, as just mentioned.
As implemented, the Javadoc tool requires and relies on the java compiler to do its job. The Javadoc tool calls part of javac to compile the declarations, ignoring the member implementation. It builds a rich internal representation of the classes, including the class hierarchy, and "use" relationships, then generates the HTML from that. The Javadoc tool also picks up user-supplied documentation from documentation comments in the source code.
In fact, the Javadoc tool will run on .java source files that are pure stub files with no method bodies. This means you can write documentation comments and run the Javadoc tool in the earliest stages of design while creating the API, before writing the implementation.
Relying on the compiler ensures that the HTML output corresponds exactly with the actual implementation, which may rely on implicit, rather than explicit, source code. For example, the Javadoc tool documents default constructors (section 8.6.7 of Java Language Specification) that are present in the .class files but not in the source code.
In many cases, the Javadoc tool allows you to generate documentation for source files whose code is incomplete or erroneous. This is a benefit that enables you to generate documentation before all debugging and troubleshooting is done. For example, according to the Java Language Specification, a class that contains an abstract method should itself be declared abstract. The Javadoc tool does not check for this, and would proceed without a warning, whereas the javac compiler stops on this error. The Javadoc tool does do some primitive checking of doc comments. Use the DocCheck doclet to check the doc comments more thoroughly.
When the Javadoc tool builds its internal structure for the documentation, it loads all referenced classes. Because of this, the Javadoc tool must be able to find all referenced classes, whether bootstrap classes, extensions, or user classes. For more about this, see How Classes Are Found. Generally speaking, classes you create must either be loaded as an extension or in the Javadoc tool's class path.
Javadoc Doclets
You can customize the content and format of the Javadoc tool's output by using doclets. The Javadoc tool has a default "built-in" doclet, called the standard doclet, that generates HTML-formatted API documentation. You can modify or subclass the standard doclet, or write your own doclet to generate HTML, XML, MIF, RTF or whatever output format you'd like. Information about doclets and their use is at the following locations:
· Javadoc Doclets
· The -doclet command-line option
When a custom doclet is not specified with the -doclet command line option, the Javadoc tool will use the default standard doclet. The javadoc tool has several command line options that are available regardless of which doclet is being used. The standard doclet adds a supplementary set of command line options. Both sets of options are described below in the options section.
Related Documentation and Doclets
· Javadoc Enhancements for details about improvements added in Javadoc.
· Javadoc FAQ for answers to common questions, information about Javadoc-related tools, and workarounds for bugs.
· How to Write Doc Comments for Javadoc for more information about Sun conventions for writing documentation comments.
· Requirements for Writing API Specifications - Standard requirements used when writing the Java 2 Platform Specification. It can be useful whether you are writing API specifications in source file documentation comments or in other formats. It covers requirements for packages, classes, interfaces, fields and methods to satisfy testable assertions.
· Documentation Comment Specification - The original specification on documentation comments, Chapter 18, Documentation Comments, in the Java Language Specification, First Edition, by James Gosling, Bill Joy, and Guy Steele. (This chapter was removed from the second edition.)
· DocCheck Doclet - Checks doc comments in source files and generates a report listing the errors and irregularities it finds. It is part of the Sun Doc Check Utilities.
· MIF Doclet - Can automate the generation of API documentation in MIF, FrameMaker and PDF formats. MIF is Adobe FrameMaker's interchange format.
Terminology
The terms documentation comment, doc comment, main description, tag, block tag, and in-line tag are described at Documentation Comments. These other terms have specific meanings within the context of the Javadoc tool:
generated document
The document generated by the javadoc tool from the doc comments in Java source code. The default generated document is in HTML and is created by the standard doclet.
name
A name of a program element written in the Java Language -- that is, the name of a package, class, interface, field, constructor or method. A name can be fully-qualified, such as java.lang.String.equals(java.lang.Object), or partially-qualified, such as equals(Object).
documented classes
The classes and interfaces for which detailed documentation is generated during a javadoc run. To be documented, the source files must be available, their source filenames or package names must be passed into the javadoc command, and they must not be filtered out by their access modifier (public, protected, package-private or private). We also refer to these as the classes included in the javadoc output, or the included classes.
included classes
Classes and interfaces whose details are documented during a run of the Javadoc tool. Same as documented classes.
excluded classes
Classes and interfaces whose details are not documented during a run of the Javadoc tool.
referenced classes
The classes and interfaces that are explicitly referred to in the definition (implementation) or doc comments of the documented classes and interfaces. Examples of references include return type, parameter type, cast type, extended class, implemented interface, imported classes, classes used in method bodies, @see, {@link}, {@linkplain}, and {@inheritDoc} tags. (Notice this definition has changed since 1.3.) When the Javadoc tool is run, it should load into memory all of the referenced classes in javadoc's bootclasspath and classpath. (The Javadoc tool prints a "Class not found" warning for referenced classes not found.) The Javadoc tool can derive enough information from the .class files to determine their existence and the fully-qualified names of their members.
external referenced classes
The referenced classes whose documentation is not being generated during a javadoc run. In other words, these classes are not passed into the Javadoc tool on the command line. Links in the generated documentation to those classes are said to be external references or external links. For example, if you run the Javadoc tool on only the java.awt package, then any class in java.lang, such as Object, is an external referenced class. External referenced classes can be linked to using the -link and -linkoffline options. An important property of an external referenced class is that its source comments are normally not available to the Javadoc run. In this case, these comments cannot be inherited.
SOURCE FILES
The Javadoc tool will generate output originating from four different types of "source" files: Java language source files for classes (.java), package comment files, overview comment files, and miscellaneous unprocessed files. This section also covers test files and template files that can also be in the source tree, but which you want to be sure not to document.
Class Source Code Files
Each class or interface and its members can have their own documentation comments, contained in a .java file. For more details about these doc comments, see Documentation Comments.
Package Comment Files
Each package can have its own documentation comment, contained in its own "source" file, that the Javadoc tool will merge into the package summary page that it generates. You typically include in this comment any documentation that applies to the entire package.
To create a package comment file, you have a choice of two files to place your comments:
· package-info.java - Can contain a package declaration, package annotations, package comments and Javadoc tags. This file is new in JDK 5.0, and is preferred over package.html.
· package.html - Can contain only package comments and Javadoc tags, no package annotations.
A package may have a single package.html file or a single package-info.java file but not both. Place either file in the package directory in the source tree along with your .java files.
package-info.java This file can contain a package comment of the following structure -- the comment is placed before the package declaration:
File: java/applet/package-info.java
/** * Provides the classes necessary to create an applet and the classes an applet uses * to communicate with its applet context. *

* The applet framework involves two entities: * the applet and the applet context. An applet is an embeddable window (see the * {@link java.awt.Panel} class) with a few extra methods that the applet context * can use to initialize, start, and stop the applet. * * @since 1.0 * @see java.awt */package java.lang.applet;
Note that while the comment separators /** and /* must be present, the leading asterisks on the intermediate lines can be omitted. package.html - This file can contain a package comment of the following structure -- the comment is placed in the element:
File: java/applet/package.html
Provides the classes necessary to create an applet and the classes an applet uses to communicate with its applet context.

The applet framework involves two entities: the applet and the applet context. An applet is an embeddable window (see the {@link java.awt.Panel} class) with a few extra methods that the applet context can use to initialize, start, and stop the applet. @since 1.0@see java.awt
Notice this is just a normal HTML file and does not include a package declaration. The content of the package comment file is written in HTML, like all other comments, with one exception: The documentation comment should not include the comment separators /** and */ or leading asterisks. When writing the comment, you should make the first sentence a summary about the package, and not put a title or any other text between and the first sentence. You can include package tags; as with any documentation comment, all block tags must appear after the main description. If you add a @see tag in a package comment file, it must have a fully-qualified name. For more details, see the example of package.html.
Processing of package comment file - When the Javadoc tool runs, it will automatically look for the package comment file; if found, the Javadoc tool does the following:
· Copies the comment for processing. (For package.html, copies all content between and HTML tags. You can include a section to put a