Buscar
Social
Ofertas laborales ES
viernes
abr182008

Reflexionando sobre el gordito de Java

Opinion de un programador....

Todos sabemos el crecimiento que ha tenido Java en los ultimos años, ha crecido tanto en funcionalidades, caracteristicas, mejoras de todo tipo y tamaño de disco. El tamaño del JRE es algo que se ha discutido mucho y no quiero retomar ese tema. SUN esta encontrando mecanismos para mejorarlo, el Pack2000 o el consumer JRE son algunos ejemplos. A mi realmente no me molesta el que Java crezca en tamaño, pues java al ser un lenguaje de proposito general necesita una vasta libreria para poder defenderse a la mayoria de los problemas. Lo que si me ha puesto a pensar es si realmente esas librerias estan de adorno en el JRE o tiene algun proposito. Les pongo el ejemplo mas tipico:

Un programador a empezado a tener sus propias alas y quiere explorar algunos frameworks porque sabe que ayudan mucho al desarrollo de aplicaciones. Decide primero por aprender Hibernate+Spring (o cualquier otro), se baja las distribuciones, los manuales, y los aprende a usar. Pero hay algo que llama su atencion, las dependencias de esos frameworks, nota que Spring y Hibernate necesitan ademas de sus jars (hibernate.jar y spring.jar) muchas dependencias, las famasosas Common-beanutils, common-io, common-collections, common-xxx y ademas dom4j, log4j, xerces, xml, cgbxx. Y nota que muchos otros frameworks utilizan las mismas dependencias. Investigando un poco se da cuenta de que son librerias para manejar XML, colecciones, archivos, logs, etc,etc Y aqui sale la pregunta del millon:

¿Acaso java no tiene ya soporte para tooodas esas cosas, o es que tienen mal rendimiento, o mala implementacion que es necesario otras que "hacen lo mismo" pero que estan hechas por terceros??

Lo ideal seria un framework un jar. Salvo algunos otros jar especificos y directamente relacionados con el framework. ¿Se han dado cuenta que cuando hacen una aplicacion web por ejemplo, el tamaño de esta es minimo de 20mb si utilizan Spring + Hibernate??? los jar que uno fabrica no llegan ni a los 200k si tienes todo modular, o maximo 500k si tienes todo en solo jar, practicamente toca distribuir otra "JRE" junto con esos pequeños archivos.

SUN deberia haber notado todo esto hace años, y creo que no ha hecho practicamente nada, corrijanme si me equivoco. Deberian reemplazar las implementaciones de sus API con estas famosas commons y asi tener por cada framework, un jar.

¿Seria posible que todas las personas que se hayan dado cuenta de esto podamos hacer suficiente bulla como para cambiar el futuro de java?? ¿Save the cheerleader, save the world??

Saludos a todos

viernes
abr182008

Netbeans 6.1 RC2

Acaba de publicarse la RC2 (Release Candidate 2) de entorno Netbeans versión 6.1.

No hace poco que salió la 6.0 y la 6.01 pero al parecer ha sido algo inestable para unos cuantos desarrolladores (me incluyo). Aprovecho el anuncio para solicitar una encuensta de uso de este gran IDE que va creciendo en posibilidades: PHP, Ruby On Rails, JavaScript , JSF y un largo etc. 

Lo podeís descargar desde http://download.netbeans.org/netbeans/6.1/rc/ 

jueves
abr172008

Los ganadores del Netbeans Innovators Grant

Finalmente han sido publicados los proyectos ganadores del Netbeans Innovators Grant
que como ya anunciamos premia los proyectos open source que se desarrollen para Netbeans.

La lista de ganadores es la siguiente:

Proyectos grandes

  • CashForward (Bill Snyder)
  • Cube°n (Anuradha Gunasekara)
  • JavaSpaces (Magdalena Dukielska)
  • IvyBeans (Laurent Forêt)
  • NB Project (Sergey Sheypak)
  • NB-XUL (Aditya Kumar Sharma)
  • NetBeans Spot/Sun SPOT Plugin
  • NbPython (Allan Davis)
  • Scala Support (Caoyuan Deng)
  • Visual JavaFX (Adam Kędziora)

