Yo sé que Java prometía ser un lenguaje casi universal, pues parecía cumplir con la expectativa escríbase una vez y córrase en cuanta plataforma halle. Todo esto es factible porque Java trabaja sobre una máquina virtual y entonces no hay que escribir un compilador para cada plataforma. Se cambia esta ingrata tarea por la de escribir una máquina virtual lo cual, parece ser, es mucho más fácil de hacer. De hecho los emuladores son una solución económica a muchísimos problemas de compatibilidad y el software actualmente tiene el suficiente nivel de abstracción para lograr este cometido.
Java, supuestamente, funciona en algo que se llama un “sandbox”, un arenero, una analogía para indicar que lo que corre en el arenero no puede salir de ahí y por ende, los virus son imposibles. Sin embargo, hay reportes de posibles virus como el “Java.Trojan.Exploit.Bytverify.Q”, el cual, se dice, aprovecha la vulnerabilidad de Java Runtime Environment para ejecutar código malicioso. El peligro, afirman, acecha en los ‘applets’ de Java que se integran en las páginas web. A mí no me queda estrictamente claro cómo es esto posible de acuerdo a la definición de seguridad de Java, pero evidentemente no faltará quien haya encontrado una manera de brincarse las trabas que originalmente pone el sistema.
Y la verdad es que Java suena como una muy buena idea y tiene montones de virtudes que no hay que despreciar, amén de que hoy en día hay muchísimas bibliotecas de funciones para todos los gustos y necesidades. Es increíble la cantidad de gente que ha escrito código y rutinas para Java. No es un asunto que debiésemos despreciar.
Sin embargo, el problema es el tipo de aplicaciones y programas que se pueden hacer con Java. En muchos casos, queda claro que Java es una buena opción, pero hay un caso interesante en donde me pone a dudar el usar Java. Se trata cuando las aplicaciones por escribir tienen que ver con sistemas que inherentemente buscan ser seguros. Hablamos de los bancos o bien del SAT, en donde los usuarios (con eso de la factura electrónica), están mucho más involucrados para hacer todo el asunto de sus impuestos vía una página web.
Y si vamos a la experiencia práctica, ocurren una serie de factores que me ha tocado ver de primera mano en el uso de Java y particularmente en el SAT (Servicio de Administración Tributaria). Por ejemplo, si como yo, no se recuerda la clave (contraseña) con la que se definió la FIEL (Firma Electrónica Avanzada), está perdido, porque no podrá facturar electrónicamente. La solución es relativamente simple pero implica ir a la oficina local del SAT para pedir una nueva firma electrónica avanzada. No hay que llevar más que una identificación y un USB o disco compacto para que le graben la información. Curiosamente para ello se puede bajar un programa del sitio del SAT para generar un archivo con extensión “.req” y con él, al ir a la oficina del SAT, le generarán los archivos “.key” y “.cer”. Pero oh, uno descarga el archivo y cuando lo quiere ejecutar en el navegador, Java se niega a hacerlo.
Y esto es uno solo de los detalles. Otro es el acceso a la información de cada usuario que factura electrónicamente. Por una parte, el manejo de bases de datos parece ser una cuestión crítica y resulta que al hacer una factura nueva, a veces el registro tarda hasta 72 horas en generarse. ¿Tantas horas? ¿Por qué? ¿No debería ser inmediato? ¿Dónde está el cuello de botella? ¿En el manejador de bases de datos usado? Misterio.
Y no quiero exagerar, pero el sistema simplificado de facturación electrónica es malísimo, mal explicado, lento, en donde muchas veces no funciona si uno usa Chrome, Firefox o el inútil pero favorito del SAT, el Internet Explorer. En ocasiones no se sabe qué está pasando porque aparece un símbolo como que el sistema está cargando algo pero no pasa nada en la pantalla en un buen rato. Sigo sin entender muy bien qué software es el responsable de todas estas dificultades.
Si a mí me hubiesen preguntado cómo hacer un sistema de esta naturaleza, hubiese elegido otra opción. Mi enfoque hubiese sido hacer programas clientes para las diferentes plataformas, los cuales pudiesen acceder a las bases de datos de los usuarios en particular. Por una parte, los sistemas tenderían a ser más ágiles, porque solamente se mandarían y se recibirían los datos, sin necesidad de mandar toda la parafernalia que significa por ejemplo, crear la factura electrónica en línea. De hecho, éste es el enfoque de algunos sitios web donde interactúan con el usuario. El sistema en donde se ven sus ventajas es por ejemplo el Internet Chess Club – ICC, un sitio web donde se puede jugar ajedrez en línea. A diferencia de Yahoo, por ejemplo, que su “club de ajedrez” funciona usando un programa que corre en Java en el navegador, el ICC corre un cliente en la plataforma de cada usuario y solamente manda la información relevante de las partidas. La diferencia en el desempeño de Yahoo contra el del ICC es evidente: el segundo supera en agilidad y precisión al sistema escrito en Java.
Mi opinión sobre todo este asunto de usar Java para estos sitios de -digamos- misión crítica no es la mejor. De acuerdo con este sitio, podemos entender por sistemas de misión crítica a aquellos servidores que ejecutan aplicaciones esenciales que, si fallan, tienen un impacto significativo en el funcionamiento de cualquier empresa, organización o institución que dependa de su información. Quizás lo que ocurre es que todo esto de la factura electrónica va evolucionando y por ende, hallamos las dificultades normales porque aún estamos aprendiendo a hacer estas cosas. No obstante esta argumentación, me queda claro que en este país hay suficiente masa crítica de neuronas que pudo haber llevado a una solución mucho, pero mucho más eficiente en el SAT, y sin necesidad de Java.