NetBeans: el IDE que se Autoanaliza

Botón para que Netbeans se autoanalice

Botón para que Netbeans se autoanalice

En los últimos a años el entorno de desarrollo NetBeans respondió a la competencia que representa Eclipse y mejoró en muchísimos aspectos, entre los que se destaca el soporte para diferentes lenguajes (hoy PHP, C/C++, Ruby y Groovy están perfectamente integrados a NetBeans). Pero un aspecto clave para muchos es el rendimiento y para lograr mejoras es fundamental identificar dónde hay margen para mejorar.

Así que NetBeans se puede autoanalizar (realizar un sampling profiling de si misma al vuelo) y mostrar los resultados desde su propia interfaz mientras la usamos. ¡Cuántas veces quisiera hacer eso mientras uso otros programas!

Resultado del Profiling de NetBeans

Resultado del Profiling de NetBeans

Realmente en las últimas versiones se han notado mejoras en rendimiento. Más tareas se realizan en segundo plano sin interferir al usuario y hay menos operaciones que tomen mucho tiempo.

Además el profiler que viene integrado con NetBeans es excelente. Lo he usado para analizar código que nunca antes había visto  y en nada de tiempo me permitió detectar los tres o cuatro métodos donde había mucho margen para hacer optimizaciones.

Incluso muchas veces importo proyectos de Eclipse con el único objetivo de pasarlos por el profiler de NetBeans.

Evitar que se Cierre una Aplicación Java / Swing

A veces es necesario evitar que el usuario cierre la aplicación mientras se está realizando un procesamiento o simplemente queremos que confirme que es verdaderamente si intención salir en ese momento


public class MyApp extends JFrame {
    public MyApp() {
        super("MyApp");
        this.setDefaultCloseOperation(DO_NOTHING_ON_CLOSE);
        this.addWindowListener(new WindowAdapter() {
            @Override
            public void windowClosing(WindowEvent e) {
                if(!model.isProcessing()){
                    setVisible(false);
                    dispose();
                }else{
                    JOptionPane.showMessageDialog(
                            MyApp.this, "Espere a que terminemos de procesar..."));
                }
            }
        });
    }
}

En el ejemplo  suponemos que hay una variable de instancia “model” que nos permite saber si la aplicación está en condiciones de ser cerrada o no.

El salir de la aplicación ocurre al hacer dispose() del último o único JFrame que está visible siempre y cuando estén dadas las demás condiciones para que la aplicación termine. Es importante asignar DO_NOTHING_ON_CLOSE como operación de cerrado por defecto para poder definir nosotros qué pasa cuando el usuario quiere cerrar.

El Rol de la Prensa

Mientras algunos están interesados en confundir todo lo posible acerca del papel del periodismo en la sociedad, la realidad nos muestra cuál es ese rol con hechos. Ni expresiones de deseo ni opiniones.

Esta es la historia de un gobierno democrático, elegido en 2005 por el voto del pueblo en elecciones limpias. El gobierno municipal de la ciudad de Bell, en Los Angeles, California, EE.UU.

Básicamente al llegar al poder, los miembros del consejo deliberante se dedicaron a enriquecerse asignándose salarios de alrededor de un millón y medio de dólares anuales (Obama como presidente de todo el país gana 400.000). Para compensar los gastos aumentaron los impuestos y las tasas municipales todo lo que legalmente pudieron. En las referencias que publico al final de este texto está el artículo en la Wikipedia donde se detallan todos los delitos que hicieron estos chantas y que se fueron descubriendo cuanto más se investigó.

Se trata de una ciudad de 36.000 habitantes, en su mayoría pobres, algunos inmigrantes sin papeles y que de repente pagaban por sus casas más que lo que se pagaba en lugares como Beverly Hills.

Lo interesante es que esto sucedía a espaldas de la gente, nadie en esa ciudad sabía lo que ganaban sus gobernantes. Algunos iban a protestar por los impuestos altos, pero nunca recibían respuesta y no tenían mucho poder para cambiar las cosas. Nadie de adentro del consejo denunciaba porque estaban todos metidos en la “joda”.

La prensa local se dedicaba a cubrir las noticias “oficiales”, básicamente publicaban las gacetillas de prensa o llamaban por teléfono luego de las asambleas y preguntaban que se había decidido. No investigaban.

