Java proporciona toda la funcionalidad de un lenguaje potente, pero sin las características menos usadas y más confusas de éstos. C++ es un lenguaje que adolece de falta de seguridad, pero C y C++ son lenguajes más difundidos, por ello Java se diseñó para ser semejante a C++ y así facilitar un veloz y sencillo aprendizaje. garbage collector thread Java reduce en un 50% los yerros más comunes de programación con lenguajes como C y C++ al descartar muchas de las características de éstos, entre las que destacan: aritmética de punteros no tienen lugar referencias registros (struct) definición de tipos (typedef) macros (#define) necesidad de liberar memoria (free) Aunque, en realidad, lo que hace es descartar 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, unicamente ocupa 215 Kb de RAM. ORIENTADO A OBJETOS clases instancias. Estas instancias, como en C++, requieren ser construidas y destruidas en lugares 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 laborar con librerías dinámicas (DLLs) que obligan a recompilar la aplicación cuando se retocan las funciones que se encuentran en su interior. Este inconveniente es resuelto por Java mediante una interfaz específica llamada RTTI ( RunTime Type Identification ) que determina 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 faculta a los programadores interrogar por el tipo de clase y unir dinámicamente la clase con el fruto de la búsqueda. DISTRIBUID ht ftp. Esto faculta a los programadores alcanzar a la información a través de la red con tanta facilidad como a los archivos locales. La realidad es que Java en sí no es distribuido, sino que ofrece las librerías y dispositivos para que los proyectos puedan ser distribuidos, es decir, que se corran en algúnas máquinas, interactuando. ROBUSTO arrays auténticos, en vez de listas enlazadas de punteros, con comprobación de límites, para eludir la probabilidad de sobreescribir o corromper memoria fruto de punteros que señalan a zonas equivocadas. Estas características reducen drásticamente el tiempo de desarrollo de aplicaciones en Java. byte-codes, que son el fruto de la compilación de un proyecto 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 byte-codes ARQUITECTURA NEUTRAL Para establecer Java como fracción 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 sdeterminados la máquina en que ha sido generado. Actualmente tienen lugar 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 (byte-codes) 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 fundamentos que forman fracción de la arquitectura de Java sobre una plataforma genérica, obtendríamos una figura como la siguiente: Máquina Virtual Java Java 2D: gráficos 2D y manipulación de imágenes 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 SEGURO casting yerros de alineación. Los programadores de C emplean punteros en conjunción con operaciones aritméticas. Esto le faculta al programador que un puntero referencie a un espacio conocido de la memoria y pueda sumar (o restar) determinado valor, para mencionarse a otro espacio de la memoria. Si otros programadores conocen nuestras estructuras de datos pueden extraer información confidencial de vuestro sistema. Con un lenguaje como C, se pueden beber números enteros aleatorios y convertirlos en punteros para despues alcanzar a la memoria: printf( "Escribe un valor entero: " ); scanf( "%u",&puntero ); printf( "Cadena de memoria: %s\n",puntero ); Caballo de Troya /etc/shado testsSi los byte-codes pasan la verificación sin generar ningún mensaje de error, entonces conocemos 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 adecuados No ha sucedido ninguna conversión ilegal de datos, tal como convertir enteros en punteros El entrada a los campos de un objeto se sabe que es legal: public, private, protected No hay ningún intento de violar las normas de entrada y seguridad creadas El Cargador de Clases también ayuda a Java a mantener su seguridad, separando el lugar de nombres del sistema de archivos 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 despues entre las procedentes del exterior. Las clases importadas de la red se almacenan en un lugar de nombres privado, vinculado con el origen. Cuando una clase del lugar de nombres privado accede a otra clase, primero se busca en las clases predefinidas (del sistema local) y despues en el lugar 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 adaptar la pila de proyecto, la memoria abierta o utilizar objetos y métodos de un proyecto sin los privilegios del kernel del sistema operativo. Además, para eludir transformaciónes por fracción de los crackers de la red, implementa un método ultraseguro de autentificación por clave pública. El Cargador de Clases puede comprobar una firma digital antes de hacer 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 de compilación, con el nivel de detalle y de privilegio que sea necesario. Dada, pues la concepción del lenguaje y si todos los fundamentos 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 laboran sobre el disco duro de la máquina de donde partió el applet), no faculta ejecutar ninguna aplicación nativa de una plataforma e impide que se utilicen otros ordenadores como puente, es decir, nadie puede utilizar vuestra máquina para hacer peticiones o hacer operaciones con otra. Además, los intérpretes que incorporan los navegadores de la Web son aún más restrictivos. Debajo estas cláusulas (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 analizar que Java es un lenguaje seguro y que los applets están libres de virus javapPORTABLE enteros INTERPRETADO El intérprete Java (sistema run-time) puede ejecutar directamente el código objeto. Enlazar (linkar) un proyecto, 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 particulares de Java para las variadas plataformas, Java es más lento que otros lenguajes de proyectoción, como C++, ya que debe ser interpretado y no ejecutado como sucede en cualquier proyecto tradicional. Se dice que Java es de 10 a 30 veces más lento que C, y que tampoco tienen lugar en Java programas de mayor envergadura como en otros lenguajes. La realidad es que ya hay comparaciones ventajosas entre Java y el resto de los lenguajes de programación, y una ingente porción de folletos electrónicos que supuran fanatismo en favor y en contra de los diferentes lenguajes contendientes con Java. Lo que se suele abandonar de lado en todo esto, es que primero habría que determinar 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 realidad es que Java para obtener 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 byte-code. Este código intermedio es de muy debajo nivel, pero sin conseguir las instrucciones máquina particulares de cada plataforma y no tiene nada que ver con el p-code de Visual Basic. El byte-code 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 run-time, que sí es completamente dependiente de la máquina y del sistema operativo, que interpreta dinámicamente el byte-code y agrega el 20% de instrucciones que faltaban para su ejecución. Con este sistema es sencillo crear aplicaciones multiplataforma, pero para ejecutarlas es indispensable que exista el run-time correspondiente al sistema operativo utilizado. MULTITHREADED Al ser multithreaded (multihilvanado, en mala traducción), Java faculta muchas actividades simultáneas en un programa. Los threads (a veces llamados, procesos ligeros), son básicamente pequeños procesos o piezas independientes de un mayor proceso. Al estar los threads contruidos en el lenguaje, son más fáciles de usar y más robustos que sus homólogos en C o C++. El beneficio de ser miltithreaded 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.), aún supera a los ámbitos de flujo único de proyecto (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 mayor imagen que se está trayendo. En Java, las imágenes se pueden ir trayendo en un thread independiente, permitiendo que el usuario pueda alcanzar a la información en la página sin tener que esperar por el navegador. DINAMICO Java se beneficia todo lo probable de la tecnología enfocada a objetos. Java no intenta conectar todos los módulos que comprenden una aplicación hasta el tiempo de ejecución. Las librería nuevas o actualizadas no paralizarán 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 descubre 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 cualquiera de esas piezas que el sistema requiere para funcionar. Java, para eludir que los módulos de byte-codes o los objetos o nuevas clases, haya que estar trayéndolos de la red cada vez que se necesiten, implementa las alternativas de persistencia, para que no se eliminen cuando de limpie la caché de la máquina.