Asociación Profesional del Cuerpo Superior

de Sistemas y Tecnologías de la Información

de la Administración del Estado

Temas Específicos para la preparación de la Oposición al Cuerpo

Superior de Sistemas y Tecnologías de la Información de la
Administración del Estado.

TEMAS ESPECÍFICOS II: Tecnología básica.

60. Entorno de desarrollo Java para software con distribución

AUTOR: : Gonzalo Agudo del Barrio

Actualizado 2014

1
60. Entorno de desarrollo Java para software con distribución
INDICE
060.1 Notas del autor .............................................................................................................. 2
060.2 Introducción ................................................................................................................... 3
060.2.1 ¿Qué es Java: lenguaje de programación, plataforma o ambas cosas? .................. 3
060.2.2 Los entornos de desarrollo y ejecución Java ............................................................ 4
060.2.3 De Java 1.0 a Java 8 ................................................................................................. 5
060.3 Empaquetado de aplicaciones ...................................................................................... 8
060.4 Distribución manual o tradicional .................................................................................. 9
060.5 Distribución de software mediante applets ................................................................. 10
060.6 Distribución de aplicaciones mediante WebStart ........................................................ 11
060.7 Java Plug-in ................................................................................................................. 12
060.8 Ejecución de aplicaciones nativas ............................................................................... 14
060.8.1 Compiladores nativos de Java ................................................................................ 14
060.9 Interfaces de programación para entornos de ventanas ............................................ 15
060.9.1 AWT (Abstract Window Toolkit) .............................................................................. 15
060.9.2 Swing ....................................................................................................................... 15
060.9.3 SWT (Standard Widget Toolkit) y JFace ................................................................. 16
060.9.4 JavaFX .................................................................................................................... 17
060.10 Principales librerías ..................................................................................................... 18
060.10.1 Lang y Util ................................................................................................................ 18
060.10.2 Sistema de entrada/salida: librerías io y nio. .......................................................... 18
060.10.3 Acceso a bases de datos: JDBC (Java Database Connectivity)............................. 19
060.10.4 JNDI (Java Naming and Directory Interface)........................................................... 20
060.10.5 JNI (Java Native Interface) ...................................................................................... 20
060.10.6 JAXP (Java API for XML Processing) ..................................................................... 20
060.11 Cuestiones sobre seguridad ........................................................................................ 21
060.12 Entornos de desarrollo integrado (IDEs) Java ............................................................ 21
060.13 Casos de éxito en la Administración General del Estado ........................................... 22
060.14 Bibliografía ................................................................................................................... 24

60.1 Notas del autor

Se recomienda leer este tema y el tema 116 Arquitectura de desarrollo en la web (III).
Tecnología Java, juntos y por este orden para tener una idea general del entorno de desarrollo
Java.

Ambos temas no pretenden ser una guía técnica y detallada de todo lo que rodea a Java sino
una visión general y actualizada del contexto actual en el que se encuentra la tecnología Java.
Se pretende explicar los términos, nombres y productos más importantes relacionados con el
mundo Java. No se profundiza en el lenguaje de programación en sí, ya que no es el alcance
de estos temas.

2
60. Entorno de desarrollo Java para software con distribución
La revisión de septiembre de 2014 parte de la base del tema anterior elaborado por Antonio
Carrasco Grande. Se ha actualizado el tema con las últimas novedades, tratando de no
cambiar radicalmente su redacción (para beneficio del opositor) sino completar ciertos
apartados y ampliar otros nuevos con las principales novedades.

60.2 Introducción

60.2.1 ¿Qué es Java: lenguaje de programación, plataforma o ambas

cosas?
El término Java en la actualidad no se utiliza solo para referirse al lenguaje de programación
original sino que se emplea también para referirse a toda una Plataforma. Oracle (actual
propietario de Java) define Java como un lenguaje de programación y una Plataforma (separa
por decir así la existencia del lenguaje de programación y de la Plataforma si bien deben de
convivir juntas el uno de la otra).

Podemos definir la Plataforma Java (Java Platform) como un conjunto de tecnologías

(servidores, aplicaciones, especificaciones y librerías o APIs) que permiten desarrollar y
ejecutar aplicaciones desarrolladas con el lenguaje de programación Java.

Oracle ha diseñado diferentes ediciones de la Plataforma Java (se suele utilizar también el
término 3 plataformas):

- Java Platform, Standard Edition (Java SE): permite desarrollar y desplegar

aplicaciones Java para su ejecución en diferentes máquinas.

- Java Platform, Enterprise Edition (Java EE): permite desarrollar y ejecutar

aplicaciones Java en arquitectura de N capas distribuidas.

- Java Platform, Micro Edition (Java ME): permite desarrollar y ejecutar aplicaciones
en dispositivos con recursos restringidos como teléfonos móviles, electrodomésticos
etc. No se debe de confundir con el término Embedded Java o Java embebido. Este
término hace referencia a aplicaciones embebidas en memorias, las cuales pueden
haberse desarrollado tanto en Java ME como en Java SE.

3
60. Entorno de desarrollo Java para software con distribución
En la imagen anterior vemos, de forma orientativa, como J2EE “expande” a J2SE, mientras que
J2ME “recorta” a J2SE al tiempo que tiene una fracción de contenido diferenciada exclusiva de
J2ME (notar que la terminología utilizada en la imagen es la anterior ya que ahora no se utiliza
J2EE sino Java EE así como Java SE y Java ME en lugar de J2SE y J2ME). En realidad hablar
de expansiones y recortes no es correcto, porque cada distribución es en sí misma distinta
puesto que están concebidas con distintas finalidades. Por tanto no puede decirse que sean
expansiones o recortes, pero de forma coloquial muchas veces se interpreta así.

En este tema se verán los principales aspectos de Java SE enfocándonos en la distribución de

software en máquinas cliente (de usuario) mientras que en el tema 116 se verá las edición Java
EE orientada a aplicaciones web sin necesidad de instalación de Java en cliente (se ejecutan
en el servidor).

Como se remarca en la propia definición de la Plataforma Java, hay dos entornos bien
diferenciados en Java, el entorno de desarrollo y el entorno de ejecución el cual se explican a
continuación.

60.2.2 Los entornos de desarrollo y ejecución Java

Java como lenguaje de programación es un lenguaje:
 de propósito general: puede ser usado para varios propósitos como aplicaciones
varias, sistemas operativos etc.
 de alto nivel: su programación se abstrae de los detalles de la máquina donde se va a
ejecutar.
 orientado a objetos: se programan objetos para representar y modelar los datos del
negocio.
 compilado e interpretado: todo programa debe compilarse, generando un bytecode el
cual es interpretado en una máquina virtual.
 fuertemente tipado: no se permiten violaciones de los tipos de datos.

Pero como ya hemos dicho Java no es un simple lenguaje de programación: es también un

entorno de ejecución que se ve influido por una filosofía de desarrollo determinada y las
decisiones que se tomaron durante su diseño. Java nació en 1991 cuando un grupo de
ingenieros de Sun Microsystems diseñaban un nuevo lenguaje de programación para sistemas
empotrados. El objetivo fundamental de los ingenieros de Sun liderados por James Gostling era
crear un lenguaje genérico que permitiese desarrollar programas que pudieran ejecutarse en
cualquier sistema, con independencia de la CPU. Se quería huir del problema producido por el
entorno tecnológico y los continuos cambios de CPU que obligaban a reprogramar todas las
aplicaciones. Por ello, se diseñó un entorno basado en un lenguaje de alto nivel que al
compilarse no generara código máquina para una CPU concreta sino un código binario
intermedio que posteriormente se interpretara en cada CPU en lo que se denominó una
máquina virtual Java o JVM (Java Virtual Machine).

