Asignatura. Taller de Computación VI. Módulo II Introducción a Java

Transcripción

1 Asignatura Módulo II Introducción a Java Elaboración Hugo Sanoguera, Fabián Gentile Este material pertenece a la materia, de la Carrera de Analista de Sistemas de Computación del INSTITUTO DE TECNOLOGÍA ORT. Todos los derechos reservados. No está permitida la reproducción total o parcial de este apunte, ni su tratamiento informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, por registro u otros métodos, sin el permiso previo de los titulares. 1ra edición Mayo de

2 UNIDAD DIDÁCTICA II TABLA DE CONTENIDOS UNIDAD DIDÁCTICA II 1 TABLA DE CONTENIDOS 1 Introducción y orientaciones para el estudio 3 Objetivos 3 Aclaraciones previas al estudio 3 ORIGEN DE JAVA 4 Cómo funciona Java básicamente 5 Características de Java 6 Simple 6 Orientado a Objetos 6 Distribuido 7 Robusto 7 Arquitectura Neutral 8 Seguro 10 Portable 12 Interpretado 12 Multihilo 14 Dinámico 15 Diferencias y Similitudes con C++ 18 Instalación de un entorno de desarrollo integrado (IDE) Eclipse 21 Tutorial de Eclipse 26 Material extraído de la pagina: 26 de Enrique Serrano Valle. 26 Parte 1: Entorno de Proyectos de Eclipse 26 Parte 2: Crear Elementos de Java 30 Java Class 30 File 31 Folder 31 Interface 32 Package 33 Scrapbook Page 33 Source Folder 33 Parte 3: Funciones Útiles de Programación 34 Compilar y Detectar Errores 34 Icono de Bombilla = Autocorregir 34 CTRL + Espacio = Autocompletar 35 Menú "Source" 37 Menu Refactor 40 Consultar la Documentación 42 Archivos JAR Importar 42 Parte 4: Vistas de Eclipse 43 Perspectivas-Restaurar Vistas 43 Tareas 44 Navigator 44 1

3 Package Explorer 45 Outline View 46 Hierarchy View 46 Fast Views 47 Search View 47 Navegar por las Vistas y los Editores 48 Maximizar una Vista o Editor 48 Ir al Último Cambio 49 Acciones de Navegación de los Editores 49 Revisar Problemas 49 Parte 5: Ejecutar y Depurar 51 Ejecutar 51 Depurar 52 Gestión de Cambios 54 Primera aplicación en Java 55 Sintaxis De Java y Nomenclatura 57 Estilo de codificación 57 Comentarios y documentación incrustada 57 Documentación en forma de comentarios 57 Sintaxis 58 HTML empotrado 58 Etiquetas de documentación de variables 60 Etiquetas de documentación de métodos 60 Ejemplo de documentación 60 Tipos de Datos 62 Recolector de Basura (garbage collector) 64 Ámbito de los objetos 64 Limpieza: finalización y recolección de basura 64 La recolección de basura no es destrucción 64 Para qué sirve finalize( )? 65 Hay que llevar a cabo la limpieza 66 Cómo funciona un recolector de basura 66 LA CLASE String 69 Funciones Básicas 69 Funciones de Comparación de Strings 69 Funciones de Comparación de Subcadenas 70 Funciones ValueOf 71 Funciones de Conversión 71 LA CLASE StringBuffer 72 Cambio de Tamaño 72 Modificación del Contenido 73 Las funciones que cambian el tamaño son pues: 73 Operadores de Concatenación 74 Referencias 75 Referencias y Arrays 77 2

4 Introducción y orientaciones para el estudio En el desarrollo de este módulo abordaremos: Un poco de historia del lenguaje Java. Entorno de trabajo Eclipse. Primera aproximación al lenguaje Java. Manejo de Strings en Java. Creación de un programa en Java. Objetivos Pretendemos que al finalizar de estudiar esta Unidad, el alumno logre: Conocer un poco de historia del lenguaje Java con el cual trabajaremos a lo largo de esta asignatura. Conocer las distintas plataformas en las que corre Java. Tener una primera aproximación a un entorno de trabajo (Eclipse). Tener una aproximación al Lenguaje Java. Conocer el manejo de Strings en Java. Poder realizar el primer programa desde su escritura hasta su ejecución, conociendo las etapas intermedias. Aclaraciones previas al estudio En este módulo, usted encontrará: Contenidos Conceptualizaciones centrales Bibliografía Referencia de material bibliográfico recomendado Usted debe tener presente que los contenidos presentados en el módulo no ahondan profundamente en el tema, sino que pretenden ser un recurso motivador, para que a través de la lectura del material, la bibliografía sugerida, y el desarrollo de las actividades propuestas alcance los objetivos planteados en el presente módulo. 3