Algunos ciudadanos que sabían lo que pasaba, pero no estaban en la joda tampoco denunciaban por miedo a perder el trabajo o porque recibían ayuda en forma de planes sociales.

Todo eso empezó a cambiar cuando el diario Los Angeles Times descubrió lo que pasaba y pidió los registros públicos al consejo. Los corruptos funcionarios se negaron a darlos, pero allá existe una ley de acceso a la información (algo que no existe en todos lados). Gracias a esa ley, el diario obtuvo las pruebas de que estos funcionarios y sus allegados se estaban enriqueciendo a costa del dinero de los contribuyentes. La “joda” se terminó en 2010. El diario ganó el premio Pulitzer por su investigación y los funcionarios tuvieron que renunciar y fueron a la cárcel.

Ese es el rol del periodismo: investigar al gobierno y denunciar sus abusos por el bien del pueblo.

Se necesitan medios de comunicación fuertes con respaldo económico y capacidad de llegar a mucha gente. Un blog local había denunciado el tema, pero no fue sino hasta que un LA Times lo puso en la tapa que sobrevinieron las investigaciones judiciales, las renuncias y la cárcel.

Referencias:

Algunas de las Razones del Éxito de Java

Java es un lenguaje muy criticado desde todos los ángulos. Que es lento, que no sirve para cierta tarea, que no soporta tal cosa o que es el nuevo COBOL. Muchas críticas más. Sin embargo, con todos sus defectos es uno de los lenguajes de programación más exitosos. Pero, ¿por qué?

No hay un solo motivo, claro está, pero pienso que uno de los más importantes es retrocompatibilidad. Un programa hecho para la versión de Java 1.0 requiere ningún cambio para ejecutarse en una versión posterior de Java. Esto contrasta fuertemente con otros lenguajes que introducen cambios incompatibles con cada nueva versión, obligando a tener que ejecutarse con una determinada versión de su intérprete o máquina virtual.

Python

Python es un ejemplo. En este artículo se detallan algunas de las cuestiones que se deben tener en cuenta a la hora de escribir código que se piensa algún día migrar a Python 3.0. Esto hace que muchas bibliotecas de funciones queden atadas a cierta versión de Python, creando una situación muy poco deseada: para usar cierta biblioteca debo usar yo la versión de Python compatible o esperar a que migren la biblioteca.

PHP

PHP es el ejemplo más patético de este problema. Introdujeron varios cambios incompatibles de la versión 3 a la 4, de la 4 a la 5 y de la 5 a la 6. Y como cada nueva versión de PHP requiere que se escriba el código de otra forma, los frameworks tampoco se esfuerzan en mantener compatibilidad. Un programa hecho con Symfony 1.0 no funciona en ninguna versión posterior. En general un programa hecho con Symfony N va a requerir que se tenga instalada la versión N de Symfony (y la de PHP correspondiente) para siempre mientras esté en uso. Existe la posibilidad (desde Symfony 1.2) de migrar el proyecto, pero se requiere volver a probarlo, revisar que haya quedado todo bien y en general tener mucha suerte de no haber hecho nada que no esté contemplado por el migrador.

La clave para que Java haya podido lograr esa compatibilidad está en que los cambios que se introducen (que han sido muchísimos a lo largo de los años) son propuestos, analizados y aprobados por expertos en el área.

Otra ventaja de dar participación a expertos en las decisiones sobre el lenguaje favorece a que no se meta la pata tan seguido. Por ejemplo, Java desde el día 0 soporta Unicode. Esto facilitó su adopción en el mundo y le ahorró a todos los programadores innumerables problemas. Hoy, a más de 15 años de su primera versión,  Python 3.0 y PHP 6 finalmente están incorporando Unicode, claro que sumando una nueva incompatibilidad.

Finalizar Aplicación Java / Swing sin Recurrir a System.exit()

La máquina virtual Java termina su ejecución cuando todos los threads que están corriendo son demonios. En particular el thread main (en el que corre nuestro programa apenas arranca) no es un demonio, por lo que mientras se ejecuta, la JVM sigue corriendo.

Cuando abrimos un JFrame de Swing arranca el EDT que es otro thread que no es demonio.

Ningún thread creado por nuestro código es demonio a menos que se lo indique explícitamente con el método setDaemon(true).

