OpenBaseMovil: Framework JavaME (J2ME) con base de datos relacional, scripting y más vistas en XML

OpenBaseMovil es un framework para la creación de aplicaciones móviles J2ME (JavaMe, Java Micro Edition) de forma sencilla y rápida. Publicado bajo licencia dual GPL y comercial.Publicado en Sourceforge

Algunas de sus principales características:

• un potente motor de base de datos relacional, que puede alojar cientos de miles de datos en bases de datos de muchos megabytes.
• un motor de script, con el que puedes extender y crear aplicaciones fácilmente, y en un futuro cercano ejecutar esas mismas aplicaciones con Android o Windows Mobile.
• un lenguaje declarativo para definir las vistas de la aplicación, con un simple fichero XML puedes generar todas tus vistas, y estas saben conectar con la base de datos y el script: con cinco líneas de código puedes navegar los resultados de una consulta.
• y mucho más, como gestión de tareas, ficheros sobre RecordSets con acceso aleatorio, soporte de coma flotante, internacionalización, conexión con gps, impresoras, lectores de códigos de barras...

Está formada por 3 librerías:

1. OpenBaseMovil-core

2. OpenBaseMovil-db

3. OpenBaseMovil-script

Las cuales pueden usarse de manera independiente. openbasemovil-core contiene entre algunas cosas;Administrador de eventos,Threads,Loggins(debug),Serialización,MVC,Internalización,conpresión , manejo de datos encriptados (CRC,Symmetric encryption with Blowfish,Message digest with MD5).

¿Que os parece éste Framework ,alguno de UDs. lo ha usado? .

Parece una muy buena propuesta ,a su par TagsME ,pero con licencia GPL .

¿Que creen ?

JSF 2.0 Early Draft Disponible

Las metas de la especificación 314 para JSF 2.0 se dividen en cuatro áreas importantes:

La primer de estas cuatro áreas se concentra en el desarrollo fácil de componentes JSF:

• Desarrollo de componentes mediante agregación sin utilización de codificación Java.
• Cero configuración No faces-config.xml, no web.xml.
• Utilización de anotaciones para componentes, Manage Beans entre otros.

La segunda en Nuevas características:

• Expandir el ciclo de vida del request para que tenga conciencia de Ajax
• Provide a mechanism to easily access persistent store (En ingles por que se entiende un poco mejor).
• Agregaciones estratégicas al RenderKit estándar de HTML: Date Picker, Tree, Tab View, File Upload components.

La tercera en el Desempeño y Escalabilidad del Runtime:

• Salvar y restaurar deltas de las páginas en ves de restaurar el estado de la vista completamente cada ves que se requiere.
• Streamline el proceso de renderizado vía cache si es posible.
• Entre otros

Y la cuarta en la Adopción:

• Mejorar la especificación de UIComponent para permitir un incremento en la interoperabilidad de las librerías de UIComponents de diferentes vendedores.
• Permitir a los recursos de las  aplicaciones JSF ser accedidos vía REST.
• "Skinning", o "Themeing" de  componentes.
• Entre otros

Como siempre incentivar a la comunidad a hacer feedback de esta JSR para mejorar el estándar de componentes para el desarrollo de aplicaciones WEB.  Y para una información más completa.

Pagina JSR

Pagina Download

Y tratar de dar mucho feedback, ya que se ve que esta ves si se esta haciendo fácil el desarrollo de componentes JSF, algo que hacia mucha falta pero que necesita mucho feedback. Ya que desarrollar una aplicación JSF no es tan fácil como se quiere y si se puede hacer esto un poco más llevadero  tratar de aportar nuestro granito de arena.

Soporte del locale de euskera en Java

Hace ya unos meses que aprovechando la nueva capacidad de extender Java con Locales, cree una extensión SPI para incorporar el Locale de Euskera (eu-ES) en Java.

El jar se puede descargar de la siguiente dirección:

http://java-basque-locale.googlecode.com

 El código está disponible ahí mismo, y se puede descargar con un cliente SVN, por lo que quien quiera puede usarlo de base para crear una extensión para Gallego o Asturiano.

