Re: [EXT] Re: ClassFile API

[Remi Forax]

- Original Message -
> From: "Jochen Theodorou" 
> To: "dev" 
> Sent: Sunday, January 28, 2024 10:38:24 PM
> Subject: Re: [EXT] Re: ClassFile API

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

68 as major version is Java 24, 65525 as minor version means preview.
The current plan is to introduce value classes as a preview feature.

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

yes, no change for invokedynamic from the user POV. In fact, given that 
invokedynamic is only linked at runtime, we know that at call site no boxing 
will occur. But, boxing may occur if the target method has already been loaded 
without the values classes of its descriptor being preloaded at the time the 
target method was created.

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

yes, and no. If the method is too big to be inlined, the value will be boxed. 
If the method is inlined, there will be no boxing.

> 
> bye Jochen

regards,
Rémi

Re: [EXT] Re: ClassFile API

[Remi Forax]

- Original Message -
> From: "Jochen Theodorou" 
> To: "dev" 
> Sent: Sunday, January 28, 2024 1:19:24 PM
> Subject: Re: [EXT] Re: ClassFile API

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

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.

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


If you do not read the attribute corresponding to a sealed type, Groovy will 
not reject a user defined class, defined as a subtype of a selaed type that is 
not in the set of the permitted subtypes so the VM will reject the code at 
runtime with a weird error message.

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

yes, users may want to use new features (by example records) that are gated by 
a specific version of the classfile.

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

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

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

> 
> bye Jochen

regards,
Rémi

Re: [EXT] Re: ClassFile API

[Remi Forax]

- Original Message -
> From: "Jochen Theodorou" 
> To: "dev" 
> Sent: Saturday, January 27, 2024 12:35:40 PM
> Subject: Re: [EXT] Re: ClassFile API

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

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.

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.

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

> 
> bye Jochen

Rémi

Re: Unable to setup workspace

[Remi Forax]

> From: "Manas Marthi" 
> To: "dev" 
> Sent: Sunday, August 27, 2023 8:18:39 PM
> Subject: Re: Unable to setup workspace

> Hi Paul,
> thanks I did not get the response email. I found your response by visiting the
> group link

> I updated master branch and the issue is resolved, and build succeeded

> However, it showed a few errors

> > Task :groovy-binary:asciidoctor
> java.io.IOException: Cannot run program "/opt/local/bin/dot": error=2, No such
> file or directory
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
> at java.base/java.lang.Runtime.exec(Runtime.java:615)
> at
> net.sourceforge.plantuml.dot.ProcessRunner$MainThread.startThreads(ProcessRunner.java:160)
> at
> net.sourceforge.plantuml.dot.ProcessRunner$MainThread.runJob(ProcessRunner.java:120)
> at
> net.sourceforge.plantuml.api.TimeoutExecutor$MyThread.run(TimeoutExecutor.java:76)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
> at java.base/java.lang.ProcessImpl.(ProcessImpl.java:319)
> at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:249)
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
> ... 5 more
> java.io.IOException: Cannot run program "/opt/local/bin/dot": error=2, No such
> file or directory
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
> at java.base/java.lang.Runtime.exec(Runtime.java:615)
> at
> net.sourceforge.plantuml.dot.ProcessRunner$MainThread.startThreads(ProcessRunner.java:160)
> at
> net.sourceforge.plantuml.dot.ProcessRunner$MainThread.runJob(ProcessRunner.java:120)
> at
> net.sourceforge.plantuml.api.TimeoutExecutor$MyThread.run(TimeoutExecutor.java:76)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
> at java.base/java.lang.ProcessImpl.(ProcessImpl.java:319)
> at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:249)
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)

> > Task :groovy-binary:asciidoctorPdf
> Dependency verification has been disabled for configuration
> detachedConfiguration5
> D ependency verification has been disabled for configuration
> detachedConfiguration6
> 2023-08-27T19:07:51.880+01:00 [main] WARN FilenoUtil : Native subprocess 
> control
> requires open access to the JDK IO subsystem
> Pass '--add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens
> java.base/java.io=ALL-UNNAMED' to enable.
> Converting
> /Users/manas/_dev/groovy/subprojects/groovy-binary/src/spec/doc/index.adoc

> The above errors repeated afew number of times though

> Is the installation of "dot" a pre requisite. Any thoughts on how to install 
> it

dot is an executable that is part of graphviz [1] 

> thanks
> Manas

regards, 
Rémi 

[1] https://graphviz.org/download/ 

> From: Manas Marthi 
> Sent: 25 August 2023 23:34
> To: dev@groovy.apache.org 
> Subject: Unable to setup workspace

> hi

> are there any specific steps to setup groovy workspace in intellij? I am 
> getting
> below weird errors. Never faced this issue. Any thoughts?

> I am trying to setup master branch using JDK21 preview build. This is on home
> laptop. So no proxy issues in connecting to maven or any other repo..

> * configuration ':build-logic:compileClasspath' 5 errors

> MODULE ARTIFACT PROBLEM(S)
>   org.jfrog.buildinfo:build-info-api:2.39.8
> build-info-api-2.39.8.jar (.asc)


> Key 2ee4988c55528f25 (not found) couldn't be found in any key server so
> verification couldn't be performed
>   org.jfrog.buildinfo:build-info-client:2.39.8
> build-info-client-2.39.8.jar (.asc)


> Key 2ee4988c55528f25 (not found) couldn't be found in any key server so
> verification couldn't be performed
>   org.jfrog.buildinfo:build-info-extractor:2.39.8
> build-info-extractor-2.39.8.jar (.asc)


> Key 2ee4988c55528f25 (not found) couldn't be found in any key server so
> verification couldn't be performed
>   org.jfrog.buildinfo:build-info-extractor-gradle:5.1.0
> build-info-extractor-gradle-5.1.0.jar (.asc)


> Key 2ee4988c55528f25 (not found) couldn't be found in any key server so
> verification couldn't be performed
>   org.jfrog.filespecs:file-specs-java:1.1.2
> file-specs-java-1.1.2.jar (.asc)


> Key 2ee4988c55528f25 (not found) couldn't be found in any key server so
> verification couldn't be performed

> thanks
> manas

switch in Groovy 5

[Remi Forax]

Hello, 
reading the proposed enhancements for Groovy 5.0 

I've several remarks, 
the proposed destructuring syntax is ambiguous 
switch(point3D) { 
case (a, b, c) -> ... 
} 
It's not clear if a, b and c are existing local variables (declared above) or 
fresh new bindings. 
Choosing fresh new variables instead of existing local variable has been a 
major contention point when the Python syntax was discussed. 
I do not want to influence you one way or another on the syntax to choose, just 
point the ambiguity. 

Otherwise, we are adding '_' as an unamed pattern/variable (as a preview) [1] 
and are using "when" instead of "&&" for the guard [2]. 

regards, 
Rémi 

