I think the argument is that for small scripts (think replacing shell
scripts) and domain classes, @CompileStatic and @CompileDynamic are
seldom used, but dates often are.
I am overall in favor of making it easier to use those classes. I
think we have some more options to explore though with the p
-0 from me.
`@CompileStatic` and `@CompileDynamic` are used more frequently than the
classes in the java.time package.
Why not add them as well?
Cheers,
Daniel Sun
On 2025/05/31 07:36:51 Paul King wrote:
> Hi folks,
>
> We have a feature request, and potential PR, to add java.time.* as a
> n
I have a few points to mention here:
(1) we could consider, and that is combined with some danger, to import
specific classes only. import foo.bar.X does not have the same problem
as import foo.bar.* for the performance of the compiler. The danger of
course is that if X is no longer there, it
com/r/java/comments/10jfba1/how_to_request_new_java_features_like_import_alias/
Merlin Beedell
-Original Message-
From: Paul King
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'
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 wrote:
> The c
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 propo
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. The
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 enha
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 ca
1. 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.
1. (As I understood it, java.time.format & java.time.temporal
would be auto-imported under the proposal (?))
2. I do
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
+1
On Sun, Jun 1, 2025 at 6:30 AM Gianluca Sartori wrote:
> +1
>
> Gianluca Sartori
> --
> https://dueuno.com
>
> On Sat, 31 May 2025 at 09:37, Paul King wrote:
> >
> > Hi folks,
> >
> > We have a feature request, and potential PR, to add java.time.* as a
> > new default import:
> >
> > https:/
+1
Comment: using CompilerConfiguration with a custom ImportCustomizer
works but is only applicable to a GroovyShell or GroovyScriptEngine i
create myself and @BaseScript is not really transparent. What would be
really nice would be to be able to easily adjust default imports in
groovy-starte
+1
This issue is really important to be me because I have written *a lot* of short
Groovy scripts that do date manipulation. I had to continue using the Date
class to avoid imports bogging down the script.
There is also a strong need for this for an easy migration of Grails domain
classes that
On Sat, May 31, 2025 at 9:48 PM James Daugherty
wrote:
>
> Hi Paul,
>
> Is the proposal to do this for 5.x or earlier?
5.0+
> -James
>
> On Sat, May 31, 2025 at 6:25 AM Sergio del Amo
> wrote:
>>
>> +1 from me.
>>
>> Although I have fallen into Groovy's @Singleton vs Jakarta @Singleon
>> pitf
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 ,
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
+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
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
>
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
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
+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 wrote:
>
> Hi folks,
>
> We have a feature request, and potential PR, to
I'd love to have java.time as a default import!
It's interesting you post this today, as just yesterday, I was writing a
Groovy script, using java.time, and somehow forgot that it wasn't already a
default.
Of course, I got an error, and immediately understood that I should have
imported the java.ti
21 matches
Mail list logo
