1. J2EE
Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2
Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de
programación—parte de la Plataforma Java—para desarrollar y ejecutar software
de aplicaciones en Lenguaje de programación Java con arquitectura de N niveles
distribuida, basándose ampliamente en componentes de software modulares
ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está
definida por una especificación. Similar a otras especificaciones del Java
Community Process, Java EE es también considerada informalmente como un
estándar debido a que los suministradores deben cumplir ciertos requisitos de
conformidad para declarar que sus productos son conformes a Java EE;
estandarizado por The Java Community Process / JCP.
Java EE incluye varias especificaciones de API, tales como JDBC, RMI, e-mail,
JMS, Servicios Web, XML, etc y define cómo coordinarlos. Java EE también
configura algunas especificaciones únicas para Java EE para componentes. Estas
incluyen Enterprise JavaBeans, servlets, portlets (siguiendo la especificación de
Portlets Java), JavaServer Pages y varias tecnologías de servicios web. Esto
permite al desarrollador crear una Aplicación de Empresa portable entre
plataformas y escalable, a la vez que integrable con tecnologías anteriores. Otros
beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede
manejar transacciones, la seguridad, escalabilidad, concurrencia y gestión de los
componentes desplegados, significando que los desarrolladores pueden
concentrarse más en la lógica de negocio de los componentes en lugar de en
tareas de mantenimiento de bajo nivel.
La especificación original J2EE fue desarrollada por Sun Microsystems.
Comenzando con J2EE 1.3, la especificación fue desarrollada bajo el Java
Community Process. JSR 58 especifica J2EE 1.3 y JSR 151 especifica J2EE 1.4.
El SDK de J2EE 1.3 fue distribuida inicialmente como beta en abril de 2001. La
beta del SDK de J2EE 1.4 fue distribuida por Sun en diciembre de 2002.
La especificación Java EE 5 fue desarrollada bajo el JSR 244 y el lanzamiento
final se hizo el 11 de mayo de 2006.

2. J2SE
Java Platform, Standard Edition o Java SE (conocido anteriormente hasta la
versión 5.0 como Plataforma Java 2, Standard Edition o J2SE), es una colección
de APIs del lenguaje de programación Java útiles para muchos programas de la
Plataforma Java. La Plataforma Java 2, Enterprise Edition incluye todas las clases
en el Java SE, además de algunas de las cuales son útiles para programas que se
ejecutan en servidores sobre workstations.
Comenzando con la versión J2SE 1.4 (Merlin), la plataforma Java SE ha sido
desarrollada bajo la supervisión del Java Community Process. JSR 59 la
especificación para J2SE 1.4 y JSR 176 especificó J2SE 5.0 (Tiger). En 2006,
Java SE 6 (Mustang) está siendo desarrollada bajo el JSR 270.
Lo siguiente son descripciones de algunos de los principales paquetes Java SE.
 java.applet
Creado para soportar la creación de applet Java, el paquete java.applet permite a
las aplicaciones ser descargadas sobre una red y ejecutarse dentro de una
sandbox. Las restricciones de seguridad son impuestas fácilmente en la sandbox.
Un desarrollador, por ejemplo, puede aplicar una firma digital a un applet, en
consecuencia etiquetándola como segura. Haciéndolo permite al usuario conceder
permiso al applet para realizar operaciones restringidas (tales como acceder al
disco duro local), y elimina alguna o todas las restricciones de la sandbox. Los
certificados digitales son emitidos por agencias como Thawte o Entrust.
 java.beans
Incluidos en el paquete java.beans hay varias clases para desarrollar y manipular
beans, componentes reutilizables definidos por la arquitectura JavaBeans. La
arquitectura suministra mecanismos para manipular propiedades de componentes
y lanzar eventos cuando esas propiedades cambian. La mayoría de las APIs en
java.beans están pensadas para su uso en herramientas de edición de beans, en
la cual los beans puedan combinarse, personalizarse y manipularse. Un tipo de
editor bean es el diseñador GUI en un entorno de desarrollo integrado(IDE).
 java.awt
La Abstract Window Toolkit contiene rutinas para soportar operaciones básicas
GUI y utiliza ventanas básicas desde el sistema nativo subyacente. Muchas
implementaciones independientes de la API Java implementan todo excepto AWT,
el cual no es usado por la mayoría de las aplicaciones de lado de servidor. Este
paquete también contiene la API de gráficos Java 2D.

3.  java.rmi
El paquete java.rmi suministra invocación a métodos remotos Java para soportar
llamadas a procedimientos remotos entre dos aplicaciones Java que se ejecutan
en diferentes JVM. Esto es esencial para tener en cuenta en la certificación
 java.security
