| Artículos | 01 SEP 1997

Programación en Java

Tags: Histórico

El mundo Java, al igual que el resto de la programación, está cambiando deprisa. Conozca el panorama actual de la programación en Java y vea las últimas tecnologías así como las nuevas herramientas que se están incorporando.

Sin duda, el lenguaje Java pasará a la historia como uno de los oportunismos mayores que se han dado a lo largo de los tiempos. Quién iba a decir a Sun, que el lenguaje que estaba desarrollando en 1990 destinado a la electrónica de consumo (vídeos, asistentes personales, etc.) se convertiría en poco tiempo en uno de los lenguajes más utilizados y más conocidos, incluso hay quien llega a compararlo con C/C++. Desde luego, el cambio de estrategia de Sun orientando Oak para Internet (Java) ha marcado en gran medida la situación actual de la red.

Actualmente estamos en condiciones de afirmar que Java es el único lenguaje que está adaptado a la red sin problemas de compatibilidad entre plataformas, es decir, es el único lenguaje propio de Internet. Sin embargo, en Java se han introducido demasiadas restricciones que habitualmente los programadores más avanzados no están dispuestos a tolerar. Por este motivo, las alternativas a Java están saltando con más o menos acierto. Pero realmente hay que saber que ninguna de las alternativas ofrece la compatibilidad de Java y que, las mejoras, se consiguen a base de la pérdida de esa compatibilidad.

Java y ActiveX

Nada más hablar de estas dos tecnologías salta la duda: ¿ActiveX lucha contra Java? o ¿ActiveX lucha junto con Java?. Lo cierto es que no resulta fácil comparar ambas tecnologías pues, aunque con ambas se pueden conseguir cosas parecidas, lo cierto es que entre ellos no compiten, en contra de lo que se pudiera pensar. Veamos exactamente las semejanzas y diferencias entre ambas tecnologías.

ActiveX, como el lector sabrá (consulte el artículo de Componentes de Software en este mismo número), son componentes que pueden estar escritos en cualquier lenguaje y prácticamente no poseen restricciones de ningún tipo. Con esto se consigue básicamente tres cosas: por un lado, los programadores no tienen por qué aprender un lenguaje nuevo, ya que pueden utilizar el habitual C/C++, Pascal o Visual Basic. Por otro lado, no se añaden restricciones a los lenguajes, por lo que los programadores tienen toda la potencia en sus manos. Finalmente, las velocidades de ejecución son mucho mejores en ActiveX que en Java. Sin embargo, ActiveX tiene en contra algo que es inevitable: la seguridad. Digo que es inevitable porque cualquier tecnología que elimine restricciones tiene que ser a consecuencia de perder seguridad, ya que ambos conceptos van ligados. Con el fin de añadir algo más de seguridad al sistema, Microsoft posee un sistema de autenticación que permite conocer al usuario el fabricante del componente antes de descargarlo. En este punto hay que destacar que el sistema de seguridad introducido en el JDK 1.1 es parecido al que posee Microsoft.

Otra posible desventaja de ActiveX con respecto a Java es la compatibilidad. ActiveX, al tratarse de una parte de un programa almacenada en código nativo del procesador, como es evidente, únicamente funcionará en aquellos equipos que posean ese procesador para el que han sido fabricados. Sin embargo, gracias a la tecnología DCOM, que permite unir componentes, se pueden tener ActiveX en prácticamente cualquier plataforma (actualmente en Windows 95/NT, Macintosh y algunos Unix comerciales), y unirlos todos ellos para conseguir una única unidad. Con esto podemos conseguir algo que parece imposible, y es tener una aplicación como suma de trozos de todas las plataformas. Es evidente que este concepto de multiplataforma no es el mismo que el de multiplataforma en Java, pues en Java, el mismo programa ejecutable en una máquina virtual lo podemos ejecutar en otra máquina virtual sin demasiados problemas (aunque esto resulta un idealismo no completamente real).

