<body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d5078236\x26blogName\x3dSoloJava+Noticias\x26publishMode\x3dPUBLISH_MODE_BLOGSPOT\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttp://solojava.blogspot.com/search\x26blogLocale\x3des_ES\x26v\x3d2\x26homepageUrl\x3dhttp://solojava.blogspot.com/\x26vt\x3d2241489689991862587', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>

SoloJava Noticias

Lo mejor del mundo IT con o sin Java

A SUN no le gusta JDocs

30.8.04
Al parecer SUN no ha visto con buenos ojos la salida al aire de JDocs. En javaHispano podemos leer que:

"... Según informa Rick Ross, Sun les ha expresado que los Javadoc de las APIs de Sun deben ser accedidas única y exclusivamente desde sun.com. El temor de Sun venía dado por la posibilidad de que JDocs.com no mantuviese actualizadas las versiones de las API.
Rick Ross reconoce el error de no haber pedido permiso y por haber creído inocentemente que Sun les ayudaría a ofrecer un mejor servicio a la comunidad Java. También ha destacado que en la trayectoria de Javalobby nunca han tenido interés en fragmentar la plataforma Java™, sino todo lo contrario.
"

Algunos comentarios señalan que la verdadera preocupación de SUN radica en perder el protagonismo dentro del mundo java.

Más información y comentarios en : theserverside, javaHispano.

Javadocs a la mano

11.8.04
La gente de Javalobby ha puesto a la disposición de la comunidad de desarrolladores Java un sitio web llamado jdocs donde se encuentra la documentación en formato Javadoc de muchos librerías. Entre las ventajas de este servicio se encuentra la capacidad de realizar búsquedas y de añadir comentarios a la documentación para la ayuda de todos los usuarios

Maven: There's a new Sheriff in town

9.8.04
Built by mavenA pesar de que Ant es el estándar de facto como build tool para Java. "There's a new Sheriff in town".
Y es que rápidamente Maven (el cual está basado en Ant) se ha convertido en el tool por excelencia para administración y comprensión de proyectos Java. Casi todos los proyectos open-source Java (de cierto renombre) están siendo "manejados" en la actualidad con Maven.

Maven está basado en el concepto de un project object model (POM). Todos los artefactos son producidos y controlados a través del POM. Los artefactos más comunes incluyen: builds, documentación, métricas de los fuentes, lista de dependencias, reportes de unit tests y source cross-references entre otros.

Un concepto interesante que incorpora Maven es el uso de un repositorio central para los JARs. Maven provee un mecanismo que permite descargar automáticamente cualquier dependencia necesaria por el proyecto. Esto permite llevar un mejor control de versiones para las dependencias, asi como la reusabilidad de los JARs. Por defecto Maven viene configurado para usar el repositorio central definido en Ibiblio, sin embargo es fácilmente configurable para usar un repositorio propio, o mejor aun, una jerarquía de repositorios (si la dependencia no la consigue en mi repositorio central, busca en Ibiblio)

Nosotros lo hemos venido usando por casi dos años para nuestros proyectos, y realmente nos ha ayudado mucho en la automatización de los artefactos que elaboramos.

La versión 1.0 de Maven fue liberada el 13 de Julio.

Les recomiendo darle una probada ;-)

Java en una servilleta

Napkin Look & Feel te permite mostrar tu aplicación Java™ como si estuviera hecha en una servilleta, con la idea de que tenga una apariencia informal. También lo puedes usar para demostrar que el proyecto no ha sido terminado.



Se puede leer un comentario en Notes on a napkin.

Sun está defendiendo la marca registrada Java™

7.8.04
Ultimamente he estado observando que Sun, los creadores y dueños de la marca Java™, están siendo un poco más recelosos con el uso de esta por terceros, aunque hay momentos en que considero se sobrepasan, en el caso de MerchantSpace, que venden su producto como "Java e-Commerce Software" creo que están haciendo lo correcto, tienen hasta un número gratuito 800.942.Java, lo que me parece un uso inapropiado de la marca de otra empresa.

Si quieren evitarse problemas, nunca usen el termino Java™ en el nombre de sus productos y recuerden siempre usar el símbolo ™ cuando especifican que este requiere o está hecho en Java™ y no usen los logos hasta que hayan solicitado el permiso necesario. Más detalles los pueden encontrar en las Normas para el uso de las marcas de Sun.

¿Que opinan ustedes?

Jikes: Javac en Esteroides

4.8.04
Desde hace algún tiempo uso el compilador Jikes de IBM en vez del clásico Javac ¿Por qué? Porque es rápido. En nuestras pruebas informales en diferentes equipos Jikes consistentemente compilaba el mismo código que Javac en la mitad del tiempo. Adicionalmente:

  • El código es abierto (Open source) certificado por OSI (Open Source Initiative).
  • La implementación respeta por completo la especificación de Java como lenguaje, así como la de la Máquina Virtual de Java (JVM). De hecho, en algunos casos es tan estricta que es mayor que la del propio Javac, es decir: Es posible que tu código compile bien en Javac y que Jikes te ponga en los palitos.
  • Los mensajes tienden a contener mucha más información que los generados por Javac, llegando al punto de sugerir métodos candidatos cuando uno se pela con un signature.
Al principio tuvimos una cierta desconfianza sobre el hecho de usar un compilador que no fuera el "venerable" Javac, sin embargo en ningún momento hemos tenido ningún problema con códigos en desarrollo o en producción en las instalacioens de nuestros clientes.

La versión más reciente es la 1.21, que ya incluye soporte beta para algunas de las nuevas características de Java 1.5.

Red Hat Application Server

3.8.04

Red Hat ofrece un servidor de aplicaciones Java™ basado en Jonas y Tomcat, 100% opensource y disponible en formato RPM para i386, ia64 y PPC. Tambien incluye Eclipse 3.0 y plugins adicionales compilados nativamente con GCJ.

Tengo planeado hacerle una pruebas en unos días y compartiré con ustedes mis experiencias desde la perspectiva de un usuario de JBoss.