5 ORIGEN DE JAVA Material extraído de la pagina: Tutorial de Java de Agustin Froufe Sun Microsystems, líder en servidores para Internet, uno de cuyos lemas desde hace mucho tiempo es "the networkis 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 desarrollado el lenguaje Java, en un intento de resolver simultáneamente todos los problemas que se le plantean 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 funcionaban 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 pericia de los usuarios para el manejo de estos dispositivos, requería unas interfaces mucho más cómodas e intuitivas que los sistemas de ventanas que proliferaban en el momento. Otros requisitos importantes a tener en cuenta 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 aportadas por la 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, el cual, aún partiendo de la sintaxis de C++, intentaba remediar las deficiencias que iba observando. 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 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 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. 4

6 Tras un cambio de nombre y modificaciones de diseño, el lenguaje Java fue presentado en sociedad en agosto de 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. Cómo funciona Java básicamente 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 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, Mainframes, AS400, 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 multiplataforma 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 5

7 propia mejora de los elementos que integran la máquina virtual como el recolector de basura, 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. 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++ es un lenguaje con pocas posibilidades para la 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 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 muy pequeño. 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. Mientras que en java solo se recompila la clase modificada(.class ) 6

8 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. 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. 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. 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 7

9 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, SunOs, Windows Servers, Windows XP, Linux, Irix, Aix, Mac, Apple, Mainframes, As400 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: 8

10 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, video... 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. 9

11 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. 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 presentando el contenido del directorio. Se notará un retardo, pero nada inusual. 10

12 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 sin 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, 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 desemsamblador 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 javap 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 11

13 descompilable todo el código; aunque así se pierda portabilidad. Es otra de las cuestiones que Java tiene pendientes. 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. Interpretado El intérprete Java (sistema run-time) puede ejecutar directamente el código objeto. Enlazar (linkear) 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. 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. 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 multiplataforma, pero para ejecutarlas es necesario que exista el runtime correspondiente al sistema operativo utilizado. No obstante, este panorama está cambiando 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. 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. 12

14 La imagen de la derecha 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, situada a la izquierda, 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 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. 13

15 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. Multihilo 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 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++. 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. 14

16 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ía 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. 15

17 A continuación vemos 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 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 16

18 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. 17

19 Diferencias y Similitudes con C++ Si conocemos C++, esta sección 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 extenso, es una sección de lectura obligada para tener en cuenta las cosas que debes alterar en la forma de concebir la programación cuando encares proyectos en Java. 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 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 contenidos 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 alguna versiones de 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. La 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. 18

20 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 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 se redeclaren fuera de la clase. Esto tampoco es necesario en Java. 19

21 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 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 pasar 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(soportada en la versión Java 6 ). 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 completa 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. 20

22 Instalación de un entorno de desarrollo integrado (IDE) Eclipse Material extraído de la pagina La instalación y configuración de Eclipse, un entorno de desarrollo integrado (IDE) que sirve para muchos lenguajes. Eclipse tiene interesantes utilidades para Java y además es gratuito. Como hemos dicho, un IDE puede hacernos el trabajo mucho más sencillo, sobretodo si nuestro desarrollo ya va manejando un buen número de Clases. Además estos entornos nos permiten mucha más versatilidad para depurar nuestros programas puesto que tienen debbugers mucho más avanzados, cosa que nos viene de perlas para ir empezando en este mundillo. Eclipse es un IDE de código abierto. Hay más herramientas similares de código abierto disponibles pero esta es la que creo que tiene mejor relación calidad-facilidad de las que he encontrado. Su instalación es muy sencilla, podemos descargárnoslo de en forma de archivo ZIP y solo tenemos que descomprimirlo en la carpeta donde queramos tenerlo instalado. Para ejecutarlo solo hay que arrancar el fichero Eclipse.exe. Una vez arrancado lo único que nos pedirá es que le demos la ruta por defecto donde queramos que eclipse nos vaya guardando los proyectos que creemos: Después de esto nos aparecerá la ventana principal de Eclipse: 21