[1] [ https://openjdk.org/jeps/443 | https://openjdk.org/jeps/443 ] 
[2] [ https://openjdk.org/jeps/441 | https://openjdk.org/jeps/441 ] 

> From: "Paul King" 
> To: "dev" 
> Sent: Saturday, August 19, 2023 4:07:39 PM
> Subject: Re: [VOTE] Release Apache Groovy 5.0.0-alpha-1

> I will be updating the release notes over the next few days (during the voting
> window) and they will be here:
> [ https://groovy-lang.org/releasenotes/groovy-5.0.html |
> https://groovy-lang.org/releasenotes/groovy-5.0.html ]

> It's just a skeleton at the moment but I'll update as I go, but I won't start 
> in
> earnest until tomorrow.

> In the meantime, perhaps looking at the issues labelled 'breaking' is the best
> bet:

> [
> https://issues.apache.org/jira/browse/GROOVY-8?jql=project%20%3D%2012318123%20AND%20fixVersion%20%3D%2012351227%20and%20labels%20%3D%20breaking
> |
> https://issues.apache.org/jira/browse/GROOVY-8?jql=project%20%3D%2012318123%20AND%20fixVersion%20%3D%2012351227%20and%20labels%20%3D%20breaking
> ]

> Cheers, Paul.

> On Sat, Aug 19, 2023 at 10:36 PM Andres Almiray < [ mailto:aalmi...@gmail.com 
> |
> aalmi...@gmail.com ] > wrote:

>> +1 (binding)

>> Is there a list of breaking changes for 5.x?

>> On Sat, Aug 19, 2023 at 4:21 AM Paul King < [ mailto:pa...@asert.com.au |
>> pa...@asert.com.au ] > 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
>>> |
>>> 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
>>> |
>>> 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 |
>>> 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 |
>>> 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 |
>>> 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 |
>>> 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 |
>>> 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: [EXT] Re: [DISCUSS] Groovy 5 planning

[Remi Forax]

- Original Message -
> From: "Milles, Eric (TR Technology)" 
> To: "dev" 
> Sent: Tuesday, July 5, 2022 4:59:52 PM
> Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning

> I was interested in native interface default/private/static methods
> (GROOVY-8299, GROOVY-9801, GROOVY-1) for Groovy 5.  There was discussion 
> on
> what was needed for this at one point.  Does anyone remember if Java 8 was
> holding us back in this area?

It does not, Java the language only adds interface private methods in Java 9 
but the VM already supports them since 8.

As a trivia, the support in the VM was added in 8 to be able to desugar the 
body of a lambda as a private method (static or not) when a lambda is used 
inside a default method.

> 
> https://issues.apache.org/jira/browse/GROOVY-8299
> https://issues.apache.org/jira/browse/GROOVY-9801
> https://issues.apache.org/jira/browse/GROOVY-1

regards,
Rémi

> 
> 
> -Original Message-
> From: Daniel Sun 
> Sent: Sunday, July 3, 2022 1:21 PM
> To: dev@groovy.apache.org
> Subject: [EXT] Re: [DISCUSS] Groovy 5 planning
> 
> External Email: Use caution with links and attachments.
> 
> Hi Jochen,
> 
> I agree with you. The manpower is always a big problem...
> 
> As for the Groovy 5 itself, I wonder what features we should add to the 
> release.
> I think following Java's steps is right, but Groovy should have its own
> evolving plan. Also, I think polishing Groovy 4 is important too, e.g. 
> fixing
> issues and improving performance.
> 
> Cheers,
> Daniel Sun
> On 2022/06/26 21:55:33 Jochen Theodorou wrote:
>> 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: [EXT] Re: [DISCUSS] Groovy 5 planning

[Remi Forax]

> From: "Milles, Eric (TR Technology)" 
> To: "dev" 
> Sent: Wednesday, May 11, 2022 3:29:54 PM
> Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning

> Is there a compelling reason to drop support for Java 8? I don't see it 
> holding
> us back quite like Java 7 support in Groovy 2.5 means no use of lambdas,
> optional, functional interfaces, etc.

from the POV of a parser, 
you have access to methods like Integer.parseInt(CharSequence) which avoid to 
create a String token before transforming it to an int. 

from the POV of a bytecode generator, you have two major features, 
- nestmates which tell the VM that it's fine to access private field/methods 
from other classes given they come from the same script, 
so less need to use reflection at runtime 
- constantdynamic which allow to share constant values in between callsites of 
the same classes. Unlike invokedynamic which requires c2 to kick in to get 
performance, c1 is enough. 
A simple example is def a = 42; here 42 need to be converted to an Object (an 
Integer), it can be done each time or with a constant dynamic, once the first 
time you need it. 

from the POV of the runtime, 
- you are in a post module world and you can ditch the invocation part of the 
reflection API (you still need it for the discovery part) 
- you get access to Lookup.accessClass, findClass and defineClass. The last one 
makes the creation of named class dynamically far easier (it makes the 
GroovyClassLoader far less useful), the other two avoid to have you own checks 
in the runtime duplicating the one of the VM. 
- you can reduce your dependency to sun.misc.Unsafe using VarHandles instead, 
for lock-free algorithms of your runtime. 
- you have ClassLoader.getDefinedPackages() 
- you have the StackWalker API, easier to get the caller method info of things 
like that (you even get the bytecode index of each stack frame) 
- you have more method handles, zero(), tryFinally() and empty() 
- you have access to Runtime.version() so detecting the version of Java becomes 
easy. 

regards, 
Rémi 

> From: Paul King 
> Sent: Wednesday, May 11, 2022 7:58 AM
> To: Groovy_Developers 
> Subject: [EXT] Re: [DISCUSS] Groovy 5 planning



> External Email: Use caution with links and attachments.

> I would certainly hope we had Groovy 6 with JDK17 minimum out before JDK11
> support was phased out. It might be the case then that Groovy 4 and Groovy 6
> are our "sort of LTS" versions at that point.

> On Wed, May 11, 2022 at 2:22 PM J. David Beutel < [ mailto:l...@getsu.com |
> l...@getsu.com ] > wrote:

>> One thing to consider is the EOL schedule, of course. Oracle advertises[1]
>> "extended support" for its Java customers for:


>> JDK version

>> until


>> 8

>> 2030*


>> 11

>> 2026


>> 17

>> 2029

>> * "The Extended Suppo rt uplift fee will be waived for the period March 2022 
>> -
>> December 2030 for Java SE 8. During this period, you will receive Extended
>> Support as described in the Oracle Technical Support Level sections of the
>> Technical Support Policies."

>> On the other hand, Oracle's "premier support" for JDK11 ends in 2023.

>> Likewise, Red Hat advertises[2] OpenJDK support for 8 until 2026, but 11 
>> until
>> 2024.

>> Cheers,
>> 11011011

>> [1] [
>> https://urldefense.com/v3/__https:/www.oracle.com/java/technologies/java-se-support-roadmap.html__;!!GFN0sa3rsbfR8OLyAw!bb6_MeGN-73wJ61WVbbOSp6bvWENnVdRT1txFW18y8GpXo8Mmlb7VBHyHu1-bcyDz4njUuGa9XADfDkDFNyn8g$
>> |
>> https://www.oracle.com/java/technologies/java-se-support-roadmap.html ]
>> [2] [
>> https://urldefense.com/v3/__https:/access.redhat.com/articles/1299013__;!!GFN0sa3rsbfR8OLyAw!bb6_MeGN-73wJ61WVbbOSp6bvWENnVdRT1txFW18y8GpXo8Mmlb7VBHyHu1-bcyDz4njUuGa9XADfDmI5II-Tg$
>> |
>> https://access.redhat.com/articles/1299013 ]

>> On 2022-05-10 15: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.
>>> 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 

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

[Remi Forax]

> De: "Christopher Smith" 
> À: "dev" 
> Envoyé: Jeudi 29 Avril 2021 19:38:27
> Objet: Re: () call-type syntax for functional interfaces?

> Also an object implementing multiple functional interfaces. In dynamic mode, 
> you
> wouldn't know which method to invoke.

if that object is a lambda proxy, i.e. an object created by a Java lambda, the 
only way to implement several functional interfaces is to have default methods, 
those methods are defined in their respective interfaces, not in the lambda 
class. 

You can have several methods in the lamba proxy class either because you have 
method of java.lang.Object (equals/hashCode/toString) or because of the way 
generics are implemented. 
Because of erasure, you can have a bridge method alongside the method that 
calls the lambda body, 
but in that case, selecting the method with the most specific return type and 
the less specific parameter types is enough. 

Rémi 

> On Thu, Apr 29, 2021, 12:34 Jochen Theodorou < [ mailto:blackd...@gmx.org |
> blackd...@gmx.org ] > wrote:

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

[Remi Forax]

- Mail original -
> De: "Christopher Smith" 
> À: "dev" 
> Envoyé: Mercredi 28 Avril 2021 01:37:14
> Objet: GDK retrofit for Java functional interfaces

> Since Paul is now threatening us with a 4.0 beta, I wanted to float an
> idea that I've been thinking over for a bit now that might be best to
> add there (though maybe it would be okay in 3 still, with the Java 8
> baseline).
> 
> A large number of the GDK extension methods (particularly stuff like
> `with`, `collect`, and similar) have signatures that rely explicitly
> on Closure for their strategies. This means that there are
> interoperability problems with libraries that provide strategy
> implementations as functional types; e.g., imagine this trivial
> example:
> 
> ```
> public UnaryOperator multiplier(int multiplicand) {
>  return x -> x * multiplicand;
> }
> ```
> 
> I can't say `[1, 2, 3].collect(multiplier(2))`, because `collect`
> takes only a Closure.
> 
> I would like to (ideally) alter the signatures of the methods in
> DefaultGroovyMethods and similar to replace Closure with the "more
> static" interfaces where possible; most of these cases would end up
> being Function, Consumer, and some of the other usual suspects, with
> some of the extension methods being duplicated to account for the
> cases where the GDK currently does runtime magic like arity detection.
> In the alternative, at least adding overrides for these would support
> language-level interoperability.
> 
> What is the opinion regarding making this change, and what kinds of
> compatibility problems might result from replacing Closure with (e.g.)
> Function rather than adding a new override?

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 :) 

Rémi

Re: Groovy 3.0.8 release

[Remi Forax]

Hi, 
we (the ASM Team) have released, a few weeks ago, a new version of ASM, ASM 
9.1, that support Java 17. 

Given that Java 17 is the next LTS, having the next Groovy releases already 
able to run on Java 17 may be cool thing to add. 

Rémi 

> De: "Milles, Eric (TR Technology)" 
> À: "dev" 
> Envoyé: Mercredi 3 Mars 2021 21:30:09
> Objet: Groovy 3.0.8 release

> Should any of the JIRA issues listed below also be included in Groovy 3.0.8?

> I looked through JIRA for bug fixes in 4.0.0-alpha-2 and the upcoming
> 4.0.0-alpha-3 to see what could be fixed in Groovy 3.0.8 as well. Many fixes
> have been cherry picked already:
> https://github.com/apache/groovy/commits/GROOVY_3_0_X

> I have taken note of issues involving generics or meta class changes, since
> these are historically more likely to cause new compiler or runtime concerns.

> GROOVY-9852+GROOVY-9881 meta class changes

> GROOVY-9956 generics for diamond

> GROOVY-9948 generics for diamond

> GROOVY-9945 generics

> GROOVY-9915 generics

> GROOVY-9914 generics for collectEntriesVariant (merged) -- rollback to exclude
> any changes to generics?

> GROOVY-9902 generics
> This e-mail is for the sole use of the intended recipient and contains
> information that may be privileged and/or confidential. If you are not an
> intended recipient, please notify the sender by return e-mail and delete this
> e-mail and any attachments. Certain required legal entity disclosures can be
> accessed on our website:
> https://www.thomsonreuters.com/en/resources/disclosures.html

Re: Next releases

[Remi Forax]

ASM 9 should have been released this week end but we have an issue with our 
nexus requiring human intervention on the hardware, 
hopefully, this should be fixed soon. 

Rémi 

> De: "paulk" 
> À: "dev" 
> Envoyé: Lundi 21 Septembre 2020 03:47:13
> Objet: Next releases

> Hi everyone,

> I hope to make some more releases before ApacheCon @Home[1] starts in just 
> over
> a week since we have quite a few fixes and improvements ready for release (we
> have over 60 fixes in 3.0.6 for instance). I'd like a Groovy 4.0.0-alpha-1,
> hopefully 3.0.6 and possibly 2.5.14.

> There are a few known regressions which we'd still like to fix so won't be 
> for a
> few days but just giving everyone a heads-up. Please help out if you can on 
> any
> regressions which are important to you, or finish up any improvements you may
> be working on that you'd like to see in the various releases.

> ASM 9 final is also due soon, so we'll hold off 3.0.6 waiting for that if we
> can.

> Cheers, Paul.
> [1] [ https://www.apachecon.com/acna2020/ | 
> https://www.apachecon.com/acna2020/
> ]

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

[Remi Forax]

Native image support neither the reflection nor java.lang.invoke/invokedynamic. 

Are you suggesting to implement a new backend based on an interpreter, while 
it's possible, it's a very big project ? 

Rémi 

> De: "MG" 
> À: "dev" 
> Envoyé: Mercredi 5 Août 2020 17:04:19
> Objet: Groovy as a JVM-less Bash-Script/Perl/Python alternative ?

> In my opinion the reason why Bash-Script/Perl/Python are the predominant Linux
> script languages is, because all or most of them come preinstalled on every
> Linux distribution, and because they run standalone with minimal startup time
> and memory fotprint.
> One of the great things about Grooy is, that it is "one language for
> everything", and as a dynamic language with a concise and C-based (i.e. widely
> used/understood) syntax, good File support, String interpolation and powerful
> closures, it is well suited to be used as a modern Script language.

> However Groovy is dependent on an existing Java installation (of the correct
> version).

> Since JVM based applications are, in my experience, often massively disliked 
> by
> people outside of the JVM community (e.g. sys admins), I have been wondering
> whether Groovy could/should supply a precompiled, memory footprint optimized,
> standalone version that runs without a JVM, so that it could be used for Linux
> (Windows) scripting the same as Bash-Script/Perl/Python are, and if GraalVM
> could be the principal way to do it ( [
> https://www.graalvm.org/docs/reference-manual/native-image/ |
> https://www.graalvm.org/docs/reference-manual/native-image/) ] ?

> Thoughts ?
> mg

Re: About native support for lazy constants

[Remi Forax]

Several things to know:
- you can rewrite all access to a field marked @Lazy to use a constant dynamic,
  that part can already be implemented. If you want to keep the compatibility
  with Java 8, it means that you have to have two translations one for Java 11+
  and one for Java 10-.
- if you want the bytecode getstatic to access the field, here you need the VM
  to be changed, it's in the roadmap for the VM but not yet implemented
- you don't care about getstatic because you can simulate it with an indy*
  (which means that even with @CompileStatic you will use indy)
  in that case you can implement it but it means that all codes that use
  a combination of @Lazy + @CompileStatic has to be recompiled.

Rémi

* there is actually no support of ldc constantdynamic in java.lang.invoke.


- Mail original -
> De: "sunlan" 
> À: "dev" 
> Envoyé: Dimanche 12 Janvier 2020 13:34:22
> Objet: About native support for lazy constants

> Hi all,
> 
>  I read an article[1] about the new features of Java 11 just now, and
> find "JEP 309: Dynamic Class-File Constants"[2] can help us implement lazy
> constants elegantly, e.g. `@Lazy static final Object SOME_LAZY_CONST =
> `. The feature is very useful, so I propose to add *native*
> support for lazy constants in some future version of Groovy.
> 
>  Any thoughts?
> 
> Cheers,
> Daniel.Sun
> [1]
> https://javabeginnerstutorial.com/core-java-tutorial/java-11-new-features/
> [2] https://openjdk.java.net/jeps/309
> 
> 
> 
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
r

Re: Upcoming releases

[Remi Forax]

ASM is backward compatible since ASM 4.

Rémi

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Mardi 12 Novembre 2019 23:15:40
> Objet: Re: Upcoming releases

> On 12.11.19 08:14, Cédric Champeau wrote:
>> Just saying that using external ASM is an option now. Back then we had
>> to repackage because ASM wasn't backwards compatible so triggered all
>> sorts of problems when another library used it with a different version.
>> This is not the case now since you always pass in the ASM version in the
>> constructor now, so ASM knows what visitor to use.
> 
> You remember the ASM version this was? Was it ASM 5?
> 
> bye blackdrag

Re: [VOTE] Support switch expression in the next version

[Remi Forax]

Stephen reharsh what Cay Horstmann said two years ago :(

The main issue is that there is still a lot of switch on string/characters that 
are using fallthrough for a good reason.
You can put your blinkers and pretend that those switches never exist, that 
falltrough is the root of all evil and that nobody will want to refactor them 
to be switch expression, it's not what the EG group has decided.

We, several Google guys in fact, have done some research on the existing 
switches, if i remember correctly the conclusion were:
- there are very few switches per libraries, so the stats are not that useful 
because we expect more usages in the future,
- most of the switches has one of the case that have more than one statement, 
so the syntax has to mix only one line case with multi-lines cases
- there very very few switches with default not at the end
- switch are used a lot for string/characters parsing, think a lexer, and those 
are using fallthrough (the intended use case of the switch in C)

The last point explain why we ends up with a 2x2 matrix.
Obviously, you may argue that the first point make the matrix useless because 
in the future all switches will be only pattern matching switches so in term of 
percents the number of switches used on strings + fallthrough will be 
negligible.
 
Rémi

- Mail original -
> De: "Daniel.Sun" 
> À: "dev" 
> Envoyé: Mardi 5 Novembre 2019 05:21:16
> Objet: Re: [VOTE] Support switch expression in the next version

> It does not matter. Different people have different concerns.
> 
> Maybe we could do better if time allowed:
> https://blog.joda.org/2019/11/java-switch-4-wrongs-dont-make-right.html
> 
>> and Happy Birthday from me, whenever the exact date is G-)
> 
> Thank you, MG :-)
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> 
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [PROPOSAL]Provide an option to generate stubs in in-momery file system for better compiling performance

[Remi Forax]

- Mail original -
> De: "Daniel.Sun" 
> À: "dev" 
> Envoyé: Samedi 19 Janvier 2019 16:44:43
> Objet: Re: [PROPOSAL]Provide an option to generate stubs in in-momery file 
> system for better compiling performance

> Use `ClassLoader.getPlatformClassLoader()` instead to solve the issue.
> 
> GroovyClassLoader dependencyLoader = new GroovyClassLoader(new
> URLClassLoader(urls, (ClassLoader)ClassLoader.getPlatformClassLoader()))
> 
> class loading changed in Java 9+. WTF!

ClassLoading have not changed but classes that were previously loaded by the 
boot loader (the one written in C so reported as null from the Java side) have 
been moved to the platform loader for security reason.
Being loaded by the boot loader make you a privileged class.

https://bugs.openjdk.java.net/browse/JDK-8189116?jql=labels%20%3D%20deprivilege

> 
> 
> Cheers,
> Daniel.Sun

cheers,
Rémi

> 
> 
> 
> 
> -
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Aw: Groovy 2.5.4 generates dead code

[Remi Forax]

The history from the ASM point of view, 
starting with Java 6, the VM starts to use a new bytecode verifier which is 
linear in time and not exponential like the previous one but it requires to 
annotate with a StackMap attribute the bytecode with the state of the local 
types and the stack types more or less at the start of each basic block. 
with Java 7, if you want to generate Java 7 bytecode (to access to 
invokedynamic by example), you have to use the new bytecode verifier, so you 
have no choice but to add those StackMap attributes. 

ASM since Java 6 allows users to ask to generate the StackMap attributes by 
running a point fix algorithm (the exponential one) when you generate the 
bytecode so the VM can verify the bytecode linearly. 
The problem if that in order to compute the StackMap information, we need to 
information that comes from the "parameter" of the basic block, but if the code 
is never called, we do not have this information. 
A previous release of ASM (again a long time ago) was failing in that case, a 
lot of people ask us to find a way to generate something (you can not remove 
it) when there is a dead code given that it will be never called anyway. That's 
why ASM generates the infamous nop ... athrow sequence. 

So you have several ways to fix the issue, 
- ask Evgeny (in CC) that jacoco should recognize the nop ... athrow sequence 
and do not report it. 
- fix the groovy compiler to not generate dead code 

regards, 
Rémi 

> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Mercredi 21 Novembre 2018 15:02:49
> Objet: Aw: Groovy 2.5.4 generates dead code

> Hi Andres,
> there was at some point in the past (I think it was related to Java8) a 
> problem
> with us doing entries into the exception table (I think it was that table).
> There was no fix to this on any simple or middle level. The entry was made 
> like
> that because of how the data is processed in AsmClassGenerator. That is why we
> added an additional instruction at the end, which then gets compiled by asm as
> nop; athrow; even though we do something else here. I vagually remember it had
> to do with us using asm to create a label for marking a range, then not having
> any instructions anymore and then marking the end of the range, followed by no
> further instructions... take it with care, this was 3 or 4 years ago or so -
> and I do not remember any JIRA issue for this right now either, but I think 
> the
> riginal issue mentioned VerificationErrors.
> It is possible that this original issue no longer exists.
> bye Jochen
> Gesendet: Mittwoch, 21. November 2018 um 11:19 Uhr
> Von: "Andres Almiray" 
> An: dev@groovy.apache.org
> Betreff: Groovy 2.5.4 generates dead code
> Hello everyone,
> Evgeny Mandrikov (from JaCoCo) sent me a message regarding dead code produced 
> by
> Groovy 2.5.4 (see [
> https://github.com/jacoco/jacoco/pull/733#issuecomment-440030323 |
> https://github.com/jacoco/jacoco/pull/733#issuecomment-440030323 ] in 
> context).
> Reproducing full message:

> [ https://github.com/aalmiray | @aalmiray ] while playing further with 
> Groovy, I
> noticed that groovyc 2.5.4 generates dead bytecode for the following
> Example.groovy
> Closure closure = { println ( " Hello, " ) println ( " World! " )
> }
> closure()

> here is corresponding part from javap -v -p Example\$_run_closure1 output
> public java.lang.Object doCall(java.lang.Object);
> descriptor: (Ljava/lang/Object;)Ljava/lang/Object;
> flags: ACC_PUBLIC
> Code:
>   stack=3, locals=3, args_size=2
> 0: invokestatic  #22 // Method
>  $getCallSiteArray:()[Lorg/codehaus/groovy/runtime/callsite/CallSite;
>  3: astore_2
>  4: aload_2
>  5: ldc   #32 // int 0
>  7: aaload
>  8: aload_0
>  9: ldc   #34 // String Hello,
>11: invokeinterface #40,  3   // InterfaceMethod
> 
> org/codehaus/groovy/runtime/callsite/CallSite.callCurrent:(Lgroovy/lang/GroovyObject;Ljava/lang/Object;)Ljava/lang/Object;
> 16: pop
> 17: aload_2
> 18: ldc   #41 // int 1
> 20: aaload
> 21: aload_0
> 22: ldc   #43 // String World!
>24: invokeinterface #40,  3   // InterfaceMethod
> 
> org/codehaus/groovy/runtime/callsite/CallSite.callCurrent:(Lgroovy/lang/GroovyObject;Ljava/lang/Object;)Ljava/lang/Object;
> 29: areturn
> 30: nop
> 31: athrow
>   StackMapTable: number_of_entries = 1
> frame_type = 255 /* full_frame */
>   offset_delta = 30
>   locals = []
>   stack = [ class java/lang/Throwable ]
>   LineNumberTable:
> line 2: 4
> line 3: 17
>   LocalVariableTable:
> Start  Length  Slot  Name   Signature
> 0  30 0  this   LExample$_run_closure1;
> 0  30 1it   

Re: About type inference of method return value

[Remi Forax]

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Samedi 8 Septembre 2018 14:22:25
> Objet: Re: About type inference of method return value

[...]
> 
> "var" is a bit a different story. It will lead to surprising types being
> used and partially violates the paradigm that you should not use the
> most special class for your variables if not needed. But even then the
> effect is quite local. If you keep your methods small, as you should
> anyway, then there is not much of a disadvantage here to be seen in my
> opinion. But it already makes the program less readable for another
> user. It is the same in dynamic Groovy with def... Which shows you
> simply have to learn to read the method differently. But the effect is
> very localized.

yes, using an interface instead of a concrete type is only useful if the type 
is visible from the outside, so parameter types/return type of public methods 
or public fields should use interfaces. A local variable (or a private field) 
is never visible from another class so one should use a concrete type here, 
there is not point to ask the VM to de-virtualize when it's not necessary (even 
if de-virtualisation is cheap).   

> 
> Now return type inference is not, as I have shown already. And that,
> plus the lazy developer part, is why I am not friend of this.
> 
> bye Jochen

Rémi

Re: Old bytecode targets

[Remi Forax]

COMPUTE_FRAMES + getCommonSuperClass is one option, calling visitFrame by 
yourself is the other option, for the later usually you have more context to 
find the super type but it means you have to generate the visitFrame at the 
right place.

Rémi

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Mercredi 5 Septembre 2018 12:44:45
> Objet: Re: Old bytecode targets

> Am 05.09.2018 um 12:36 schrieb Remi Forax:
> [...]
>> 
>> it's not free if you ask ASM (COMPUTE_FRAMES) to do the fix point algorithm
>> (which is not linear) and to infer the common supertype, if you generate the
>> StackFrames in the groovy compiler by calling explicitly visitFrame, the
>> runtime cost is not big (but you need to modify your compiler backend which 
>> has
>> development a cost).
> 
> 
> we cannot let asm just do this 100% for us. The classes under
> compilation are possibly not available through classloading, and asm
> might not even use the right classloader if they would. what we do then
> is using COMPUTE_FRAMES, but override
> 
> protected String getCommonSuperClass(String arg1, String arg2)
> 
> which does a not 100% correct calculation of the common super class.
> (not 100% correct means here to claim it is Object in some cases, where
> there would be a better fit)
> 
> bye Jochen

Re: Support of Java 11 using ASM 6.2.1 and ASM 7

[Remi Forax]

Forget to ling to the related bug:
https://issues.apache.org/jira/browse/GROOVY-8727

cheers,
Rémi

- Mail original -
> De: "Remi Forax" 
> À: "dev" 
> Envoyé: Dimanche 2 Septembre 2018 18:04:12
> Objet: Support of Java 11 using ASM 6.2.1 and ASM 7

> Hi all,
> Java 11 introduces several new forward incompatible features* in the class 
> file.
> 
> Currently javac only uses one of them, nestmates [1], which allows to declare
> that several classes are part of the same nest thus allow access to private
> members in between them, obviously changing the semantics of the private 
> access
> for invokevirtual (see [2] if you want more info) if not forward compatible.
> 
> Even if NestMates are declared as class attributes, we have decided in ASM to
> not ignore them if there are present in the bytecode (a class compiled with
> javac 11) because this change for the VM is far from innocuous, if you scrap
> those attributes, you get IllegalAccessError laters, so if you use a
> ClassVisitor configured with the ASM6 API and ASM see a nestmate related
> attributes (NestHost or NestMembers) it will fail with an
> UnsuportedOperationException.
> 
> Moreover, even if the support of Java 11 will came with ASM7, we have decided 
> to
> introduce a new experimental API version (currently ASM7_EXPERIMENTAL) which
> let you parse Java 11 using ASM6 (6.2+), so if you want your favorite language
> to support Java 11, all visitors need to be upgraded to the api version
> ASM7_EXPERIMENTAL.
> You can also decide as before to wait until we release ASM7 (the first week 
> end
> after the release of Java as usual, so at the end of September) to use the 
> ASM7
> api.
> 
> regards,
> Rémi
> 
> * see also Constant Dynamic (http://openjdk.java.net/jeps/309) and Preview
> Feature (http://openjdk.java.net/jeps/12)
> 
> [1] http://openjdk.java.net/jeps/181
> [2] https://youtu.be/-k_IicifbxQ?list=PLX8CzqL3ArzVnxC6PYxMlngEMv3W1pIkn

Re: Cannot build Groovy "out of the box"

[Remi Forax]

yes,
JAXB has to be pulled from Maven Central now.

Rémi

- Mail original -
> De: "Russel Winder" 
> À: "Uwe Schindler" , "dev" 
> Envoyé: Samedi 18 Août 2018 19:33:36
> Objet: Re: Cannot build Groovy "out of the box"

> On Sat, 2018-08-18 at 15:42 +, Uwe Schindler wrote:
>> Hi,
>> 
>> I assume you are building with Java 11! JAXB is unfortunately no
>> longer bundled/enabled in the JDK.
>> 
> 
> True, which shows that Groovy has a problem. Only 38 days till Java 11
> is the current version of Java.
> 
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk

Re: module information creation for Groovy 3

[Remi Forax]

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Vendredi 15 Juin 2018 17:38:29
> Objet: Re: module information creation for Groovy 3

> Am 15.06.2018 um 08:58 schrieb Remi Forax:
>> Hi,
>> moditech provides two different things,
>> - if you are an application, you can add the module-info to your 
>> dependencies,
>> from the POV of the VM, it means all your code will be modular so you can use
>> jlink to create a minimal docker file
>> - you can add module-info to your own jar
>> 
>> The first case is fully valid, i do the same thing but fully automatically
>> (doing a static analysis) with pro [1], it's great but only works if you are
>> the final application, not a library,
>> the second case adds maintenance burden because the module-info doesn't get
>> updated when you change the code source or the pom.xml, so you can have the 
>> pom
>> and the module-info disagreeing on the dependency, a package you have just
>> added being exported by default exported (instead of been non-exported by
>> default), a service being declared in the META-INF but not in the module-info
>> etc.
>> 
>> So it means that you have to test your produced jars twice, with the 
>> classpath
>> and with the module-path to catch the regressions you may have introduced by
>> not updating the moditech plugin configuration to the changes done in the
>> source code. Without modifying the test to run twice, you will get nasty
>> surprises :(
> 
> that might be true, but don't I have to do this anyway? And not only
> that. I have to test as a system module as well.

yes !

> 
> bye Jochen

Rémi

Re: module information creation for Groovy 3

[Remi Forax]

Hi,
moditech provides two different things,
- if you are an application, you can add the module-info to your dependencies, 
from the POV of the VM, it means all your code will be modular so you can use 
jlink to create a minimal docker file
- you can add module-info to your own jar

The first case is fully valid, i do the same thing but fully automatically 
(doing a static analysis) with pro [1], it's great but only works if you are 
the final application, not a library,
the second case adds maintenance burden because the module-info doesn't get 
updated when you change the code source or the pom.xml, so you can have the pom 
and the module-info disagreeing on the dependency, a package you have just 
added being exported by default exported (instead of been non-exported by 
default), a service being declared in the META-INF but not in the module-info 
etc.

So it means that you have to test your produced jars twice, with the classpath 
and with the module-path to catch the regressions you may have introduced by 
not updating the moditech plugin configuration to the changes done in the 
source code. Without modifying the test to run twice, you will get nasty 
surprises :(

Rémi

[1] https://github.com/forax/pro

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Jeudi 14 Juin 2018 23:50:05
> Objet: module information creation for Groovy 3

> Hi all,
> 
> I just found https://github.com/moditect/moditect, there is no gradle
> plugin yet, though it seems there will be soon one. We could use this to
> produce our module information without requiring JDK9 for the build. I
> think we should investigate the usage of this.
> 
> bye Jochen

Re: Building Gant

[Remi Forax]

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" , "Russel Winder" 
> Envoyé: Lundi 16 Avril 2018 21:22:36
> Objet: Re: Building Gant

> On 16.04.2018 19:16, Russel Winder wrote:
>> I know no-one (including me) really gives a  about Gant these days
>> – except perhaps Bob Swift for GINT – but it is useful for testing
>> Gradle and Groovy.
>> 
>> Currently I build against:
>> 
>> 3.0.0 using my build from master/HEAD
>> 2.4.x
>> 2.5.x
>> 2.6.x
>> 
>> where I use the latest version of 2.4, 2.5, and 2.6.
>> 
>> 3.0.0-SNAPSHOT, 2.4.15, and 2.5.0-rc-1 all build and tests execute and
>> fail in not unreasonable ways. 2.6.0-alpha-3 fails due to something the
>> creates the following stack trace. I am running OpenJDK10 obviously.
>> Should I just forget Groovy 2.6.0?
>> 
>> 
>> General error during conversion: java.lang.IllegalArgumentException
>> 
>> java.lang.IllegalArgumentException
>>  at groovyjarjarasm.asm.ClassReader.(ClassReader.java:160)
>>  at groovyjarjarasm.asm.ClassReader.(ClassReader.java:143)
>>  at groovyjarjarasm.asm.ClassReader.(ClassReader.java:418)
> 
> judging by the few examples I found online this mandates ASM 6.1.1
> (https://mvnrepository.com/artifact/org.ow2.asm/asm/6.1.1) 6.1 comes
> with Java10 support. No idea what they added in 10, that is not binary
> compatible. I was not following that so much

the support of version 54.0 and only one sentence in section 4.7.25, see 
https://bugs.openjdk.java.net/browse/JDK-8191867

> 
> bye Jochen

Rémi

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

[Remi Forax]

- Mail original -
> De: "Jochen Theodorou" <blackd...@gmx.org>
> À: "dev" <dev@groovy.apache.org>
> Envoyé: Jeudi 8 Mars 2018 19:51:57
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

> On 08.03.2018 17:34, Remi Forax wrote:
> [...]
>>>> int accumulator = 0
>>>> LOOP: for (T element : someList) {
>>>>accumulator += switch (element.type) {
>>>>  case PLUS_ONE -> +1;
>>>>  case MINUS_ONE -> -1;
>>>>  case ERROR:
>>>>break LOOP;
>>>>  case default -> 0
>>>>}
>>>> }
>>>
>>> with the idea that element.type is an enum... But my problem is with
>>> break LOOP. Is LOOP the label LOOP, or is it a constant/variable?
>> 
>> this will not compile, because you can not use return or break/continue 
>> inside
>> an expression switch.
> 
> you mean I cannot use the normal break/continue inside an expression
> switch, because this example
> 
>> int result = switch (s) {
>> case "Foo" -> 1;
>> case "Bar" -> 2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
> 
> is straight from the JEP 325 page. And that was actually my point, this
> overlap, but redefinition of break. 

yes, you can not use the normal break/containue inside an expression,
so break foo; in an expression switch has only one meaning. 

> break is what makes the switch-case ugly for most people in the first place. 
> Giving that special treatment like this looks off to me.

using break here is ugly, i agree with you but we (the amber EG) are not able 
to find a better solution,
if you know a better way to handle local return of a value in the case of a 
switch, please help us.

> 
>>> If they need the break only to break out of the switch, then why not
>>> capitalize on lambdas ?
>> 
>> it was the first idea :)
>> but lambda can capture effectively final local variable, when a case in an
>> expression switch acts more like a routine so you can access any variables 
>> with
>> no restriction. So re-using the same syntax for two different semantics is 
>> not
>> a good idea.
> 
> A problem you would not have in Groovy, because we don´t do the
> capturing like Java.

It's not like in java but you use a box so the perf model is still not the same 
between a captured variable and a plain old variable in Groovy. 

> 
>> The idea is that the expression switch should be used when it's a simple 
>> switch
>> and the C switch with all it's subtle behaviors if the control flow is more
>> complex,
>> exactly like you use for(:) if it's a simple loop and for(;;) if it's a more
>> complex one.
> 
> maybe, but I still think it does not make so much sense on its own. With
> a step-by-step approach of getting features in I can understand this,
> but then it means to decide to use this here, before deciding the
> details of pattern matching... and that sounds wrong.

no, the Java part of the pattern matching is mostly decided (there is still 
corner cases like how re-starting when a guard fails).
The pattern matching is delayed more because
1/ the VM support is not there, part will be in the jdk 11, but how to specify 
a sealed interface to avoid to have to specify a default when you have cover 
all the cases is still open.
2/ the support of de-constructor (extractor) to keep encapsulation without 
allocation in the middle of the pattern matching requires:
   2a/ value types, good progress have been made on the valhalla side, a 
release of value types without changing generics (which is a major PITA) may be 
a temporary solution.
   2b/ another temporary solution is to make pattern matching only working on 
records (data classes).
   
The only part of the pattern matching which is ugly IMO is how to specify a 
"local return" of a value in a case with several instructions. 

Now, releasing an expression switch first has several advantages:
- allow to align the old switch with the pattern matching switch by modernizing 
the behavior of the old switch with respect to null.
- it fixes several bugs of the current switch implementation:
  - having to recompile the switch when you change the enum
  - the switch on string being slow when the number of cases is small
  - reduce the switch footprint in term of bytecodes
- and obviously allow to use a switch that "returns" an expression. 

> 
> bye Jochen

regards,
Rémi

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

[Remi Forax]

Hi Jochen,

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Vendredi 2 Mars 2018 00:57:16
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

> On 01.03.2018 16:39, Jesper Steen Møller wrote:
> [...]
>> |int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case
>> TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; };|
>> 
>> with
>> 
>> |case LABEL -> expression;|
>> 
>> essentially sugar for
>> 
>> |case LABEL: break expression;|
> 
> to make this straight.
> 
>> int result = switch (s) {
>> case "Foo":
>> break 1;
>> case "Bar":
>> break 2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
> 
> is the long form of
> 
>> int result = switch (s) {
>> case "Foo" ->  1;
>> case "Bar" ->  2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
> 
> The default here has no shorter version, because they are using a
> statement and need to return something in the expression. I understood
> the proposal, that both forms are valid and can be mixed.
> 
> There is a few things I dislike...and most of all it is the break
> command here.
> 
>> int accumulator = 0
>> LOOP: for (T element : someList) {
>>   accumulator += switch (element.type) {
>> case PLUS_ONE -> +1;
>> case MINUS_ONE -> -1;
>> case ERROR:
>>   break LOOP;
>> case default -> 0
>>   }
>> }
> 
> with the idea that element.type is an enum... But my problem is with
> break LOOP. Is LOOP the label LOOP, or is it a constant/variable?

this will not compile, because you can not use return or break/continue inside 
an expression switch.

> 
> If they need the break only to break out of the switch, then why not
> capitalize on lambdas ?

it was the first idea :)
but lambda can capture effectively final local variable, when a case in an 
expression switch acts more like a routine so you can access any variables with 
no restriction. So re-using the same syntax for two different semantics is not 
a good idea.

The idea is that the expression switch should be used when it's a simple switch 
and the C switch with all it's subtle behaviors if the control flow is more 
complex, 
exactly like you use for(:) if it's a simple loop and for(;;) if it's a more 
complex one.  

[...]

> 
> bye Jochen

cheers,
Rémi

Re: About the callable native lambda

[Remi Forax]

- Mail original -
> De: "Daniel Sun" 
> À: "dev" 
> Envoyé: Mardi 30 Janvier 2018 01:14:25
> Objet: About the callable native lambda

> Hi all,
> 

[...]

>   In addition, have you any idea about the issue[1]? If you do not know
> off the top of your head, I'll have to investigate when I have some spare
> time. Any help is appreciated!

you have a call to operandStack.pop() at the end of the method writeLambda, is 
it what you want ?

> 
> Cheers,
> Daniel.Sun
> 

Rémi

> [1]
> https://github.com/apache/groovy/blob/native-lambda/src/main/java/org/codehaus/groovy/classgen/asm/sc/StaticTypesLambdaWriter.java#L136
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About the callable native lambda

[Remi Forax]

You should try to reuse the LambdaMetaFactory instead of generating your own 
proxy,
- generating a proxy means you have a way to define a class in module that do 
not own, so you have to use lookup.defineClass (or worst unsafe.defineClass), 
so you need to generate an invokedynamic
- you can generate the proxy at compile time but in that case, you loose the 
fact that lambdas reduce of disk footprint.
- JDK lambdas use a lightweight classloader so their code is unloaded if the 
lambda is GCed, something which is hard to emulate with your own proxy,
- JDK lambdas consider captured values as really final fields trusted by the 
VM, again something hard to emulate.

so (2) seems to be a better option.

cheers,
Rémi

- Mail original -
> De: "Daniel Sun" 
> À: "dev" 
> Envoyé: Mardi 30 Janvier 2018 01:14:25
> Objet: About the callable native lambda

> Hi all,
> 
>  I'm trying to implement the callable native lambda(e.g.
> `Function f = e -> e + 1; assert 3 == f(2);`), and there
> are 2 ideas come to my mind:
> 
> 1) Generate a proxy implementing the FunctionInterface(e.g. `Function`,
> `Consumer`, etc.) and a `Callable` interface(maybe we should create a new
> one), the proxy will delegate invocations of `call(Object... args)` method
> of `Callable` to the method of the FunctionInterface. As you know, `f(2)` is
> actually `f.call(2)`, so we need the method `call`.
> 2) Transform `f(2)` to `f.apply(2)`, we can get the target method name by
> the type of FunctionInterface. To make it clear, let's have a look at two
> example: `Function`'s method is `apply`, `Consumer`'s method is `accept`.
> 
>   I prefer the first way, but I want to get advice from you :-)
> 
>   In addition, have you any idea about the issue[1]? If you do not know
> off the top of your head, I'll have to investigate when I have some spare
> time. Any help is appreciated!
> 
> Cheers,
> Daniel.Sun
> 
> [1]
> https://github.com/apache/groovy/blob/native-lambda/src/main/java/org/codehaus/groovy/classgen/asm/sc/StaticTypesLambdaWriter.java#L136
> 
> 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Why no asm6 on Groovy2.4.x?

[Remi Forax]

yes, 
when some dependencies are using asm-all and some are not, with the classpath, 
it was working after sacrificing a goat, it does not work with modules so we 
have retired this artifact. 

Happy Christmas, 
Rémi 

> De: "Cédric Champeau" 
> À: "dev" 
> Cc: "dev" 
> Envoyé: Mardi 26 Décembre 2017 08:36:28
> Objet: Re: Why no asm6 on Groovy2.4.x?

> There's no such thing as asm-all. Just like us, they had to get rid of their
> "all" artifact in 6.0. So we have to use the normal version.

> Le 26 déc. 2017 00:54, "Daniel.Sun" < [ mailto:sun...@apache.org |
> sun...@apache.org ] > a écrit :

>> Hi Jochen,

>> It seems that Groovy does not rely on asm-all:
>> [
>> https://github.com/apache/groovy/blob/e9b6bddda05165195db24d42ed3715e4752e0397/build.gradle#L178-L182
>> |
>> https://github.com/apache/groovy/blob/e9b6bddda05165195db24d42ed3715e4752e0397/build.gradle#L178-L182
>> ]

>> In addition, the asm's jar files can be downloaded properly(I could
>> not find "Gradle failure report"):
>> [ https://travis-ci.org/apache/groovy/jobs/321192018#L586-L596 |
>> https://travis-ci.org/apache/groovy/jobs/321192018#L586-L596 ]

>> Could you show me the link to the error messages?

>> Cheers,
>> Daniel.Sun

>> --
>> Sent from: [ http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html |
>> http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html ]

Re: [VOTE] Automatic module names

[Remi Forax]

Cedric,
you can not have a dash in the name if you want the module name be referenced 
in a module-info.java.

so it should be org.apache.groovy.json

cheers,
Rémi 


On December 3, 2017 10:31:27 AM GMT+01:00, "Cédric Champeau" 
 wrote:
>Hi fellow Groovy devs,
>
>We had 2 different conversations in the past weeks regarding automatic
>module names for Groovy. We also starting receiving notifications that
>some
>3rd party projects are blocked by Groovy when upgrading to modules
>(which
>is no surprise). Logback for one.
>
>We need to move forward, and take small steps forward. So, here's the
>plan:
>
>1a. Replace the groovy-all jar with a groovy-all POM with just
>dependencies, so that those depending on groovy-all.jar would now get
>groovy.jar, groovy-json.jar and friends, instead of the all jar.
>1b. Add automatic module names for all jars we have. Since we know
>breaking
>changes are coming, I'd suggest using "org.codehaus.groovy",
>"org.codehaus.groovy-json", ...
>2. Fix split packages
>3. When this is fixed, change module names to "org.apache.groovy",
>"org.apache.groovy-json", ...
>
>I would do 1a and 1b as soon as possible (2.5).
>I would do 2 and 3 for 3.0, since those are binary breaking changes.
>This
>is also why I would leverage that to move to org.apache module names.
>
>I am against providing another -all jar, which would be confusing. Also
>we
>have to get rid, as a larger community (java), of the bad habit of
>using
>fat jars as dependencies. Those should only be used in final
>applications,
>not libraries, so should be transparent to consumers.
>
>Please vote, so that we can move forward.
>
>[ ] +1 The plan sounds good
>[ ] 0 I don't understand enough of the context to have an opinion
>[ ] -1 because...
>
>Thanks a lot,

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Building Groovy

[Remi Forax]

Do you have a problem with those people ? :)

Rémi


On November 22, 2017 10:06:48 AM GMT+01:00, Russel Winder 
 wrote:
>On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote:
>> 
>[…]
>> I don't see the old callsite caching still working properly in a
>> Java9 
>> world, so it is time to cut loose
>> 
>
>And now of course people will be using OpendJDK10 ;-)
>
>-- 
>Russel.
>===
>Dr Russel Winder  t: +44 20 7585 2200
>41 Buckmaster Roadm: +44 7770 465 077
>London SW11 1EN, UK   w: www.russel.org.uk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Removing our use of sun.misc.Unsafe

[Remi Forax]

Hi Paul, 
multi-release jars are not well supported by the ecosystem yet, 
eclipse and idea do not support it well, junit do not support it (all tools 
that does annotations scanning in fact), maven do not support it well, 
proguards do not support it, etc 

Rémi 

> De: "Paul King" 
> À: "dev" 
> Envoyé: Samedi 14 Octobre 2017 02:52:30
> Objet: Re: Removing our use of sun.misc.Unsafe

> We could use a multi-release jar to still provide a faster option for pre jdk9
> users but avoiding that added complexity would also be a good thing.

> On Sat, Oct 14, 2017 at 12:28 AM, John Wagenleitner < [
> mailto:john.wagenleit...@gmail.com | john.wagenleit...@gmail.com ] > wrote:

>> I would be in favor of removing Unsafe from the groovy-json subproject which 
>> I
>> think is the only place where it's used. I had planned to propose this to the
>> dev list but never got around to it. With compat strings in Java 9 I believe 
>> it
>> will no longer be a viable optimization (at least not without quite a bit of
>> effort) and while there may be some performance (or memory) impact for those
>> using Java 7/8 I suspect it wont be that noticeable for most all workloads.
>> I not sure var handles will help much given the work that would be needed to
>> decode the new byte array that String uses in 9. I definitely think offset 
>> can
>> be removed since now we are Java 6 minimum, though I would propose Unsafe be
>> removed altogether from 2.5 onwards.

>> On Thu, Oct 12, 2017 at 8:41 PM, Paul King < [ mailto:pa...@asert.com.au |
>> pa...@asert.com.au ] > wrote:

>>> I was going to try to progress removing Unsafe but I am a little unsure 
>>> where
>>> others might have gotten up to in previous investigations. So, I have a 
>>> bunch
>>> of questions in case others have some answers/ideas.

>>> Does anyone know whether variable handles might work for us? Inside some 
>>> kind of
>>> jdk9 plugin I guess?

>>> Has anyone looked into how we might package up our unsafe usage in such a 
>>> way
>>> that it could be used in pre-jdk9 environments where var handles aren't
>>> available but not result in errors/warnings in jdk9?

>>> What tests were being run to ensure that performance wasn't lost?

>>> Can we remove the OFFSET enum in FastStringUtils described as applicable for
>>> JDK4/5?

>>> Cheers, Paul.

Re: Next steps for Groovy and Java 9?

[Remi Forax]

Cedric,
the illegal access flag will still be present in 18.3. It will be removed 
later, it's not clear when exactly  (it will depend on the adoption).

Rémi




On October 4, 2017 4:25:28 PM GMT+02:00, "Cédric Champeau" 
 wrote:
>I would say a good step forward is to report errors people see with
>running
>Groovy on JDK 9 on JIRA right now. Because Groovy _does run_ on JDK 9.
>Only
>it does with lots of unfriendly warnings (and will stop working with
>JDK
>10/18.3). If there are showstoppers, we're not aware of them.
>
>2017-10-04 16:18 GMT+02:00 Andrew Bayer :
>
>> No worries - I just wanted to get the ball rolling and get myself
>aware of
>> things so that I can calm Jenkins people down that no, we won't be
>stuck on
>> Java 8 forever. =)
>>
>> A.
>>
>> On Wed, Oct 4, 2017 at 4:17 PM, Paul King  wrote:
>>
>>> Hi Andrew,
>>>
>>> We have discussed a few things quite often but don't have a
>definitive
>>> list of remaining tasks. There are a mix of big and small tasks, so
>we
>>> should definitely try to carve off a list of tasks that aren't too
>hard for
>>> others to do. I won't get time to look at this until next week.
>>>
>>> Cheers, Paul.
>>>
>>> On Wed, Oct 4, 2017 at 10:26 PM, Andrew Bayer
>
>>> wrote:
>>>
 Hey all -

 So over in the Jenkins project, we're more than a little bit
>freaked out
 about Groovy + Java 9, since Groovy is absolutely critical to
>Jenkins. I
 think I can carve out time to work on the problems with Groovy +
>Java 9,
 but to a certain extent, I'd be jumping into the jungle without a
>map. =)
 Do we have any kind of roadmap for what needs to be done, or any
>specific
 concrete tasks that need to be tackled?

 A.

>>>
>>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Groovy and code coverage

[Remi Forax]

> De: "Cédric Champeau" <cedric.champ...@gmail.com>
> À: "dev" <dev@groovy.apache.org>
> Envoyé: Vendredi 8 Septembre 2017 15:03:05
> Objet: Re: Groovy and code coverage

> Damn, who thought it was a good idea to put TIMESTAMPS in generated sources?

It's a drop in replacement for javax.annotation.Generated [1] which is in a 
module what will be removed [2] from the modules of Java SE, 
so a long time ago :) 

Rémi 

[1] https://docs.oracle.com/javase/8/docs/api/javax/annotation/Generated.html 
[2] https://bugs.openjdk.java.net/browse/JDK-8152842 

> 2017-09-08 15:00 GMT+02:00 Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@univ-mlv.fr ] > :

>> A standard annotation for generated code was added in Java 9:
>> [
>> http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html
>> |
>> http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html
>> ]

>> Rémi

>>> De: "Andres Almiray" < [ mailto:aalmi...@gmail.com | aalmi...@gmail.com ] >
>>> À: [ mailto:dev@groovy.apache.org | dev@groovy.apache.org ]
>>> Envoyé: Vendredi 8 Septembre 2017 11:41:18
>>> Objet: Groovy and code coverage

>>> Hello everyone,

>>> As you may be aware there are only a few choices in the Java pace that can 
>>> be
>>> used for code coverage, JaCoCo being the one that gives the most accurate
>>> results. While it's easy to setup JaCoco for Groovy sources there are times
>>> where the tool reports no coverage for some lines of code that should not 
>>> have
>>> been counted for coverage in the first case, these are some of the methods
>>> coming from GroovyObject and AST transformations, specifically 
>>> `getProperty`,
>>> `setProperty`, `getMetaClass`, and `invokeMethod`.

>>> I had a chat with Marc Hoffmann yesterday about this situation, which is a 
>>> topic
>>> we've discussed a few times in the past. I've got some good news, Groovy is 
>>> not
>>> alone in this problem, the Lombok project has suffered the same fate which 
>>> has
>>> prompted them to seek a solution. The alternative they came up with is to 
>>> have
>>> Lombok identified generated code that should not be covered with a special
>>> annotation (@lombok.Generated), JaCoCo has a filtering feature (not yet 
>>> public)
>>> that can identify elements annotated with said annotation and skip them from
>>> coverage reports. See

>>> [ https://projectlombok.org/api/index.html?lombok/Generated.html |
>>> https://projectlombok.org/api/index.html?lombok/Generated.html ]
>>> [ https://github.com/jacoco/jacoco/pull/513 |
>>> https://github.com/jacoco/jacoco/pull/513 ]
>>> [
>>> https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/LombokGeneratedFilter.java
>>> |
>>> https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/LombokGeneratedFilter.java
>>> ]

>>> This feature will be available for consumption in the next releases of 
>>> Lombok
>>> (1.16.8+) and JaCoCo (0.7.9+).

>>> Given this, Marc suggested that Groovy could follow the same idea and 
>>> provide an
>>> annotation that JaCoCo can identify, say for example
>>> @groovy.transform.Generated.

>>> If such annotation were to be added to Groovy we would need (at least) the
>>> following steps too:
>>> - update compiler to annotate `getProperty`, `setProperty`, `getMetaClass`, 
>>> and
>>> `invokeMethod` when the class does not explicitly defines any of those 
>>> methods.
>>> - review and update all core AST xforms that generate methods that should be
>>> skipped from coverage.
>>> - document the usage of this annotation and encourage AST xform developers 
>>> to
>>> use it once they upgrade.

>>> Would be great to have this feature in the 2.6.0 release if possible.

>>> Thoughts?

>>> ---
>>> Java Champion; Groovy Enthusiast
>>> [ http://andresalmiray.com/ | http://andresalmiray.com ]
>>> [ http://www.linkedin.com/in/aalmiray | http://www.linkedin.com/in/aalmiray 
>>> ]
>>> --
>>> What goes up, must come down. Ask any system administrator.
>>> There are 10 types of people in the world: Those who understand binary, and
>>> those who don't.
>>> To understand recursion, we must first understand recursion.

Re: Groovy and code coverage

[Remi Forax]

You are generating bytecode ? 

Rémi 

> De: "Andres Almiray" <aalmi...@gmail.com>
> À: "dev" <dev@groovy.apache.org>
> Envoyé: Vendredi 8 Septembre 2017 15:04:57
> Objet: Re: Groovy and code coverage

> Unfortunately that annotation is coming in JDK9. We'll need something that can
> be used with JDK7
> an upwards.

> ---
> Java Champion; Groovy Enthusiast
> [ http://andresalmiray.com/ | http://andresalmiray.com ]
> [ http://www.linkedin.com/in/aalmiray | http://www.linkedin.com/in/aalmiray ]
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.

> On Fri, Sep 8, 2017 at 3:00 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@univ-mlv.fr ] > wrote:

>> A standard annotation for generated code was added in Java 9:
>> [
>> http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html
>> |
>> http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html
>> ]

>> Rémi

>>> De: "Andres Almiray" < [ mailto:aalmi...@gmail.com | aalmi...@gmail.com ] >
>>> À: [ mailto:dev@groovy.apache.org | dev@groovy.apache.org ]
>>> Envoyé: Vendredi 8 Septembre 2017 11:41:18
>>> Objet: Groovy and code coverage

>>> Hello everyone,

>>> As you may be aware there are only a few choices in the Java pace that can 
>>> be
>>> used for code coverage, JaCoCo being the one that gives the most accurate
>>> results. While it's easy to setup JaCoco for Groovy sources there are times
>>> where the tool reports no coverage for some lines of code that should not 
>>> have
>>> been counted for coverage in the first case, these are some of the methods
>>> coming from GroovyObject and AST transformations, specifically 
>>> `getProperty`,
>>> `setProperty`, `getMetaClass`, and `invokeMethod`.

>>> I had a chat with Marc Hoffmann yesterday about this situation, which is a 
>>> topic
>>> we've discussed a few times in the past. I've got some good news, Groovy is 
>>> not
>>> alone in this problem, the Lombok project has suffered the same fate which 
>>> has
>>> prompted them to seek a solution. The alternative they came up with is to 
>>> have
>>> Lombok identified generated code that should not be covered with a special
>>> annotation (@lombok.Generated), JaCoCo has a filtering feature (not yet 
>>> public)
>>> that can identify elements annotated with said annotation and skip them from
>>> coverage reports. See

>>> [ https://projectlombok.org/api/index.html?lombok/Generated.html |
>>> https://projectlombok.org/api/index.html?lombok/Generated.html ]
>>> [ https://github.com/jacoco/jacoco/pull/513 |
>>> https://github.com/jacoco/jacoco/pull/513 ]
>>> [
>>> https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/LombokGeneratedFilter.java
>>> |
>>> https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/LombokGeneratedFilter.java
>>> ]

>>> This feature will be available for consumption in the next releases of 
>>> Lombok
>>> (1.16.8+) and JaCoCo (0.7.9+).

>>> Given this, Marc suggested that Groovy could follow the same idea and 
>>> provide an
>>> annotation that JaCoCo can identify, say for example
>>> @groovy.transform.Generated.

>>> If such annotation were to be added to Groovy we would need (at least) the
>>> following steps too:
>>> - update compiler to annotate `getProperty`, `setProperty`, `getMetaClass`, 
>>> and
>>> `invokeMethod` when the class does not explicitly defines any of those 
>>> methods.
>>> - review and update all core AST xforms that generate methods that should be
>>> skipped from coverage.
>>> - document the usage of this annotation and encourage AST xform developers 
>>> to
>>> use it once they upgrade.

>>> Would be great to have this feature in the 2.6.0 release if possible.

>>> Thoughts?

>>> ---
>>> Java Champion; Groovy Enthusiast
>>> [ http://andresalmiray.com/ | http://andresalmiray.com ]
>>> [ http://www.linkedin.com/in/aalmiray | http://www.linkedin.com/in/aalmiray 
>>> ]
>>> --
>>> What goes up, must come down. Ask any system administrator.
>>> There are 10 types of people in the world: Those who understand binary, and
>>> those who don't.
>>> To understand recursion, we must first understand recursion.

Re: Groovy and code coverage

[Remi Forax]

A standard annotation for generated code was added in Java 9: 
http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html
 

Rémi 

> De: "Andres Almiray" 
> À: dev@groovy.apache.org
> Envoyé: Vendredi 8 Septembre 2017 11:41:18
> Objet: Groovy and code coverage

> Hello everyone,

> As you may be aware there are only a few choices in the Java pace that can be
> used for code coverage, JaCoCo being the one that gives the most accurate
> results. While it's easy to setup JaCoco for Groovy sources there are times
> where the tool reports no coverage for some lines of code that should not have
> been counted for coverage in the first case, these are some of the methods
> coming from GroovyObject and AST transformations, specifically `getProperty`,
> `setProperty`, `getMetaClass`, and `invokeMethod`.

> I had a chat with Marc Hoffmann yesterday about this situation, which is a 
> topic
> we've discussed a few times in the past. I've got some good news, Groovy is 
> not
> alone in this problem, the Lombok project has suffered the same fate which has
> prompted them to seek a solution. The alternative they came up with is to have
> Lombok identified generated code that should not be covered with a special
> annotation (@lombok.Generated), JaCoCo has a filtering feature (not yet 
> public)
> that can identify elements annotated with said annotation and skip them from
> coverage reports. See

> [ https://projectlombok.org/api/index.html?lombok/Generated.html |
> https://projectlombok.org/api/index.html?lombok/Generated.html ]
> [ https://github.com/jacoco/jacoco/pull/513 |
> https://github.com/jacoco/jacoco/pull/513 ]
> [
> https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/LombokGeneratedFilter.java
> |
> https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/LombokGeneratedFilter.java
> ]

> This feature will be available for consumption in the next releases of Lombok
> (1.16.8+) and JaCoCo (0.7.9+).

> Given this, Marc suggested that Groovy could follow the same idea and provide 
> an
> annotation that JaCoCo can identify, say for example
> @groovy.transform.Generated.

> If such annotation were to be added to Groovy we would need (at least) the
> following steps too:
> - update compiler to annotate `getProperty`, `setProperty`, `getMetaClass`, 
> and
> `invokeMethod` when the class does not explicitly defines any of those 
> methods.
> - review and update all core AST xforms that generate methods that should be
> skipped from coverage.
> - document the usage of this annotation and encourage AST xform developers to
> use it once they upgrade.

> Would be great to have this feature in the 2.6.0 release if possible.

> Thoughts?

> ---
> Java Champion; Groovy Enthusiast
> [ http://andresalmiray.com/ | http://andresalmiray.com ]
> [ http://www.linkedin.com/in/aalmiray | http://www.linkedin.com/in/aalmiray ]
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.

Re: trySetAccessible for Java 9

[Remi Forax]

Use reflection, 
have inside groovy a method needSetAccessible coded like this 

private static final Method tryAccessible; 
static { 
Method method; 
try { 
method = AccessibleObject.class.getMethod("tryAccessible", ...); 
} catch(NoMethodFoundException e) { 
method = null; 
} 
tryAccessible = method; 
} 

public static boolena needSetAccessible(...) { 
if (tryAccessible == null) { 
return true; 
} 
return tryAcessible.invoke(...); 
} 

with jdk <= 8 needSetAccessible() always returns true otherwise, it delegates 
to tryAccessible. 
So in the Groovy code, instead of calling setAccessible, one just have to call 
needSetAccessible in a test before calling setAccessible. 

cheers, 
Rémi 

> De: "Cédric Champeau" 
> À: dev@groovy.apache.org
> Envoyé: Mercredi 5 Juillet 2017 18:28:57
> Objet: trySetAccessible for Java 9

> Hi folks,
> We've made some good progress on making Gradle compatible with Java 9 as a
> runtime. However, since the latest release, builds easily get bloated with
> warnings like this:

> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.codehaus.groovy.reflection.CachedClass
> (file:/home/cchampeau/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-all/2.4.11/444a64af79c540aad257e49d95050e7c189f1309/groovy-all-2.4.11.jar)
> to method java.lang.Object.finalize()

> Which is, I think, related to calls to AccessibleObject#setAccessible in
> org.codehaus.groovy.reflection.CachedClass#makeAccessible.

> However, this class precisely _tries_ to set accessible members of a class, 
> but
> doesn't necessarily _have to_. That is, precisely the semantics of the new
> `trySetAccessible` method in AccessibleObject on JDK 9, so I would suggest we
> use it.

> However, as you may understand, things are never so easy: for binary and 
> runtime
> compatibility, we need to be able to use this method only if JDK 9 is
> available, so it either requires using reflection, or method handles if we are
> using Java 8.

> It would be nice to have this in the next 2.x release of Groovy, so that we 
> can
> get rid of those nasty error messages, but then it also means no MethodHandle,
> so no fast call of that `trySetAccessible` method. We cannot use the `Java7` 
> or
> `Java8` approach either, without actually _building_ on JDK 9, which would be 
> a
> problem itself.

> Any suggestion?

Re: groovysh and local variables

[Remi Forax]

Hi Jochen,
jshell, the equivalent of groovysh for java included in 9, does something like 
this,
it stores the content of all variables declaration as fields into a synthetic 
class and all statements as method so statement have access to the content of 
the field.

But because you have bindings in groovy, it may be simpler ? (i do not know if 
bindings are typed ?)

cheers,
Rémi

- Mail original -
> De: "Jochen Theodorou" 
> À: dev@groovy.apache.org
> Envoyé: Mercredi 24 Mai 2017 09:49:32
> Objet: groovysh and local variables

> Hi,
> 
> a User on the user-list mentioned it is currently not possible to define
> a local variable in one evaluation and use it in the next. So for example
> 
> > def x = 10
> 
> > println x
> 
> this fails because the eval for println x has no knowledge about x=10.
> 
> Is this correct, did we have any plans to change this? I mean I know why
> it behaves like that and as a script you would get the same. But in the
> context of groovysh I really wonder if that makes sense. We could
> extract the top level local variables using a transform and make them
> and their values available to the next evaluation
> 
> bye Jochen

Re: build requirements for Groovy and language level in master

[Remi Forax]

On April 8, 2017 7:35:18 PM GMT+02:00, Jochen Theodorou <blackd...@gmx.org> 
wrote:
>On 08.04.2017 16:29, Remi Forax wrote:
>> Jochen,
>> technically, you do not need the jdk 9,
>> you can compile with jdk 8 and have a jar that contains the
>declaration
>> of methods of the jdk 9 you want.
>
>and use -Xbootclasspath/p:path? yes, I guess we can do that.
>JDK-8177827 
>will get in the way, but that is minor. Too bad that is in the future
>no 
>real option anymore because of JDK-8177844. 

you can use --patch-module, 8177844 is about --patch-module having the side 
effect of making the module upgradeable,  i.e. being able to replace the module 
instead of patching it.

> But that will not affect us right now
>
>> JRuby had worked that way when it was jdk 6 compatible but optionally
>> uses the java.lang.invoke API.
>
>yeah, good idea ;)
>
>bye Jochen

Rémi 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: build requirements for Groovy and language level in master

[Remi Forax]

Jochen,
technically, you do not need the jdk 9,
you can compile with jdk 8 and have a jar that contains the declaration of 
methods of the jdk 9 you want.

JRuby had worked that way when it was jdk 6 compatible but optionally uses the 
java.lang.invoke API.

regards,
Rémi

On April 8, 2017 10:11:51 AM GMT+02:00, Jochen Theodorou  
wrote:
>Hi all,
>
>so if we want to be serious about JDK9 support and not life with a 
>thousands of warnings displayed whenever you try to execute a Groovy 
>program or test (44k+ in our build for example)... then we will need 
>JDK9 specific code.
>
>That means we will have to change our build to support optional JDK9 
>code, like we did in the past several times already. That also means a 
>full build will require JDK9 a lower JDK will not make a full build 
>then. And once Cedric fixed JDK9 support in gradle... ahem... poor guy.
>
>Anyway, I would like to hear thoughts about this from the others.
>
>
>And then there is the matter of going to JDK8 master is supposed to be 
>Groovy 3 did we say we want to go to JDK8 here? I think that would be 
>nice... and of course if JDK8 is the minimum could start thinking about
>
>having indy enabled by default. Here too I would to hear what people
>think
>
>bye Jochen

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: About a new annotation Groovydoc

[Remi Forax]

Technically,
Python was not the first language to introduce the idea of using a plain string 
at the start of a function as documentation, all LISPs do that :)

Rémi

- Mail original -
> De: "Daniel Sun" 
> À: d...@groovy.incubator.apache.org
> Envoyé: Vendredi 24 Février 2017 03:46:53
> Objet: About a new annotation Groovydoc

> Hi all,
> 
>  I am going to add a new annotation Groovydoc(Retention: RUNTIME),
> which is configurable(e.g. -Dgroovy.attach.annotation.groovydoc=true) and
> can be attached to target element at compilation time automatically.
> 
>  Groovydoc can be got easily even if Groovy source code is compiled
> into class files, it is a bit like Python's Documentation Strings and will
> be useful for IDE and developers who set a high value on documentations.
> BTW, currently groovydoc is attached as metadata of AST node, which is only
> avaliable at compilation time and is a bit hard to get(we have to use
> CompilationUnit, which is not familiar and friendly to most of Groovy
> developers)
> 
> # demo for Python's Documentation Strings
> def my_function():
>"""Do nothing, but document it.
> No, really, it doesn't do anything.
>"""
>pass
> print(my_function.__doc__)  # print the Documentation Strings of the
> function
> 
> 
>  Any thoughts?
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/About-a-new-annotation-Groovydoc-tp5738721.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: [VOTE]About the implementation of lambda expression

[Remi Forax]

Hi Daniel,

On February 7, 2017 5:20:11 PM GMT+01:00, Daniel Sun  
wrote:
>Hi all,
>
>  Jesper and I discussed the *real* lambda expression(i.e. Java8's
>lambda expression) just now. As Jesper found, Java8's lambda expression
>is
>implemented in Java as an invokedynamic call which makes use of a
>bootstrap
>method calling into a class called the LambdaMetafactory
>(https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html).
>and puts the body of the lambda expression into a hidden method on the
>class. The LambdaMetafactory sets up the magic class which holds any
>escaped
>variables and implements the functional interface. To work, it requires
>EXACT type information,* so it's only possible to do this in static
>compilation*.

It's not fully true.
javac generate a lambda body with the exact type info so the lambda proxy class 
has to be created with the exact info, if the groovy compiler desugar a lambda 
body using Objects, the lambda factory will only need Objects. 
Also, the groovy compiler do not have to call the bootstrap method of the 
lambda meta factory directly so the runtime can also find the target 
dynamically if that info is available and ask the user to insert a cast to the 
interface otherwise.
You can also imagine that the groovy runtime can use the interfaces of 
java.util.function if no interface is provided an do a lambda to lambda 
conversion at runtime if the number of parameters match but not the interface.



>
>  Current lambda expression is based on closure, so it can work well in
>the default mode and static compilation mode. But if we want the *real*
>lambda expression, it will be only available in the static compilation
>mode(as above said). When developers does not enable static
>compilation, we
>provide them lambda expression based on closure or provide no lambda
>expression at all? I prefer the universal version of lambda expression,
>i.e.
>lambda expression based on closure with some warning(such as changing
>the
>delegation strategy of 'this' is forbidden, reference:
>http://groovy-lang.org/closures.html#_delegation_strategy)
>
>- [ ] A, lambda expression based on closure with warning(or error
>prompt)
>- [ ] B, *real* lambda expression is available *in the static
>compilation
>mode* while lambda expression based on closure is available *in the
>default
>mode*
>- [ ] C, *real* lambda expression is only available *in the static
>compilation mode* while *no lambda expression* is available *in the
>default
>mode*
>
>P.S. My vote is A

Java lambdas are identity less so there is more than just how this/super 
behave, as an example, an array of lambdas can be differently than an array of 
reference. 

And also please do not forget that the code of the meta factory can change for 
any updates of the JDK.

>
>Cheers,
>Daniel.Sun

Rémi 

>
>
>
>--
>View this message in context:
>http://groovy.329449.n5.nabble.com/VOTE-About-the-implementation-of-lambda-expression-tp5738486.html
>Sent from the Groovy Dev mailing list archive at Nabble.com.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: About array initializer of Java style for Groovy 3

[Remi Forax]

Also note that in Java 
Integer[] o = { 3 }; and int[] o = { 3 }; 
both work but 
Object o = { 3 }; 
does not compile because the syntax '{' '}' with no explicit array type do 
inference (and here Object is not an array so the inference fails). 

Supporting only explicit array initialization seems to be the right choice ! 

Rémi 

> De: "Daniel Sun" 
> À: d...@groovy.incubator.apache.org
> Envoyé: Mardi 24 Janvier 2017 10:42:03
> Objet: Re: About array initializer of Java style for Groovy 3

> +1

> 在 "Guillaume Laforge [via Groovy]" ，2017年1月24日
> 下午5:19写道：

>> Good point.
>> We should definitely avoid confusion as much as possible, and avoid 
>> introducing
>> ambiguities.

>> On Tue, Jan 24, 2017 at 10:12 AM, Andres Almiray < [hidden email] > wrote:

>>> I think we should support only explicit array initilization with array type,
>>> that is "new int[] { 2 }" for compatibility's sake.

>>> Sent from my iPhone

>>> On 24 Jan 2017, at 09:59, Daniel Sun < [hidden email] > wrote:

 or we just support new int[] {1,2,3} ？

 在 "Guillaume Laforge [via Groovy]" ，2017年1月24日
 16:54写道：

> What happens for def a = { 2 }, is it parsed as a closure or an array
> initializer?

> On Tue, Jan 24, 2017 at 9:52 AM, Daniel Sun < [hidden email] > wrote:

>> Hi Andres,

>> Parrot can parse ` def a = {1, 2, 3}` properly, but it can not parse
>> `{1, 2, 3}`, which is not supported by Java too.

>> This is the initial implementation :)
>> https://github.com/danielsun1106/groovy-parser/commit/96e6c923a4d09d48448f8731a314c918ee6c0e7c

>> Cheers,
>> Daniel.Sun

>> --
>> View this message in context:
>> http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737944.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com .

> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform

> Blog: http://glaforge.appspot.com/
> Social: @glaforge / Google+

> If you reply to this email, your message will be added to the discussion 
> below:
> http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737945.html
> To unsubscribe from About array initializer of Java style for Groovy 3, 
> click
> here .
> NAML

 View this message in context: Re: About array initializer of Java style for
 Groovy 3
 Sent from the Groovy Dev mailing list archive at Nabble.com .

>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform

>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge / Google+

>> If you reply to this email, your message will be added to the discussion 
>> below:
>> http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737949.html
>> To unsubscribe from About array initializer of Java style for Groovy 3, click
>> here .
>> NAML

> View this message in context: Re: About array initializer of Java style for
> Groovy 3
> Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Remi Forax]

There are com.sun classes and com.sun classes :) 

These ones are exported 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.httpserver/share/classes/module-info.java
 
so ok to use. 

Said differently, they are not part of Java but part of the OpenJDK. 

Rémi 

> De: "Cédric Champeau" 
> À: dev@groovy.apache.org
> Cc: d...@groovy.incubator.apache.org
> Envoyé: Dimanche 11 Décembre 2016 17:20:08
> Objet: Re: About SimpleHTTPServer

> Is it just me or Remi is advising to use a com.sun class?

> Le 11 déc. 2016 17:18, "Daniel Sun" < realblue...@hotmail.com > a écrit :

>> Hi Paul,

>> The built-in httpserver of JDK suggested by Remi seems better for us,
>> it is stable and does not require 3rd party library:

>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.httpserver/share/classes/com/sun/net/httpserver/package-info.java

>> As to hooking to the existing socket server, I think it feasible as
>> mrhaki showed the relevant sample code, but we have to maintain it... so I
>> would like to implement SimpleHTTPServer based on the built-in httpserver.

>> Cheers,
>> Daniel.Sun

>> --
>> View this message in context:
>> http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737211.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Remi Forax]

FYIW, there is already an httpserver with the jdk
  
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.httpserver/share/classes/com/sun/net/httpserver/package-info.java

cheers,
Rémi

- Mail original -
> De: "Daniel Sun" 
> À: d...@groovy.incubator.apache.org
> Envoyé: Dimanche 11 Décembre 2016 09:02:23
> Objet: About SimpleHTTPServer

> Hi all,
> 
>  Does Groovy provide any function like Python's SimpleHTTPServer(e.g.
> python -m SimpleHTTPServer 8000)?  If no similar module exits, I'd like to
> implement one via Groovy 3(e.g. groovy -m SimpleHTTPServer 8000).
> 
>  FYI: https://docs.python.org/2/library/simplehttpserver.html
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Default Method for Groovy 3

[Remi Forax]

Hi Daniel,
as you have discovered, there is no flag for specifying a default method in the 
JVM spec, hence no ACC_DEFAULT flag in ASM,
a default method is just a non abstract method in an interface.

Also default and static methods in interface can be either public or private.

cheers,
Rémi

- Mail original -
> De: "Daniel Sun" 
> À: d...@groovy.incubator.apache.org
> Envoyé: Jeudi 8 Décembre 2016 18:40:14
> Objet: Default Method for Groovy 3

> Hi all,
> 
> The new parser(Parrot) supports default method now. You can find
> the new feature at  the enhancedInterface branch of groovy-parser project
>   (
> https://github.com/danielsun1106/groovy-parser/commit/89f45ac86e7945ef81283697b6ed9018e997a045
> ). If no problem with the implementation, I'll merge it into the master
> later.
> 
> *Here is an example:*
> 
> interface Greetable {
>String name();
>default String hello() {
>return 'hello'
>}
> }
> 
> class Person implements Greetable {
>@Override
>public String name() {
>return 'Daniel'
>}
> }
> 
> def p = new Person()
> assert 'hello, Daniel' == "${p.hello()}, ${p.name()}"
> 
>  *Another more complicated example can be found at:*
> https://github.com/danielsun1106/groovy-parser/blob/enhancedInterface/src/test/resources/core/DefaultMethod_02x.groovy
> 
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> 
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Remi Forax]

Perhaps only on method reference,
filter (Objects!::isNull) ?

Remi 

On November 18, 2016 4:10:24 PM GMT+01:00, Paul King  wrote:
>On Sat, Nov 19, 2016 at 12:16 AM, Graeme Rocher
> wrote:
>> In agreement with everyone else here.
>>
>> +1 to !in and !instanceof
>> -1 to everything else
>
>Same for me. I am undecided about sticky or not (allowing a space) but
>easier to be conservative and loosen later.
>I'm -1 for 'as' (no one has proposed it but another of our operators)
>and probably 'is' too. If we do is, I don't see why we wouldn't do it
>for all methods (that return boolean), e.g. assert 'a'.!isUpperCase()
>and I am a little hesitant about such a notation.
>
>Paul.
>
>> On Fri, Nov 18, 2016 at 2:25 PM, Daniel Sun 
>wrote:
>>> OK. I see :)
>>>
>>>
>>>
>>> 在 Cédric Champeau [via Groovy] ，2016年11月18日
>>> 下午9:18写道：
>>>
>>> I agree with Jochen and Guillaume: +1 to !instanceof and !in, but I
>don't
>>> like the other variants.
>>>
>>> 2016-11-18 14:11 GMT+01:00 Daniel Sun <[hidden email]>:

 Hi Jochen,

 >  I think !instanceof and !in are ok. The others... not sure here.
>Right
 >  now a*=b, which means !< is >=. And in this
 >  case I actually prefer >=.

  Sometimes we write code like "!(a > b)", now we can write "a
>!> b"
 instead, which is much close to our mind :)

 Cheers,
 Daniel.Sun





 --
 View this message in context:

>http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736816.html
 Sent from the Groovy Dev mailing list archive at Nabble.com.
>>>
>>>
>>>
>>>
>>> 
>>> If you reply to this email, your message will be added to the
>discussion
>>> below:
>>>
>http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736817.html
>>> To unsubscribe from Negative relational operators for Groovy 3,
>click here.
>>> NAML
>>>
>>>
>>> 
>>> View this message in context: Re: Negative relational operators for
>Groovy 3
>>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Graeme Rocher

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Negative relational operators for Groovy 3

[Remi Forax]

- Mail original -
> De: "Graeme Rocher" 
> À: dev@groovy.apache.org
> Cc: d...@groovy.incubator.apache.org
> Envoyé: Vendredi 18 Novembre 2016 15:16:04
> Objet: Re: Negative relational operators for Groovy 3

> In agreement with everyone else here.
> 
> +1 to !in and !instanceof
> -1 to everything else
> 
> Cheers

even !!

Rémi

> 
> On Fri, Nov 18, 2016 at 2:25 PM, Daniel Sun  wrote:
>> OK. I see :)
>>
>>
>>
>> 在 Cédric Champeau [via Groovy] ，2016年11月18日
>> 下午9:18写道：
>>
>> I agree with Jochen and Guillaume: +1 to !instanceof and !in, but I don't
>> like the other variants.
>>
>> 2016-11-18 14:11 GMT+01:00 Daniel Sun <[hidden email]>:
>>>
>>> Hi Jochen,
>>>
>>> >  I think !instanceof and !in are ok. The others... not sure here. Right
>>> >  now a*=b, which means !< is >=. And in this
>>> >  case I actually prefer >=.
>>>
>>>  Sometimes we write code like "!(a > b)", now we can write "a !> b"
>>> instead, which is much close to our mind :)
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736816.html
>>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>>
>>
>>
>> 
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736817.html
>> To unsubscribe from Negative relational operators for Groovy 3, click here.
>> NAML
>>
>>
>> 
>> View this message in context: Re: Negative relational operators for Groovy 3
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
> 
> 
> 
> --
> Graeme Rocher

Re: replacing jarjar by gradle shadow plugin

[Remi Forax]

Some OS stubbornly refuses to be UTF8 by default :) 

