MG, just as for
> ... letting people define their own... I might be just missing something of importance or not getting properly what you mean here, but I'd say Groovy already supports defining our own “compound imports” pretty nicely; there are at the very least two ways I know of: - you can set up desired imports in a config script through an ImportCustomizer; - if not granular/convenient enough, you can fine-tune the required set of imports essentially without any limitation through ASTTs and the ModuleNode APIs. All the best, OC > On 1. 6. 2025, at 22:47, 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. >> >> >