Si bien es cierto que Java se ha conocido desde sus inicios por la frase “programar una vez,
ejecutar en cualquier parte” (WORA Write Once Run Anywhere), también es cierto que, debido
a la propia evolución del entorno, hoy por hoy, esto sólo es cierto cuando se cumplen ciertas
restricciones en cuanto a la compatibilidad entre el entorno de desarrollo utilizado y la máquina
virtual instalada en las plataformas en las que se requiere ejecutar el código objeto generado
(“bytecode”). Estos posibles problemas a la hora de la ejecución de un programa vienen
derivados de la utilización de librerías con diferentes versiones que forman parte del propio
lenguaje (la API de Java) o de extensiones a esta API desarrolladas por empresas o por el
propio desarrollador. Por ello, y aunque, como veremos existe una solución para estos
problemas, el estudio de las tecnologías que envuelven el desarrollo y la distribución de
aplicaciones Java es una cuestión que merece cierta consideración técnica.

Históricamente, cada entorno de desarrollo Java (JDK - Java Development Kit) ha tenido un
entorno de ejecución Java (JRE – Java RuntimeEnvironment) asociado. Un producto de
software desarrollado con un JDK determinado necesita, por lo general, un JRE equivalente o

4
60. Entorno de desarrollo Java para software con distribución
superior para poder ser ejecutado en la máquina destino. Además, en ocasiones se ha roto la
compatibilidad hacia atrás para determinadas clases de la biblioteca, al quedar definitivamente
obsoletos los métodos o las clases previamente marcados como deprecated. Esto implica que
determinados productos creados con un JDK concreto no pueden ser ejecutados en un entorno
de ejecución de fecha posterior.

Este hecho no ha supuesto un problema insalvable ya que en una máquina pueden coexistir
dos o más entornos de ejecución diferentes.

60.2.3 De Java 1.0 a Java 8

En este apartado vamos a ver las principales características de cada versión de Java desde la
versión JDK 1.0 a la versión más reciente disponible para los desarrolladores JDK 8u20 (de
septiembre de 2014), si bien la última versión disponible para la descarga por el público general
es la JDK 7u67. Las últimas versiones se ponen siempre primero a disposición de los
desarrolladores para dar tiempo suficiente para realizar las pruebas y certificaciones antes de
que esté disponible para su descarga en el sitio web java.com. No es de interés repasar en
detalle todas y cada una sino mencionar las principales novedades introducidas en cada
versión y ver más en detalle la versión actual.

El primer entorno de desarrollo utilizado de forma masiva fue Java 1.0. Este entorno estaba
compuesto por el JDK 1.0 y por el JRE asociado. Java 1.0 proporcionó un marco de trabajo
básico para el desarrollo con Java, así como una API gráfica para el desarrollo de aplicaciones
y applets (componente Java incorporado en una página web html). En realidad, desde una
perspectiva actual, esta primera versión de Java tiene un interés fundamentalmente histórico ya
que el JDK1.0/JRE1.0 tenía importantes limitaciones. Por ello, se hubo de esperar hasta la
siguiente versión del JDK para que el producto tuviera las características que le convirtieron en
un entorno de desarrollo productivo para aplicaciones reales. El lenguaje en sí mismo toma
mucha de su sintaxis de Visual Basic, pero tiene un modelo de objetos más simple y elimina
herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa
de punteros o memoria así como la incorporación del garbagecollector o recollector de basura.

En 1998 el entorno Java entró en una nueva era: Java 1.2 o Java 2. En Java 2 la interfaz
1
gráfica de usuario estándar pasó a ser Swing y se crearon las Java FoundationClasses.
También se incorporaron características como la conectividad con bases de datos, la
invocación remota de métodos para objetos distribuidos, un nuevo modelo de seguridad que
permitía acceso controlado a los recursos del sistema y una API criptográfica, una API para
manejo de gráficos en 2D, soporte para la internacionalización, colecciones, soporte para
arrastrar y soltar. Se puede decir que el salto a Java 2 supuso la consagración de Java como
un modelo de desarrollo maduro y moderno.

Desde el punto de vista de la distribución de aplicaciones el paso a Java 2 también supuso un

cambio de modelo: a partir de la entrada en el mercado de Java 2, la versión del entorno de
ejecución de Java se independizó del navegador asociado de forma que un cambio en el
navegador no afectase a los entornos de Java instalados y a la inversa, una instalación de un
nuevo entorno no implicase la actualización del navegador. La tecnología utilizada
(denominada conexión de Java o Java Plug-In) permitió además la posibilidad de tener
distintos entornos de ejecución para tener un mayor control sobre las distribuciones de los
distintos productos.

JDK 1.3 (2000) incorporó mejoras notables de rendimiento, a la vez que amplió y mejoró
notablemente la interfaz de programacióngráfica Swing y las facilidades para la programación
distribuida.

1
Aunque AWT se mantuvo y se siguió mejorando para garantizar la compatibilidad hacia atrás de miles de
applets que habían sido desarrollados para esta API gráfica.

5
60. Entorno de desarrollo Java para software con distribución
Desde el punto de vista de la distribución, la versión 1.3 mejoró el mecanismo de
almacenamiento intermedio de applets y clases de soporte. También incorporó la indexación de
paquetes que permite la descarga selectiva de paquetes para la ejecución de applets.

JDK 1.4 (2002) incorpora las aserciones, la encapsulación de excepciones, tratamiento de

expresiones regulares así como nuevas funcionalidades tanto en el lado del servidor: con la
definitiva introducción de XML, el soporte para arquitecturas de 64 bits, operaciones de entrada
salida escalables, mejoras en las APIs de seguridad y otras características como la aceleración
de gráficos 2D, extensiones de autenticación y autorización, soporte para comunicaciones
seguras, soporte para Kerberos, etc.

Desde el punto de vista de la distribución, el JDK 1.4 incorporó finalmente la tecnología

Webstart (que ya se había lanzado durante JDK 1.3, aunque como un producto independiente)
lo que convirtió a Java en un entorno de desarrollo adaptado a la distribución de aplicaciones
de forma centralizada y transparente, al margen de los navegadores y las tecnologías.
Dedicaremos un apartado exclusivo a Java Web Start.

JDK 5.0 (2004) introduce genéricos, anotaciones, datos enumerados, número de argumentos
variables etc.

JDK 6 (2006) se dota de APIs para soportar servicios web, API para el compilador, mejoras en
la interfaz gráfica.

En 2010 Oracle compró SUN Mycrosystems haciéndose cargo entre otros de la tecnología
Java así como del sistema operativo Solaris.

JDK 7 (2011) incorpora Strings en Switchs, multicatch, operador diamante <> así como
sustanciales mejoras de seguridad siendo su última versión 7u67.

Java 8 se lanza en marzo de 2014 y como principales novedades incorpora de forma completa
la librería JavaFX. A la fecha de la redacción de este tema la última versión es la JDK 8u20.
Todavía no está extendido su uso y desarrollo en la actualidad pero conviene nombrarla ya que
es el futuro a corto plazo de Java.

Como se comentó anteriormente la plataforma Java (en este tema hablamos de la edición SE)
es un conjunto de tecnologías que permiten desarrollar y ejecutar aplicaciones programadas en
Java. Para cada edición de la plataforma hay un JDK, un JRE, documentación, test de prueba,
ejemplos y especificaciones.

Un JDK contiene todo lo que contiene un JRE y además herramientas como compiladores y
depuradores de errores (debuggers) necesarias para desarrollar applets y aplicaciones. Un
JRE proporciona las librerías, la JVM y otros componentes para ejecutar applets y aplicaciones
escritas en lenguaje de programación Java. Es importante mencionar que un JRE incluye
componentes que no cumplen una especificación Java SE junto con otros componentes que sí
cumplen con dichas especificaciones (JSR – Java SpecificationRequest).

