Re: Potential to include java.time.* as a default import for Groovy 5

+1

Comment: using CompilerConfiguration with a custom ImportCustomizer 
works but is only applicable to a GroovyShell or GroovyScriptEngine i 
create myself and @BaseScript is not really transparent. What would be 
really nice would be to be able to easily adjust default imports in 
groovy-starter.conf (and make $HOME/.groovy/conf/groovy-starter.conf 
take precedence of $GROOVY_HOME/conf/groovy-starter.conf). Creating a 
custom CompilationCustomizer, put it in a jar and load it in 
groovy-starter.conf is quite cumbersome imho.

Best regards,

Per

On 5/31/25 09:36, 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.