Re: [HEADS-UP] Grails would like to join the ASF

[Jochen Theodorou]

for me discussion points would be:
* Groovy version for Grails
* release cycle aligned with Groovy or not
* shared mailing lists
* ...

On 11.07.24 07:09, Paul King wrote:

Hi folks,

The Grails project is wanting to enter the ASF. They have two paths.
They can enter in the normal way via the Incubator. Alternatively, the
Groovy project can sponsor their incubation.

If you do/don't support the Grails project joining the ASF, let us
know. If you favor either of the two paths, let us know.

Personally, I am in favor of them joining and believe having the
Groovy project sponsor their incubation makes a lot of sense.

In terms of process, the Incubator has a standard template they use
for project proposals. I have proposed to the Grails project that they
fill out that template regardless of which path they take. [Shout if
you want to help with that goal.]

Once the project proposal is ready, there is typically a [DISCUSS]
thread for initial discussions and perhaps revisions to the proposal,
then a [VOTE] thread. Those threads would appear on the Incubator or
Groovy mailing lists, and would be voted on by the Incubator PMC or
the Groovy PMC depending on which path was taken. Regardless of which
path, I think the goal is for Grails to become its own top-level
project (and it would in due course get its own PMC). A less likely
but possible other outcome is that Grails becomes a subproject of
Groovy (and we'd share a PMC).

This email is mostly just a heads-up and a chance for folks to give
preliminary feedback or become involved. I expect more discussions
when the [DISCUSS] thread is sent.

Cheers, Paul.

Re: [VOTE] EOL for Groovy 2.4.x

[Jochen Theodorou]

+1
On 08.07.24 08:04, Paul King wrote:

Hi folks,

As per the [DISCUSS] thread[1], there is strong consensus to EOL
2.4.x. Please vote to formalize this step.

[1] https://lists.apache.org/thread/ft6l7j331xxnj2sg1c2kz1mwz45mxyn3

My vote:
+1 (binding)

Paul.

Re: [DISCUSS] EOL for Groovy 2.4.x

[Jochen Theodorou]

On 28.06.24 18:35, Christopher Smith wrote:

Heads up that Jenkins (as of plugin parent 4.83, and at least
workflow-cps is still on 4.80) still uses Groovy 2.4.21. The CPS plugin
is a drastic ASTT, and it's core to modern Jenkins pipelines.


you mean this I think:
https://github.com/jenkinsci/workflow-cps-plugin/tree/master/lib/src/main/java/com/cloudbees/groovy/cps

That is indeed a handful, but I don't think that is really a stopper.
The problem is probably finding somebody brave enough to start it.

bye Jochen

Re: [DISCUSS] EOL for Groovy 2.4.x

[Jochen Theodorou]

+1 out with it

I would consider 2.5 for EOL as well


Hi folks,

Groovy 2.4.x hasn't been something we have progressed for some time.
The last "real" commit to the GROOVY_2_4_X branch and the last release
(2.4.21) were both in Dec 2020.

For reference, 2.4.x supports back to JDK 1.6 while 2.5.x (which is
not part of this discussion) supports back to JDK 1.7:
https://groovy.apache.org/download.html#requirements

On the recommended page for GitHub security policy:
https://github.com/apache/groovy/security/policy

We state:
2.4.x Only severe/critical vulnerabilities (*)
(*) The 2.4.x stream is no longer the focus of the core team but
critical security fixes or community contributions may lead to
additional releases.

I propose to make the EOL official. I don't think the "weak support"
will be good enough once CRA regulations come into play. My
understanding from the CRA requirements is that we either intend to
provide timely fixes for vulnerabilities for any supported version, or
we should mark versions as EOL. This doesn't stop us from making an
emergency fix/release if we chose, it just indicates that shouldn't be
the expectation.

If anyone objects, please discuss here, otherwise I will create a VOTE
thread in a few days.

Paul.


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 5.0.0-alpha-9

[Jochen Theodorou]

+1
On 27.06.24 10:38, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 5.0.0-alpha-9 release!

This release includes 57 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354489

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_5_0_0_ALPHA_9
Tag commit id: 6dcf2666196a7613b813d0faad4b202d9375d359

The artifacts to be voted on are located as follows (r70013).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-9/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-9/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 5.0.0-alpha-9.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 5.0.0-alpha-9
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 5.0.0-alpha-9 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 4.0.22

[Jochen Theodorou]

+1
On 27.06.24 09:44, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.22 release!

This release includes 35 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354490

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_22
Tag commit id: 393f1174dcab86c82281611e32d16d9e247612b9

The artifacts to be voted on are located as follows (r70009).
Source release: https://dist.apache.org/repos/dist/dev/groovy/4.0.22/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.22/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 4.0.22.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.22
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.22 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 3.0.22

[Jochen Theodorou]

+1
On 27.06.24 08:56, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 3.0.22 release!

This release includes 19 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354377

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_3_0_22
Tag commit id: 20fc13abeafc3a5ccdeacf6dc10cd4e70a4f50f6

The artifacts to be voted on are located as follows (r70003).
Source release: https://dist.apache.org/repos/dist/dev/groovy/3.0.22/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/3.0.22/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 3.0.22.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 3.0.22
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 3.0.22 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Groovy Poster for Community Over Code EU

[Jochen Theodorou]

I like it

On 14.05.24 13:47, Paul King wrote:

Hi folks,

We have a poster that will be displayed at Community Over Code EU in
Bratislava in a few weeks.

Here is my current draft:

https://github.com/apache/apachecon-eu/blob/main/static/posters/CoCEU_WhyGroovyToday.pdf

There is a small window to make changes before they send the posters
off to the printers. It will be printed I think on A1 size paper,
about 594mm W x 841mm H (23.4 x 33.1 inches).

At the moment, it is rich in technical content - perhaps a little
light in marketing the benefits. If I was to make changes I'd prefer
to maybe reduce the first slightly and increase the latter. Let me
know if you have any feedback.

Thanks, Paul.

Re: weird error report

[Jochen Theodorou]

On 13.05.24 16:16, o...@ocs.cz wrote:
[...]

2074 ocs /tmp>  /usr/local/groovy-4.0.18/bin/groovy q
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/private/tmp/q.groovy: 1: Unexpected input: '{' @ line 1, column 32.
def all=['hi','there'].findAll { it.startsWith('h')) }
   ^
1 error
2076 ocs /tmp>
===


I assume the problem is the )) for the startsWith. The parser backtracks
because there is no opening ( for the closing one and then finds that {
can't be a valid input here.

Could you please make an issue for this? We should look into how we can
improve this

bye  Jochen

Re: Replacing GrapeIvy

[Jochen Theodorou]

On 03.05.24 00:28, Paul King wrote:

Hi folks,

One of the things we know is that Apache Ivy (used by Grab/grapes) is
being maintained less these days. I am going to start a spike to
better understand what a replacement using Apache Maven Resolver might
look like. If anyone has strong opinions or free cycles and wants to
help, let me know and you can join in the fun. Otherwise, I'll create
future issues(s)/PR(s) for folks to look at in due course assuming all
goes well.


I'd love to help, but I have currently no spare cycles, sorry.

I was wondering... hos does @GrabConfig(systemClassLoader=true) work
these days? From my knowledge this cannot work anymore in later JDK
versions (9+) because of the changes to the system class loader. Or did
we somehow bypass the limitation?

I personally use these in script files only. There is a potential class
loader suitable to do such work, but it is still not the system class
loader. If something really would need that, it would be having no
chance of working.

I hear really really little for such a nice feature having a problem. So
maybe it does not matter in reality?

bye Jochen

Re: Potential enhancement to type checking extensions

[Jochen Theodorou]

On 08.04.24 13:56, Paul King wrote:
[...]

What I wanted to show is the same examples but using the '==' and '!='
operators, since that would be the typical Groovy style for this
scenario. Unfortunately, using the type checking extension DSL doesn't
currently work for binary operators. The swap from '==' to the
'equals' method call occurs well after type checking is finished. The
same would apply to operators eventually falling back to 'compareTo'.


the replacements may be even on ScriptBytecodeAdapter.


You can still make it work by not using the DSL and writing your own
type checking extension, but that's significantly more work.

Our options seem to be:
(1) not trying to make this work
(2) modify operators to method call expressions earlier (might remove
some optimization steps)
(3) tweak StaticTypeCheckingVisitor#visitBinaryExpression to support
before/after method call hooks for known cases like equals/compareTo
with a pretend method call
(4) alter the TypeCheckingExtension interface with before/after binary
expression calls.


[...]


Does anyone have strong opinions on this before I start having a play
and seeing what might work? In particular, a preference for option 3
or 4?


Doing that only for special cases does not sound right to me. I would be
for option 4... is there anything speaking against that?

bye Jochen

Re: [GSoC 2024] Idea: A Basic Superset of Java | Java+

[Jochen Theodorou]

On 29.03.24 21:10, Caleb Brandt wrote:

Hey all,

I'm very grateful for your feedback, and it's clear that you aren't
convinced that this will be helpful enough to be an Apache-sponsored
project.


What do you understand under "Apache-sponsored"? I do for example use
Project Lombok if I have the chance to do so and it has to be in Java. I
think many here would. The things people have been pointing out are that
you probably underestimate some of the problems and that there can be
really silly reasons to reject something.

I would for one not speak of that as a language, but just as a tool. And
next you need good integration. It must be easy to use from an IDE and
in a build... at least potentially.

I can see how you could make the build variant a GSOC project. But under
the Apache Groovy flag? I mean there is no advantage for Groovy we would
get out of this. Right now it is mostly unrelated.

If you wanted to make this a transform and with this a compiler
extension, then this is a whole different matter. It would then be at
least related to Groovy. But is there a path forward from this?

Just why to explain why I mention transforms... they are annotation
based pre-processors to some extend, just on the AST level instead the
source level. Unlike in Java transforms are allowed to mutate the
classes in almost any way.

bye Jochen

Re: [GSoC 2024] Idea: A Basic Superset of Java | Java+

[Jochen Theodorou]

On 25.03.24 21:17, Caleb Brandt wrote:
[...]

If you do

class X {
  String foo = "bar"
  get() { return this.foo; }
  set(x) { this.foo = x; doSomethingElse()}
}

then the call to doSomethingElse is on line 4. But what will happen if
the IDE find doSomethingElse does not exist and wants to mark the call?
If the IDE works on the Java code for this the position will be wrong.
Yes, you would get an error message that is fitting as in
"soSomethingElse not found"... maybe even the correct line. This means
your IDE would have to know how to translate back to the code you
actually wrote. That is why this probably ends up as extension for the
compiler... which the IDEs may or may not support. I think Manifold is
doing that.


We all know what a getter and a setter is, so condensing them into one
place is easy to understand.


Sure, then I can write
private String foo = ("bar", {->this.foo}, {x->this.foo=;
doSomethingElse()})
And you will totally understand... right.. right?? I mean there are so
much in one place, you can barely compress this more and still write the
code. Well.. to get more serious again. You should not underestimate the
challenges of language design. And yes, this can be as bad as: "eh... it
is using begin/end instead of curly braces? Nah, don't like it".. "why
are there no blocks? There are? Oh the space is significant for this!?".
And I am not kidding. the first Is a C-guy disliking anything Pascal,
the second is all about Python.


But what's a "closure"? What's a
"delegate"? What's a "virtual thread"??? (I'm kidding.)  People don't
have a basis for these things in Java, so it's just /more/ stuff to
learn instead of already making sense to a Java-only programmer.


closures are quite similar to lambdas. The delegate concept is not the
difficult part. The difficult part is that you attach a code block to a
method and then the method does something with the code block. Ah yes...
conceptually those lambdas are also very near to anonymous inner
classes. A concept existing in Java for a long time already. It is all
about the approach really. Of course if the people you are showing this
are not open to the concepts and different views, then you can forget
about it. I for example never discuss with people about static
compilation if I get the impression they are thinking the false security
of static compilation solves all their problems in life.

[...]

Every addition needs to scan like Java at face value and
feel like something Oracle themselves would have added.


With lambdas they did quite the style break in my opinion. They did it
before though... with enums for example. And don't get me started about
generics or the switch-case. I really doubt I would be able to tell of a
new feature if it is as if Oracle themselves would have added it. In the
end that is not the key-point. It is how the new features work and look
together with the overall language. For example we had a feature request
to support "statement if expression", meaning "if (expression)
statement". Which exists in some language, but we decided against,
because it does not fit the style of the Groovy language.

[...]

_*1. WE CAN USE JAVA'S TOOLS*
_
Yeah so remember what I said about how "nothing will ever match Java in
a Java space"?  If you can't beat 'em, join 'em.  By acting as a
transparent frontend to real Java source code, we can leverage existing
Java analyzers to do our linting for us.


But it is not fully transparent. It is one-way.


The IntelliJ system already
has a variant of this for CLion's macro processing, being able to detect
errors in the applied macro and display the code it'll be replaced with
in a hover popup.


But the preprocessor in C/C++ was made part of the compiler even though
it originally existed and was intended as independent tool. It just did
not work, because of the line numbering being messed up. Back in the day
there existed quite a few languages that transpiled to C, all of them
got eventually their own compiler. In the word of gcc for example you
have many languages that compile to shared representation in memory,
which is then actually compiled to the target platform. This way you
have a front-end for Modula and one for C++, but lots of the back-end
part is still the same. In the end it is still like transpiling to C,
just on a different level, where the source does not matter.


We can also use Java debuggers to their fullest extent too: it'll link
to the processed Java8 sources when we freeze on a breakpoint instead of
the J+ sources, but once again that's a /feature/, not a bug.  With a
good enough formatter on the processor, they'll even thank us for it.


For this there is actually support in the Java bytecode world. If the
IDE can figure out from the file name attribute and the class name what
file to open, then the correct position in that source can be opened.
In your case the opened source would have to be the generated Java
source, since the IDE would not automatically know how that 

Re: [VOTE] Release Apache Groovy 5.0.0-alpha-7

[Jochen Theodorou]

+1

On 11.03.24 00:04, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 5.0.0-alpha-7 release!

This release includes 12 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354374

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_5_0_0_ALPHA_7
Tag commit id: 6dad260e0702e5c983481502cc8fcb97f4be21e0

The artifacts to be voted on are located as follows (r67868).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-7/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-7/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 5.0.0-alpha-7.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 5.0.0-alpha-7
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 5.0.0-alpha-7 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 4.0.20

[Jochen Theodorou]

+1

On 11.03.24 01:16, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.20 release!

This release includes 7 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354376

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_20
Tag commit id: fb36c6a20b99e388abbe0348c8007f9636ca449a

The artifacts to be voted on are located as follows (r67870).
Source release: https://dist.apache.org/repos/dist/dev/groovy/4.0.20/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.20/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 4.0.20.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.20
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.20 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 3.0.21

[Jochen Theodorou]

+1

On 27.02.24 12:09, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 3.0.21 release!

This release includes 17 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354073

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_3_0_21
Tag commit id: c4681c558ccc0644e217beb3ca7cd641fbc2533d

The artifacts to be voted on are located as follows (r67600).
Source release: https://dist.apache.org/repos/dist/dev/groovy/3.0.21/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/3.0.21/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 3.0.21.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 3.0.21
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 3.0.21 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 4.0.19

[Jochen Theodorou]

+1


On 27.02.24 11:41, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.19 release!

This release includes 18 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354149

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_19
Tag commit id: 7d25a39ae4c26f38b86b181c98e079a40e1d787e

The artifacts to be voted on are located as follows (r67599).
Source release: https://dist.apache.org/repos/dist/dev/groovy/4.0.19/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.19/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 4.0.19.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.19
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.19 because...

Here is my vote:

+1 (binding)

Re: [VOTE] Release Apache Groovy 5.0.0-alpha-6

[Jochen Theodorou]

+1

On 27.02.24 08:45, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 5.0.0-alpha-6 release!

This release includes 29 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354153

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_5_0_0_ALPHA_6
Tag commit id: 5769bc66c28b0ca5e9aedeb8bdef24723e981401

The artifacts to be voted on are located as follows (r67592).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-6/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-6/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 5.0.0-alpha-6.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 5.0.0-alpha-6
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 5.0.0-alpha-6 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Performance in Groovy 5

[Jochen Theodorou]

Hi,

to say this first I am currently working on several improvements in
indy, but progress is really slow. Just yesterday I learned something
new I have now to think about how to make it part of the overall
construction.

Just for clarification: callsite is a place of a method call. foo.bar()
has a callsite that calls the method bar. foo.bar(); foo.bar2(); is two
call sites and 10.times {foo.bar()} has only 1 callsite for bar, which
will be visited multiple times.

One central problem to indy is that it is quite expensive to construct.
Not each time, mostly the first time. All my tests show that cost in our
runtime generated callsites in old Groovy are far worse when you look at
them in isolation. But if you go with thousands of callsites  the
runtime generated versions are basically the same requiring basically no
recreation, while indy currently does. This then results in a longer
initial time spend. If your application has many callsites that are
visited only a few times the overall performance will be suffering a bit.

Then there is the caching in the callsite itself. For simple cases this
works, but there are some cases where our caching results in the
callsite needed recreation all the time. And as I stated before this is
not cheap. Thus the two problems are a bit related actually. Especially
in the static method calls I noticed some problems.

Now I have not enough information about Gabriel's specific problems. It
would actually be nice to have more details and trying to analyze what
exactly goes wrong here. But in case of MG I think it is both, specific
static method call patterns and initial costs.

bye Jochen

Re: Redirecting Output of groovy.util.GroovyScriptEngine to a custom Writer

[Jochen Theodorou]

On 13.02.24 08:38, Anadi Kashyap wrote:

Hello Groovy Developers and Community,

Perhaps my last question was missed so I'm asking it again, would
appreciate some direction here -

I am currently working with groovy.util.GroovyScriptEngine and I have
encountered a specific requirement where I need to redirect the output
of the script engine to a custom Writer, separate from the default
stdout/stderr, without affecting the rest of the JVM. This functionality
is somewhat similar to what javax.script.ScriptContext offers with
methods to set a custom writer.I am aware of
org.codehaus.groovy.jsr223.GroovyScriptEngineImpl, but it seems limited
for my use case. I am looking for a way to achieve this with
groovy.util.GroovyScriptEngine.Could you please guide me on how to
redirect the output effectively? Is there an existing feature in Groovy
that I might have missed, or would this be a case for a feature
request?Any guidance or suggestions would be greatly appreciated.Thank
you for your time and assistance.


ok... first there is GroovyScriptEngine (GSE) and the code it does
generate and execute. GSE itself is more a class management engine that
(re)compiles on demand). I think you want the output of those scripts
GSE is executing. GSE does not directly offer this. In Groovy a script
has a print, println and printf methods, that can depend on an optional
out property, which can hold any redirection you may want. But that does
not include error, direct usages of System.out or code called by the
script, nor explicit classes in the script. So this is very limited.