En el siguiente diagrama conceptual se muestran los componentes de la Java Platform,

Standard Edition actuales y se explicarán en los siguientes apartados los más importantes.

6
60. Entorno de desarrollo Java para software con distribución
Como vemos en la imagen los componentes Java SE se categorizan en niveles. El JDK
contiene todos los niveles, mientras que el JRE contiene los niveles de despliegue,
herramientas de interfaz de usuario, librerías de integración, otras librerías base, librerías base
lang y útil y la JVM.

A la derecha de la imagen se puede identificar hasta donde abarca la Java SE API. La parte de
arriba de las APIs (JavaFx, Java Web Start, Java Plug-in, herramientas) y la parte de abajo
(JVM) es propiedad de Oracle y es Oracle la encargada de su desarrollo y mantenimiento (en
consecuencia Oracle puede estimar o desestimar su desarrollo cuando quiera). Sin embargo
las APIs están basadas en especificaciones JSR (Java SpecificationRequest) las cuales son
aprobadas dentro del Java CommunityProcess (JCP). El JCP es un proceso formalizado que
permite a las diferentes partes de la industria involucradas (empresas importantes del sector)
participar en la definición de especificaciones JSR (que se traducen en APIs que cumplen
dichas especificaciones) para que sean aceptadas en la Plataforma Java. Estas
especificaciones garantizan el futuro tecnológico de Java.

Existe el proyectoOpenJDK el cual consiste en una implementación de software libre y abierto

de la Java Platform SE, si bien no incluye Java Web Start ni Java Plug-in. Está basado en tres
componentes principales: una máquina virtual, un compilador y todas las APIs que
implementan las especificaciones JSR.

Como hemos visto hasta ahora, los programas Java no son tan portables como sería de
desear. Y esto es, frecuentemente, con independencia de que hayamos utilizado tecnología
puramente Java y conforme al estándar. Según el nivel del entorno de desarrollo que hayamos
utilizado, la distribución puede ser más o menos complicada. En cualquier caso, el mantra Java
“programe una vez, ejecute en todas partes” sigue siendo una utopía, por lo que, cuando
estemos en la fase de análisis y desarrollo seguiremos teniendo que anticipar el entorno en el
que serán instaladas o ejecutadas las aplicaciones finalmente.

7
60. Entorno de desarrollo Java para software con distribución
Oracle Java SE no funciona en todos los sistemas operativos ni en todos los navegadores si
bien como se puede ver en la siguiente lista está soportada un gran porcentaje de la industria:

- Sistemas operativos soportados: Solaris, Windows (Vista, 7, 8, Server 2008 y Server

2012), Linux (Ubuntu, Red Hat, Suse y Oracle Linux), Mac OS X / OS X.
- Navegadores: Internet Explorer, Firefox, Chrome, Safari (si bien solo en OX X no en
iOS).

En la actualidad el gran nicho donde Java todavía no es compatible es en sistemas operativos

móviles como iOS y Android. Fuera de este entorno podemos afirmar que Java puede ser una
solución tecnológica candidata para el desarrollo de cualquier aplicación, con instalación en
cliente estaremos hablando de Java SE, con instalación en servidor estaremos hablando de
Java EE y con instalación en dispositivo móvil o periférico estaremos hablando de Java ME.

60.3 Empaquetado de aplicaciones

A diferencia de otros lenguajes de programación, el compilador de Java crea un fichero con
2
extensión .class independiente por cada clase del sistema , lo que hace que, para proyectos de
alta complejidad, el número de ficheros a distribuir sea muy elevado: ficheros .class, imágenes,
vídeos etc.
Para facilitar la gestión, distribución, instalación y reutilización de todos estos ficheros es para
lo que se han definido diferentes formatos para empaquetar aplicaciones Java:

- Formato JAR (Java Archive): formato utilizado para empaquetar applets, aplicaciones
Java SE, librerías etc. Se verá en este tema.

- Formato WAR (Web Application Archive): formato utilizado para empaquetar

aplicaciones web desarrolladas en Java EE. Se verá en el tema 116 “Arquitectura de
desarrollo en la web (III). Tecnología Java”.

- Formato EAR (Enterprise Archive): formato utilizado para empaquetar varios módulos
(una o más aplicaciones web en formato WAR, librerías externas, o EJBs
empaquetados en JAR) y desplegarlos en un servidor de aplicaciones web que cumpla
las especificaciones Java EE. Se verá también en el tema 116.

Un archivo JAR es un fichero en el que se reúnen las clases, imágenes, sonidos y otros
ficheros necesarios para la ejecución de un applet o una aplicación Java. Esto permite facilitar
la gestión de descargas o la distribución del programa. Un fichero JAR también puede incluir un
subdirectorio de meta información llamado META-INF que contenga lo siguiente:

 Un fichero llamado MANIFEST.MF. Este fichero puede almacenar información diversa

acerca de los restantes ficheros incluidos en el JAR; información como la codificación
utilizada y otros parámetros locales de la aplicación, el directorio donde se debe
instalar, etc.
 Una serie de ficheros con extensión .sf que contienen información relacionada con la
firma de clases y aplicaciones. Debe existir uno por cada fichero firmado incluido en el
JAR.
 Las firmas digitales de ficheros con una extensión que depende del formato de firma
digital.

2
En realidad sólo las clases concretas generan ficheros (no las clases abstractas) y, si se han definido
clases internas a una clase dada, el compilador genera un fichero .class adicional por cada clase interna;
esto es muy habitual cuando se definen interfaces gráficas de usuario, ya que los manejadores de eventos
suelen definirse como clase internas en cada componente gráfico que debe ser gestionado, lo que
rápidamente llena un proyecto de ficheros .class asociados a la interfaz gráfica de usuario.

8
60. Entorno de desarrollo Java para software con distribución
El formato JAR no sólo cumple el objetivo de empaquetar los ficheros sino que además los
comprime utilizando un algoritmo de compresión muy extendido: el LZW (utilizado en la
compresión de archivos .ZIP). Con la compresión, el tamaño de la aplicación a distribuir se
reduce considerablemente. Esto es muy importante, sobre todo cuando la distribución de las
clases se hace a través de Internet o la Intranet de la organización.

Junto con las versiones del JDK se proporciona una utilidad que permite la creación de estos
ficheros JAR. Esta utilidad se invoca desde la línea de comandos mediante el programa “jar” y
tiene las funciones típicas para añadir ficheros, extraerlos, borrarlos, listarlos, etc.

Los ficheros JAR son independientes de la plataforma y cualquier JVM los interpretará sin
problemas. Este modo de empaquetar los ficheros se puede utilizar independientemente del
método de distribución de software elegido, ya sea un método de distribución tradicional (es
decir copiando directamente los ficheros o instándolo en la máquina donde se ejecutarán), o un
sistema de distribución automática como la distribución de applets o webstart.

60.4 Distribución manual o tradicional

En realidad la instalación de una aplicación Java se reduce a la copia de la estructura de
directorios (o los ficheros JAR) que contienen las clases de la aplicación en un directorio que
3
esté definido en la variable de entorno CLASSPATH de la máquina donde se va a ejecutar.
Esto es posible gracias a que los programas son compilados a un código intermedio (bytecode)
que es interpretado por una JVM; por otra parte, esto hace necesario que exista previamente
un entorno de ejecución Java (JRE).

Este método de instalación, aunque aparentemente sencillo, no es recomendable cuando el

número de máquinas es muy grande (como en el caso de grandes corporaciones con miles de
máquinas en las que se debe realizar una instalación), o cuando no se conocen de antemano
las máquinas ni las plataformas donde se va a ejecutar un programa (como es el caso de la
distribución de aplicaciones a través de Internet); en el primer caso, porque estaríamos sujetos
a una carga de administración excesiva cada vez que se actualice la aplicación, se instalen
nuevas máquinas, etc.; en el segundo caso sencillamente porque la administración no está
centralizada ni puede estarlo. Esta es la razón por la que se han buscado nuevos modos de
distribución dentro del mundo Java que veremos en los próximos apartados.