Proyectos pequeños

  • CoffeeDregs (Kees Huizing)
  • JSpree (ManiKanta G)
  • Netbeans Update Service (Mark Ashworth)
  • MONOH (Carlos Oliveira)
  • Numbered Bookmarks (M.A.S. Jayasundara)
  • PDFViewer (Steve Tzou)
  • PL/SQL Editor (Alexandre Soumbatov)
  • Project Darkstar Tools and Mobility Support (Karel Herink)
  • Regular Expressions Module (Angad Singh)
  • Resource Bundle Editor (Denis Stepanov)

Como se presentaron varios proyectos con el mismo nombre se publica el nombre del ganador entre paréntesis para diferenciarlos. En breve se publicará la lista con una pequeña descripción de cada proyecto en la página web de Netbeans.

Por los nombres de los ganadores no parece haber ningún hispano en la final... la próxima vez será ;-)

miércoles
abr162008

Mejoras y correcciones en DynamicJasper 2.0.8

La  nueva versión de DynamicJasper (2.0.8), la librería que permite realizar reportes dinámicos con JasperReports fue liberada.

Para los que no conocen la librería, en estos dos posts se cuenta para que sirve.

1.       /contenidos/es/agrega_dinamismo_a_los_reportes_en_jasperreports_con_dynamicjasper_11/

2.       /contenidos.item.action?id=8099424&menuId=ANNOUNCEMENTS

 

Las mejoras y cambios a partir de la versión 2.0.1 (la ultima informada en este sitio) son

·         A partir de la versión 2.0.7 DynamicJasper está en el repositorio central de ibiblio: http://mirrors.ibiblio.org/pub/mirrors/maven2/ar/com/fdvs/DynamicJasper/
Usuarios de maven2 pueden agregarla la dependencia directamente al pom.xml

·         Se pueden tener columnas con código de barra (ej.)

·         Se pueden tener columnas con imágenes (ej.)

·         Se puede embeber una query en el reporte (como con JasperReports). Para los parámetros referenciados en la query, basta con pasar un mapa con sus valores, ¡DynamicJasper declarará los parámetros! (ej., ej. 2)

·         Exportar a un diseño dinámico a jrxml. Esta característica te permite generar un draft muy rápido del reporte para luego darle los retoques necesarios en iReport. ¡En este caso DynamicJasper es utilizada como herramienta para generar templates! (ej.)

·         Se pueden embeber las fuentes (ttf, etc.) en los PDF. Ideal para internacionalización. (ej.)

·         Registración automática de parámetros: Todo el contenido del mapa con los parámetros, serán registrados automáticamente (se usa la key del mapa como nombre del parámetro)

·         Soporte para orígenes de datos XML (ej.)

·         Definir comportamiento cuando no se encuentra un recurso (para las missing keys) (ej.)

·         Definir comportamiento cundo el origen de datos está vacío. Aquí podemos mostrar un texto en particular en el reporte cuando este está vacío (ej.)

·         Los sub reportes pueden compartir parámetros con el reporte padre. (ej.)

·         Los sub reportes pueden empezar en una nueva línea. (ej.)

·         Controlar que la banda de detalle no se “parta en 2” (split) cuando no alcanza el espacio. (ej.)

·         Mejora a la integración con WebWorks, se puede especificar una propiedad del Action para ser usada como mapa de parámetros.

Como siempre nos encontramos en sourceforge: http://dynamicjasper.sourceforge.net

Saludos!

Dj

martes
abr152008

SpringSecurity (antes Acegi Security) 2.0

Después de 2 años de desarrollo, SpringSource ha terminado la nueva versión de Acegi Security, que implica la integración completa con Spring y un cambio de nombre: SpringSecurity.

Para los que no lo conocéis, SpringSecurity es un framework no intrusivo para implementar servicios de autenticación y autorización a recursos java que se integra a los estándares de la industria. Permite controlar la seguridad desde una granularidad muy fina como el acceso a determinado método o a granularidad muy alta como el acceso a toda una aplicación.

En esta nueva versión ha habido un refactoring del código y actualización de las dependencias, además incluye nuevas características entre las que destacan:

  • Soporte a OpenId
  • Soporte completo a autorización a nivel de métodos en superclases, genéricos, bridges, clases e interfaces.
  • Autorización web basada en URIs restful
  • Mejoras al tutorial de ejemplo