example:

Binding binding = new Binding(out: System.err)
groovyScriptEngine.run("""
println "Hello World from script"
class X {
  void foo() {
   println "Hello World from class"
  }
}
new X().foo()
out = System.out
println "Hello World from script Number 2"
""", binding)


Executing that kind of code would create a script and a class X. The
first println will write "Hello World from script" to System.err because
we set the out property for the class (in the binding) accordingly. Next
the code cause "Hello World from class" to System.out, since the println
in the class does not know about the out-property of the script. The
script and the class are only loosely related. Next we redefine out in
the binding (can be prevented with a custom Binding) and "Hello World
from script Number 2" will be written to System.out again.

bye Jochen

Re: Questions regarding implementation approach for GROOVY-11294

[Jochen Theodorou]

On 04.02.24 17:38, Oscar N wrote:
[...]

Jochen Theodorou:

 VMPlugin should not call into SBA or InvokerHelper.


Should I be copying over code in that case? Or should it be calling DGM
instead?


if you have code that is there to produce an unmodifiable list by DGM
and that logic of that depends on the VM version, then I expect this
code in the plugin and DGM calling the plugin. If there is code shared
between VMplugin and other code parts and the shared part does not
depend on the VM version, then maybe the VM variant needs reduction to
the really version dependent part and the caller needs to handle the rest.

In short I would like to keep the VM specific code parts as small as
possible.


I actually now wonder why you do Arrays.stream(values).toList(); in the
 Java16 version. Would List.of be better if all elements are not null? If
 yes, then why not check them? And why go with List#of and catch-NPE
 instead of stream before?


Stream#toList ends up creating the same kind of object (with its JVM
@Stable optimisations) as List#of (see
java.util.stream.ReferencePipeline#toList). The difference is the former
allows nulls, while the latter iterates over each parameter and throws
an NPE if any are null. Using the try-catch approach is slower because
in the worst-case scenario it would be performing lots of null checks
only to give up and use Collections#unmodifiableList, which the JVM
can't optimise as easily due to being backed by a mutable collection.


yeah, well that is what I did mean with keeping the responsibilities
specific. When does it really matter how many list elements there are?
Only if the list has a certain size. This size is imho not given in case
of records. Thus I think it is perfectly fine for record to list
conversion code to check all elements for null, but not for a
potentially millions of entries long list if it can be avoided. That
means the requirements for the bytecode case and for a general DGM entry
are not 100% the same.

bye Jochen

Re: [EXT] Re: ClassFile API

[Jochen Theodorou]

On 28.01.24 15:05, Remi Forax wrote:
[...]

Hello,
before i answer to your questions,
my remark about sealed types is that the API of the classfile library is based 
on sealed types and pattern matching.
A sealed type is not extensible meaning that if you target a specific version 
of the classfile API,
you have to manage the fact that a new subtype of a hierarchy can appear in the 
next version.


yeah, sorry for confusing you and the limited creativity. I did
understand that.. Maybe I should have taken something else as example
that changes the class level, or members. records would have given a
better example

[..]

It's not only new bytecode, by example with the value type of Valhalla, you need
to generate the attribute Preload to inform the VM that the class of a value
type has to be loaded before the value types appears in signature of methods
and fields. If you fail to do that, it will work, value classes are backward
compatible with identity (classical) classes but you will not get any
optimization so any benchmarks of Groovy vs Java will be unfair.


How does Java do that?


Here is the current VM spec
https://cr.openjdk.org/~dlsmith/jep401/jep401-20240116/specs/value-objects-jvms.html


oh wow... the decision with the class file version 67.65535 is a bit
strong... is it then 68.65535 in Java24? If they wanted to introduce
class file variants they could have made that differently - or not?


Here is the current JEP
https://openjdk.java.net/jeps/401

If a class V is declared as a value class, and a class A uses the class V, the class A 
should contain a new attribute Preload that lists "V" as a class to preload.
Preloading the class allows the VM to see that a class is not a normal class 
but a value class (if you ask for preloading a normal class, the VM will do 
nothing more).
When the VM knows that a class is a value class, internally the way to pass 
parameters is changed (the values of the fields are sent instead of a pointer) 
and on stack/in registers the values of the field are used instead of a 
pointer. So at runtime, it's like if they were no boxing.


I assume this means no change for using invokedynamic. The
implementation would have to change of course... well at least if that
is to be used there as well.


This is true for user defined value class but also some classes of the JDK like 
Integer, Boolean, etc or Optional that are retrofitted to be value class.


So if I have a method that takes a Number as parameter there will be no
value type handling?

bye Jochen

Re: [EXT] Re: ClassFile API

[Jochen Theodorou]

On 27.01.24 18:58, Remi Forax wrote:
[...]

The classfile API uses sealed types, once those will be updated either the 
groovy compiler will need to be updated or a default of a switch will be called.
See how the overview of the API uses "default" everywhere.
   
https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html

I do not see how it changes anything for Groovy. If there is a new version of 
the classfile format, and you need to read it, then you have to modify your 
code each time there is a new version. For example, if a future version of Java 
uses a new modifier, a new bytecode instruction, a new constant pool constant 
or a new attribute (Valhalla add several of those), the java compiler will be 
modified to read and write those new 
modifier/instructions/constants/attributes, Groovy will have to do the same, 
independently of using ASM or not. The ClassFile API will not help you, because 
the semantics of the version classfile is different from the previous version 
so the code of Groovy has to be upgraded.


What would happen if we did read a sealed class, without knowing about
sealed classes? Your comment sounds like this then cannot be read, since
the specific type is required, one which we do not know, because we do
not know sealed classes.

... that does indeed limit the usability a lot.

But it is still more than today. We normally do not need to read code
blocks. So as long as the bytecode change is limited to that or if the
class simply got compiled with the newest JDK it would still work.



The ClassFile API is great if your library/application only generate bytecodes 
(this is mostly what the JDK does BTW) because in that case, you do not have to 
update to each new classfile versions, only update when you want to target a 
new LTS.


With target a new LTS you mean use the new bytecode features of that?
Because just for the heck of it I do not need to update the bytecode
version I produce.

For now I think the benefits from using the class file API are too low.


It is also a question of when we can have work started on implementing
any new bytecode based features of the new Java variant. the point might
be for mood since we rarely have the manpower to do something like this.


It's not only new bytecode, by example with the value type of Valhalla, you 
need to generate the attribute Preload to inform the VM that the class of a 
value type has to be loaded before the value types appears in signature of 
methods and fields. If you fail to do that, it will work, value classes are 
backward compatible with identity (classical) classes but you will not get any 
optimization so any benchmarks of Groovy vs Java will be unfair.


How does Java do that?

bye Jochen

Re: Questions regarding implementation approach for GROOVY-11294

[Jochen Theodorou]

Hi Oscar,

sorry for replying so late, I was very busy this week.

On 22.01.24 20:55, Oscar N wrote:

Indeed, that is the crux of my earlier questions. I've got it working at
runtime, however I'm unsure of which approach to take for compile-time.

Adding new `ScriptBytecodeAdapter`/`InvokerHelper` methods that call a
`VMPlugin` method allows for optimising other scenarios, such as
`DefaultGroovyMethods.asImmutable(List)`.


InvokerHelper normally contains methods for the users of the language to
help the with mostly invocation related issues like invoking a method in
a dynamic way or such. There is more in there, but usually we only add
if really really needed. ScriptBytecodeAdapter (SBA) is for helper code
directly called from the bytecode and tailored to the needs of those
calls only. Used mostly if too complex to compile directly to bytecode
or if further helper structures like the VMPlugin are required. Here
again the rule is trying to avoid using it, but the VMPlugin is not for
direct calling, so if you do like you did in your started
implementation, then going through SBA looks to me like the right way.
DefaultGroovyMethods are methods made available by the runtime for
method calls. DefaultGroovyMethods.asImmutable(List) would mean
List#asImmutable()

ah yes.. and VMPlugin should not call into SBA or InvokerHelper.


You can find my current implementation here: PaintNinja/groovy at
GROOVY-11294-record-immutable-tolist (github.com)



well.. I suggested some changes above already. In the end though I
second Miles and wonder if it is worth it.


As for compile-time optimisations, I'm not very familiar with Groovy's
compiler internals. What would be the most suitable place to do JVM
version-specific optimisations?


For bytecode generation we ask the supported version in the compiler
config. For the runtime VMPlugin is the right place.


Note that the exact type of immutable list used also varies on the
nullity of items and the length of the array, so for optimal performance
it's unfortunately not as simple as one method for all lists on one Java
version and another method on a different version.


I actually now wonder why you do Arrays.stream(values).toList(); in the
Java16 version. Would List.of be better if all elements are not null? If
yes, then why not check them? And why go with List#of and catch-NPE
instead of stream before?

bye Jochen

Re: [EXT] Re: ClassFile API

[Jochen Theodorou]

On 23.01.24 19:33, Milles, Eric (TR Technology) via dev wrote:

An API like this works fine for straightline code.  But if you need to add 
instructions conditionally, repeat blocks for additional instances, or other 
complex scenarios; builders can quickly break down.  I would wait to see how 
the class file api shakes out before turning over nearly all of classgen.  As 
long as ASM keeps upping its version handling we don't need something else.

Is there a strong case that can be made for using this new api?  Otherwise, I'd like to 
avoid "shiny object" syndrome and focus on fixing more bugs.


the only reason I see is one of the reasons Class File exists and that
is to be able to read/write class files of the newest Java version. Yes,
sure if Groovy X.32.50 supports Java 32 and then Java 33 is released we
can, after some months, update the asm lib and release Groovy X.33.0.
But this also means (a) we are required to release and (b) Groovy
X.32.50 will never support ordinary classes compiled to Java 33.

It is also a question of when we can have work started on implementing
any new bytecode based features of the new Java variant. the point might
be for mood since we rarely have the manpower to do something like this.

bye Jochen

Re: ClassFile API

[Jochen Theodorou]

On 22.01.24 01:23, Daniel Sun wrote:

Hi Jochen,

  Groovy relies on ASM lib directly, so it would save lots of work if we 
could have an abstract layer whose API aligns with ASM lib, just change ASM 
package name(org.objectweb.asm) with Groovy package name, e.g. 
org.apache.groovy.classfile.


yes, but how do you

