# data[].attributes.body
Archivo PDF que contiene los conceptos que se van a trabajar en la Unidad 5 necesarios para desarrollar el caso práctico.

# data[].attributes.body
En este vídeo comenzamos a ver en qué consiste la Programación Orientada a Objetos (POO) usando el lenguaje Java.

# data[].attributes.body
Aquí empezamos a escribir algunos ejemplos en Java, utilizando conceptos como métodos y constructores.

# data[].attributes.body
Vídeo donde se explica el concepto de sobrecarga de constructores mediante un par de ejemplos.

# data[].attributes.attachment_link.title
Curso Java. Sobrecarga de constructores. Vídeo 39

# data[].attributes.body
Jerarquía de paquetes de la API básica de Java en la documentación oficial de Oracle.

# data[].attributes.attachment_link.readable_text
Module Graph:

Tool Guides:

java launcher,keytool

Since:

9

Packages

Provides for system input and output through data streams, serialization and the file system.

Provides classes that are fundamental to the design of the Java programming language.

Provides library support for the Java programming language annotation facility.

Classes and interfaces to represent nominal descriptors for run-time entities such as classes or method handles, and classfile entities such as constant pool entries or invokedynamic call sites.

The java.lang.invoke package provides low-level primitives for interacting with the Java Virtual Machine.

Classes to support module descriptors and creating configurations of modules by means of resolution and service binding.

Provides reference-object classes, which support a limited degree of interaction with the garbage collector.

Provides classes and interfaces for obtaining reflective information about classes and objects.

The java.lang.runtime package provides low-level runtime support for the Java language.

Provides classes for performing arbitrary-precision integer arithmetic ( BigInteger) and arbitrary-precision decimal arithmetic ( BigDecimal).

Provides the classes for implementing networking applications.

Service-provider classes for the java.net package.

Defines buffers, which are containers for data, and provides an overview of the other NIO packages.

Defines channels, which represent connections to entities that are capable of performing I/O operations, such as files and sockets; defines selectors, for multiplexed, non-blocking I/O operations.

Defines charsets, decoders, and encoders, for translating between bytes and Unicode characters.

Defines interfaces and classes for the Java virtual machine to access files, file attributes, and file systems.

Interfaces and classes providing access to file and file system attributes.

Provides the classes and interfaces for the security framework.

Provides classes and interfaces for parsing and managing certificates, certificate revocation lists (CRLs), and certification paths.

Provides interfaces for generating RSA (Rivest, Shamir and Adleman AsymmetricCipher algorithm) keys as defined in the RSA Laboratory Technical Note PKCS#1, and DSA (Digital Signature Algorithm) keys as defined in NIST's FIPS-186.

Provides classes and interfaces for key specifications and algorithm parameter specifications.

Provides classes and interfaces for handling text, dates, numbers, and messages in a manner independent of natural languages.

Service provider classes for the classes in the java.text package.

The main API for dates, times, instants, and durations.

Generic API for calendar systems other than the default ISO.

Provides classes to print and parse dates and times.

Access to date and time using fields and units, and date time adjusters.

Support for time-zones and their rules.

Contains the collections framework, some internationalization support classes, a service loader, properties, random number generation, string parsing and scanning classes, base64 encoding and decoding, a bit array, and several miscellaneous utility classes.

Utility classes commonly useful in concurrent programming.

A small toolkit of classes that support lock-free thread-safe programming on single variables.

Interfaces and classes providing a framework for locking and waiting for conditions that is distinct from built-in synchronization and monitors.

Functional interfaces provide target types for lambda expressions and method references.

Provides classes for reading and writing the JAR (Java ARchive) file format, which is based on the standard ZIP file format with an optional manifest file.

This package contains classes and interfaces that support a generic API for random number generation.

Classes for matching character sequences against patterns specified by regular expressions.

Service provider classes for the classes in the java.util package.

Classes to support functional-style operations on streams of elements, such as map-reduce transformations on collections.

Provides classes for reading and writing the standard ZIP and GZIP file formats.

Provides the classes and interfaces for cryptographic operations.

Provides interfaces for Diffie-Hellman keys as defined in RSA Laboratories' PKCS #3.

Provides classes and interfaces for key specifications and algorithm parameter specifications.

Provides classes for networking applications.

Provides classes for the secure socket package.

This package provides a framework for authentication and authorization.

This package provides the classes necessary for services to interact with applications in order to retrieve information (authentication data including usernames or passwords, for example) or to display information (error and warning messages, for example).

This package provides a pluggable authentication framework.

This package provides the interface to be used for implementing pluggable authentication modules.

This package contains the classes that should be used to store X500 Principal and X500 Private Credentials in a Subject.

Provides classes for public key certificates.

Services

An abstract implementation of a calendar system, used to organize and identify dates.

Service-provider class for asynchronous channels.

An abstract class for service providers that provide localized string representations (display names) of Calendar field values.

Charset service-provider class.

A calendar system, used to organize and identify dates.

This interface defines a factory for content handlers.

Service-provider class for file systems.

A file type detector for probing a file to guess its file type.

Service-provider interface for authentication technology providers.

This class represents a "provider" for the Java Security API, where a provider implements some or all parts of Java Security.

ResourceBundleProvider is a service provider interface for resource bundles.

Service-provider class for selectors and selectable channels.

The LoggerFinder service is responsible for creating, managing, and configuring loggers to the underlying framework it uses.

An interface for command-line tools to provide a way to be invoked without necessarily starting a new VM.

URL stream handler service-provider class.

Provider of time-zone rules to the system.

Report a bug or suggest an enhancement
For further API reference and developer documentation see the Java SE Documentation, which contains more detailed, developer-targeted descriptions with conceptual overviews, definitions of terms, workarounds, and working code examples. Other versions.
Java is a trademark or registered trademark of Oracle and/or its affiliates in the US and other countries.
Copyright © 1993, 2024, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.

# data[].attributes.body
Paso de parámetros a métodos en los manuales de Oracle sobre Java.

