groovy-starter.conf support (especially for import deletes) would have my strong support. The Tuple imports do work fine; I was using them as another example of collisions with the auto-imported namespaces where I'd like a project-level delete.
On Mon, Jun 2, 2025, 06:32 Paul King <pa...@asert.com.au> wrote: > 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. > > > > > > >