´´´
ClassBuilder classBuilder = ...;
classBuilder.withMethod("fooBar", MethodTypeDesc.of(CD_void, CD_boolean,
CD_int), flags, methodBuilder ->
methodBuilder.withCode(codeBuilder -> {
Label label1 = codeBuilder.newLabel();
Label label2 = codeBuilder.newLabel();
codeBuilder.iload(1)
.ifeq(label1)
.aload(0)
.iload(2)
.invokevirtual(ClassDesc.of("Foo"), "foo",
MethodTypeDesc.of(CD_void, CD_int))
.goto_(label2)
.labelBinding(label1)
.aload(0)
.iload(2)
.invokevirtual(ClassDesc.of("Foo"), "bar",
MethodTypeDesc.of(CD_void, CD_int))
.labelBinding(label2);
.return_();
});
´´´

with an ASM style of API? The lambdas make a mapping not nice

bye Jochen

Re: [EXT] ClassFile API

[Jochen Theodorou]

On 22.01.24 20:15, Milles, Eric (TR Technology) via dev wrote:

The new Class File API is for reading not writing, correct?


I had a different impression. Sure, reading is a big use case for normal
Javausers, but they are currently moving their bytecode generation as
well. For example for proxies. Also there is the statement, that
something like calculating the stack frames should be done automatically
- that is something you need only for writing.

bye Jochen

Re: ClassFile API

[Jochen Theodorou]

On 20.01.24 17:47, Daniel Sun wrote:

Hi Jochen,

  Both ASM lib and Class-File API are good, I would like to have an 
abstract layer for them. The API for the abstract layer could be align with ASM 
lib as Groovy relies on ASM lib heavily.

  If Groovy finds Class-File API is avaible, use Class-File API as the 
implementation for an abstract layer, otherwise use ASM lib.


hmm... yes. I see ASM API as less intrusive in the way you would handle
things, thus this abstracted API would proably look a lot like the
Class-File API?

bye Jochen

ClassFile API

[Jochen Theodorou]

Hi all,

currently the Classfile API (https://openjdk.org/jeps/457) is getting
more and more usage in the newest version of the jdk. Even though the
target is not to replace the ASM lib, that is actually happening for the
JDK. As for the motivation of why they move from ASM to the ClassFile
API (taken from JEP-457):
"""
Because the class-file format can evolve every six months, frameworks
are more frequently encountering class files that are newer than the
class-file library that they bundle. This version skew results in errors
visible to application developers or, worse, in framework developers
trying to write code to parse class files from the future and engaging
in leaps of faith that nothing too serious will change. Framework
developers need a class-file library that they can trust is up-to-date
with the running JDK.
"""

Well... in Groovy we have a bit the same problem. I'd like to encourage
a discussion about this here... staying with ASM, moving to ClassFile or
use both?

What do you guys think about?

bye Jochen

Re: [VOTE] Release Apache Groovy 5.0.0-alpha-5

[Jochen Theodorou]

+1

Am 16.01.24 um 12:46 schrieb Paul King:

Dear development community,

I am happy to start the VOTE thread for a Groovy 5.0.0-alpha-5 release!

This release includes 21 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354072

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_5_0_0_ALPHA_5
Tag commit id: edcba8e9aec60c8f8657335f686e3683f7ee2857

The artifacts to be voted on are located as follows (r66637).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-5/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-5/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 5.0.0-alpha-5.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 5.0.0-alpha-5
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 5.0.0-alpha-5 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 4.0.18

[Jochen Theodorou]

+1

Am 16.01.24 um 04:26 schrieb Paul King:

Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.18 release!

This release includes 16 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12354066

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_18
Tag commit id: c17afaaf3984624e98519fcd397439d152f55b10

The artifacts to be voted on are located as follows (r66628).
Source release: https://dist.apache.org/repos/dist/dev/groovy/4.0.18/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.18/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 4.0.18.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.18
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.18 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Closure Class Files Recreation

[Jochen Theodorou]

Am 15.01.24 um 20:24 schrieb o...@ocs.cz:

Jochen,


On 15. 1. 2024, at 10:35, Jochen Theodorou  wrote:
If the goal is to give Groovyc a source file and let it compile that,
but write only certain files... well that is something that could be
worked out.


Well I don't know.

Theoretically, it would be nice if the compiler wrote only those .classes, 
which did change from the previous compilation.

I might be overlooking something of importance, but I fear that would be pretty 
difficult, at the verge of impossible. I guess the solution might be found 
somewhere nearby creating some hash of the last generated code, stored in 
.class, checking when building and not re-writing the .class if unchanged... am 
not sure whether feasible at all.


Assume the following Java-like

import static Foo.bar

class BarExec {
  public Runable getExec() {
return new Runable() {
  public void run(){ bar() }


So basically this wraps a call around Foo.bar, in way you would not do
it anymore these days, but this is just for illustration. So assume my
change now is replacing the import and import Foo.bar2 instead of
Foo.bar. Because the method is called in the anonymous class in getExec
the minimum we need to do is recompile BarExec$1. BarExec does not need
recompilation, even though the code we changed is not even directly in
the inner class. That kind of problem makes it really difficult to do
any kind of partial compilation

But the idea with a hash (where we compile the whole file) sounds
possible to me.


This is not really incremental compilation like we may know
it from eclipse-java though.


I've tried to use the Eclipse thing and it was terrible enough (not just due to 
unreliable incremental build; a plethora of other problems, GUI ugly as hell, 
contra-intuitive and completely non-ergonomic, slow and crashing pretty often) 
that I spent a non-trivial time writing my own scripts and even an external EOF 
model editor to be able to use Xcode to build my WebObjects/Groovy applications 
:)


yeah, Eclipse has its weaknesses


Anyway I would be contented with a build system which
- never tries to re-compile sources which did not change after the previous 
build (this works with my scripts all right)
- reliably re-builds all the classes generated by a source changed after the 
previous build (this works with my scripts all right)
- reliably deletes classes which were created by the previous build, but do not 
exist anymore with the current one (and this, alas, my scripts do not support 
properly yet).


to know what files we would create we would have to do a complete
compilation process except the actual writing of files. Under the
assumption of a class Foo will produce a number of class files
Foo($.+)*.class we could then in theory identify which files for Foo are
then surplus. But if you for example deleted Bar.groovy, then we do not
have a Bar.groovy to find out that we do not need Bar.class and
Bar$1.class anymore. For this we would have to compile all source files,
though we would not have to create the class files of course.

Now what do you understand under re-compile? process the source like in
a normal compilation and write out the result, or does it not matter if
the result is written out? If the later does not matter, then
determining the list of unused top-level classes conflicts with the idea
of re-compiling only files that did not change. This is also because in
Groovy a source file can contain any number of top level classes, it
does not even have to contain a class that is similar to the name of the
file.

But of course if you say you want the fixed relationship of one file
containing one class and its inner classes, then this is actually
solvable. For example if there is a bar.class but not bar.groovy we can
delete bar.class. Or if there is bar.class bar$1.class and bar$2.class
and if bar was changed, then any bar class file with a time from before
the last compilation can be deleted.


I understand Eclipse and other Java-related IDEs do this completely wrong, for 
they naïvely assume an XXX.source always generates just XXX.class. I might be 
wrong of course — for years I happily use Xcode plus my scripts and haven't 
touched those other IDEs by a ten-foot pole; perhaps they improved meantime :)


IDEs usually know that there can be more. At least inner classes for the
Java case. Well... they all got even more memory hungry mostly.
Sometimes it is interesting to work with something like vscode for
example. It makes a more lean impression... but in the end it is similar
bad in terms of memory consumption once you start adding plugins. If you
are happy with xcode, stay with xcode ;)

bye Jochen

bye Jochen

Re: Closure Class Files Recreation

[Jochen Theodorou]

If the goal is to give Groovyc a source file and let it compile that,
but write only certain files... well that is something that could be
worked out. This is not really incremental compilation like we may know
it from eclipse-java though.

bye Jochen

On 14.01.24 21:43, OCsite wrote:

MG,

I might be wrong (haven't checked for a long long time and at least a
couple of major Groovy versions), but I believe groovyc always simply
re-creates all the .class files which result from a source compiled
(could be a number of them: aside of the closure classes, groovyc — very
reasonably unlike the Java disaster — supports any number of
/class/ definitions in one source, and can generate one more as a script
if the source happens to have statements outside all classes).

(And yes, if your build system supports the incremental build, it can be
a royal PITA. My scripts — so that I can build directly from Xcode, I
wrote a set of my own ones — do support incremental and it doesn't work
quite reliably due to this very problem. I considered to make a special
support which would internally pair the source with all the classes
generated from it, allowing the scripts later to check timestamps and
auto-delete extra classes which are not needed anymore, yadda yadda,
but, alas, so far I haven't got to implementing it properly — ars longa,
vita brevis :/ )

All the best,
OC


On 14. 1. 2024, at 20:02, MG  wrote:

Hi Jochen,

 1. we build using IntelliJ, and this has occurred independent of the
IntelliJ version for years.
 1. (It is now that I work more from home that this becomes more
of a nuiscance, due to much slower upload speed to the server.)
 2. Does "Groovyc compiles what you give it to compile" hold true in
this case ?
 1. Closures are compiled to classes, but they do not exist as
such in the code, so how would IntelliJ tell Groovyc to
compile (or not compile) the closures in a Groovy source file... ?
 2. Based on this I always assumed it is Groovyc who decides to
recreate all those auto-generated closure classes... (?)

Cheers,
mg


On 14/01/2024 14:04, Jochen Theodorou wrote:

On 12.01.24 18:50, MG wrote:

Hi guys,

is there a way to get Groovy not to nedlessly recreate closure class
files during a build which would otherwise just change one or two
non-closure class files ?
The recreation of large numbers of closure class files seems to be
triggered randomly at certain points, and having to continuously
rsync-upload these files to the server after small code changes becomes
a factor in turnaround time...


I think we need a bit more detail. Groovyc compiles what you give it to
compile. If something is deciding one time to  compile a set A and
sometimes a set B, then it is because the part controlling Groovyc
decided to do that.

so what is controlling Groovyc in your case? Gradle, Maven, Intellij..?

bye Jochen

Re: Closure Class Files Recreation

[Jochen Theodorou]

On 12.01.24 18:50, MG wrote:

Hi guys,

is there a way to get Groovy not to nedlessly recreate closure class
files during a build which would otherwise just change one or two
non-closure class files ?
The recreation of large numbers of closure class files seems to be
triggered randomly at certain points, and having to continuously
rsync-upload these files to the server after small code changes becomes
a factor in turnaround time...


I think we need a bit more detail. Groovyc compiles what you give it to
compile. If something is deciding one time to  compile a set A and
sometimes a set B, then it is because the part controlling Groovyc
decided to do that.

so what is controlling Groovyc in your case? Gradle, Maven, Intellij..?

bye Jochen

Re: Possible improvement to NumberRange

[Jochen Theodorou]

On 10.01.24 05:53, Paul King wrote:

Hi folks,

The NumberRange abstraction tries very hard to allow any Number
numeric type to be used but since the Number interface doesn't convey
much behavior, there are a few places where it defaults to using
Groovy's NumberMath plumbing which, to cut a long story short, falls
back to using BigDecimal for any numeric calculations which aren't
using the common known simpler types.


But wouldn't that mean we are lacking a range type for this?


A consequence of this is that currently if you created a range using
e.g. the Apache Commons Fraction class (which does extend Number), and
used a Fraction stepSize, the values in the range would be one
Fraction (for the first element) and then subsequent elements would be
BigDecimals.

@Grab('org.apache.commons:commons-lang3:3.14.0')
import org.apache.commons.lang3.math.Fraction
def r = (Fraction.ONE..2).by(Fraction.ONE_QUARTER)
println r.toList() // => [1/1, 1.25, 1.50, 1.75, 2.00]

This isn't incorrect in one sense but is somewhat surprising. Given
that the Number interface doesn't have operators, providing a smarter
detection of the number system to use becomes somewhat tricky. One
thing we could do is provide some interface that providers could use
and we could have a "Fraction" math implementation that satisfied that
interface.


But we have this convention already, which is substract, add and negate
as dynamic methods being called. It is not a formal interface, yes, but
so is also not for previous and next for the ObjectRange.


Alternatively, we could supply some [Bi]Functions that
offered the supplied behavior that the StepIterator needs when
calculating subsequent elements in the range. With this second
approach, we could do something like:

@Grab('org.apache.commons:commons-lang3:3.14.0')
import org.apache.commons.lang3.math.Fraction
(Fraction.ONE..2).by(Fraction.ONE_QUARTER,
 Fraction::add, Fraction::subtract, Fraction::negate).toList()

Which gives a list of all Fraction instances: [1/1, 5/4, 3/2, 7/4, 2/1]

Is this something we should support? Does anyone have ideas on the
best implementation?


the key point about the Number interface is actually converting to one
of the Java numbers. Of course I understand what you want to achieve,
but is that really a NumberRange in the end?

If I extend and abstract the idea above, don't I end up with something
where I define a step-function:

(Fraction.ONE..2).by(it -> it.add(Fraction.ONE_QUARTER)

and would that not kind of abstract ObjectRange as well:

('a'...'z').by(Character::next)

I like here especially the simplicity, that you really only require
Comparable for this to work.

Then again what does Number.next() do? It is calling plus(1). If we go
to the essence of it we actually have only one real range, which is the
ObjectRange and all other ranges are optimizations.

In fact if you look at it strictly we are even breaking the contract by
not doing next in there, but plus(1). If you would replace next() on
Integer our IntRange will ignore that.

Anyway, since they are optimization for specific cases maybe NumberRange
should not try to solve this, but a new range?


bye Jochen

Re: [VOTE] Release Apache Groovy 3.0.20

[Jochen Theodorou]

+1
On 19.12.23 03:53, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 3.0.20 release!

This release includes 59 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353572

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_3_0_20
Tag commit id: 6ad73a654d11db5abd383dde16f8587954c07dd4

The artifacts to be voted on are located as follows (r66157).
Source release: https://dist.apache.org/repos/dist/dev/groovy/3.0.20/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/3.0.20/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 3.0.20.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 3.0.20
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 3.0.20 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 4.0.17

[Jochen Theodorou]

On 19.12.23 03:27, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.17 release!


+1


This release includes 8 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353979

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_17
Tag commit id: 0bd637ff3a7bf917fe5edb907f331861c0df8a84

The artifacts to be voted on are located as follows (r66156).
Source release: https://dist.apache.org/repos/dist/dev/groovy/4.0.17/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.17/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 4.0.17.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.17
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.17 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 5.0.0-alpha-4

[Jochen Theodorou]

+1
On 19.12.23 02:08, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 5.0.0-alpha-4 release!

This release includes 16 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353967

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_5_0_0_ALPHA_4
Tag commit id: 433daecc3942257fc33c159765b25bb3aa77d3ed

The artifacts to be voted on are located as follows (r66155).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-4/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-4/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 5.0.0-alpha-4.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 5.0.0-alpha-4
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 5.0.0-alpha-4 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: next releases

[Jochen Theodorou]

On 11.12.23 22:11, Paul King wrote:

Hi folks,

I was planning to do one more round of releases before the end of the
year. Let me know what might need to be done before I hit the go
button. It would need to be done in about a week (to get in before
Christmas) or I'd probably aim for around the 27th to get in before
the new year.


I intend to spend some time on the indy cache next week, but that can go
in the release after np. I don't even know if I will be able to get it
done before xmas.

bye Jochen

Re: [VOTE] Release Apache Groovy 4.0.15

[Jochen Theodorou]

+1
On 11.09.23 11:24, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.15 release!

This release includes 12 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353571

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_15
Tag commit id: f821c4627c197b6332e1d0e200681f3ae411df83

The artifacts to be voted on are located as follows (r63911).
Source release: https://dist.apache.org/repos/dist/dev/groovy/4.0.15/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.15/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 4.0.15.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.15
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.15 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 5.0.0-alpha-2

[Jochen Theodorou]

+1
On 11.09.23 10:20, Paul King wrote:

Dear development community,

I am happy to start the VOTE thread for a Groovy 5.0.0-alpha-2 release!

This release includes 20 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353570

Tag: 
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_5_0_0_ALPHA_2
Tag commit id: 50b6e95748b76f272e6e865c04988388a1277974

The artifacts to be voted on are located as follows (r63907).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-2/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-2/distribution

Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS

Please vote on releasing this package as Apache Groovy 5.0.0-alpha-2.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://www.apache.org/info/verification.html

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 5.0.0-alpha-2
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 5.0.0-alpha-2 because...

Here is my vote:

+1 (binding)


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 2.5.23

[Jochen Theodorou]

+1
On 19.08.23 07:50, Paul King wrote:


Dear development community,

I am happy to start the VOTE thread for a Groovy 2.5.23 release!

This release includes 2 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353077


Tag:
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_23

Tag commit id: a8f3b116afd969be3f06b1807371d976462d6a2c

The artifacts to be voted on are located as follows (r63511).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/2.5.23/sources

Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/2.5.23/distribution


Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS


Please vote on releasing this package as Apache Groovy 2.5.23.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval

Hints on validating checksums/signatures (but replace md5sum with
sha256sum):
https://www.apache.org/info/verification.html


The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 2.5.23
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 2.5.23 because...

Here is my vote:

+1 (binding)

Re: [VOTE] Release Apache Groovy 3.0.19

[Jochen Theodorou]

+1
On 19.08.23 06:51, Paul King wrote:


Dear development community,

I am happy to start the VOTE thread for a Groovy 3.0.19 release!

This release includes 7 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353387


Tag:
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_3_0_19

Tag commit id: 1040cabcefe8e0776ca2d87e7a3f0ee2840dbf68

The artifacts to be voted on are located as follows (r63510).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/3.0.19/sources

Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/3.0.19/distribution


Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS


Please vote on releasing this package as Apache Groovy 3.0.19.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval

Hints on validating checksums/signatures (but replace md5sum with
sha256sum):
https://www.apache.org/info/verification.html


The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 3.0.19
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 3.0.19 because...

Here is my vote:

+1 (binding)

Re: [VOTE] Release Apache Groovy 4.0.14

[Jochen Theodorou]

+1
On 19.08.23 05:18, Paul King wrote:


Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.14 release!

This release includes 15 bug fixes/improvements as outlined in the
changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353386


Tag:
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_14

Tag commit id: 034b8f90052752c978c5454cc3b17b163c68ffec

The artifacts to be voted on are located as follows (r63509).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/4.0.14/sources

Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.14/distribution


Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS


Please vote on releasing this package as Apache Groovy 4.0.14.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval

Hints on validating checksums/signatures (but replace md5sum with
sha256sum):
https://www.apache.org/info/verification.html


The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.14
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.14 because...

Here is my vote:

+1 (binding)

Re: [VOTE] Release Apache Groovy 5.0.0-alpha-1

[Jochen Theodorou]

not so sure about the removal of $getLookup, but still +1

On 19.08.23 04:20, Paul King wrote:


Dear development community,

I am happy to start the VOTE thread for a Groovy 5.0.0-alpha-1 release!

NOTE: We are not feature complete for Groovy 5. In the release notes,
I will make it clear that this is an alpha release, not recommended for
production use and subject to change. But I think we need to start getting
feedback on the parts that are ready and having a release will help with
that.

This release includes 119 bug fixes/improvements as outlined in the
changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12351227


Tag:
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_5_0_0_ALPHA_1

Tag commit id: cbd5a526a7af9375858c8967adc1e32555cb91f7

The artifacts to be voted on are located as follows (r63508).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-1/sources

Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/5.0.0-alpha-1/distribution


Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS


Please vote on releasing this package as Apache Groovy 5.0.0-alpha-1.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval

Hints on validating checksums/signatures (but replace md5sum with
sha256sum):
https://www.apache.org/info/verification.html


The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 5.0.0-alpha-1
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 5.0.0-alpha-1 because...

Here is my vote:

+1 (binding)

Re: removing dgm helper methods

[Jochen Theodorou]

Am 17.08.23 um 08:07 schrieb Paul King:

I created this issue to track that work:

https://issues.apache.org/jira/browse/GROOVY-11158


There are possibly still a few places where we use some classes directly
still. Also, we want to retain backwards compatibility, e.g.
libraries/plugins compiled on earlier versions should still work in
Groovy 5. [...]


well.. how are dgm helper classes are used?

In dynamic Groovy they are not compiled against, their runtime
information is used to enhance the classes and their invocation
mechanism is not with invokedynamic and should actually be changed.

Now in static Groovy there is a chance that for example list#each will
compile to something using a dgm. But that would be quite unfortunate,
as the dgm classes are really only numbered and their numbering can vary
from release to release. I would consider that a bug actually.

let me check ... oh btw, the jfrog download link on the top of the
download page is giving a 404 - actually several jfrog links give that
error.

Anyway.. looking at the static compiled code we correctly ignore the dgm
helper classes and directly go for DefaultGroovyMethods & Co.

Thus I do not really see any danger here. In the worst case a
precompiled program with Groovy 4 would be have a slightly longer
initialization time on Groovy 5. But that is something I can tell for
sure only after the change has been done.

bye Jochen

removing dgm helper methods

[Jochen Theodorou]

Hi,

We have those dgm helper methods we generate at build time. They are
originally used as part of the callsite caching to have less reflection
for the invocation. Accordingly they are meta methods with an invoke
method. But we are now using invokedynamic and for this we actually
would need a MethodHandle instead.

There is also dgminfo to consider, which is basically a serialized map
version of our default groovy methods using DGM. I would keep that of
course, but I think the old GeneratedMethod is maybe not the right thing.

Do we want to do something in that area for Groovy 5?

bye Jochen

Re: Joint Compilation Limits and Alternatives

[Jochen Theodorou]

On 29.06.23 07:52, Paul King wrote:



[...]

I would be interested in looking at earlier attempts like V2 to see if
advances in the meantime now make them more feasible.


[...]

On Mon, Jun 26, 2023 at 10:16 PM Jochen Theodorou mailto:blackd...@gmx.org>> wrote:

[...]

V2:
Collect class data from javac using annotation processing and feed that
to groovyc. This would then be a 3 stage process. First we use javac to
get the class information, but javac cannot complete compilation, since
not all classes are resolved. Then we use the extracted information to
compile Groovy. And finally we compile normally with Java.

I tried this years ago and did not manage to get this working properly.
I would have to investigate what exactly was the problem since I tried
this maybe 8 years ago. But I think I actually was able to extract the
information and my problem was more making the classes then known to
Groovy. If not done in-memory this can probably be done easily.


Today I had some time to play around with this and got something running
quite fast... but looking a bit deeper I found issues.

assume you have something like this in Java
'''
package a;
public class J1 {}
'''

this in Groovy
'''
package b
import a.*
class G1 extends J1 {}
'''

and this in Java
'''
package a;
import b.*;
public class J2 extends G1 {}
'''

and finally in Groovy
'''
package b
import a.*
class G2 extends J2 {}
'''

The problem lies in resolving G1 in J2. The java compiler will not do
that for us, it cannot, since it does not have the required information.

Assume G1 defines a method and G2 uses @Override to override the method.
The result would be a compilation error on the Groovy side, since the G1
in J2 is not our b.G1 and is just an empty shell.


To resolve this by hand I would require the import statements, which
seem not to be part of javax.lang.model. If I go for the "Compiler Tree
API", but then I am specific to Oracle and OpenJDK. I would still have
to resolve things by hand of course.

Any ideas on how to proceed?

bye Jochen

Re: [EXT] Re: Joint Compilation Limits and Alternatives

[Jochen Theodorou]

On 29.06.23 20:39, Christopher Smith wrote:

Implementing javax.annotation.processing would cover a lot of surface
area because it exposes the Java AST (via the RoundEnvironment methods)
and the entire TypeMirror "Spock in a goatee" representation of the Java
classes under processing. This means that the Groovy AST would need
*two* facades, and irritatingly the javac implementations are all
unexported (which has been causing me problems in my Java annotation
processors when using reflective property access).


It would be quite a bit of work, and since we have a mutable AST with no
tracking for modifications we would have to create that AST for
annotation processors every round new. I guess I would go with a kind of
"generate it when requested approach". Ideally a full AST is not required...

Because of the Java module system I am actually expecting a lot of
annotations to not be processed at runtime, but at compile time. Since
this is a slow moving target it is not urgent though

bye Jochen

Re: [EXT] Re: Joint Compilation Limits and Alternatives

[Jochen Theodorou]

On 29.06.23 19:28, Christopher Smith wrote:

One note I'll add is that while Lombok was presented as an example of a
Java annotation processor, it really isn't—it's a monkey-patch of javac
itself, as otherwise annotation processors can't modify classes, just
add new ones.


I am actually aware of that... they even have different "hacks" for
javac and jdt. Sadly lombok is for me one of the most used annotation
processors and I would not like to dispose of it in Java files I cannot
replace with Groovy


Regarding "regular" annotation processors, it would be
possible to implement the javax.annotation.processing interfaces to
resolve from the Groovy AST structures, though this would be decidedly
non-trivial.


Why do you think that this would be non-trivial?

bye Jochen

Re: [EXT] Re: Joint Compilation Limits and Alternatives

[Jochen Theodorou]

On 29.06.23 16:24, Milles, Eric (TR Technology) via dev wrote:

Thanks for raising that issue. It has been a limitation for some folks for 
quite a while. I am very keen to improve our joint compilation process if we 
can.


I was actually wondering if someone really still cares.



I do get issues quite often (for groovy-eclipse tooling) that expect traits, 
@PackageScope, @TupleConstructor and so on to be cross-compatible with Java 
code in the same project.  I have experimented with improving the experience, 
with some success but also some circular dependency issues.  
https://github.com/groovy/groovy-eclipse/commit/9e1f1a753cecba8320da3fba757b7d64cfd091a5


I was wondering if groovy-eclipse would actually gain something from a
project in which we first collect Java Class Nodes, then compile Groovy
against them, then compile actual Java against the resulting Groovy
ClassNodes. I do not know how the different phases interact in JDT and
the GroovyCompiler.

bye Jochen

Re: Joint Compilation Limits and Alternatives

[Jochen Theodorou]

On 29.06.23 07:52, Paul King wrote:


Hi Jochen,

Thanks for raising that issue. It has been a limitation for some folks
for quite a while. I am very keen to improve our joint compilation
process if we can.


I was actually wondering if someone really still cares.


I did try one experiment to improve the V0 process by making transforms
smarter and idempotent. Essentially, I was trying to get more transform
results into the stubs and I was duplicating more of the process. I was
basically regenerating stubs after each phase and repeating earlier
Groovy phases for files affected by any changes. I was trying to make
more things incremental otherwise that approach doesn't scale at all.
But I ran out of cycles to explore before getting anything that I would
call usable.


interesting... but doesn't that mean you compile the Java part multiple
times too? That would be very very bad for performance.


I would be interested in looking at earlier attempts like V2 to see if
advances in the meantime now make them more feasible.

[...]
V2 was:

V2:
Collect class data from javac using annotation processing and feed that
to groovyc. This would then be a 3 stage process. First we use javac to
get the class information, but javac cannot complete compilation, since
not all classes are resolved. Then we use the extracted information to
compile Groovy. And finally we compile normally with Java.


The big problem part is that we are working on something that possibly
cannot compile in Java. I am actually not sure annotation processors are
fully defined in these environments. Needs to be tested.

V1 with javaparser has also the option to use the SymbolResolver (which
I have not used yet) to resolve classes against imports.

In the end it does not matter who is feeding us with the classes from
Java. What we need are ClassNodes (non-primary) to give them to the
ClassNodeResolver and we are good to go.

bye Jochen

Joint Compilation Limits and Alternatives

[Jochen Theodorou]

Hi all,

yesterday I was playing around with joint compilation and I want to
share some thoughts:

current state (afaik): V0

Groovy creates stubs, Javac compiles Java and stubs, Groov compiles
against generated classes. Annotationprocessing on Java should work, on
Groovy it depends on the phase. Reading constants from Java compiled
classes should work for Groovy, I the stubs contain these too, therefore
Java can read the constants as well. Since this runs the Groovy compiler
and the Java compiler together, this consumes quite a bit of memory.

In summary this works quite well with some problems in the stubs here
and there, memory consumption is not so nice, limitations on Groovy
annotations are not so nice.

The stubs also allow annotation processors to run on them. Of course
this does not make sense for Lombok, but if a processor is collecting
meta data for example then this is a different matter altogether.


Now I will list a few variants I will not specifically mention the
eclipse plugin, I would leave that to Eric to add if he wants to.


V1:
In this version I use javaparser to ClassNodes the Groovy compiler does
understand and then let the Groovy compiler proceed normally. The result
is a compilation of only the Groovy classes. All information relevant in
the java classes (modifiers, referenced classes, members, field
constants, imports) have to be resolved in a limited way. Limited means
that we assume any class we cannot resolve comes from Groovy and is to
be resolved by the Groovy compiler later on. In a second step we would
call Javac to compile against the files Groovyc produced. This approach
is less memory consuming than V0, since we can completely end the groovy
compilation. In fact this architecture would be somewhat extensible to
support other languages as well. Also the Java compilation would always
see the fully applied Groovy annotations. A potential problem is
annotations processors working on Java, since there is no Javac
compatible source tree. I am not sure this problem can be solved
satisfactory. An example would be compiling against a Java class using
Lombok and then not seeing methods generated by Lombok.

V2:
Collect class data from javac using annotation processing and feed that
to groovyc. This would then be a 3 stage process. First we use javac to
get the class information, but javac cannot complete compilation, since
not all classes are resolved. Then we use the extracted information to
compile Groovy. And finally we compile normally with Java.

I tried this years ago and did not manage to get this working properly.
I would have to investigate what exactly was the problem since I tried
this maybe 8 years ago. But I think I actually was able to extract the
information and my problem was more making the classes then known to
Groovy. If not done in-memory this can probably be done easily.

V3:
in-process joint compilation by sharing ASTs with Javac. This we tried
more or less with a the Google Summer of Code project. The idea is that
we let both compilers progress in parallel and concurrently resolve
missing types against each other.

This has numerous problems, mostly the lack of control over Javac, but
even Groovyc does not work as required for this. Because for this to
work you would need to progress a unit at a time as much as possible.
Otherwise Java cannot see the changes by transforms on Groovy. And then
you are basically in the same position as V0 with additional drawbacks.

V4:
Mix of V3 and V2. Use javac to extract information instead of annotation.

Frankly I am not sure we get all that many advantages of V3 and V4. If
the goal is to have completely transformed Groovy classes available to
javac, then I see possible advantages. Memorywise I don't see them. But
annotation processing would then work on both, just Groovy seeing a
method added by lombok probably not.

V5/V6:
Use ECJ/JDT instead of javac.

V7:
maybe there is a variant with language server infrastructure? I did not
really look into that the last years. Last time I spoke with the guys I
suggested adding some kind of type resolving bridge where multiple
language server can exchange type data, but they did not see a need for
this back then. Today's situation might be different.


Well... what do others think? Are we happy with our joint compilation.
Did I list something that sounds like a better alternative?

bye Jochen

Re: [VOTE] Release Apache Groovy 3.0.18

[Jochen Theodorou]

+1

Am 26.06.23 um 08:53 schrieb Søren Berg Glasius:

+1 (not binding)

Med venlig hilsen,
Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.


Den man. 26. jun. 2023 kl. 08.51 skrev Paul King mailto:pa...@asert.com.au>>:


Dear development community,

I am happy to start the VOTE thread for a Groovy 3.0.18 release!

This release includes 34 bug fixes/improvements as outlined in the
changelog:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353078
 


Tag:
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_3_0_18 

Tag commit id: 07d4af6e4d3e5fbed2cf67ae0058bdcf83042e7f

The artifacts to be voted on are located as follows (r62642).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/3.0.18/sources

Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/3.0.18/distribution


Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS


Please vote on releasing this package as Apache Groovy 3.0.18.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval

Hints on validating checksums/signatures (but replace md5sum with
sha256sum):
https://www.apache.org/info/verification.html


The vote is open for the next 72 hours and passes if a majority of
at least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 3.0.18
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 3.0.18 because...

Here is my vote:

+1 (binding)




 Virus-free.www.avast.com 


<#m_4916143649572235556_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release Apache Groovy 4.0.13

[Jochen Theodorou]

+1

Am 26.06.23 um 08:53 schrieb Søren Berg Glasius:

+1 (not binding)

Med venlig hilsen,
Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.


Den man. 26. jun. 2023 kl. 08.32 skrev Paul King mailto:pa...@asert.com.au>>:


Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.13 release!

This release includes 25 bug fixes/improvements as outlined in the
changelog:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12353213
 


Tag:
https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_13 

Tag commit id: c8eaf830d481572e1cd668b77c2fb2b444ce8f87

The artifacts to be voted on are located as follows (r62641).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/4.0.13/sources

Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.13/distribution


Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS


Please vote on releasing this package as Apache Groovy 4.0.13.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval

Hints on validating checksums/signatures (but replace md5sum with
sha256sum):
https://www.apache.org/info/verification.html


The vote is open for the next 72 hours and passes if a majority of
at least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.13
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.13 because...

Here is my vote:

+1 (binding)




 Virus-free.www.avast.com 


<#m_-8806616514831804336_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [EXT] Groovy HEAD & JDK21

[Jochen Theodorou]

On 17.06.23 01:24, Paul King wrote:

Yes

On Fri, Jun 16, 2023 at 9:10 PM Jochen Theodorou mailto:blackd...@gmx.org>> wrote:

On 16.06.23 13:08, Jochen Theodorou wrote:
 > On 15.06.23 16:55, Paul King wrote:
 >> We only upgraded to 8.1.1 a few days ago and not all tasks have been
 >> tested yet. On the version you have, you should be able to build an
 >> installation with "distBin" or "installGroovy".
 >>
 >> I just fixed "publishToMavenLocal", so update and you should be
good to
 >> go to get the SNAPSHOT artifacts.
 >>
 >> Groovy 4.0.12 should run fine with JDK 21ea. From your stack
trace, it
 >> looks like an older version of ASM or Groovy is on your classpath.
 >
 >
 > really? I cannot confirm this

sorry... run fine, not build fine. My bad

Yes, we'll need to get it building on JDK21 too if we find a need for a
Java21 vmplugin. But nothing requires that just yet.


yeah, but the problem is gradle 8.1.1 supports only up to JDK20. Even if
our code would already support JDK21, the build cannot be run with it.
As soon as you have a build script gradle will produce class files with
JDK21 (version 65), which the Groovy version coming with gradle cannot
read. At least that is my interpretation of


./gradlew clean
Type-safe project accessors is an incubating feature.


Task :build-logic:compileGroovy

Groovy compilation avoidance is an incubating feature.


Task :build-logic:compileGroovy FAILED


FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':build-logic:compileGroovy'.

BUG! exception in phase 'semantic analysis' in source unit 
'./build-logic/src/main/groovy/org/apache/groovy/gradle/CheckstyleHtmlReport.groovy'
 Unsupported class file major version 65


* Try:

Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.


* Get more help at https://help.gradle.org

BUILD FAILED in 2s
4 actionable tasks: 1 executed, 3 up-to-date


What seems to happen though is that Gradle produces a bunch of java
files and compiles these with JDK21, which Groovy then fails to load.
Anyone any idea how those files are generated?

bye Jochen

Re: [EXT] Groovy HEAD & JDK21

[Jochen Theodorou]

On 16.06.23 13:08, Jochen Theodorou wrote:

On 15.06.23 16:55, Paul King wrote:

We only upgraded to 8.1.1 a few days ago and not all tasks have been
tested yet. On the version you have, you should be able to build an
installation with "distBin" or "installGroovy".

I just fixed "publishToMavenLocal", so update and you should be good to
go to get the SNAPSHOT artifacts.

Groovy 4.0.12 should run fine with JDK 21ea. From your stack trace, it
looks like an older version of ASM or Groovy is on your classpath.



really? I cannot confirm this


sorry... run fine, not build fine. My bad

bye Jochen

Re: [EXT] Groovy HEAD & JDK21

[Jochen Theodorou]

On 15.06.23 16:55, Paul King wrote:

We only upgraded to 8.1.1 a few days ago and not all tasks have been
tested yet. On the version you have, you should be able to build an
installation with "distBin" or "installGroovy".

I just fixed "publishToMavenLocal", so update and you should be good to
go to get the SNAPSHOT artifacts.

Groovy 4.0.12 should run fine with JDK 21ea. From your stack trace, it
looks like an older version of ASM or Groovy is on your classpath.



really? I cannot confirm this

bye Jochen

JDK 21 build

[Jochen Theodorou]

Hi,

since I just got that mail with JDK21 coming along I thought I try to
run Groovy with it - fully expecting gradle to fail already. And of course

Caused by: BUG! exception in phase 'semantic analysis' in source unit
'./build-logic/src/main/groovy/org/apache/groovy/gradle/CheckstyleHtmlReport.groovy'
Unsupported class file major version 65

That is basically not surprising but I was wondering... why is it
actually the case? Should we not be able to compile with a target class
file version for the build?

From the home page for Gradle 8.1.1:
"""
With toolchain support added to GroovyCompile, it is possible to compile
Groovy code using a different Java version than the one running Gradle.
If you also have Java source files, this will also configure JavaCompile
to use the right Java compiler is used, as can be seen in the Java
plugin documentation.
"""

There is actually 2 things I would like to have. One is to be able to
use for example JDK21 for Groovy compilation, but with 16 (or something
we support) as target. And the other is to be able to additionally use a
different JDK version to run Gradle itself.

What do you guys think?

bye Jochen

Re: Harmless ctor call takes 100 ms - trait dependent problem ?

[Jochen Theodorou]

On 07.05.23 23:05, MG wrote:

H(a|e)llo Jochen,

thank you for your reply.

@POJO is a Groovy 4 only feature, so I spent several hours getting our
project to build under groovy-4.0.11, then started profiling with
different settings, with the following results:

 1. The good news is, that we might have pinpointed the or at least one
of the major reasons for the 2-3x performance drop when switching
our project from Groovy 3 -> 4:
 1. The TBKMS_Table ctor call takes about 2 to 4 times as long on
average when using groovy-4.0.11 out-of-the-box (i.e. indy),
compared to other Groovy varieties (see below).
 2. https://issues.apache.org/jira/browse/GROOVY-10307


Sigh... I wish I had the time to produce a deeply integrated Graal
version of Groovy. With Java blocking the fast paths from the early
times and MethodHandles seemingly to take a lot of init time the current
situation is really really annoying.

Which reminds me... how did you measure those timings? With warmup-phase
and long running test? A single run? Something else?


 2. The not-so-good thing is, that alas the performance of non-indy
groovy-4.0.11 with @CompileStatic @POJO on all involved traits is
still a little bit slower than groovy-3.0.14 (default, i.e. non-indy)...


still a little bit slower means what? Actually I fail a bit to imagine
that this is the fault of those table classes directly. You could try
making the table class pojo-static as well to avoid any direct meta
class creation... though the decompiled class you showed me does not
implement GroovyObject, which suggests  you do that already.


 3. I have attached the performance measurements for different Groovy
versions / compiler settings
 1. Average performance for calling the TBKMS_Table ctor ranges from
 > 400ms for groovy-4.0.11 out-of-the-box to < 100ms for
groovy-3.0.14
 2. The expected/required performance would be < 1ms


That is still a long way off


 4. I also attached the decompiled ctor for the TBKMS_Table class, one
of the two Table classes that compete for the longest ctor execution
time (both all-in-all depend on about the same number of traits).


The decompiled version may hide some things.


Anyway, if I have

class A {

  public A(a,b=0) {
println "some more code here"
  }
}

then this compiles to:

class A {
  public A(a,b) {
println "some more code here"
  }
  public A(a) {
this(a,0)
  }
}

the second constructor is really really small and exists only to
delegate to the first one, that does all the work.

So if you have

Table(String name, String shortName, Table parentTable = null, boolean
isReference = false, Schema schema = null) {

then I expect something similar. Alas none of the constructors in the
attachment is delegating using "this(..)". As a result I see a lot of
code duplication.


 1. Regarding the trait classes: At the location corresponding to
the involved traits package path I could only see some very
small, trivial interface class files in IntelliJ...


It is mostly the ctor of the table and the generated trait helper
classes I am after. A trait X would produce also a class X.Trait.Helper,
which contains the connectivity code.

But again if the table is pojo-static and the traits too, then only code
called from there or code calling that can cause the breakdown in speed
I think. There is a small chance the with invokedynamic realized casts
are to be blamed, for some slowdown, but we should be surpassing Groovy
3 in a nonstatic variant here a lot already normally.

bye Jochen

Re: Harmless ctor call takes 100 ms - trait dependent problem ?

[Jochen Theodorou]

On 09.05.23 01:09, MG wrote:

Hi Jochen,

@alas none of the constructors in the attachment is delegating using
"this(..)". As a result I see a lot of  code duplication: From my Groovy
code that is just a single ctor with default arguments, the code
duplication is created by the Groovy compiler.


That is very odd and in my opinion not normal

[...]> @I fail a bit to imagine that this is the fault of those table
classes

directly: Quite a few of them display the desired performance, but some
are not, and the biggest offenders depend on the largest & deepest
hierarchy of traits, some inheriting the same trait from more than one
source - that is all the difference I can see (I tried to find other
differences today, but the ones I saw, when checked, all had no impact
on  performance).


If I have

trait T1 {}
trait T2 extends T1 {}
trait T3 extends T1 {}

class C1 implements T2, T3 {}

then In C1 I find init code for T1,T2 and T3 and for each only once

If I do

class C2 extends C1 {}

it will have no init code for the traits, C1 is doing that already.

If I do

class C2 extends C1 implements T3 {}

then C2 contains init code for T3, which I think is actually surplus/wrong.

Could it be, that this is what adds up here?


@A trait X would produce also a class X.Trait.Helper: I just realized
that the reason I did not find these class files is, that IntelliJ does
not display; the only files accessible are uninteresting @Trait
annotated interface classes.

Unfortunately I am running out of time, I have a few days to get the
queries back to acceptable speed, so I will probably actually have to
rip out the traits, add their members to each class by hand and replace
them with interfaces...


too bad.

bye Jochen

Re: Harmless ctor call takes 100 ms - trait dependent problem ?

[Jochen Theodorou]

On 07.05.23 00:56, MG wrote:

Hi guys,

we have (a bit of an urgent) performance problem: The SQL generation
part that is an elemental part of our framework has become too slow in
certain key cases in the most recent extension to our main web application.
We have finally narrowed the cause down to what looks like the main
bottleneck, and to our surprise it is a very harmless looking ctor call
that every Table class uses to internally create references of itself:

Table(String name, String shortName, Table parentTable = null, boolean
isReference = false, Schema schema = null) {
     super(name) // Base class just stores name in String field
     this.parentTable = parentTable
     this.shortName = shortName
     this.isReferenceTable = isReference
     this.schema = schema
     this.originalTableField = parentTable?.originalTableField
}

The cost of the ctor should be something like:

   cost for delegating this-call (1)
+  cost for super-call (2)
+  cost for initiating the trait helpers (3)
+  cost for setting fields (4)

[...]

The KMS, TBKMS, etc classes look harmless enough, and the only thing I
can see is, that it seems the performance degradation seems to be tied
to the number of traits the class depends on.


That speaks for (3) getting out of hand.

It could be the meta class generation... if you have one class and 5
traits, then you generate 1 meta class for the class itself and 1 for
each helper, that would mean then 6.

And that even though the helpers do not need meta classes in my opinion.


[...]

If any one has any suggestions how to speed up our scenario, that would
be appreciated. The code this applies to is a mix of predominantly
static & some dynamic Groovy...


If possible could you use @CompileStatic @POJO on the traits and see if
that improves things? This would reduce the number of generated meta
classes in the constructor at least. They might be still created of
course. So maybe it is no complete solution. But if you can put it on
even some of the traits the improvement should be noticeable. Then we
know for sure that this is the problem and discuss further steps.

Otherwise I would have to see the bytecode of the ctors of the trait
helpers and the table class to say more

bye Jochen

Re: Disabling auto inferencing

[Jochen Theodorou]

Am 04.12.22 um 16:34 schrieb Saravanan Palanichamy:

Thanks Jochen and Christopher for helping clarify behaviour. So if I
wanted to make sure declaration and not flow type is honored, the
quickest way is to make sure flow type matches declaration by casting
it? Are there other ways inside the compiler to fix this (some options
or some indications in the variable declaration statement itself) (I
looked and didnt find anything, but thought I'd ask)?


the nodes have meta data, which usually also contains static type
information such as the flow type. You would have to make changes here.
What exactly you have to look for and change I cannot say without a deep
look into the code myself. Eric Miles would be a good address for this
though.

bye Jochen

Re: Disabling auto inferencing

[Jochen Theodorou]

On 03.12.22 15:50, Christopher Smith wrote:

I believe the feature at play is "flow typing", and it surprises me that
it would apply to variables declared with an explicit type. What version
of Groovy are you targeting, and is this compiled statically or
dynamically?


The declaration type is to be understood as an base type for the
variable, not the flow type. Which means in

Y foo = bar()
foo.x()

the flow type of foo is whatever is inferred as result type for the call
bar(). The assignment to foo is valid if the result type for the call to
bar() is assignable to Y. The call x() on foo is valid if the method x()
exists on the flow type.

This is the intended behaviour.

bye Jochen

Re: Removing some old pre-release doco

[Jochen Theodorou]

+1.. of course a nice touch would be to make autoforward any link to the
docu in for example 2.5.0-rc-3 to 2.5.18 (I actually think we do not
need to keep 2.5.0 - 2.5.17 either). Why the forwarding? To keep
potential links valid.

bye Jochen


On 24.07.22 13:45, Paul King wrote:

Hi folks,

I was thinking of removing some old versions of the doco. It isn't
that disk space is particularly tight but I think it is just easier
for folks to find versions they are after with less clutter from the
noisy pre-release versions. I was thinking of getting rid of:

'2.5.0-rc-1', '2.5.0-rc-2', '2.5.0-rc-3' (we'd be left with 2.5.0
through 2.5.18)

'3.0.0-alpha-1', '3.0.0-alpha-2', '3.0.0-alpha-3', '3.0.0-alpha-4',
'3.0.0-beta-1', '3.0.0-beta-2', '3.0.0-beta-3' (we'd be left with the
RCs and 3.0.0 thru 3.0.12)

'4.0.0-alpha-1', '4.0.0-alpha-2', '4.0.0-alpha-3' (we'd be left with
the betas, RCs and 4.0.0 - 4.0.4)

This wouldn't impact any actual releases (including doc zips) which
would all remain, just the online versions of the docs for those
pre-release versions. Changelogs or versions in Jira would also not be
touched.

Any objections?

Thanks, Paul.

Re: [DISCUSS] Groovy 5 planning

[Jochen Theodorou]

On 27.06.22 00:04, James Bond wrote:

I think  Daniel has a point here.  I too have been in FinServ (on the
periphery) for many years, and I know how slow to adopt new standards
organizations like banks can be.

That being said, I would like to suggest two relatively obvious things
to consider:

1) what's the time frame for Groovy 5 to be released?


let's say it would be another two years... if support is till 2030 it is
likely to find lots of Java8 till 2030 and beyond. Especially in those
big organizations. There will be a considerable time frame with Java8
support running and Groovy 5 out. Heck, with that time frame we might
speak about Groovy 7+ even.


2) what is the rate of the Java 8 dependent organizations switching to a
newer version, where will they be at the time Groovy 5 is released, and
(I hate to say it), how large of a percentage of the total Groovy using
developer population are they?


That would be indeed interesting to know, but those numbers do not exist.


I've watched how the Groovy developer
community is very good about continuing to release new versions of older
version of Groovy, to be sure to include necessary fixes, etc.  It's
possible that since these "laggards" (not by choice, necessarily) cannot
move beyond Java 8, perhaps an earlier version of Groovy will continue
to suffice for them until they can move to a more recent JVM.


The problem is that it means double the effort for every back port fix,
where the code base diverged a lot. On the other hand we have to
consider what type of fix would even be back ported? Security related
stuff and most likely problems in the compiler (minus new features)?
Those could possibly be done together without too much effort.


I, for one, would not like to see Groovy held back by catering to the
LCD, especially if that LCD is a very small percentage of the total
developer population.  I think Groovy needs to remain up to date and be
able to fully leverage all the more recent Java runtime and JVM
improvements to remain relevant.


Up-to-date means for me means many things here.
(1) have Groovy running on newer JVMs. That requires in the best case
only an update of the asm library
(2) transfer new language features to Groovy. They make the new Java
versions interesting for most people and while I see a need for this it
is not urgent
(3) handle conflicting API. Sometimes a new method is added to a Java
class, that already exists under the same name in Groovy, but has a
different logic. Usually we then remove the Groovy method in favor of
the Java one. But that is a breaking change and would not be backported.
Nether the less it will increase the code base divergence.
(4) handle deprecated/removed API. This part is imho a big deal. Before
Java9 we simply did not have this problem, making it much more easy to
have a Groovy 1.x, Groovy 2.x and Groovy 3.x. In Groovy 4 we removed the
old callsite caching with us expecting Java8 to go out of business soon
and the module system to become a *must*. We still have to deal with the
fallout from that one. The SecurityManager is another big project. Is
Groovy 4 still Groovy 4, if we simply remove it? If we limit the Groovy4
support to be really Groovy on Java8, then it means to keep the
SecurityManager infrastructure in Groovy4 and remove it in Groovy5+

Also assume it is 2030, we have Groovy 7 and Groovy 4 in parallel...
what is the next version? Assuming they do not extend the extended
support for other versions it would be Java21 for 1 year.



My 2c, as a long time Groovy fan, but first time poster.


you are welcome to write more often

bye Jochen

Re: [DISCUSS] Groovy 5 planning

[Jochen Theodorou]

On 26.06.22 19:39, Daniel Sun wrote:

AFAIK, quite a lot of Groovy users are still using Java 8 because their company 
have no plan to upgrade systems to run on Java 9+. It is especially common for 
bank systems I have been working on for years, so it's better to continue 
supporting Java 8 in Groovy 5 releases.


When is it likely for them to change? If we go by the Oracle extended
support it would mean to have Java8 in till 2030.

if we had the manpower I would suggest making a java8 version of Groovy
5. But I think that is not realistic. It will be difficult to support
deprecated/removed API. I mean it is a bit more than in the past where
it was about backporting features to older Java versions or enabling
language only features on older Java versions. The alternative would
then be to not to support that feature anymore... like for example the
SecurityManager. But would such a Groovy-Version still be useful in its
current usage?


bye Jochen

Re: StackTrace sanitization list

[Jochen Theodorou]

On 23.06.22 11:41, Paul King wrote:

I tend to agree with you but it does get a little tricky. If "my own
user code" is making use of e.g. Java collection classes, then
sometimes I'd really like to see "one level down".


one level down... well, for you in

[...]

Caught: java.lang.NullPointerException
java.lang.NullPointerException
 at java.util.Hashtable.containsKey(Hashtable.java:336)
 at java.util.Hashtable$KeySet.contains(Hashtable.java:654)
 at 
java.util.Collections$SynchronizedCollection.contains(Collections.java:2023)
 at java.util.ArrayList.batchRemove(ArrayList.java:726)
 at java.util.ArrayList.removeAll(ArrayList.java:696)
 at Script.run(Script.groovy:9)


it is the removeAll, so one level down means for you one level down from
the caller (skipping indy code) - which is somewhere in the "middle" of
the trace if not sanitized in this example.

Could we make the sanitizer more intelligent to recognize the caller
(Script.groovy:9) and the method called (ArrayList#removeAll) to then
sanitize the rest in a more aggressive way?

I think actually that is maybe thought a bit too short... there can be
multiple such places, that you want to retain. Then we would have to
recognize user code vs non-user code, which is what the sanitization is
kind of about...

How about doing something like this:
* have a "hard sanitizer" list, consisting of packages/classes, that
will be always removed. like "sun." or GroovyStarter
* have a "soft sanitizer" list, consisting of packages that will be
removed only under condition
* in a first iteration we remove the frames with the hard sanitizer, in
a second iteration we remove all frames with the soft sanitizer if the
frame two frames ago has been removed. Going with the full trace from
before the expected result would then be:
* two frames ago is true if the frame is the top frame, or the first
frame in the list as well of course


java.lang.NullPointerException
at java.util.Hashtable.containsKey(Hashtable.java:336)
at 
java.util.Collections$SynchronizedCollection.contains(Collections.java:2023)
at java.util.ArrayList.removeAll(ArrayList.java:696)
at Script.run(Script.groovy:9)


hard list: org.codehaus.groovy.tools.GroovyStarter, java.lang.reflect.,
sun., org.codehaus.groovy.vmplugin

soft list:
java., groovy.

I would actually also always keep the last frame, which in this case
just be chance is true, meaning the trace above has only 1 unwanted
frame for me.

Maybe somebody else has a better idea

bye Jochen

Re: [VOTE] Release Apache Groovy 4.0.3 (take 2)

[Jochen Theodorou]

+1 (binding)

On 01.06.22 13:24, Guillaume Laforge wrote:

+1 (binding)

On Wed, Jun 1, 2022 at 12:49 PM Paul King mailto:pa...@asert.com.au>> wrote:

[This fixes the groovysh issue Daniel found.]

Dear development community,

I am happy to start the VOTE thread for a Groovy 4.0.3 release!

This release includes 40 bug fixes/improvements as outlined in the
changelog:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12351650



Tag:

https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_3


Tag commit id: 63283624d3b87d5bcb6688bc238c126d829dbc6d

The artifacts to be voted on are located as follows (r54813).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/4.0.3/sources

Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/4.0.3/distribution


Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/release/groovy/KEYS


Please vote on releasing this package as Apache Groovy 4.0.3.

Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval

Hints on validating checksums/signatures (but replace md5sum with
sha256sum):
https://www.apache.org/info/verification.html


The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release Apache Groovy 4.0.3
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 4.0.3 because...

Here is my vote:

+1 (binding)



--
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/ 
Twitter: @glaforge 

Re: Surprising behavior when having Integer & Long in Set & Map

[Jochen Theodorou]

On 13.05.22 08:34, Nhan Vo wrote:
[...]

Was it indeed an intention to have numbers equal in set comparisons but
not in map lookup via keys?


yes. Same for String and GString.


bye Jochen

Re: [DISCUSS] Groovy 5 planning

[Jochen Theodorou]

On 11.05.22 03:05, Paul King wrote:

Hi folks,

We still have a few things on our TODO list to improve Groovy 4, like
performance and some regressions, but we also need to start planning
for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
begin, so feel free to comment, but I don't expect many of us will
have time to act on big items straight away. As always, Apache
"do-ocracy" wins the day for starting progress on such items!

For now, I mostly just want to tackle one aspect right now - the
minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
4 but I think we need to bump to at least JDK11 for Groovy 5.


In my experience JDK11 or higher is very widespread by now.


We have a VMPlugin mechanism which allows us to make use of features
in newer JDKs without bumping up the minimum version and we'd still
continue with that approach. However, there are many API changes in
the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
of those changes through the VMPlugin mechanism would blow out the
associated interface(s) substantially and limit certain choices.
Bumping to JDK11 provides a nice compromise on keeping just the more
critical functionality in the VMPlugin hierarchy and allows us to
start removing our usage of deprecated JDK APIs and moving to their
replacements in other places in the codebase. (As a concrete example,
groovy-console uses the deprecated modelToView method from TextUI
which is replaced with modelToView2D in JDK9+. It is a lot cleaner
just moving to the new APIs than pushing that through the VMPlugin
mechanism).


I would not want the VMPlugin mechanism depend on graphics classes. If
something like that, I would probably do something comparable just for
that module as internal API.


Some other projects have moving straight to JDK17 on their roadmaps.


afaik many more things have been deprecated in the time from 11 to 17
and partially replaced with new APIs, so a JDK17 build will probably be
required, but I would fix the decision on details. Like for example the
upcoming SecurityManager removal.. it is deprecated in 17 already I thnk.


I
am not proposing we do that as yet but I'm interested in others'
views. Groovy has typically tried to keep the minimum version as low
as possible only jumping to when functionality dictated it as
necessary. Offering users features similar to what Java provides but
on earlier JDK versions has been one of Groovy's selling points for
many users.


Groovy was able to run on pretty old version of Java in a time where
Java had a quite stable API, new major versions took years and
deprecation barely happened. That is all over now. And that means for
Groovy that that stand is very difficult. With limited resources it is
better to go with the new version, than to spend a lot of time in
finding ways to conform to old and new versions at the same time. The
last big change in the past was the support for Java5. And the changes
required in codebase to fully switch to 5 then took many years.


Further Groovy 5 roadmap discussions may make the case
stronger for JDK minimum greater than 11, but for now I was proposing
we take the first small step and cross other bridges when we get to
them.


I must say I do not follow the features of new Java versions all that
much anymore. It is just too much to get used to a new version every
half year in detail, when that is not what you are doing as part of your
job. Java 17 being an LTS version is then of course different. But Java
17 does not have any features I "need" in my projects. The foreign
memory access API could be interesting (and dangerous). But does it
require a Groovy adaption? Sealed classes are interesting language wise.
For me they are overengineering in class design. the whole purpose of
those is actually supporting pattern matching with a closed set of
classes, to be able to ensure your matching covers all cases. Afaik we
do not even do that for enums (and I never used that even in Java)


A related but orthogonal discussion we need to have is when to phase
out our (optional) use of the SecurityManager-related APIs (related to
JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
suggest Groovy 6 is the version for removal. Having said that, we
could consider parts of the codebase like groovysh as candidates for
removing the security manager in Groovy 5 - though the Java team
haven't proposed their replacement for our System.exit interception as
of yet.


What really annoys me about
https://bugs.openjdk.java.net/browse/JDK-8199704 and comparable ones is
that the first deprecate an API, without having replacements for the
obvious problems. It means that the version, that provides the new API
will be most likely a version that has the SecurityManager removed,
stealing from you the ability of a transition.

The question is where a SecurityManager is still relevant. Applets are
gone. That leaves server side scripting.. for example Jenkins. What do
they 

Re: Groovy 3 -> 4 Performance Degradation Sample

[Jochen Theodorou]

On 09.05.22 22:13, MG wrote:

Hi Jochen,

our code certainly creates a lot of (short lived) class instances*, but
we do not dynamically create new classes, so the overhead of creating
the initial Indy callsites should only be incurred once at the
beginning, and then should no longer play a role. So if the same SQL
creation code is executed in a loop as in the sample script I provided,
each loop after the first should be as fast as non-Indy Groovy, no ?


You pay the cost every time the callsite gets invalidated. If you do

def getMeta(table, column) {
  table.getMetaData(column)
}

getMeta(PERSON, PERSON_NAME)
getMeta(PERSON, PERSON_STREET)

class PERSON extends Table {
...
  class PERSON_NAME extends Column {...}
  class PERSON_STREET extends Column {...}
...
}

then you have 3 callsites, but 4 inits, since the callsite in getMeta
will be invalidated for the change from PERSON_NAME to PERSON_STREET.
And if you do

10.times {
  getMeta(PERSON, PERSON_NAME)
  getMeta(PERSON, PERSON_STREET)
}

you get 20 callsite inits plus 19 callsite invalidations in getMetaClass.

Even with caching.. in the current implementation we check only on the
receiver, but here an argument is changing.

If I rerun my test with 1 classes a 1 method and let this run for 500k
times then I get

Groovy 4 indy: 68-73
Groovy 3 non-indy: 90-101

Of course the less iterations the worse for indy:

Groovy 4

1k: 1215
10k: 231
100k: 105
1m: 70

Groovy 3
1k: 780-1000
10k: 169
100k: 96
1m: 90

each run involves running the code 10 times, then measuring 10 times to
really really trying to exclude any initial costs. And from that
perspective Groovy 4 indy is better.



Do you think that a Groovy feature such as e.g. traits could be
responsible for the constant need for callsite creation ? A less-used
Groovy feature such as traits, that we use only in certain, more complex
scenarios, being responsible might explain why the performance problems
a) occur only in more complex test cases, and b) up to date no other
project seems to suffer the same problem as we do...

[...]

I do not remember anymore how they are compiled - but from what I
remember I think there is a level of indirection involved, just don't
remember if that call is in dynamic or static. If the first, then it
might be


bye Jochen

Re: Groovy 3 -> 4 Performance Degradation Sample

[Jochen Theodorou]

On 09.05.22 17:41, MG wrote:

Hi Jochen,

since I am not feeling well right now, just some quick answers to some
of your questions:

 1. I am not at liberty to release the source code from our project, not
even partially, so these JARs are currently all I can provide. I
felt when I reported this problem initially, there were doubts that
it even exists, so after I could not pinpoint the problem on my
side, I invested the time to extract these project parts, clean them
from any historical references to other modules etc and supply them
in compiled form.


I think I can test if it is really my assumption or not. I made myself a
little program, that will create a class with many methods and one more
method, that is calling all of them, one-by-one. The methods are empty
and nothing takes parameters. I then put this in the compiler and
measure times for creating the class and running the methods.

For 1000 Methods I get on my machine these results for Groovy-3.0.9
non-Indy:
1 Class: 36ms
10 Classes: 114ms
100 Classes: 985ms
1000 Classes: 8227ms

the last case means, that 1+ million methods are executed inside of the
test class

Then I repeat the test with Groovy-4.0.2 Indy:
1  Class: 137ms(* 3,80)
10 Classes: 670ms  (* 5,88)
100 Classes: 3711ms(* 3,77)
1000 Classes: 108235ms (* 13,16)

I would not classify these numbers as a proper test, but it does hint at
what I had assumed... creating the initial callsites in indy is too
expensive

the script I used:


def CLASSES = args[0] as Integer
def METHODS = args[1] as Integer


def methods = ""
def calls   = ""
METHODS.times { i ->
  methods += "\ndef foo$i(){}"
  calls   += "\nfoo$i()"
}

def gcl = new GroovyClassLoader();
def testClasses = (1..CLASSES).collect{
def testClass = """
class MyPerfTest$it{
  $methods
  def run() {
$calls
  }
}
"""
gcl.parseClass(testClass)
}


def time1 = System.nanoTime()
for (clazz :testClasses) {
  clazz.newInstance().run()
}
def time2 = System.nanoTime()
def timeDiff = (time2-time1)/100
println "Time = $timeDiff ms"


While this is surely not "real world" my goal was testing the callsite
creation, and I think the test does this well enough. Why exactly this
scenario? Because I know indy can perform well in micro-benchmarks,
where you crunch a number in tight loops. and if there is no problem
there, then it must be with the many callsites you tend to visit only
once - like here.


 2. As I have said in previous posts, the performance degradation occurs
with non-Indy vs Indy. In fact this is how I could pinpoint that
Indy was to blame: After realizing that our test suite ran for 3h
under Groovy 4, instead of 1h under Groovy 3, and that this was not
restricted to a few tests becoming really slow, but was a more or
less general phenomenon (which was puzzling), I ran the test suite
under Groovy 3 Indy (for the first time), and got basically the same
reduced performance.


I had a suspicion for a long time already actually. Bad since I sadly
have barely any time for Groovy these days... and checking this can take
very very long.

[...]

 4. Throwing away the first test loop: It is a bit of an acdemic
discusssion, since Groovy 4 performance is always 2 to 3 times
slower in any case. You can execute the test script interleaved
between Grooyv 3 / 4 multiple times to see how measurements develop,
but I would say it is clear that Groovy 4 is always way slower than
Groovy 3 for this test, and that is all that matters :-)


in my little test factor 2-3 times is for me factor 3-4 and that was my
best case.

bye Jochen

Re: Groovy 3 -> 4 Performance Degradation Sample

[Jochen Theodorou]

On 07.05.22 01:55, MG wrote:

Hi Groovy devs,

I have finally managed to extract a sample from our Groovy framework
that only uses our most basic modules and still exhibits the 2-3x
performance degradation between (non-indy) Groovy 3 and Groovy 4 I
already described in multiple posts a while ago.
The code was built using the latest Groovy releases (3.0.10 / 4.0.1),
you can find the 2 JARs & a test script at:

https://github.com/mgroovy/groovyperformance/tree/trunk/groovy4_performance_public_sample


The problem is that the jars contain compiled Groovy code only, which
means we do not know the source for them... makes it a bit harder to
find out what is actually going wrong by trying to reproduce it


To check the performance:

 1. Open a GroovyConsole window for Groovy 3.0.10
 2. Do Script\Add JAR(s) to ClassPath: groovyperformance-3.0.10.jar
 3. Load & execute groovysql_performance_groovy4_2_xx_yy_.groovy

Analogue for Groovy 4.0.1 with groovyperformance-4.0.1.jar.

On 3 different PCs I consistently get results as shown below (each timed
test step executes the same code 100x, each time creating the same
simple SQL GString using our framework):

*Groovy 3.0.10*
0) dt = 7.99 ms
1) dt = 2.01 ms
2) dt = 1.53 ms
3) dt = 1.65 ms
4) dt = 1.36 ms

