Hi Paul,

Is the proposal to do this for 5.x or earlier?

-James

On Sat, May 31, 2025 at 6:25 AM Sergio del Amo <sergio.del...@softamo.com>
wrote:

> +1 from me.
>
> Although I have fallen into Groovy's @Singleton vs Jakarta @Singleon
> pitfall, given that `java.time` classes are strongly recommended, I think
> this change is positive.
>
> > On 31 May 2025, at 09:36, Paul King <pa...@asert.com.au> 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.
>
>

Reply via email to