Rémi 

> De: "Cédric Champeau" <cedric.champ...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Vendredi 28 Octobre 2016 09:15:20
> Objet: Re: replacing jarjar by gradle shadow plugin

> Of course everybody should use utf-8 :)

> 2016-10-28 9:14 GMT+02:00 Remi Forax < fo...@univ-mlv.fr > :

>> It doesn't work well on Windows if you do not change the default java 
>> encoding
>> to be UTF8,
>> says the guy that witness a whole team of students to frantically tries
>> everything possible the day before a very important release.

>> Rémi

>>> De: "Cédric Champeau" < cedric.champ...@gmail.com >
>>> À: dev@groovy.apache.org
>>> Envoyé: Vendredi 28 Octobre 2016 09:03:36
>>> Objet: Re: replacing jarjar by gradle shadow plugin

>>> Yes, the shadow plugin is also one of the most used Gradle plugins out 
>>> there.
>>> It's rock solid :)

>>> 2016-10-28 0:12 GMT+02:00 Guillaume Laforge < glafo...@gmail.com > :

>>>> Right, that's what it says on the tin:
>>>> https://github.com/johnrengelman/shadow

>>>> On Fri, Oct 28, 2016 at 12:01 AM, Jochen Theodorou < blackd...@gmx.org > 
>>>> wrote:

>>>>> On 27.10.2016 21:58, Guillaume Laforge wrote:

>>>>>> Does it do package translation too?

>>>>> afaik yes

>>>>> bye Jochen

>>>> --
>>>> Guillaume Laforge
>>>> Apache Groovy committer & PMC Vice-President
>>>> Developer Advocate @ Google Cloud Platform

>>>> Blog: http://glaforge.appspot.com/
>>>> Social: @glaforge / Google+

Re: Lambda expression for Groovy 3

[Remi Forax]

Daniel,
you have also to test that Type::method work not only with static methods but 
also with instance method.

The awful case being when you have a static method that takes an instance in 
parameter that 'overload' an instance method, like Integer.toString() and 
Integer.toString(int).

Rémi

- Mail original -
> De: "daniel_sun" 
> À: d...@groovy.incubator.apache.org
> Envoyé: Mercredi 19 Octobre 2016 12:23:09
> Objet: Re: Lambda expression for Groovy 3

> Hi Jochen,
> 
>  I plan to map Java's *::* to Groovy's *.&*, the following code is ok
> now. What do you think about it?
> 
> [1, 2, 3].stream().forEach(System.out.)  // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.) // class method,  [1, 2,
> 3].stream().forEach(Objects::requireNonNull)
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Lambda expression for Groovy 3