Soporte para seguridad, incluyendo el algoritmo de resumen de mensaje, está
incluido en el paquete java.security.
 java.sql
Una implementación de la API JDBC (usada para acceder a bases de datos SQL)
se agrupa en el paquete java.sql.
 javax.rmi
suministra el soporte para la comunicación remota entre aplicaciones, usando el
protocolo RMI sobre IIOP. Este protocolo combina características de RMI y
CORBA.
 org.omg.CORBA
Suministra el soporte para comunicación remota entre aplicaciones usando
general inter ORB protocol y soporta otras características de common object
request broker architecture. Igual que RMI y RMI-IIOP, este paquete es para
llamar métodos remotos de objetos en otras máquinas virtuales (normalmente por
la red). De todas las posibilidades de comunicación CORBA es la más portable
entre varios lenguajes. Sin embargo es también un poco difícil de comprender.
 javax.swing
Swing es una colección de rutinas que se construyen sobre java.awt para
suministrar un toolkit de widgets independiente de plataforma. Swing usa las
rutinas de dibujado 2D para renderizar los componentes de interfaz de usuario en
lugar de confiar en el soporte GUI nativo subyacente del Sistema operativo.
Swing es un sistema muy rico por sí mismo, soportando pluggable looks and feels
(PLAFs) para que los controles(widgets) en la GUI puedan imitar a aquellos del
sistema nativo subyacente. Los patrones de diseño impregnan el sistema,
especialmente una modificación del patrón modelo-vista-controlador, el cual afloja
el acoplamiento entre función y apariencia. Una inconsistencia es que (para J2SE
1.3) las fuentes son dibujadas por el sistema nativo subyacente, limitando la
portabilidad de texto. Mejoras, tales como usar fuentes de mapas de bits, existen.
En general, las layouts(disposiciones de elementos) se usan y mantienen los
elementos dentro de una GUI consistente a través de distintas plataformas.

4.  javax.swing.text.html.parser
Suministra el parser de HTML tolerante a errores que se usa para escribir varios
navegadores web y web bots.
J2ME
La plataforma Java Micro Edition, o anteriormente Java 2 Micro Edition(J2ME), es
una especificación de un subconjunto de la plataforma Java orientada a proveer
una colección certificada de APIs de desarrollo de software para dispositivos con
recursos restringidos. Está orientado a productos de consumo como PDAs,
teléfonos móviles o electrodomésticos.
Java ME se ha convertido en una buena opción para crear juegos en teléfonos
móviles debido a que se puede emular en un PC durante la fase de desarrollo y
luego subirlos fácilmente al teléfono. Al utilizar tecnologías Java el desarrollo de
aplicaciones o videojuegos con estas APIs resulta bastante económico de portar a
otros dispositivos.
JRE
También conocido como JRE, es un conjunto de utilidades que permite la
ejecución de programas Java. En su forma más simple, el entorno en tiempo de
ejecución de Java está conformado por una Máquina Virtual de Java o JVM, un
conjunto de bibliotecas Java y otros componentes necesarios para que una
aplicación escrita en lenguaje Java pueda ser ejecutada. El JRE actua como un
"intermediario" entre el sistema operativo y Java.
La JVM es el programa que interpreta el código Java mientras que las librerias de
clases estándar son las que implementan el API de Java. Ambas JVM y API deben
ser consistentes entre sí, de ahí que sean distribuidas de modo conjunto.
Un usuario sólo necesita el JRE para ejecutar las aplicaciones desarrolladas en
lenguaje Java, mientras que para desarrollar nuevas aplicaciones en dicho
lenguaje es necesario un entorno de desarrollo, denominado JDK, que además del
JRE (mínimo imprescindible) incluye, entre otros, un compilador para Java.