*Groovy 4.0.1*
0) dt = 16.51 ms
1) dt = 7.14 ms
2) dt = 5.83 ms
3) dt = 6.6 ms
4) dt = 6.24 ms


just a note, since you mention this later: This is Groovy 3 non-Indy vs.
Groovy 4 (always indy)


Throwing away the first loop, which includes framework setup time,
Groovy 3 outperforms Groovy 4 by a factor of about 3 (Note: On my
notebook the factor is closer to 2).


I am not sure that throwing out the first loop is actually right to do.
As always with benchmarks, the problem is partially figuring out what
you are really measuring. My assumption is that the initial callsite
creation is much slower in indy, than it was with non-indy. If you have
a lot of 1-time only invocations, this would pile up quite a bit.


Execution times generally decrease when starting the script multiple
times, but the best dt I have observed on the PC the above measurements
were taken was 3.3ms, whereas Groovy 3.0.10 goes down below 1ms (In any
case this is irrelevant for practical applications, since here a short,
identical code segment will not be executed n x 500-times in a loop).

[...]

You have to imagine it like this for non-indy...
You do a method call, Groovy finds the method that is called and
generates bytecode for a call to this method, guarded by some class
(receiver and parameters) checks basically. Subsequent call are then
done using this optimized path and all you pay compared to normal Java
is the class checks, some special logic for category methods and like
2-3 method calls. All can be inlined pretty well. But won't with this
low amount of calls. Still the path itself is pretty fast already on the
second execution.

