You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Paul King <pa...@asert.com.au> on 2025/05/31 07:36:51 UTC
Potential to include java.time.* as a default import for Groovy 5
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.
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Paul King <pa...@asert.com.au>.
This would be the kind of thing that we could support with
ImportCustomizer by adding delete functionality. We don't currently
support that. Or by allowing default imports to be specified as part
of groovy-starter.conf. If we did have a mechanism, it would need to
be discoverable from IDEs too. They already have hooks for those two
mechanisms. That is outside the scope of this proposal.
Vavr's tuples should be fine to use by appropriate imports.
Cheers,
Paul.
On Sat, May 31, 2025 at 11:56 PM Christopher Smith
<ch...@gmail.com> wrote:
>
> Would it be feasible to have a project-level configuration akin to lombok.config that could be used to un-auto-import packages (classes would be even better, but I think this conflicts with the internal compiler representation of the auto-imports). I would personally like java.time included, but I use Vavr's Tuple types.
>
> Christopher Smith
>
> On Sat, May 31, 2025, 08:35 Joe Wolf <jo...@gmail.com> wrote:
>>
>> +1
>>
>> From a class-centric perspective, if Date is available by default, LocalDate et. al. should also be available.
>>
>>
>> On Sat, May 31, 2025, 7:48 AM James Daugherty <jd...@jdresources.net> wrote:
>>>
>>> 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 <se...@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.
>>>>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Christopher Smith <ch...@gmail.com>.
Would it be feasible to have a project-level configuration akin to
lombok.config that could be used to un-auto-import packages (classes would
be even better, but I think this conflicts with the internal compiler
representation of the auto-imports). I would personally like java.time
included, but I use Vavr's Tuple types.
Christopher Smith
On Sat, May 31, 2025, 08:35 Joe Wolf <jo...@gmail.com> wrote:
> +1
>
> From a class-centric perspective, if Date is available by default,
> LocalDate et. al. should also be available.
>
> On Sat, May 31, 2025, 7:48 AM James Daugherty <jd...@jdresources.net>
> wrote:
>
>> 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 <se...@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.
>>>
>>>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Christopher Smith <ch...@gmail.com>.
Would it be feasible to have a project-level configuration akin to
lombok.config that could be used to un-auto-import packages (classes would
be even better, but I think this conflicts with the internal compiler
representation of the auto-imports). I would personally like java.time
included, but I use Vavr's Tuple types.
Christopher Smith
On Sat, May 31, 2025, 08:35 Joe Wolf <jo...@gmail.com> wrote:
> +1
>
> From a class-centric perspective, if Date is available by default,
> LocalDate et. al. should also be available.
>
> On Sat, May 31, 2025, 7:48 AM James Daugherty <jd...@jdresources.net>
> wrote:
>
>> 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 <se...@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.
>>>
>>>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Joe Wolf <jo...@gmail.com>.
+1
From a class-centric perspective, if Date is available by default,
LocalDate et. al. should also be available.
On Sat, May 31, 2025, 7:48 AM James Daugherty <jd...@jdresources.net>
wrote:
> 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 <se...@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.
>>
>>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Paul King <pa...@asert.com.au>.
On Sat, May 31, 2025 at 9:48 PM James Daugherty
<jd...@jdresources.net> wrote:
>
> Hi Paul,
>
> Is the proposal to do this for 5.x or earlier?
5.0+
> -James
>
> On Sat, May 31, 2025 at 6:25 AM Sergio del Amo <se...@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.
>>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Joe Wolf <jo...@gmail.com>.
+1
From a class-centric perspective, if Date is available by default,
LocalDate et. al. should also be available.
On Sat, May 31, 2025, 7:48 AM James Daugherty <jd...@jdresources.net>
wrote:
> 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 <se...@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.
>>
>>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by James Daugherty <jd...@jdresources.net>.
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 <se...@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.
>
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by James Daugherty <jd...@jdresources.net>.
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 <se...@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.
>
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Sergio del Amo <se...@softamo.com>.
+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.
RE: Potential to include java.time.* as a default import for Groovy 5
Posted by Merlin Beedell <MB...@cryoserver.com>.
It would be useful to be able to provide an alias name for each import to avoid clashes with other libraries. So, java.time.* could be aliased down to 'jt'. Then you would need to prefix each use with jt (e.g. jt.Duration.ofHours(3) )
Could that be a groovy thing?
https://www.reddit.com/r/java/comments/10jfba1/how_to_request_new_java_features_like_import_alias/
Merlin Beedell
-----Original Message-----
From: Paul King <pa...@asert.com.au>
Sent: 02 June 2025 12:13
To: users@groovy.apache.org
Subject: Re: Potential to include java.time.* as a default import for Groovy 5
We aren't likely to add "@NoAutoImports or @NoExtendedImports"
annotations. The ImportCustomizer is fairly feature rich and is the recommended way to add imports for folks that want them. It doesn't provide a way to remove default imports at present, but it is more likely a place we'd consider enhancing in that way. We don't normally add to the default imports, the java.time case just seems a standout case for us to consider.
On Sun, Jun 1, 2025 at 12:21 AM <to...@natusoft.se> wrote:
>
> I'm a big fan of the Groovy language and more default imports are nice. May I suggest a @NoAutoImports or @NoExtendedImports annotation that will disable those for the source files the annotation is in when not wanted due to conflicts ?
>
> /Tommy Svensson
> On 31 May 2025 at 09:43 +0200, 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.
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Paul King <pa...@asert.com.au>.
We aren't likely to add "@NoAutoImports or @NoExtendedImports"
annotations. The ImportCustomizer is fairly feature rich and is the
recommended way to add imports for folks that want them. It doesn't
provide a way to remove default imports at present, but it is more
likely a place we'd consider enhancing in that way. We don't normally
add to the default imports, the java.time case just seems a standout
case for us to consider.
On Sun, Jun 1, 2025 at 12:21 AM <to...@natusoft.se> wrote:
>
> I'm a big fan of the Groovy language and more default imports are nice. May I suggest a @NoAutoImports or @NoExtendedImports annotation that will disable those for the source files the annotation is in when not wanted due to conflicts ?
>
> /Tommy Svensson
> On 31 May 2025 at 09:43 +0200, 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.
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by to...@natusoft.se.
I'm a big fan of the Groovy language and more default imports are nice. May I suggest a @NoAutoImports or @NoExtendedImports annotation that will disable those for the source files the annotation is in when not wanted due to conflicts ?
/Tommy Svensson
On 31 May 2025 at 09:43 +0200, 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.
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Scott Murphy Heiberg <sc...@apache.org>.
+1
This issue is really important to be me because I have written *a lot* of short Groovy scripts that do date manipulation. I had to continue using the Date class to avoid imports bogging down the script.
There is also a strong need for this for an easy migration of Grails domain classes that utilize the Date class. Currently I had to introduce a workaround via a config script, but this approach is not compiler friendly. This will allow the elimination of the config script and true compiler support.
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Remko Popma <re...@gmail.com>.
+1
On Sun, Jun 1, 2025 at 6:30 AM Gianluca Sartori <g....@gmail.com> wrote:
> +1
>
> Gianluca Sartori
> --
> https://dueuno.com
>
> On Sat, 31 May 2025 at 09:37, 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.
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Remko Popma <re...@gmail.com>.
+1
On Sun, Jun 1, 2025 at 6:30 AM Gianluca Sartori <g....@gmail.com> wrote:
> +1
>
> Gianluca Sartori
> --
> https://dueuno.com
>
> On Sat, 31 May 2025 at 09:37, 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.
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Gianluca Sartori <g....@gmail.com>.
+1
Gianluca Sartori
--
https://dueuno.com
On Sat, 31 May 2025 at 09:37, 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.
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Paul King <pa...@asert.com.au>.
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 <su...@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.
> >
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Daniel Sun <su...@apache.org>.
-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.
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Guillaume Laforge <gl...@gmail.com>.
I'd love to have java.time as a default import!
It's interesting you post this today, as just yesterday, I was writing a
Groovy script, using java.time, and somehow forgot that it wasn't already a
default.
Of course, I got an error, and immediately understood that I should have
imported the java.time class I needed, but I also thought, hey, that would
be nice to have it as a default!
On Sat, May 31, 2025 at 9:37 AM 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.
>
--
*Guillaume Laforge*
Apache Groovy committer
Developer Advocate @ Google Cloud <https://cloud.google.com/>
- Blog: glaforge.dev
- X: @glaforge <http://twitter.com/glaforge>
- Bluesky: @glaforge.dev <https://bsky.app/profile/glaforge.dev>
- Mastodon: @glaforge@uwyn.net <http://%40glaforge@uwyn.net/>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Sergio del Amo <se...@softamo.com>.
+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.
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Per Nyfelt <pe...@alipsa.se>.
+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.
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Guillaume Laforge <gl...@gmail.com>.
I'd love to have java.time as a default import!
It's interesting you post this today, as just yesterday, I was writing a
Groovy script, using java.time, and somehow forgot that it wasn't already a
default.
Of course, I got an error, and immediately understood that I should have
imported the java.time class I needed, but I also thought, hey, that would
be nice to have it as a default!
On Sat, May 31, 2025 at 9:37 AM 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.
>
--
*Guillaume Laforge*
Apache Groovy committer
Developer Advocate @ Google Cloud <https://cloud.google.com/>
- Blog: glaforge.dev
- X: @glaforge <http://twitter.com/glaforge>
- Bluesky: @glaforge.dev <https://bsky.app/profile/glaforge.dev>
- Mastodon: @glaforge@uwyn.net <http://%40glaforge@uwyn.net/>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by OCsite <oc...@ocs.cz>.
MG,
just as for
> ... letting people define their own...
I might be just missing something of importance or not getting properly what you mean here, but I'd say Groovy already supports defining our own “compound imports” pretty nicely; there are at the very least two ways I know of:
- you can set up desired imports in a config script through an ImportCustomizer;
- if not granular/convenient enough, you can fine-tune the required set of imports essentially without any limitation through ASTTs and the ModuleNode APIs.
All the best,
OC
> On 1. 6. 2025, at 22:47, MG <mg...@arscreat.com> wrote:
> I think the idea is, that if the older java.util.Date family of classes gets auto-imported, then its newer counterpart should also be, which makes sense to me.
> (As I understood it, java.time.format & java.time.temporal would be auto-imported under the proposal (?))
> I do however see the problem of where to draw the line with regards to other often used java.* packages (not related to the date-time domain).
> Perhaps instead of auto importing more and more packages, Groovy could:
> Issue a special kind of error if a script does not compile and it finds class names that match ones from well known / often used Java packages.
> The error message could include the required import statements ready to copy into the script, if the user so chooses.
> That would evidently not solve the "single line Groovy script" case, but how many people actually use Groovy that way... ?
> Single-line usage is always very limited in any case.
> Support "compound imports", analogue to existing AnnotationCollector for annotations.
> e.g.:
> import all java // all but the most obscure Java libs
> import all java_core // all often used Java libs
> import all datetime // all DateTime related libs
> import all text // all text realted libs
> etc
> Groovy then could come with some predefined "compound imports" like in the examples given above, as well as letting people define their own...
> Cheers,
> mg
>
>
> Am 01.06.2025 um 14:56 schrieb Alexander Veit via users:
>> Am 31.05.25 um 09:36 schrieb Paul King:
>>> 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
>>
>> I would vote against this proposal. Here are some arguments why:
>>
>> First of all, I'm generally not in favor of adding more default default imports to the language, since I suspect negative impacts on maintainability of scripts and the efficiency of the compilation process.
>>
>> Apart from Instance, LocalDateTime and ZonedDateTime most of the classes in java.time are probably rarely used. Does this justify to add 16 extra classes?
>>
>> The classes in java.time are not fully usable without classes from other packages like java.time.format or java.time.temporal which should then also be default imports.
>>
>>> There are many good points about including such a star import
>>
>> This argument also holds for other packages like java.nio.* or java.text.
>>
>>
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Christopher Smith <ch...@gmail.com>.
groovy-starter.conf support (especially for import deletes) would have my
strong support. The Tuple imports do work fine; I was using them as another
example of collisions with the auto-imported namespaces where I'd like a
project-level delete.
On Mon, Jun 2, 2025, 06:32 Paul King <pa...@asert.com.au> wrote:
> The current proposal doesn't extend to the format and temporal
> subpackages. With just the java.time classes and Groovy's datetime
> extensions, you can go a long way. If you want all the bells and
> whistles, then you'll need to import some classes/packages.
>
> While it is outside the scope of this proposal, it would be
> interesting to consider whether a custom type checker could be used
> with CompileStatic to auto-import what looked like known classes.
>
> Cheers, Paul.
>
> On Mon, Jun 2, 2025 at 6:47 AM MG <mg...@arscreat.com> wrote:
> >
> >
> >
> > I think the idea is, that if the older java.util.Date family of classes
> gets auto-imported, then its newer counterpart should also be, which makes
> sense to me.
> >
> > (As I understood it, java.time.format & java.time.temporal would be
> auto-imported under the proposal (?))
> >
> > I do however see the problem of where to draw the line with regards to
> other often used java.* packages (not related to the date-time domain).
> >
> > Perhaps instead of auto importing more and more packages, Groovy could:
> >
> > Issue a special kind of error if a script does not compile and it finds
> class names that match ones from well known / often used Java packages.
> >
> > The error message could include the required import statements ready to
> copy into the script, if the user so chooses.
> >
> > That would evidently not solve the "single line Groovy script" case, but
> how many people actually use Groovy that way... ?
> > Single-line usage is always very limited in any case.
> >
> > Support "compound imports", analogue to existing AnnotationCollector for
> annotations.
> >
> > e.g.:
> >
> > import all java // all but the most obscure Java libs
> > import all java_core // all often used Java libs
> > import all datetime // all DateTime related libs
> > import all text // all text realted libs
> > etc
> >
> > Groovy then could come with some predefined "compound imports" like in
> the examples given above, as well as letting people define their own...
> >
> > Cheers,
> > mg
> >
> >
> > Am 01.06.2025 um 14:56 schrieb Alexander Veit via users:
> >
> > Am 31.05.25 um 09:36 schrieb Paul King:
> >
> > 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
> >
> >
> > I would vote against this proposal. Here are some arguments why:
> >
> > First of all, I'm generally not in favor of adding more default default
> imports to the language, since I suspect negative impacts on
> maintainability of scripts and the efficiency of the compilation process.
> >
> > Apart from Instance, LocalDateTime and ZonedDateTime most of the classes
> in java.time are probably rarely used. Does this justify to add 16 extra
> classes?
> >
> > The classes in java.time are not fully usable without classes from other
> packages like java.time.format or java.time.temporal which should then also
> be default imports.
> >
> > There are many good points about including such a star import
> >
> >
> > This argument also holds for other packages like java.nio.* or java.text.
> >
> >
> >
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Jochen Theodorou <bl...@gmx.org>.
I have a few points to mention here:
(1) we could consider, and that is combined with some danger, to import
specific classes only. import foo.bar.X does not have the same problem
as import foo.bar.* for the performance of the compiler. The danger of
course is that if X is no longer there, it would fail compilation even.
(2) I was wondering if we should copy a feature from python here and
allow for something like:
import package java.util as u
assert u.List == java.util.List
we already have class aliases, this would kind of complete the picture.
(3) and this is building on top of (2) and a bit on (1)... let me call
them virtual packages:
import package groovy.vp.calendar as CAL
def calendar = new CAL.Calendar.Builder()
.set(CAL.Calendar.DAY_OF_MONTH, 11)
.set(CAL.Calendar.MONTH, Calendar.JULY)
.set(CAL.Calendar.YEAR, 2022)
.set(CAL.Calendar.HOUR, 8)
.set(CAL.Calendar.MINUTE, 30)
.set(CAL.Calendar.SECOND, 00)
.build()
def simpleDateFormat = new CAL.SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
println(simpleDateFormat.format(calendar.getTime()));
the idea is to have some container for classes, that is bound by
feature, not by package structure. In this case SimpleDateFormat and
Calender are both in the package groovy.vp.calendar, which is no real
package and only contains the information that Calender is from
java.util.Calender and SimpleDateFormat from java.format.SimpleDateFormat
Then you can have tailored packages like nio, nio2, collections, ...
(4) ha, so many crazy suggestions you think and you think I could not
put one more on top? Wrong:
import groovy.vp.calendar.*
Now this is basically importing all classes from my virtual calendar
package, namely Calendar and SimpleDateFormat.
Something general about class resolving...
I think I have to explain a bit about class resolving in Groovy in
general. In the old times java was more dynamic than it was today. Back
then You could have a jar X and a jar Y and both could declare classes
in the same package. Practically this means if I import foo.* and do
println Foo. I have to go through all class path elements and check if
they define a package foo and if the package foo contains a class Foo -
for each star import of course. And since it might be one time jar X and
one time jar Y during compilation, heck both could define the class...
it could be jar Z at runtime.
This is why in Groovy - which follows the tradition - additional star
imports are expensive: # vanilla names * # classpath elements * # star
imports. Only the situation is worse in Groovy since we decided to make
classes and variables share the namespace. println foo could mean the
class foo and we have to so maybe a 1000 search operations or a dynamic
variable foo. Which is why lower case class names are not valid in
Groovy anymore.
Ah yes. A import of a class full name would be resolved with this cost:
# classpath elements. Which is significantly lower.
In newer Java versions one package can only reside in one jar. It does
no longer allow these things on the module path and the class path then
stays empty. Also they imply that module path at compile time equals
module path at runtime, so there are no classloader shenanigans to
consider. No the compiler can take all module path elements and make a
big map (vanilla name -> full class name | Error) once and resolve all
vanilla names in one go. Or you could see it as if the java compiler
replace java.util.* with full name imports from java.util, like
java.util.List.
My suggestion (1) goes in the same direction and with (4) building on
top of that you get a similar version with similar performance and
without relying on the module system.
bye Jochen
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Paul King <pa...@asert.com.au>.
The current proposal doesn't extend to the format and temporal
subpackages. With just the java.time classes and Groovy's datetime
extensions, you can go a long way. If you want all the bells and
whistles, then you'll need to import some classes/packages.
While it is outside the scope of this proposal, it would be
interesting to consider whether a custom type checker could be used
with CompileStatic to auto-import what looked like known classes.
Cheers, Paul.
On Mon, Jun 2, 2025 at 6:47 AM MG <mg...@arscreat.com> wrote:
>
>
>
> I think the idea is, that if the older java.util.Date family of classes gets auto-imported, then its newer counterpart should also be, which makes sense to me.
>
> (As I understood it, java.time.format & java.time.temporal would be auto-imported under the proposal (?))
>
> I do however see the problem of where to draw the line with regards to other often used java.* packages (not related to the date-time domain).
>
> Perhaps instead of auto importing more and more packages, Groovy could:
>
> Issue a special kind of error if a script does not compile and it finds class names that match ones from well known / often used Java packages.
>
> The error message could include the required import statements ready to copy into the script, if the user so chooses.
>
> That would evidently not solve the "single line Groovy script" case, but how many people actually use Groovy that way... ?
> Single-line usage is always very limited in any case.
>
> Support "compound imports", analogue to existing AnnotationCollector for annotations.
>
> e.g.:
>
> import all java // all but the most obscure Java libs
> import all java_core // all often used Java libs
> import all datetime // all DateTime related libs
> import all text // all text realted libs
> etc
>
> Groovy then could come with some predefined "compound imports" like in the examples given above, as well as letting people define their own...
>
> Cheers,
> mg
>
>
> Am 01.06.2025 um 14:56 schrieb Alexander Veit via users:
>
> Am 31.05.25 um 09:36 schrieb Paul King:
>
> 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
>
>
> I would vote against this proposal. Here are some arguments why:
>
> First of all, I'm generally not in favor of adding more default default imports to the language, since I suspect negative impacts on maintainability of scripts and the efficiency of the compilation process.
>
> Apart from Instance, LocalDateTime and ZonedDateTime most of the classes in java.time are probably rarely used. Does this justify to add 16 extra classes?
>
> The classes in java.time are not fully usable without classes from other packages like java.time.format or java.time.temporal which should then also be default imports.
>
> There are many good points about including such a star import
>
>
> This argument also holds for other packages like java.nio.* or java.text.
>
>
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by MG <mg...@arscreat.com>.
1. I think the idea is, that if the older java.util.Date family of
classes gets auto-imported, then its newer counterpart should also
be, which makes sense to me.
1. (As I understood it, java.time.format & java.time.temporal
would be auto-imported under the proposal (?))
2. I do however see the problem of where to draw the line with regards
to other often used java.* packages (not related to the date-time
domain).
1. Perhaps instead of auto importing more and more packages, Groovy
could:
1. Issue a special kind of error if a script does not compile
and it finds class names that match ones from well known /
often used Java packages.
1. The error message could include the required import
statements ready to copy into the script, if the user so
chooses.
1. That would evidently not solve the "single line
Groovy script" case, but how many people actually
use Groovy that way... ?
2. Single-line usage is always very limited in any case.
2. Support "compound imports", analogue to existing
AnnotationCollector for annotations.
1. e.g.:
1. import all java // all but the most obscure Java
libs
2. import all java_core // all often used Java libs
3. import all datetime // all DateTime related libs
4. import all text // all text realted libs
5. etc
3. Groovy then could come with some predefined "compound
imports" like in the examples given above, as well as
letting people define their own...
Cheers,
mg
Am 01.06.2025 um 14:56 schrieb Alexander Veit via users:
> Am 31.05.25 um 09:36 schrieb Paul King:
>> 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
>
> I would vote against this proposal. Here are some arguments why:
>
> First of all, I'm generally not in favor of adding more default
> default imports to the language, since I suspect negative impacts on
> maintainability of scripts and the efficiency of the compilation process.
>
> Apart from Instance, LocalDateTime and ZonedDateTime most of the
> classes in java.time are probably rarely used. Does this justify to
> add 16 extra classes?
>
> The classes in java.time are not fully usable without classes from
> other packages like java.time.format or java.time.temporal which
> should then also be default imports.
>
>> There are many good points about including such a star import
>
> This argument also holds for other packages like java.nio.* or java.text.
>
>
Re: Potential to include java.time.* as a default import for Groovy 5
Posted by Alexander Veit via users <us...@groovy.apache.org>.
Am 31.05.25 um 09:36 schrieb Paul King:
> 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
I would vote against this proposal. Here are some arguments why:
First of all, I'm generally not in favor of adding more default default imports to the language, since I suspect negative impacts on maintainability of scripts and the efficiency of the compilation process.
Apart from Instance, LocalDateTime and ZonedDateTime most of the classes in java.time are probably rarely used. Does this justify to add 16 extra classes?
The classes in java.time are not fully usable without classes from other packages like java.time.format or java.time.temporal which should then also be default imports.
> There are many good points about including such a star import
This argument also holds for other packages like java.nio.* or java.text.
--
Cheers, Alex