[Remi Forax]

Hi Cedric, 

> De: "Cédric Champeau" 
> À: dev@groovy.apache.org
> Envoyé: Mercredi 19 Octobre 2016 09:09:51
> Objet: Re: Lambda expression for Groovy 3

> First of all, great work, Daniel ! I'm confident that making the "lambdas" be
> "closures" in Groovy is enough. I stated it in the past but I'm going to 
> repeat
> myself here, I don't think having 2 syntax for "closures/lambdas" with 
> slightly
> different semantics would help our users/language. That said, the static
> compiler can do better, doing escape analysis, and using "real" lambdas when
> the target bytecode is 8, as an optimization.

The main issue i see of having one semantics is that the meaning of 'this' in a 
Groovy closure means the closure itself while 'this' in a Java lambda means the 
enclosing object, so { -> this } in Groovy is a substitute to () -> this in 
Java. 
The choice seems to be, the semantics of 'this' in a lambda in Groovy can be 
either the same as Java so you can copy/paste a Java code and it will work as 
is in Groovy or the same semantics as in a Groovy closure so as you said you 
will not have to explain why in Groovy { -> this } and () -> this do not return 
the same value. 

I have no opinion about that, i let you guys decide :) 

That said, the lambda metafactory takes a desugared lambda as argument (a plain 
old static method, apart in corner cases), so choosing the semantics of the 
lambda in Groovy is orthogonal to the choice of using the lambda metafactory or 
not. 