# data[].attributes.attachment_link.title
Passing Information to a Method or a Constructor (The Java™ Tutorials > Learning the Java Language > Classes and Objects)

# data[].attributes.attachment_link.description
This beginner Java tutorial describes fundamentals of programming in the Java programming language

# data[].attributes.body
Artículo de Wikipedia sobre el paso de parámetros donde se explica la diferencia entre el paso por valor y el paso por referencia.

# data[].attributes.attachment_link.readable_text
En ciencias de la computación, un parámetro es una variable utilizada para recibir valores de entrada en una rutina, subrutina o método. Dichos valores, que serán enviados desde la rutina invocante, son llamados argumentos. La subrutina usa los valores asignados a sus parámetros para alterar su comportamiento en tiempo de ejecución. La mayor parte de los lenguajes de programación pueden definir subrutinas que aceptan cero o más argumentos.

Paso de argumentos

Diagrama del funcionamiento de una subrutina.

Existen cinco formas de pasar un argumento a una función (subrutina) o procedimiento: por valor, por referencia, por resultado, por valor-resultado y por nombre.

Paso por valor

El paso de parámetros por valor consiste en copiar el contenido de la variable que queremos pasar en otra dentro del ámbito local de la subrutina, consiste pues en copiar el contenido de la memoria del argumento que se quiere pasar a otra dirección de memoria, correspondiente al argumento dentro del ámbito de dicha subrutina. Se tendrán dos valores duplicados e independientes, con lo que la modificación de uno no afecta al otro.

Paso por referencia

El paso de parámetros por referencia consiste en proporcionar a la subrutina a la que se le quiere pasar el argumento la dirección de memoria del dato. En este caso se tiene un único valor referenciado (o apuntado) desde dos puntos diferentes, el programa principal y la subrutina a la que se le pasa el argumento, por lo que cualquier acción sobre el parámetro se realiza sobre la misma posición de memoria.

El paso de la dirección de memoria debe ser transparente al programador. Los lenguajes que permiten tratar con direcciones de memoria, como C, permiten simular el paso de argumentos por referencia, sin disponer realmente de esta característica.

Paso por valor resultado

Es un tipo poco usado en los lenguajes de programación actuales. Se basa en que dentro de la función se trabaja como si los argumentos hubieran sido pasados por valor pero al acabar la función los valores que tengan los argumentos serán copiados a las variables que pertenecían.

Este tipo puede ser simulado en cualquier lenguaje que permita el paso de valores por referencia de la siguiente forma:

Tal y como indica el ejemplo de simulación de valor-resultado, el orden de copia depende del compilador, lo que implica que la misma función pueda dar resultados diferentes según el compilador usado.

Ejemplo de diferencias entre los distintos pasos de parámetros

Aquí se exponen unos ejemplos que demuestran las diferencias de estos tipos:

Argumentos pasados por valor: a = 0

Argumentos pasados por referencia: a = 3

Argumentos pasados por valor-resultado:

Si el compilador copia los resultados de derecha a izquierda: a = 1

Si el compilador copia los resultados de izquierda a derecha: a = 2

Véase también

# data[].attributes.attachment_link.title
Argumento (informática) - Wikipedia, la enciclopedia libre

# data[].attributes.attachment_link.description
En ciencias de la computación, un parámetro es una variable utilizada para recibir valores de entrada en una rutina, subrutina o método. Dichos valores, que serán enviados desde la rutina invocante, son llamados argumentos. La subrutina usa los valores asignados a sus parámetros para alterar su comportamiento en tiempo de ejecución.

# data[].attributes.body
Artículo general sobre la referencia this en los manuales de Oracle.

# data[].attributes.attachment_link.readable_text
Within an instance method or a constructor, this is a reference to the current object — the object whose method or constructor is being called. You can refer to any member of the current object from within an instance method or a constructor by using this.

Using this with a Field

The most common reason for using the this keyword is because a field is shadowed by a method or constructor parameter.

For example, the Point class was written like this

public class Point {
    public int x = 0;
    public int y = 0;
 //constructor public Point(int a, int b) { x = a; y = b; } }

but it could have been written like this:

public class Point {
    public int x = 0;
    public int y = 0;
 //constructor public Point(int x, int y) { this.x = x; this.y = y; } }

Each argument to the constructor shadows one of the object's fields — inside the constructor is a local copy of the constructor's first argument. To refer to the Point field , the constructor must use this.x.

Using this with a Constructor

From within a constructor, you can also use the this keyword to call another constructor in the same class. Doing so is called an explicit constructor invocation. Here's another Rectangle class, with a different implementation from the one in the Objects section.

public class Rectangle {
    private int x, y;
    private int width, height;

