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 <joew...@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 <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. >>> >>>