The problem here is that the first execution is actually done from
within the callsite code. This has to happen, as somebody has to do the
invocation in the end. And even the nth invocation is done from Groovy
created code. If you have to deal with the java module system, then this
is a killer. But anyway. Let us note for the first time call performance:

method selection + small (unverified) bytecode generation + actual
invocation, with 2-3 method calls deepness and some type transformations
before you get to the actual method

With Indy you have the bootstrap method, which is called and here we do
basically the method selection and produce method handles, method types,
guards and type transformations. There is also some kind of cache

Now the question is, what is going wrong. The method selection is not
the cost, since that is in both the same. Type transformations are done
differently in both. In the callsite code we basically generate code for
it, in indy we create a handle for it.

Basically I see 2 basic possible troubles:
1) creating the initial selection is too expensive
2) the caching is not actually working

The first one is one I suspect. In my opinion Indy is slower because of
the type transformation code, because of how MethodTypes are produced
for Indy, because an invocation of generated code is much faster than a
method handle (which is kind of interpreted before Java creates bytecode
for it). A bit slower would be no problem of course.

I spend the whole Saturday looking at the code and trying to understand
what is happening

Well.. the structure seems to be that there is a size 4 LRU cache per
callsite. But since the threshold is so high nothing is ever going to be
cached. If I set the threshold to -1 (0) actually would not work, since
there is a comparison with >, not >=. Every cache entry can be seen as a
pair of something that will call the target and a fallback. The fallback
seems to be to select the method again. Imho that should lead back to
the cache, otherwise the cache makes no sense in a case of reselection
of the cached method 

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[Jochen Theodorou]