Entonces cuando el usuario nos indica que quiere salir de nuestra aplicación o por cualquier circunstancia deseamos terminar la ejecución nos basta con hacer que tanto el thread main, el EDT y todos los thread que creamos terminen.

En general el thread main ya no se está ejecutando cuando arrancamos el EDT (ya se ejecutó la última instrucción del método main). Los thread que creamos deben llegar la última instrucción del método run (habrá que revisar la lógica de cada uno si es que hay algún bucle o está esperando recursos).

Pero ¿cómo finalizar el EDT, si es el thread que está permanentemente esperando los eventos del usuario?

El EDT finaliza cuando se destruye el último componente visual de nivel superior (JFrame o  JDialog) de Swing. Entonces, por ejemplo si nuestra aplicación es un JFrame, basta con hacer

this.setVisible(false);
this.dispose();

Si ese JFrame es el último (o único), entonces el EDT termina y la JVM también. Si hay más instancias de JFames o JDialog abiertas por ahí, habrá que hacerlo con cada una.

Recurrir a System.exit() para salir de la aplicación de escritorio es como usar el administrador de tareas del sistema operativo para cerrar los programas.

Si pensamos un poco en el flujo natural del control de nuestra aplicación, no lo necesitaremos ni siquiera para salir en caso de errores fatales.

La desventaja es que si tenemos varios System.exit() diseminados por todo el código no tenemos forma de asegurarnos que antes de salir, se haga determinada tarea (borrar archivos temporales, imprimir algún mensaje, pedir confirmación al usuario, etc.) Habrá que hacerla en cada punto donde se quiera salir.

Swing y el EDT

Una de las primeras cosas que hay que saber al empezar a programar aplicaciones de escritorio en Java con Swing es que el thread main que arranca cuando se ejecuta el método main de nuestra aplicación no es el mismo thread en el que se ejecutan los eventos que dispara el usuario al interactuar con nuestra aplicación.

De hecho, si en tu aplicación haces algo así:

public static void main(String args[]){
    new MyApp().setVisible(true);
}

entonces el thread main termina inmediatamente después de poner visible el JFrame.  Al hacerlo queda corriendo el thread de Swing, también conocido como EDT (por Event Dispatch Thread). La aplicación continuará corriendo mientras quede ese thread activo independientemente de que el thread main ya esté finalizado.

El tema es que los objetos de Swing no admiten ser manipulados desde otro thread que no sea el EDT, entonces llamar al método setVisible(true) desde el thread main es incorrecto. Para ejecutar código en el thread de Swing tenemos que hacerlo indirectamente:

public static void main(String args[]){
    SwingUtilities.invokeLater(new Runnable() {
        @Override
        public void run() {
            new MyApp().setVisible(true);
        }
    });
}

De esa forma el método run() del objeto Runnable que creamos se va a ejecutar en el EDT, tal como se ejecutan los eventos que dispara el usuario.

Hay que estar siempre atentos para evitar manipular objetos de Swing en threads que no sean el EDT, ya sea el thread main o en otro thread que hayamos creado nosotros.

Minimizar el Espacio Desperdiciado al Grabar un CD o DVD (Parte 2)

Get Ready to Burn es un programa como cualquiera de los que ya hablé en esta oportunidad, pero que intenta tomar lo mejor de cada uno.

Sirve para grabar un conjunto de archivos o carpetas en varios discos grabables de manera de intentar llenar cada disco lo máximo posible y aprovechar al máximo su capacidad.

Get Ready To Burn v0.1

Get Ready To Burn v0.1

  • Multi plataforma (Windows, Mac OS X, Linux, etc.)
  • Soporta diferentes tamaños de CD, DVD y BluRay.
  • Puede generar imágenes ISO directamente (en forma nativa, sin herramientas externas).
  • Sistema de archivos UDF o ISO 9660.
  • Soporta las extensiones de ISO 9660 Joliet y Rock Ridge.
  • Versiones de UDF soportadas: 1.02, 2.01 o 2.60.
  • Opcionalmente se puede sólo separar los archivos en carpetas en lugar de generar imágenes ISO.
  • Drag y drop de carpetas sobre la ventana de la aplicación.
  • Usa 4 algoritmos para calcular la solución (Best Fit, Worst Fit, Next Fit y First Fit) y se queda con el mejor resultado.
  • Es gratuito y su código fuente está disponible bajo licencia GPL versión 3.
Bajar la Última Versión

Bajar la Última Versión