3
Aunque el intérprete de Java que se puede ejecutar desde la línea de comandos permite añadir nuevos
directorios en el CLASSPATH para una ejecución concreta.

9
60. Entorno de desarrollo Java para software con distribución
60.5 Distribución de software mediante applets
Un applet es un programa desarrollado en Java cuyo objetivo es proporcionar funcionalidad
avanzada a una página web. Se puede incluir en una página HTML5 de forma muy sencilla
4
mediante una etiqueta especial (<object>). En esta etiqueta se indican la clase que
implementa el applet (parámetro archive) y otros atributos en los que se configura cómo debe
ejecutarse. Veamos un ejemplo sencillo donde podemos observar cómo se indica la clase que
contiene al applet y cómo se le pasa al entorno de ejecución los parámetros de visualización
como por ejemplo la anchura y la altura del marco donde se visualizará la interfaz de usuario.

<object type="application/x-java-applet" height="300" width="550">

<param name="code" value="Sample" />
<param name="archive" value="Sample.jar" />
Applet failed to run. No Java plug-in was found.
</object>

La característica más importante de los applets es que su instalación en la máquina que lo va a

ejecutar es automática: cuando un navegador habilitado para Java detecta una etiqueta
<object> de tipo applet, comprueba si el código del applet está presente en la caché de Java.
Si no es así, el navegador hace una nueva petición http al servidor para descargar el código
que contiene la clase a ejecutar (generalmente junto con otras clases relacionadas y agrupadas
en un fichero JAR) y luego procede a cargarlo, vía el Java Plug-in, en la JVM instalada en la
máquina y a ejecutarlo; en otro caso, el paso de la descarga desde el servidor se obvia,
procediendo directamente a su ejecución.

Es preciso mencionar que los navegadores (originalmente Internet Explorer) ya no traen una
máquina virtual propia para la ejecución de applets (por problemas legales entre Sun y
Microsoft). Por ejemplo Microsoft desarrolló la MSJVM (Microsoft JVM) la cual venía
incorporada en sus ediciones de Internet Explorer para la ejecución de applets dentro del
navegador sin necesidad de tener instalada una JVM en la máquina. Debido a esto en toda
máquina donde se quiera ejecutar un applet es necesario tener instalado en el ordenador una
JVM que como veremos viene incluida dentro del Java Plug-in.

Todo appletes una especialización (subclase) de la clase java.applet.Applet. Normalmente, al

especializar la clase Applet, se sobrecargan (reescriben) algunos métodos de la clase original
para implementar la funcionalidad específica del applet. Los métodos que normalmente se
reescriben son:

1 init()– Inicializa el applet cada vez que se carga.

2 start() – Inicia la ejecución del applet cargado o cuando se visita de nuevo una página
que contiene el applet.
3 stop() – Detiene la ejecución; por ejemplo, cuando el usuario abandona la página del
applet o cierra el navegador.
4 destroy() – Realiza las operaciones previas a la descarga.
5 paint() – Dibuja el appleten el navegador.
6 update() – En conjunción con paint() mejora la visualización del applet.

Durante su ejecución un applet pasa por una serie de estados concretos. Estos estados son lo
que podríamos denominar ciclo de vida de un applet. Estos estados son los cinco siguientes:

 Descarga del applet: Es el estado que antes habíamos explicado por el cual el
navegador comprueba la existencia del applet en la caché de Java y, si es necesario,
hace la petición http para obtenerlo.

4
En versiones anteriores a HTML5 se utiliza la etiqueta <applet> la cual quedó obsoleta (deprecated) y
sustituida por la etiqueta <object>. La versión HTML5 ya no soporta la etiqueta <applet>.

10
60. Entorno de desarrollo Java para software con distribución
  Carga del applet: El applet está en este estado durante el proceso de creación del
objeto que concreta la subclase de Applet y de ejecución de los métodos init() y start().

 Ejecución del applet: Realiza su ejecución hasta que el usuario abandone la página o
cierre el navegador.

 Applet detenido: Cuando el usuario abandona la página el applet para su ejecución con
el método stop(). Cuando el usuario vuelva a la página se ejecutará el método start() de
nuevo, con lo que el applet volverá al estado de ejecución. El efecto de minimizar la
ventana del navegador y posteriormente maximizar también provoca la misma
secuencia stop-start.

 Descarga del applet: Cuando se cierra el navegador se ejecuta el método stop() y

posteriormente el destroy() para liberar los recursos que estuviese utilizando el applet.

60.6 Distribución de aplicaciones mediante WebStart

Java WebStart es una tecnología que permite simplificar la distribución e instalación de
aplicaciones Java permitiendo la ejecución de aplicaciones Java haciendo clic en un enlace de
una página web desde un navegador sin realizar ninguna instalación adicional.

Con Java WebStartinstalado en la máquina cliente (actualmente viene ya dentro del JRE que
se descarga un usuario al instalar Java en un ordenador) cuando se hace clic en el enlace
correspondiente, si la última versión de la aplicación no está instalada en la máquina,
automáticamente se descargan todos los ficheros necesarios. De este modo podemos
asegurar siempre que la máquina está ejecutando la última versión del sistema.

Las aplicaciones lanzadas con Java WebStartson independientes del navegador. De esa
forma, tras el proceso inicial de carga y posible puesta al día, se puede cerrar el navegador y la
aplicación descargada seguirá funcionando.

Java WebStartestá diseñado para proporcionar aplicaciones con una interfaz compleja no
basada en web que permitan trabajar sin estar conectado a la red y con tiempos de respuesta
mejores que los de las aplicaciones web puras, a la vez que sin las desventajas de distribución,
instalación y actualización de las aplicaciones tradicionales. Este esquema ofrece una solución
muy conveniente para las compañías que tienen que mantener miles de máquinas actualizadas
y para las que el modelo tradicional de distribución de aplicaciones se ha demostrado muy
costoso.

Desde el punto de vista del usuario, Java WebStart es transparente, no se diferencia en nada
de los mecanismos para lanzar aplicaciones locales pero en realidad lo que está ocurriendo es
lo siguiente:

1. El enlace en la página manda al navegador que ejecute la tecnología Java WebStart.

2. Ésta determina preguntando al servidor web si la aplicación está instalada y
actualizada.
3. Si no es así, se lanza la instalación o actualización de la aplicación descargando lo que
sea necesario de forma transparente al usuario.

Java WebStart utiliza JNLP (Java LaunchingProtocol) el cual es un esquema XML que permite
a los desarrolladores crear un fichero con extensión .jnlp para definir el mecanismo de
lanzamiento. Es decir es en ese fichero .JNLP donde Java WebStart obtiene la información de
los ficheros JARs que son necesarios, su localización en el servidor, la clase principal de
arranque de la aplicación así como otros atributos como el ancho y largo de la ventana.

11
60. Entorno de desarrollo Java para software con distribución
Debe quedar claro que para que este sistema funcione debe estar instalado en la máquina
cliente el software de Java WebStart (actualmente viene ya dentro del JRE que se descarga un
usuario al instalar Java en un ordenador). Además esta tecnología permite:

1. La convivencia de múltiples entornos de ejecución Java (JRE) en la misma máquina.

2. La implementación de políticas de seguridad basadas en código firmado.
3. La definición de políticas de seguridad para acceso a recursos locales (sandboxing).
4. La realización de actualizaciones incrementales: si los cambios en una versión afectan
sólo al 10% de las clases de la aplicación, sólo se bajará y actualizará ese 10%.
5. Una integración completa con el escritorio de forma que el usuario no percibe la
diferencia que supone lanzar una hoja de cálculo mediante una tecnología tradicional y
una basada en Java WebStart. En un entorno de intranet (donde las aplicaciones
residen en un servidor de la red local) el retraso percibido debido a las operaciones de
actualización es mínimo.

