rrr_java

Manual de Java

Rodolfo-J. Rodríguez-R. E-mail: [email protected]

MANUAL DE JAVA Rodolfo J. Rodríguez-R.

[email protected]

ÍNDICE:

1. RESUMEN 2

2. PROGRAMACIÓN CLIENTE-SERVIDOR 3

3. PLUG-INS 4

4. SCRIPTS 4

5. JAVA 4

6. ACTIVEX 5

7. SCRIPTLETS 5

8. JAVA EN "DOS PALABRAS" 6

9. ORIGEN DE JAVA 8

10. CARACTERÍSTICAS DE JAVA 9

11. ORIENTADO A OBJETOS 10

12. DISTRIBUIDO 10

13. ROBUSTO 10

14. SEGURO 13

15. PORTABLE 15

16. INTERPRETADO 15

17. DINÁMICO 19

18. DIFERENCIAS Y SIMILITUDES CON C++ 21

19. JAVA PARA APLICACIONES CORPORATIVAS 24

20. DESARROLLO RÁPIDO DE APLICACIONES 25

21. APLICACIONES EFECTIVAS Y EFICIENTES 25

22. PORTABILIDAD PARA PROGRAMADOR Y PROGRAMA 26

23. COSTOS DE DESARROLLO 27

24. MANTENIMIENTO Y SOPORTE 27

25. APRENDIZAJE 29

26. RESUMEN 29

27. PRIMEROS PASOS EN JAVA 31

Manual de Java


1. Resumen El uso principal que se hace de Internet e incluso de las redes internas (corporativas) es correo electrónico (e-mail), aunque actualmente hay un auge sorprendente de la navegación web. Los documentos web pueden contener variedad de texto, gráficos de todas clases y proporcionar enlaces hipertexto hacia cualquier lugar de la red. Los navegadores utilizan documentos escritos en lenguaje HTML. La combinación actual de navegadores HTML/WWW está limitada pues a texto y gráficos. Si se quiere reproducir un sonido o ejecutar un programa de demostración, primero hemos de bajarnos (download) el fichero en cuestión y luego utilizar un programa en nuestro ordenador capaz de entender el formato de ese fichero, o bien cargar un módulo (plug-in) en nuestro navegador para que pueda interpretar el fichero que hemos bajado. Hasta ahora, la única forma de realizar una página web con contenido interactivo, era mediante la interfaz CGI (Common Gateway Interface), que permite pasar parámetros entre formularios definidos en lenguaje HTML y programas escritos en Perl o en C. Esta interfaz resulta muy incómoda de programar y es pobre en sus posibilidades. El lenguaje Java y los navegadores con soporte Java, proporcionan una forma diferente de hacer que ese navegador sea capaz de ejecutar programas. Con Java se puede reproducir sonido directamente desde el navegador, se pueden visitar home pages con animaciones, se puede enseñar al navegador a manejar nuevos formatos de ficheros, e incluso, cuando se pueda transmitir vídeo por las líneas telefónicas, nuestro navegador estará preparado para mostrar esas imágenes. Utilizando Java, se pueden eliminar los inconvenientes de la interfaz CGI y también se pueden añadir aplicaciones que vayan desde experimentos científicos interactivos de propósito educativo, a juegos o aplicaciones especializadas para la televenta. Es posible implementar publicidad interactiva y periódicos personalizados. Por ejemplo, alguien podría escribir un programa Java que implementara una simulación química interactiva -una cadena de adn-. Utilizando un navegador con soporte Java, un usuario podría recibir fácilmente esa simulación e interaccionar con ella, en lugar de conseguir simplemente un dibujo estático y algo de texto. Lo recibido cobra vida. Además, con Java podemos estar seguros de que el código que hace funcionar el experimento químico no contiene ningún trozo de código malicioso que dañe al sistema. El código que intente actuar destructivamente o que contenga errores, no podrá traspasar los muros defensivos colocados por las características de seguridad y robustez de Java. Además, Java proporciona una nueva forma de acceder a las aplicaciones. El software viaja transparentemente a través de la red. No hay necesidad de instalar las aplicaciones, ellas mismas vienen cuando se necesitan. Por ejemplo, la mayoría de los navegadores del Web pueden procesar un reducido número de formatos gráficos (típicamente GIF y JPEG). Si se encuentran con otro tipo de formato, el navegador estándar no tiene capacidad para procesarlo, tendría que ser actualizado para poder aprovechar las ventajas del nuevo formato. Sin embargo, un navegador con soporte Java puede enlazar con el servidor que contiene el algoritmo que procesa ese nuevo formato y mostrar la imagen. Por lo tanto, si alguien inventa un nuevo algoritmo de compresión para

Manual de Java


imágenes, el inventor sólo necesita estar seguro de que hay una copia en código Java de ese algoritmo instalada en el servidor que contiene las imágenes que quiere publicar. Es decir, los navegadores con soporte Java se actualizan a sí mismos sobre la marcha, cuando encuentran un nuevo tipo de fichero o algoritmo. En esta filosofía es en la que se basan los NC (Network Computer), que serán ordenadores sin disco y con mucha memoria. Sus programas residen en un servidor que se los envía cuando los solicita. Es quizá un guiño al pasado y una versión futurista de lo que ha sido un Terminal-X en otros tiempos, salvando las diferencias, evidentemente (no sea que alguien me tilde de irreverente con las nuevas tecnologías).

2. Programación Cliente-Servidor Java es un nuevo lenguaje de programación, como tantos otros. Así que uno se pregunta el por qué del revuelo que se ha formado con su aparición. La respuesta no es inmediatamente obvia si se observa el asunto desde el punto de vista de la programación tradicional, porque aunque resuelve algunos de los problemas típicos de este tipo de programación, lo que verdaderamente es importante es que también resuelve los problemas que se generan en Internet, en la Telaraña Mundial, en el World-Wide-Web, en la Web. Internet puede resultar algo misterioso al principio, sobre todo porque se utiliza un vocabulario propio, que hasta que no se domina, uno anda un poco despistado. Pero, en esencia, Internet es un sistema Cliente-Servidor gigante. La idea primaria de un sistema cliente-servidor es que debe haber un sitio donde se centraliza la información, que se desea distribuir bajo demanda a un conjunto de personas o máquinas. La clave de este concepto radica en que si se produce un cambio en la información del sistema central, inmediatamente es propagada a los receptores de la información, a la parte cliente. Luego, el concepto básico es muy simple; el problema se presenta cuando hay solamente un servidor que tiene colgados a muchos clientes, en que el rendimiento general del sistema decrece de forma exponencial al aumento del número de clientes. El funcionamiento de la Web sigue este mismo principio. Inicialmente, se solicita una información a un servidor y éste envía de vuelta un fichero que será interpretado por el navegador (el cliente) que lo formateará para visualizarlo en la máquina cliente. El navegador fue el primer paso adelante en la expansión de Internet, ya que permitía visualizar un mismo fichero en plataformas diferentes sin hacerle cambio alguno; pero su finalidad principal es la visualización de ficheros, no la interactividad con el usuario, ni la posibilidad de ejecutar programas en la parte del usuario, en la parte cliente del sistema. Para proporcionar un poco de interactividad, se dotó al lenguaje HTML de ciertos mecanismos básicos de entrada de datos, como botones, cajas de selección, campos de texto, y algunos otros; pero la carga que incorporaban al sistema caía del todo dentro del lado del servidor, con lo cual, si había muchos clientes colgando, el colapso del servidor era casi seguro. Así que surgieron algunas alternativas a los CGI, para que se pudiese descargar al servidor de tanto trabajo y que el cliente realizase también operaciones.

Manual de Java


3. Plug-ins Esto son piezas de código que se incorporan al navegador y le indican que "a partir de ahora dispones de una nueva característica". Hay características que se añaden a los navegadores a través de plug-ins que son muy rápidas y eficientes, pero el problema es que escribir un plug-in no es una tarea trivial ni tampoco es algo que haya que hacer en el proceso de construcción de un Site. Luego los plug-ins son herramientas válidas para programadores muy expertos que permiten incorporar características nuevas al navegador sin necesidad de que el vendedor conceda su permiso.

4. Scripts Un lenguaje script permite embeber código fuente para la programación del lado cliente, directamente en la página HTML, y el plug-in que interpreta ese lenguaje se activará automáticamente cuando se cargue en el navegador. Estos lenguajes tienden a ser muy simples y sencillos, además se cargan muy rápidamente porque van incluidos en la página que envía el servidor. La pega es que el código del programador está expuesto a la vista de cualquiera, aunque tampoco se pueden hacer demasiadas filigranas con un lenguaje script. Estos lenguajes se utilizan fundamentalmente para hacer más atractivos las interfaces gráficas de las páginas, porque disponen de elementos gráficos y pueden llegar a resolver el 80% de los problemas que se plantean en la programación de la parte cliente del sistema cliente-servidor; y, además, son lenguajes mucho más sencillos de aprender e implementar soluciones con ellos que recurrir a Java o ActiveX. Siempre que los problemas de el caigan dentro de ese 80% que son capaces de resolver los lenguajes script, y el programador se encuentre cómodo con este tipo de lenguajes, serían la elección prioritaria, antes de adentrarse en las profundidades que representa siempre el estudio de un nuevo lenguaje de programación. El lenguaje script más utilizado es JavaScript, que no tiene nada que ver con Java, me imagino que se llamará así para aprovechar el tirón de popularidad de Java, pero también se puede realizar scripts en la parte cliente con Visual Basic o con Tcl/Tk.

5. Java ¿Y qué pasa con el 20% de los problemas que no pueden resolver los lenguajes script? La respuesta más común, si se hiciese una encuesta, sería Java, y no solamente porque sea un poderoso lenguaje de programación enfocado a la seguridad, multi-plataforma e internacional, sino porque Java está siendo continuamente extendido para proporcionarle nuevas características y librerías que resuelven elegantemente problemas que son muy difíciles en la programación tradicional como el acceso a bases de datos, el uso de multihilo, la programación de redes y la programación distribuida, y además porque Java, a través de los applets, permite la programación de la parte cliente. Un applet es un miniprograma que corre solamente bajo un navegador y es descargado automáticamente como parte de una página Web, al igual que cualquier gráfico, y cuando se activa, ejecuta un programa. Este es el interés, proporciona una forma a través de la cual se puede distribuir software al cliente desde el servidor, en el momento en que el cliente necesite ese software, y no

Manual de Java


antes, con lo cual siempre tendrá el cliente la última versión de ese software, se actualice cuando se actualice. Además, tal como está diseñado Java, el programador necesita crear su programa una sola vez, y ya estará listo para ser ejecutado en todas las plataformas que dispongan de un navegador con soporte Java. Con Java se podrá realizar tanto trabajo como sea posible en el cliente antes y después de hacer peticiones al servidor. Por ejemplo, se puede evitar el enviar una petición a través de Internet mientras el usuario no haya introducido los parámetros correctos de esa petición, que estará chequeando el cliente, sin necesidad de tener que consultar continuamente al servidor; con ello se gana en velocidad de respuesta ante el usuario, una reducción general en el tráfico de red y una gran descarga de trabajo para el servidor. Una de las ventajas de los applets sobre los scripts es que están en forma compilada, con lo cual el código fuente no es visible; aunque se puede descompilar sin demasiadas complicaciones, pero vamos, no está del todo accesible. Además, un applet puede comprimir varios módulos, utilizando ficheros JAR, evitando múltiples conexiones con el servidor, ya que en una sola se descargan todos los componentes necesarios. Y, finalmente, está la curva de aprendizaje, porque a pesar de lo que el lector haya podido escuchar o leer por ahí, Java no es un lenguaje trivial. Si el lector domina Visual Basic, por ejemplo, el que realice sus trabajos en VBscript le resultará más fácil y rápido y resolverá sus problemas de programación cliente-servidor sin embarcarse en la dura empresa de aprender Java.

6. ActiveX La competencia directa de Java es ActiveX, de Microsoft, aunque su enfoque sea bastante diferente. ActiveX es originalmente una solución orientada a entornos Windows, aunque parece ser que ahora está siendo desarrollado para ser multi-plataforma. Lo que hace ActiveX es decir "si tu programa se conecta a este entorno, se podrá descargar en una página Web y correr bajo un navegador que soporte controles ActiveX". Microsoft. Internet Explorer soporta ActiveX directamente y Netscape lo soporta a través de plug-in. Por lo tanto, ActiveX no está constreñido a un solo lenguaje de programación, sino que se pueden desarrollar componentes ActiveX en el lenguaje que domine el programador, ya sea C++, Visual Basic o el Delphi de Borland.

