New Recipe to use java.time api instead of @Temporal annotation

[FredMencier]

What's changed?

Add a new recipe to remove @Temporal annotation when using java.util.Date and convert type with java.time api

What's your motivation?

Prefer using java.time api in persistence layer

Anything in particular you'd like reviewers to focus on?

Maybe this recipe can be used not only in quarkus context

Anyone you would like to review specifically?

@timtebeek

Have you considered any alternatives or workarounds?

Yes, looking for existing recipe but not found

Any additional context

no

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

hi @FredMencier ; thanks for the contribution! I've polished up the implementation and tests a bit. Wondering mostly how you'd plan to handle any fall out from running this recipe, as changing the type in entity classes is likely to have knock on effects that would need further changes. Any thoughts you can share there?

[FredMencier]

Hi Tim, thanks for your review.
You are completely right. The idea is to use this recipe with another recipes to be able to change date type everywhere is needed. Another idea is to manually create an helper class to convert date between types after recipe run.
This recipe is a small unitary recipe to help us to use java.time api which is natively understood by persistence layer. We use it during our migration process and we always need to adapt manually propagated date type.
Do you think the recipe should be rethink to be able to change type everywhere it s needed in the project, not only on persistence layer ?

[timtebeek]

The idea is to use this recipe with another recipes to be able to change date type everywhere is needed. Another idea is to manually create an helper class to convert date between types after recipe run. This recipe is a small unitary recipe to help us to use java.time api which is natively understood by persistence layer. We use it during our migration process and we always need to adapt manually propagated date type. Do you think the recipe should be rethink to be able to change type everywhere it s needed in the project, not only on persistence layer ?

If we were to include it here I think indeed we should strive for a complete migration, as the context of manual work being needed might be lost on folks that stumble across this recipe. Such cascading type changes would require a scanning recipe, to first identify which types would be changed, and then from there make the necessary code changes (possibly using adapters) as needed.

If the recipe is already usable to you all in the current form then it's also fine not to contribute it just yet, and keep it internal. Happy to help review and think through the options even if we can't yet merge this with confidence here.

[github-actions]

This PR is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in two weeks. PRs may be reopened when there is renewed interest.