Por todo esto, Java WebStart puede ser la tecnología en la que basarse para poder distribuir
aplicaciones con interfaces de usuario complicadas que necesitan instalación de software en
cliente, sin el tremendo coste de la distribución y gestión tradicional.

60.7 Java Plug-in

Java Plug-in no es más que un puente entre los navegadores instalados en el sistema y los
distintos entornos de ejecución de java (JRE) que se hayan instalado en la máquina cliente.
Esto permite a las empresas distribuir applets o aplicaciones mediante WebStartdesarrollados
con las últimas versiones y capacidades de la plataforma Java sin preocuparse por la
compatibilidad con la versión del entorno de ejecución original del navegador.

Sun Microsystems introdujo la tecnología JavaPlug-in en 1998 mucho antes de que Java se
divorciase de algunos de los navegadores más populares. Desde entonces, el plug-in ha sido
parte de la instalación del paquete que contenía los distintos JRE que Sun y ahora Oracle han
ido liberando a lo largo de los años.

Una de las cuestiones más interesantes de la tecnología del Java Plug-in es la capacidad que
ofrece de detección de entornos de ejecución (JRE) instalados en la máquina. En este caso, el
sistema permite al navegador obtener un entorno de ejecución distinto.

El elemento más característico de Java Plug-in es el panel. Esta es una aplicación Java que
permite configurar en el sistema distintos aspectos relacionados con la actividad del plug-in,
como la actividad de la caché, la presencia de la consola Java, la acción del compilador just-in-
time, la gestión de certificados y la seguridad etc.

12
60. Entorno de desarrollo Java para software con distribución
 13
60. Entorno de desarrollo Java para software con distribución
60.8 Ejecución de aplicaciones nativas
Una de las características más importantes de Java es que el código fuente de una aplicación
escrita en este lenguaje puede ser compilado sin cambios en cualquier máquina de cualquier
fabricante, pero lo más revolucionario es que el código compilado en una máquina determinada
puede ser ejecutado sin ser recompilado en cualquier otra máquina para la que exista una
JVM, sea cual sea la arquitectura y tecnología de esa máquina. Esto es debido a que, como
hemos mencionado anteriormente, la compilación no genera código ejecutable para el
hardware específico sino que genera un código binario (bytecode ) que es interpretado por un
entorno de ejecución Java (JRE). Este modo de trabajo es lo que permite una completa
independencia de la plataforma. Sin embargo, no debemos olvidar que debe existir una JRE
disponible y de la versión adecuada en la plataforma en la que se quiera ejecutar las
aplicaciones Java.

60.8.1 Compiladores nativos de Java

La portabilidad se convierte en una de las grandes ventajas del lenguaje pero lógicamente esta
característica no es gratuita. El hecho de que el entorno de ejecución tenga que interpretar el
bytecode antes de ejecutarlo ralentiza la ejecución y esto, para determinados entornos, puede
ser un inconveniente decisivo: entornos de tiempo real (simuladores etc., Java ofrece menos
rapidez que otros lenguajes de programación como C++).

Para solucionar este problema de rendimiento, algunos fabricantes propusieron el desarrollo de

compiladores nativos de Java. Los compiladores nativos permiten a las aplicaciones escritas en
Java ser compiladas directamente al código máquina nativo de un entorno concreto (el binomio
hardware y sistema operativo). Por supuesto, esta solución eliminaba la independencia de la
plataforma del código compilado a cambio de:

1. Proporcionar un rendimiento de ejecución supuestamente mejor y en ocasiones con una

mejora absolutamente fundamental.
2. Ser innecesaria la instalación de un JRE en las máquinas que debían ejecutar la aplicación.

Por otra parte, es importante tener en cuenta ciertos aspectos antes de lanzarnos a la
utilización de este tipo de compiladores ya que, aunque los compiladores nativos de Java
tienen ya un nivel de madurez importante, no siempre obtienen mejores rendimientos que el
código bytecodey esto es debido a que existen ciertas optimizaciones que las máquinas
virtuales pueden realizar y que no se pueden implementar en el código nativo. De hecho, no
está demostrado en la práctica que el bytecode sea intrínsecamente más lento que el código
nativo; las diferencias más importantes están asociadas no al bytecode en si mismo, sino al
hecho de que la máquina virtual realiza toda una serie de comprobaciones de integridad del
programa que ralentizan su funcionamiento: las llamadas retardadas, la gestión automática de
memoria, la utilización de recursos por mecanismos uniformes que en muchos casos hacen
subir excesivamente el consumo en memoria, etc. Estas son características del sistema por las
que hay que pagar cierto precio.

En definitiva, antes de decantarse por un compilador nativo se recomienda hacer

comparaciones con el entorno estándar y con otros compiladores nativos del mercado y ver
cuales son los resultados. Dependiendo de nuestras restricciones y estos resultados podremos
adoptar la decisión más adecuada.

Hay diferentes tipos de compiladores nativos. Los más importantes a la hora de tomar una
decisión son los llamados compiladores AOT (Ahead-Of-time) y los compiladores JIT (Just in
Time). La principal diferencia entre unos y otros es que los compiladores AOT compilan a
código máquina nativo antes de la ejecución de la aplicación, mientras que los JIT compilan
durante la ejecución. Dependiendo del tipo de aplicación puede convenir más un compilador u
otro en caso de querer compilar a código nativo.

14
60. Entorno de desarrollo Java para software con distribución
60.9 Interfaces de programación para entornos de ventanas
Una interfaz de programación para entornos de ventanas es un conjunto de clases que
permiten crear y gestionar ventanas, botones, elementos gráficos de la interfaz de usuario para
cada sistema. Aunque, como hemos dicho antes, Java nació en el mundo de los sistemas
empotrados, desde su primera versión incorporó clases y librerías para cubrir las necesidades
que se iban a exigir a un lenguaje de programación de propósito general en este ámbito.
Actualmente, Java tiene tres grandes colecciones de componentes (AWT, Swing y JavaFx) que
facilitan la labor del programador con distintos niveles de versatilidad, potencia, sencillez y
consumo de recursos del sistema.

60.9.1 AWT (AbstractWindowToolkit)

El paquete java.awt es una biblioteca para el desarrollo de interfaces de usuario gráficas (GUI)
y poder gestionar entornos de ventanas desde aplicaciones Java.

AWT incluye:
- Un conjunto de componentes nativos de interfaz de usuario: es decir para sistemas
operativos distintos los componentes (por ejemplo la pantalla- window) son de
apariencia diferente. Implica que las interfaces desarrolladas con AWT se ven
diferentes en un sistema operativo que en otro. Este hecho es una de las principales
pegas de los desarrolladores.
- Un modelo de manejo de eventos (eventhandler).
- Herramientas para imágenes, gráficos.
- Diferentes estilos de diseño (layaouts).
- Clases para transferir datos de entrada y salida y poder cortar y pegar desde el
portapapeles (clipboard) nativo del ordenador.

A pesar de sus limitaciones el paquete se sigue manteniendo en todas las versiones de Java
siendo la base de otros paquetes como Swing que veremos más adelante.

60.9.2 Swing
Swing es, en realidad, el nombre clave del proyecto que desarrolló los nuevos componentes de
la JFC (Java FoundationClasses) como extensión a los componentes estándar del AWT
incluido en la versión 1.1 del JDK. Sin embargo, este nombre ha venido a ser conocido de
forma generalizada para referirse también a los resultados de este proyecto; es decir al
conjunto de componentes de nueva generación (flexibles, 100% Java y basados en la nueva
arquitectura de eventos).