Exadel Flamingo: RAD con Flex y JavaFX

Exadel ha publicado su framework Flamingo, que permite el desarrollo rápido de aplicaciones RIA usando JBoss Seam (usando JPA para persistencia) o Spring (usando Hibernate para persistencia) en el backend y Flex o JavaFX en el cliente. El framework se basa en maven para, de forma similar a Trails o AppFuse, crear el esqueleto de la aplicación en base a tus requisitos. El proyecto creado es un proyecto maven típico por lo que puede abrirse con Eclipse o Netbeans o Idea.

Flamingo te ayuda a integrar estas tecnologías de forma transparente y te configura el entorno para que tú solamente te tengas que preocupar por programar la lógica del negocio de tus aplicaciones. Flamingo actúa como el pegamento para comunicar el backend con tu cliente RIA (de forma similar a BlazeDS para Flex) y proporciona servicios de autenticación y validación, además de brindar componentes visuales para utiilzar en tus clientes.

Flamingo es una herramienta gratuita y Exadel obtiene dinero vendiendo soporte, por cierto ahroa mismo hay una oferta de soporte gratis por 30 días. Los de Exadel han portado el famoso demo de reservación de hotel de Seam a Flamingo, tanto en versión Flex como JavaFX, puedes jugar con él en la página del demo.

Con el auge de tecnologías RIA, últimamente han ido apareciendo herramientas para desarrollo RAD con ellas, otras opciones incluyen un plugin para generar interfaces Flex para Grails y este framework para integrar Flex con Ruby on Rails. Flamingo resulta una opción interesante al estar enfocada al mundo JEE, además de contar con el respaldo y soporte de una empresa como Exadel que se ha ganado un lugar en el mercado gracias la calidad de sus herramientas para Eclipse.

Generics podría ser el final de Java, Jonathan Locke (fundador de Wicket)

Jonathan Locke, el fundador del popular framework web Java Wicket, ha publicado una entrada en su weblog comentando los problemas que generics está trayendo a Wicket. Los desarrolladores y los usuarios no se ponen de acuerdo en si tiene sentido aplicar generics a ciertas partes del API del framework y, en caso afirmativo, como aplicarlas.

Jonhatan también afirma que en varios trabajos anteriores ha visto problemas similares con generics y ha visto como gente tremendamente inteligente ha tenido muchos quebraderos de cabeza intentando aplicar generics para luego darse cuenta que no era posible y tener que deshacer el trabajo hecho.

Jonhatan afirma que el principal problema que tiene Java en la actualidad son las generics y que es necesario que los programadores puedan escribir código con generics, y no sólo usarlo (es de consenso que usar generics, por ejemplo el framework de colecciones, es sencillo y es una ventaja para el programador; lo complicado es escribir tu propio código genérico, en especial si necesitas usar wildcards). Jonhatan afirma que ésto es mucho más importante que otros temas más populares en la actualidad como son las closures.

Personalmente, estoy de acuerdo en que escribir un API Java empleando generics es complicado. Aunque en mi experiencia (bastante particular, el dominio del procesado de señal) el factor más limitante es el hecho de que los generics en Java sean un mero azúcar sintáctico para el compilador y se eliminen en tiempo de ejecución. Tras varios días devanandome los sesos sobre cómo hacer genérico un framework de procesado de señal en el que trabajo llegué a la conclusión de que no me merecía la pena porque nunca conseguiría que los arrays donde se almacena la señal fuesen genéricos, y ahí es donde estaría la principal ventaja de hacer genérico mi framework. Así que tuve que abandonar la idea.

Siendo honestos, el abandonar la idea por un lado me decepcionó (hubiera sido muy útil para el usuario del framework). Por otro lado, me sentí aliviado porque se me estaban poniendo los pelos de punta con lo que iba a tener que hacer para aplicar generics...

¿Cuál es vuestra experiencia particular con generics? ¿Cuantos habéis usado generics en vuestro propio código? ¿Creéis que efectivamente es uno de los principales problemas que tiene Java en la actualidad?