[
https://issues.apache.org/jira/browse/GROOVY-11513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17946892#comment-17946892
]
ASF GitHub Bot commented on GROOVY-11513:
-----------------------------------------
codeconsole commented on PR #2156:
URL: https://github.com/apache/groovy/pull/2156#issuecomment-2825914773
Well, I have found, as is, unintentionally encourages deprecated behavior in
domain classes due to the added complexity of having to add imports in view
layers. Even in standalone applications and scripts, I find a bias to utilizing
Date over LocalDate to avoid having to add redundant imports.
It just seems logical to automatically support modern Data/Time usage by
importing the java.time package. Working with Date's is such a common task,
not having comparable support for LocalDate and LocalDateTime can be very
limiting.
> java.time.* should be imported automatically
> --------------------------------------------
>
> Key: GROOVY-11513
> URL: https://issues.apache.org/jira/browse/GROOVY-11513
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
> Affects Versions: 4.0.23
> Reporter: Scott Murphy Heiberg
> Assignee: Eric Milles
> Priority: Major
> Labels: breaking
>
> if java.time is the recommended way to proceed forward when dealing with
> dates,
> java.time.* should be included automatically similar to how java.util.Date is
> currently available without import.
> The preferred approach would be to make it a global import which would be in
> line with existing Groovy handling of java.util.Date
>
> The least invasive approach would be to make the import only apply if
> groovy-datetime module has been added.
>
> implementation "org.apache.groovy:groovy-datetime"
>
> should automatically import java.time.* to all classes
>
> This provides an easier migration path from Date -> DateTIme
> [https://groovy.apache.org/blog/groovy-dates-and-times-cheat]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
