Attribute converter not called successfully during EntityManager.refresh() call

[oramattkosem]

Attribute converter not called successfully during EntityManager.refresh() call

[rfelcman]

I think, that issue is in TestObjectConverter. I think, that better implementation is:

@Converter
public class TestObjectConverter
        implements AttributeConverter<char[], String> {

    @Override
    public String convertToDatabaseColumn(char[] argNormal) {
        return argNormal != null ? new StringBuilder().append(argNormal).reverse().toString()
                : null;
    }

    @Override
    public char[] convertToEntityAttribute(String argReversed) {
        return argReversed != null ? new StringBuilder().append(argReversed).reverse().toString().toCharArray()
                : null;
    }
}

Why String instead of char[]? It better suits to JDBC <-> DB text data types mapping.
On the background of em.refresh(entity); is SELECT and java.sql.ResultSet called
https://docs.oracle.com/en/java/javase/21/docs/api/java.sql/java/sql/ResultSet.html
and there no any getXXX() which return char[].
This is reason why public char[] convertToEntityAttribute(char[] argReversed) is not invoked, because it expect
public char[] convertToEntityAttribute(String argReversed) as DB + JDBC produce String.

[oramattkosem]

The proposed code is a hypothetical example, since I can't share the actual code, but the code in question deals with sensitive information that needs to be flushed from arrays once persisted. Strings cannot be flushed, since they are immutable, so we use char[] in cases like this. The PreparedStatement and ResultSet API methods dealing with Reader and Writer support this use case without a trip through String.

char[] is a standard supported type in JPA and we shouldn't really see a ClassCastException either way. Apart from this refresh() use case, char[] appears to behave correctly everywhere else.

[rfelcman]

Yes char[] is supported in JPA, but I'm speaking about data type fetched from DB by JDBC.
So You mentioned Reader and Writer and which data type is declared in the DB table? In this case maybe converter should be something like public char[] convertToEntityAttribute(java.io.Reader argReversed) {.

[oramattkosem]

At the database level, the fields are just varchar2 fields. Reader and Writer aren't types listed as supported by JPA, and I don't believe they could reasonably be used in entities either way given their unidirectional and single-use natures.

[rfelcman]

But JPA/EclipseLink depends on JDBC. By default DB varchar2 field is fetched by ResultSet.getString(). This is why I'm mentioning JDBC. DB/JDBC delivers it as a String. In my case Converter input from JPA side is char[] but from DB/JDBC is String. Converter is applied to values delivered by JDBC driver.

[oramattkosem]

What you're suggesting seems consistent with the Javadoc for converters. Our prior JPA implementation supports this, but we're hoping to switch to EclipseLink.

Given the circumstances, and the state of this in the JPA/JDBC APIs, what is the preferred course of action for storing sensitive information which needs to be cleansed from memory after use in this library? The AttributeConverter API doesn't support the reader/writer paradigm, given that the Y (dbData) parameter must be usable for reading and writing. The only logical choice for this field type seems to be char[], but this seems a bit contradictory to the Note that it is the responsibility of the converter writer to specify the correct dbData type for the corresponding column for use by the JDBC driver: i.e., persistence providers are not expected to do such type conversion. verbiage in the Javadoc.

[rfelcman]

I verified JDBC calls if there is any chance to set/get char[] directly from DB but I don't think, that is possible.
You can try attached code com.oracle.jpa.bugtest.TestBug#bugTestPureJDBCInsert() or com.oracle.jpa.bugtest.TestBug#bugTestPureJDBCSelect.
In case of EclipseLink You can take a look at https://github.com/eclipse-ee4j/eclipselink/pull/2004/files#diff-5f6f66f60c7c0f9a5c9754175e5f1b0a20f01c08961008c848d0c90415145ddf
https://github.com/eclipse-ee4j/eclipselink/blob/master/foundation/org.eclipse.persistence.core/src/main/java/org/eclipse/persistence/internal/security/SecurableObjectHolder.java as a some idea how we handle passwords in EclipseLink. Or use BLOB, CLOB mapping to use byte[]. But I think, that there is still some moment in every JPA implementation when String is used due a JDBC limitation.
jpa-bug-2096-AttributeConverterEntityManagerRefresh.tar.gz

[oramattkosem]

You lost me a little bit on that last one. The JPA specification suggests that all basic types other than Id, Temporal, and Enumerated should be supported for conversion. At the JDBC driver level, It is definitely possible to work directly in char to service this use case using the getCharacterStream/setCharacterStream methods. Ignoring the desire to clear the arrays after use, which JPA claims no support for, char[] to String conversions to satisfy the terms of the specification's support for basic types would at least allow the type to be usable.