On 18.11.21 15:10, Alessio Stalla wrote:

Dates are not something to mess with lightheartedly. All kinds of weird
exceptions exist. In some dates in some timezones, midnight (i.e. 00:00)
does not exist:
https://stackoverflow.com/questions/18489927/a-day-without-midnight

These kinds of implicit conversions may look like they simplify things
but actually they hide nasty bugs under the carpet, that you'll only
discover when it's Jan 1st 2031 and you get angry calls in the morning
while you're hungover, or when your first customer who was born at, I
don't know, 1978-08-01 at midnight in the Fiji islands signs up into the
application.
Please, don't do that. MySQL did that, and I've already suffered because
of it.


I learned that everything with Strings and times/dates/resources/outputs
for multiple languages/regions are not to underestimate ;)

But this here is really news to me... wow

bye Jochen

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[Jochen Theodorou]

On 17.11.21 20:28, MG wrote:
[...]

 3. I have never encountered any other assumption than the one that a
Date carries the implicit time of midnight (00:00:00.000...). What
other time would one logically pick, given that time intervals are
by convention typically closed on the left and open on the right ?


But you have here already trouble. you can take the start of the day, or
the end of the day. both is midnight, both based on the same date, but
they are basically 24h apart. In my last project we mostly used end of
the day for example. And in some parts actually 2:00 in the morning,
because it is the time to run after some processes... which did not
proof to be a good idea btw.