    public Rectangle() {
this(0, 0, 1, 1); } public Rectangle(int width, int height) {this(0, 0, width, height); } public Rectangle(int x, int y, int width, int height) { this.x = x; this.y = y; this.width = width; this.height = height; } ... }

This class contains a set of constructors. Each constructor initializes some or all of the rectangle's member variables. The constructors provide a default value for any member variable whose initial value is not provided by an argument. For example, the no-argument constructor creates a 1x1 Rectangle at coordinates 0,0. The two-argument constructor calls the four-argument constructor, passing in the width and height but always using the 0,0 coordinates. As before, the compiler determines which constructor to call, based on the number and the type of arguments.

If present, the invocation of another constructor must be the first line in the constructor.

# data[].attributes.attachment_link.description
This beginner Java tutorial describes fundamentals of programming in the Java programming language

# data[].attributes.body
Enlace al tutorial oficial de Java donde se explica el lanzamiento de excepciones.

# data[].attributes.attachment_link.readable_text
Before you can catch an exception, some code somewhere must throw one. Any code can throw an exception: your code, code from a package written by someone else such as the packages that come with the Java platform, or the Java runtime environment. Regardless of what throws the exception, it's always thrown with the throw statement.

As you have probably noticed, the Java platform provides numerous exception classes. All the classes are descendants of the class, and all allow programs to differentiate among the various types of exceptions that can occur during the execution of a program.

You can also create your own exception classes to represent problems that can occur within the classes you write. In fact, if you are a package developer, you might have to create your own set of exception classes to allow users to differentiate an error that can occur in your package from errors that occur in the Java platform or other packages.

You can also create chained exceptions. For more information, see the Chained Exceptions section.

The throw Statement

All methods use the throw statement to throw an exception. The throw statement requires a single argument: a throwable object. Throwable objects are instances of any subclass of the Throwable class. Here's an example of a throw statement.

throwsomeThrowableObject;

Let's look at the throw statement in context. The following pop method is taken from a class that implements a common stack object. The method removes the top element from the stack and returns the object.

public Object pop() {
    Object obj;

    if (size == 0) {
throw new EmptyStackException(); } obj = objectAt(size - 1); setObjectAt(size - 1, null); size--; return obj; }

The pop method checks to see whether any elements are on the stack. If the stack is empty (its size is equal to 0), pop instantiates a new EmptyStackException object (a member of java.util) and throws it. The Creating Exception Classes section in this chapter explains how to create your own exception classes. For now, all you need to remember is that you can throw only objects that inherit from the java.lang.Throwable class.

Note that the declaration of the pop method does not contain a throws clause. EmptyStackException is not a checked exception, so pop is not required to state that it might occur.

Throwable Class and Its Subclasses

The objects that inherit from the Throwable class include direct descendants (objects that inherit directly from the Throwable class) and indirect descendants (objects that inherit from children or grandchildren of the Throwable class). The figure below illustrates the class hierarchy of the Throwable class and its most significant subclasses. As you can see, Throwable has two direct descendants: and .

Error Class

When a dynamic linking failure or other hard failure in the Java virtual machine occurs, the virtual machine throws an Error. Simple programs typically do not catch or throw Error s.

Exception Class

Most programs throw and catch objects that derive from the Exception class. An Exception indicates that a problem occurred, but it is not a serious system problem. Most programs you write will throw and catch Exceptions as opposed to Error s.

The Java platform defines the many descendants of the Exception class. These descendants indicate various types of exceptions that can occur. For example, IllegalAccessException signals that a particular method could not be found, and NegativeArraySizeException indicates that a program attempted to create an array with a negative size.

One Exception subclass, RuntimeException, is reserved for exceptions that indicate incorrect use of an API. An example of a runtime exception is NullPointerException, which occurs when a method tries to access a member of an object through a null reference. The section Unchecked Exceptions — The Controversy discusses why most applications shouldn't throw runtime exceptions or subclass RuntimeException.

# data[].attributes.attachment_link.description
This Java tutorial describes exceptions, basic input/output, concurrency, regular expressions, and the platform environment

# data[].attributes.body
Tutorial sobre cómo documentar código Java con Javadoc.

# data[].attributes.attachment_link.readable_text
Cuando desarrollamos aplicaciones, de un modo paralelo debemos construir la
documentación.

Desde las primeras versiones de Java e incluso para documentar las propias
libreriís del lenguaje, se utiliza un mecanismo llamado JavaDoc para garantizar
que el código y su documentación estan sincronizados.

Este sistema consiste en incluir comentarios en el código, utilizando unas
etiquetas especiales, que despues pueden procesarse y generar un juego navegable
de documento HTML.

Estos comentarios estan incluidos en bloques entre las etiquetas /** y */

Al igual que obtenemos en binario de un programa java con javac,
podemos obtener la documentación ejecutando sobre los mismos elementos el
comando javadoc.

Los entornos de desarrollo avanzado ya hacen muchas de estas
cosas por nosostros ..... solo tenemos que saber encontrarlas.

Vamos a crear una clase y ver lo que se va generando.

Buscamos en el menú.... y vemos que en herramientas .... podemos generar el
documento JavaDoc..

Las etiquetas disponibles son:

Aunque pongamos todas las etiquetas, no todas se muestran. En
función de los parametros que se pasen al comando javadoc, selecionamos
cuales queremos ver.

Aquí podemos ver como configurarlo en FORTE o NETBEANS.
Activamos la opción de ver el autor.

Y comprobamos que disponemos de una nueva etiqueta en nuestra
documentación.

En la documentación estandar de Java podemos comprobar donde
podemos utilizar cada una de las distintas etiquetas:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javadoc.html#{@link}

Os mostramos un pequeño ejemplo ...