Los objetivos de Swing eran:

 Ser 100% Java para promover la consistencia de las GUI entre plataformas y para
facilitar el mantenimiento.
 Ofrecer una única API capaz de ofrecer múltiples aspectos de forma que
desarrolladores y usuarios no tuvieran que estar condicionados por una cuestión más
relacionada con la estética que con la funcionalidad.
 Capacitar al sistema de un modelo dirigido por eventos que no implicase tener que
tratar con él en otras APIs de nivel superior.
 Mantener la adherencia a los principios de diseño de JavaBeans para asegurar que los
componentes se podían utilizar sin problemas en las herramientas y los entornos de
desarrollo para Java.
 Ofrecer compatibilidad con las APIs de AWT donde hubiera elementos comunes, para
facilitar el acceso de los programadores que utilizasen AWT.

Swing está incluida bajo el paquete javax.swing y amplia la funcionalidad de AWT con muchos
más tipos de componentes gráficos y, gracias a su implementación 100% Java, proporciona

15
60. Entorno de desarrollo Java para software con distribución
una mayor versatilidad para que el programador pueda ampliar y ajustar las funcionalidades de
dichos componentes (además de no depender de las implementaciones nativas de los
sistemas de gestión de ventanas). Estas son las principales diferencias con AWT, aunque hay
otras como la mayor escalabilidad y el mejor rendimiento del sistema gráfico.

La arquitectura de Swing está basada en un patrón de diseño muy conocido: el patrón modelo-
vista-controlador (MVC). Esto permite independizar bastante la lógica de la aplicación diseñada
de la interfaz concreta, de forma que es más sencillo hacer cambios en una u otra con un
menor impacto en la totalidad del conjunto. Casi todos los componentes contenedores de
Swing tienen un modelo (funciones) asociado. Por ejemplo, un botón (Jbutton) tiene un modelo
asociado que almacena el estado del botón (cuál es su tecla asociada, si está habilitado, si
está seleccionado o presionado, etc.); una lista (Jlist) tiene dos modelos asociados: uno que
mantiene el contenido de la lista y otro que lleva el control de la selección actual de la lista. Por
lo general, no es necesario que el programador sepa cómo gestionar el modelo del
componente; la cuestión de la existencia de los modelos, pues, no se justifica en realidad
porque el programador los utilice directamente, sino porque ofrecen una flexibilidad única al
determinar cómo se almacenan los datos y cómo se recuperan. Por ejemplo, si un equipo de
desarrollo está diseñando una aplicación que incluye una hoja de cálculo que maneja datos de
una matriz triangular, el programador puede crear su propio modelo de tabla optimizado para
este caso con un consumo de recursos mínimo.

Con Java 2, Swing empezó también a hacer uso extensivo de otra API que mejoró
considerablemente muchos aspectos de la visualización en pantalla: Java2D. Esta API es un
conjunto de clases que ofrecen herramientas avanzadas para gestionar gráficos 2D e
imágenes, con un modelo sencillo a la par que completo.

Hoy por hoy, Swing ofrece todas las características necesarias para crear interfaces de usuario
robustas y complejas siendo el paquete más utilizado para desarrollar interfaces de usuario
para aplicaciones de escritorio desarrolladas con Java SE. Es una colección de componentes
madura y potente. Sin embargo, su principal crítica es que las interfaces que se realizan con
Swing tienden a ser relativamente proclives a consumir una gran cantidad de recursos de
máquina en forma de memoria. Por ello, han surgido distintas alternativas como SWT (Estándar
WidgeteToolkit) y JFace de la Fundación Eclipse y Java FX (incluida ya en el JDK/JRE 8) que
veremos a continuación.

60.9.3 SWT (Standard Widget Toolkit) y JFace

SWT es una librería de código abierto diseñada para construir interfaces gráficas de usuario
por la fundación Eclipse.

SWT/JFace es similar a AWT/Swing en Java con la diferencia de que utiliza un amplio conjunto
de componentes gráficos nativos, más ricos que los de AWT y más sencillos que los de Swing.

Swing tenía una cierta fama de lento. En 1998, tras la liberación de la plataforma Java 2, había
sin duda problemas de rendimiento en algunas áreas. Sin embargo, cuatro años después, el
rendimiento se había mejorado y estabilizado bastante. Los autores de SWT dicen que la
principal razón para crear SWT era el rendimiento.

Los desarrolladores necesitaban librerías portables que proporcionaran componentes gráficos

comparables a los que ofrecía cualquier herramienta desarrollada con herramientas
específicas. Algunos reclamaban acceso a características específicas de cada plataforma.
SWT trató de proporcionar esta funcionalidad utilizando una pequeña API. Esta API se
implementó sobre diferentes plataformas con una combinación de componentes Java y
componentes nativos. La implementación no era puramente Java ya que utilizaba el interfaz
nativo con C (JNI) para llamar al sistema operativo desde Java. La idea de los ingenieros de
Eclipse era utilizar los componentes nativos del sistema para acelerar el rendimiento de la
interfaz. Finalmente, rodearon el conjunto con una paleta de componentes denominados JFace
(que abstraían la implementación concreta de cada sistema operativo).

16
60. Entorno de desarrollo Java para software con distribución
En cierto sentido SWT tiene muchos elementos en común con AWT: son tecnologías de
componentes pesados; aunque SWT lo que ofrece es un conjunto de componentes más
extenso. Pero en realidad tienen las mismas limitaciones.

Otros problemas con SWT tienen relación con la propia naturaleza de Java como lenguaje
multiplataforma, cuya mejor baza se supone que es la portabilidad. Con SWT esta portabilidad
se reduce bastante. Si consideramos que, por otra parte, según las pruebas comparativas
realizadas entre la primera versión de Java 2 (JDK 1.2) y la actual (JDK 8) el rendimiento de
Swing es considerablemente mejor, la conveniencia de utilizar SWT/JFace por su mejor
rendimiento está claramente cuestionada.

60.9.4 JavaFX
JavaFX pretende sustituir a Swing como estándar de desarrollo de interfaces gráficas de
usuario en Java SE. JavaFX viene ya incluido como novedad desde la versión 7u6 del
JDK/JRE pero no está basado en ninguna especificación estándar JSR sino que es un
producto de Oracle, por lo que Oracle puede suspender su desarrollo si lo considera oportuno.
Esta situación es importante tenerlo en cuenta a la hora de elegir un nuevo desarrollo de una
aplicación de escritorio haciendo uso de Swing o de JavaFx.

Entre sus mejoras está que soporta gráficos en 3D, interfaces más atractivas, efectos visuales,
permite añadir JavaScript etc.

17
60. Entorno de desarrollo Java para software con distribución
60.10 Principales librerías
A continuación se detallan las principales librerías de la edición Java SE.

60.10.1 Lang y Util

Elpaquete Javajava.langcontiene clasese interfacesfundamentalesestrechamenteligado
eltiempo de ejecución: (Object, Enum, Class, Throwable, Error, Exception…)

El paquete Java java.util contiene las estructuras de datos que agregan objetos, como los tipos
Collection, Set…

60.10.2 Sistema de entrada/salida: librerías io y nio.

El sistema de entrada/salida de un lenguaje siempre es un punto crítico en cuanto al
rendimiento y escalabilidad de las aplicaciones desarrolladas con dicho lenguaje. Un programa
se puede comunicar con su entorno a través de ficheros, una consola, la red, bases de datos,
etc. Además ese acceso puede ser secuencial o directo, en modo binario o en modo carácter,
síncrono o asíncrono, etc. Es decir, existe una gran funcionalidad que debe ser cubierta por las
librerías que dan soporte a la entrada/salida.

