Los plugins que encontré para groovy y para grails me resultaban más bien escasos o incluso no se dejaban instalar. Al final conseguí una sintaxis coloreada de groovy, con el compilado automático deshabilitado y sin ningún tipo de integración con Grails. No se puede arrancar la aplicación Grails ni, por supuesto, depurarla.

Siguiendo con google, por las páginas de grails y asociadas, acabas llegando a que hay un IDE basado en eclipse y con muy buena integración con groovy/grails. Este IDE es STS (SpringSource Tool Suite). Pero yendo a la página correspondiente, resulta que para bajarlo me piden el nombre, el apellido, el teléfono, la empresa, mi puesto en la empresa, el sueldo, el tercer apellido de mis abuelos (de todos) y la partida de nacimiento, así que pasé totalmente de bajarlo.

También vi por internet que Netbeans soporta bien groovy y grails sin necesidad de plugins, viene ya integrado. Me lo bajé y lo probé. Mi primera impresión fue muy buena. Hace años, cuando usaba/probé netbeans, recuerdo que tenía un arranque muy lento y pesado. La nueva versión parece que arranca en un tiempo prudente. La integración con grails bien, se pueden arrancar las aplicaciones grails (no he probado a depurar, pero supongo que sí). Me bastó con abrir el proyecto grails ya creado con grails create-app para ponerme en marcha. Sin embargo, sigo acostumbrado a eclipse y hay cosas de netbeans que no me gustan, más por gusto personal que por defectos del IDE.

Así que me armé de valor, fuí a la página de STS, puse el nombre de mi compañero de mesa en el curro, su dirección, su teléfono, su tarjeta de crédito, le engañé para que me pasara su certificado de penales que también piden y me bajé el STS. Luego, Aitortxu en twitter me comenta de una página en la que se puede uno bajar STS sin descubrirle a nadie sus intimidades.

El STS una maravilla. Es un eclipse, por lo que ya estoy acostumbrado a él, y viene "tuneado" para hacer aplicaciones web, aspectj, una cosa que se llama roo (una especie de grails, pero puramente java), jpa, etc, etc. Grails y Groovy no vienen por defecto, pero hay una pestaña llamada "dashboard" en la que con un par de clicks nos baja los plugins correspondientes y funciona todo bien.

La sintaxis coloreada, ejecución, autocompletar y demás todo bien. Viene todo lo necesario para trabajar a gusto, aunque tanto plugin hacen el arranque y la instalación un poco pesados. El autocompletar como todo autocompletar en lenguajes no tipados: si sabemos de qué tipo es la variable, bien, si no lo sabemos, imposible. Así que me quedo definitivamente con STS. Aparte, me he puesto a jugar un poco con los proyectos JPA (viene con EclipseLink) y aun a pesar de no tener ni idea, lo que he intentado me ha salido a la primera o casi, lo que quiere decir que es más o menos intuitivo y robusto ante torpes como yo.

Un compañero me mostró una característica interesante de eclipse. Es posible configurarlo para que cada vez que demos "salvar" a uno de nuestros ficheros java, realice en él algunas acciones que le indiquemos: arreglar los imports, darle formato al código, poner las llaves en todos los bloques if, while, for aunque no sean necesarios, eliminar variables locales o privadas que no se usan, etc, etc.

A todo esto se accede desde "window" -> "preferences" -> "java" -> "editor" -> "save actions" (en eclipse versión 3.4.1). Ahí nos muestra una ventana con un montón de acciones que se pueden hacer, junto con un ejemplo de texto java para que veamos cómo afecta.

Hace poco, comenté que he instalado Sonar y viendo algunas de las métricas que tiene en cuenta, veo que muchas pueden cumplirse sin dificultad símplemente configurando eclipse con estas opciones. Por ejemplo, Sonar considera incorrecto (warning) no poner llaves en un if, else o bucle que sólo tenga una línea. Poniendo esta opcion, no solo nuestros nuevos ficheros cumplirán esta métrica, sino que los viejos, según los vayams tocando para lo que sea, se iran arreglando solos.

Un pequeño detalle, ojo con lo de eliminar automáticamente los atributos privados y variable locales no usadas. Yo lo he puesto y según voy escribiendo código, tengo la costumbre de salvar con cierta frecuencia. Si escribo una variable local que voy a usar más adelante, pero todavía no la he usado y le doy a salvar, me la borra, por lo que tengo que volver a escribirla o darle al Ctrl-Z.

Más detalles en Accion adicionales al salvar un fichero con eclipse.

Sin embargo, sí me ha salido la necesidad. Nuestras aplicaciones de escritorio como tales son realmente sólo interface de usuario, mucho java Swing sobre PCs con Windows. Pero esa, aunque es la parte más labiorosa y la que más líneas de código lleva y la que es más difícil de hacer bien, es lo que la mayoría de la gente considera la parte "tonta" de la aplicación. La parte "de verdad" de la aplicación es una ejecutable java que hace de servidor, que corre en una estación de trabajo Sun que ni siquiera tiene monitor ni teclado. El código de ese ejecutable se desarrolla y prueba por supuesto, en PCs con pantalla y teclado y eclipse. El software se instala y arranca en esas estaciones sun a base de "telnet" desde los PCs. Y por ello es muy difícil de depurar en el "entorno de producción".