7. Scriptlets Microsoft ha subido una vez más la apuesta en su batalla contra Java con el lanzamiento de los scriplets, que son similares en naturaleza a los componentes JavaBeans, y aparecen como una campaña de vaporware por parte de Microsoft. Su aparente meta es posicionar esta tecnología como un potencial rival multi-platafroma de Java, que, según dice Microsoft, no cumple su compromiso de ser tan manejable como propugna su publicidad. Los scriplets, a diferencia de Java, sólo se pueden utilizar sobre un navegador Web. Si bien es cierto que a los applets les ocurre lo mismo, Java deja abierta la posibilidad de crear aplicaciones, dependientes de una máquina virtual Java, pero no de un navegador; y en cuanto la máquina virtual Java se encuentra incluida en el propio sistema operativo, el usuario no advierte dependencia

Manual de Java


alguna. La verdad es que los scriplets no aportan nada nuevo a las posibilidades de las herramientas actuales, sino que son otra forma de hacer lo mismo. La descarga y ejecución automática de programas a través de Internet, en principio, suena como el sueño de cualquier creador de virus. Los componentes ActiveX son especialmente sensibles a este ataque, ya que se puede hacer lo que se quiera, sin control alguno, con lo cual, el usuario puede bajarse un componente ActiveX que haga estragos en su máquina. Esto no es nuevo, sino que es un problema largamente conocido desde los tiempos de las BBS, pero que aquí se ve amplificado por la velocidad de Internet. Cuando se pide una página Web, se reciben ficheros gráficos, el código de la página (con o sin scripts), código Java precompilado y componentes ActiveX. De estos, algunos son casi inofensivos, como los ficheros gráficos y el código HTML de la página, porque es muy poco lo que se puede manipular sobre ellos. Java está diseñado para ejecutar los applets en una caja cerrada (sand box), envuelta en una capa de seguridad que impide cualquier acceso a disco o a memoria que se encuentre fuera de esa caja cerrada. Así que, la parte más propensa a introducir elementos no deseados en la máquina cliente son los componentes ActiveX. Actualmente se está intentando paliar esta desagradable posibilidad a través de las firmas digitales, que permiten reconocer al autor. Esta idea parte de que los autores de virus normalmente son anónimos, y si se eliminan estos componentes anónimos, siempre se podrá forzar al programador a que sea responsable de sus acciones. Puede ser una buena idea, porque permitirá a los programas ser más funcionales, aunque si un programa tiene un bug inadvertido que pueda resultar destructivo, todavía podrá causar problemas. Con respecto a Java, hay diversas opiniones respecto a la draconiana restricción a que un applet no pueda escribir en el disco local del cliente; porque, que pasa si el usuario quiere crear una base de datos local, o quiere guardar cualquier tipo de información para cuando se encuentre desconectado de Internet. La asunción inicial de que todo el mundo estaría conectado es impracticable, aunque si se redujesen los precios del teléfono, pudiese llegar a ser el estado normal de muchos usuarios; así que la solución debe llegar por otra vía. Los applets firmados, que utilizan una clave pública para comprobar que el applet viene del lugar correcto y no ha sido manipulado puede ser una de esas soluciones. Desde Java 1.1 se dispone de un entorno para implementar firmas digitales, por lo que sí fuese necesario se podría hacer que un applet se saliese de su caja cerrada.

8. Java en "dos palabras" A continuación se explica de forma muy resumida y básica cómo funciona Java, extendiendo las pinceladas que se han soltado en secciones anteriores, porque es importante conocer el funcionamiento del lenguaje para saber cuáles son sus virtudes y cuáles sus defectos. Esto son cosas muy básicas sobre Java, por lo que va dirigido a aquellos lectores que no posean conocimientos algo avanzados. Java es el primer lenguaje que tiene la virtud de ser compilado e interpretado de forma simultánea. Cuando un programador realiza una aplicación o un applet en Java y lo compila, en realidad, el compilador no trabaja como un

Manual de Java


compilador de un lenguaje al uso. El compilador Java únicamente genera el denominado ByteCode. Este código es un código intermedio entre el lenguaje máquina del procesador y Java. Evidentemente este código no es ejecutable por sí mismo en ninguna plataforma hardware, pues no se corresponde con el lenguaje de ninguno de los procesadores que actualmente se conocen (habrá que esperar a ver qué ocurre con los procesadores Java). Por lo tanto, para ejecutar una aplicación Java es necesario disponer de un mecanismo que permita ejecutar el ByteCode. Este mecanismo es la denominada Máquina Virtual Java. En cada plataforma (Unix, Linux, Windows 95/NT, Macintosh, etc.) existe una máquina virtual específica. Así que cuando el ByteCode llega a la máquina virtual, ésta lo interpreta pasándolo a código máquina del procesador donde se esté trabajando, y ejecutando las instrucciones en lenguaje máquina que se deriven de la aplicación Java. De este modo, cuando el mismo ByteCode llega a diferentes plataformas, éste se ejecutará de forma correcta, pues en cada una de esas plataformas existirá la máquina virtual adecuada. Con este mecanismo se consigue la famosa multi-plataforma de Java, que con sólo codificar una vez, podemos ejecutar en varias plataformas. En realidad la máquina virtual desempeña otras funciones, como la de aislar los programas Java al entorno de la máquina virtual, consiguiendo una gran seguridad. Sin embargo, como podrá estar deduciendo el lector, esto tiene algunas desventajas, y la más clara es la velocidad de ejecución. Puesto que la máquina virtual debe estar interpretando constantemente el ByteCode, se consume demasiado tiempo de procesador en realizar esta interpretación, que por otra parte no aporta nada a la aplicación, obteniendo así un bajo rendimiento. Para solucionarlo se han adoptado soluciones intermedias. Una de las más novedosas y útiles son los compiladores JIT (Just-In-Time). Estos compiladores están situados a la entrada de la máquina virtual, de forma que según llega el ByteCode lo van compilando al lenguaje máquina del procesador. A diferencia de la interpretación, el compilador no ejecuta el ByteCode, únicamente lo traduce y lo almacena en código nativo dentro de la máquina virtual. Así, una vez que la aplicación está dentro de la máquina virtual, ya se encuentra en lenguaje máquina y, por lo tanto, será directamente ejecutable, sin necesidad de interpretaciones, consiguiendo dotar de mayores rendimientos a la aplicación. Que Java es lento, resultará pues evidente, pero vamos, hasta los más pesimistas respecto a Java, como Microsoft, reconocen que Java obtendrá gracias a los compiladores JIT un rendimiento cercano al 80% del de C++, lo cual es más que suficiente para la mayoría de las aplicaciones; y más aún si se tiene en cuenta el sector al cual va dirigido Java, porque, al fin y al cabo, tampoco se trata de escribir el Doom III en Java. No obstante, el uso de ByteCode no es la única causa de que Java sea más lento que C++. Porque este último lenguaje no tiene un recolector de basura, ni que cargar clases dinámicamente, ni realizar comprobaciones en tiempo de ejecución como la de los límites de los arrays, las condiciones de seguridad o que el ByteCode no esté manipulado para acceder ilegalmente a campos marcados como privados o protegidos. Estas características suponen una sobrecarga importante, sólo el recolector de basura puede superar el 15%, y son la causa última de que Java no pueda alcanzar el cien por cien del rendimiento de C++. A pesar de todo, hay grandes expectativas en la compilación dinámica y en la propia mejora de los elementos que integran la máquina virtual como el recolector de basura,

Manual de Java


porque afortunadamente, a diferencia de otras ocasiones, muchas empresas e investigadores no se han quedado en una queja estéril y se han puesto a trabajar para solucionar estas cuestiones. A cambio de este incremento de la carga se obtiene mayor fiabilidad, lo que reduce ostensiblemente el coste de mantenimiento y un sinfín de nuevas posibilidades. Muy breve y de forma muy genérica, este es el funcionamiento básico de Java. Todas las mejoras al lenguaje se centran básicamente en conseguir mejores tiempos de ejecución y dotar de mayores prestaciones a la máquina virtual.

9. Origen de Java Sun Microsystems, líder en servidores para Internet, uno de cuyos lemas desde hace mucho tiempo ha sido "the network is the computer" (lo que quiere dar a entender que el verdadero ordenador es la red en su conjunto y no cada máquina individual), es quien ha inventado el lenguaje Java, en un intento de resolver simultáneamente todos los problemas que se planteaban a los desarrolladores de software por la proliferación de arquitecturas incompatibles, tanto entre las diferentes máquinas como entre los diversos sistemas operativos y sistemas de ventanas que funcionan sobre una misma máquina, añadiendo la dificultad de crear aplicaciones distribuidas en una red como Internet. He podido leer más de cinco versiones distintas sobre el origen, concepción y desarrollo de Java, desde la que dice que este fue un proyecto que rebotó durante mucho tiempo por distintos departamentos de Sun sin que nadie le prestara ninguna atención, hasta que finalmente encontró su nicho de mercado en la aldea global que es Internet; hasta la más difundida, que justifica a Java como lenguaje de pequeños electrodomésticos. Hace algunos años, Sun Microsystems decidió intentar introducirse en el mercado de la electrónica de consumo y desarrollar programas para pequeños dispositivos electrónicos. Tras unos comienzos dudosos, Sun decidió crear una filial, denominada FirstPerson Inc., para dar margen de maniobra al equipo responsable del proyecto. El mercado inicialmente previsto para los programas de FirstPerson eran los equipos domésticos: microondas, tostadoras y, fundamentalmente, televisión interactiva. Este mercado, dada la falta de sofisticación de los usuarios, requerían de interfaces mucho más cómodos e intuitivos que los sistemas de ventanas que proliferaban en el momento. Otros requisitos importantes eran la fiabilidad del código y la facilidad de desarrollo. James Gosling, el miembro del equipo con más experiencia en lenguajes de programación, decidió que las ventajas de eficiencia de C++ no compensaban el gran coste de pruebas y depuración. Gosling había estado trabajando en su tiempo libre en un lenguaje de programación que él había llamado Oak, según parece el nombre se debe al roble que se veía por la ventana de su casa (¡originalidad ante todo!), el cual, aún partiendo de la sintaxis de C++, intentaba remediar las deficiencias que había observado. Los lenguajes al uso, como C o C++, deben ser compilados para un chip, y si se cambia el chip, todo el software debe compilarse de nuevo. Esto encarece mucho los desarrollos y el problema es especialmente acusado en el campo de la electrónica de consumo. La aparición de un chip más barato y, generalmente, más eficiente, conduce inmediatamente a los fabricantes a incluirlo en las nuevas series de sus cadenas de producción, por pequeña que

Manual de Java


sea la diferencia en precio ya que, multiplicada por la tirada masiva de los aparatos, supone un ahorro considerable. Por tanto, Gosling decidió mejorar las características de Oak y utilizarlo. El primer proyecto en que se aplicó este lenguaje recibió el nombre de proyecto Green y consistía en un sistema de control completo de los aparatos electrónicos y el entorno de un hogar. Para ello se construyó un ordenador experimental denominado *7 (Star Seven). El sistema presentaba una interfaz basada en la representación de la casa de forma animada y el control se llevaba a cabo mediante una pantalla sensible al tacto. En el sistema aparecía Duke, la actual mascota de Java. Posteriormente se aplicó a otro proyecto denominado VOD (Video On Demand) en el que se empleaba como interfaz para la televisión interactiva. Ninguno de estos proyectos se convirtió nunca en un sistema comercial, pero fueron desarrollados enteramente en un Java primitivo y fueron como su bautismo de fuego. Una vez que en Sun se dieron cuenta de que a corto plazo la televisión interactiva no iba a ser un gran éxito, urgieron a FirstPerson a desarrollar con rapidez nuevas estrategias que produjeran beneficios. No lo consiguieron y FirstPerson cerró en la primavera de 1994. Pese a lo que parecía ya un olvido definitivo, Bill Joy, cofundador de Sun y uno de los desarrolladores principales del Unix de Berkeley, juzgó que Internet podría llegar a ser el campo de juego adecuado para disputar a Microsoft su primacía casi absoluta en el terreno del software, y vio en Oak el instrumento idóneo para llevar a cabo estos planes. Tras un cambio de nombre y algunos de diseño, el lenguaje Java fue presentado en sociedad en agosto de 1995. Lo mejor será hacer caso omiso de las historias que pretenden dar carta de naturaleza a la clarividencia industrial de sus protagonistas; porque la cuestión es si independientemente de su origen y entorno comercial, Java ofrece soluciones a nuestras expectativas. Porque tampoco vamos a desechar la penicilina aunque haya sido su origen fruto de la casualidad.

