Entries for Java

Utilizando JPA en Eclipse para almacenar en HSQLDB me he encontrado con el siguiente error:

Catalog "SA" cannot be resolved for table xxx

Para solucionarlo, vamos a las Propiedades de nuestro proyecto, en el apartado JPA y sobreescribimos el catálogo de la conexión activa. En HSQLDB es PUBLIC.

Para los programadores de C, C++, Java, ... puede resultar un tanto extraño la forma de gestionar los parámetros que tiene Python.

Voy a explicar en esta entrada los tipos de parámetros y cómo podemos hacer uso de ellos.

Ahora vamos a ver como podemos acceder a una base de datos SQLite a través de JDBC. Para ello, voy a hacer uso de del driver JDBCSQlite, así que lo primero que vamos a hacer es descargarlo:

$ wget -c http://files.zentus.com/sqlitejdbc/sqlitejdbc-v056.jar

Después podemos hacer uso del siguiente código de ejemplo para ver que todo funciona:

import java.sql.* ;

class SQLiteJDBCTest {
    private static String DATABASE = "base_de_datos.db";
    private static String TABLE = "TablaDeLaBaseDeDatos";

    public static void main(String args[]) {
        try {
            // Load the database driver
            Class.forName("org.sqlite.JDBC");

            // Get a connection to the database
            Connection conn = DriverManager.getConnection("jdbc:sqlite:" + DATABASE);

            // Print all warnings
            for(SQLWarning warn = conn.getWarnings(); warn != null; warn = warn.getNextWarning()) {
                System.out.println("SQL Warning:");
                System.out.println("State: " + warn.getSQLState());
                System.out.println("Message: " + warn.getMessage());
                System.out.println("Error: " + warn.getErrorCode());
            }

            // Get a statement from the connection
            Statement stmt = conn.createStatement() ;

            // Execute the query
            ResultSet rs = stmt.executeQuery("SELECT * FROM " + TABLE);

            // Close the result set, statement and the connection
            rs.close();
            stmt.close();
            conn.close();
        }
        catch(SQLException se) {
            System.err.println("SQL Exception:");

            // Loop through the SQL Exceptions
            while(se != null) {
                System.err.println("State: " + se.getSQLState());
                System.err.println("Message: " + se.getMessage());
                System.err.println("Error: " + se.getErrorCode());

                se = se.getNextException();
            }
        }
        catch(Exception e) {
            System.err.println(e.toString());
        }
    }
}

Lo único que habrá que modificar son las variables de clase DATABASE y TABLE. Una vez hecho esto, bastará con compilar y ejecutar para asegurarnos que todo funciona:

$ javac SQLiteJDBCTest.java
$ java SQLiteJDBCTest 
java.lang.ClassNotFoundException: org.sqlite.JDBC

Es importante recordar, que para que esto funcione debemos añadir el driver que descargamos al principio al classpath:

$ java -cp .:sqlitejdbc-v056.jar SQLiteJDBCTest

Mondrian es un servidor OLAP software libre escrito en Java. Mondrian permite a los usuarios de negocio analizar grandes cantidades de datos en tiempo real. Los usuarios exploran los datos de negocio mediante la extracción y tabulación cruzada de información, mediante consultas analíticas complejas.

Además está preparado para ser desplegado en servidores de aplicaciones (en concreto he usado Tomcat), ya que está incluido un archivo WAR.

La idea es muy sencilla: estamos desarrollando una aplicación en Java con NetBeans y hacemos uso de una o varias bibliotecas JAR externas, pero cuando generamos el archivo .jar de nuestro proyecto, dentro del directorio dist se crea un directorio llamado lib que contiene una copia de las bibliotecas. La intención es generar un único fichero .jar con todo el contenido.

Para ello vamos a modificar el fichero build.xml que contiene las reglas de compilación para Ant. Desde el directorio de nuestro proyecto, editamos el fichero nbproject/build-impl.xml. Aquí buscamos la sección -post-jar:

<target name="-post-jar">
    <!-- Empty placeholder for easier customization. -->
    <!-- You can override this target in the ../build.xml file. -->
</target>

Y la substituiremos por una como la siguiente:

<target name="-post-jar">
    <jar jarfile="dist/miproyecto-dist.jar">
        <zipfileset src="${dist.jar}" excludes="META-INF/*" />
        <zipfileset src="lib/mibiblioteca.jar" excludes="META-INF/*" />
        <manifest>
            <attribute name="Main-Class" value="es.menudoproblema.miproyecto.Main"/>
        </manifest>
    </jar>
</target>

Dónde:

