According to NUCJPA-28, @Column(columnDefinition) is now implemented as a string appended to the inferred type when generating schema. This is wrong. The whole point is to allow the programmer to specify the column type exactly, e.g.:

  @Basic
  @Column(columnDefinition = "numeric(5,2) default 1.01")
  float variance;

Here, rather than using the driver-specific mapping for 'float', the programmer is telling you to use exactly the SQL standard 'numeric' type with explicit precision and scale, DDL default value, and no 'not null' constraint.

If columnDefinition is set, it should override all the related attributes (e.g., nullable, length, precision, scale), as the columnDefinition contains the EXACT backend-specific DDL definition for that column's type including all of these four attributes. The Javadoc for @Column is sparse, but it specifically notes:


public abstract String columnDefinition
    (Optional) The SQL fragment that is used when generating the DDL for the column.
    Defaults to the generated SQL to create a column of the inferred type.


Taking the contrapositive of this, if columnDefinition is *not* the default (empty) value, then the inferred type is not used at all. Yes, this means that a programmer can make a type that conflicts with the Java type. However, that flexibility is the whole point: how else can you make the schema generator spit out the type "vendorspecific_floatingpoint2" (which otherwise behaves like a float or double in JDBC)?