Los diseñadores de Java crearon un gran número de clases para cubrir estos aspectos de
entrada/salida. Para muchos programadores que se inician en este entorno, esta complejidad
de la API de entrada/salida puede hacer que la curva de aprendizaje sea algo más pronunciada
que en otros lenguajes.

La entrada/salida desde Java se realiza a través de las clases del paquete java.io. Dentro de
este paquete aparecen jerarquías y clases dedicadas a funcionalidades más concretas. Por
ejemplo:

 File. Representa un path a un fichero o directorio.

 InputStream. Representa una clase para recibir un flujo de datos de entrada.
 OutputStream. Representa una clase para generar un flujo de datos de salida.
 Reader. Clase orientada a la entrada de caracteres.
 Writer. Clase orientada a la salida de caracteres.
 ...

Así, podríamos enumerar un enorme conjunto de clases que combinadas proporcionan a Java
una completa funcionalidad de entrada/salida.

Con la versión 1.4 del JDK aparece un nuevo paquete de librería de entrada/salida: java.nio,
que tiene como principal objetivo mejorar el rendimiento de las clases del que, hasta ese
momento, había sido el paquete estándar de entrada/salida: java.io. La principal diferencia
entre java.io y java.nio es que la primera utiliza streams y la segunda blocks, a la hora de
almacenar y transmitir la información, siendo la segunda opción más rápida y flexible.

En definitiva podemos decir que, en su versión actual, Java encapsula toda la funcionalidad
genérica de entrada/salida en dos paquetes java.io y java.nio. Claro que también existen
librerías que cubren otras necesidades de entrada/salida específica como puede ser el acceso
a bases de datos.

18
60. Entorno de desarrollo Java para software con distribución
60.10.3 Acceso a bases de datos: JDBC (Java DatabaseConnectivity)
La API java.sql es un paquete de clases conocido como JDBC (Java DatabaseConnectivity)
que proporciona una interfaz común para el acceso a bases de datos (generalmente
relacionales) a través del lenguaje SQL (Standard QueryLanguage). JDBC permite el acceso a
un gran número de bases de datos, en realidad no sólo a bases de datos, sino a cualquier
fuente de datos tabular para la que el fabricante haya proporcionado un controlador específico.

En realidad es importante entender que el paquete java.sql no está formado fundamentalmente

por clases, sino que casi en su totalidad es un conjunto de interfaces. Los programas Java que
el desarrollador escribe para acceder a una base de datos referencian a los métodos
declarados por estas interfaces y serán los drivers los encargados de implementar esos
métodos. De este modo se consigue completa independencia del código fuente y del sistema
gestor de base de datos (aunque no olvidemos que la mayoría de los gestores de bases de
datos tienen extensiones propietarias de SQL y la utilización de estas extensiones arruina la
posible independencia de nuestros programas respecto del gestor de base de datos que
hayamos utilizado).

En JDBC se distinguen cuatro tipos de drivers, que se numeran desde el tipo I al tipo IV.

El driver de tipo I es el bridge JDBC-ODBC. Este driver utiliza controladores ODBC para
conectarse con el sistema gestor de base de datos. Por lo tanto requiere que el controlador
ODBC esté configurado correctamente en la máquina de ejecución.

La ventaja de este tipo de driver es que da acceso a prácticamente todos los sistemas de
gestión de base de datos del mercado puesto que los drivers ODBC están muy extendidos.
Como desventajas deben destacarse, por un lado la existencia de tres niveles de software
entre la aplicación y la base de datos (API JDBC, bridge JDBC-ODBC, driver ODBC) lo que
disminuye considerablemente el rendimiento total del sistema, y por otro lado la utilización del
driver ODBC (código nativo – no Java) se salta el modelo de seguridad del JRE por lo que su
utilización en applets no está recomendada.

Driver de tipo II o driver parcialmente nativo. Este tipo de driver utiliza código Java para
hacer llamadas a una API nativa que debe estar en la máquina que accede a la base de datos.
Esta API nativa es la que realmente proporciona la conectividad.

La ventaja de este tipo de drivers es la rapidez ya que está utilizando código nativo de una API
propietaria para una base de datos. Sin embargo, al utilizar código nativo tiene el mismo
inconveniente que los de tipo I de cara a los applets.

Driver de tipo III o Middelware driver. Este tipo de driver utiliza los protocolos de red del JDK
para conectar con un servidor intermedio. El driver JDBC traduce las peticiones a un protocolo
independiente de la base de datos y las envía a dicho servidor. Éste suele ser un servidor
físicamente diferenciado, aunque no es necesario. El intermediario traduce las peticiones del
programa al lenguaje específico de la base de datos. Este tipo de driver no requiere ninguna
instalación adicional en la máquina cliente, pero obliga a la existencia del middleware. La
principal ventaja es que sólo requiere código Java en cliente y por lo tanto puede ser utilizado
con seguridad por applets. La desventaja es la capa, middleware que añade un nivel más de
software y por lo tanto provoca una disminución de rendimiento.

19
60. Entorno de desarrollo Java para software con distribución
Driver de tipo IV o Pure Java driver. Este tipo de drivers están desarrollados exclusivamente
en Java y utilizan directamente el protocolo propietario de la base de datos a la que accede. Al
igual que los de tipo III no requieren software adicional en cliente y por lo tanto pueden
utilizarse en applets y su principal ventaja está en que, al tener menos capas, ofrecen mejor
rendimiento. Generalmente el fabricante de la base de datos que vayamos a utilizar nos
proporcionará su driver JDBC de tipo IV (también nos proporcionará otros tipos, aunque el tipo
más utilizado suele ser el 4. Un ejemplo es el driver “thin” de Oracle ampliamente utilizado.).

60.10.4 JNDI (Java Naming and Directory Interface)

API de Java para acceso a servicios de directorio (LDAP, DNS etc.). Permite a las aplicaciones
Java clientes descubrir y buscar objetos y datos a través de un nombre. Dentro de la pila de
Java SE API se encuentra en el grupo de librerías de integración. Es utilizada por otras librerías
como RMI y librerías de Java EE.

60.10.5 JNI (Java Native Interface)

JNI es la interfaz estándar de programación para llamar a métodos nativos escritos en otros
lenguajes como C o C++.

Normalmente, un desarrollador de Java programará sus aplicaciones completamente en Java;

por un lado, por comodidad y, por otro, para evitar incompatibilidades con las plataformas. Sin
embargo, en algunas ocasiones el desarrollador puede considerar adecuado utilizar métodos
implementados en otros lenguajes y compilados exclusivamente para una plataforma. Ejemplos
de esta problemática son los siguientes:

 Cuando busquemos un mejor rendimiento: determinados procesos críticos pueden ser

más rápidos si han sido desarrollados en lenguajes como C o C++.
 Cuando tengamos que utilizar características propias de una plataforma concreta.
 Cuando tengamos que utilizar librerías escritas en otros lenguajes y éstas no existan
en Java.
 Cuando tengamos programas o código heredado para el que no se disponga de un
conector y no sea aconsejable técnica o económicamente migrarlo a Java.

JNI nos permite cargar librerías dinámicas de la plataforma en la que nos encontremos (por
ejemplo: ficheros DLL en Windows o librerías .so en UNIX) en nuestro programa Java y
posteriormente acceder a los métodos y propiedades de estas librerías de forma casi
transparente para el programador.

Otra de las ventajas que nos proporciona la interfaz JNI es que podemos crear aplicaciones
nativas y utilizar desde estas clases desarrolladas en Java. El JNI nos permite cargar, inicializar
e invocar a la maquina virtual de Java para poder crear clases Java desde nuestro programa
escrito en lenguaje nativo.

Sin embargo, atendiendo a la distribución de aplicaciones no hay que olvidar que al utilizar
librerías nativas en nuestros programas Java, estamos perdiendo la famosa portabilidad
universal entre diferentes plataformas de nuestra aplicación Java quedando limitada a la
portabilidad de las librerías nativas.