bye Jochen

Re: Groovy 4.0.0-beta-1 Performance

[Jochen Theodorou]

On 14.10.21 01:24, MG wrote:
[...]

Alas performance-wise what we surprisingly found was, that the
performance of our main web application dropped by a factor of 2 (table
refresh) to 3 (startup).
Executing our test suite showed a similar picture. Since no immediate
source for this performance drop emerged, we checked the performance of
Groovy 3 Indy, more to rule out that the performance reduction had
something to do with invokedynamic;
as can be seen in the table below, to our surprise performance
degradiation of Groovy 3.0.9 with full invokedynamic (Groovy JARs &
IntelliJ compiler switch/checkbox active) was in fact in most cases
close to the one seen with Groovy 4.0.0-beta-1, pointing to
invokedynamic  as the potential cause.

Right now it looks to us, as if Groovy with invokedynamic for us is just
"leaking performance everywhere", with no clear source.
Speed changes range from about 0.6 (i.e. a speedup) to about 5.0, with a
large bias towards a slowdown by a factor of 2.0 to 2.5. The overall
time of the test suite increased by a factor of 2.37 (G3 Indy) and 2.45
(G4) respectively.

Any ideas what could be the cause of this unexpected slowdown or where
we should put our focus in analyzing this, to create a test case
independent of our framwork ?


Unless someone here has a concrete candidate it will be difficult to
find out what exactly the problem is without having the code itself I
guess.

What I can tell you for sure is, that invokedynamic has a big problem
with 1-time calls. It is much more expensive to generate the callsite
for invokedynamic than it is for our old callsite code (which will stop
working) and also of course compared to direct method calls.

By the nature of performance tests, this is rarely measured though and I
don't believe that this is causing the problem here.

A profiler, that profiles also the Groovy runtime code, could maybe show
code from the indy part, that is involved a lot and maybe should not.

If I would have no clue what this really could be I would actually do
the following.. I would turn on the hotspot compilation tracing,
printing me the machine code it produces and of which methods. Then I
would compare what methods are not compiled in indy? These are
candidates for being significant.

I am curious to see what others suggest

bye Jochen

Re: () call-type syntax for functional interfaces?

[Jochen Theodorou]

On 29.04.21 15:32, Christopher Smith wrote:

Sure, this is theoretically possible (though many functional interfaces
aren't annotated), but the convenience I'm asking about would have to be
compile-time, because it would depend on the declared type (which is
part of why I suspect it might not even make semantic sense in the
underlying dynamic model).


why does it have to be compile time only? I don't quite get that. The
problem you have to face is of course an Object, which realizes a
functional interface, but also has a call method (not part of the interface)

bye Jochen

Re: GDK retrofit for Java functional interfaces

[Jochen Theodorou]

On 28.04.21 03:43, Christopher Smith wrote:

This would be both expensive and problematic with static mode, which is
what I use almost exclusively for production code.

On Tue, Apr 27, 2021, 20:26 Remi Forax mailto:fo...@univ-mlv.fr>> wrote:

[...]

It may be simpler to have a conversion from any instance of a
functional interface to a Closure,
with closure.call() calling the abstract method of the functional
interface.

This will require to check at runtime if a class implement a
functional interface, to wrap the instance in a Closure.
It would be cool if the annotation @FunctionalInterface was declared
with a retention RUNTIME, so the check to know if an instance is a
lambda or not will be easy.
But wait, it's already the case, someone thought about that in the
lambda expert group :)


If this way is expensive solely depends on the implementation. Of course
it is always more expensive than "no more conversion needed"

I want to give you a different angle your original question. Let us put
our method calls with Closures in two categories:

* Fixed Scope
Where we have attached code blocks with the same restrictions as
functional interfaces in Java, only that they would be instances of
Closure. They may capture and modify variables of the surrounding
*static* scope. *collect*, may support different arities, but important
really is that it does not mess with the resolution. This is an example
of Fixed Scope

* Altering Scope
Where the method to be called is using the resolving strategy and or
delegate to change the resolution of variables. *with* requires to
change the resolution strategy, so it can't take a functional interface
and is an example of Altering Scope.


Which means there are methods with scope alteration and such without,
and only those without can be using Functional interfaces.


On a practical level there is the current problem (unless Daniel "fixed"
that and I did not notice. As I cannot follow the project as much
anymore, this is entirely possible) that calling a method with
functional interface using a code block in Groovy will still create a
Closure, then convert the Closure with a Proxy to the interface. This is
of course less efficient then calling into the interface implementation
directly.

bye Jochen

Re: Ordering of AST transformations

[Jochen Theodorou]

On 21.01.21 02:10, Christopher Smith wrote:

Sorting the list should be inconsequential, but you seem to miss my
concern, which is about the loop nesting:

A) for each transform in list, visit each node
B) for each node, visit by each transform in list

In case B, transforms wouldn't entirely execute as distinct "layers"
across the compilation unit but would rather be interleaved as the
compiler proceeds through the AST. In that case, the effect of ordering
is highly constrained.



In fact the compiler uses B on a per phase base. In each phase a
transform may cause a new source unit to be added to the compilation,
its class nodes then transitions though the phases, till they reach the
same phase as the current overall compilation is in.

But defining an order for a class node for transforms in the phase is
still possible and should cover almost all cases.

My problem is more identifying the transforms by name individually. Lets
say we have transform X in the compiler and transform U defined by the
user with U should run before X (U

Re: Getting return type of generated Closure at runtime

[Jochen Theodorou]

On 19.01.21 09:28, Jan Lukavský wrote:

Hi OC,

I'm pretty sure Closure has a return type, that is what the type
parametr V in Closure stands for. When source is compiled using at
least @TypeChecked, the return type (e.g. long as in the example I gave)
should be known and (I suppose) accessible during runtime somehow.


There is a return type inferred by the static compiler for a Closure in
Groovy. But the compiler is of course at compile time, not runtime.
Though in case of


String script = "def a = { 1L }";
Closure closure = (Closure) compile(script).run();


you could of course have access to the compiler. Basically you would
progress the AST and then find the Closure node and get the inferred
return type from it..

I am not 100% sure, but I think we do not store the type in the generics
information, otherwise there would be another potential way

bye Jochen

Re: Alternatives to try/finally code structure

[Jochen Theodorou]

On 21.11.20 20:29, Milles, Eric (TR Technology) wrote:
[...]

I was thinking of something like this so as not to overload the try keyword:

class Foo {

   def bar() {

     push (field1 = value, field2) { // AST would be re-written to
try/finally like Scenario 1/2

   baz()

     }

   }

   ...

}



how about


class Foo {

  def withState(tryState, code) {
def finalState = state
try {
  state = tryState
  code.call()
} finally {
  state = finalState
}
  }
 
  def bar(){
withState(value) {
  baz()
}
  }
}


could be a mixin... but if your requirement is to avoid the creation of
additional objects, then this will not work, as the Closure will be
created new every time. And then a macro would be indeed better.

bye jochen

Re: [DRAFT] Apache Board Report November 2020 (reporting on Aug/Sep/Oct)

[Jochen Theodorou]

+1

On 10.11.20 13:43, Paul King wrote:

I'll also mention the latest TIOBE index briefly.


Virus-free. www.avast.com



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Nov 10, 2020 at 4:55 PM Paul King mailto:pa...@asert.com.au>> wrote:


Hi Folks,

Any other updates/comments before I submit our latest board report?
(Due tomorrow)

Thanks, Paul.

===>8==

## Description:
Apache Groovy is responsible for the evolution and maintenance of
the Groovy
programming language

## Issues:
No issues requiring board attention at this time.

## Membership Data:
Apache Groovy was founded 2015-11-18 (5 years ago)
There are currently 20 committers and 10 PMC members in this project.
The Committer-to-PMC ratio is 2:1.

Community changes, past quarter:
- No new PMC members. Last addition was Daniel Sun on 2019-05-06.
- No new committers. Last addition was Mikko Värri on 2020-06-03.

## Project Activity:
We continue to work on bug fixes for 2.5 and 3 and continue to assist
other non-Apache projects within the Groovy ecosystem move to 3.0.

We are also working on our roadmap for Groovy 4 and recently released
our first alpha version. Groovy 4 GA is expected next year.
Some interesting aspects (some have incubating status) of the release
include a contributed design-by-contract module, a language
integrated query module, move to org.apache.groovy maven coordinates
from legacy org.codehaus.groovy, additional built-in type checkers,
additional built-in macro methods, record-like classes and numerous
legacy consolidation activities.

Recent releases:
3.0.6 was released on 2020-09-29.
4.0.0-alpha-1 was released on 2020-09-29.
2.4.20 was released on 2020-07-22.

Downloads (Maven central/bintray only):
- For Aug/Sep/Oct quarter: approx 93 million
- last 12 months: ~310M
- since 2012 (when we started keeping stats from above repos):  ~670M

## Community Health:
The overall community status remains healthy. The community tries very
hard to be welcoming and interesting discussions continue to take place
at appropriate times. Large endeavours currently take a while to
progress
due to the part-time nature of most contributors.

One key community building aspect for the project was our participation
in ApacheCon@Home. The project had a dedicated track and received
interest
from numerous speakers. There were two days of talks, a workshop and
a hackerthon.

This quarter, 318 (575) commits were contributed from 12 (16)
contributors
including 7 non-committer contributors (5 new) to the main
branch (all branches/repos).





Virus-free. www.avast.com




<#m_4392882591858557772_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Stub constructor selection (related to GROOVY-9777)

[Jochen Theodorou]

On 11.10.20 23:32, Keegan Witt wrote:

Related to https://issues.apache.org/jira/browse/GROOVY-9777 that was
noticed by someone last week, I'm thinking
JavaStubGenerator.selectAccessibleConstructorFromSuper should select the
closest matching parent constructor related to the number and type of
parameters in the child.
The code has a variable named bestMatch, but it seems to me (unless I'm
misreading) that it functions more like firstMatch.  Other than it being
a more complicated implementation (I'm still thinking about how I'd do
it), was there any reason to avoid this?


So far the rule was, that if the wrong constructor has been chosen, use
a cast to force the right one. Yes, that mans adding a cast in Groovy
code, you actually do not need - even if it can dramatically reduce the
bytecode size for the generated constructor.

The stub code on the other hand is no executed code, we need to only
select *any valid* constructor and things are fine. So of course you can
try to find a better matching constructor, but you don't actually gain
anything compared to selecting another correct constructor.

bye Jochen

Re: [DRAFT] Apache Board Report August 2020 (reporting on May/Jun/Jul)

[Jochen Theodorou]

+1

Re: [DRAFT] Apache Board Report August 2020 (reporting on May/Jun/Jul)

[Jochen Theodorou]

On 10.08.20 12:57, Paul King wrote:


Hi Everyone,

Any other updates/comments before I submit our latest board report? (Due
in a couple of days)


gcontracts falls in August, thus would be part of the next report?

bye Jochen

Re: Parrot parser customization

[Jochen Theodorou]

On 09.08.20 01:54, Saravanan Palanichamy wrote:

Hello everyone

If I wanted to introduce new syntax in my groovy script, how would I go about 
doing it? I want to embed custom syntax directly into the groovy file and have 
it be parsed into my custom AST nodes. An example would be

myFunction() {
List tableValues = select value from mySQLTable where 
(select tableName from myTableNames where user = $userName)

  ... Use table Values
}


if you have


List tableValues = select value from mySQLTable where (select 
tableName from myTableNames where user == userName)


the Groovy parser should parse this as:


List tableValues = 
select(value).from(mySQLTable).where(select(tableName).from(myTableNames).where(user 
== userName))


which means except that I have userName instead of $userName it should
be valid syntax.


I want to enable a few behaviors
a) Check for syntax correctness (which is why I want to parse using antlr 
grammar)
b) Check for semantic correctness (I suppose if I parsed this into my custom 
AST nodes, that takes care of that. I could make an SQLExpressionASTNode and 
validate things there)
c) Enable a debug experience where I am able to see the result of the inner SQL 
first and then see it move to the outer SQL (this would be super awesome, but I 
realize this is in the purview of the groovy IDE plugin. I am asking here to 
see if I can get any pointers)