10. Características de Java Las características principales que nos ofrece Java respecto a cualquier otro lenguaje de programación, serían: Simple Java ofrece toda la funcionalidad de un lenguaje potente, pero sin las características menos usadas y más confusas de éstos. C++ no es un lenguaje conveniente por razones de seguridad, pero C y C++ son los lenguajes más difundidos, por ello Java se diseñó para ser parecido a C++ y así facilitar un rápido y fácil aprendizaje. Java elimina muchas de las características de otros lenguajes como C++, para mantener reducidas las especificaciones del lenguaje y añadir características muy útiles como el garbage collector (reciclador de memoria dinámica). No es necesario preocuparse de liberar memoria, el reciclador se encarga de ello y como es de baja prioridad, cuando entra en acción, permite liberar bloques de memoria muy grandes, lo que limita en mucho la fragmentación de la memoria. Java reduce en un 50% los errores más comunes de programación con lenguajes como C y C++ al eliminar muchas de las características de éstos, entre las que destacan:

• aritmética de punteros • no existen referencias

Manual de Java


• registros (struct) • definición de tipos (typedef) • macros (#define) • necesidad de liberar memoria (free)

Aunque, en realidad, lo que hace es eliminar las palabras reservadas (struct, typedef), ya que las clases son algo parecido. Además, el intérprete completo de Java que hay en este momento es muy pequeño, solamente ocupa 215 Kb de RAM.

11. Orientado a Objetos Java implementa la tecnología básica de C++ con algunas mejoras y elimina algunas cosas para mantener el objetivo de la simplicidad del lenguaje. Java trabaja con sus datos como objetos y con interfaces a esos objetos. Soporta las tres características propias del paradigma de la orientación a objetos: encapsulación, herencia y polimorfismo. Las plantillas de objetos son llamadas, como en C++, clases y sus copias, instancias. Estas instancias, como en C++, necesitan ser construidas y destruidas en espacios de memoria. Java incorpora funcionalidades inexistentes en C++ como por ejemplo, la resolución dinámica de métodos. Esta característica deriva del lenguaje Objective C, propietario del sistema operativo Next. En C++ se suele trabajar con librerías dinámicas (DLLs) que obligan a recompilar la aplicación cuando se retocan las funciones de su interior. Este inconveniente es resuelto por Java mediante una interfaz específica llamada RTTI (RunTime Type Identification) que define la interacción entre objetos excluyendo variables de instancias o implementación de métodos. Las clases en Java tienen una representación en el runtime que permite a los programadores interrogar por el tipo de clase y enlazar dinámicamente la clase con el resultado de la búsqueda.

12. Distribuido Java se ha construido con extensas capacidades de interconexión TCP/IP. Existen librerías de rutinas para acceder e interactuar con protocolos como http y ftp. Esto permite a los programadores acceder a la información a través de la red con tanta facilidad como a los ficheros locales. Java en sí no es distribuido, sino que proporciona las librerías y herramientas para que los programas puedan ser distribuidos, es decir, que se corran en varias máquinas, interactuando.

13. Robusto Java realiza verificaciones en busca de problemas tanto en tiempo de compilación como en tiempo de ejecución. La comprobación de tipos en Java ayuda a detectar errores, lo antes posible, en el ciclo de desarrollo. Java obliga a la declaración explícita de métodos, reduciendo así las posibilidades de error. Maneja la memoria para eliminar las preocupaciones por parte del programador de la liberación o corrupción de memoria.

Manual de Java


También implementa los arrays auténticos, en vez de listas enlazadas de punteros, con comprobación de límites, para evitar la posibilidad de sobreescribir o corromper memoria resultado de punteros que señalan a zonas equivocadas. Estas características reducen drásticamente el tiempo empleado en el desarrollo de aplicaciones Java. Además, para asegurar el funcionamiento de la aplicación, realiza una verificación de los ByteCodes, que son el resultado de la compilación de un programa Java. Es un código de máquina virtual que es interpretado por el intérprete Java. No es el código máquina directamente entendible por el hardware, pero ya ha pasado todas las fases del compilador: análisis de instrucciones, orden de operadores, etc., y ya tiene generada la pila de ejecución de órdenes. Java proporciona, pues:

• Comprobación de punteros • Comprobación de límites de arrays • Excepciones • Verificación de ByteCodes • Arquitectura Neutral

Para establecer Java como parte integral de la red, el compilador Java compila su código a un fichero objeto de formato independiente de la arquitectura de la máquina en que se ejecutará. Cualquier máquina que tenga el sistema de ejecución (run-time) puede ejecutar ese código objeto, sin importar en modo alguno la máquina en que ha sido generado. Actualmente existen sistemas run-time para Solaris 2.x, SunOs 4.1.x, Windows '95, Windows NT, Linux, Irix, Aix, Mac, Apple y probablemente haya grupos de desarrollo trabajando en el porting a otras plataformas.

El código fuente Java se "compila" a un código de bytes de alto nivel independiente de la máquina. Este código (ByteCode) está diseñado para ejecutarse en una máquina hipotética que es implementada por un sistema run-time, que sí es dependiente de la máquina. En una representación en que tuviésemos que indicar todos los elementos que forman parte de la arquitectura de Java sobre una plataforma genérica, obtendríamos una imagen como la siguiente:

Manual de Java


En ella podemos ver que lo verdaderamente dependiente del sistema es la Máquina Virtual Java (JVM) y las librerías fundamentales, que también permitirían acceder directamente al hardware de la máquina. Además, siempre habrá APIs de Java que también entren en contacto directo con el hardware y serán dependientes de la máquina, como ejemplo de este tipo de APIs podemos citar:

• Swing : Mejora de las herramientas para la implementación de interfaces de usuario

• Java 2d: gráficos 2D y manipulación de imágenes • Java Media Framework: Elementos críticos en el tiempo: audio, vídeo... • Java Animation: Animación de objetos en 2D • Java Telephony: Integración con telefonía • Java Share: Interacción entre aplicaciones multiusuario • Java 3d: Gráficos 3D y su manipulación

La siguiente figura ilustra la situación en que se encuentra Java cuando se ejecuta sobre un sistema operativo convencional. En la imagen se observa que si se exceptúa la parte correspondiente al Sistema Operativo que ataca directamente al hardware de la plataforma, el resto está totalmente programado por Javasoft o por los programadores Java, teniendo en cuenta que HotJava es una aplicación en toda regla, al tratarse de un navegador y estar desarrollado en su totalidad en Java. Cualquier programador podría utilizar las mismas herramientas para levantar un nuevo desarrollo en Java, bien fuesen applets para su implantación en Internet o aplicaciones para su uso individual.

Manual de Java


Y la imagen que aparece a continuación muestra la arquitectura de Java sin un Sistema Operativo que lo ampare, de tal forma que el kernel tendría que proporcionar suficientes posibilidades como para implementar una Máquina Virtual Java y los drivers de dispositivos imprescindibles como pantalla, red, ratón, teclado y la base para poder desarrollar en Java librerías como AWT, ficheros, red, etc. Con todo ello estaría asegurado el soporte completo del API de Java, quedando en mano de los desarrolladores la implementación de aplicaciones o applets o cualquier otra librería.

14. Seguro La seguridad en Java tiene dos facetas. En el lenguaje, características como los punteros o el casting implícito que hace el compilador de C y C++ se eliminan para prevenir el acceso ilegal a la memoria. Cuando se usa Java para crear un navegador, se combinan las características del lenguaje con protecciones de sentido común aplicadas al propio navegador. El lenguaje C, por ejemplo, tiene lagunas de seguridad importantes, como son los errores de alineación. Los programadores de C utilizan punteros en conjunción con operaciones aritméticas. Esto le permite al programador que un puntero referencie a un lugar conocido de la memoria y pueda sumar (o restar) algún valor, para referirse a otro lugar de la memoria. Si otros programadores conocen nuestras estructuras de datos pueden extraer información confidencial de nuestro sistema. Con un lenguaje como C, se pueden tomar números enteros aleatorios y convertirlos en punteros para luego acceder a la memoria: printf( "Escribe un valor entero: " ); scanf( "%u",&puntero ); printf( "Cadena de memoria: %s\n",puntero ); Otra laguna de seguridad u otro tipo de ataque, es el Caballo de Troya. Se presenta un programa como una utilidad, resultando tener una funcionalidad destructiva. Por ejemplo, en UNIX se visualiza el contenido de un directorio con el comando ls. Si un programador deja un comando destructivo bajo esta referencia, se puede correr el riesgo de ejecutar código malicioso, aunque el comando siga haciendo la funcionalidad que se le supone, después de lanzar su carga destructiva. Por ejemplo, después de que el caballo de Troya haya enviado por correo el /etc/shadow a su creador, ejecuta la funcionalidad de ls

Manual de Java


presentando el contenido del directorio. Se notará un retardo, pero nada inusual. El código Java pasa muchos tests antes de ejecutarse en una máquina. El código se pasa a través de un verificador de ByteCode que comprueba el formato de los fragmentos de código y aplica un probador de teoremas para detectar fragmentos de código ilegal -código que falsea punteros, viola derechos de acceso sobre objetos o intenta cambiar el tipo o clase de un objeto-. Si los ByteCodes pasan la verificación si generar ningún mensaje de error, entonces sabemos que:

• El código no produce desbordamiento de operandos en la pila • El tipo de los parámetros de todos los códigos de operación son

conocidos y correctos • No ha ocurrido ninguna conversión ilegal de datos, tal como convertir

enteros en punteros • El acceso a los campos de un objeto se sabe que es legal: public,

private, protected • No hay ningún intento de violar las reglas de acceso y seguridad

establecidas El Cargador de Clases también ayuda a Java a mantener su seguridad, separando el espacio de nombres del sistema de ficheros local del de los recursos procedentes de la red. Esto limita cualquier aplicación del tipo Caballo de Troya, ya que las clases se buscan primero entre las locales y luego entre las procedentes del exterior. Las clases importadas de la red se almacenan en un espacio de nombres privado, asociado con el origen. Cuando una clase del espacio de nombres privado accede a otra clase, primero se busca en las clases predefinidas (del sistema local) y luego en el espacio de nombres de la clase que hace la referencia. Esto imposibilita que una clase suplante a una predefinida. En resumen, las aplicaciones de Java resultan extremadamente seguras, ya que no acceden a zonas delicadas de memoria o de sistema, con lo cual evitan la interacción de ciertos virus. Java no posee una semántica específica para modificar la pila de programa o la memoria libre o utilizar objetos y métodos de un programa sin los privilegios del kernel del sistema operativo. Además, para evitar modificaciones por parte de los crackers de la red, implementa un método ultraseguro de autentificación por clave pública. El Cargador de Clases puede verificar una firma digital antes de realizar una instancia de un objeto. Por tanto ningún objeto se crea y almacena en memoria, sin que se validen los privilegios de acceso. Es decir, la seguridad se integra en el momento en que se interpreta, con el nivel de detalle y de privilegio que sea necesario. Con código compilado no sería posible establecer estos niveles de seguridad entre dos objetos pertenecientes al mismo proceso, porque al compartir un único espacio de direcciones, el código de uno podría acceder tranquilamente a cualquier dirección del otro. Dada, pues la concepción del lenguaje y si todos los elementos se mantienen dentro del estándar marcado por Sun, no hay peligro. Java imposibilita, también, abrir ningún fichero de la máquina local (siempre que se realizan operaciones con archivos, éstas trabajan sobre el disco duro de la máquina de donde partió el applet), no permite ejecutar ninguna aplicación nativa de una plataforma e impide que se utilicen otros ordenadores como puente, es decir,

Manual de Java


nadie puede utilizar nuestra máquina para hacer peticiones o realizar operaciones con otra. Además, los intérpretes que incorporan los navegadores de la Web son aún más restrictivos. Bajo estas condiciones (y dentro de la filosofía de que el único ordenador seguro es el que está apagado, desenchufado, dentro de una cámara acorazada en un bunker y rodeado por mil soldados de los cuerpos especiales del ejército), se puede considerar que Java es un lenguaje seguro y que los applets están libres de virus. Respecto a la seguridad del código fuente, no ya del lenguaje, el propio JDK proporciona un desensamblador de ByteCode, lo cual hace que cualquier programa pueda ser convertido a código fuente, lo que para el programador significa una vulnerabilidad total a su código. Utilizando java no se obtiene el código fuente original, pero sí desmonta el programa mostrando el algoritmo que se utiliza, que es lo realmente interesante. La protección de los programadores ante esto es utilizar llamadas a programas nativos, externos (incluso en C o C++) de forma que no sea descompilable todo el código; aunque así se pierda portabilidad. Es otra de las cuestiones que Java tiene pendientes.

15. Portable Más allá de la portabilidad básica por ser de arquitectura independiente, Java implementa otros estándares de portabilidad para facilitar el desarrollo. Los enteros son siempre enteros y además, enteros de 32 bits en complemento a 2. Además, Java construye sus interfaces de usuario a través de un sistema abstracto de ventanas de forma que las ventanas puedan ser implantadas en entornos Unix, Pc o Mac.

16. Interpretado El intérprete Java (sistema run-time) puede ejecutar directamente el código objeto. Enlazar (linkar) un programa normalmente consume menos recursos que compilarlo, por lo que los desarrolladores con Java pasarán más tiempo desarrollando y menos esperando por el ordenador. No obstante, el compilador actual del JDK es bastante lento. Por ahora, que todavía no hay compiladores específicos de Java para las diversas plataformas, Java es más lento que otros lenguajes de programación, como C++, ya que debe ser interpretado y no ejecutado como sucede en cualquier programa tradicional. Se dice que Java es de 10 a 30 veces más lento que C, y que tampoco existen en Java proyectos de gran envergadura como en otros lenguajes. La verdad es que ya hay comparaciones ventajosas entre Java y el resto de los lenguajes de programación, y una ingente cantidad de folletos electrónicos que supuran fanatismo en favor y en contra de los distintos lenguajes contendientes con Java. Lo que se suele dejar de lado en todo esto, es que primero habría que decidir hasta que punto Java, un lenguaje en pleno desarrollo y todavía sin definición definitiva, está maduro como lenguaje de programación para ser comparado con otros; como por ejemplo con Smalltalk, que lleva más de 20 años en cancha. La verdad es que Java para conseguir ser un lenguaje independiente del sistema operativo y del procesador que incorpore la máquina utilizada, es tanto interpretado como compilado. Y esto no es ningún contrasentido, me explico, el código fuente escrito con cualquier editor se compila generando el ByteCode.

Manual de Java


Este código intermedio es de muy bajo nivel, pero sin alcanzar las instrucciones máquina propias de cada plataforma y no tiene nada que ver con el p-code de Visual Basic. El ByteCode corresponde al 80% de las instrucciones de la aplicación. Ese mismo código es el que se puede ejecutar sobre cualquier plataforma. Para ello hace falta el runtime, que sí es completamente dependiente de la máquina y del sistema operativo que interpreta dinámicamente el ByteCode y añade el 20% de instrucciones que faltaban para su ejecución. Con este sistema es fácil crear aplicaciones multi-plataforma, pero para ejecutarlas es necesario que exista el runtime correspondiente al sistema operativo utilizado.

No obstante, este panorama está cambiando a pasos agigantados, y aunque Java sigue siendo básicamente un lenguaje interpretado, la situación se acerca mucho a la de los programas compilados, sobre todo en lo que a la rapidez en la ejecución del código se refiere. Para comprender el funcionamiento de HotSpot, que es el último lanzamiento que hace Sun y que promete interpretar los ByteCodes más rápido que un programa compilado, las siguientes imágenes muestran cómo actúa el sistema runtime en los diversos casos que hasta ahora pueden darse.

Manual de Java


La imagen de la izquierda muestra las acciones correspondientes a un compilador tradicional. El compilador traslada las sentencias escritas en lenguaje de alto-nivel a múltiples instrucciones, que luego son enlazadas junto con el resultado de múltiples compilaciones previas que han dado origen a librerías, y juntando todo ello, es cuando genera un programa ejecutable. La imagen de arriba muestra la forma de actuación de un intérprete. Básicamente es un enorme bucle, en el cual se va leyendo o recogiendo cada una de las instrucciones del programa fuente que se desea ejecutar, se analiza, se parte en trozos y se ejecuta. Luego se va a recoger la siguiente instrucción que se debe interpretar y se continúa con este proceso hasta que se terminan las instrucciones o hasta que entre las instrucciones hay alguna que contiene la orden de detener la ejecución de las instrucciones que componen el programa fuente.

La imagen siguiente, muestra un tipo de intérprete más eficiente que el anterior, el intérprete de ByteCodes, que fue popularizado hace más de veinte años por la Universidad de California al crear el UCSD Pascal. En este caso, el intérprete trabaja sobre instrucciones que ya han sido trasladadas a un código intermedio en un paso anterior. Así, aunque se ejecute en un bucle, se elimina la necesidad de analizar cada una de las instrucciones que componen el programa fuente, porque ya lo han sido en el paso previo. Este es el sistema que Java utiliza, y la Máquina Virtual Java es un ejemplo de este tipo de intérprete. No obstante, sigue siendo lento, aunque se obtenga un código independiente de plataforma muy compacto, que puede ser ejecutado en

Manual de Java


cualquier ordenador que disponga de una máquina virtual capaz de interpretar los ByteCodes trasladados.

Un paso adelante en el rendimiento del código Java lo han representado los compiladores Just-In-Time, que compilan el código convirtiéndolo a código máquina antes de ejecutarlo. Es decir, un compilador JIT va trasladando los ByteCodes al código máquina de la plataforma según los va leyendo, realizando un cierto grado de optimización. El resultado es que cuando el programa se ejecute, habrá partes que no se ejecuten y que no serán compiladas, y el compilador JIT no perderá el tiempo en optimizar código que nunca se va a ejecutar. No obstante, los compiladores JIT no pueden realizar demasiadas optimizaciones, ya que hay código que ellos no ven, así que aunque siempre son capaces de optimizar la parte de código de inicialización de un programa, hay otras partes que deben ser optimizadas, según se van cargando, con lo cual, hay una cierta cantidad de tiempo que inevitablemente ha de perderse. Y, finalmente, se presenta la última tendencia en lo que a compilación e intérpretes se refiere. Lo último en que trabaja Sun es HotSpot, una herramienta que incluye un compilador dinámico y una máquina virtual para interpretar los ByteCodes, tal como se muestra en la figura siguiente, situada a la izquierda de la página. Cuando se cargan los ByteCodes producidos por el compilador por primera vez, éstos son interpretados en la máquina virtual. Cuando ya están en ejecución, el profiler mantiene información sobre el rendimiento y selecciona el método sobre el que se va a realizar la compilación. Los métodos ya compilados se almacenan en un caché en código máquina nativo. Cuando un método es invocado, esta versión en código máquina nativo es la que se utiliza, en caso de que exista; En caso contrario, los ByteCodes son reinterpretados. La función control que muestra el diagrama es como un salto indirecto a través de la memoria que apunta tanto al código máquina como al interpretado, aunque Sun no ha proporcionado muchos detalles sobre este extremo. Al ser Multihilo (o multihilvanado, mala traducción de multithreaded), Java permite muchas actividades simultáneas en un programa. Los hilos -a veces llamados, procesos ligeros, o hilos de ejecución- son básicamente pequeños procesos o piezas independientes de un gran proceso. Al estar estos hilos construidos en el mismo lenguaje, son más fáciles de usar y más robustos que sus homólogos en C o C++.

Manual de Java


El beneficio de ser multihilo consiste en un mejor rendimiento interactivo y mejor comportamiento en tiempo real. Aunque el comportamiento en tiempo real está limitado a las capacidades del sistema operativo subyacente (Unix, Windows, etc.) de la plataforma, aún supera a los entornos de flujo único de programa (single-threaded) tanto en facilidad de desarrollo como en rendimiento. Cualquiera que haya utilizado la tecnología de navegación concurrente, sabe lo frustrante que puede ser esperar por una gran imagen que se está trayendo de un sitio interesante desde la red. En Java, las imágenes se pueden ir trayendo en un hilo de ejecución independiente, permitiendo que el usuario pueda acceder a la información de la página sin tener que esperar por el navegador.

17. Dinámico Java se beneficia todo lo posible de la tecnología orientada a objetos. Java no intenta conectar todos los módulos que comprenden una aplicación hasta el mismo tiempo de ejecución. Las librerías nuevas o actualizadas no paralizarán la ejecución de las aplicaciones actuales -siempre que mantengan el API anterior. Java también simplifica el uso de protocolos nuevos o actualizados. Si su sistema ejecuta una aplicación Java sobre la red y encuentra una pieza de la aplicación que no sabe manejar, tal como se ha explicado en párrafos anteriores, Java es capaz de traer automáticamente cualquier pieza que el sistema necesite para funcionar.

Java, para evitar que los módulos de ByteCode o los objetos o nuevas clases, no haya que estar trayéndolas de la red cada vez que se necesiten, implementa las opciones de persistencia, para que no se eliminen cuando de limpie la caché de la máquina.

Manual de Java


Y, para que el lector tenga idea de qué es lo que se mueve alrededor de Java, no hay mejor explicación que la descripción de los APIs que componen la plataforma Java, aunque no todas las que aquí se citan están disponibles para su uso, ya que algunas se encuentran en fase de desarrollo, otras en fase de discusión pública para aporte de ideas y otras en fase beta.

Java Enterprise Conjunto de especificaciones para entornos corporativos

JDBC API Java Database Connectivity, para permitir a aplicaciones o applets acceder a bases de datos de forma homogénea vía consultas SQL

Java RMI Remote Method Invocation, invocación remota de métodos para aplicaciones distribuidas

Java IDL Puente de compatibilidad con el modelo estándar de objetos CORBA

JNDI Java Naming and Directory Interface, proporciona servicios de directorio y localización de recursos en un entorno corporativo

JavaBeans Especificación de componentes basados en Java

JAF JavaBeans Activation Framework, entorno para determinar el tipo de datos, encapsular el acceso a ellos, descubrir las acciones que se les pueden aplicar e instanciar el componente JavaBean adecuado

Java Security API

API para componentes que necesitan encriptación, certificación, firmas digitales y autentificación

JFC Java Foundation Classes, jerarquía de clases para el desarrollo de aplicaciones gráficas e interfaces de usuario

Swing Set Conjunto de pequeños componentes gráficos para aplicaciones: botones, pestañas, etc.

Java 2D Extensión del AWT para el tratamiento de información gráfica bidimensional

Java Servlet API Especificación que permite crear applets que se ejecutan en el servidor

Java Server API API para el intercambio de información entre un servidor Web y aplicaciones que se ejecutan en su entorno

Java Commerce API

API para transacciones comerciales en Internet

Java Media API Conjunto de especificaciones para el acceso y utilización de información interactiva

JMF Java Media Framework, conjunto de especificaciones para la arquitectura, protocolos e interfaces de programación para reproductores multimedia, captura y videoconferencia

Java Collaboration

Especificación para la comunicación interactiva bidireccional

Manual de Java


Java Telephony Especificación para aplicaciones de telefonía

Java Speech Especificación para el reconocimiento y síntesis de voz

Java Animation Especificación para la manipulación y movimiento de objetos bidimensionales

Java 3D Especificación para la manipulación de objetos tridimensionales

Java Management API

Especificación para la gestión remota de redes

JavaMail API Especificación para proporcionar un conjunto de clases abstractas que modelice un sistema de correo

Personal Java Espeficaciones para aparatos electrónicos de consumo conectables a redes, incluyendo televisores, teléfonos inteligentes, videoconsolas, etc.

Java Smart Card Especificaciones para tarjetas inteligentes, tipo tarjeta de crédito

Embedded Java Especificaciones para dispositivos electrónicos industriales con software embebido ejecutándose sobre sistemas operativos de tiempo real, incluyendo dispositivos de instrumentación, electrónica de control de procesos, etc.

18. Diferencias y Similitudes con C++ Si no eres programador C++, puedes saltarte esta sección, porque no te dirá nada; Al contrario, probablemente contribuya a confundirte más que a aclararte cosas, al introducir conceptos muy familiares que entiende muy bien el que conoce C++, pero que a un profano lo dejan indiferente. Además, muchas de las cosas que se citan no se utilizan en Java, sino que se enumeran para que los programadores que aterrizan en Java desde C++ las tengan en cuenta. Por todo esto, el embrollo que se puede formar un profano puede ser mayúsculo. Si conoces C++, esta sección te servirá para tener como referencia respecto a los cambios que representa Java sobre C++, y donde debes cambiar el concepto de las cosas. Fundamentalmente, porque hay características que siguen utilizándose en Java heredadas de C++, pero el sentido con que se aplican es ligeramente diferente, lo que muchas veces lleva a los programadores C++ que atacan Java, a confusiones innecesarias. Por ello, aunque un poco denso y latoso, es una sección de lectura obligada para que tengas en cuenta las cosas que debes alterar en tu forma de concebir la programación cuando ataques proyectos en Java. Entramos en materia. Java no soporta typedefs, defines o comandos de preprocesador. Al no existir un preprocesador, no está prevista la inclusión de ficheros de cabecera, tampoco tiene cabida el concepto de macro o constante. Sin embargo, sí se permite cierto uso de constantes enumeradas a través de la utilización de la palabra clave final. Java tampoco soporta enums, aunque soporte constantes enumeradas, como acabo de decir. Java soporta clases, pero no soporta estructuras o uniones. Todas las aplicaciones C++ necesitan una función de entrada llamada main() y puede haber multitud de otras funciones, tanto funciones miembros de una

Manual de Java


clase como funciones independientes. En Java no hay funciones independientes, absolutamente todas las funciones han de ser miembros de alguna clase (métodos). Funciones globales y datos globales en Java no están permitidos. En C++ se pueden crear árboles de herencia de clases independientes unos de otros. En Java esto no es posible, en última instancia hay una clase Object, de la que hereda todo lo que el programador cree. Todas las funciones o definiciones de métodos en Java deben estar contenidas dentro de la definición de la clase. Para un programador C++ puede parecerle que esto es semejante a las funciones inline, pero no es así. Java no permite, al menos directamente, que el programador pueda declarar funciones inline. Tanto Java como C++ soportan funciones o métodos (estáticos) de clases, que pueden ser invocados sin necesidad de tener que instanciar ningún objeto de la clase. En Java se introduce el concepto de interface, que no existe en C++. Una interface se utiliza para crear una clase base abstracta que contenga solamente las constantes y las declaraciones de los métodos de la clase. No se permite que haya variables miembro ni definiciones de métodos. Además, en Java también se pueden crear verdaderas clases abstractas. Java no soporta herencia múltiple, aunque se pueden utilizar las posibilidades que ofrece el uso de interfaces para emplear las ventajas que ofrece la herencia múltiple, evitando los inconvenientes que se derivan de su uso. La herencia simple es similar en Java y en C++, aunque la forma en que se implementa es bastante diferente, especialmente en lo que respecta a la utilización de los constructores en la cadena de herencia. Java no soporta la sentencia goto, aunque sea una palabra reservada. Sin embargo, soporta las sentencias break y continue con etiquetas, que no están soportadas por C++. Bajo ciertas circunstancias, estas sentencias etiquetadas se pueden utilizar como un goto encubierto. Java no soporta la sobrecarga de operadores, aunque la utilice internamente, pero no está disponible para el programador. Tampoco soporta la conversión automática de tipos, excepto en las conversiones seguras. Al contrario que C++, Java dispone de un tipo String y los objetos de este tipo no pueden modificarse. Las cadenas que se encuentren definidas entre comillas dobles son convertidas automáticamente a objetos String. Java también dispone del tipo StringBuffer, cuyos objetos sí se pueden modificar, y además se proporcionan una serie de métodos para permitir la manipulación de cadenas de este tipo. Al contrario que C++, Java trata a los arrays como objetos reales. Disponen de un miembro, length, que indica la longitud del array. Se genera una excepción cuando se intenta sobrepasar el límite indicado por esta longitud. Todos los arrays son instanciados en memoria dinámica y se permite la asignación de un array a otro; sin embargo, cuando se realiza una asignación, simplemente tenemos dos referencias a un mismo array, no hay dos copias del array, por lo que si se altera un elemento de un array, también se alterará en el otro. A diferencia de C++, el tener dos "punteros" o referencias a un mismo objeto en memoria dinámica no representa necesariamente un problema (aunque sí puede provocar resultados imprevistos). En Java, la memoria dinámica es liberada automáticamente, pero esta liberación no se lleva a cabo hasta que todas las referencias a esa memoria son NULL o dejan de existir. Por tanto, a

Manual de Java


diferencia de C++, una zona de memoria dinámica nunca puede ser inválida mientras esté siendo referenciada por alguna variable. Java no soporta punteros, al menos en el sentido que atribuye C++, es decir, no permite modificar el contenido de una zona de memoria apuntada por un puntero, o realizar operaciones aritméticas con punteros. La mayor necesidad de uso de punteros deriva de la utilización de cadenas y arrays, y esto se evita al ser objetos de primera clase en Java. Por ejemplo, la declaración imprescindible en C++, char *puntero, para referenciar al primer elemento de una cadena no se necesita en Java, al ser la cadena un objeto String. La definición de clase es semejante en Java y C++, aunque en Java no es necesario el punto y coma (;) final. El operador de ámbito (::) necesario en C++ no se usa en Java, sino que se utiliza el punto (.) para construir referencias. Y, como no hay soporte de punteros, el operador flecha (->) tampoco está soportado en Java. En C++, las funciones y datos miembros se invocan utilizando el nombre de la clase y el nombre del miembro estático conectados por el operador de ámbito. En Java, se utiliza el punto (.) para conseguir el mismo propósito. Al igual que C++, Java dispone de tipos primitivos como int, float, etc. Pero, al contrario de C++, los tamaños de estos tipos son iguales independientemente de la plataforma en que se estén utilizando. No hay tipos sin signo en Java, y la comprobación de tipos es mucho más restrictiva en Java que en C++. Java dispone de un tipo boolean verdadero. Las expresiones condicionales en Java se evalúan a booleano en vez de a entero como en el caso de C++. Es decir, en Java no se permiten sentencias del tipo if( x+y ), porque la expresión que va dentro del paréntesis no se evalúa a booleano. El tipo char en C++ es un tipo de 8 bits que mapea el conjunto completo de caracteres ASCII. En Java, el tipo char es de 16 bits y utiliza el set de caracteres Unicode (los caracteres del 0 al 127 del set Unicode, coinciden con el set ASCII). Al contrario que en C++, el operador desplazamiento (>>) es un operador con signo, insertando el bit de signo en la posición vacía. Por ello, Java incorpora el operador >>>, que inserta ceros en las posiciones que van quedando vacías tras el desplazamiento. C++ permite la instanciación de variables u objetos de cualquier tipo en tiempo de compilación sobre memoria estática o, en tiempo de ejecución, sobre memoria dinámica. Sin embargo, Java requiere que todas las variables de tipos primitivos sean instanciadas en tiempo de compilación, y todos los objetos sean instanciados en memoria dinámica en tiempo de ejecución. Java proporciona clases de envoltura para todos los tipos primitivos, excepto para byte y short, que permiten que estos tipos primitivos puedan ser instanciados en memoria dinámica como objetos en tiempo de ejecución, si fuese necesario. C++ requiere que las clases y funciones estén declaradas antes de utilizarlas por primera vez. Esto no es necesario en Java. C++ también requiere que los miembros estáticos de una clase sé redeclaren fuera de la clase. Esto tampoco es necesario en Java. En C++, si no se indican valores de inicialización para las variables de tipos primitivos, pueden contener basura. Aunque las variables locales de tipos primitivos se pueden inicializar en la declaración, los datos miembros de tipo primitivo de una clase no se pueden inicializar en la definición de la clase. En Java, se pueden inicializar estos datos miembros de tipo primitivo en la declaración de la clase. También se pueden inicializar en el constructor. Si la inicialización no se realiza explícitamente, o falla por lo que

Manual de Java


sea, los datos son inicializados a cero (o su equivalente) automáticamente. Al igual que ocurre en C++, Java también soporta constructores que pueden ser sobrecargados. Y, del mismo modo que sucede en C++, si no se proporciona un constructor explícitamente, el sistema proporciona un constructor por defecto. En Java todos los objetos se pasan por referencia, eliminando la necesidad del constructor copia utilizado en C++. No hay destructores en Java. La memoria que no se utiliza es devuelta al Sistema a través del reciclador de memoria, que se ejecuta en un thread diferente al del programa principal. Esta es una de las diferencias extremadamente importantes entre C++ y Java. Como C++, Java también soporta la sobrecarga de funciones. Sin embargo, el uso de argumentos por defecto no está soportado en Java. Al contrario que C++, Java no soporta templates, por lo que no existen funciones o clases genéricas. El multithreading, o multihilo, es algo característico de Java, que se proporciona por defecto. Aunque Java utiliza las mismas palabras clave que C++ para indicar el control de acceso: private, public y protected, la interpretación es significativamente diferente entre C++ y Java. La implementación del manejo de excepciones en Java es más completo y bastante diferente al empleado en C++. Al contrario que C++, Java no soporta la sobrecarga de operadores. No obstante, los operadores + y += son sobrecargados automáticamente para concatenar cadenas, o para convertir otros tipos a cadenas. Como en C++, las aplicaciones Java pueden hacer llamadas a funciones escritas en otros lenguajes, llamadas métodos nativos. No obstante, los applets no pueden hacer llamadas a métodos nativos. A diferencia de C++, Java dispone de un sistema interno de generación de documentación. Si se utilizan comentarios escritos de determinada forma, se puede utilizar la herramienta javadoc para generar la documentación de la aplicación Java, e incluso se pueden programar doclets para generar tipos específicos de documentación.

19. Java para Aplicaciones Corporativas Java actualmente está en boca de todos, Java e Intranet son las palabras de moda. Pero, surge la pregunta de sí esta es una buena tecnología para desarrollar aplicaciones corporativas. Y la respuesta es afirmativa, en donde la red sea algo crítica, Java facilita tremendamente la vida de la programación corporativa. Durante años, las grandes empresas se han convencido de que la "red" corporativa es la arteria por donde fluye la sangre que mantiene vivo su negocio. Desde el gran servidor de sus oficinas centrales, hasta los servidores de las delegaciones, las estaciones de trabajo de los programadores y la marabunta de PCs, la información va fluyendo de unos a otros. Para muchas compañías, La Red es la Empresa. Si esta red no se mantiene sana, los pedidos no llegan, el inventario no se actualiza, el software no se realiza adecuadamente, los clientes no están satisfechos y, fundamentalmente, el dinero no entra. La necesidad de diagnosticar y reducir la arteriosclerosis de la red, hace que se estén inyectando continuamente nuevas metodologías que subsanen este grave problema. ¿Es Java la medicina? Está claro que cuando vemos un cepillo animado limpiando los dientes, cubos moviéndose en 3-D, o una banda de gatos locos en applets de Java, nos convencemos de que es el lenguaje idóneo para

Manual de Java


Internet. Pero, qué pasa con las aplicaciones corporativas, ¿sería una buena tecnología allí donde la red es el punto crítico? Vamos a intentar responder a esta cuestión comparando las capacidades de Java contra la lista de necesidades de la red corporativa.

20. Desarrollo rápido de aplicaciones Hace años, se decía que los programadores pronto desaparecerían. Los generadores automáticos de programas, eliminarían a los generadores humanos y el mundo sería un lugar mejor para vivir. Desdichadamente, quienes decían esto no tuvieron en cuenta la acelerada demanda de software de calidad para muy diferentes aplicaciones. La tecnología de objetos pronto vino a intentar facilitar la tarea, adoptando el modelo de "generar parte de un programa", así, generando la parte básica de un programa (los objetos), se podría conectar con otros para proporcionar diferentes utilidades al usuario. El lenguaje C++ es una buena herramienta, pero no cumple totalmente la premisa. Visual Basic y NextStep, se acercan cada vez más al poder de los objetos. Java facilita la creación de entornos de desarrollo-aplicaciones de modo similar, pero además es flexible, poderoso y efectivo. Los programadores ahora disponen de herramientas de programación de calidad, que apuntan hacia esa meta; todas se incluyen dentro de los Entornos Visuales de Desarrollo y se conocen como herramientas RAD (Rapid Application Development), como son el Java WorkShop de SunSoft, el entorno JBuilder de Borland, el Visual J++ de Microsoft, el Café de Symantec, la Jfactory de Rogue Wave, el Visual Age de IBM, el Mojo de Penumbra Software, y herramientas más sofisticadas como Netcode o FutureTense. Esto proporciona una gran progresión a los entornos de desarrollo Java.

21. Aplicaciones efectivas y eficientes Las aplicaciones que se crean en grandes empresas deben ser más efectivas que eficientes; es decir, conseguir que el programa funcione y el trabajo salga adelante es más importante que el que lo haga eficientemente. Esto no es una crítica, es una realidad de la programación corporativa. Al ser un lenguaje más simple que cualquiera de los que ahora están en el cajón de los programadores, Java permite a éstos concentrarse en la mecánica de la aplicación, en vez de pasarse horas y horas incorporando APIs para el control de las ventanas, controlando minuciosamente la memoria, sincronizando los ficheros de cabecera y corrigiendo los agónicos mensajes del linker. Java tiene su propio toolkit para interfaces, maneja por sí mismo la memoria que utilice la aplicación, no permite ficheros de cabecera separados (en aplicaciones puramente Java) y solamente usa enlace dinámico. Muchas de las implementaciones de Java actuales son puros intérpretes. Los ByteCodes son interpretados por el sistema run-time de Java, la Máquina Virtual Java (JVM), sobre el ordenador del usuario. Aunque ya hay ciertos proveedores que ofrecen compiladores nativos Just-In-Time (JIT). Si la Máquina Virtual Java dispone de un compilador instalado, las secciones (clases) del ByteCode de la aplicación se compilarán hacia la arquitectura nativa del ordenador del usuario. Los programas Java en ese momento rivalizarán con el rendimiento de programas en C++. Los compiladores JIT no se utilizan en la forma tradicional de un compilador; los programadores no compilan y distribuyen binarios Java a los usuarios. La compilación JIT tiene

Manual de Java


lugar a partir del ByteCode Java, en el sistema del usuario, como una parte (opcional) del entorno run-time local de Java. Muchas veces, los programadores corporativos, ansiosos por exprimir al máximo la eficiencia de su aplicación, empiezan a hacerlo demasiado pronto en el ciclo de vida de la aplicación. Java permite algunas técnicas innovadoras de optimización. Por ejemplo, Java es inherentemente multithreaded. A la vez que ofrece posibilidades de multithread como la clase Thread y mecanismos muy sencillos de usar de sincronización, Java en sí utiliza threads. Los desarrolladores de compiladores inteligentes pueden utilizar esta característica de Java para lanzar un thread que compruebe la forma en que se está utilizando la aplicación. Más específicamente, este thread podría detectar qué métodos de una clase se están usando con más frecuencia e invocar a sucesivos niveles de optimización en tiempo de ejecución de la aplicación. Cuanto más tiempo esté corriendo la aplicación o el applet, los métodos estarán cada vez más optimizados (Guava de Softway es de este tipo). Si un compilador JIT está embebido en el entorno run-time de Java, el programador no se preocupa de hacer que la aplicación se ejecute óptimamente. Siempre he pensado que los Sistemas Operativos tendrían que aplicarse esta filosofía; un optimizador progresivo es un paso más hacia esta idea.

22. Portabilidad para programador y programa En una empresa de relativo tamaño hay una pléyade diferente de ordenadores. Probablemente nos encontremos con estaciones de trabajo Sun para el desarrollo de software, hordas de PCs para cada empleado, algún Mac en el departamento de documentación, una estación de trabajo HP en administración y una estación SGI en la sala de demos. Desarrollar aplicaciones corporativas para un grupo tan diferente de plataformas es excesivamente complejo y caro. Hasta ahora era complicado convencer a los programadores de cada arquitectura que utilizasen un API común para reducir el coste de las aplicaciones. Con un entorno run-time de Java portado a cada una de las arquitecturas de las plataformas presentes en la empresa y una buena librería de clases ("packages" en Java), los programadores pueden entenderse y encontrar muy interesante trabajar con Java. Esta posibilidad hará tender a los programadores hacia Java, justo donde otros intentos anteriores con entornos universales (como Galaxy o XVT) han fracasado. Estos APIs eran simplemente inadecuados, no orientados a redes y, verdaderamente, pesados. Una vez que los programas estén escritos en Java, otro lado interesante del asunto es que los programadores también son portables. El grupo de programadores de la empresa puede ahora enfrentarse a un desarrollo para cualquiera de las plataformas. La parte del cliente y del servidor de una aplicación estarán ahora escritas en el mismo lenguaje. Ya no será necesario tener un grupo que desarrolle en Solaris en del departamento de I+D, programadores trabajando sobre Visual Basic en el departamento de documentación y programadores sobre GNU en proyectos especiales; ahora todos ellos podrán estar juntos y formar el grupo de software de la empresa.

Manual de Java


23. Costos de Desarrollo En contraste con el alto costo de los desarrollos realizados sobre estaciones de trabajo, el costo de creación de una aplicación Java es similar al de desarrollar sobre un PC. Desarrollar utilizando un software caro para una estación de trabajo (ahora barata) es un problema en muchas empresas. La eficiencia del hardware y el poco costo de mantenimiento de una estación de trabajo Sun, por ejemplo, resulta muy atractivo para las empresas; pero el costo adicional del entorno de desarrollo con C++ es prohibitivo para la gran mayoría de ellas. La llegada de Java e Intranet reducen considerablemente estos costos. Las herramientas Java ya no están en el entorno de precios de millones de pesetas, sino a los niveles confortables de precio de las herramientas de PCs. Y con el crecimiento cada día mayor de la comunidad de desarrolladores de software freeware y shareware que incluso proporcionan el código fuente, los programadores corporativos tienen un amplio campo donde moverse y muchas oportunidades de aprender y muchos recursos a su disposición. El éxito que Internet ha proporcionado a los equipos de software corporativos es un regalo. El precio del software es ahora el mismo para un poderoso equipo corriendo Unix que para un PC. Incluso Netscape tiene al mismo precio la versión Unix de su servidor Web SuiteSpot que la versión PC/NT. Esta es la filosofía de precios que parece ser será la que se siga con las herramientas basadas en Java.

24. Mantenimiento y Soporte Un problema bien conocido que ocurre con el software corporativo es la demanda de cuidados y alimentación. Java no es, ciertamente, la cura para la enfermedad del mantenimiento, pero tiene varias características que harán la vida del enfermero más fácil. Uno de los componentes del JDK es javadoc. Si se usan ciertas convenciones en el código fuente (como comenzar un comentario con /** y terminarlo con */) Java, javadoc podrá fácilmente generar páginas HTML con el contenido de esos comentarios, que pueden visualizarse en cualquier navegador. La documentación del API de Java ha sido creada de este modo. Esto hace que el trabajo de documentar el código de nuevas clases Java sea trivial. Y más todavía con la incorporación de los doclets, que son pequeñas aplicaciones Java que permiten configurar qué información y en qué formato se va a generar, con lo cual la versatilidad de la herramienta es mucho mayor. Otro gran problema del desarrollador corporativo es la creación y control de makefiles. Leerse un makefile es como estar leyendo la historia de empresa. Normalmente se pasan de programador a programador, quitando la información que no es esencial, siempre que se puede. Esto hace que muchos de los makefiles de las aplicaciones contengan docenas de librerías, una miríada de ficheros de cabecera y ultra-confusos macros. Es como mirar en el estómago de un gran tiburón. Java reduce las dependencias de complejos makefiles drásticamente. Primero, no hay ficheros de cabecera. Java necesita que todo el código fuente de una clase se encuentre en un solo fichero. Java tiene la inteligencia de make en el propio lenguaje para simplificar la compilación de ByteCodes. Por ejemplo: public class pepe { // Fichero: pepe.java guitarra flamenca;

Manual de Java


} public class guitarra { // Fichero: guitarra.java } % javac -verbose pepe.java [parsed pepe.java in 471ms] [loaded d:\jdk1.1.1\lib\classes.zip(java/lang/Object.class) in 230ms] [checking class pepe] [parsed .\guitarra.java in 30ms] [wrote pepe.class] [checking class guitarra] [wrote .\guitarra.class] [done in 3996ms] El compilador Java se da cuenta de que necesita compilar el fichero guitarra.java. Ahora se puede forzar a que recompile pepe.java sin cambiar guitarra.java, con lo que se podrá comprobar que el compilador de ByteCode Java no recompila innecesariamente el fichero guitarra.java. % javac -verbose pepe.java [parsed pepe.java in 350ms] [loaded d:\jdk1.1.1\lib\classes.zip(java/lang/Object.class) in 90ms] [checking class pepe] [loaded .\guitarra.java in 30ms] [wrote pepe.class] [done in 3054ms] Ahora, si se modifica guitarra.java (añadiendo, por ejemplo, otro miembro a la clase) y se compila pepe.java, el compilador Java se dará cuenta de que debe recompilar tanto pepe.java como guitarra.java % javac -verbose pepe.java [parsed pepe.java in 541ms] [loaded d:\jdk1.1.1\lib\classes.zip(java/lang/Object.class) in 90ms] [checking class pepe] [parsed .\guitarra.java in 41ms] [wrote pepe.class] [checking class guitarra] [wrote .\guitarra.class] [done in 3265ms] En el libro Just Java de Peter van der Linden hay un capítulo excelente acerca del compilador de Java, si el lector tiene oportunidad, no debería dejar pasarla sin leerlo. Y también a la hora de hablar de costes se encuentra el debate inexistente entre terminales y ordenadores. Es inexistente, porque ambos extremos no son excluyentes. Ni se trata de que haya que volver a la época de los grandes ordenadores enclaustrados en salas especiales a temperaturas de helarse, ni de que toda la empresa tenga ordenadores que deba actualizar cada año y medio. En general, para una empresa de investigación y desarrollo, para un estudiante o para un simple aficionado a la informática, es mucho más interesante la opción de tener un ordenador, no un terminal, por muy NetComputer que sea. Sin embargo, en el caso de empresas de no muchos empleados, en que se ejecuta como mucho Office y alguna otra aplicación propietaria, resulta prohibitivo actualizar ordenadores con esa frecuencia, pero también es

Manual de Java


prohibitivo, de cara a la competitividad, el quedarse anclado en el pasado. La solución le llega, por tanto, de la mano de los NCs, o terminales en general, conectados a un ordenador potente. De esta forma, sí pueden permitirse actualizar un único equipo y además, actualizar las aplicaciones, puesto que éstas utilizarían los recursos del servidor central para ejecutarse, con la ventaja adicional de que cualquier instalación de software se realiza sobre un único equipo. Esto no quiere decir que necesariamente haya que volver a los mainframes, puesto que el problema de éstos no radicaba en el concepto, sino en el cose que podía suponer para una empresa, coste tanto de hardware como de aprendizaje. IBM con los PCs y Microsoft con Windows han contribuido a rebajar estos costes a niveles inimaginables, de modo que la solución ideal de servidores con aplicaciones facilita el manejo del software al usuario, con NCs o NetPCs conectados a ellos.

25. Aprendizaje Si la empresa está llena de programadores de C++ con alguna experiencia en el manejo de librería gráficas, aprenderán rápidamente lo esencial de Java. Si el equipo de ingenieros no conoce C++, pero maneja cualquier otro lenguaje de programación orientada a objetos, les llevará pocas semanas dominar la base de Java. Lo que sí que no es cierto es que haya que aprender C++ antes de aprender Java. Si los ingenieros de la empresa no conocen ningún lenguaje orientado a objetos, sí que tienen que aprender los fundamentos de esta tecnología antes de nada, y luego aplicarlos a la programación con Java. El análisis y diseño orientado a objetos debe ser comprendido antes de intentar nada con Java. Los programadores de Java sin un fondo de conocimientos de OOA/D producirán código pobre. Además, los libros sobre Java crecen como la espuma, ya hay más de 200 publicados, y si se busca "Progamming in Java" en la Red, encontraremos una increíble cantidad de Web sites, y lo mismo si nos dedicamos a buscar sites dedicados a "Learning Java". Y si esto no es el sustituto de un instructor humano, hay ya varias empresas que ofrecen enseñanza de Java (incluso a través de Internet), entre ellas, Sun.

26. Resumen En base a los argumentos que acabamos de exponer, ¿podría una empresa utilizar Java para sus aplicaciones críticas? En este instante, sería suficiente un acercamiento a Java. Porque más importante que la elección de Java o cualquier otro lenguaje de programación es un buen diseño de la arquitectura de la aplicación. Diseñar la aplicación para que esté distribuida entre servidores y clientes, y la línea de partida debe ser el diseño modular. Algunas sugerencias para adoptar Java como tecnología corporativa, serían:

1. Usar Java en el desarrollo de la interface del cliente; Java es suficientemente estable para desarrollar una interface portable. Utilizar herramientas de programación más estables en los servidores, porque son la parte crítica.

2. Portar o crear un servidor no-crítico en Java, de forma que tanto cliente como servidor estén escritos en Java.

3. Utilizar Java en proyectos de envergadura tanto en el cliente como en el servidor, para valorar la efectividad de Java.

Manual de Java


Intranet está creciendo actualmente más rápido que Internet. Las organizaciones corporativas están adoptando la metodología Internet para proporcionar soluciones a sus usuarios y clientes. Java tiene todas las cartas para ser una herramienta de inestimable valor en el desarrollo de aplicaciones corporativas. Pero aunque Java convence y aporta argumentos para ello, no es todavía la panacea que en ocasiones Sun pretende vender. De hecho, Java no es sencillo de dominar, y no es tan rápido como otros lenguajes. Como tantas tecnologías que superan la fase de emergencia para iniciar la de consolidación, facilita las cosas, pero todavía debe mejorarse a sí mismo. De cara a la empresa y a los responsables de tecnología, lo que es cierto es que se encuentran ante dos mundos, Windows y Java, en parte complementarios pero también diferentes y, de la parte que les toca a sus respectivos fabricantes, visceralmente enfrentados. Lograr lo mejor de ambos exige la adopción de dos arquitecturas que evolucionan muy deprisa y cada una en una dirección. Situación que introduce una variable de complejidad para los equipos de desarrollo que si quieren estar a ambos lados, deberán contemplar y seguir las evoluciones de las dos plataformas que, al menos por el momento, no parece que estén dispuestas a converger. Actualmente Java se está usando cada vez más en las empresas, a pesar de los problemas de rendimiento, ya que ni los mejores compiladores JIT, que pueden acelerar la aplicación entre 10 y 20 veces, suelen acercarse al 50% del rendimiento de un programa en C. Y además se usa en los servidores, que siempre se ha dicho que tienen que ejecutar el software más rápido. Lo que ocurre es que en la vida real, un servlet que no utiliza AWT para nada y corre en una máquina virtual con JIT tiene un rendimiento aceptable; el que sea inferior a otros componentes escritos en C y utilizando FastCGI es pura anécdota mientras no se necesite ese extra de rendimiento. Y aún entonces, cabe valorar si el precio de un procesador adicional es inferior a la diferencia de coste de desarrollo y mantenimiento entre en código en C y en de Java. Sin embargo Java, por otro lado, se está introduciendo muy rápidamente en los procesos de Control Distribuido, en las empresas que trabajan con sistemas de control embebidos. Sun promociona Java diciendo que es el lenguaje ideal para este tipo de aparatos, como teléfonos móviles, tarjetas de crédito, etc. Y lo cierto es que parece que tienen razón, y en este momento sólo se está empezando.

La imagen reproduce un sistema de control de papel, montado por la empresa

Manual de Java


finlandesa Valmet Automation, que utiliza Java como lenguaje base para el complejo control de la producción del papel. Sus ingenieros han embebido una Máquina Virtual Java en las estaciones de control de procesos de su sistema de control distribuido Damatic XDi. La producción del papel involucra una comunicación instantánea de la maquinaria con los sensores, cada cual de un fabricante. Los paquetes de software que controlan estos sensores se ejecutaban sin el control directo del sistema de control distribuido, pero ahora, los fabricantes de los sensores, utilizando Java, pueden traspasarle el conocimiento directamente al Sistema de Control. Pero también en otras áreas se está recurriendo a Java; como por ejemplo el hospital Northern California Kaiser Permanente, que utiliza el sistema Kahuna, basado en WebChart, que emplea simultáneamente Corba y Java. Este sistema, del cual la figura siguiente reproduce algunas de sus pantallas, es empleado para la gestión de datos de pacientes, doctores, medicamentos, diagnósticos; datos que residen en gran cantidad de bases de datos distintas, con servidores y clientes corriendo en gran cantidad de plataformas diferentes; es decir, es un sistema completamente concurrente y heterogéneo; aunque el CDR (Clinical Data Repository) reside en Walnut Creek y Corona, al sur de California, en mainframes IBM, manejando los datos de casi tres millones de pacientes de todos los Estados Unidos de América. El sistema completo de WebChart fue desarrollado por 5 programadores durante 6 meses, empleando 45 días más para concluir la primera versión utilizable del sistema. Este sistema fue primero portado de Cobol a C++, pero en medio del proyecto en C++, que ya se demoraba en exceso, se cambió a Java para acelerar la velocidad de desarrollo. El sistema mantiene un histórico de datos de cada paciente con gráficas demográficas, problemas médicos significativos, alergias, inmunizaciones, histórico de visitas del paciente, hospitalizaciones del paciente, resultados del laboratorio, histórico de medicaciones, imágenes de Resonancia Magnética o Tomografía Axial Computarizada. También muestra las planificaciones tanto clínicas como de los doctores, con enlaces a las tablas de paciente. Permite acceder a los mainframes del hospital y consultar las bibliotecas de diagnósticos y de referencias de fármacos de la intranet del hospital. Y para todo lo que no se pueda conseguir a través del sistema, dispone de un emulador 3270 para acceder a los mainframes. Para acceder a toda esta información solamente es necesario disponer de un navegador con soporte Java y un módem; pudiendo verse tanto la aplicación como las complejas imágenes de radiografías o tomografías, utilizando el plug-in Amicas.

27. Primeros Pasos en Java 1. Una mínima aplicación en Java ? HolaMundo ? Compilación y Ejecución de HolaMundo ? Ficheros Fuente Java ? Compilación ? Ejecución ? Problemas de Compilación ? HolaMundo en C++ 2. Un Applet básico en Java

Manual de Java


? HolaMundo ? Componentes Básicos de un Applet ? Clases Incluidas ? La clase Applet ? Métodos de Applet ? Compilación de un Applet ? Llamada a Applets ? Prueba de un Applet 3. Argumentos en la Línea de Comandos Como cualquier otro lenguaje, Java se usa para crear aplicaciones. Pero, además Java tiene la particularidad especial de poder crear aplicaciones muy especiales, son los applets, que es una mini (let) aplicación (app) diseñada para ejecutarse en un navegador. A continuación se verá en detalle lo mínimo que se puede hacer en ambos casos, lo que permitirá presentar la secuencia de edición, compilación, ejecución en Java, que será imprescindible a la hora de estudiar detalles más concretos de Java, porque los ejemplos que se muestren serán mejor comprendidos. Hay que hacer una aclaración antes de entrar a ver nada, porque muchos programadores que se introducen en Java piensan solamente en applets, pero Java va mucho más allá, y no hay por qué establecer una distinción entre applet como aplicación gráfica y aplicación independiente como aplicación de consola. No hay nada que impida a una aplicación independiente funcionar como una aplicación en modo gráfico, lo único que hay que hacer es tomarse la molestia de inicializar la ventana de la aplicación a mano y añadirle el evento de que se cierre cuando el mensaje que se lo indique le llegue, cosas en el caso de los applets están a cargo del navegador o visualizador que se esté empleando. Esto es importante, porque en este Tutorial se utilizarán fundamentalmente aplicaciones Java independientes, porque los applets tienen unas medidas de seguridad tan estrictas que no permiten muchas de las opciones del lenguaje, como por ejemplo el acceso a ficheros o la impresión de documentos. Una mínima aplicación en Java La aplicación más pequeña posible es la que simplemente imprime un mensaje en la pantalla. Tradicionalmente, el mensaje suele ser "Hola Mundo!". Esto es justamente lo que hace el siguiente fragmento de código: // Aplicación HolaMundo de ejemplo // class HolaMundoApp { public static void main( String args[] ) { System.out.println( "Hola Mundo!" ); } } HolaMundo Hay que ver en detalle la aplicación anterior, línea a línea. Esas líneas de código contienen los componentes mínimos para imprimir Hola Mundo! en la pantalla. Es un ejemplo muy simple, que no instancia objetos de ninguna otra clase; sin embargo, accede a otra clase incluida en el JDK. // Aplicación HolaMundo de ejemplo //

Manual de Java


Estas dos primeras líneas son comentarios. Hay tres tipos de comentarios en Java, // es un comentario orientado a línea. class HolaMundoApp { Esta línea declara la clase HolaMundoApp. El nombre de la clase especificado en el fichero fuente se utiliza para crear un fichero nombredeclase.class en el directorio en el que se compila la aplicación. En este caso, el compilador creará un fichero llamado HolaMundoApp.class. public static void main( String args[] ) { Esta línea especifica un método que el intérprete Java busca para ejecutar en primer lugar. Igual que en otros lenguajes, Java utiliza una palabra clave main para especificar la primera función a ejecutar. En este ejemplo tan simple no se pasan argumentos. public significa que el método main() puede ser llamado por cualquiera, incluyendo el intérprete Java. static es una palabra clave que le dice al compilador que main se refiere a la propia clase HolaMundoApp y no a ninguna instancia de la clase. De esta forma, si alguien intenta hacer otra instancia de la clase, el método main() no se instanciaría. void indica que main() no devuelve nada. Esto es importante ya que Java realiza una estricta comprobación de tipos, incluyendo los tipos que se ha declarado que devuelven los métodos. args[] es la declaración de un array de Strings. Estos son los argumentos escritos tras el nombre de la clase en la línea de comandos: %java HolaMundoApp arg1 arg2 ... System.out.println( "Hola Mundo!" ); Esta es la funcionalidad de la aplicación. Esta línea muestra el uso de un nombre de clase y método. Se usa el método println() de la clase out que está en el paquete System. A una variable de tipo class se puede acceder sin necesidad de instanciar ningún objeto de esa clase. Por ello ha de ser un tipo básico o primitivo, o bien puede ser una referencia que apunta a otro objeto. En este caso, la variable out es una referencia que apunta a un objeto de otro tipo, aquí una instancia de la clase PrintStream (un objeto PrintStream), que es automáticamente instanciado cuando la clase System es cargada en la aplicación. Esto es algo semejante al hecho de que los objetos stream de entrada/salida, cin y cout son automáticamente instanciados y enlazados a los dispositivos estándar de entrada y salida cuando un programa C++ comienza su ejecución. El método println() toma una cadena como argumento y la escribe en el stream de salida estándar; en este caso, la ventana donde se lanza la aplicación. La clase PrintStream tiene un método instanciable llamado println(), que lo hace e presentar en la salida estándar del Sistema el argumento que se le pase. En este caso, se utiliza la variable o instancia de out para acceder al método. } } Finalmente, se cierran las llaves que limitan el método main() y la clase HolaMundoApp. En C++, la función main() en un programa puede tener cualquiera de los siguientes prototipos: tipo_retorno main() tipo_retorno main( int argc,char argv[] )

Manual de Java


El tipo_retorno puede ser cualquier tipo válido, o void, para indicar que la función no tiene que devolver valor alguno. La lista de argumentos puede estar vacía, o contener los argumentos de soporte para pasar parámetros en la línea de comandos. Esta forma de implementación la función difiere de la que acaba de presentar para Java, que siempre habrá de ser la misma, independientemente de los valores de retorno o la lista de parámetros que se pasen en la lista de argumentos a la aplicación. Compilación y Ejecución de HolaMundo A continuación se puede ver el resultado de esta primera y sencilla aplicación Java en pantalla. Se genera un fichero con el código fuente de la aplicación, se compilará y se utilizará el intérprete Java para ejecutarlo. Ficheros Fuente Java Los ficheros fuente en Java terminan con la extensión ".java". Crear un fichero utilizando cualquier editor de texto ascii que tenga como contenido el código de las ocho líneas de nuestra mínima aplicación, y salvarlo en un fichero con el nombre de HolaMundoApp.java. Para crear los ficheros con código fuente Java no es necesario un procesador de textos, aunque puede utilizarse siempre que tenga salida a fichero de texto plano o ascii, sino que es suficiente con cualquier otro editor. Compilación El compilador javac se encuentra en el directorio bin por debajo del directorio java, donde se haya instalado el JDK. Este directorio bin, si se han seguido las instrucciones de instalación, debería formar parte de la variable de entorno PATH del sistema. Si no es así, tendría que revisar la Instalación del JDK. El compilador de Java traslada el código fuente Java a byte-codes, que son los componentes que entiende la Máquina Virtual Java que está incluida en los navegadores con soporte Java y en appletviewer. Una vez creado el fichero fuente HolaMundoApp.java, se puede compilar con la línea siguiente: %javac HolaMundoApp.java Si no se han cometido errores al teclear ni se han tenido problemas con el path al fichero fuente ni al compilador, no debería aparecer mensaje alguno en la pantalla, y cuando vuelva a aparecer el prompt del sistema, se debería ver un fichero HolaMundoApp.class nuevo en el directorio donde se encuentra el fichero fuente. Si ha habido algún problema, en Problemas de compilación al final de esta sección, hemos intentado reproducir los que más frecuentemente se suelen dar, se pueden consultar por si pueden aportar un poco de luz al error que haya aparecido. Ejecución Para ejecutar la aplicación HolaMundoApp, hemos de recurrir al intérprete java, que también se encuentra en el directorio bin, bajo el directorio en donde se haya instalado el JDK. Se ejecutará la aplicación con la línea: %java HolaMundoApp y debería aparecer en pantalla la respuesta de Java: %Hola Mundo! El símbolo % representa al prompt del sistema, y se utilizará aquí para presentar las respuestas que devuelva el sistema como resultado de la ejecución de los comandos que se introduzcan por teclado o para indicar las líneas de comandos a introducir.

Manual de Java


Cuando se ejecuta una aplicación Java, el intérprete Java busca e invoca al método main() de la clase cuyo nombre coincida con el nombre del fichero .class que se indique en la línea de comandos. En el ejemplo, se indica al Sistema Operativo que arranque el intérprete Java y luego se indica al intérprete Java que busque y ejecute el método main() de la aplicación Java almacenada en el fichero HolaMundoApp.class. Problemas de compilación A continuación se encuentra una lista de los errores más frecuentes que se presentan a la hora de compilar un fichero con código fuente Java, tomando como base los errores provocados sobre la mínima aplicación Java que se está utilizando como ejemplo, pero también podría generalizarse sin demasiados problemas. %javac: Command not found No se ha establecido correctamente la variable PATH del sistema para el compilador javac. El compilador javac se encuentra en el directorio bin, que cuelga del directorio donde se haya instalado el JDK (Java Development Kit). %HolaMundoApp.java:3: Method printl(java.lang.String) not found in class java.io.PrintStream. System.out.printl( "HolaMundo! ); ^ Error tipográfico, el método es println no printl. %In class HolaMundoApp: main must be public and static Error de ejecución, se olvidó colocar la palabra static en la declaración del método main de la aplicación. %Can´t find class HolaMundoApp Este es un error muy sutil. Generalmente significa que el nombre de la clase es distinto al del fichero que contiene el código fuente, con lo cual el fichero nombre_fichero.class que se genera es diferente del que cabría esperar. Por ejemplo, si en el fichero de código fuente de la aplicación HolaMundoApp.java se coloca en vez de la declaración actual de la clase HolaMundoApp, la línea: class HolaMundoapp { se creará un fichero HolaMundoapp.class, que es diferente del HolaMundoApp.class, que es el nombre esperado de la clase; la diferencia se encuentra en la a minúscula y mayúscula. %Note: prueba.java uses a deprecated API. Recompile with "-deprecation" for details. 1 Warning Esto es originado por otra de las cosas que ha introducido el JDK 1.1 como son los elementos obsoletos (deprecated), es decir, aquellas clases o métodos que no se recomienda utilizar, aunque sigan siendo válidos, porque están destinados a desaparecer de la faz de la Tierra a partir de alguna de las versiones posteriores del JDK. Si se compila un programa que hace uso de uno de estas clases, o bien utiliza o sobrecarga un método obsoleto, el compilador mostrará un mensaje de este tipo. Solamente se genera un aviso por módulo, independientemente del número de métodos obsoletos que se estén utilizanzo, por eso hay que seguir la recomendación del aviso si se quiren saber los detalles completos de todas las clases y métodos obsoletos que se están utilizando. La llamada a estos métodos rara vez tiene excusa, aunque haya casos especiales en que se escriba código para que sea llamado tanto por programas generados con la versión 1.0 del JDK y con la versión 1.1 o 1.2, En este caso JavaSoft

Manual de Java


recomienda indicarle al compilador que se está haciendo uso intencionado del método obsoleto, y esto se consigue colocando el comentario /** @deprecated */ justo antes del método sobrecargado, por ejemplo: /** @deprecated */ public boolean handleEvent( Event evt ) { if( evt.id == Event.WINDOW_DESTROY ) System.exit( 0 ); return( false ); } No obstante, en este caso y a pesar de estos avisos, el compilador genera código perfectamente ejecutable. HolaMundo en C++ Para poder establecer comparaciones, y en deferencia a los programadores que dominen C++, se muestran a continuación dos versiones C++ de la pequeña aplicación que se ha empleado para imprimir el mensaje de saludo en la pantalla. La primera versión, HolaA.cpp, presenta en pantalla el consabido mensaje "Hola Mundo!", pero en el código no se utilizan clases y es significativamente diferente al programa Java que se ha discutido hasta ahora. En Java no se puede escribir nada semejante. #include <iostream.h> void main() { // Presenta el mensaje en pantalla cout << "Hola Mundo!"; } Cuando se compila y ejecuta el fichero ejecutable resultante, el mensaje de saludo aparece en la pantalla. Pero se puede crear una nueva versión del programa C++, HolaB.cpp, estructurada de forma semejante a lo que se hace en Java. Así, esta segunda versión de la aplicación ya contiene una clase, que tiene una función miembro estática que es la encargada de presentar el mensaje de saludo en pantalla. Como en Java, las funciones miembro se pueden invocar sin necesidad de instanciar ningún objeto de la clase. #include <iostream.h> // Se define la clase HolaB class HolaB { public: // Se define una función estática para presentar // la cadena static void presentarMensaje() { // Presenta el mensaje en la pantalla cout << "Hola Mundo!"; } }; // Se llama a la función miembro estática, sin ningún // objeto, para presentar el mensaje en pantalla void main() { HolaB::presentarMensaje();

Manual de Java


} Teniendo en cuenta las tres versiones de la aplicación a la vez, se puede observar claramente la orientación a objetos que está incluida en Java y la forma en que esto se demuestra, incluso en una aplicación tan sencilla como la que se limita a presentar un mensaje en pantalla. Un Applet básico en Java A continuación se trata de crear el código fuente de un applet que sea sencillo y sirva para mostrar el ciclo de desarrollo de escritura del código fuente Java, compilación, ejecución y visualización de resultados, es decir, un applet que presente un mensaje de saludo en la pantalla (la originalidad al poder!). Recuérdese que Java utiliza la extensión .java para designar los ficheros fuente. La programación de applets Java difiere significativamente de la aplicación de aplicaciones Java. Se puede prever que cuando haya necesidades de un interface gráfico, la programación de applets será bastante más sencilla que la programación de aplicaciones que realicen los mismos cometidos, aunque los applets necesiten de un visualizador de ficheros html con soporte Java, para poder ejecutarse. HolaMundo A continuación está el código fuente del applet HolaMundo, que es la versión applet de la mínima aplicación Java que antes se ha presentado y desarrollado tanto como aplicación Java como en su versión C++. Este código se guardará en un fichero fuente Java como HolaMundo.java, y que como todos los ejemplos de código que se incorporan en este Tutorial, se pueden encontrar ya preescritos y se pueden cargar directamente en el navegador (los .html) o compilar (los .java). import java.awt.Graphics; import java.applet.Applet; public class HolaMundo extends Applet { public void paint( Graphics g ) { // Pinta el mensaje en la posición indicada g.drawString( "Hola Mundo!",25,25 ); } } Componentes básicos de un Applet El lenguaje Java implementa un modelo de Programación Orientada a Objetos. Los objetos sirven de bloques centrales de construcción de los programas Java. De la misma forma que otros lenguajes de programación, Java tiene variables de estado y métodos. La descomposición de un applet en sus piezas/objetos, sería la que se muestra a continuación: /* Sección de importaciones */ public class NombreDelNuevoApplet extends Applet { /* Aquí se declaran las variables de estado (public y private) */ /* Los métodos para la interacción con los objetos se

Manual de Java


declaran y definen aquí */ public void MetodoUno( parámetros ) { /* Aquí viene para cada método, el código Java que desempeña la tarea. Qué código se use depende del applet */ } } Para HolaMundo, se importan las dos clases que necesita. No hay variables de estado, y sólo se tiene que definir un método para que el applet tenga el comportamiento esperado. Clases Incluidas El comando import carga otras clases dentro del código fuente. El importar una clase desde un paquete de Java hace que esa clase importada esté disponible para todo el código incluido en el fichero fuente Java que la importa. Por ejemplo, en el applet HolaMundo que se esta presentando aquí, se importa la clase java.awt.Graphics, y se podrá llamar a los métodos de esta clase desde cualquiera de los métodos que se encuentren incluidos en el fichero HolaMundo.java. Esta clase define una área gráfica y métodos para poder dibujar dentro de ella. La función, método, paint() declara a g como un objeto de tipo Graphics; luego, paint() usa el método drawString() de la clase Graphics para generar su salida. La Clase Applet Se puede crear una nueva clase, en este caso HolaMundo, extendiendo la clase básica de Java: Applet. De esta forma, se hereda todo lo necesario para crear un applet. Modificando determinados métodos del applet, se puede lograr que lleve a cabo las funciones que se desee. import java.applet.Applet; . . . public class HolaMundo extends Applet { Métodos de Applet La parte del applet a modificar es el método paint(). En la clase Applet, se llama al método paint() cada vez que el método arranca o necesita ser refrescado, pero no hace nada. En este caso, del applet básico que se está gestando, lo que se hace es: public void paint( Graphics g ) { g.drawString( "Hola Mundo!",25,25 ); } De acuerdo a las normas de sobrecarga, se ejecutará este último paint() y no el paint() vacío de la clase Applet. Luego, aquí se ejecuta el método drawString(), que le dice al applet cómo debe aparecer un texto en el área de dibujo. Otros métodos básicos para dibujar son: drawLine( int x1,int y1,int x2,int y2 ) drawRect( int x,int y,int ancho,int alto ) drawOval( int x,int y,int ancho,int alto ) Tanto para drawRect() como para drawOval(), las coordenadas (x,y) son la esquina superior izquierda del rectángulo (para drawOval(), el óvalo es encajado en el rectángulo que lo circunscribe).

Manual de Java


Compilación de un Applet Ahora que ya está el código del applet básico escrito y el fichero fuente Java que lo contiene guardado en disco, es necesario compilarlo y obtener un fichero .class ejecutable. Se utiliza el compilador Java, javac, para realizar la tarea. El comando de compilación será: %javac HolaMundo.java Eso es todo. El compilador javac generará un fichero HolaMundo.class que podrá ser llamado desde cualquier navegador con soporte Java y, por tanto, capaz de ejecutar applets Java. Llamada a Applets ¿Qué tienen de especial HotJava, Microsoft Explorer o Netscape con respecto a otros navegadores? Con ellos se puede ver código escrito en lenguaje html básico y acceder a todo el texto, gráfico, sonido e hipertexto que se pueda ver con cualquier otro navegador. Pero además, y esto es lo que tienen de especial, pueden ejecutar applets, que no es html estándar. Ambos navegadores entienden código html que lleve la marca <APPLET>: <APPLET CODE="SuCodigo.class" WIDTH=100 HEIGHT=50> </APPLET> Esta marca html llama al applet SuCodigo.class y establece su ancho y alto inicial. Cuando se acceda a la página Web donde se encuentre incluida la marca, se ejecutará el byte-code contenido en SuCodigo.class, obteniéndose el resultado de la ejecución del applet en la ventana del navegador, con soporte Java, que se esté utilizando. Si no se dispone de ningún navegador, se puede utilizar el visor de applets que proporciona Sun con el JDK, el appletviewer, que además requiere muchos menos recursos de la máquina en que se esté ejecutando, que cualquier otro de los navegadores que se acaban de citar. Prueba de un Applet El JDK, Kit de Desarrollo de Java, incluye el visor de applets básico, appletviewer, que puede utilizarse para la visualización rápida y prueba de applets. La ejecución de un applet sobre appletviewer se realiza a través de la llamada: %appletviewer fichero.html En este caso el fichero con el código html que ejecutará el applet HolaMundo es HolaMundo.html que generará la salida que muestra la figura.

rrr_java

Documents

Transcript of rrr_java