60.10.6 JAXP (Java API for XML Processing)

20
60. Entorno de desarrollo Java para software con distribución
API de Java para validar y parsear documentos XML. Proporciona varias interfaces para poder
parsear el documento XML en modo DOM, SAX, StAX (Streaming SAX) y una interfaz XSLT
(XML StylesheetLanguageforTransformations) para poder transformar el documento XML en
otro tipo de documento (HTML, PDF…).

60.10.7 Cuestiones sobre seguridad

Una aplicación Java se enfrenta a los mismos problemas de seguridad que una aplicación en
cualquier otro lenguaje, aunque como veremos Java implementa ciertas funcionalidades que
harán más seguro el entorno de ejecución. Una aplicación nativa tiene acceso a los recursos
del sistema sobre el que se ejecuta, sólo limitada por el esquema de seguridad del sistema
operativo o por productos de seguridad específicos.

El lenguaje Java incluye en su diseño una serie de características que han ayudado a hacer de
Java un entorno bastante seguro. Algunas de estas características son implementadas por el
compilador:

 Es un lenguaje fuertemente tipado. El intento de actualizar posiciones de memoria con

datos de tipo incorrecto es bloqueado por el compilador generando errores en tiempo
de compilación.
 Eliminación de operaciones con punteros. Con lo que se elimina el potencial riesgo de
acceso a posiciones de memoria restringidas o a la modificación de código cargado en
memoria.

Durante la compilación se verifican las reglas de seguridad que hemos mencionado, pero como
no podemos garantizar que el código compilado no ha sido modificado o partir de la base de
que todos los compiladores hacen lo que tienen que hacer (alguien podría construirse su propio
compilador que permitiese hacer operaciones ilegales para un compilador estándar de Java), el
entorno de ejecución implementa estas revisiones antes de ejecutar la clase. Con esta revisión
se garantizan temas como:

1. Que no se realicen operaciones con punteros.

2. Que no existan desbordamientos que puedan permitir el acceso a zonas de memoria a
las que no deberían acceder.
3. Que los tipos de los parámetros coinciden con lo que se espera.
4. Que no se está accediendo a métodos privados o protegidos desde una clase que no
deba tener accesos a ellos.
5. Que el fichero compilado está bien formado.

Estas características, indudablemente, les restan oportunidades a los que con determinados
trucos intentan saltar la seguridad de un programa y propone a Java como un lenguaje con el
que desarrollar sistemas seguros.

60.11 Entornos de desarrollo integrado (IDEs) Java

Un entorno de desarrollo integrado, llamado también IDE (sigla en inglés de
integrateddevelopmentenvironment), es un programa informático compuesto por un conjunto de
herramientas de programación. Puede dedicarse en exclusiva a un solo lenguaje de
programación o bien puede utilizarse para varios.

Un IDE incorpora habitualmente:

- Un espacio para la escritura de código con cierta ayuda interactiva para generar código
y para indicar los errores de sintaxis que se cometan por parte del programador.
- La posibilidad de compilar y ejecutar el código escrito.
- La posibilidad de organizar los proyectos de programación.

21
60. Entorno de desarrollo Java para software con distribución
 - Herramientas auxiliares para programadores para detección de errores o análisis de
programas (debuggers).
- Otras opciones como utilidades para pruebas, carga de librerías, etc.

Existen diversos IDEs para Java. Se citan los más utilizados en la actualidad, siendo los dos
primeros sin lugar a dudas los más utilizados:

1. Eclipse: software libre. Es uno de los entornos Java más utilizados a nivel profesional.
El paquete básico de Eclipse se puede expandir mediante la instalación de plugins para
añadir funcionalidades a medida que se vayan necesitando.
2. NetBeans: software libre. Otro de los entornos Java muy utilizados, también
expandible mediante plugins. Facilita bastante el diseño gráfico asociado a
aplicaciones Java.
3. BlueJ: software libre. Es un entorno de desarrollo dirigido al aprendizaje de Java
(entorno académico) y sin un uso muy extendido a nivel profesional. Es utilizado en
distintas universidades para la enseñanza de Java. Destaca por ser sencillo e incluir
algunas funcionalidades dirigidas a que las personas que estén aprendiendo tengan
mayor facilidad para comprender aspectos clave de la programación orientada a
objetos.

60.12 Casos de éxito en la Administración General del Estado

A continuación se muestran una serie de casos de éxitos de aplicaciones desarrolladas bajo la
plataforma Java SE dentro de la Administración General del Estado que tienen una amplia
utilización no solo por parte de las administraciones públicas sino también por parte de los
ciudadanos:

- Programa PADRE: El programa PADRE (Programa de Ayuda a la Declaración de la

Renta) es el programa desarrollado por la AEAT (Agencia Estatal de Administración
Tributaria) para que el contribuyente pueda realizar la declaración del IRPF desde casa
sin necesidad de tener que acercarse a una oficina presencial. Está disponible para
varias plataformas: Windows, Linux y Mac OS.

- Cliente @firma: El Cliente de @firma es una herramienta de firma electrónica en

entornos de escritorio y dispositivos móviles (se proporciona también para dispositivos
móviles pero desarrollado en código nativo no en Java), que funciona en forma de
Applet de Java integrado en una página Web mediante JavaScript como aplicación de
escritorio, o como aplicación móvil (Cliente de Firm@ móvil), dependiendo del entorno
del usuario. Se proporciona a las Administraciones Públicas para que dispongan de los
instrumentos necesarios para implementar la autenticación y firma electrónica
avanzada de una forma rápida y efectiva. En la actualidad se han desarrollado dos
versiones del Applet para uso en navegador: el Applet de @firma y el Miniapplet de
@firma.
 Applet de @firma: applet original el cual está en proceso de
descontinuación.
 Miniapplet @firma: appletmultiformato de firma, multinavegador y
multisistema operativo. Nueva implementación de las funcionalidades
más solicitadas pero con un nuevo diseño más reducido, eficiente y
ágil de cara al usuario.

Además de los clientes @firma Miniapplet y Cliente de firm@ móvil hay disponibles dos
aplicaciones Java de escritorio:
o Standalone: Interfaz de escritorio para poder realizar firma offline en nuestro
escritorio. A diferencia del cliente @firma que realiza firma online por decir así.
Permite al Cliente de Firma ejecutarse como una aplicación independiente o
aplicación de escritorio. Proporciona toda la funcionalidad del cliente: Firma en
el formato elegido, cifrado, ensobrado.

22
60. Entorno de desarrollo Java para software con distribución
 o Firma fácil: Sencilla aplicación de escritorio, para usuarios sin conocimientos
de firma electrónica. Autoselecciona el formato de firma más apropiado al
documento a firmar, y permite visualizar los firmantes y documento firmado en
caso de que se le introduzca una firma.

Todas estas herramientas han sido desarrolladas por la Dirección General de

Modernización Administrativa, Procedimientos y para el impulso de la Administración
electrónica del Ministerio de Hacienda y Administraciones Públicas.

23
60. Entorno de desarrollo Java para software con distribución
60.13 Bibliografía
Oracle http://www.oracle.com/es/technologies/java/overview/i
ndex.html
Thinking in Java (Bruce Eckel) http://www.bruceeckel.com
Compiladores nativos http://gcc.gnu.org/java
http://www.excelsior-usa.com/jet.html
http://www.bearcave.com/software/java/comp_java.ht
ml
Programación Java en Linux (Meyers) Editorial Prentice Hall 2002
JavaWorld http://www.javaworld.com/

Excelsiorcompiler http://www.excelsior-usa.com/articles/java-to-exe.html
Wikipedia http://www.wikipedia.org/

24
60. Entorno de desarrollo Java para software con distribución