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.
