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 <chrylis+gro...@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 <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. >>>>