Normalmente no es necesaria esa depuración. El ejecutable java que hace de servidor suele salir lo bastante bien del PC como para tener cierta garantía de que funciona bien. Y si hay algún problema, no suele haber problemas en arrancar el servidor con eclipse en el PC y depurarlo ahí de una forma normal. Pero no siempre es posible y, de hecho, tenemos un problema últimamente que requiere depuración en el entorno real, así que me he metido con lo de la depuración remota con eclipse.

El tema es bastante sencillo. Por un lado, basta con arrancar el programa que queremos probar con las siguientes opciones:

-Xdebug -Xrunjdwp:transport=dt_socket,address=1044,server=y,suspend=n

donde básicamente le estamos indicando con -Xdebug que debe admitir una conexión remota para debug y con -Xrunjdwp:transport los parámetros para esa conexión, así como que no debe esperar la conexión del debugger (suspend=n).

Luego, en eclipse, con el proyecto y los fuentes del programa a depurar montados, basta abrir la configuración de debugger (Run -> Debug Configuration) y crear una configuración de Remote Java Application para ese proyecto indicando los parámetros de conexión y el ordenador en que corre el ejecutable.

Por supuesto, aunque es una tontería, en la Chuwiki he puesto los detalles de la depuración remota con eclipse. Y hasta he puesto fotos, yo, que soy vago para capturar pantallas.

Sin embargo, el móvil que me han regalado sí tiene una cosa que me ha hecho ilusión: Java.

Así que me he decidido a hacer un primer "Hola Mundo" para el móvil y así enterarme de qué va todo esto de J2ME.

Primero a la página de sun, a bajarme el J2ME. Ya empezamos con cosas raras (para el que no tiene ni idea, como yo). Lo que hay que bajar es el "Sun java wireless Toolkit 2.5.2 for CLDC". Bueno, yo esperaba algo así como un JDK o un JRE y no un nombrecito tan extraño. Urgando un poco en google vi que era eso lo que había que bajarse para hacer programitas para el móvil.

La instalación es sencilla. Primero te pide el directorio de tu SDK de J2SE (tienes que tenerlo instalado previamente) para añadirle la parte de J2ME. Luego te pregunta por un directorio donde instalar el Wireless Toolkit. Ahí mete un pequeño entorno de desarrollo y un par (cuatro) emuladores de móviles estándar, para poder hacer pruebas antes de meter el código en el móvil.

Luego, como soy muy bruto, pensé en hacer el programa a pelo, es decir, con el gvim y compilando en línea de comandos. Es la mejor forma de enterarse qué estás haciendo. Sin embargo, mirando tutoriales, no encontré nada que me convenciera, además, soy un "caga-prisas" incapaz de pasarme dos días buscando y leyendo manuales antes de ponerme a codificar. Así que me decidí por Eclipse y su plugin para J2ME, el EclipseME, que por lo que he visto en google, debe ser el más aceptado.

Una vez instalado el plugin, se le da a nuevo proyecto J2ME y te crea un proyecto para J2ME con todos las dependencias ya puestas y un ficherito jda por defecto. Ese ficherito jda por lo visto en algo parecido al fichero de manifiesto de java estándar, pero para móviles y es obligatorio tenerlo. Ahí se indica el nombre de la aplicación, el icono que tiene que tener y la clase principal de la aplicación (la del main(), pero que aquí no tiene main(), sino que hereda de MIDlet, al igual que los applets no tienen main y heredan de Applet).

Luego, mirando por google y copiando trozillos de código de un lado y otro, hice el "Hola Mundo". Un programita que saca en la pantalla del móvil el texto "Hola Mundo". Ahora queda arrancarlo en eclipse a ver si funciona.

Hay que configurar el plugin EclipseME indicándole dónde están los emuladores de móviles. Para ello se le indica el directorio del Wireless Toolkit de Sun, donde están esos cuatro emuladores que comenté antes, y el plugin los busca y encuentra. Una vez hecho esto y elegido qué emulador quieres (el de móvil estándar con pantalla en color en mi caso), ya se puede ejecutar el programa.

Sale una ventana con el dibujo de un móvil en la pantalla. Allí se ejecuta el programa que hemos hecho y vemos en la pantalla del móvil el "Hola Mundo". Con el ratón podemos pulsar las teclas del móvil.

Ahora sólo me queda lo más importante, generar el .jar y meterlo en el móvil de verdad, a ver si funciona. La pega es que de momento no tengo ni bluetooth, ni cable de datos, así que hasta que vaya de compras no veré el resultado final.