EasyWay, librería para creación de juegos

EasyWay es una librería para crear juegos 2D desde Java. Se distribuye bajo una licencia libre, se basa en OpenGL (aunque sólo la usa para renderizar escenarios en dos dimensiones) y soporta tanto Windows como Linux y Mac. En el caso de Windows se soporta jugar a pantalla completa.



Sus creadores afirman que hace falta un número de líneas muy pequeño para crear juegos apoyandose en la librería. Aquí tenéis varios juegos de ejemplo; se pueden ejecutar a través de Java Webstart y es posible descargar el código fuente de varios de ellos.

JAJAH: VoIP desde el móvil con J2ME

La compañía americana JAJAH ha lanzado un sistema de telefonía de voz sobre IP disponible en teléfonos móviles equipados con el S.O. Symbian o con Java y que permitirá a sus usarios realizar llamadas internacionales como si fueran llamadas locales.



El software está disponible para descargar al pc o instalarlo directamente en el teléfono via O.T.A.



Otro movimiento más que confirma la gran actividad que hay últimamente en el mercado VoIP y que esta vez viene de la mano de Java.



Reseña de la noticia en el diario El Mundo

Integrando Tomcat 5.5 y Apache 2.2

Feli en tres entradas diferentes de su weblog nos explica cómo integrar Tomcat 5.5 y Apache 2.2 para que Apache sirva el contenido estático y redirija las peticiones de contenido dinámico a Tomcat. También explica cómo realizar un balance de carga entre varias instancias de Tomcat y todo en español :).



Tomcat 5.5 + Apache 2.2 (I)

Tomcat 5.5 + Apache 2.2 (II)

Tomcat 5.5 + Apache 2.2 (III)

JSR 306: hacia una nueva versión del JCP

Recientemente se ha propuesto el JSR 306, "Towards a New Version of the JCP", que pretende definir cómo funcionará la siguiente versión del Java Community Process, el organismo que controla y dirige la polución de toda la plataforma Java. Los principales cambios que se proponen son:

• Incrementar la transparencia sobre el funcionamiento de los grupos de expertos de los JSR y como los desarrolladores pueden participar en ellos.





• Influir sobre el tiempo que le lleva al grupo de expertos alcanzar hitos a lo largo del JSR





• Permitir implementaciones no Java de los JSRs.





• Definir cómo los estándares creados por este organismo podrán colaborar con otros organismos que creen estándares.





• Proporcionar un método para incorporar tecnologías ya existentes al JCP.

En general los cambios van más en la línea de optimizar lo ya existente que en la línea de proponer cambios radicales. Si estás interesado en conocer más acerca del funcionamiento del Java Community Process puedes leerte esto.

Domain Specific Languages ¿buena o mala idea?

Los Domain Specific Languages (DSL) son lenguaje de programación construidos por los propios programadores "a medida" para resolver un determinado problema, de ahí su nombre: son un lenguaje específico para un determinado dominio. Dentro de la plataforma Java, por lo de ahora, no son demasiado populares ya que no sería fácil construir uno. Pero en los lenguajes de programación dinámicos, como Ruby, que dan soporte a la construcción de extensiones de lenguaje y, por tanto, a DSLs sí lo son.



En la actualidad existe bastante controversia sobre si "son buenos o son malos los DSLs". En InfoQ ( un portal casi recién creado de prensa tecnológica que está llamado a convertirse en uno de los grandes por la gran cantidad de colaboraciones y apoyos que tiene, entre ellos el de Floyd Marinescu, antiguo editor de TSS) han publicado un artículo recopilación donde se exponen varios puntos de vista sobre este tema (artículo creado por Marinescu, por cierto).



Joel Spolsky ha empleado un DSL para solucionar problemas de despliegue y mantenimiento de aplicaciones. Su proyecto fue un éxito y, por tanto, está a favor de ellos. Mark Dominus afirma que los patrones de diseño son una muestra de deficiencias en un lenguaje . Por tanto, debemos buscar formas de mejorar los lenguajes y los DSLs son el camino adecuado. Ralph Johnson, uno de los autores del libro de patrones GoF, no está de acuerdo con este punto de vista.



Buko Obele está en contra de los DSLs porque no permiten controlar adecuadamente el cambio a lo largo del tiempo. El ha desarrollado varios de estos lenguajes y, cuando los requerimientos del sistema cambian, se ha visto obligado a cambiar el lenguaje (cosa que tiene bastante sentido: si has diseñado un lenguaje muy adaptado a un problema y el problema cambia el lenguaje deja de ser adecuado). Obele se encontró con que cada vez perdía más tiempo reescribiendo estos lenguajes.



Otro problema que yo les veo es el mantenimiento al largo tiempo: si has creado tu propio lenguaje nadie lo conoce y cualquier persona que entre en el proyecto tendrá que aprenderlo. Por otro lado, el lenguaje debe documentarse exhaustivamente o se corre el riesgo de que si todos los que lo conocen abandonan la empresa nadie sabe cómo trabajar con él. Generar documentación también consume tiempo.



También pueden tener un efecto pedagógico negativo: alguien que empieza a programar por primera vez en Ruby en un proyecto en el que se emplea un DSL al final del proyecto no sabrá Ruby ya que no será capaz de distinguir qué es parte de Ruby y qué era parte de lenguaje de la compañía.



Aunque ahora a lo mejor nos parece que en la plataforma Java esto ni nos viene y nos va, con la gran cantidad de lenguajes dinámicos que están surgiendo dentro de la propia plataforma esto pronto será un tema de discusión. ¿Alguien ha construido/empleado alguna vez un DSL? ¿cuál es tu opinión sobre ellos?