Rémi 

Re: Lambda expression for Groovy 3

[Remi Forax]

I would say Groovy Closure with the Java syntax.

Rémi 

On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge 
 wrote:
>Is it actually Groovy closures? or "real" Java lambdas?
>
>On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou 
>wrote:
>
>>
>> hah, I knew you can do it ;)
>>
>> On 18.10.2016 18:34, daniel_sun wrote:
>>
>>> Jochen, lambda expression is fully supported now :)
>>>
>>> https://github.com/danielsun1106/groovy-parser/commit/c380e4
>>> 230ecef350855b9f56a220411635a7ff87
>>>
>>> https://github.com/danielsun1106/groovy-parser/blob/master/
>>> src/test/resources/core/Lambda_01x.groovy
>>>
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> 在 "Jochen Theodorou [via Groovy]" >> >，2016年10月18日 00:37
>>>
>>> 写道：
>>>
>>>
>>>
>>> On 17.10.2016 17:40, daniel_sun wrote:
>>>  > Hi all,
>>>  >
>>>  >Lambda expression for Groovy has been completed with a
>>> little
>>>  > limitation, which is due to the existing closure whose
>parameter
>>> list can be
>>>  > ambiguous to lambda expression, e.g. {a -> a} which can be
>parsed
>>> as a
>>>  > lambda expression in a block, but we expect it a closure.
>>>
>>> I think that limitation is ok
>>>
>>>  > In order to
>>>  > resolve the ambiguities, the parentheses for parameters is a
>>> must, e.g.
>>>  > *Java8* allows parentheses-less parameter for lambda when the
>>> parameter is
>>>  > single and without type: e -> e, but *Groovy* only allows
>>> parameter with
>>>  > parentheses: (e) -> e.
>>>  >
>>>  >*Here are some examples for lambda expression for
>Groovy:*
>>>  > assert 9 == [1, 2, 3].stream().map((e) -> e + 1).reduce(0,
>(r, e)
>>> -> r + e)
>>>
>>> which means you cannot write
>>>  > assert 9 == [1, 2, 3].stream().map(e -> e + 1).reduce(0, (r,
>e)
>>> -> r + e)
>>>
>>> which I find not so ok. Here again it would be no problem if it
>is
>>> recognized as Closure if that is more easy to accomplish.
>>>
>>> bye Jochen
>>>
>>>
>>> 
>>> 
>>> If you reply to this email, your message will be added to the
>>> discussion below:
>>> http://groovy.329449.n5.nabble.com/Lambda-expression-for-
>>> Groovy-3-tp5736169p5736171.html
>>>
>>> To unsubscribe from Lambda expression for Groovy 3, click here.
>>> NAML
>>> >> jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.
>>>
>naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.
>>> NabbleNamespace-nabble.view.web.template.NodeNamespace&
>>> breadcrumbs=notify_subscribers%21nabble%3Aemail.
>>> naml-instant_emails%21nabble%3Aemail.naml-send_instant_
>>> email%21nabble%3Aemail.naml>
>>>
>>>
>>>
>>>
>
>>> View this message in context: Re: Lambda expression for Groovy 3
>>> >> Groovy-3-tp5736169p5736176.html>
>>> Sent from the Groovy Dev mailing list archive
>>>  at
>>> Nabble.com.
>>>
>>
>>
>
>
>-- 
>Guillaume Laforge
>Apache Groovy committer & PMC Vice-President
>Developer Advocate @ Google Cloud Platform
>
>Blog: http://glaforge.appspot.com/
>Social: @glaforge  / Google+
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: TeamCity back on track

