"Es hora de echar a Java de la ciudad" InfoWorld
AbrahamComo ya hemos cubierto en múltiples ocasiones en este portal (1, 2) la situación de java en el escritorio actualmente a nivel de seguridad es patética, siendo el principal vector de ataque contra equipos Windows. Y, tras el troyano para Mac descubierto recientemente, que ha infectado a más de 600,000 equipos, puede que Java también lidere el ranking de infecciones en esta plataforma.
Todo esto ha llevado a InfoWorld a publicar un artículo titulado "Es hora de echar a Java de la ciudad" que comienza así:
A Java security hole just nailed 670,000 Macs, and Java accounts for more Windows infections than any other source. It's time to get rid of Java and stop the madness
Aunque la mayor parte del artículo es correcto, el autor comete un error en cuanto a la raíz del problema. El problema realmente no es que Oracle sea incapaz de resolver estos problemas (como afirma el artículo). Java tiene los mismos problemas que Windows, Mac, cualquier navegador web, o cualquier otra pieza de software empleada por mucha gente. Todos ellos tienen múltiples agujeros de seguridad. Y, para evitar que esos agujeros sean explotados la única solución es parchearlos según se van descubriendo. Nadie ha encontrado todavía la forma de escribir un software sin agujeros de seguridad.
El problema con Java es que los usuarios no saben qué es, no saben por qué lo tienen, y no lo actualiza manualmente. La solución, como ya hemos repetido en múltiples ocasiones, es actualizar de modo trasparente y automático el JRE. Igual que se actualizan de modo automático por defecto los sistemas operativos. Igual que lo hace Chrome, igual que pronto lo hará Firefox e Internet Explorer en la versión 10.
Respecto al troyano Flashback, si eres usuario de Mac y tienes Java instalado te recomiendo que compruebes si ha sido infectado por el visitando esta web de Kaspersky.
Reader Comments (19)
@Abraham
Hemos hablado de esto en infinidad de ocasiones.
Haciéndola corta.
El problema no es "java en el escritorio", el problema es "java en los browser's".
El problema tampoco es "java en los browser's".
El problema son los browser's, y da igual, si el vector de ataque es un applet, un activex, un flash, una imagen o un streaming de video.
Y este es el motivo por el cual arrastrar WebKit como parte de JavaFX en lugar de empotrar el navegador de la plataforma al estilo de Native Swing me sigue pareciendo una pésima idea.
Un saludo.
De acuerdo, aunque en la práctica "Java en el escritorio" implica que tienes "Java en el navegador".
Es un problema de retorica (o, más bien, de argumento de venta).
¿Cómo puedes venderle a un cliente un desarrollo en java para el desktop, si este vive leyendo que java no sirve como cliente de aplicación?.
Además el tema de los plugin en los browser's es algo que tienden a desaparecer, por lo que el problema se resolverá por sí solo a la manera de Robespierre.
Nota:
En algunas empresas por "política de seguridad" la ejecución de applet's y de flash en el browser está bloqueada.
@Abraham
"... aunque en la práctica "Java en el escritorio" implica que tienes "Java en el navegador"'.
No necesariamente. Yo uso habitualmente Chrome, que por ser un navegador de 32 bits no usa, porque no puede, mi instalación actual de Java SE 1.7u4b19 de 64 bits.
Para usar el plug-in de JavaSE con este navegador, debería instalar adicionalmente una versión de JavaSE de 32 bits.
@choces
pero la 1.7u4b19 es un developer preview, no es una versión ampliamente utilizada por la mayoría de los usuarios...
Añadir al comentario de Antonio que aquellos usuarios que tienen Java 7 u4 no son precisamente el problema. El principal problema son los que tienen Java 6, Java 5, Java 1.4... y no ven ningún motivo para instalarlo, porque realmente ni saben qué es lo que tienen ni porque lo tienen.
Siguiendo el criterio del artículo en InfoWorld,
¿Para resolver este problema, abría que prohibir las aplicaciones instaladas en móviles?
RootSmart - la nueva red zombi de teléfonos móviles
Puse ese ejemplo de JavaSE 1.7 de igual manera que podría haber puesto otro relativo a versiones anteriores de Java; porque también tienen versiones de 64 bits, no solamente una Developer Preview.
Y me quería referir exclusivamente al hecho de que tener instalado Java no implica necesariamente que también se tenga "por defecto" en el navegador de Internet.
@efrigerio
Siguiendo los criterios del autor de ese libelo, porque no es otra cosa, él mismo debería haber recomendado que se retirase Windows a otra galaxia, más que fuera de la ciudad.
Pero claro está, ni lo hizo ni lo hará jamás, porque se gana la vida escribiendo libros y artículos sobre Windows y Office.
Pues si la solucion es hacer una actualizacion automatica sin que el usuario se entere...
De entrada eso de que el sistema se actualice sin avisarme a mi me pone negro. Desinstalo lo que sea que haga eso. Otra cosa es que me diga "me tengo que actualizar ¿me dejas?". Entonces seguramente le de al boton sin pensar mucho.
Y ese es el segundo problema (que igual se soluciona), que Java no se actualiza, se reinstala. Java no dice "tengo un problema en el Vector.class, asi que me la bajo. Aguanta la respiracion que en 30 segundos esto lo tengo solucionado". Java dice "tengo un problema en el Vector.class, asi que me bajo los 70 megas de la nueva version y me reinstalo de nuevo (y el anterior ya vere como te lo dejo). Aguanta la respiracion 20 minutos y respondeme tres preguntas, porque claro, tu tienes el jdk, pero te voy a preguntar donde te pongo el jre y si quieres unos ejemplos o las fuentes".
Y ese don de gentes que han tenido tanto Sun como Oracle para llevarse mal con los que hacen los sistemas operativos tampoco es que ayuden mucho a la hora de integrar las actualizaciones en el resto del sistema operativo. Igual lo de los parches se arregla con el JDK ese que va a tener las librerias por partes, pero lo de la integracion con el sistema operativo no termino de verlo porque el amigo Ellison no parece el tio mas simpatico del barrio (mas bien al reves).
El problema de Java en el escritorio es que ni Sun ni Oracle se han preocupado por el escritorio lo mas minimo. Ellos viven en el mundo corporativo, en el servidor, donde la actualizacion se hace como una parada programada de noche, se contrata asistencia tecnica (que cuesta un cojon de pato) y por gente que sabe lo que esta haciendo (a veces ;) ), no en el señor que ve el ordenador como nosotros vemos la lavadora, como un electrodomestico mas que no queremos que de problemas.
Por una vez y sin que sirva de precedente ;), de acuerdo con nilogj. Aparte de con choces. O sea, el problema es que los usuarios no tienen algo en su sistema actualizado y la solución es... tirarlo... claaro. Y la funcionalidad que da eso la haremos con otra cosa que seguro segurito que los usuarios tendrán actualizada.... sí, ya...
La solución de actualización automática transparente de algo a tan bajo nivel... a mí que no me busquen. Pero si que se podría mejorar mucho, por que Java si se actualiza desde hace unas cuantas versiones, lo que pasa es que es un cristo.
Por cierto que todo esto no tiene que ver con Java el lenguaje, si no con programas nativos escritos en otro lenguaje, ¿adivináis cual?, lo cual viene más bien a reivindicar la idea de Java de applets/Java Web Start con aplicaciones autoactualizables. El problema es que una cadena es tan frágil como su eslabón más débil, y en este caso suele ser el código nativo.
Hay un error de fondo, del que ese "artículo" es un exponente reducido al absurdo, que consiste en ver el JRE como un "aditivo" del navegador de Internet, una extensión más del mismo, que solo sirve para poco más que reproducir "programitas" en forma de applets.
Desde esa perspectiva ridícula, se entiende lo que el autor pretende: o se arregla, o se tira; porque en definitiva, solamente un 3% del total de sitios de Internet requieren del JRE en el ordenador cliente.
Sin embargo, el JRE se parece más a un Sistema Operativo, que a una simple aplicación del mismo. Es una "aplicación" únicamente en el sentido de que necesita iniciarse desde un Sistema Operativo; pero su función consiste en ejecutar aplicaciones escritas en Java.
El hecho de que esas aplicaciones dependan del JRE, hace que las actualizaciones del mismo puedan provocar efectos indeseados en las aplicaciones mismas, cuando no bugs sonoros, como ha sucedido varias veces en el pasado.
Las aplicaciones escritas en Java deben verificarse exhaustivamente con cada nueva versión del JRE, antes de recomendar su actualización. Y con frecuencia, deben realizarse modificaciones en el código, si se quiere que se ejecuten sin problemas en un nuevo JRE.
La compatibilidad no está garantizada por completo, en ningún caso, tanto si se codifica en Java como en cualquier otro lenguaje. Hay ejemplos sobrados, de los que no se libra ningún fabricante de lenguajes o sistemas operativos.
Por ello, las actualizaciones automáticas del JRE, con las ventajas que sin duda tiene, también plantean serias dudas sobre las posibles consecuencias sobre las aplicaciones, que posiblemente no se hayan probado todavía con la nueva versión.
Vaya presentación de artículo más tendenciosa :D
- Oracle cuidará Java en el escritorio si tiene necesidades comerciales para hacerlo. Actualmente, no parecen ser muchas.
- Actualmente Java en el escritorio es francamente malo (iba a escribir algo peor) y que desaparezca seguro que dolerá a los usuarios corporativos (en donde hay bastantes cosas desplegadas) pero a nivel doméstico, será una bendición. Por mi parte, la única aplicación en Java que uso, SQL Developer, no desaparecerá. Oracle no podrá ahorrar dinero empleando la misma base de código para todas las plataformas, pero nuestra calidad de vida subirá varios enteros :)
Jugar en el escritorio es durísimo y, o se hace bien, o es un problema con muchas facetas. La seguridad es una de ellas. Y Java en el escritorio está muy lejos de ser una buena plataforma.
@Juan
No sé exactamente a qué te refieres con "Java en el escritorio", y menos aún con eso de que "es francamente malo".
¿Crees que aplicaciones como Vuze, aTunes o LimeWire, por citar algunas de las más conocidas, son "francamente malas"?.
¿Estarían de acuerdo sus usuarios en que desaparezcan, porque sería una bendición para ellos?.
Las actualizaciones automáticas podrían ser por cuestiones de seguridad y cuando se tengan nuevas características entonces ahora si preguntar "desea cambiar a java 9.1 que ahora tiene X y Z mejorado".
Las actualizaciones no tienen por que echarnos abajo todo lo creado. Pero creo que aquí afecta mas la velocidad de Oracle, siempre me ha parecido una empresa lenta, cualquier mejora tiene uno que esperar sentado.
@choces Tienes razón: lío de nombres. Por Java en el escritorio me refiero a aplicaciones para Windows, Mac, etc.
No van a desaparecer, está claro. Pero si aparecen aplicaciones nativas, ahí estaremos (de hecho, ya hay bastante gente migrando, yo entre ellos)
Conozco Vuze y creo es un buen ejemplo. El desarrollo de los programadores es sensacional (funcionalidad, gestión de plugins, opciones con complejidad escalable, conexión con otras librerías -vídeo, dispositivos con streaming, etc) y precisamente los aspectos más negativos no vienen de ellos, sino del uso de SWT en él (y eso que es al menos SWT, en muchos casos un mapeo directo a Cocoa).
¿Qué aspectos en concreto? Al menos estos (te hablo de Mac):
- Uso brutal de memoria y de CPU. A veces es absurdo ver lo que consume.
- Lentitud en la respuesta del UI. Ridícula en muchas ocasiones (ej: cuando tienes un número sensible de archivos y haces click con el botón derecho para obtener el menú contextual tarda sobre 2 segundos). En algunas pantallas puedes ver cómo se "dibujan".
- Las mejoras, peculiaridades de Mac para aplicaciones, al retrete (esto es aún peor en aplicaciones Swing obviamente)
- Algunos de los aspectos del uso normal de Mac (ej: arrastrar y soltar hasta el escritorio para obtener una copia de los seleccionado) desaparecen. Se convierte en un PC.
Las aplicaciones con Java son más fáciles de desarrollar y mantener para múltiples plataformas (que no es poco en absoluto y es muy útil y una decisión de peso en algunos contextos). Pero eso es todo.
@Juan
No uso Vuze, y tampoco Mac. Pero quiero comentar que para hacer aplicaciones gráficas en Java, al menos con Swing, se necesitan dos habilidades, que por separado ya son difíciles de por sí, y juntas...
1.-Es imprescindible un dominio completo de las capacidades multitarea de Java.
El hecho de que Swing se ejecute en un único thread, el EDT, plantea desde siempre una dificultad al tener que separar en diferentes threads la representación visual (que se ejecuta en el EDT), y la creación y actualización de los modelos, que deben ejecutarse en tareas paralelas, para no bloquear el EDT.
Es muy habitual ver código que ejecuta tareas necesariamente lentas (accesos a disco, a red, a bases de datos), en los mismos listeners de Swing (¡Qué barbaridad!), por no decir en secciones de código que se ejecutan por necesidad en el EDT.
La mayoría de las quejas sobre la lentitud de Swing se deben, en gran medida, a una incomprensión de la necesidad de usar la concurrencia, y dónde y cómo usarla.
No es nada fácil, ni siquiera evidente.
Otro error habitual, que causa desde lentitud hasta artefactos extraños, cuando no cuelgues, es justamente lo contrario: ejecutar código fuera del EDT, cuando debería hacerse dentro.
2.- Swing es muy complejo de codificar
Si no se conoce su API a la perfección, y si no se saben utilizar con eficiencia los listeners y los events, el código acaba siendo un completo caos. Tareas en apariencia tan simples como llenar una JTable, una JList o un JComboBox, con datos procedentes de una base de datos, y enviar las selecciones de usuario a otros componentes de Swing, se convierten en la práctica en un galimatías de código lento, obtuso, casi imposible de mantener, y no digamos ampliar o mejorar.
Cuando las dos dificultades anteriores están medianamente resueltas, se puede lograr que Swing funcione con un elevado rendimiento, aparte de la mantenibilidad y extensibilidad necesarias.
Hace algún tiempo publiqué este enlace que sigue:
http://idisk.mac.com/han.solo-Public/SteelSeries/test.jnlp
mediante el que se puede comprobar la eficiencia de una excelente codificación en Swing.
Dejando claro que el problema son los browser's, y no el escritorio,
Dejando claro que los plugin's en los navegadores tienen los días contados.
Entonces, hablemos de update automático en la jvm.
¿Cuántos de ustedes son usuarios de Ubuntu?.
En esta distro (y en otras) el gestor de actualizaciones, no solo se encarga de actualizar los paquetes del SO, sino también el resto del software instalado (OpenOffice, Firefox, Flash Player, OpenJDK, etc..).
Microsoft tiene una política similar, pero limitada a software propio (Microsoft Office, Internet Explorer, .NET y demás yerbas), no está abierto para terceros.
¿Conclusión?.
Si a M$S tanto le preocupa Java como factor de riesgo, y teniendo en cuenta que (de palabras de la propia Microsoft), java es en Windows un "ciudadano de primera categoría", deberían ofrecerle a Oracle (o al OpenJDK) las mismas facilidades con las que cuenta.NET.
Y lo mismo va para Apple, que el haber pateado el JVM al OpenJDK, no significa desentenderse y solo criticar el trabajo ajeno.
Todo esto, es independiente de Oracle, IBM, Red Hat y el resto del Java Community Process / OpenJDK, pero tampoco los libera de dejar de parlotear y ponerse a trabajar enserio en GUI para todos los SO/arquitecturas de hardware más extendidos (incluyendo ARM).
Lo que más me molesta de estas notas es la forma en que se distorsionan las cosas y se sacan de contexto.
Un saludo,