+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.
