Tuesday March 16, 2004
El dichoso Ping en Java ¿Qué informático no ha ejecutado nunca el siguiente comando?
C:\>ping www.yahoo.es
Haciendo ping a www.euro.yahoo.akadns.net [217.12.3.11] con 32 bytes de datos:
Respuesta desde 217.12.3.11: bytes=32 tiempo=202ms TTL=243
Respuesta desde 217.12.3.11: bytes=32 tiempo=317ms TTL=243
Respuesta desde 217.12.3.11: bytes=32 tiempo=235ms TTL=243
Respuesta desde 217.12.3.11: bytes=32 tiempo=258ms TTL=243
Estadísticas de ping para 217.12.3.11:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 202ms, Máximo = 317ms, Media = 253ms
Es tan común que parece extraño que incluso en la versión actual de Java 1.4.2 no exista ninguna función con ese cometido, pero es que además tampoco puede implementarla uno mismo programando sólo en Java. Por ambos motivos, por lo habitual y la falta de una solución, es tanto una de las preguntas más frecuentes que hacen los desarrolladores que se inician en Java, como una de las peticiones más demandadas a Sun, concretamente la número 4727550 ICMP protocol support a.k.a. PING applets pide que se pueda hacer un ping con código Java ya en Noviembre de 1997 (!hace más de 6 años!), teniendo con sus 254 votos un lugar destacado entre el top 25 de fallos y peticiones de mejoras sobre J2SE.
¿Por que tantos problemas por un simple ping? Pues porque no todo es tan sencillo como parece a primera vista, el asunto no se resuelve con una conexión normal tipo HTTP, sino que este comando excepcionalmente necesita de ICMP que es un protocolo de red de bajo nivel, utilizado por ejemplo para la monitorización de la red o el enrutado. Pero el acceso a ICMP se considera privilegiado ya que su mal uso puede comprometer la seguridad del sistema, por lo que sólo está disponible para el usuario root en Unix o el Administrador de Windows. Por ejemplo en Linux para resolver este inconveniente el comando ping ignora nuestra identidad actual y se ejecuta como root automáticamente, sin necesidad de preguntarnos una contraseña, esto es seguro porque el administrador nos concede estos permisos sólo durante el ping, que es un ejecutable en el que confía y que no puede ser modificado por otros usuarios salvo él mismo. Actualmente no existe ningún API en Java sobre el protocolo ICMP, eso queda pendiente para otra futura mejora ya con 65 votos, pero aunque fuese ese el caso difícilmente el usuario va a conceder alegremente permisos de root o Administrador a nuestros programas Java sólo porque le expliquemos que queremos hacer un ping, mucho menos si se trata de un applet o de una aplicación servidor.
¿Que podemos hacer entonces? La solución más fácil consiste en ejecutar el comando ping de nuestro sistema operativo utilizando la función Runtime.exec y comprobar el valor de retorno que nos dirá cuando el ordenador responde o no. Hay que tener en cuenta que los parámetros del comando ping y su funcionamiento varían ligeramente en Linux y Windows, además el sistema de seguridad de Java nos pedirá autorización si se trata de un applet o una aplicación con webstart, pero no será necesario que seamos ni root ni Administrador. Problema resuelto, no es 100% Java pero sí bastante portable.
A partir de J2SE 1.5 tenemos una opción más. La clase java.net.InetAddress tiene una nueva función public boolean isReachable(int timeout) que viene a ser más o menos como un ping. Esta función intenta determinar si puede establecer una conexión con un ordenador remoto, para ello en primer lugar cuando el usuario tenga los permisos de administrador necesarios enviará un ping, en caso contrario enviará un ECHO. ¿Que es un ECHO? Pues poca cosa, otro protocolo utilizado para determinar si un ordenador está activo o no, tiene la ventaja de que sí se trata de un protocolo normal sin restricciones de seguridad (puerto 7), pero el grandísimo inconveniente de que la mayoría de los ordenadores que sí responden al ping ignoran completamente el ECHO. En la práctica esto significa que si no tenemos esos permisos de administrador la función
isReachable no va a poder establecer una conexión en la mayoría de los casos aunque tenga el otro ordenador perfectamente funcionando a dos palmos. Además me he encontrado que en la versión beta actual de J2SE 1.5 esta función en Windows produce una excepción si el usuario no es el Administrador, en vez de mandar ese ECHO como indica su contrato, cosas de betas supongo.
¿Es que no hay una solución mejor? La verdad es que sí, pero requiere plantearse el problema incial y preguntarse ¿para qué necesitamos enviar un ping? ¿que significa establecer una conexión? Por ejemplo quizás queramos descargar unas páginas web para el usuario, tenemos que tener en cuenta entonces que aunque el ordenador remoto nos responda al ping es posible que su servidor web no funcione o que sencillamente no tenga ninguno, además también es habitual encontrarse con servidores web que por seguridad no responden al ping. En este caso el ping no nos aporta la información que queremos, si el servidor web es o no accesible, en su lugar como mecanismo de comprobación es mucho mejor establecer una conexión HTTP habitual que sí nos dirá si el servidor web responde o no, además sin caer en las restricciones de seguridad del ping. La mayoría de las situaciones son muy similares, normalmente lo que queremos saber es si un servicio de un ordenador remoto está operativo, como el servidor web, un servicio XMP-RPC o cualquier otro, una conexión específica a ese servicio con su protocolo nos proprocionará una información más fiable que un simple ping. No es siempre así, en un caso me encontré con una aplicación J2EE que necesitaba comprobar si unos ordenadores estaban encendidos o no, un ping implementado con una llamada al comando del sistema operativo fue la solución en ese caso, pero sólo ha sido una vez entre muchas otras.
Así que la moraleja de esta historia es pensarse dos veces si necesitamos un ping o no, seguramente tendremos una mejor respuesta consultando el servicio que nos interesa, además con código 100% Java.
(2004-03-16 23:09:11.0)
Permalink
Comentarios [3]
Monday March 01, 2004
JBoss explica su aventura de capital riesgo
Utilizando un blog como medio JBoss ha explicado las motivaciones que le han llevado a buscar el apoyo de un inversor de capital riesgo, y de paso intenta despejar algunas dudas que puedan existir entre sus usuarios (perdón, clientes) tras este movimiento.
JBoss quiere dejar de ser percibido como el servidor J2EE casero, útil durante el prototipo pero que finalmente acaba siendo substituido cuando llega la hora de la verdad por otro comercial, más fiable, con un buen soporte y como no bastante caro. Para eso no sólo necesitan competir con un buen producto, algo en lo que obviamente ya venían trabajando, sino con un buen servicio. Y eso les va a costar dinero.
En el último año han ido cambiado su modelo de negocio basado en la consultoría para centrarse en el soporte, como con sus nuevos contratos de soporte 24x7. El pastel es más que apetecible, por ejemplo el artículo habla de unos ingresos por parte de BEA en concepto de soporte de $250 millones (también es verdad que BEA es mucho BEA). Como pez pequeño ellos competirán entre otras cosas con un mejor precio, o sea no tan absurdamente desorbitado como los que rondan en J2EE, por ejemplo no estará basado en el número de CPUs sino en aplicaciones. El papel aguanta todos estos proyectos de crecimiento y expectativas, pero si te inyectan $10 millones es porque tu plan de empresa es bastante sólido, no se los dan a cualquiera.
Comentan también que en sus contactos con más de veinte firmas de capital riesgo buscaron aquellas que compartían esa visión de negocio, descartando ya de entrada aquellas que pretendían obtener ingresos creando una edición extendida del servidor JBoss con una licencia comercial ya no gratuita. Su intención es mantener el producto bajo la misma licencia LGPL, de hecho en la práctica no es tan fácil cambiarla ya que no tienen el copyright de muchas colaboraciones.
Relacionado con JBoss pero en otro sentido, está previsto que esta semana sea liberada la versión 1.0 ya definitiva de JBoss Nukes, un CMS insparado en postnuke (PHP) que últimamente está despertando bastante interés. Un nuevo CMS a la lista, que ya es extensa, de soluciones open source en Java, para que no se diga que a los desarrolladores no nos gusta reinventar la rueda.
(2004-03-01 22:13:45.0)
Permalink
Comentarios [0]
Thursday February 19, 2004
JBoss apuesta por crecer deprisa
Hoy JBoss ha anunciado oficialmente haber llegado a un acuerdo con una firma de capital riesgo para financiarse, en una primera fase por $10 millones. Bueno, debería decir The JBoss Group, que no es exactamente lo mismo que simplemente JBoss.
Dentro de la comunidad de desarrolladores en Java, si es que ese concepto existe, The JBoss Group ha levantado sentimiento opuestos. Criticado por muchos por la manera en la que ha llevado a cabo su transición de un simple proyecto open source a un modelo empresarial, pero también alabado por otros por conseguir pertenecer al exclusivo grupo de empresas basadas en un producto open source propio. Tampoco es que ayudasen mucho las polémicas con Sun sobre si debía o no pagar la certificación, o con el proyecto Geronimo con advertencias de abogados incluida.
Tendremos que esperar todavía algún tiempo para ver qué consecuencias tiene este paso. ¿Seguirán basando su modelo de negocio en el soporte de tercer nivel? ¿Se plantearán nuevas formas de ingresos? Se admiten apuestas, la solución aproximadamente dentro de un año.
(2004-02-19 21:14:04.0)
Permalink
Comentarios [0]
Wednesday January 28, 2004
Moneydance gratis
Si buscais una aplicación de control de gastos domésticos gratuita y que además sea decente la verdad es que no teneis muchas opciones. Yo soy usuario desde hace más de un año de gnucash, un programa que además de gratuito es open source, aunque esto último es para mí ahora mismo poco importante, vamos pienso como un usuario que busca un producto final y no como un desarrollador en C interesado en colaborar.
Un punto a favor de gnucash es que es una aplicación que sencilla, algo que después de haber utilizado algunos productos comerciales de la competencia se agradece. Sencilla que no simple, con lo que ya hace gnucash la verdad es que me sobra, no necesito la nueva funcionalidad que se le está dando para además gestionar un pequeño negocio. Además es un proyecto vivo, cada cierto tiempo aparece una nueva versión, lo que da unas ciertas garantías de continuidad y nuevas prestaciones.
Lamentablemente tiene algunos inconvenientes. Uno es que sólo funciona en Linux, eso por sí sólo ya lo convierte en un producto minoritario. Otro es que instalar las nuevas versiones desde el código fuente es bastante palo por el lío de dependencias, o sea que normalmente uno se apaña con la versión que acompañana a la distribución de Linux que suele estar bastante retrasada. Alguna vez se me ha colgado sin guardar los datos, una experiencia que no es agradable.
Tan sencillo me parece gnucash, si no tenemos en cuenta algunas características avanzadas que me parecen un poco dudosas, que de vez en cuando me ronda por la cabeza hacerme una aplicación para mí en Java y ser completamente autosuficiente. Podría ser como no open source.
También hay una aplicación comercial hecha ya en Java, Moneydance, que me parece muy interesante, es similar a gnucash pero además de ser mucho más bonita es portable y funciona también en Windows. La única razón por la que no la he probado más a fondo es que cuesta 30$.
La novedad es que ahora Javalobby ha llegado a un acuerdo por el que está distribuyendo Moneydance de manera gratuita, sólo necesitas ser un usuario registrado y visitar esta página.
Si no habeis probado ningún software de este tipo os recomiendo que le deis una oportunidad. Tras haber introducido unos cuantos datos y generar unos cuantos informes es posible que os guste y os sorprendan algunos resultados. Será que soy catalán.
(2004-01-28 23:29:59.0)
Permalink
Comentarios [3]
Tuesday January 20, 2004
Demasiado XML
Todos somos tarde o temprano víctimas de las modas. Uno de estos abusos está en la programación en un script basado en XML, algo en lo que seguramente ha influido mucho Ant. Por ejemplo por ese motivo Maven, la nueva herramienta de construcción de proyectos de Jakarta, utiliza también XML como lenguaje, y gana así compatibilidad con los scripts en Ant. Otra influencia notable es sin duda Jelly, una extensión de los conceptos de Ant que permite introducir en un script XML elementos más complejos como control de flujo con bucles y condicionales, variables, funciones, etc.
Leyendo un mensaje reciente de la lista de usuarios de Maven me he encontrado con la siguiente frase de Jason van Zyl, uno de los desarrolladores:
"Ya no soy un fan de Jelly. Ya sé que hay gente que parece estar enamorada de la programación en XML pero creo que es el mayor error que he cometido con Maven, algo que nos has costado mucho. No cometeré errores similares en el futuro".
No puedo estar más de acuerdo. Llevo dos años trabajando en un proyecto donde la personalización con un script es un elemento crucial. Influenciado por la experiencia de éxito de Ant concebí un script basado en XML para que los usuarios (de alto nivel) pudiesen utilizar las tareas que les proporcionaba el lenguaje, que eran como plugins (al estilo Ant). Desde hace ya unos meses sustituimos este lenguaje por un script que ahora es compatible con Python, todo ello gracias a un excelente proyecto open source llamado Jython que combina ambos lenguajes.
Python tiene una sintaxis tan clara (ni { ni } ni ; en el código), es tan incremental (inicialmente no necesitas aprender conceptos como las clases para empezar a trabajar) y tan productivo (no necesitas compilar y puedes probar el código sobre la marcha en una consola interactiva) que ahora nuestros usuarios lo prefieren a la alternativa en XML. Encima para nosotros es más fácil trabajar con Jython, nos cuesta menos mantener el código y sólo tenemos que diseñar un API que desde el script es ya directamente accesible. Tampoco tenemos que educar desde cero a los usuarios porque ya tienen un montón de recursos disponibles sobre Python, sólo les enseñamos como funciona ese API sencillo. Y a medida que los usuarios con la práctica adquieren pericia tienen a su disposición toda la potencia de Python, como una amplia librería estandard para que hagan scripts que nos sorprendan a nosotros mismos.
Desde Maven ya se está hablando de substituir el script XML por otro lenguaje más adecuado como BeanShell, Groovy o Jython, conservando la compatibilidad con el script XML como mínimo inicialmente. También en su día el tema levantó interés en el equipo de Ant. Espero que sepan adaptarse a pesar del coste que supone una refactorización así, si no lo hacen ellos lo harán otros.
Esta era una entrada combinada, un mea culpa público y unas palabras de ánimo para Ant y Maven.
(2004-01-20 22:18:40.0)
Permalink
Comentarios [0]
Wednesday December 24, 2003
Ya tenemos J2SE 1.5 en alfa
Ya podemos examinar una versión en construcción de la esperada J2SE 1.5, más o menos un mes después de que Sun se comprometiese a dar ese paso. Es la primera que se nos permite examinar un J2SE mientras aún está siendo desarrollado, lo que sin duda es un buen gesto por parte de Sun, su regalo de Navidad.
Una muestra de la influencia y expectación que tuvo la noticia en Javalobby es que la distribución de J2SE 1.5 es fruto de la cooperación entre este sitio y Sun, de manera que el enlace para la descarga se obtiene desde una página sólo para miembros de JavaLobby (o sea rellenar un formulario).
A diferencia de la versión Beta prevista para dentro de unos meses, se trata precisamente de un producto incompleto, con fallos y sin documentación. Sólo es útil para que los desarrolles echen un vistazo a parte de las características nuevas ya conocidas como los tipos genéricos o algunos JSR incluidos, y para que Sun reciba información sobre errores.
Esta versión se distribuye bajo una licencia de privacidad de modo que no puede ser comentada salvo con los empleados de Sun, así que nada de detalles en ningún blog, a ver si portándonos bien esta práctica se convierte en habitual. Parece que existe una lista de correo de Sun en la que sí se puede hablar sobre esta versión, pero de momento no está claro cómo subscribirse (¿?).
Lo único que puedo añadir son comentarios aplicables a cualquier otra versión, por ejemplo recordar que las herramientas de java utilizan parámetros para que funcionen las características nuevas de cada versión (como el habitual javac -source 1.4 -target 1.4). Si os bajais la versión de evaluación podeis haceros una idea de algunas novedades buscando en el código fuente la cadena "@source 1.5" que señala los cambios en la documentación javadoc, o mejor aún buscando con la expresión regular "@source\s+1.5", para así tener en cuenta las combinaciones en las que no aparece exáctamente un espacio.
Y de momento a probar y morderse la lengua.
(2003-12-24 17:52:35.0)
Permalink
Comentarios [0]
Monday December 08, 2003
El NetBeans que viene
Para el futuro de Java frente a otras alternativas, básicamente la única amenaza razonable me parece NET y por el empuje de Microsoft más que por sus méritos presentes, hay tres areas que resultan clave: el lenguaje, las APIs y las herramientas. El lenguaje es un punto fuerte de Java por su madurez y la amplia comunidad, que además ha pasado por una revisión y será mejorado con el objetivo de ganar en sencillez en la ya cercana J2SE 1.5, las APIs son sin duda otro de sus puntos fuertes, el número disponible de ellas no deja de crecer y otras compañias se involucran en su creación participando en el JCP, en cambio las herramientas siempre han sido históricamente el punto fuerte de Microsoft, basta con recordar a Visual Basic.
Desde hace unos pocos días ya sabemos que Sun e IBM han renunciado a unir sus comunidades de NetBeans y Eclipse, de manera que si hablamos de herramientas la responsabilidad recae del lado de Sun en buena parte sobre NetBeans. Y ya se han dado buenos pasos, por ejemplo los nuevos usuarios que se descarguen el SDK ya pueden hacerlo junto a este IDE, para cualquier programador de Visual C++ la primera impresión al encontrarse sólo frente a javac debería ser algo desoladora.
NetBeans es lento, NetBeans es feo y NetBeans no me ayuda con la refactorización. Esas son
probablemente las tres frases más pronunciadas por los detractores de NetBeans, y hay que decir que
las dos primeros eran verdad, la tercera lo seguirá siendo aún unos meses. Las dos primeras no es que
sean exclusivas de NetBeans, lo mismo se ha dicho de Java durante mucho tiempo no sin cierta razón,
francamente no me gustaría vivir atrapado en uno de los primeros NetBeans sobre aquellos JRE de hace
unos años sin optimizaciones en los que Swing tenía tantas features como bugs. Pero también sería injusto repetirlo una y otra vez sin molestarse a probar la versión 3.6 de NetBeans, actualmente en desarrollo, sobre el JRE 1.4.2_02 y en un ordenador de los de ahora (sí, en un pentium a 133 Mhz sigue siendo lento).
La nueva versión 3.6 de Netbeans en un alarde de precisión está prevista que esté disponible el 12 de Marzo. Si la versión 3.5 se centró en optimizaciones para mejorar su respuesta en la 3.6 se está atacando uno de sus puntos más críticados: su aspecto. Después de probarlo tengo que decir que el resultado hasta ahora no está nada mal, con menos sobrecarga de elementos visuales su apariencia es más sencilla y de paso la respuesta es más suave, como se muestra en esta imagen. Podeis ver ya algunos cambios, por ejemplo no hay workspaces (otro punto criticado porque parecía confuso) y las hojas de las propiedades tienen un nuevo diseño. Otras mejoras previstas son que incluye Tomcat 5, una lista de tareas que se genera automáticamente a partir de comentarios en el código fuente además de otras facilidades para editar el código como expandir y contraer fragmentos, añadir corchetes para terminar un bloque automáticamente o escribir cadenas de texto en varias lineas.
También hay prevista una planificación para la versión 4.0 unos cinco meses después. Refactorización es probablmente la característica más novedosa y demandada, para hay también otras llamativas como la integración con Ant y Junit en el IDE, y como no el soporte para JDK 1.5, J2EE 1.4 y Tomcat.
Sin esperar a tanto sólo la versión 3.6 de Netbeans puede hacer cambiar algunas opiniones.
(2003-12-08 21:37:41.0)
Permalink
Comentarios [9]
Monday December 01, 2003
Un logo demasiado comunista
El proyecto Maven está llamado a ser uno de los de más éxito de Jakarta / Apache, especialmente a partir de los próximos meses en los que aparecerá su versión 1.0. El número no debe tomarse como un indicador de que está en pañales porque llevan mucho tiempo trabajando y ha pasado por más de una docena de versiones y varias refactorizaciones. Maven está listo.
Se trata de una herramienta de construcción de proyectos que lleva Ant a un nivel superior en la cadena evolutiva. Puede construir toda una aplicación, gestionar dependencias, generar las páginas web, mostrar informes y mucho más de forma realmente sencilla, algo que en Ant sería tedioso y significaría miles de líneas en XML. Pero si uno prefiere Ant también puede tener los mejor de los dos mundos con Maven, que a cambio impone unas determinada maneras de trabajar, bastante razonables por cierto. Yo diría que es inevitable resistirse a Maven.
Todo proyecto necesita un logo, y Maven tiene uno. ¿Cuales son las cualidades de un buen logo? ¿Debe ser agradable? ¿Evocador? ¿Sencillo? Seguro que en esta lista de virtudes no tendría que aparecer la palabra polémico, pero las discusiones sobre el logo de Maven han degenerado en ese sentido en su lista de usuarios. El logo actual, conocido como Propaganda, es el siguiente:
Algunos usuarios y desarrolladores se han quejado de que la estrella y el fondo rojo tienen una cierta evocación comunista, además la letra E girada acaba por darle un tono soviético que tampoco es precisamente neutro. Es verdad que los tiempos de la guerra fría ya han terminado, pero a juzgar por las respuestas en las listas de Maven, algunas comparando las bondades del nazismo y de gobiernos como el chino, parece que el logo no es precisamente conciliador. Hay quien ha comparado la sensación del logo actual para un americanos con la que produciría un símbolo nazi en un europeo. Hay sin embargo quien sencillamente no le da ninguna importancia al tema.
Finalmente se ha organizado una votación en la que los desarrolladores pueden participar para cambiar el el logo anterior por otro, la pluma:
Si esta historia tiene una moraleja y sirve de algo es para que seamos un poco más cuidadosos. Las dos posturas, que el logo anterior deba mantenerse o que mejor sea substituido, pueden ser razonablemente defendidas y criticadas al mismo tiempo. Lo que está fuera de toda duda es que algo como el logo de una aplicación no debe ser un factor de división y polémica, así que aunque yo no tenga derecho de voto oficial ahí va el mio:
+1 a la pluma.
(2003-12-01 21:01:57.0)
Permalink
Comentarios [2]
Monday November 24, 2003
De momento no, pero pronto
Cuando me enteré del programa CAP para evaluar J2SE 1.5 envié la petición por correo, fue el mismo día que el programa fue desbordado por muchos otros usuarios y que ha motivado cambios en la planificación de la versión de J2SE.
Ayer me llegó la contestación de Sun, pronto tendremos una versión alfa:
Thank you very much for your interest in Sun's forthcoming release of
the Java 2 Platform, Standard Edition (J2SE) 1.5 code named "Tiger."
Sun appreciates your J2SE-related efforts and continued support. The
Javalobby and its many faithful members are critical to the success of
J2SE. Sun definitely wants your input, but the CAP program is not well
suited for hundreds of individual developers.
As a result of your feedback, Sun is planning to provide a broadly
available and simplified means to access an early release of "Tiger" in
the near future. See Rick Ross' posting for details
http://javalobby.org/thread.jspa?forumID=61&threadID=9648
Thank you again for your request and please accept our apologies for the
unintended confusion Sun caused with the Javalobby via the posting on
November 18, 2003.
Stay tuned...
===========================
J2SE CAP Program Team
Java Web Service
Sun Microsystems
(2003-11-24 15:16:17.0)
Permalink
Comentarios [0]
Thursday November 20, 2003
La buena noticía del día
Ayer comentaba como un ingeniero de Sun había informado de la existencia de un programa llamado CAP que permitía evaluar la nueva versión de J2SE 1.5 mientras se está desarrollando, antes incluso de que sea oficial la beta. Hasta entonces este programa era un secreto bien guardado, sino ya hace tiempo que le habríamos echado un vistazo a la 1.5 y sería comentada públicamente.
Lo sorpredente por contradictorio es que este ingeniero anució el programa en varios foros bastantes populares, y además que cada inviduo interesado podía inscribirse enviando un FAX, sin embargo un día después parecía sorprendido por la masiva respuesta. ¿Es que no era previsible el interés que despertaría? ¿No estaba bastante claro que una buena parte de la comunidad Java querría curiosear sobre el Java del 2004?
Ahora parece que el programa en principio había sido pensado para gestionar 20 participantes, pero después del anuncio público ya ha sido totalmente desbordado. Si el primer día ya tenían 350 peticiones, ahora que ya ha corrido la voz deben tener como mínimo unos cuantos miles, algo que empieza a ser un poco inmanejable como "pequeño secreto".
Sun ha reaccionado muy bien y aunque ha cancelado el programa, en vista del interés ha decidido hacer un prelanzamiento de J2SE 1.5, probablemente en diciembre, adelantando su previsión inicial entre dos y tres meses. Además ya no será necesario la petición por correo y el envío del FAX sino que el acceso será público
Eso es lo que yo llamo la buena noticia del día
(2003-11-20 21:03:03.0)
Permalink
Comentarios [0]
Wednesday November 19, 2003
J2SE 1.5 disponible en alfa
Neal M Gafter, un ingeniero de Sun que está trabajando en nuevas características de J2SE 1.5 como los tipos genéricos, publicó ayer día 18 de noviembre un mensaje en un foro de JavaLobby anunciando un programa para evaluar la versión actual en desarrollo de J2SE 1.5. He buscado un poco y también he visto un mensaje similar suyo en los foros de Java, evidentemente con bastante menos repercusión.
Para inscribirse sólo hay que mandar un correo electrónico a Ingrid.Yao@sun.com pidendo ser añadido al programa CAP y diciendo que vamos de parte de Neal Gafter. La contestación será un documento de privacidad que deberemos firmar y enviar por FAX, y a partir de ahí podemos acceder a una página web donde descargar la versión alfa más reciente de J2SE 1.5, que es actualizada cada dos semanas. Y ahora llega la mala noticia. Hoy, sólo un día después, Neal Gafter informaba en el mismo foro de que habían recibido el día anterior 350 peticiones, algo para lo que no estaban preparados, así que de momento no aceptan más peticiones mientras deciden que van a hacer con ellas a partir de ahora.
Aunque el programa de momento está en espera, es una buena noticia que Sun permita el acceso a la versión alfa en construcción. Significa un modelo de desarrollo más abierto en el que los usuarios podemos participar más y examinar exactemente qué novedades y en que forma están por venir. A mí por ejemplo me interesaría saber el estado del JSR 203, la nueva especificación conocida como NIO.2 que cambiará el acceso al sistema de ficheros en Java, entre otras cosas para permitir examinar toda la información nativa sobre los ficheros (tipo, atributos, permisos, etc), aunque lamentablemente todo apunta a que al final quedará pendiente para la 1.6. Lo que parece bastante seguro es que J2SE 1.5 traerá muchas otras novedades como un nuevo diseño visual del Look And Feel de Java, ¿estará ya en la versión alfa? ¿será bonito? ¿qué hay de las nuevas características del lenguaje? ¿genericos? ¿enumeraciones? ¿metadata? ¿autoboxing? ¿un printf?
En el peor de los casos tendremos que esperar a la beta. La última previsión que leí la situaba a finales de este año, así que con suerte quizás podamos tenerla a principios del que viene.
(2003-11-19 20:07:09.0)
Permalink
Comentarios [3]
Tuesday November 18, 2003
Muéstrame en otra tarea
Sun a actualizado su tutorial básico de introducción a Java,
The Java Tutorial, uno de los textos con los que más programadores dan sus primeros pasos en Java (yo mismo en su día). No sería una gran novedad si no fuese porque no es algo que suceda muy a menudo, la anterior modificación fue en mayo, mientras que en todo el año que ya finaliza el tutorial ha sufrido tres actualizaciones.
Eso da una idea de que las modificaciones no son simples cambios cosméticos o se limitan a corregir errores tipográficos. Concretamente las últimas modificaciones se han centrado en las lecciones de Swing, principalmente para que estén más al día frente a la versión 1.4, hasta con algún comentario sobre la futura 1.5.
Lo que más me ha llamado la atención es la nueva propuesta de Sun para mostrar las ventanas de Swing ya desde la propia tarea de despacho de eventos (event dispatching thread). Hasta ahora el ejemplo más simple y más típico para construir una ventana en Swing era de la forma:
public static void main(String[] args) {
JFrame frame = new JFrame();
...
frame.pack();
frame.setVisible(true)
}
Trabajar con Swing implica tener bastante cuidado en no modificar componentes visuales salvo desde la propia tarea de eventos, utilizando para ello cuando sea necesario los métodos invokeLater() e invokeAndWait() de la clase SwingUtilities. No seguir este consejo significa en el mejor de los casos que los componentes no se actualicen ni se dibujen correctamente, pero también puede provocar que la aplicación se llegue a quedar colgada en un temido deadlock. Sin embargo había una excepción notable, una vez llamada frame.pack() debía seguirse esa regla, pero la siguiente línea con frame.setVisible(true) se ejecutaba no desde la tarea de eventos sino desde la tarea que inició main().
Ahora Sun ha admitido que esa era la causa de que uno de sus ejemplos a veces se pudiese quedar colgado. La nueva recomendación consiste en que las ventanas se muestren ya por primera vez desde la tarea de eventos. El ejemplo anterior ahora necesitará de dos métodos y podría escribirse de la forma:
public static void showWindow() {
JFrame frame = new JFrame()
...
frame.pack();
frame.setVisible(true);
}
public static void main(String args[]) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
showWindow();
}
});
}
O sea, todo desde la tarea de eventos. No es así como nos habían enseñado hasta ahora, apuesto a que el 99% de las aplicaciones Swing necesitan ese pequeño cambio para seguir con las nuevas recomendaciones de Sun.
Si teneis curiosidad el capítulo del tutorial que comenta este cambio podeis leerlo aquí.
(2003-11-18 00:13:08.0)
Permalink
Comentarios [0]
Wednesday November 12, 2003
Licencia Apache 2.0
Recientemente la Fundación Apache ha anunciado que está revisando la licencia con la que distribuye sus proyectos. Este movimiento es importante porque se trata de una de las comunidades open source más importantess, y la más destacada sin duda cuando se habla de Java.
La versión actual de está licencia es la 1.1, proablemente sea una de las más breves, no llega a las 60 líneas, y difícilmente puede ser más generosa. Las restricciones son que no puedes cambiar el copyright ni la licencia del código fuente, cualquier programa que utilice un proyecto de Apache debe de informar brevemente de que incluye código desarrollado por ellos (en el manual del usuario o en la típica ventana que suele hablar en todas las aplicaciones con ese fin) y finalmente que no puedes llamar a lo que hagas también como "Apache". Todas las restricciones son muy aceptables y las concesiones son las restantes que se puedan imaginar: puedes tomar el código fuente, modificarlo como quieras y distribuirlo bajo tu propia licencia comercial. Por poder hasta puedes bajar un proyecto cualquiera de Apache, como Tomcat, cambiarle el nombre, decir que es algo tuyo (con la mención anterior de que incluye código de Apache) y venderlo sin código fuente como te de la gana. La licencia Apache es básicamente un regalo.
La nueva propuesta de licencia, que no es definitiva aún, bautizada com versión 2.0 sigue la misma línea que la anterior. En primer lugar es mucho más clara y precisa, eso se nota ya en las casi 190 líneas que ocupa (el triple) y su redactado en una terminología más legal. Apache pretende así confirmar los mismos derechos que en la versión anterior (el derecho a hacer casi lo que te de la gana conservado copyrights y respetando su nombre), matizando dos aspectos importantes que antes no eran mencionados: no te autoriza al uso de las marcas registradas que puedan aparecer mencionadas y sobre todo no te garantiza que el código no incumpla alguna patente. De esta manera pretenden protegerse de posibles litigios motivados por ese tema tan espinoso de las patentes del software. Otro problema de la versión anterior es que cada proyecto utilizaba una versión ligeramente modificada de la original, para incluir algunas menciones específicas, por lo que realmente no se podía hablar de una licencia apache, sino de toda una familia. Esta nueva versión se mejora para que todos estos proyectos utilicen realmente la misma licencia y definan sus menciones a parte (así es más claro para el usuario), ya tenemos por tanto la licencia Apache.
Es bueno ver como la fundación Apache retoca su licencia reafirmando al mismo tiempo su visión de open source. Ella es en parte responsable de su éxito, algo que de momento ya les ha permitido incluir su código en el JRE de Java, o que Sun los mire con buenos ojos y les facilite la certificación de sus proyectos.
(2003-11-12 15:11:57.0)
Permalink
Comentarios [0]
Friday November 07, 2003
Presentación de Gosling sobre Java
En febrero de 1995, James Gosling publicó un White Paper en el que presentaba un lenguaje llamado Java, creación por la que ha llegado a ser famoso. Principios de 1995, ha llovido mucho desde entonces, pero de la misma manera que ahora ya parece cosa de otro tiempo la peseta, para los que vivimos buena parte del día en el mundo Java a veces cuesta un poco recordar como era todo antes.
El texto original es cortito, describe de forma general algunas de las características más importantes de lo que era el Java de entonces, comenzando por el origen motivado por los problemas al desarrollar pequeños sistemas empotrados en C++. Al leerlo me he puesto a pensar en algunas de las cosas que me gustan de Java, hay otras que no tanto, pero eso queda para otro día.
Es sorprendente como con menos características puedes mejorar un lenguaje. También a mi en un primer momento me pareció una buena idea que C++ tuviese herencia múltiple, sobrecargas de operadores y conversiones automáticas, hasta descubres algo más tarde el caos que eso significa. Era un verdadero dolor de cabeza el uso y abuso de la sobrecarga de operadores junto a las múltiples combinaciones de conversiones implícitas. Eliminación de punteros, otro gran acierto. Los fallos por problemas con la gestión de la memoria en C++ no sólo son persistentes sino catastróficos y difíciles de depurar. No hay punteros, así que adiós a los constructores de copia, al paso de parámetros por referencia y valor (olvida que un método recibe los parámetros por referencia y ya te enterarás pero 1000 líneas de código más adelante) y a la memoria que se pierde misteriosamente (en el trabajo utilizamos un programa comercial en C++ que se olvida en el limbo un mega de memoria por hora).
Juntando otras ideas que individualmente no eran novedosas Gosling acuñó un lenguaje que sí lo era, gracias a características como por ejemplo la multiplataforma (máquina virtual), la seguridad, la multitarea integrada, un código realmente modular, y como no, la amplia librería estandard. Parece tan natural que si no hubiese sido Gosling, Java tendría que haber sido inventado otro.
Pero no podia ser todo perfecto ya en 1995, lo diga quien lo diga, incluyendo al propio Gosling, Java no era un lenguaje de un rendimiento "casi indistinguible de código nativo en C o C++". La primera versión de Java era lenta, lenta, lenta, y aunque la historia ya ha ido corrigiendo ese error, la mala prensa le acompañará un buen tiempo. Y otras ahora provocan una sonrisa, como que la firma de paquetes no estaba lista en la versión 0.2 (qué miedo da ese número), o que AWT aún no estaba implementado para Windows.
¡Qué tiempos!
(2003-11-07 00:26:58.0)
Permalink
Comentarios [0]
Wednesday October 22, 2003
Dependencias, no gracias
El infierno de las DLL (DLL Hell), es una de las peores
situaciones en las que se puede encontrar un usuario de Windows. Viene
provocado cuando los programadores han separado parte de su aplicación
en librerías dinámicas que esperan compartir con el resto de
aplicaciones. De esta forma si otra aplicación utiliza la misma librería
dinámica ya no hace falta que la instale, la misma sirve para las dos y
así se ahorra el espacio de almacenarla por duplicado en el disco duro.
Por duplicado, triplicado o las veces que pueda ser compartida por más
programas.
La teoría parecía buena. Pero,
desgracidamente no todo es tan sencillo. Una aplicación puede requerir
una versión más moderna de una librería dinámica que ya está instalada,
así que substituye la versión anterior por la más nueva, que será la
única compartida. El problema surge porque a alguien se le ocurrió
introducir alguna incompatibilidad de la versión nueva respecto a la
versión anterior (a veces esto puede ser difícil de evitar), y el
programa anterior hace buuummm cuando se encuentra con la nueva
librería dinámica, y deja de funcionar. Instalas un programa y descubres
que misteriosamente otro se cuelga a partir de entonces.
No es un
problema de Windows. En Linux se puede decir lo mismo, por ejemplo el
infierno de los RPMs. Los paquetes de Linux están llenos de dependencias
(normalmente también librerías dinámicas) que son necesarias instalar
primero, pero de nuevo cuando una de esas librerías dinámicas tiene
alguna incompatibilidad con versiones futuras descubres que otros
programas dejan de funcionar sin una explicación aparente.
Hace poco quise instalar gnucash,
un programa de gestión de gastos para Linux, sobre un Mandrake 9.1.
Aunque esta versión de Mandrake ya viene con gnucash 1.8.1,
se trata de una versión antigua de hace ocho meses cuando ya está
disponible la versión 1.8.7 con bastante correciones sobre la anterior.
Mi idea era actualizarme, y para ello los desarrolladores de gnucash
ya me proporcionan una versión empaquetada para Mandrake, hasta aquí todo muy
sencillo. Pero aunque gnucash sólo tiene un puñado de
dependencias, si las instalaba a su vez estas dependencias (nuevos
paquetes) me obligaban a actualizar a una versión más moderna otros
paquetes afectados, que de nuevo provocaban otras actualizaciones en
otros paquetes. Conclusión: actualizar de versión significa instalar
102 paquetes por un total de 275 megas. Para empeorarlo todo aún
más parte de los paquetes sólo se encontraban en la distribución de
Mandrake experimental (Cooker), por ser algunos demasiado nuevos.
Parémonos a pensar. Actualizar de versión una aplicación de escritorio
que en apariencia es sencilla y considerada estable por sus creadores,
significaba instalar más de 100 paquetes causados por dependencias,
algunos de los cuales estaban aún en pruebas. Como tenía que instalar de
nuevo Mandrake por otros motivos no perdía nada en probar a ver que
pasaba, así salía de dudas sobre si funcionaría todo bien. Evidentemente
después de todas esas actualizaciones algunas aplicaciones ya no
funcionaban como antes. Eso es lo que yo llamo un ejemplo práctico del
infierno RPM.
Si eres un programador, de todo esto puedes extraer
algunas conclusiones para evitarte problemas a tí y a tus usuarios:
- No compartes tus librerías por ahorrarte un puñado de megas de disco duro. Si sólo tú usas tus dependencias podrás actualizarlas cuando quieras sin que eso tenga incidencias sobre otras aplicaciones.
- Piensa bien si necesitas todas esas librerías. Si utilizas un buen número de librerías, aunque no las compartas con el resto del mundo, puedes descubrir que varias de estas librerías a su vez dependen de una misma librería pero sobre versiones diferentes que pueden no ser del todo compatibles. Según qué versión de una librería coloques otras de las que ya tienes puede no funcionar como esperas. Este problema aparecerá más a menudo si se olvida el tercer punto.
- Si construyes una librería en vez de una aplicación, añade todas las características nuevas que quieras en las nuevas versiones, pero piénsatelo dos veces antes de introducir incompatibilidades con versiones anteriores. Mejor tres veces.
Y ya hay suficiente por hoy sobre dependecias.
Disculpas: gnucash es una aplicación gratuita (sólo para Linux) muy recomendable para todo aquel que quiera llevar un control de sus propios gastos domésticos. Pocos han hecho tanto por Java como la gente de Jakarta, el proyecto commons es una de las pocas cosas que no me gusta como han gestionado.
(2003-10-22 00:08:46.0)
Permalink
Comentarios [1]
