Category Archives: JAVA

Named parameter not found in JPA/Hibernate native SQL queries

Leave a reply

When using named parameters in native SQL queries with Hibernate implementation of the Java Persistence API (JPA), you may run into the following error
[code lang=java]
org.springframework.dao.InvalidDataAccessApiUsageException: Parameter with that name [orderId] did not exist;
nested exception is java.lang.IllegalArgumentException: Parameter with that name [orderId] did not exist
[/code]

This happens even if the named parameter was properly set, as in the following example :

For example :
[code lang=java]
void update(EntityManager em) {
Query q = em.createNativeQuery(“SELECT * FROM orders where id = :orderId;”);
q.setParameter(“orderId”, “1234”);
q.executeUpdate();
}
[/code]

The issue comes from Continue reading →

Solving Eclipse/maven error : dependency/ a.b.c (managed from x.y.z)

Leave a reply

If Eclipse/M2E reports a maven dependency version conflict, with message “managed from x.y.z” (ex : “jooq/ 3.7.1 (managed from 3.6.0)“), the conflicting dependency is defined by an ancestor of the current maven project (could be its parent, great-parent, great-great-parent, etc.).

For example, let’s say maven signals a dependency conflict for a spring-boot 1.3 application. Version 3.7.1 of the JOOQ library is used while you specified version 3.6.0 (which is a pain because JAVA 7 is targeted, while JOOQ 3.7.1 only supports JAVA 8).

The error returned by the SpringBoot application is :
[code]
java.lang.UnsupportedClassVersionError: org/jooq/SQLDialect :
Unsupported major.minor version 52.0
[/code]

JOOQ is used by a dependency of the spring-boot application. The main application itself has no reference to JOOQ.

Indeed :

  1. project A declares a maven dependency on JOOQ 3.6.0 :
    [code lang=xml]

    org.jooq
    jooq
    3.6.0

    [/code]
    datawarehouse-jooq-dependency
  2. project B declares a maven dependency on project A, and defines spring-boot-starter-parent as a parent
    In project B dependencies, Eclipse/M2E flags JOOQ as “version 3.7.1 (managed from 3.6.0)” while version 3.6.0 is expected.
    feedbackrestservices-jooq-dependecy
  3. spring-boot-starter-parent has spring-boot-dependencies as a parent, which itself manages dependencies for JOOQ
    spring-boot-dependencies-managed-dependencies-jooq
    [code lang=xml]

    org.jooq
    jooq
    ${jooq.version}

    [/code]

To fix it, you could add a jooq 3.6.0 dependency to project B, so that the maven dependency conflict solving strategy uses this version since it is the nearest dependency. But that would be ugly. A cleaner solution consists in overriding the jooq.version property defined in spring-boot-starter-parent, as documented here :
[code lang=xml] 3.6.0 [/code]

Why is “boolean val = (0 == 0 ? null : true)” causing a Java NullPointerException ?

Leave a reply

This would be a funny interview question : why is the following Java code compiling but throwing a NullPointerException at runtime ?
[code lang=java]
boolean val = (0 == 0 ? null : true);
[/code]

Since boolean is a primitive data type, it can’t be initialized with a null value. As a matter of fact, the compiler rejects the following code :
[code lang=java]boolean val = null;[/code]
So, one would expect the conditional/ternary operator assignement to also fail at compile time, whether because null can’t be assigned to a boolean, or because null and true don’t have the same data type, which is not allowed by the ternary operator.
That’s not the case, compilation runs fine, only at runtime do you get a NullPointerException.
Why ?

I guess this comes from Java autoboxing/autounboxing feature. Since the “then” and “else” parts of the operator must have the same type, Java autoboxes true to Boolean.TRUE, and assumes null is a Boolean. Knowing that Boolean can be autounboxed to boolean, the compiler will accept the statement.

Then, at runtime, null will be autoboxed to boolean, eventually causing the NullPointerException. Et voilà !

Where are JAVA user preferences saved on Windows ?

Leave a reply

If you want to store user preferences/settings for a JAVA application, the java.util.prefs.Preferences class is the way to go. It abstracts the storage of the user info, as explained in the JAVA doc:

This class allows applications to store and retrieve user and system preference and configuration data. This data is stored persistently in an implementation-dependent backing store.

Question : On Windows, where are the JAVA user preferences stored ?
Answer : In the registry. Typically in HKEY_CURRENT_USER\Software\JavaSoft\Prefs\[your path] If you want to change your storage (i.e : backing store) you will need a new PreferencesFactory, as detailed in this post.