Skip to content

add @Convert(to = ....class)#819

Draft
gavinking wants to merge 5 commits into
jakartaee:mainfrom
gavinking:convert-to
Draft

add @Convert(to = ....class)#819
gavinking wants to merge 5 commits into
jakartaee:mainfrom
gavinking:convert-to

Conversation

@gavinking

Copy link
Copy Markdown
Member

see #619

@gavinking gavinking changed the base branch from master to main December 15, 2025 19:57
@gavinking gavinking changed the title add @Covert(to = ....class) add @Convert(to = ....class) Dec 16, 2025
@gavinking gavinking added the candidate-for-4 Good candidate for JPA 4 label Dec 18, 2025
Comment thread api/src/main/java/jakarta/persistence/Convert.java
Comment thread api/src/main/java/jakarta/persistence/Convert.java Outdated
*
* @since 4.0
*/
Class<?> to() default void.class;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if something like as() wouldn't be less confusing here... because this is fundamentally not a one-way conversion.

But then as is a keyword in Groovy, so there's that.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if it were @Persist or @Treat then as would be better. But "convert as string" isn't grammatically correct.

gavinking and others added 3 commits January 14, 2026 21:25
@gavinking

Copy link
Copy Markdown
Member Author

If we're going to touch this stuff, we should take the opportunity to bless the use of @Convert as a meta-annotation, as discussed in #43.

@gavinking

Copy link
Copy Markdown
Member Author

@sebersole Are you in favor of doing this one in JPA4?

Or should we put it on ice for reconsideration as part of 4.1, where we're already considering other longstanding enhancements to converters (composite converters #105, and @Convert as a meta-annotation #73)?

@sebersole

Copy link
Copy Markdown
Contributor

Like we discussed in chat, I'd be inclined to (also?) expose this on @Column. E.g.

@Column(type=String.class)
UUID uuid;

Which, granted, implies some level of implicit conversion. But you already called that out, and I don't think needs to be a huge set for the spec itself - providers could ofc provide extended set of conversions if they wish

@gavinking

Copy link
Copy Markdown
Member Author

Yeah so I'm trying to think this through.

  • There's something appealing about putting it on @Column because it really is just the column type you're specifying, and to the extend that there's a converter, it's entirely implicit and theoretical.
  • On the other hand, it feels at least a bit strange to me to be specifying a column type as a Java type., and I feel like this sorta pushes me back in the direction of the place I actually started out at which was @Column(jdbcType=Types.BIGINT).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

candidate-for-4 Good candidate for JPA 4

Projects

None yet

Development

Successfully merging this pull request may close these issues.

consider adding JDBC type to @Column or a zoo of built-in AttributeConverters

3 participants