Diario de Programación

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.

Bueno, es un tema muy sabido, yo también sabía que existía hace tiempo y mucha gente lo usa para depurar la parte del servidor en sus aplicaciones web. Yo, como desarrollo aplicaciones de escritorio, nunca me había preocupado por el tema.

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.

Este verano me han regalado un móvil. No es que me hagan especial ilusión, de hecho el que tenía  lo usaba como hucha y me explico: es de tarjeta prepago, cada seis meses le echo dinero para que no caduque, pero habitualmente dejo el móvil apagado y en casa, por lo que el saldo se va incrementando, como una hucha.

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.