Source of the problem is in method InferredBasicValueResolver#from.

When explicitJavaType is non null, call to BasicTypeRegistry#resolve. This part of code is real source of the problem:

final BasicType<J> basicType = getRegisteredType( jtdToUse.getJavaType() );

if ( basicType != null ) {

if ( basicType.getJdbcType() == stdToUse )

Unknown macro: { return basicType; }

else

Unknown macro: { return new NamedBasicTypeImpl<>( jtdToUse, stdToUse, basicType.getName() ); }

}

basicType is non null since there is registered type corresponding to JavaType. Since basicType.jdbcType is identical to required JdbcType, it will be returned as result

To avoid that problem, when explicitJavaType is non null, part of code

jdbcMapping = resolveSqlTypeIndicators(

stdIndicators,

typeConfiguration.getBasicTypeRegistry().resolve( explicitJavaType, inferredJdbcType ),

explicitJavaType

);

is replaced by

final BasicTypeImpl<T> basicType = new BasicTypeImpl<>( explicitJavaType, inferredJdbcType );

// if we are still building mappings, register this ad-hoc type

// via a unique code. this is to support envers

typeConfiguration.getMetadataBuildingContext().getBootstrapContext()

.registerAdHocBasicType( basicType );

jdbcMapping = resolveSqlTypeIndicators(

stdIndicators,

basicType,

explicitJavaType

);

Which is copy&paste cerator parameter from BasicTypeRegistry#resolve