[Remi Forax]

- Mail original -
> De: "Jochen Theodorou" 
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 21:14:51
> Objet: Re: TeamCity back on track

[...]

> 
> so setAccessible is forbidden, but a subclass from a different module
> can access the method... strange new rules. Anyway... was there a thread
> on jigsaw-dev about this? I would like to reread the proposal

http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000390.html

> 
>> For your specific bug, you can use ClassLoader.getDefinedPackages() or
>> classloader.getUnamedModule().getPackages() instead.
> 
> of course with the disadvantage that these are JDK9 only methods.

yes

> 
> bye Jochen

Rémi

Re: TeamCity back on track

[Remi Forax]

It's a feature, 
so you can easily detect sofwares that try to do reflection using 
setAccessible, i.e. violates the VM access rules to, by example, get access to 
a security token, 
what is not known is which part of the JDK should allow this kind of reflection 
(think things like sun.misc.Unsafe.theUnsafe). 

It works like with the exports feature, you can use the command line flag 
--add-exports-private which works like --add-exports 

Rémi 

> De: "Cédric Champeau" <cedric.champ...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 15:13:17
> Objet: Re: TeamCity back on track

> Thanks but I'm afraid it won't allow me to boot Gradle either. Even after 
> trying
> `getDefinedPackages` instead, I only reach another error of this kind:
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> private
> final java.util.Map java.util.Collections$UnmodifiableMap.m accessible: module
> java.base does not "exports private java.util" to unnamed module @6da21078
> at
> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:171)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:165)
> at
> net.rubygrapefruit.platform.internal.WrapperProcess.getEnv(WrapperProcess.java:110)

