[
https://issues.apache.org/jira/browse/GROOVY-11513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17946584#comment-17946584
]
ASF GitHub Bot commented on GROOVY-11513:
-----------------------------------------
paulk-asert commented on PR #2156:
URL: https://github.com/apache/groovy/pull/2156#issuecomment-2822890969
In general, it is domain classes that have the same name as the java.time
classes and no package that catch us out.
E.g. for a `Main.groovy` file containing `println Period.ZERO` and a project
containing this top-level class:
```
class Period {
public static final ZERO = 'Nothing to see here'
}
```
Running `Main` currently outputs:
> Nothing to see here
But after this change will output (toString for java.time.Period#ZERO):
> P0D
I don't believe there is a problem for classes with a package since classes
in the same package and references via existing imports would come before the
default imports.
The other potentially problematic cases would be existing classes that are
currently picked up by e.g. the groovy.util.* default import that might now
come after java.time.*, but groovy.time.Duration (for instance) isn't a default
import, so I believe we are good there. If folks have not followed split
packaging naming conventions and have gone and created their own groovy.util
packaged classes, maybe wrapping joda time or some such, with names like Month,
Year, etc., they would be impacted. We don't prohibit that in the compiler
currently but I would think it rare and maybe something we wouldn't care
strongly about.
> 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)
