I think the argument is that for small scripts (think replacing shell scripts) and domain classes, @CompileStatic and @CompileDynamic are seldom used, but dates often are.
I am overall in favor of making it easier to use those classes. I think we have some more options to explore though with the possibility of adding support via a groovy-starter.conf file or having some kind of meta information in a jar to add to the default imports if a particular jar is added to the classpath like we currently do for runners. Paul. On Tue, Jun 10, 2025 at 12:33 PM Daniel Sun <sun...@apache.org> wrote: > > -0 from me. > > `@CompileStatic` and `@CompileDynamic` are used more frequently than the > classes in the java.time package. > > Why not add them as well? > > Cheers, > Daniel Sun > > On 2025/05/31 07:36:51 Paul King wrote: > > Hi folks, > > > > We have a feature request, and potential PR, to add java.time.* as a > > new default import: > > > > https://issues.apache.org/jira/browse/GROOVY-11513 > > https://github.com/apache/groovy/pull/2156 > > > > There are many good points about including such a star import but also > > some drawbacks, so we'd like to gauge community feedback to understand > > interest in having such a feature. > > > > First the good points: Groovy is known for allowing short scripts that > > can do date manipulation, e.g. as one example: > > > > groovy -e "println 'Days left this year: ' + (365 - Calendar.instance[6])" > > > > Such one-liners become much longer if you have to do all the imports > > which are required for the java.time classes even though they have > > been the preferred ones to use for many years. > > > > Similarly, many domain classes in frameworks like Grails are often > > composed from fields with simple types like strings, numbers, > > booleans, and dates, or lists thereof. Many of these don't require > > imports but java.time variants do. > > > > You may not write many one-liners or Grails domain classes, but > > perhaps you write Gradle scripts. Again, many things don't need > > imports but java.time classes would. > > > > So, having java.time imported automatically would be a good way to > > promote the more robust java.time classes over the legacy equivalents > > in a range of different scenarios. > > > > What are the downsides? > > > > Well, we have received feedback in the past that having too many > > default imports can cause trouble. As just one example, there are > > numerous frameworks/libraries that have a @Singleton annotation, and > > the fact that Groovy's @Singleton is automatically imported is a cause > > of temporary pain for folks that forget to import their framework's > > version of that annotation. > > > > It is also a breaking change for anyone who has already created domain > > classes in the default package that clash with the java.time classes. > > This list includes the following classes: > > > > Clock > > Duration > > Instant > > LocalDate > > LocalDateTime > > LocalTime > > MonthDay > > OffsetDateTime > > OffsetTime > > Period > > Year > > YearMonth > > ZonedDateTime > > ZoneId > > ZoneOffset > > DayOfWeek > > Month > > DateTimeException > > > > If folks have classes with those names in other packages, they are not > > affected since existing imports in a source file are always before the > > default ones. > > > > Let us know what you think. > > > > Cheers, Paul. > >
