What causes "Unable to access JDBC type mapping [" + field.getName() + "]" in hibernate/hibernate-orm?

Verify the runtime JDK: run with an unmodified JDK distribution and a recent Hibernate; try another JDK build to rule out a patched java.sql.

hibernate/hibernate-orm · warning · HibernateException

Unable to access JDBC type mapping [" + field.getName() + "]

Error message

Unable to access JDBC type mapping [" + field.getName() + "]

What it means

JdbcTypeNameMapper.buildJdbcTypeNameMap (JdbcTypeNameMapper.java:44-58) reflects over the public static int fields of java.sql.Types to build a name-to-code map; an IllegalAccessException while reading a field is wrapped in HibernateException 'Unable to access JDBC type mapping [<field>]'. Public static fields of java.sql.Types are accessible on every stock JDK, so hitting this means an unusual runtime: a restrictive security manager, a patched/shaded java.sql.Types, or bytecode instrumentation interfering with reflection.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/type/descriptor/JdbcTypeNameMapper.java:54

					CORE_LOGGER.JavaSqlTypesMappedSameCodeMultipleTimes( code, old, field.getName() );
				}
			}
			catch ( IllegalAccessException e ) {
				throw new HibernateException( "Unable to access JDBC type mapping [" + field.getName() + "]", e );
			}
		}
		return unmodifiableMap( map );
	}

	private static Map<String, Integer> buildJdbcTypeNameMap(Class<?> typesClass) {
		final HashMap<String, Integer> map = new HashMap<>();
		for ( Field field : typesClass.getFields() ) {
			try {
				final int code = field.getInt( null );
				map.put( field.getName(), code );
			}
			catch ( IllegalAccessException e ) {
				throw new HibernateException( "Unable to access JDBC type mapping [" + field.getName() + "]", e );
			}
		}
		return unmodifiableMap( map );
	}

	/**
	 * Determine whether the given JDBC type code represents a standard JDBC type
	 * ("standard" being those defined on {@link java.sql.Types}).
	 *
	 * @implNote {@link java.sql.Types#OTHER} is also "filtered out" as being non-standard.
	 *
	 * @param typeCode The JDBC type code to check
	 *
	 * @return {@code true} to indicate the type code is a standard type code; {@code false} otherwise.
	 */
	public static boolean isStandardTypeCode(int typeCode) {
		return isStandardTypeCode( Integer.valueOf( typeCode ) );
	}

View on GitHub (pinned to fad1729dce)

Solutions

Verify the runtime JDK: run with an unmodified JDK distribution and a recent Hibernate; try another JDK build to rule out a patched java.sql.
If a security manager/policy is active, allow reflective access to java.sql (or remove the policy) and retry.
Disable or reconfigure shading/bytecode agents that touch java.sql, and check the uber-jar for relocated JDK classes.
If reproducible on a stock JDK, capture the full stack trace and report it as a Hibernate JIRA issue with the JDK vendor/version.

Defensive patterns

Strategy: try-catch

Validate before calling

// Fail fast with a clear message if JDK reflection is restricted
try {
    Field f = java.sql.Types.class.getField("VARCHAR");
    f.getInt(null);
} catch (Exception e) {
    throw new IllegalStateException(
        "java.sql.Types reflection is blocked in this runtime; JdbcTypeNameMapper will fail", e);
}

Try / catch

try {
    // operation that may log/resolve JDBC type names (exception formatting, schema export)
    new SchemaExport().createOnly(EnumSet.of(TargetType.DATABASE), metadata);
} catch (HibernateException e) {
    if (e.getMessage() != null && e.getMessage().startsWith("Unable to access JDBC type mapping")) {
        // environment defect: run on an unmodified JDK / relax the security policy, then retry
        log.error("Blocked reflection on java.sql.Types - check JDK/security manager", e);
    }
    throw e;
}

Prevention

Pin builds and deploys to unmodified JDK distributions; audit uber-jar relocation rules that could touch java.sql.
When running with restrictive security policies or instrumentation agents, smoke-test Hibernate bootstrap in that exact environment.

When it happens

Trigger: Running under a SecurityManager / custom policy that denies reflective access to java.sql; deploying a JDK or driver jar where java.sql.Types was rebuilt/shaded with non-public fields; Java agents or AOP/coverage tools weaving java.sql and breaking reflection; unit tests mocking java.sql.Types via agent-based frameworks.

Common situations: Legacy application-server security policies; shading/uber-jar builds that relocate or stub JDK classes (rare but seen with broken relocation rules); debugging environments with aggressive instrumentation (JaCoCo on JDK internals, hostile mocks); practically never on a standard JDK.

Related errors

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/97e3b7c198e91dd7. Report an issue: GitHub.