5. JVM
Una Máquina virtual Java (en inglés Java Virtual Machine, JVM) es un máquina
virtual de proceso nativo, es decir, ejecutable en una plataforma específica, capaz
de interpretar y ejecutar instrucciones expresadas en un código binario especial (el
Java bytecode), el cual es generado por el compilador del lenguaje Java.
El código binario de Java no es un lenguaje de alto nivel, sino un verdadero código
máquina de bajo nivel, viable incluso como lenguaje de entrada para un
microprocesador físico. Como todas las piezas del rompecabezas Java, fue
desarrollado originalmente por Sun Microsystems.
La JVM es una de las piezas fundamentales de la plataforma Java. Básicamente
se sitúa en un nivel superior al Hardware del sistema sobre el que se pretende
ejecutar la aplicación, y este actúa como un puente que entiende tanto el
bytecode, como el sistema sobre el que se pretende ejecutar. Así, cuando se
escribe una aplicación Java, se hace pensando que será ejecutada en una
máquina virtual Java en concreto, siendo ésta la que en última instancia convierte
de código bytecode a código nativo del dispositivo final.
La gran ventaja de la máquina virtual java es aportar portabilidad al lenguaje de
manera que desde Sun Microsystems se han creado diferentes máquinas virtuales
java para diferentes arquitecturas y así un programa .class escrito en un Windows
puede ser interpretado en un entorno Linux. Tan solo es necesario disponer de
dicha máquina virtual para dichos entornos. De ahí el famoso axioma que sigue a
Java, "escríbelo una vez, ejecútalo en cualquier parte", o "Write once, run
anywhere".
Pero, los intentos de la compañía propietaria de Java y productos derivados de
construir microprocesadores que aceptaran el Java bytecode como su lenguaje de
máquina fueron más bien infructuosos.
La máquina virtual de Java puede estar implementada en software, hardware, una
herramienta de desarrollo o un Web browser; lee y ejecuta código precompilado
bytecode que es independiente de la plataforma multiplataforma. La JVM provee
definiciones para un conjunto de instrucciones, un conjunto de registros, un
formato para archivos de clases, la pila, un heap con recolector de basura y un
área de memoria. Cualquier implementación de la JVM que sea aprobada por
SUN debe ser capaz de ejecutar cualquier clase que cumpla con la especificación.
Existen varias versiones, en orden cronológico, de la máquina virtual de Java. En
general la definición del Java bytecode no cambia significativamente entre
versiones, y si lo hacen, los desarrolladores del lenguaje procuran que exista
compatibilidad hacia atrás con los productos anteriores.
A partir de J2SE 5.0, los cambios en la especificación de la JVM han sido
desarrollados bajo el auspicio de la Java Community Process (JCP) y especificada
en la JSR 924.[1] Desde el año 2006, cambios en la especificación para soportar
las modificaciones del formato del fichero de clases (JSR 202[2] ) se están

6. llevando a cabo en una versión de mantenimiento en la JSR 924. Las
especificaciones para la JVM están publicadas en lo que se conoce como "el libro
azul".[3] Así reza el prefacio: Esperamos que esta especificación documente
suficientemente la Máquina Virtual de Java para hacer posibles implementaciones
desde cero. Sun proporciona tests que verifican que las implementaciones de la
Máquina Virtual de Java opere correctamente
Kaffe es un ejemplo de una implementación de JVM desde cero. Sun es la
propietaria de la marca registrada "Java", que usa para certificar aquellas
implementaciones que se ajustan y son totalmente compatibles con sus
especificaciones.
Bytes Code.
El bytecode es un código intermedio más abstracto que el código máquina.
Habitualmente es tratado como un fichero binario que contiene un programa
ejecutable similar a un módulo objeto, que es un fichero binario producido por el
compilador cuyo contenido es el código objeto o código máquina .
El bytecode recibe su nombre porque usualmente cada código de operación tiene
una longitud de un byte, si bien la longitud del código de las instrucciones varía.
Cada instrucción tiene un código de operación entre 0 y 255 seguido de
parámetros tales como los registros o las direcciones de memoria. Esta sería la
descripción de un caso típico, si bien la especificación del bytecode depende
ampliamente del lenguaje.
Como código intermedio, se trata de una forma de salida utilizada por los
implementadores de lenguajes para reducir la dependencia respecto del hardware
específico y facilitar la interpretación. Menos frecuentemente se utiliza el bytecode
como código intermedio en un compilador. Algunos sistemas, llamados traductores
dinámicos o compiladores just-in-time traducen el bytecode a código máquina
inmediatamente antes de su ejecución para mejorar la velocidad de ejecución.
Los programas en bytecode suelen ser interpretados por un intérprete de bytecode
(en general llamado máquina virtual, dado que es análogo a un ordenador). Su
ventaja es su portabilidad: el mismo código binario puede ser ejecutado en
diferentes plataformas y arquitecturas. Es la misma ventaja que presentan los
lenguajes interpretados. Sin embargo, como el bytecode es en general menos
abstracto, más compacto y más orientado a la máquina que un programa pensado
para su modificación por humanos, su rendimiento suele ser mejor que el de los
lenguajes interpretados. A causa de esa mejora en el rendimiento, muchos
lenguajes interpretados, de hecho, se compilan para convertirlos en bytecode y
después son ejecutados por un intérprete de bytecode. Entre esos lenguajes se