Una diferencia fundamental entre ambas tecnologías es que mientras ActiveX puede ser fabricado utilizando los lenguajes más comunes, Java es un lenguaje en sí mismo. Aquí es donde reside la clave de la competencia o unión de ambas tecnologías. La realidad es que ActiveX extiende Java, puesto que Java puede utilizar ActiveX y, además, desde Java se pueden generar ActiveX. Por este motivo, la competencia no es demasiado directa, sino que ambos tienen puntos de vista diferentes que se pueden unir para conseguir mejores resultados.

Java tiene varios problemas. El primero de ellos es las altas restricciones a las que está sometido. Esto va a favor de la seguridad, pues como se ha visto, son conceptos que van relacionados de forma directa (a mayores restricciones, mayor seguridad). Si en Java optamos por eliminar algunas de esas restricciones, nos encontraremos ante un problema de seguridad parecido al que tiene ActiveX. Por otro lado, Java es muy lento. La lentitud viene por dos cauces bien distintos. En primer lugar, hay que recordar que cada vez que ejecutamos un applet Java éste se tiene que descargar desde el servidor, sea la primera vez que se utilice o no, es decir, siempre hay que descargarlo. Así el inicio de un applet no resulta demasiado rápido. Por otro lado, cuando el ByteCode llega a la máquina virtual tiene dos posibles caminos. El primero es que comience a ser interpretado, por lo que la lentitud en la ejecución está asegurada. El segundo camino es que sea compilado según va llegando mediante la utilización de un JIT. Así, una vez compilado el código será más ágil, pero hay una etapa inicial de compilación que hay que sufrir cada vez que se descarga el applet.

Así que podemos concluir diciendo que ambas tecnologías no tiene por qué competir, sino más bien al contrario, pueden unirse para aportar mayores capacidades al programador.

Librerías AWT y AFC

Ni que decir tiene que a Java le viene la fama por las applets, ya que éstas son las que se integran dentro del navegador y aprovechan toda la potencia gráfica de éstos. Cuando se adaptó Java y apareció el primer SDK, Sun dotó a Java del paquete AWT que encapsulaba todo lo referente al entorno gráfico. Hoy en día, este paquete es un estándar dentro de la comunidad de programadores Java y a las nuevas librerías hay que pedirlas, como mínimo, que sean compatibles con AWT.

Una de estas librerías es la AFC (Application Foundation Classes). Como el lector podrá observar, AFC tiene mucho que ver con MFC y, efectivamente es así. Ambas provienen de Microsoft y, en el caso de las AFC, un aspecto básico es el que ya hemos citado: guarda completa compatibilidad con las AWT. Realmente, las AFC se limitan a extender las AWT y proporcionar nuevas clases a los programadores. Así, se contemplan nuevos controles, como por ejemplo barras de herramientas, diálogos con pestañas, etc. Además de extender a la AWT, las AFC permiten mezclar ambas librerías dentro de una misma applet. Actualmente la versión GUI de las AFC se puede localizar dentro del Microsoft SDK 2.0 para Java.

Sin embargo, las AFC van más lejos y están disponibles en una versión superior a la GUI. Está versión es la denominada empresarial e incluye un conjunto de servicios destinados a la informática distribuida. Así se puede encontrar dentro de las AFC Enterprise servicios de directorio, acceso a datos y comunicaciones entre objetos distribuidos. Estando escritas en Java, u por lo tanto siendo completamente portables, las AFC Enterprise soportan buena parte de los protocolos estándar, entre los que se encuentran LDAP, HTTP y DCOM. Ambas librerías, la GUI y la Enterprise, serán incluidas dentro de Microsoft Explorer 4.0, así como Microsoft está trabajando para exportarlas a algunas versiones comerciales de Unix.

Al igual que sucede en otras ocasiones, las que marcan el rumbo de la programación son las compañías con los productos que sacan al mercado. Por eso, a continuación

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información