Почему JPA не поддерживает java.time.Instant?

Я попробую это снова. В этой проблеме есть обсуждение. Последнее обсуждение выглядит следующим образом:

mkarg сказал: Хотя это абсолютно правильно, технический ответ немного сложнее: какой последний предикат делает тип данных пригодным для включения в набор обязательных сопоставлений типов?

Можно было бы сказать, что этот предикат — «существенный» или «общеупотребительный», но кто определяет, что такое «существенный» или «общеупотребительный»? Видите ли, для некоторых приложений поддержка java.awt.Image и java.net.URL может быть гораздо важнее, чем поддержка LocalDate или ZonedDateTime. С другой стороны, другие приложения могут быть заполнены LocalDate, но никогда не использовать Instant. Так где именно делать разрез? Это становится особенно сложным, если посмотреть на огромное количество типов, найденных в JRE, и становится очевидным, что где-то должен быть вырез. Даже JavaFX, который связан с JRE, не поддерживает Instant еще в v8, так зачем JPA? И, глядя на текущий прогресс Project Jigsaw, возможно, на определяющий предикат можно просто ответить «все типы в конкретном модуле головоломки»?

В любом случае решать не мне. Я поддерживаю ваш запрос и хотел бы видеть поддержку для всех времен API Java Time, особенно для Instant и Duration, и у вашего запроса есть известные сторонники, такие как, например, Java Champion Арун Гупа, как я узнал недавно. Но я сомневаюсь, что окончательный ответ будет таким же простым и удовлетворительным, как нам бы хотелось его получить.

Возможно, было бы лучше просто настроить другой JSR, например «Общие преобразования типов данных для платформы Java», который обеспечивает гораздо больше сопоставлений, чем просто дата и время, но также не будет привязан к JPA, но также может использоваться JAXB , JAX-RS и, возможно, другие API, которые решают проблему преобразования "в"? Наличие такого транспортного средства действительно значительно уменьшит количество шаблонов.

TL-DR; Есть много типов. Нам нужно было где-то провести черту.

Существует новая проблема, которая будет добавлена ​​в будущую версию JPA. .

Еще один интересный фрагмент анализа, который я нашел в ветке от Douglas Surber (работает на JDBC):

Версия JDK 8 JDBC включает поддержку большинства типов SQL, соответствующих классам 310.

• ДАТА – местная дата
• ВРЕМЯ – местное время
• TIMESTAMP БЕЗ ЧАСОВОГО ПОЯСА — LocalDateTime
• TIMESTAMP С ЧАСОВЫМ ПОЯСОМ – OffsetDateTime

Версия JDK 8 JDBC не включает сопоставление между типами INTERVAL и соответствующими классами 310.

Не существует типа SQL, точно соответствующего любому другому классу 310. В результате спецификация JDBC ничего не говорит обо всех остальных классах.

Я бы настоятельно рекомендовал разработчикам JDBC использовать новые классы 310. Существуют проблемы с java.util.Date, java.sql.Date, java.sql.Time и java.sql.Timestamp. Вы должны считать их устаревшими. Классы 310 намного лучше.

Дуглас

TL:DR; Мы только что выбрали один тип Java 8 для каждого из 4 возможных способов хранения временных данных в базе данных.

Наконец, если вы прочитаете эту thread похоже, существует значительное культурное давление, чтобы стандартные API были маленькими и простыми.

Это не проблема JPA, а проблема JDBC.

JDBC поддерживает Date, Timestamp, LocalDate, LocalTime и LocalDateTime, но НЕ Instant.

Это не проблема Java, а проблема SQL, из-за которой в базе данных хранится конструкция год-месяц-день-час-минута-секунда.

Подумайте о функциях SQL: ГОД() МЕСЯЦ() и т.д...

Эти функции нельзя применять к простым миллисенкодам с номера 1970. Для выполнения этих функций им требуется конструкция LocalDateTime.