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