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.