Groovy is a good language for inner DSLs, that is DSLs written in the
syntax of the language. Partially because of that Groovy is quite a
complex language, and complex languages tend to be a tad difficult to
extend further on the grammar level. Which is why we do not really
provide hooks into our antlr code for people to extend this. Long ago we
had the idea of specially marked blocks for which you can define your
own sub grammar, but it never seemed really to come to a acceptable
solution.

Another idea is of course to just use a string, as you wrote:


My limited ideas so far are to annotate the List declaration with @SQL, hook 
into the semantic phase to translate the select clause (embedded in a gstring) 
into a validated, redirect into a custom function call.

so if I see

@SQL List tableValues = "select "

I'll convert it to
@SQL List tableValues = sqlRunner.run("select ...")

This does not get me debuggability though and it feels contrived


To get debuggability you will need to place the inner/outer SQL into
variables with line number information (and noncolliding names maybe) in
your new AST.

I prefer the String solution these days

bye Jochen

Re: Groovy as a JVM-less Bash-Script/Perl/Python alternative ?

[Jochen Theodorou]

On 06.08.20 12:35, Paolo Di Tommaso wrote:
[...]

I saw almost no interest in this community
on the possibility to have a groovy interpreter/compiled based on the
new Truffle subsystem
, which it has
already proved to be able to deliver a minimal footprint and high
performance with dynamically typed lang such Ruby
, R
, Python
, and others
.

I think this should be a possibility to be taken in consideration.


into consideration most certainly... I would love to take the time to
make something like this fly... but I don't see me having the time

bye Jochen

Re: [DISCUSS] Proposed new optional module: groovy-contracts

[Jochen Theodorou]

On 03.08.20 11:50, Guillaume Laforge wrote:
[...]

And honestly, it's pretty rare that we have to dig in anyway.


that could be true in case of gcontracts.
For groovy-core it certainly is not true. Especially if the code part I
am looking at is unfamiliar it is very important to get why some things
are how they are. That is also why it was so important to have all the
old codehaus issues in apache.

bye Jochen

Re: [DISCUSS] Proposed new optional module: groovy-contracts

[Jochen Theodorou]

On 03.08.20 07:57, Paul King wrote:


Hi everyone,

The GContracts project (design-by-contract extension for Groovy) has
been archived:

https://github.com/andresteingress/gcontracts/

I believe there is sufficient merit in the functionality it offers for
us to consider taking up support of the codebase, and the project owner,
Andre Steingress, is happy for that transition to take place.


I think there are some regulations to follow from the ASF side. Since
you and Andre are the sole committers it should not be too difficult.
Best of course would be if Andre would be a Apache member, then we could
do this as simple code contribution


We could try to re-invigorate GContracts outside the ASF but I think our
community where a larger pool of folks can contribute when they have
availability makes more sense than another single person trying to take
it over and then potentially running out of steam down the track.

We could give it it's own repo and have it as a subproject but for now I
think it is easiest just to have it as an optional module in the core
repo (targeting Groovy 4). In the PR, I have marked the main annotations
as @Incubating for the time being. For further details, see here:

https://github.com/apache/groovy/pull/1337
https://issues.apache.org/jira/browse/GROOVY-9671


+1 except... would this loose the history? That would not be nice.

bye Jochen

Re: [PROPOSAL]Support conditional return

[Jochen Theodorou]

On 30.07.20 18:08, MG wrote:

1. Hiding a semantic "if" inside a "for"-loop syntax is not good, in my
book - in C++ I would have introduced a "returnIf"-macro to make the
intention clear in that case... ;-)

2. I was also thinking along the same line, but more like:

if(it = goo(); a>6 && it>10) { return it }

How does the return know what to return in your example, btw... ?-)

3. Would the "it" variable in the ClosureList move from term to term,
i.e. it would always reference the last term before the current one, or
always refernce the first ?


the idea in the original ClosureList was that each element of the list
is a Closure, the only difference being that they share the same
variable scope. So (def it = goo(); a>6 && it>10; return it) would
absolutely allow for the declaration of a variable it, to be used in the
condition and the return. The method taking the ClosureList, here "if"
determines order and meaning of the elements..

What of course does not work is the return ;) Sorry, forgot that.




Cheers,
mg

PS: The difference between
returnIf (goo(); a>6 && it>10)
and
returnIf (goo(), a>6 && it>10)
is of course miniscule, and maybe the second variety might actually be
less confusing... (?)


yeah, I think if we go for that returnIf, we really should go for the
semicolon

 bye Jochen

Re: [PROPOSAL]Support conditional return

[Jochen Theodorou]

On 30.07.20 01:10, Daniel Sun wrote:

Hi mg,

  I like your idea, but it's hard for IDE to infer the type of `it` during 
we coding.

```
returnIf(a > 6 && it > 10) { goo() }
```



long time ago I made the suggestion of a ClosureList based on the
classic for: "(" expr (";" expr)+ ")". It  got shot down very much for
being so ugly, but using that, we would get this:

```
retunIf (goo(); a>6 && it>10)
```

of course going crazy we could move this further:

```
for (goo(); a>6 && it>10;) {return}
```

or


```
for (goo(); a>6 && it>10; return)
```

bye Jochen

Re: [PROPOSAL]Support conditional return

[Jochen Theodorou]

On 27.07.20 18:13, MG wrote:
[...]

Continously reassigning to methodChosen  to itself once it has been set
(or in your code: Once it has acquired a value that is Groovy-true)
seems confusing & inelegant to me.


I am actually using this style quite often, because of a lack of good
alternatives. In the groovy code base you will find several places
looking like this:

foo = foo || m1()
foo = foo || m2()
foo = foo || m3()
foo = foo || m4()

or

foo = m1()
if (foo == null) foo = m2()
if (foo == null) foo = m3()
if (foo == null) foo = m4()

depending on if foo is a boolean or not

[...]

or if adjustArguments is an identity operation if the type argument is
null (to me it is more elegant if the doChooseMethod call appears only
once):

def chooseMethod(String methodName,Object[] arguments) {
  def methodChosen = null
  [null, Character.TYPE,Integer.TYPE ].find{ methodChosen = 
doChooseMethod(methodName, adjustArguments(arguments, it))}
  if(methodChosen) {return methodChosen } else {throw new 
GroovyRuntimeException("$methodNamenot found") }
}


well, with the streams API:


return Stream.of(null,Character.TYPE,Integer.TYPE).
  map {doChooseMethod(methodName, adjustArguments(arguments, it)}.
  findFirst {it}.
  orElseThrow {new GroovyRuntimeException("$methodName not found")}


The key here being that map is not executed eager.


(Disclaimer: Dry programmed code again, so can contain stupid mistake(s))


dito

bye Jochen

Re: [PROPOSAL]Support conditional return

[Jochen Theodorou]

On 25.07.20 20:55, Daniel Sun wrote:

Hi all,

  We always have to check the returning value, if it match some condition, 
return it. How about simplifying it? Let's see an example:

```
def m() {
 def r = callSomeMethod()
 if (null != r) return r

 return theDefaultResult
}
```

How about simplifying the above code as follows:
```
def m() {
 return? callSomeMethod()
 return theDefaultResult
}
```


I am partial to this. I can see it's use, but I find the multiple
returns a bit irritating. When I read code, then returns are important
points and I am trained to spot them as especially important and what
structure they are in. Of course I can see that even better here
(kinda), but I am not used to it. On the other hand it is so much alike
to what I am used to... I think I could easily oversee the conditional
sign. It happened to me when reading the examples actually


Futhermore, we could make the conditional return more general:
```
def m() {
 return(r -> r != null) callSomeMethod() // we could do more checking, e.g. r 
> 10
 return theDefaultResult
}
```


Initially I disliked this, but once I am getting more used to I find it
actually quite interesting. It makes the return a special kind of
function. Of course to be complete you would actually have to have

return {r -> r!=null} callSomeMethod()

Though there is a problem if I compare this with what we have.. because
this would mean:

return({r -> r!=null}).callSomeMethod()

command expressions, and that does not work out. Which then again brings
me back to

return(r -> r != null) callSomeMethod()

which should read as

return(r -> r != null).callSomeMethod()

and then it does not work out either. So what first looked like making
the language more using its own constructs is actually something
completely new, a special syntax just for return, that kinda overlaps
with command expressions and only doesn't do that because of the return
keyword... Nope, that part is a -1 to me right now

bye Jochen

Re: [PROPOSAL]Support conditional return

[Jochen Theodorou]

On 27.07.20 12:19, MG wrote:

Hi Jochen,

I assume there is a typo ("?:" -> "?=") in your example, but apart from
that, Groovy-truth prohibits your solution for any method returning a
type which has special Groovy-truth meaning, so what we would need for
general applicability and terseness would be:

def chooseMethod(String methodName, Object[] arguments) {
     def methodChosen = doChooseMethod(methodName, arguments)
     methodChosen ??= doChooseMethod(methodName,
adjustArguments(arguments.clone(), Character.TYPE))
     methodChosen ??= doChooseMethod(methodName,
adjustArguments(arguments.clone(), Integer.TYPE))
     return methodChosen  ??:  throw new
GroovyRuntimeException("$methodName not found")
}


oh dear, looks like it was to early in the morning;

I did mean this:


def chooseMethod(String methodName, Object[] arguments) {
def methodChosen = doChooseMethod(methodName, arguments)
methodChosen = methodChosen ?: doChooseMethod(methodName, 
adjustArguments(arguments.clone(), Character.TYPE))
methodChosen = methodChosen ?: doChooseMethod(methodName, 
adjustArguments(arguments.clone(), Integer.TYPE))
if (null != methodChosen) return methodChosen

throw new GroovyRuntimeException("$methodName not found")
}


bye Jochen

Re: [PROPOSAL]Support conditional return

[Jochen Theodorou]

On 26.07.20 20:23, Daniel Sun wrote:

Hi mg,


maybe you can give some real life code where you encounter this on a regular 
basis ?


Let's think about the case about choosing method by method name and arguments:

```
def chooseMethod(String methodName, Object[] arguments) {
def methodChosen = doChooseMethod(methodName, arguments)
if (null != methodChosen) return methodChosen

methodChosen = doChooseMethod(methodName, 
adjustArguments(arguments.clone(), Character.TYPE))
if (null != methodChosen) return methodChosen

methodChosen = doChooseMethod(methodName, 
adjustArguments(arguments.clone(), Integer.TYPE))
if (null != methodChosen) return methodChosen

throw new GroovyRuntimeException("$methodName not found")
}
```


now that I would now maybe write like this:


def chooseMethod(String methodName, Object[] arguments) {
def methodChosen = doChooseMethod(methodName, arguments)
methodChosen ?: doChooseMethod(methodName, 
adjustArguments(arguments.clone(), Character.TYPE))
methodChosen ?: doChooseMethod(methodName, 
adjustArguments(arguments.clone(), Integer.TYPE))
if (null != methodChosen) return methodChosen

throw new GroovyRuntimeException("$methodName not found")
}



compared to



The above code could be simplified as:
```
def chooseMethod(String methodName, Object[] arguments) {
return? doChooseMethod(methodName, arguments)
return? doChooseMethod(methodName, adjustArguments(arguments.clone(), 
Character.TYPE))
return? doChooseMethod(methodName, adjustArguments(arguments.clone(), 
Integer.TYPE))

throw new GroovyRuntimeException("$methodName not found")
}
```


bye Jochen

Re: "super" object expression for attribute, property, and method call

[Jochen Theodorou]

On 26.06.20 18:43, MG wrote:
[...]> Btw: I am wondering how many people are actually aware that copy
& paste

compatibility of Groovy with regards to Java is one of its feature, and
something that e.g. Kotlin cannot match ?


from my experience quite a lot. That is how many advertise the migration
from Java to Groovy.


How many projects actually use Groovy as a full on replacement for Java?


That is impossible to say I think.


And how many see it still as "just a script language" ?
And how can we promote that more ? G-)


promote it more, that Groovy is a drop-in  replacement?

bye Jochen

Re: "super" object expression for attribute, property, and method call

[Jochen Theodorou]

On 26.06.20 18:02, OCsite wrote:



On 26 Jun 2020, at 17:46, Daniil Ovchinnikov
mailto:daniil.ovchinni...@jetbrains.com>> wrote:

when located within "getX()", "isX()" or "setX()"

I think the meaning of an expression must not depend on the context.


Note currently it does, actually :) Based on context, in today's Groovy,
/this.foo/ might be compiled either as /this.getFoo()/ or as /this.@foo/
— which I argue is wrong and should be cleaned up :) IMO, /this.foo/
should be always compiled as /this.getFoo()/. If someone wants
/this.@foo/, it is really very easy to write the one small '@'. And it
is intention-revealing and makes it the code intuitively understandable,
which are very good traits.


But that is not how property access in general works in Groovy. if you
have foo.bar, then (not considering the specialities of the MOP) this
calls getBar(), but only if getBar() exists. if there is an accessible
(not Java accessible) field bar, then we access the field. If we go
strictly by foo.bar means foo.getBar(), it would mean the call must fail
if there is no getter for bar.

bye Jochen

Re: "super" object expression for attribute, property, and method call

[Jochen Theodorou]

On 26.06.20 17:52, OCsite wrote:

Jochen,


On 26 Jun 2020, at 17:33, Jochen mailto:blackd...@gmx.org>> wrote:

On 26.06.20 17:21, Jochen Theodorou wrote:
[...]

public class X {
  private String foo;
  public String getFoo(){ return this.foo; }
  public void setFoo(String foo){ this.foo = foo; }
}

This works perfectly fine in Java


Correct me please if I am wrong, but the reason it work in the thing is
that in Java /this.foo/ is something completely different than in  Groovy.


the point was about migrating Java code to Groovy though - the reason
why we have many constructs in Groovy we do not really need.

[...]

What if there's a case when someone /would/ want a limited recursion?

def getX() { some_condition?this.x:1 }

That said, an error would be infinitely better than the current behaviour :)


then call a method that does this and do the recursion on that method.
If we call about migrated Java code, where Groovy idioms have been used,
then you will not see "getFoo(){ return this.foo; }" or "private String
foo;", you will see "String foo" and all problems are solved. My concern
is really solely about the migration story, of Java code executed in Groovy.

bye Jochen

Re: "super" object expression for attribute, property, and method call

[Jochen Theodorou]

On 26.06.20 16:34, Milles, Eric (TR Tech, Content & Ops) wrote:

Sorry for replying to my own...

class A {
   def x = 1
   def getX() { 2 }
   def m() { return x }
}

print new A().m() // output 1 or 2?


If we go by the principle of "when in doubt, do it like Java", the
answer is quite clear: 1. Of course nothing is clear ;) You can actually
expand the question to: Is there a difference between "return x" and
"return this.x" in m()?


class B extends A {
   def x = 3
   def getX() { 4 }
   def m2() { return x }
   def m3() { return super.x }
}

print new B().m3() // output 1 or 2?
print new B().m2() // output 3 or 4?
print new B().m() // output 1 or 2 or 3 or 4?


For me the result should be (old):
1
3
1

and with the changes to super (new):
2
3
1

if I understood OC right we would get:
2
4
4



bye Jochen