 /*
 * ejemplojavadoc.java
 *
 * Created on July 5, 2003, 4:24 AM
 */

/**
 * Clase que comienza la estructura de escepciones
 * @author  Roberto Canales
 * @since  1.0
 * @see Visitar /**
 *
 * @author  Roberto Canales
 * @since  1.0
 * @see Visitar    /**
     *  Punto de entrada a la aplicación
     *  @exception RCException Se genera una excepción genérica.
     *  @returnwww.adictosaltrabajo.com */ class RCException extends Exception { void depura(String psError) { System.out.println("Error: " + psError); } RCException(String psError) { super(psError); depura(psError); } }www.adictosaltrabajo.com */ public class ejemplojavadoc { /** Constantes publicas de gestion errores*/ public static final int ERROR = 0; public static final int LOG = 1; public static final int INFO = 2; /** Constructor por defecto */ public ejemplojavadoc() { } void depura(String sError) { System.out.println("ejemplojavadoc: " + sError); } /** * @param args Array de argumentos */ public static void main(String[] args) { /** Construimos un objeto no estático */ ejemplojavadoc objetoAuxiliar = new ejemplojavadoc(); try { objetoAuxiliar.ejecuta(); } catch(RCException e) { objetoAuxiliar.depura("Excepcion = " + e.getMessage()); } } /** Retornamos true por defecto */ int error = 0; if(error == 0) { throw new RCException("Invocamos excepciones"); } return true; } }true */ public boolean ejecuta() throws RCException {

Las marcas utilizada por defecto, se pueden extender y crear
otras nuevas.... para ello hay que crear nuevas clases con el API de Taglet y doclets

Pero esto es otra historia ......

# data[].attributes.attachment_link.title
Documentar código Java con JavaDoc - Adictos al trabajo

# data[].attributes.attachment_link.description
Os mostramos como utilizar los comentarios y etiquetas de JavaDoc para documentar programas Java.

# data[].attributes.body
Tutorial de Javadoc de Oracle: recurso oficial de Oracle para entender los conceptos básicos y avanzados de Javadoc.

# data[].attributes.attachment_link.readable_text
The javadoc command uses doclets to determine its output. The javadoc command uses the default standard doclet unless a custom doclet is specified with the -doclet option. The javadoc command provides a set of command-line options that can be used with any doclet. These options are described in Javadoc Options. The standard doclet provides an additional set of command-line options that are described in Standard Doclet Options. All option names are not case-sensitive, but their arguments are case-sensitive.

The options are:

The following options are the core Javadoc options that are available to all doclets. The standard doclet provides the rest of the doclets: -bootclasspath, -breakiterator, -classpath, -doclet, -docletpath, -encoding, - exclude, -extdirs, -help, -locale, -overview, -package, -private, -protected, -public, -quiet, -source, -sourcepath, -subpackages, and -verbose.

Javadoc Options

-overview path\filename

Specifies that the javadoc command should retrieve the text for the overview documentation from the source file specified by the path\filename and place it on the Overview page (overview-summary.html). The path\filename is relative to the current directory.

While you can use any name you want for the filename value and place it anywhere you want for the path, it is typical to name it overview.html and place it in the source tree at the directory that contains the topmost package directories. In this location, no path is needed when documenting packages, because the -sourcepath option points to this file.

For example, if the source tree for the java.lang package is \src\classes\java\lang\, then you could place the overview file at \src\classes\overview.html

See Real-World Examples.

For information about the file specified by path\filename, see Overview Comment Files.

The overview page is created only when you pass two or more package names to the javadoc command. For a further explanation, see HTML Frames. The title on the overview page is set by -doctitle.

-Xdoclint:(all|none|[-]<group>)

Reports warnings for bad references, lack of accessibility and missing Javadoc comments, and reports errors for invalid Javadoc syntax and missing HTML tags.

By default, the -Xdoclint option is enabled. Disable it with the option -Xdoclint:none.

Change what the -Xdoclint option reports with the following options:

The variable has one of the following values:

html : Detects high-level HTML issues, like putting block elements inside inline elements, or not closing elements that require an end tag. The rules are derived from the HTML 4.01 Specification. This type of check enables the javadoc command to detect HTML issues that many browsers might accept.

reference : Checks for issues relating to the references to Java API elements from Javadoc tags (for example, item not found in @see , or a bad name after @param).

syntax : Checks for low level issues like unescaped angle brackets (< and >) and ampersands (&) and invalid Javadoc tags.

You can specify the -Xdoclint option multiple times to enable the option to check errors and warnings in multiple categories. Alternatively, you can specify multiple error and warning categories by using the preceding options. For example, use either of the following commands to check for the HTML, syntax, and accessibility issues in the file .

javadoc -Xdoclint:html -Xdoclint:syntax -Xdoclint:accessibility filename
javadoc -Xdoclint:html,syntax,accessibility filename

Note: The javadoc command does not guarantee the completeness of these checks. In particular, it is not a full HTML compliance checker. The goal of the - Xdoclint option is to enable the javadoc command to report majority of common errors.

The javadoc command does not attempt to fix invalid input, it just reports it.

-public

Shows only public classes and members.

-protected

Shows only protected and public classes and members. This is the default.

-package

Shows only package, protected, and public classes and members.

-private

Shows all classes and members.

-help

-doclet class

Specifies the class file that starts the doclet used in generating the documentation. Use the fully qualified name. This doclet defines the content and formats the output. If the -doclet option is not used, then the javadoc command uses the standard doclet for generating the default HTML format. This class must contain the start(Root) method. The path to this starting class is defined by the -docletpath option. See Doclet Overview at
https://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/doclet/overview.html

-docletpath classpathlist

-1.1

Removed from Javadoc 1.4 with no replacement. This option created documentation with the appearance and functionality of documentation generated by Javadoc 1.1 (it never supported nested classes). If you need this option, then use Javadoc 1.2 or 1.3 instead.

-source release

Specifies the release of source code accepted. The parameter can have the value 1.3, 1.4, 1.5, 6, 7, or 8. Use the value that corresponds to the value used when you compiled your code with the javac command.

-sourcepath sourcepathlist

Specifies the search paths for finding source files when passing package names or the -subpackages option into the javadoc command.

Separate multiple paths with a. semicolon (;).

The javadoc command searches all subdirectories of the specified paths. Note that this option is not only used to locate the source files being documented, but also to find source files that are not being documented, but whose comments are inherited by the source files being documented.

You can use the -sourcepath option only when passing package names into the javadoc command. This will not locate source files passed into the javadoc command. To locate source files, change to that directory or include the path ahead of each file, as shown at Document One or More Classes. If you omit -sourcepath, then the javadoc command uses the class path to find the source files (see -classpath). The default -sourcepath is the value of class path. If -classpath is omitted and you pass package names into the javadoc command, then the javadoc command searches in the current directory and subdirectories for the source files.

Set sourcepathlist to the root directory of the source tree for the package you are documenting.

For example, suppose you want to document a package called com.mypackage, whose source files are located at:\user\src\com\mypackage\*.java . Specify the sourcepath to \user\src, the directory that contains com\mypackage, and then supply the package name as follows:

javadoc -sourcepath C:\user\src com.mypackage

Notice that if you concatenate the value of sourcepath and the package name together and change the dot to a backslash (\), then you have the full path to the package:
\user\src\com\mypackage.
To point to two source paths:

javadoc -sourcepath \user1\src;\user2\src com.mypackage

-classpath classpathlist

Specifies the paths where the javadoc command searches for referenced classes These are the documented classes plus any classes referenced by those classes.

Separate multiple paths with a semicolon (;).

The javadoc command searches all subdirectories of the specified paths. Follow the instructions in the class path documentation for specifying the classpathlist value.

For example, if you want to document com.mypackage, whose source files reside in the directory \user\src\com\mypackage, and if this package relies on a library in , \user\lib, then you would use the following command:

javadoc -sourcepath \user\lib -classpath \user\src com.mypackage

A class path element that contains a base name of * is considered equivalent to specifying a list of all the files in the directory with the extension .jar or .JAR.

-subpackages package1:package2:...

Generates documentation from source files in the specified packages and recursively in their subpackages. This option is useful when adding new subpackages to the source code because they are automatically included. Each package argument is any top-level subpackage (such as java) or fully qualified package (such as javax.swing) that does not need to contain source files. Arguments are separated by colons on all operating systems. Wild cards are not allowed. Use -sourcepath to specify where to find the packages. This option does not process source files that are in the source tree but do not belong to the packages. See Process Source Files.

For example, the following command generates documentation for packages named java and javax.swing and all of their subpackages.

javadoc -d docs -sourcepath \user\src -subpackages java:javax.swing

-exclude packagename1:packagename2:...

Unconditionally excludes the specified packages and their subpackages from the list formed by -subpackages. It excludes those packages even when they would otherwise be included by some earlier or later -subpackages option.

javadoc -sourcepath \user\src -subpackages java -exclude
    java.net:java.lang

-bootclasspath classpathlist

Separate directories in the classpathlist parameters with semicolons (;) for Windows and colons (:) for Oracle Solaris.

-extdirs dirist

-verbose

-quiet

Shuts off messages so that only the warnings and errors appear to make them easier to view. It also suppresses the version string.

-breakiterator

English default sentence-break algorithm. Stops at a period followed by a space or an HTML block tag, such as <P>.

Breakiterator sentence-break algorithm. Stops at a period, question mark, or exclamation point followed by a space when the next word starts with a capital letter. This is meant to handle most abbreviations (such as "The serial no. is valid", but will not handle "Mr. Smith"). The -breakiterator option does not stop at HTML tags or sentences that begin with numbers or symbols. The algorithm stops at the last period in ../filename, even when embedded in an HTML tag.

In Java SE 1.5 the -breakiterator option warning messages are removed, and the default sentence-break algorithm is unchanged. If you have not modified your source code to eliminate the -breakiterator option warnings in Java SE 1.4.x, then you do not have to do anything. The warnings go away starting with Java SE 1.5.0.

-locale language_country_variant

Note: The -locale option must be placed ahead (to the left) of any options provided by the standard doclet or any other doclet. Otherwise, the navigation bars appear in English. This is the only command-line option that depends on order. See Standard Doclet Options.

Specifying a locale causes the javadoc command to choose the resource files of that locale for messages such as strings in the navigation bar, headings for lists and tables, help file contents, comments in the stylesheet.css file, and so on. It also specifies the sorting order for lists sorted alphabetically, and the sentence separator to determine the end of the first sentence. The -locale option does not determine the locale of the documentation comment text specified in the source files of the documented classes.

-encoding

Specifies the encoding name of the source files, such as EUCJIS/SJIS. If this option is not specified, then the platform default converter is used. See also the and options.

-Jflag

There is no space between the J and the flag.

Use the -version option to find out what version of the javadoc command you are using. The version number of the standard doclet appears in its output stream. See Running the Javadoc Command.

javadoc -J-version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

-javafx

Generates HTML documentation using the JavaFX extensions to the standard doclet. The generated documentation includes a Property Summary section in addition to the other summary sections generated by the standard Java doclet. The listed properties are linked to the sections for the getter and setter methods of each property.

If there are no documentation comments written explicitly for getter and setter methods, the documentation comments from the property method are automatically copied to the generated documentation for these methods. This option also adds a new @defaultValue tag that allows documenting the default value for a property.

Example:

javadoc -javafx MyClass.java -d testdir

Standard Doclet Options

-d directory

-use

Includes one Use page for each documented class and package. The page describes what packages, classes, methods, constructors and fields use any API of the specified class or package. Given class C, things that use class C would include subclasses of C, fields declared as C, methods that return C, and methods and constructors with parameters of type C. For example, you can look at the Use page for the String type. Because the getName method in the java.awt.Font class returns type String, the getName method uses String and so the getName method appears on the Use page for String.This documents only uses of the API, not the implementation. When a method uses String in its implementation, but does not take a string as an argument or return a string, that is not considered a use of String.To access the generated Use page, go to the class or package and click the Use link in the navigation bar.

-version

-author

Includes the @author text in the generated docs.

-splitindex

Splits the index file into multiple files, alphabetically, one file per letter, plus a file for any index entries that start with non-alphabetical symbols.

-windowtitle title

Specifies the title to be placed in the HTML <title> tag. The text specified in the title tag appears in the window title and in any browser bookmarks (favorite places) that someone creates for this page. This title should not contain any HTML tags because the browser does not interpret them correctly. Use escape characters on any internal quotation marks within the title tag. If the -windowtitle option is omitted, then the javadoc command uses the value of the -doctitle option for the -windowtitle option. For example, javadoc -windowtitle "Java SE Platform" com.mypackage.

-doctitle title

-title title

No longer exists. It existed only in Beta releases of Javadoc 1.2. It was renamed to -doctitle. This option was renamed to make it clear that it defines the document title, rather than the window title.

-header header

-footer footer

Specifies the footer text to be placed at the bottom of each output file. The footer value is placed to the right of the lower navigation bar. The footer value can contain HTML tags and white space, but when it does, the footer value must be enclosed in quotation marks. Use escape characters for any internal quotation marks within a footer.

-top

Specifies the text to be placed at the top of each output file.

-bottom text

Specifies the text to be placed at the bottom of each output file. The text is placed at the bottom of the page, underneath the lower navigation bar. The text can contain HTML tags and white space, but when it does, the text must be enclosed in quotation marks. Use escape characters for any internal quotation marks within text.

-link extdocURL

Creates links to existing Javadoc-generated documentation of externally referenced classes. The extdocURL argument is the absolute or relative URL of the directory that contains the external Javadoc-generated documentation you want to link to. You can specify multiple -link options in a specified javadoc command run to link to multiple documents.

The package-list file must be found in this directory (otherwise, use the -linkoffline option). The javadoc command reads the package names from the package-list file and links to those packages at that URL. When the javadoc command runs, the extdocURL value is copied into the <A HREF> links that are created. Therefore, extdocURL must be the URL to the directory, and not to a file. You can use an absolute link for extdocURL to enable your documents to link to a document on any web site, or you can use a relative link to link only to a relative location. If you use a relative link, then the value you pass in should be the relative path from the destination directory (specified with the -d option) to the directory containing the packages being linked to.When you specify an absolute link, you usually use an HTTP link. However, if you want to link to a file system that has no web server, then you can use a file link. Use a file link only when everyone who wants to access the generated documentation shares the same file system.In all cases, and on all operating systems, use a slash as the separator, whether the URL is absolute or relative, and h ttp: or f ile: as specified in the URL Memo: Uniform Resource Locators at
https://www.ietf.org/rfc/rfc1738.txt

-link  http://<host>/<directory>/<directory>/.../<name>
-link file://<host>/<directory>/<directory>/.../<name>
-link <directory>/<directory>/.../<name>

Differences between the -linkoffline and -link options
Use the -link option in the following cases:

Use the -linkoffline option when you use an absolute URL to the external API document, if your shell does not allow a program to open a connection to that URL for reading. This can occur when you are behind a firewall and the document you want to link to is on the other side.

Example 1 - Absolute Link to External Documents

javadoc -link https://docs.oracle.com/javase/8/docs/api/ com.mypackage

Example 2 - Relative Link to External Documents

Notice the -link option is relative to the destination directory (docs/spi).

Notes
The -link option lets you link to classes referenced to by your code, but not documented in the current javadoc command run. For these links to go to valid pages, you must know where those HTML pages are located and specify that location with extdocURL. This allows third-party documentation to link to java.* documentation at . Omit the -link option when you want the javadoc command to create links only to APIs within the documentation it is generating in the current run. Without the -link option, the javadoc command does not create links to documentation for external references because it does not know whether or where that documentation exists.The -link option can create links in several places in the generated documentation. See Process Source Files. Another use is for cross-links between sets of packages: Execute the javadoc command on one set of packages, then run the javadoc command again on another set of packages, creating links both ways between both sets.
How to Reference a Class
For a link to an externally referenced class to appear (and not just its text label), the class must be referenced in the following way. It is not sufficient for it to be referenced in the body of a method. It must be referenced in either an import statement or in a declaration. Here are examples of how the class java.io.File can be referenced:

In any kind of import statement. By wildcard import, import explicitly by name, or automatically import for java.lang.*.

In Java SE 1.3. n and 1.2. n, only an explicit import by name works. A wildcard import statement does not work, nor does the automatic import java.lang.*.

In a declaration: void mymethod(File f) {}

The reference can be in the return type or parameter type of a method, constructor, field, class, or interface, or in an implements, extends, or throws statement.

An important corollary is that when you use the -link option, there can be many links that unintentionally do not appear due to this constraint. The text would appear without being a link. You can detect these by the warnings they emit. The simplest way to properly reference a class and add the link would be to import that class.
Package List
For example, the package list for the Java SE API is located at
https://docs.oracle.com/javase/8/docs/api/package-list

The package list starts as follows:

java.applet
java.awt
java.awt.color
java.awt.datatransfer
java.awt.dnd
java.awt.event
java.awt.font
and so on ....

When javadoc is run without the -link option and encounters a name that belongs to an externally referenced class, it prints the name with no link. However, when the -link option is used, the javadoc command searches the package-list file at the specified extdocURL location for that package name. When it finds the package name, it prefixes the name with extdocURL.

For there to be no broken links, all of the documentation for the external references must exist at the specified URLs. The javadoc command does not check that these pages exist, but only that the package-list exists.
Multiple Links
You can supply multiple -link options to link to any number of externally generated documents. Javadoc 1.2 has a known bug that prevents you from supplying more than one -link options. This was fixed in Javadoc 1.2.2. Specify a different link option for each external document to link to javadoc -link extdocURL1 -link extdocURL2 ... -link extdocURLn com.mypackage where extdocURL1, extdocURL2, ... extdocURLn point respectively to the roots of external documents, each of which contains a file named package-list.
Cross Links
Note that bootstrapping might be required when cross-linking two or more documents that were previously generated. If package-list does not exist for either document when you run the javadoc command on the first document, then the package-list does not yet exist for the second document. Therefore, to create the external links, you must regenerate the first document after you generate the second document.

In this case, the purpose of first generating a document is to create its package-list (or you can create it by hand if you are certain of the package names). Then, generate the second document with its external links. The javadoc command prints a warning when a needed external package-list file does not exist.

-linkoffline extdocURL packagelistLoc

This option is a variation of the -link option. They both create links to Javadoc-generated documentation for externally referenced classes. Use the -linko ffline option when linking to a document on the web when the javadoc command cannot access the document through a web connection. Use the -linkoffline option when package-list file of the external document is not accessible or does not exist at the extdocURL location, but does exist at a different location that can be specified by packageListLoc (typically local). If extdocURL is accessible only on the World Wide Web, then the -linkoffline option removes the constraint that the javadoc command must have a web connection to generate documentation. Another use is as a work-around to update documents: After you have run the javadoc command on a full set of packages, you can run the javadoc command again on a smaller set of changed packages, so that the updated files can be inserted back into the original set. Examples follow. The -linkoffline option takes two arguments. The first is for the string to be embedded in the <a href> links, and the second tells the -linkoffline option where to find package-list:

The extdocURL value is the absolute or relative URL of the directory that contains the external Javadoc-generated documentation you want to link to. When relative, the value should be the relative path from the destination directory (specified with the -d option) to the root of the packages being linked to. For more information, see extdocURL in the -link option.

The packagelistLoc value is the path or URL to the directory that contains the package-list file for the external documentation. This can be a URL (http: or file:) or file path, and can be absolute or relative. When relative, make it relative to the current directory from where the javadoc command was run. Do not include the package-list file name.

You can specify multiple -linkoffline options in a specified javadoc command run. Before Javadoc 1.2.2, the -linkfile options could be specified once.

Absolute Links to External Documents
You might have a situation where you want to link to the java.lang, java.io and other Java SE packages at
https://docs.oracle.com/javase/8/docs/api/index.html

However, your shell does not have web access. In this case, do the following:

1. Open the package-list file in a browser at https://docs.oracle.com/javase/8/docs/api/package-list

2. Save the file to a local directory, and point to this local copy with the second argument, packagelistLoc. In this example, the package list file was saved to the current directory (.).

javadoc -linkoffline https://docs.oracle.com/javase/8/docs/api/ .  com.mypackage

Relative Links to External Documents Create a package-list File Manually Link to Multiple Documents
You can include the -linkoffline option once for each generated document you want to refer to:

javadoc -linkoffline extdocURL1 packagelistLoc1 -linkoffline extdocURL2
packagelistLoc2 ...

Update Documents
First, create a new destination directory, such as update, for this new small run. In this example, the original destination directory is named html. In the simplest example, change directory to the parent of html. Set the first argument of the -linkoffline option to the current directory (.) and set the second argument to the relative path to html, where it can find package-list and pass in only the package names of the packages you want to update:

javadoc -d update -linkoffline . html com.mypackage

When the javadoc command completes, copy these generated class pages in update\com\package (not the overview or index) to the original files in html\com\package.

-linksource

Creates an HTML version of each source file (with line numbers) and adds links to them from the standard HTML documentation. Links are created for classes, interfaces, constructors, methods, and fields whose declarations are in a source file. Otherwise, links are not created, such as for default constructors and generated classes.

Each link appears on the name of the identifier in its declaration. For example, the link to the source code of the Button class would be on the word Button:

public class Button extends Component implements Accessible

public String getLabel()

-group groupheading packagepattern:packagepattern

Separates packages on the overview page into whatever groups you specify, one group per table. You specify each group with a different -group option. The groups appear on the page in the order specified on the command line. Packages are alphabetized within a group. For a specified -group option, the packages matching the list of packagepattern expressions appear in a table with the heading groupheading.

When you do not supply a -group option, all packages are placed in one group with the heading Packages and appropriate subheadings. If the subheadings do not include all documented packages (all groups), then the remaining packages appear in a separate group with the subheading Other Packages.

For example, the following javadoc command separates the three documented packages into Core, Extension, and Other Packages. The trailing dot (.) does not appear in java.lang*. Including the dot, such as java.lang.* omits the java.lang package.

javadoc -group "Core Packages" "java.lang*:java.util"
        -group "Extension Packages" "javax.*"
        java.lang java.lang.reflect java.util javax.servlet java.new

Core Packages java.lang.reflect Extension Packages javax.servlet Other Packages

-nodeprecated

Prevents the generation of any deprecated API in the documentation. This does what the -nodeprecatedlist option does, and it does not generate any deprecated API throughout the rest of the documentation. This is useful when writing code when you do not want to be distracted by the deprecated code.

-nodeprecatedlist

Prevents the generation of the file that contains the list of deprecated APIs (deprecated-list.html) and the link in the navigation bar to that page. The javadoc command continues to generate the deprecated API throughout the rest of the document. This is useful when your source code contains no deprecated APIs, and you want to make the navigation bar cleaner.

-nosince

-notree

Omits the class/interface hierarchy pages from the generated documents. These are the pages you reach using the Tree button in the navigation bar. The hierarchy is produced by default.

-noindex

Omits the index from the generated documents. The index is produced by default.

-nohelp

Omits the HELP link in the navigation bars at the top and bottom of each page of output.

-nonavbar

-helpfile path\filename

javadoc -helpfile C:\user\myhelp.html java.awt.

-stylesheet path\filename

Specifies the path of an alternate HTML stylesheet file. Without this option, the javadoc command automatically creates a stylesheet file stylesheet.css that is hard-coded in the javadoc command. This option lets you override the default. The file name can be any name and is not restricted to stylesheet.css, for example:

javadoc -stylesheet file C:\user\mystylesheet.css com.mypackage

-serialwarn

-charset name

For example, javadoc -charset "iso-8859-1" mypackage inserts the following line in the head of every generated page:

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

This META tag is described in the HTML standard (4197265 and 4137321), HTML Document Representation, at
https://www.w3.org/TR/REC-html40/charset.html#h-5.2.2

-docencoding name

If you omit the -docencoding option but use the -encoding option, then the encoding of the generated HTML files is determined by the -encoding option, for example: javadoc -docencoding "iso-8859-1" mypackage. See also the and options.

-keywords

Adds HTML keyword <META> tags to the generated file for each class. These tags can help search engines that look for <META> tags find the pages. Most search engines that search the entire Internet do not look at <META> tags, because pages can misuse them. Search engines offered by companies that confine their searches to their own website can benefit by looking at <META> tags. The <META> tags include the fully qualified name of the class and the unqualified names of the fields and methods. Constructors are not included because they are identical to the class name. For example, the class String starts with these keywords:

<META NAME="keywords" CONTENT="java.lang.String class">
<META NAME="keywords" CONTENT="CASE_INSENSITIVE_ORDER">
<META NAME="keywords" CONTENT="length()">
<META NAME="keywords" CONTENT="charAt()">

-tag tagname:Xaoptcmf:"taghead"

Enables the javadoc command to interpret a simple, one-argument @tagname custom block tag in documentation comments. For the javadoc command to spell-check tag names, it is important to include a -tag option for every custom tag that is present in the source code, disabling (with X) those that are not being output in the current run.The colon (:) is always the separator. The -tag option outputs the tag heading taghead in bold, followed on the next line by the text from its single argument. Similar to any block tag, the argument text can contain inline tags, which are also interpreted. The output is similar to standard one-argument tags, such as the @return and @author tags. Omitting a value for taghead causes tagname to be the heading.

Placement of tags: The Xaoptcmf arguments determine where in the source code the tag is allowed to be placed, and whether the tag can be disabled (using X). You can supply either a, to allow the tag in all places, or any combination of the other letters:

X (disable tag)

t (types, that is classes and interfaces)

c (constructors)

Examples of single tags: An example of a tag option for a tag that can be used anywhere in the source code is: -tag todo:a:"To Do:".

If you want the @todo tag to be used only with constructors, methods, and fields, then you use: -tag todo:cmf:"To Do:".

Notice the last colon (:) is not a parameter separator, but is part of the heading text. You would use either tag option for source code that contains the @todo tag, such as: @todo The documentation for this method needs work.

Colons in tag names: Use a backslash to escape a colon that you want to use in a tag name. Use the -tag ejb\\:bean:a:"EJB Bean:" option for the following documentation comment:

/**
 * @ejb:bean
 */

Spell-checking tag names: Some developers put custom tags in the source code that they do not always want to output. In these cases, it is important to list all tags that are in the source code, enabling the ones you want to output and disabling the ones you do not want to output. The presence of X disables the tag, while its absence enables the tag. This gives the javadoc command enough information to know whether a tag it encounters is unknown, which is probably the results of a typographical error or a misspelling. The javadoc command prints a warning in these cases. You can add X to the placement values already present, so that when you want to enable the tag, you can simply delete the X. For example, if the @todo tag is a tag that you want to suppress on output, then you would use: -tag todo:Xcmf:"To Do:". If you would rather keep it simple, then use this: -tag todo:X. The syntax -tag todo:X works even when the @todo tag is defined by a taglet.

Order of tags: The order of the -ta g and -taglet options determines the order the tags are output. You can mix the custom tags with the standard tags to intersperse them. The tag options for standard tags are placeholders only for determining the order. They take only the standard tag's name. Subheadings for standard tags cannot be altered. This is illustrated in the following example.If the -tag option is missing, then the position of the -tagle t option determines its order. If they are both present, then whichever appears last on the command line determines its order. This happens because the tags and taglets are processed in the order that they appear on the command line. For example, if the -taglet and -tag options have the name todo value, then the one that appears last on the command line determines the order.

Example of a complete set of tags: This example inserts To Do after Parameters and before Throws in the output. By using X, it also specifies that the @example tag might be encountered in the source code that should not be output during this run. If you use the @argfile tag, then you can put the tags on separate lines in an argument file similar to this (no line continuation characters needed):

-tag param
-tag return
-tag todo:a:"To Do:"
-tag throws
-tag see
-tag example:X

The standard tags are initially stored internally in a list in their default order. Whenever the -tag options are used, those tags get appended to this list. Standard tags are moved from their default position. Therefore, if a -tag option is omitted for a standard tag, then it remains in its default position.

Avoiding conflicts: If you want to create your own namespace, then you can use a dot-separated naming convention similar to that used for packages: com.mycompany.todo. Oracle will continue to create standard tags whose names do not contain dots. Any tag you create will override the behavior of a tag by the same name defined by Oracle. If you create a @todo tag or taglet, then it always has the same behavior you define, even when Oracle later creates a standard tag of the same name.

Annotations vs. Javadoc tags: In general, if the markup you want to add is intended to affect or produce documentation, then it should be a Javadoc tag. Otherwise, it should be an annotation. See Custom Tags and Annotations in How to Write Doc Comments for the Javadoc Tool at
https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#annotations

You can also create more complex block tags or custom inline tags with the -taglet option.

-taglet class

Specifies the class file that starts the taglet used in generating the documentation for that tag. Use the fully qualified name for the class value. This taglet also defines the number of text arguments that the custom tag has. The taglet accepts those arguments, processes them, and generates the output. For extensive documentation with example taglets, see: Taglet Overview at
https://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/taglet/overview.html

-taglet com.sun.tools.doclets.ToDoTaglet
-tagletpath /home/taglets
-tag return
-tag param
-tag todo
-tag throws
-tag see

-tagletpath tagletpathlist

-docfilesubdirs

Enables deep copying of doc-files directories. Subdirectories and all contents are recursively copied to the destination. For example, the directory doc-files/example/images and all of its contents would be copied. There is also an option to exclude subdirectories.

-excludedocfilessubdir name1:name2

Excludes any doc-files subdirectories with the specified names. This prevents the copying of SCCS and other source-code-control subdirectories.

-noqualifier all | packagename1:packagename2...

Omits qualifying package names from class names in output. The argument to the -noqualifier option is either all (all package qualifiers are omitted) or a colon-separate list of packages, with wild cards, to be removed as qualifiers. The package name is removed from places where class or interface names appear. See Process Source Files.

The following example omits all package qualifiers: -noqualifier all.

Where a package qualifier would appear due to the previous behavior, the name can be suitably shortened. See How a Name Appears. This rule is in effect whether or not the -noqualifier option is used.

-notimestamp

-nocomment

Suppresses the entire comment body, including the main description and all tags, and generate only declarations. This option lets you reuse source files that were originally intended for a different purpose so that you can produce skeleton HTML documentation at the early stages of a new project.

-sourcetab tablength

Specifies the number of spaces each tab uses in the source.

# data[].attributes.attachment_link.description
This document contains reference information for the tools that are installed with Java Development Kit (JDK).

# data[].attributes.body
Enunciado con la tarea que tenéis que desarrollar utilizando el lenguaje Java y el IDE Netbeans.