> Is this "feature/bug" going to be fixed? Is there any way to disable that
> behavior?

> 2016-09-18 15:03 GMT+02:00 Remi Forax < fo...@univ-mlv.fr > :

>>> De: "Cédric Champeau" < cedric.champ...@gmail.com >
>>> À: dev@groovy.apache.org
>>> Envoyé: Dimanche 18 Septembre 2016 14:39:30
>>> Objet: Re: TeamCity back on track

>>> I can confirm this is a new error. Gradle 3.0 works with b119, but not 
>>> b136. And
>>> from what I can see, this is *not* going to be trivial to fix. Best I could 
>>> get
>>> now is:
>>> Caused by: java.lang.IllegalAccessException: class
>>> org.gradle.internal.reflect.JavaMethod cannot access a member of class
>>> java.lang.ClassLoader (in module java.base) with modifiers "protected"
>>> at
>>> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:405)
>>> at
>>> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:396)
>>> at
>>> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:98)
>>> at
>>> java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:359)
>>> at
>>> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:351)
>>> at java.base/java.lang.reflect.Method.invoke(Method.java:529)
>>> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:77)

>>> Which is f* annoying.

>> Sorry,wrong stacktrace.

>> This one is a new bug/feature,
>> it's part of what we have called 'stronger' (not strong) encapsulation i.e. 
>> most
>> of the classes of java.* disallow setAccessible, before that only internal
>> packages were disallowing setAccessible.

>> For your specific bug, you can use ClassLoader.getDefinedPackages() or
>> classloader.getUnamedModule().getPackages() instead.

>> Rémi

>>> 2016-09-18 13:46 GMT+02:00 Cédric Champeau < cedric.champ...@gmail.com > :

>>>> This seems to be a new error, I've never seen it before with Gradle 3.0+. 
>>>> It
>>>> says:
>>>> [Gradle failure report] Caused by:
>>>> java.lang.reflect.InaccessibleObjectException: Unable to make protected
>>>> java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module
>>>> java.base does not "exports private java.lang" to unnamed module @6ca18a14
>>>> [12:00:28][Gradle failure report] at
>>>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
>>>> [12:00:28][Gradle failure report] at
>>>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
>>>> [12:00:28][Gradle failure report] at
>>>> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192)
>>>> [12:00:28][Gradle failure report] at
>>>> java.base/java.lang.reflect.Method.setAccessible(Method.java:186)
>>>> [12:00:28][Gradle failure report] at
>>>> org.gradle.internal.reflect.JavaMethod.(JavaMethod.java:34)
>>>> [1

Re: TeamCity back on track

[Remi Forax]

> De: "Cédric Champeau" <cedric.champ...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 14:39:30
> Objet: Re: TeamCity back on track

> I can confirm this is a new error. Gradle 3.0 works with b119, but not b136. 
> And
> from what I can see, this is *not* going to be trivial to fix. Best I could 
> get
> now is:
> Caused by: java.lang.IllegalAccessException: class
> org.gradle.internal.reflect.JavaMethod cannot access a member of class
> java.lang.ClassLoader (in module java.base) with modifiers "protected"
> at
> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:405)
> at
> java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:396)
> at
> java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:98)
> at
> java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:359)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:351)
> at java.base/java.lang.reflect.Method.invoke(Method.java:529)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:77)

> Which is f* annoying.

Sorry,wrong stacktrace. 

This one is a new bug/feature, 
it's part of what we have called 'stronger' (not strong) encapsulation i.e. 
most of the classes of java.* disallow setAccessible, before that only internal 
packages were disallowing setAccessible. 

For your specific bug, you can use ClassLoader.getDefinedPackages() or 
classloader.getUnamedModule().getPackages() instead. 

Rémi 

> 2016-09-18 13:46 GMT+02:00 Cédric Champeau < cedric.champ...@gmail.com > :

>> This seems to be a new error, I've never seen it before with Gradle 3.0+. It
>> says:
>> [Gradle failure report] Caused by:
>> java.lang.reflect.InaccessibleObjectException: Unable to make protected
>> java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module
>> java.base does not "exports private java.lang" to unnamed module @6ca18a14
>> [12:00:28][Gradle failure report] at
>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
>> [12:00:28][Gradle failure report] at
>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
>> [12:00:28][Gradle failure report] at
>> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192)
>> [12:00:28][Gradle failure report] at
>> java.base/java.lang.reflect.Method.setAccessible(Method.java:186)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.reflect.JavaMethod.(JavaMethod.java:34)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.reflect.JavaMethod.(JavaMethod.java:38)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.reflect.JavaReflectionUtil.method(JavaReflectionUtil.java:224)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.classloader.FilteringClassLoader.(FilteringClassLoader.java:49)

>> Which doesn't seem to be URLClassLoader related.

>> 2016-09-18 13:11 GMT+02:00 Remi Forax < fo...@univ-mlv.fr > :

>>> Gradle thinks it can hack the classpath by seeing the application 
>>> classloader as
>>> an URLClassLoader.
>>> The application classloader is now something that loads modules, so it's 
>>> not a
>>> subclass of URLClassLoader anymore.

>>> Rémi

>>> - Mail original -
>>> > De: "Jochen Theodorou" < blackd...@gmx.org >
>>> > À: dev@groovy.apache.org
>>> > Envoyé: Dimanche 18 Septembre 2016 12:31:56
>>> > Objet: Re: TeamCity back on track

>>> > On 18.09.2016 10:47, Cédric Champeau wrote:
>>> >> I just installed Jigsaw b136. Let me know if it helps.

>>> > looks like gradle has a problem with this one as well

>>> > bye Jochen

Re: TeamCity back on track

[Remi Forax]

Gradle thinks it can hack the classpath by seeing the application classloader 
as an URLClassLoader.
The application classloader is now something that loads modules, so it's not a 
subclass of URLClassLoader anymore.

Rémi

- Mail original -
> De: "Jochen Theodorou" 
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 12:31:56
> Objet: Re: TeamCity back on track

> On 18.09.2016 10:47, Cédric Champeau wrote:
>> I just installed Jigsaw b136. Let me know if it helps.
> 
> looks like gradle has a problem with this one as well
> 
> bye Jochen

Re: JDK 9 Jigsaw builds

[Remi Forax]

- Mail original -
> De: "Jochen Theodorou" 
> À: dev@groovy.apache.org
> Envoyé: Vendredi 8 Juillet 2016 21:51:18
> Objet: Re: JDK 9 Jigsaw builds
> 
> actually, I think I did see somewhere that JDK9 will support only 8 and
> 7 as targets. Maybe someone can confirm that.

not at all !

It's not the JDK, it's just javac.
javac only support 4 releases, it's not something new, i think that policy was 
introduced with javac 7,
to be able to remove old code. So javac 9 support 9, 8, 7, and 6. And for the 
last supported platform, javac emits a warning.

so on my laptop,

$ /usr/jdk/jdk-9/bin/javac -source 1.5 Foo.java 
warning: [options] bootstrap class path not set in conjunction with -source 1.5
error: Source option 1.5 is no longer supported. Use 1.6 or later.

$ /usr/jdk/jdk-9/bin/javac -source 1.6 Foo.java 
warning: [options] bootstrap class path not set in conjunction with -source 1.6
warning: [options] source value 1.6 is obsolete and will be removed in a future 
release
warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
3 warnings

cheers,
Rémi

> 
> On 08.07.2016 17:44, Cédric Champeau wrote:
> > So I have patched the build to add the correct compile options for
> > `javac` in case JDK 9 is detected [1]. As the commit message states,
> > groovy-xml compile gets past compileJava, which is great, but then gets
> > blocked by groovyc, which doesn't see the javax.xml classes. This seems
> > like a pretty serious issue for us, because the compiler doesn't know
> > anything about modules. We thought it would be transparent to us as long
> > as we don't use modules, but since some classes are not visible by
> > default in the JDK now, we have a problem because groovyc itself becomes
> > broken.
> >
> > Another issue I don't understand is that by hiding the `java.xml.bind`
> > module by default, to be able to compile, one has to use `addmods`. But
> > doing so, we're forced to upgrade the target level to 1.9. This is
> > weird, and breaks backwards compatibility (we set source and target
> > level to 1.6, so why would the compiler force us to use 1.9???).
> >
> > In practice, it means we will have to upgrade our builds and CI
> > infrastructure to use a different strategy: run the build with Gradle on
> > whatever JDK we want, but fork a compiler process for compilation that
> > uses older JDKs. Actually I need to check something else. Maybe by using
> > the `-release` option of javac we can avoid `addmods` and the 1.9 target
> > level issue at the same time.
> >
> >
> > [1]
> > https://github.com/apache/groovy/commit/380ae614ae4d979f00e6e362d210e2dd1295bdce
> >
> > 2016-07-08 16:29 GMT+02:00 John Wagenleitner
> > >:
> >
> >
> >
> > On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder  > > wrote:
> >
> > On Fri, 2016-07-08 at 14:34 +0100, Russel Winder wrote:
> > > Turns out it is not a Groovy or Gradle thing, it seems the Java
> > > executable doesn't like the options it advertises it responds to.
> > >
> > > > > (export _JAVA_OPTIONS="-addmods java.xml.bind"
> > > > > &&  /home/users/russel/lib.Linux.x86_64/JDK9/bin/java
> > > > > -version)
> > > Unrecognized option: -addmods
> > > Error: Could not create the Java Virtual Machine.
> > > Error: A fatal exception has occurred. Program will exit.
> >
> >
> > Anyone know the difference between _JAVA_OPTIONS and JAVA_OPTIONS?
> >
> >
> >
> > I believe _JAVA_OPTIONS can be used to pass default options to the
> > JVM and takes precedence over command line arguments you would
> > normally want to pass to java/javac and other jvm tools.  There's
> > also JAVA_TOOL_OPTIONS but it is lowest in priority and
> > _JAVA_OPTIONS and command line parameters are used first in that order.
> >
> > I'm not aware of a JAVA_OPTIONS.  There is a lot of use of JAVA_OPTS
> > but that is not read by any of the JVM tools to my knowledge, unlike
> > the _JAVA_OPTIONS and JAVA_TOOL_OPTIONS which there exists code in
> > hotspot to read those env vars.  JAVA_OPTS seems to be just a
> > conventional name used by many scripts use it when they call the
> > java executible (i.e., java %JAVA_OPTS% ).
> >
> >
> 
> 

Re: JDK version for Groovy

[Remi Forax]

Hi Jochen,
javac doesn't allow you to compile a code with -source 1.7 and -target 1.6
you have to use a tool like ASM for that and i think it was rule out by Cedric 
or Guillaume.

cheers,
Rémi

- Mail original -
> De: "Jochen Theodorou" 
> À: dev@groovy.apache.org
> Envoyé: Vendredi 8 Juillet 2016 09:43:59
> Objet: Re: JDK version for Groovy
> 
> 
> 
> On 08.07.2016 09:10, Jochen Theodorou wrote:
> >
> >
> > On 07.07.2016 17:25, Cédric Champeau wrote:
> >> Gradle 3.0 will require JDK 7. Gradle 2.x can run on JDK 6. I'm not a
> >> big fan of "backporting". To me it's easier to complete 2.5 with JDK 7
> >> now, then switch master to 3.0 and upgrade to JDK 8 there.
> >
> > Gradle 3 is the only reason to even make the switch from JDK6 to JDK8. I
> > imagine if we would not want to use Gradle3 we would still switch to
> > JDK8 or newer in Groovy 3, but stay with JDK6 otherwise.
> 
> actually maybe there has been a misunderstanding.. if we want to use
> JDK7 to build but still target JDK6 as target bytecode level I am for it
> actually.
> 
> The Groovy 3 story would be different though. Here we would produce JDK8
> bytecode and use JDK8 source code features
> 
> bye Jochen
> 

Re: About the syntheticPublic property of member method node in class

[Remi Forax]

- Mail original -
> De: "Jochen Theodorou" 
> À: dev@groovy.apache.org
> Envoyé: Vendredi 1 Avril 2016 18:02:18
> Objet: Re: About the syntheticPublic property of member method node in class
> 
> 
> On 01.04.2016 17:50, daniel_sun wrote:
> > Hi List,
> >
> >The following code is copied from GinA2, which we use to test the
> >new
> > parser for Groovy.
> >
> > class Book {
> >  private String title
> >  Book (String theTitle) {
> >  title = theTitle
> >  }
> >  String getTitle(){
> >  return title
> >  }
> > }
> >
> >I have a question about the syntheticPublic of "getTitle" method
> >node,
> > which has no visibility modifier(e.g. public, protected, private), so I
> > think its "public" should be synthetic and expect syntheticPublic  is true,
> > but the old parser of Groovy set syntheticPublic  as false.  (related issue
> > url: https://github.com/jespersm/groovy/issues/19).
> >
> >   Can you tell me the rationale about syntheticPublic and synthetic of
> > MethodNode?
> 
> If you set those bean property methods to synthetic, IDEs will not offer
> them anymore in auto-completion. I too was of the opinion synthetic
> means "added by the compiler", but I see it now more as a "internal
> method, not for the user".

What about, methods generated by the compiler because they are needed by the 
VM, they cary no metadata for the compiler, that why they are ignored by the 
compiler.

There is no flag for method synthetized by the compiler but visible by the 
compiler (see [1] for more info).

> So all those mop methods we have/had or
> rightfully synthetic, but bean methods like the setTitle one above does
> not fall in this second category. getTitle is a method added by the user
> and user-added methods should never be synthetic. And yes, no visibility
> modifier means public.
> 
> bye Jochen
> 

cheers,
Rémi

[1] http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.8