7. encuentran Perl, PHP y Python. El código Java se suele trasmitir como bytecode a
la máquina receptora, que utiliza un compilador just-in-time para traducir el
bytecode en código máquina antes de su ejecución.
Son asimismo interesantes los denominados p-Codes, similares a bytecodes pero
cuyos códigos de operación pueden constar de más de un byte y pueden ser
variables en tamaño, como los opcodes de muchas CPUs. Estos códigos trabajan
a muy alto nivel, incluyendo instrucciones del estilo de «imprime esta cadena» o
«borra la pantalla». Por ejemplo, BASIC utiliza p-Codes.
Garbage Collection
Un recolector de basura (del inglés, garbage collector) es un mecanismo implícito
de gestión de memoria implementado en algunos lenguajes de programación de
tipo interpretado o semi-interpretado.
Cuando un lenguaje dispone de recolección de basura, el programador no tiene
que invocar a una subrutina para liberar memoria. La reserva de memoria también
es más o menos automática sin la intervención del programador. Por ejemplo:
En los lenguajes orientados a objetos: se reserva memoria cada vez que el
programador crea un objeto, pero éste no tiene que saber cuanta memoria se
reserva ni cómo se hace esto.
En los lenguajes declarativos: cada vez que se construye una expresión se
reserva memoria (de una manera inteligente), pero el programador no es
consciente de ello.
Cuando se compila el programa, automáticamente se incluye en éste una
subrutina correspondiente al recolector de basura. Esta subrutina también es
invocada periódicamente sin la intervención del programador.
El recolector de basura es informado de todas las reservas de memoria que se
producen en el programa. Además, el compilador colabora para que sea posible
llevar una cuenta de todas las referencias que existen a un determinado espacio
de memoria reservado.
Cuando se invoca el recolector de basura, recorre la lista de espacios reservados
observando el contador de referencias de cada espacio. Si un contador ha llegado
a cero significa que ese espacio de memoria ya no se usa y, por tanto, puede ser
liberado.
Naturalmente, este proceso consume un cierto tiempo en el que no se hace nada
verdaderamente útil para el propósito del programa. Por tanto, no puede ser
invocado con demasiada frecuencia.

8. En consecuencia, el único inconveniente a este mecanismo es determinar cuándo
se tiene que ejecutar el recolector de basura. Existen varios algoritmos para
hacerlo, pero el más eficiente es el primero de ellos:
Esperar a que no quede memoria libre, y entonces, ejecutar el recolector de
basura.
Fijar un umbral de ocupación de la memoria libre y ejecutar el recolector de basura
cuando se supere dicho umbral.
Ejecutar el recolector de basura a intervalos regulares (no siempre es posible).
Ejecutar el recolector de basura justo antes de cada reserva de memoria.
Permitir al programador que invoque explícitamente al recolector de basura
cuando quiera.
SDK
Un kit de desarrollo de software o SDK (siglas en inglés de software development
kit) es generalmente un conjunto de herramientas de desarrollo que le permite a
un programador crear aplicaciones para un sistema concreto, por ejemplo ciertos
paquetes de software, frameworks, plataformas de hardware, computadoras,
videoconsolas, sistemas operativos, etc.
Es algo tan sencillo como una interfaz de programación de aplicaciones o API (del
inglés application programing interface) creada para permitir el uso de cierto
lenguaje de programación, o puede, también, incluir hardware sofisticado para
comunicarse con un determinado sistema embebido. Las herramientas más
comunes incluyen soporte para la detección de errores de programación como un
entorno de desarrollo integrado o IDE (del inglés Integrated Development
Environment) y otras utilidades. Los SDK frecuentemente incluyen, también,
códigos de ejemplo y notas técnicas de soporte u otra documentación de soporte
para ayudar a clarificar ciertos puntos del material de referencia primario.
Los SDK como técnica de Marketing
Un programador suele recibir el SDK del desarrollador del sistema para el que se
está escribiendo el programa. Incluso, a veces el SDK puede descargarse de
Internet. De hecho, muchos SDKs se distribuyen gratuitamente para animar a los
desarrolladores a usar el sistema o el lenguaje. Así pues podemos deducir que a
veces son usados como herramientas de marketing, por ejemplo, Foo Products
distribuye el Widget SDK gratis para animar a la gente a utilizarlo. En
consecuencia mucha gente se anima a comprar muchos otros widgets suyos ya
que pueden programarlos gratuitamente.

9. Los proveedores de SDK para ciertos sistemas o subsistemas pueden utilizar un
término más específico que el de "software". Por ejemplo, tanto Microsoft como
Apple proveen Driver Development Kits (DDK) o kits para el desarrollo de drivers
para desarrollar drivers para dispositivos, y PalmSource distribuye su propio kit de
desarrollo como el PalmOS Development Kit (PDK) o kit de desarrollo para
PalmOS.