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