Bitsmi Blog
Error NullPointerException al evaluar una expresión ternaria
Descripción de error
Se produce un error de tipo NullPointerException al evaluar una expresión ternaria donde se mezclan valores de tipo primitivo (int, long, double…) con sus correspondientes tipos Wrapper (Integer, Long, Double) si el valor de resultante de la expresión es null.
Cuando la expresión condicional evalua y se asigna un valor no nulo, en este caso el segundo operando de la expresión, la operación funciona correctamente:
long val1 = 1;
Long valor2 = val1==1 ? val1 : (Long)null;
System.out.println("VALOR2 is null -> " + (valor2 != null));
→ VALOR2 is null -> true
En cambio, cuando se evalúa la condición y el valor resultante es null, tercer operando en el ejemplo, aunque este último se trate como un tipo objeto, se produce un error:
long val1 = 2;
Long valor2 = val1==1 ? val1 : (Long)null;
System.out.println("VALOR2 is null -> " + (valor2 != null));
→ Exception in thread "main" java.lang.NullPointerException
Solución propuesta
El error se produce porque en las expresiones ternarias de este tipo, el compilador escoge como tipo de retorno el valor primitivo, en el caso de los ejemplos anteriores el tipo long en lugar del tipo wrapper Long. Por esta razón, aunque se especifique una conversión explicita al tipo adecuado cuando se utiliza un valor nulo, siempre se producirá un error si ese es el resultado de la operación ya que el tipo primitivo no admite este tipo de valores.
La solución simple a este error es trasformar en todos los casos el valor resultante a un tipo wrapper. En el ejemplo, el segundo miembro de la operación es transformado a Long mediante el método valueOf para que todos los operandos sean de este tipo, que si admite valores nulos. El compilador escogerá este tipo para el resultado de la operación ya que es el único presente en las 2 alternativas, tanto si se cumple la condición como si no.
long val1 = 2;
Long valor2 = val1==1 ? Long.valueOf(val1) : (Long)null;
System.out.println("VALOR2 is null -> " + (valor2 != null));
→ VALOR2 is null -> false
Referencias
Error al tratar un dato de tipo CLOB con Hibernate en una base de datos PostgreSQL
Descripción de error
Se produce un error al recuperar datos de tipo LOB de una entidad a través de la capa de persistencia basada en JPA + Hibernate si la base de datos subyacente es PostgreSQL. Se produce un error de tipo:
org.postgresql.util.PSQLException: Bad value for type long
Patrón Cadena de Responsabilidad con Spring
El patrón de diseño Cadena de Responsabilidad (Chain of Responsability) es un patrón de tipo «comportamiento», es decir, que establece protocolos de interacción entre clases y objetos emisores y receptores de los mensajes a procesar. Es usado para desacoplar las diferentes implementaciones de un algoritmo de su uso final, ya que el emisor del mensaje no tiene porqué conocer el componente que finalmente procesará el mensaje.
Su funcionamiento básico es el siguiente:
- Se forma una lista encadenada con todos los posibles receptores del mensaje, de forma que cada uno de ellos tengo un enlace al siguiente, si se quiere, ordenados pueden ordenarse por prioridad de forma que en caso de que varios de ellos sean capaces de procesar un mismo mensaje, prevalezca el que tenga una prioridad mas alta según criterios funcionales.
- El emisor del mensaje, sólo ha de tener acceso al primero de los receptores. Será a este al que se le hará la llamada inicia y quien proporcionará el resultado al emisor.
- Cada uno de los receptores, evaluará el mensaje proporcionado por el emisor y decidirá si es capaz de procesarlo y proporcionar un resultado. En caso afirmativo, se acabará la cadena de llamadas a posteriores receptores y se retornará. Esto hará que el resultado pase por todos los receptores ejecutados anteriormente hasta devolvérselo al emisor. En caso que el receptor actual no sea capaz de evaluar el mensaje, delegará en el siguiente receptor en la cadena esperando el resultado que le proporcione, sea el o no el que finalmente se haga cargo de proporcionárselo.Todo lo explicado hasta ahora se puede resumir en el siguiente diagrama de secuencia:
OCP7 10 – E/S de archivos Java – Parte 3 – FileStore y WatchService
OCP7 10 – E/S de archivos Java – Parte 2 – Interfaz FileVisitor
OCP7 10 – E/S de archivos Java – Parte 1 – NIO.2 (New Input Output 2)
Generar esquema XSD a través de las clases de dominio con JAXB
Una operación muy habitual cuando se trabaja con JAXB para generar XML a partir de clases de dominio mediante anotaciones de JAXB es la de generar el esquema XSD asociado a la estructura de datos de dicho XML. Este esquema puede ser utilizado posteriormente para volver a generar las clases de dominio a través de JAXB. Se trata de una operativa muy común cuando se trabaja con servicios web REST para exponer la estructura de los mensajes de respuesta desde el servidor a los clientes para que estos puedan interpretarla, por ejemplo.
Una manera muy sencilla de generar esta definición XSD cuando ya se tienen modeladas las clases de dominio a partir de las que se creará el XML mediante JAXB es
utilizando el método generateSchema del contexto JAXB al que se han especificado las clases de dominio que forman el mensaje XML.
Creación de un Fat Jar con Apache Maven
Hace un tiempo publiqué un post en este mismo blog en el que se explicaba como construir un Fat Jar con Apache Ant para empaquetar toda una aplicación, dependencias incluidas, dentro de un mismo fichero jar. El procedimiento para ello se basa en extraer los ficheros *.class compilados que se encuentran dentro de los jars de las dependencias incluirlo dentro del jar principal de la aplicación. En caso de utilizar Maven como herramienta de construcción en lugar de Ant, esta acción se puede realizar utilizando el plugin Shade. Para ello será necesario incluir su definición dentro del fichero pom.xml del proyecto y asociar la ejecución de su único goal shade a la ejecución de la fase de empaquetado package:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.1</version>
<executions>
<!-- Ejecutar el goal "shade" en la fase de empaquetado "package" -->
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<!-- Se puede especificar la clase que contiene el método "main" para inluirlo en el Manifest
de la aplicación i así hacerla ejecutable
-->
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.bitsmi.yggdrasil.launcher.MainProgram</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Esto hará posible su ejecución automática durante la construcción de la aplicación a través de los goals package, install o deploy de Maven.
Adicionalmente, es posible especificar en la configuraciones adicionales para la ejecución del plugin en la sección <configuration/>, como por ejemplo reglas de inclusión y exclusión de artefactos en el Fat Jar, renombrado de paquetes, o tratamiento de recursos ubicados en el directorio META-INF para evitar solapamiento (ficheros de licencia, definición de Services…). En la página del plugin hay multitud de ejemplos sobre cómo utilizar cada una de estas funcionalidades.
Enlaces de interés
Adaptación de librería java-json.jar a JAVA 1.4
Una de las limitaciones más comunes a la hora de programar es la versión del jdk que requiere nuestra aplicación. Cuando los requerimientos exigen una versión un tanto antigua (1.4 por ejemplo), encontramos problemas a la hora de usar tecnologías como AJAX, sobretodo si necesitamos utilizar respuestas de tipo JSON. Para ello existe una librería muy simple «java-json.jar» pero nos encontramos de que es incompatible con el jdk 1.4.
Aquí explicaré en pocos pasos como adaptar y recompilar esta librería para hacerla compatible y funcional para una aplicación que use un jdk 1.4. Necesitaremos descargar el código fuente de la librería y modificar unos pequeños detalles de las clases que contiene.
Se puede descargar el código fuente de aquí
Función CONVERT en BBDD Oracle 10g
La función CONVERT permite convertir un carácter de un conjunto específico de caracteres a otro carácter de otro conjunto específico de caracteres.
En el caso concreto de la aplicación en la que se está trabajando se desea realizar una consulta sobre una tabla concreta para recuperar una descripción que contenga la palabra avión, como caso de ejemplo. Las descripciones a recuperar son las siguientes
Auxiliares de vuelo y camareros de avión, barco y tren
Mecánicos y ajustadores de motores de avión
mediante la siguiente consulta
SELECT
des.des_dcol
FROM
TABLA_DESCRIPCIONES des
WHERE
UPPER(des.des_dcol) LIKE UPPER(‘%avión%’));
No encuentra ningún resultado dado que realiza la consulta estrictamente con acento y aunque existe en la tabla no lo retorna correctamente.
Aquí es dónde entra la utilización de la función CONVERT. La siguiente consulta busca las descripciones que contengan el valor %avión% mostrando el resultado correctamente.
SELECT
des.des_dcol
FROM
TABLA_DESCRIPCIONES des
WHERE
UPPER(CONVERT(des.des_dcol, ‘US7ASCII‘))
LIKE UPPER(CONVERT(‘%avión%’, ‘US7ASCII‘));
Las descripciones recuperadas son las esperadas como se ha comentado con anterioridad.
- Auxiliares de vuelo y camareros de avión, barco y tren
- Mecánicos y ajustadores de motores de avión
La clave se encuentra en el parámetro que se le pasa, US7ASCII, correspondiente una de las codificaciones de caracteres comunes (ASCII US 7-bit) de las que puede gestionar la función..
Hasta aquí la prueba de concepto de esta función de Oracle. Para un mayor detalle de la misma se puede consultar en el siguiente enlace.