La prise en charge de la nouvelle API Date &Date avec JDBC est définie par JEP 170 :JDBC 4.2 . Postgres page de téléchargement la compatibilité avec les nouvelles fonctionnalités de JDBC 4.2 ne commence qu'à partir de la version 9.4 de Postgres, donc certains problèmes de compatibilité apparaîtront en utilisant la nouvelle API avec des pilotes plus anciens.
Même setObject(1, new java.util.Date()); est rejeté par la même contrainte dans Postgres (qui est heureusement acceptée par MySQL), pas seulement la nouvelle API comme LocalDate . Certains comportements dépendront de l'implémentation, donc seulement java.sql.* est pratiquement garanti (en gros).
En ce qui concerne le framework Spring JDBC, je pense que le remplacement de son comportement permet de le contourner sans le regretter plus tard. Je suggère une approche légèrement différente de ce que vous avez déjà fait :
- Étendre
BeanPropertySqlParameterSourcecomportement pour travailler avec la nouvelle API de date et d'heure, et d'autres classes associées à l'entrée de paramètres si nécessaire (je ne connais pas cette API Spring). - Extraire le comportement déjà remplacé de
BeanPropertyRowMapperà une autre classe pour les opérations de récupération. - Enveloppez le tout avec un modèle d'usine ou une classe utilitaire pour ne pas avoir à le regarder à nouveau.
De cette façon, vous améliorez les capacités de refactorisation futures si l'API est prise en charge et réduisez la quantité de code nécessaire pendant le développement.
Vous pouvez également consulter certains DAO approches.