• <jar jarfile="dist/miproyecto-dist.jar"> - Indica que vamos a crear un fichero .jar nuevo
• <zipfileset src="lib/mibiblioteca.jar" ... /> - Indica la biblioteca en cuestión, y podemos añadir tantos como librerías usemos
• <attribute name="Main-Class" value="es.menudoproblema.miproyecto.Main"/> - Indica la clase principal

Programando en una tarea asíncrona, AsyncTask, me he encontrado con el siguiente error:

Can't create handler inside thread that has not called Looper.prepare()

La solución es muy sencilla:

public class MiAsyncTask extends AsyncTask<Void, Void, Void> {
    @Override
    protected Void doInBackground(Void... params) {
        Looper.prepare();
        ...
    }
}

Para poder crear una activida, es necesario un contexto. Un servicio se ejecuta en segundo plano y no hace uso de un contexto. Por ello, es necesario utilizar el contexto de la aplicación:

Intent dialogIntent = new Intent(getBaseContext(), MainActivity.class);
dialogIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
getApplication().startActivity(dialogIntent);

Estoy retomando la programación Android en estos días y he encontrado algún que otro problema al trabajar con hebras. Durante la creación de una Activity necesito hacer una petición a un WebService. Para ello he creado un ProgressBar y he lanzado una hebra que se encarga de ejectuar la petición. Una vez la petición ha finalizado, si ha ocurrido algún error, quiero mostrar un AlertDialog.

Ahora mismo estoy desarrollando una práctica en la que necesito generar números de 128 bits y escribirlos en un fichero en formato decimal, formato hexadecimal y formato binario.

Empecé jugueteando con C++, y mi sorpresa fue que un long long int utiliza 64 bits bajo una arquitectura de 64 bits. Como el estándar de C/C++ no especifica el tamaño de los tipos de datos esperaba que la últimas versiones del compilador (g++ para ser concretos) utilizasen mayor precisión. Tras esto descarté C++. Existen librerías, como GMP, que nos permiten trabajar con datos de mayor precisión, pero no dispongo de tiempo para investigar.

Lo siguiente en venirme a la cabeza fue Python. La ventaja (y en este caso desventaja) de usar Python es que Python utiliza precisión arbitraria. Esto es, que tú asignas a una variable un entero y te puedes despreocupar. Python asigna dinámicamente el tipo de dato int a la variable, pero si esta crece, en lugar de producir un overflow, le asigna el tipo de dato long y continúa con la ejecución. A partir de ahí, el tipo de dato long crece (reserva de memoria automática) en función de la precisión que necesite. Esto me impide limitar los enteros a 128 bits :(

La opción por la que he optado: Java.

Cuando en una tabla se permiten columnas con valores nulos, es necesario checkear que realmente tienen un valor antes de utilizarlo para evitar un java.lang.NullPointerException.

Supongamos la siguiente situación. Tenemos una tabla en la que la clave primaria es un identificador auto incremental. En mi caso,utilizando MySQL ( por obligación :), la tabla sería la siguiente:

CREATE TABLE `tableName`
(
    `id` INT NOT NULL auto_increment,
    `name` VARCHAR(20),
    PRIMARY KEY(`id`)
);

El problema es independiente del Sistema Gestor de Bases de Datos (SGBD) ya que estoy trabajando a través de JDBC, pero la creación de la tabla si puede diferir en función del que se esté utilizando.

Ahora realizamos una nueva inserción, pero ¿cuál es el identificador que el SGBD ha asignado a la tupla?

Algunos de los componentes que he estado desarrollando últimamente trabajan con parte de la interfaz dinámicamente, de forma que los componentes se crean, añaden y eliminan durante la ejecución de la aplicación.

Después de hacer una llamada a algún remove del panel, todo lo demás desaparece.

Esto es un problema que aparece cuando tratamos de generar partes de la interfaz por código. Creamos un panel, añadimos distintos componentes y añadimos el panel que acabamos de crear a un frame. Le damos a Run y allí no se ve nada.

Ahora le toca el turno a la transparencia. Realizar componentes translúcidos es bastante sencillo. Podemos incluso a realizar efectos fade-in y fade-out jugando con la transparencia y un temporizador. Realmente no sé como afecta esto al rendimiento de la aplicación, porque no he llegado tan lejos.

Uno de los problemas con los que me he encontrado es que en algunas ocasiones, cuando estaba desarrollando en un JFrame, me resultó imposible hacer un botón del tamaño que deseaba. Por más que utilizaba los métodos setSize() y/o setPreferredSize(), aquello hacía caso omiso. Tras muchas vueltas por fin encontré la respuesta.