[jira] [Commented] (GROOVY-11113) Future.get(Duration) (& similar from java.util.concurrent) by default with extension module
[ https://issues.apache.org/jira/browse/GROOVY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738728#comment-17738728 ] Marcin Zajaczkowski commented on GROOVY-3: -- > It is not letting me assign the issue to you at the moment. I'll look into it > but I can shepherd progress in the meantime. Sure, no problem. I just wanted to do not have it unassigned, so contributors know that someone is working on it. > Future.get(Duration) (& similar from java.util.concurrent) by default with > extension module > --- > > Key: GROOVY-3 > URL: https://issues.apache.org/jira/browse/GROOVY-3 > Project: Groovy > Issue Type: Improvement >Reporter: Marcin Zajaczkowski >Assignee: Paul King >Priority: Minor > > In (for example) Spock tests, to check some asynchronous behavior, people use > classes from java.util.concurrent. It includes Future, *Lock and > CountDownLatch. As those classes were introduced in JDK 5, they use the "long > timeout, TimeUnit unit" pair in the methods which should wait with some > timeout. As people already use there Duration with more modern APIs in their > tests, to make them simpler (more consistent), using an extension module, one > can add the equivalent(s) with Duration (introduced in JDK 8), e.g. > Future.get(Duration timeout). The implementation is trivial, but to be reused > in different projects it has to be packaged as a module. > The proposal is to provide some Duration variants with an extension module by > default. > There seem to be ~100 methods with TimeUnit across the java.util.concurrent. > As discussed on Slack, it seems to be more feasible to provide the Duration > variants for "the most popular methods" and wait for the user feedback (to > potentially add some other). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11113) Future.get(Duration) (& similar from java.util.concurrent) by default with extension module
[ https://issues.apache.org/jira/browse/GROOVY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737320#comment-17737320 ] Marcin Zajaczkowski commented on GROOVY-3: -- I plan to make a draft PR with PoC in the following weeks. > Future.get(Duration) (& similar from java.util.concurrent) by default with > extension module > --- > > Key: GROOVY-3 > URL: https://issues.apache.org/jira/browse/GROOVY-3 > Project: Groovy > Issue Type: Improvement >Reporter: Marcin Zajaczkowski >Priority: Minor > > In (for example) Spock tests, to check some asynchronous behavior, people use > classes from java.util.concurrent. It includes Future, *Lock and > CountDownLatch. As those classes were introduced in JDK 5, they use the "long > timeout, TimeUnit unit" pair in the methods which should wait with some > timeout. As people already use there Duration with more modern APIs in their > tests, to make them simpler (more consistent), using an extension module, one > can add the equivalent(s) with Duration (introduced in JDK 8), e.g. > Future.get(Duration timeout). The implementation is trivial, but to be reused > in different projects it has to be packaged as a module. > The proposal is to provide some Duration variants with an extension module by > default. > There seem to be ~100 methods with TimeUnit across the java.util.concurrent. > As discussed on Slack, it seems to be more feasible to provide the Duration > variants for "the most popular methods" and wait for the user feedback (to > potentially add some other). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11113) Future.get(Duration) (& similar from java.util.concurrent) by default with extension module
[ https://issues.apache.org/jira/browse/GROOVY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737320#comment-17737320 ] Marcin Zajaczkowski edited comment on GROOVY-3 at 6/26/23 7:40 PM: --- I plan to make a draft PR with PoC in the following weeks. Please assign me to that issue. was (Author: szpak): I plan to make a draft PR with PoC in the following weeks. > Future.get(Duration) (& similar from java.util.concurrent) by default with > extension module > --- > > Key: GROOVY-3 > URL: https://issues.apache.org/jira/browse/GROOVY-3 > Project: Groovy > Issue Type: Improvement >Reporter: Marcin Zajaczkowski >Priority: Minor > > In (for example) Spock tests, to check some asynchronous behavior, people use > classes from java.util.concurrent. It includes Future, *Lock and > CountDownLatch. As those classes were introduced in JDK 5, they use the "long > timeout, TimeUnit unit" pair in the methods which should wait with some > timeout. As people already use there Duration with more modern APIs in their > tests, to make them simpler (more consistent), using an extension module, one > can add the equivalent(s) with Duration (introduced in JDK 8), e.g. > Future.get(Duration timeout). The implementation is trivial, but to be reused > in different projects it has to be packaged as a module. > The proposal is to provide some Duration variants with an extension module by > default. > There seem to be ~100 methods with TimeUnit across the java.util.concurrent. > As discussed on Slack, it seems to be more feasible to provide the Duration > variants for "the most popular methods" and wait for the user feedback (to > potentially add some other). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11113) Future.get(Duration) (& similar from java.util.concurrent) by default with extension module
Marcin Zajaczkowski created GROOVY-3: Summary: Future.get(Duration) (& similar from java.util.concurrent) by default with extension module Key: GROOVY-3 URL: https://issues.apache.org/jira/browse/GROOVY-3 Project: Groovy Issue Type: Improvement Reporter: Marcin Zajaczkowski In (for example) Spock tests, to check some asynchronous behavior, people use classes from java.util.concurrent. It includes Future, *Lock and CountDownLatch. As those classes were introduced in JDK 5, they use the "long timeout, TimeUnit unit" pair in the methods which should wait with some timeout. As people already use there Duration with more modern APIs in their tests, to make them simpler (more consistent), using an extension module, one can add the equivalent(s) with Duration (introduced in JDK 8), e.g. Future.get(Duration timeout). The implementation is trivial, but to be reused in different projects it has to be packaged as a module. The proposal is to provide some Duration variants with an extension module by default. There seem to be ~100 methods with TimeUnit across the java.util.concurrent. As discussed on Slack, it seems to be more feasible to provide the Duration variants for "the most popular methods" and wait for the user feedback (to potentially add some other). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-10937) record + lombok + groovy == Cannot specify duplicate annotation on the same member : lombok.NonNull
[
https://issues.apache.org/jira/browse/GROOVY-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697139#comment-17697139
]
Marcin Zajaczkowski commented on GROOVY-10937:
--
Thanks [~emilles] . I've just tested it with the original project and it worked!
> record + lombok + groovy == Cannot specify duplicate annotation on the same
> member : lombok.NonNull
> ---
>
> Key: GROOVY-10937
> URL: https://issues.apache.org/jira/browse/GROOVY-10937
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.9
>Reporter: Marcin Zajaczkowski
>Assignee: Eric Milles
>Priority: Minor
> Labels: annotations
> Fix For: 4.0.10
>
>
> I've bumped into a strange looking compilation error in a project using JDK
> 17 record, Lombok's @NotNull and Groovy for tests. It took me a while to find
> a construction which causes that, as:
> # Compilation error occurs in a Groovy class not related to the problematic
> Java record.
> # Groovy class must have (non related) inner interface or class.
> # Record has must have two (or more) fields with @NotNull annotation from
> Lombok.
> # Some (other) Groovy class has to refer to that record.
> For example:
> {code:java}
> // Java
> public record SampleRecordWithNonNullFromLombok(
> @NonNull
> String nonNullField,
> @NonNull//Two or more @NulNull annotated fields are required
> to trigger the problem
> String nonNullField2
> ) {}
> //Groovy
> class ClassWithReferenceToRecord {
> private SampleRecordWithNonNullFromLombok sampleRecord
> }
> class ReproducerClass { //it fails to compile
> interface RequiredToReproduceProblem {
> }
> }{code}
> The error is:
> {code:java}
> [ERROR] Failed to execute goal
> org.codehaus.gmavenplus:gmavenplus-plugin:1.13.1:compileTests (default) on
> project record-lombok-groovy: Error occurred while calling a method on a
> Groovy class from classpath.: InvocationTargetException: startup failed:
> [ERROR] .../ReproducerClass.groovy: -1: Cannot specify duplicate annotation
> on the same member : lombok.NonNull
> [ERROR] @ line -1, column -1.
> [ERROR] 1 error
> {code}
> I created a shrank version of a reproducer:
> [https://github.com/szpak/code-examples-and-poc/tree/master/record-lombok-groovy]
>
> It might be a problem with the way how Lombok generates .class for Java
> record, however, I start here as Groovy compilation is the final reason.
> I have observed that error occasionally with Groovy 3(.0.14), but it occurs
> every time with 4(0.9).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-10937) record + lombok + groovy == Cannot specify duplicate annotation on the same member : lombok.NonNull
Marcin Zajaczkowski created GROOVY-10937:
Summary: record + lombok + groovy == Cannot specify duplicate
annotation on the same member : lombok.NonNull
Key: GROOVY-10937
URL: https://issues.apache.org/jira/browse/GROOVY-10937
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 4.0.9
Reporter: Marcin Zajaczkowski
I've bumped into a strange looking compilation error in a project using JDK 17
record, Lombok's @NotNull and Groovy for tests. It took me a while to find a
construction which causes that, as:
# Compilation error occurs in a Groovy class not related to the problematic
Java record.
# Groovy class must have (non related) inner interface or class.
# Record has must have two (or more) fields with @NotNull annotation from
Lombok.
# Some (other) Groovy class has to refer to that record.
For example:
{code:java}
// Java
public record SampleRecordWithNonNullFromLombok(
@NonNull
String nonNullField,
@NonNull//Two or more @NulNull annotated fields are required to
trigger the problem
String nonNullField2
) {}
//Groovy
class ClassWithReferenceToRecord {
private SampleRecordWithNonNullFromLombok sampleRecord
}
class ReproducerClass { //it fails to compile
interface RequiredToReproduceProblem {
}
}{code}
The error is:
{code:java}
[ERROR] Failed to execute goal
org.codehaus.gmavenplus:gmavenplus-plugin:1.13.1:compileTests (default) on
project record-lombok-groovy: Error occurred while calling a method on a Groovy
class from classpath.: InvocationTargetException: startup failed:
[ERROR] .../ReproducerClass.groovy: -1: Cannot specify duplicate annotation on
the same member : lombok.NonNull
[ERROR] @ line -1, column -1.
[ERROR] 1 error
{code}
I created a shrank version of a reproducer:
[https://github.com/szpak/code-examples-and-poc/tree/master/record-lombok-groovy]
It might be a problem with the way how Lombok generates .class for Java record,
however, I start here as Groovy compilation is the final reason.
I have observed that error occasionally with Groovy 3(.0.14), but it occurs
every time with 4(0.9).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-9360) += and -= no longer rejected in assertion statement in Groovy 3
[
https://issues.apache.org/jira/browse/GROOVY-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580480#comment-17580480
]
Marcin Zajaczkowski commented on GROOVY-9360:
-
[~emilles] Having no comment on closing this issue with "Not A Problem", I
assume the behavior in Groovy 3 is ok and it is an expected to keep it in the
future versions of Groovy, right?
> += and -= no longer rejected in assertion statement in Groovy 3
> ---
>
> Key: GROOVY-9360
> URL: https://issues.apache.org/jira/browse/GROOVY-9360
> Project: Groovy
> Issue Type: Question
> Components: parser-antlr4
>Affects Versions: 3.0.0-rc-2
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> Playing with the failures which Groovy 3 brought to Spock tests itself,
> I noticed that Groovy 3 no longer rejects += and -= if used in an
> assertion statement:
> {code:java}
> //Groovy 3-rc2
> def a = 1
> assert a += 1 //passes
> assert a == 2 //passes
> {code}
> While it behaves consistently, I wonder if that change was introduced
> purposely (it was failing in Groovy 2) and should be documented or the check
> should be enhanced?
> {code:java}
> //Groovy 2.5
> startup failed:
> Script1.groovy: 3: unexpected token: += @ line 1, column 10.
>assert a += 1
> ^1 error
> {code}
> [https://github.com/apache/groovy/commit/a17b9eb85835a5eaa306a893a0a8bcd51a49e299#diff-05fe8708ce3207739a2cb39a97426e8dR345]
> Follow up of the mailing list
> [thread|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c1578490872377-0.p...@n5.nabble.com%3e].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10468) Ability to define system properties for groovyc using CompilerConfiguration
[ https://issues.apache.org/jira/browse/GROOVY-10468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486140#comment-17486140 ] Marcin Zajaczkowski commented on GROOVY-10468: -- Big thanks Paul for your comment. I tried to find a way to set a system property with some API, but I completely forgot it is global and I can set it... I was able to compile Spock test with --configscript from command line, so it addresses the problem. I have some problems with Idea which seems to ignore the file, but it is not related to Groovy itself. To sum it up, maybe it would be worth to convert this ticket into a documentation task? First, I wanted to do it, but then realized I have almost nothing about the things above, so probably someone with more extensive knowledge could do it, once upon a time. > Ability to define system properties for groovyc using CompilerConfiguration > --- > > Key: GROOVY-10468 > URL: https://issues.apache.org/jira/browse/GROOVY-10468 > Project: Groovy > Issue Type: New Feature > Components: Compiler >Affects Versions: 3.0.9, 4.0.0 >Reporter: Marcin Zajaczkowski >Priority: Minor > > In some cases, it would be useful to be able to define system properties for > groovyc using CompilerConfiguration. > The real life example is a limitation of Idea which doesn't allow to provide > system properties for groovyc (just for javac) - > [https://youtrack.jetbrains.com/issue/IDEA-287642] . As a result, Spock > 2.0-groovy-3.0 cannot be easily compiled in Idea if Maven project is imported. > There are probably also some other situations where CompilerConfiguration > might be more handy than playing with Gradle/Maven/Ant/Netbeans > configurations. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GROOVY-10468) Ability to define system properties for groovyc using CompilerConfiguration
Marcin Zajaczkowski created GROOVY-10468: Summary: Ability to define system properties for groovyc using CompilerConfiguration Key: GROOVY-10468 URL: https://issues.apache.org/jira/browse/GROOVY-10468 Project: Groovy Issue Type: New Feature Components: Compiler Affects Versions: 4.0.0, 3.0.9 Reporter: Marcin Zajaczkowski In some cases, it would be useful to be able to define system properties for groovyc using CompilerConfiguration. The real life example is a limitation of Idea which doesn't allow to provide system properties for groovyc (just for javac) - [https://youtrack.jetbrains.com/issue/IDEA-287642] . As a result, Spock 2.0-groovy-3.0 cannot be easily compiled in Idea if Maven project is imported. There are probably also some other situations where CompilerConfiguration might be more handy than playing with Gradle/Maven/Ant/Netbeans configurations. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GROOVY-10312) MissingMethodException in method with default parameter in trait - regression in 3.0.9
[
https://issues.apache.org/jira/browse/GROOVY-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-10312:
-
Description:
After switch from 3.0.8 to 3.0.9 Groovy throws at runtime
MissingMethodException for static method in a trait called from another trait,
but only if a given method has a default parameter.
A stripped down code to reproduce problem:
{code:java}
class StaticStaticInTraitProblem implements TLevel1 {
static void main(String[] args) {
staticMethodWithDefaultParameter()
}
}
trait TLevel1 extends TLevel2 {
static void staticMethodWithDefaultParameter(String params = "") {
//default param is required to make it fail at runtime
static2() //fails with MissingMethodException: No signature of method:
static foobar.TLevel1.static2() is applicable ...
}
}
trait TLevel2 {
static void static2() {}
}{code}
A stacktrace:
{code:java}
Exception in thread "main" groovy.lang.MissingMethodException: No signature of
method: static foobar.TLevel1.static2() is applicable for argument types: ()
values: []
Possible solutions: wait(), wait(long), split(groovy.lang.Closure), wait(long,
int), notify(), stream()
at
groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1584)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1570)
at
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:1003)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:180)
at
foobar.TLevel1$Trait$Helper.$static_methodMissing(StaticStaticInTraitProblem2Spec.groovy)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
at
groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1582)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1570)
at
org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:50)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
at
foobar.TLevel1$Trait$Helper.staticMethodWithDefaultParameter(StaticStaticInTraitProblem2Spec.groovy:11)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
at
org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.invoke(StaticMetaMethodSite.java:44)
at
org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:240)
at
foobar.TLevel1$Trait$Helper.staticMethodWithDefaultParameter(StaticStaticInTraitProblem2Spec.groovy)
at
foobar.TLevel1$Trait$Helper$staticMethodWithDefaultParameter.call(Unknown
Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
at
foobar.StaticStaticInTraitProblem2Spec.staticMethodWithDefaultParameter(StaticStaticInTraitProblem2Spec.groovy)
at
foobar.StaticStaticInTraitProblem2Spec.main(StaticStaticInTraitProblem2Spec.groovy:5)
{code}
Trying to minimize the original case, I reach similar error also with the other
construction:
{code:java}
class StaticInTraitProblem implements StaticTrait {
static void main(String[] args) {
staticMethodWithDefaultParameter()
}
}
trait StaticTrait {
public static final String CONSTANT = ""
static void staticMethodWithDefaultParameter(String params = "") {
//default param is required to make it
[jira] [Created] (GROOVY-10312) MissingMethodException in method with default parameter in trait - regression in 3.0.9
Marcin Zajaczkowski created GROOVY-10312:
Summary: MissingMethodException in method with default parameter
in trait - regression in 3.0.9
Key: GROOVY-10312
URL: https://issues.apache.org/jira/browse/GROOVY-10312
Project: Groovy
Issue Type: Improvement
Affects Versions: 3.0.9
Reporter: Marcin Zajaczkowski
After switch from 3.0.8 to 3.0.9 Groovy throws at runtime
MissingMethodException for static method in a trait called from another trait,
but only if a given method has default parameter.
A stripped down code to reproduce problem:
{code:java}
class StaticStaticInTraitProblem implements TLevel1 {
static void main(String[] args) {
staticMethodWithDefaultParameter()
}
}
trait TLevel1 extends TLevel2 {
static void staticMethodWithDefaultParameter(String params = "") {
//default param is required to make it fail at runtime
static2() //fails with MissingMethodException: No signature of method:
static foobar.TLevel1.static2() is applicable ...
}
}
trait TLevel2 {
static void static2() {}
}{code}
A stacktrace:
{code:java}
Exception in thread "main" groovy.lang.MissingMethodException: No signature of
method: static foobar.TLevel1.static2() is applicable for argument types: ()
values: []
Possible solutions: wait(), wait(long), split(groovy.lang.Closure), wait(long,
int), notify(), stream()
at
groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1584)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1570)
at
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:1003)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:180)
at
foobar.TLevel1$Trait$Helper.$static_methodMissing(StaticStaticInTraitProblem2Spec.groovy)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
at
groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1582)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1570)
at
org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:50)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
at
foobar.TLevel1$Trait$Helper.staticMethodWithDefaultParameter(StaticStaticInTraitProblem2Spec.groovy:11)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
at
org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.invoke(StaticMetaMethodSite.java:44)
at
org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:240)
at
foobar.TLevel1$Trait$Helper.staticMethodWithDefaultParameter(StaticStaticInTraitProblem2Spec.groovy)
at
foobar.TLevel1$Trait$Helper$staticMethodWithDefaultParameter.call(Unknown
Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
at
foobar.StaticStaticInTraitProblem2Spec.staticMethodWithDefaultParameter(StaticStaticInTraitProblem2Spec.groovy)
at
foobar.StaticStaticInTraitProblem2Spec.main(StaticStaticInTraitProblem2Spec.groovy:5)
{code}
Trying to minimize the original case, I reach similar error also with the other
construction:
{code:java}
class StaticInTraitProblem implements StaticTrait {
static void main(String[] args) {
[jira] [Commented] (GROOVY-10196) "Cannot find matching method" with specific class hierarchy and static compilation
[
https://issues.apache.org/jira/browse/GROOVY-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17399859#comment-17399859
]
Marcin Zajaczkowski commented on GROOVY-10196:
--
Btw, maybe it will make it easier to find a culprit. It is a regression in
Groovy 3.0.7. With 3.0.6 (and 3.0.4) it works fine.
> "Cannot find matching method" with specific class hierarchy and static
> compilation
> --
>
> Key: GROOVY-10196
> URL: https://issues.apache.org/jira/browse/GROOVY-10196
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 3.0.8
>Reporter: Marcin Zajaczkowski
>Assignee: Eric Milles
>Priority: Minor
>
> Groovy static compilation reports:
>
> {code:java}
> > Task :compileTestGroovy
> startup failed:
> /home/.../ReproCannotFindMethod.groovy: 11: [Static type checking] - Cannot
> find matching method
> com.example.repro.LinkedMultiValueMap3#add(java.lang.String,
> java.lang.String). Please check if the declared type is correct and if the
> method exists.
> @ line 11, column 9.
> map.add("foo", "bar")
> ^
> 1 error
> {code}
> in some weird, but still valid hierarchy of classes:
>
> {code:java}
> @CompileStatic
> class ReproCannotFindMethod {
> static ups() {
> LinkedMultiValueMap3 map = new LinkedMultiValueMap3<>()
> //fails on add()
> // MultiValueMapAdapter3 map = new
> MultiValueMapAdapter3<>() //works fine with add()
> map.add("foo", "bar")
> }
> }
> interface Map3 {
> }
> interface MultiValueMap3 extends Map3> {
> void add(K key, V value);
> }
> class MultiValueMapAdapter3 implements MultiValueMap3 {
> @Override
> void add(K key, V value) {
> }
> }
> class LinkedMultiValueMap3 extends MultiValueMapAdapter3 {
> }
> {code}
>
> It is definitely a corner case, so it might not be worth to fix it, but I
> report it as I've encountered it in a class hierarchy available related to
> LinkedMultiValueMap in Spring Framework (classes originally in Java).
> Reproduced with Groovy 3.0.8
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10196) "Cannot find matching method" with specific class hierarchy and static compilation
[
https://issues.apache.org/jira/browse/GROOVY-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-10196:
-
Description:
Groovy static compilation reports:
{code:java}
> Task :compileTestGroovy
startup failed:
/home/.../ReproCannotFindMethod.groovy: 11: [Static type checking] - Cannot
find matching method
com.example.repro.LinkedMultiValueMap3#add(java.lang.String, java.lang.String).
Please check if the declared type is correct and if the method exists.
@ line 11, column 9.
map.add("foo", "bar")
^
1 error
{code}
in some weird, but still valid hierarchy of classes:
{code:java}
@CompileStatic
class ReproCannotFindMethod {
static ups() {
LinkedMultiValueMap3 map = new LinkedMultiValueMap3<>()
//fails on add()
// MultiValueMapAdapter3 map = new
MultiValueMapAdapter3<>() //works fine with add()
map.add("foo", "bar")
}
}
interface Map3 {
}
interface MultiValueMap3 extends Map3> {
void add(K key, V value);
}
class MultiValueMapAdapter3 implements MultiValueMap3 {
@Override
void add(K key, V value) {
}
}
class LinkedMultiValueMap3 extends MultiValueMapAdapter3 {
}
{code}
It is definitely a corner case, so it might not be worth to fix it, but I
report it as I've encountered it in a class hierarchy available related to
LinkedMultiValueMap in Spring Framework (classes originally in Java).
Reproduced with Groovy 3.0.8
was:
Groovy static compilation reports:
{code:java}
> Task :compileTestGroovy
startup failed:
/home/.../ReproCannotFindMethod.groovy: 11: [Static type checking] - Cannot
find matching method
com.example.repro.LinkedMultiValueMap3#add(java.lang.String, java.lang.String).
Please check if the declared type is correct and if the method exists.
@ line 11, column 9.
map.add("foo", "bar")
^
1 error
{code}
in some weird, but still valid hierarchy of classes:
{code:java}
@CompileStatic
class ReproCannotFindMethod {
static ups() {
LinkedMultiValueMap3 map = new LinkedMultiValueMap3<>()
//fails on add()
// MultiValueMapAdapter3 map = new
MultiValueMapAdapter3<>() //works fine with add()
map.add("foo", "bar")
}
}
interface Map3 {
}
interface MultiValueMap3 extends Map3> {
void add(K key, V value);
}
class MultiValueMapAdapter3 implements MultiValueMap3 {
@Override
void add(K key, V value) {
}
}
class LinkedMultiValueMap3 extends MultiValueMapAdapter3 {
}
{code}
It is definitely a corner case, so it might not be worth to fix it, bu I report
it as I encountered it in the class hierarchy available related to
LinkedMultiValueMap in Spring Framework (classes originally in Java).
Reproduced with Groovy 3.0.8
> "Cannot find matching method" with specific class hierarchy and static
> compilation
> --
>
> Key: GROOVY-10196
> URL: https://issues.apache.org/jira/browse/GROOVY-10196
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation
>Affects Versions: 3.0.8
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> Groovy static compilation reports:
>
> {code:java}
> > Task :compileTestGroovy
> startup failed:
> /home/.../ReproCannotFindMethod.groovy: 11: [Static type checking] - Cannot
> find matching method
> com.example.repro.LinkedMultiValueMap3#add(java.lang.String,
> java.lang.String). Please check if the declared type is correct and if the
> method exists.
> @ line 11, column 9.
> map.add("foo", "bar")
> ^
> 1 error
> {code}
> in some weird, but still valid hierarchy of classes:
>
> {code:java}
> @CompileStatic
> class ReproCannotFindMethod {
> static ups() {
> LinkedMultiValueMap3 map = new LinkedMultiValueMap3<>()
> //fails on add()
> // MultiValueMapAdapter3 map = new
> MultiValueMapAdapter3<>() //works fine with add()
> map.add("foo", "bar")
> }
> }
> interface Map3 {
> }
> interface MultiValueMap3 extends Map3> {
> void add(K key, V value);
> }
> class MultiValueMapAdapter3 implements MultiValueMap3 {
> @Override
> void add(K key, V value) {
> }
> }
> class LinkedMultiValueMap3 extends MultiValueMapAdapter3 {
> }
> {code}
>
> It is definitely a corner case, so it might not be worth to fix it, but I
> report it as I've encountered it in a class hierarchy available related to
> LinkedMultiValueMap in Spring Framework (classes originally in Java).
> Reproduced with Groovy 3.0.8
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10196) "Cannot find matching method" with specific class hierarchy and static compilation
[
https://issues.apache.org/jira/browse/GROOVY-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-10196:
-
Description:
Groovy static compilation reports:
{code:java}
> Task :compileTestGroovy
startup failed:
/home/.../ReproCannotFindMethod.groovy: 11: [Static type checking] - Cannot
find matching method
com.example.repro.LinkedMultiValueMap3#add(java.lang.String, java.lang.String).
Please check if the declared type is correct and if the method exists.
@ line 11, column 9.
map.add("foo", "bar")
^
1 error
{code}
in some weird, but still valid hierarchy of classes:
{code:java}
@CompileStatic
class ReproCannotFindMethod {
static ups() {
LinkedMultiValueMap3 map = new LinkedMultiValueMap3<>()
//fails on add()
// MultiValueMapAdapter3 map = new
MultiValueMapAdapter3<>() //works fine with add()
map.add("foo", "bar")
}
}
interface Map3 {
}
interface MultiValueMap3 extends Map3> {
void add(K key, V value);
}
class MultiValueMapAdapter3 implements MultiValueMap3 {
@Override
void add(K key, V value) {
}
}
class LinkedMultiValueMap3 extends MultiValueMapAdapter3 {
}
{code}
It is definitely a corner case, so it might not be worth to fix it, bu I report
it as I encountered it in the class hierarchy available related to
LinkedMultiValueMap in Spring Framework (classes originally in Java).
Reproduced with Groovy 3.0.8
was:
Groovy static compilation reports:
{code:java}
> Task :compileTestGroovy
startup failed:
/home/.../ReproCannotFindMethod.groovy: 11: [Static type checking] - Cannot
find matching method
com.example.repro.LinkedMultiValueMap3#add(java.lang.String, java.lang.String).
Please check if the declared type is correct and if the method exists.
@ line 11, column 9.
map.add("foo", "bar")
^
1 error
{code}
in some weird, but still valid hierarchy of classes:
{code:java}
@CompileStatic
class ReproCannotFindMethod {
static ups() {
LinkedMultiValueMap3 map = new LinkedMultiValueMap3<>()
//fails on add()
// MultiValueMapAdapter3 map = new
MultiValueMapAdapter3<>() //works fine with add()
map.add("foo", "bar")
}
}
interface Map3 {
}
interface MultiValueMap3 extends Map3> {
void add(K key, V value);
}
class MultiValueMapAdapter3 implements MultiValueMap3 {
@Override
void add(K key, V value) {
}
}
class LinkedMultiValueMap3 extends MultiValueMapAdapter3 {
}
{code}
It is definitely a corner case, so it might not be worth to fix it, bu I report
it as I encountered it in the class hierarchy available related to
LinkedMultiValueMap in Spring Framework (classes originally in Java).
Reproduced with Groovy 3.0.8
> "Cannot find matching method" with specific class hierarchy and static
> compilation
> --
>
> Key: GROOVY-10196
> URL: https://issues.apache.org/jira/browse/GROOVY-10196
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation
>Affects Versions: 3.0.8
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> Groovy static compilation reports:
>
> {code:java}
> > Task :compileTestGroovy
> startup failed:
> /home/.../ReproCannotFindMethod.groovy: 11: [Static type checking] - Cannot
> find matching method
> com.example.repro.LinkedMultiValueMap3#add(java.lang.String,
> java.lang.String). Please check if the declared type is correct and if the
> method exists.
> @ line 11, column 9.
> map.add("foo", "bar")
> ^
> 1 error
> {code}
> in some weird, but still valid hierarchy of classes:
>
> {code:java}
> @CompileStatic
> class ReproCannotFindMethod {
> static ups() {
> LinkedMultiValueMap3 map = new LinkedMultiValueMap3<>()
> //fails on add()
> // MultiValueMapAdapter3 map = new
> MultiValueMapAdapter3<>() //works fine with add()
> map.add("foo", "bar")
> }
> }
> interface Map3 {
> }
> interface MultiValueMap3 extends Map3> {
> void add(K key, V value);
> }
> class MultiValueMapAdapter3 implements MultiValueMap3 {
> @Override
> void add(K key, V value) {
> }
> }
> class LinkedMultiValueMap3 extends MultiValueMapAdapter3 {
> }
> {code}
>
> It is definitely a corner case, so it might not be worth to fix it, bu I
> report it as I encountered it in the class hierarchy available related to
> LinkedMultiValueMap in Spring Framework (classes originally in Java).
> Reproduced with Groovy 3.0.8
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-10196) "Cannot find matching method" with specific class hierarchy and static compilation
Marcin Zajaczkowski created GROOVY-10196:
Summary: "Cannot find matching method" with specific class
hierarchy and static compilation
Key: GROOVY-10196
URL: https://issues.apache.org/jira/browse/GROOVY-10196
Project: Groovy
Issue Type: Improvement
Components: Static compilation
Affects Versions: 3.0.8
Reporter: Marcin Zajaczkowski
Groovy static compilation reports:
{code:java}
> Task :compileTestGroovy
startup failed:
/home/.../ReproCannotFindMethod.groovy: 11: [Static type checking] - Cannot
find matching method
com.example.repro.LinkedMultiValueMap3#add(java.lang.String, java.lang.String).
Please check if the declared type is correct and if the method exists.
@ line 11, column 9.
map.add("foo", "bar")
^
1 error
{code}
in some weird, but still valid hierarchy of classes:
{code:java}
@CompileStatic
class ReproCannotFindMethod {
static ups() {
LinkedMultiValueMap3 map = new LinkedMultiValueMap3<>()
//fails on add()
// MultiValueMapAdapter3 map = new
MultiValueMapAdapter3<>() //works fine with add()
map.add("foo", "bar")
}
}
interface Map3 {
}
interface MultiValueMap3 extends Map3> {
void add(K key, V value);
}
class MultiValueMapAdapter3 implements MultiValueMap3 {
@Override
void add(K key, V value) {
}
}
class LinkedMultiValueMap3 extends MultiValueMapAdapter3 {
}
{code}
It is definitely a corner case, so it might not be worth to fix it, bu I report
it as I encountered it in the class hierarchy available related to
LinkedMultiValueMap in Spring Framework (classes originally in Java).
Reproduced with Groovy 3.0.8
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10192) Smarter Closure delegation detection in annotation parameters
[
https://issues.apache.org/jira/browse/GROOVY-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394884#comment-17394884
]
Marcin Zajaczkowski commented on GROOVY-10192:
--
And [another
question|https://mail-archives.apache.org/mod_mbox/groovy-dev/202108.mbox/%3cb18e777a-cb55-a761-5b66-04dc3184d...@bruenings-it.net%3e]
about that by Leonard Brünings (August 2021):
It is possible to define Closures for annotations, e.g., Spock's
`@Requires(\{ os.windows })`.
However, it is currently impossible to tell the IDE what this annotation
will delegate to, as @DelegatesTo is only applicable for parameters.
Could we either allow @DelegatesTo for TYPE_USE or mabe add a new
dedicated annotation for that.
public @interface Requires {
Class value();
}
Alternatively, we could add METHOD as target, to the annotation.
public @interface Requires {
DelegatesTo(PreconditionContext.class)
Class value();
}
> Smarter Closure delegation detection in annotation parameters
> -
>
> Key: GROOVY-10192
> URL: https://issues.apache.org/jira/browse/GROOVY-10192
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 3.0.8, 4.0.0-alpha-3
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> TL;TR. I would like to have a way to inform IDE that a passed in an
> annotation Closure's execution is in fact delegated to a specific object
> (type). E.g. "@Requires(\{ jvm.java11 })" should allow to write "jv" and see
> jvm in IDE (once a delegate has that field/getter).
> More detailed version (based on my question on the mailing list in [January
> 2020|https://mail-archives.apache.org/mod_mbox/groovy-users/202001.mbox/%3cb62eefce-5d71-f394-8024-f2dd93c12...@wp.pl%3e]).
> One of the nice features of Spock is an ability to define conditions in
> Closure when test(s) should (not) be executes with @Required/@IgnoreIf.
>
> {code:java}
> @Requires({ isSpecialConditionFulfilled() })
> def "some test"() {}
> {code}
> The annotation itself is defined as:
>
> {code:java}
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD})
> @ExtensionAnnotation(RequiresExtension.class)
> public @interface Requires {
> Class value();
> }
> {code}
> Down the line the execution is delegated to PreconditionContext which
> provides convenient methods/objects such as os.linux, jvm.java11, env, etc.
> {code:java}
> @Requires({ jvm.java11 && os.linux }) {code}
> Unfortunately, there is no code completion as IDE doesn't know about
> that delegation (and jvm, os fields/methods). Groovy 2 introduced
> @DelegatesTo, however it cannot be used with other annotations or methods.
> It can be tricked by creating a static final instance of PreconditionContext
> (it's stateless) somewhere (e.g. in the Specification super class), but
> people has to know to refer it, e.g:
> {code:java}
> @Requires({ CTX.jvm.java11 }){code}
> Alternatively, I was thinking about a method in the base Spock class:
> {code:java}
> protected static def ctx(@DelegatesTo(PreconditionContext) Closure closure) {
> closure()
> }{code}
> which could be referenced as:
> {code:java}
> @Requires({ ctx { jvm.java10Compatible } }){code}
> It works, but again "ctx" has to be referenced on demand.
> The best long-term solution would be to allow to use @DelegatesTo at the
> method level:
> {code:java}
> public @interface MyRequires {
> @DelegatesTo(PreconditionContext.class) Class value();
> } {code}
> It would provide code completion out of the box (once IDEs have support for
> that ). The second main drawback I see is being not very intuitive
> declaration and limited usage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10192) Smarter Closure delegation detection in annotation parameters
[
https://issues.apache.org/jira/browse/GROOVY-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-10192:
-
Description:
TL;TR. I would like to have a way to inform IDE that a passed in an annotation
Closure's execution is in fact delegated to a specific object (type). E.g.
"@Requires(\{ jvm.java11 })" should allow to write "jv" and see jvm in IDE
(once a delegate has that field/getter).
More detailed version (based on my question on the mailing list in [January
2020|https://mail-archives.apache.org/mod_mbox/groovy-users/202001.mbox/%3cb62eefce-5d71-f394-8024-f2dd93c12...@wp.pl%3e]).
One of the nice features of Spock is an ability to define conditions in Closure
when test(s) should (not) be executes with @Required/@IgnoreIf.
{code:java}
@Requires({ isSpecialConditionFulfilled() })
def "some test"() {}
{code}
The annotation itself is defined as:
{code:java}
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@ExtensionAnnotation(RequiresExtension.class)
public @interface Requires {
Class value();
}
{code}
Down the line the execution is delegated to PreconditionContext which
provides convenient methods/objects such as os.linux, jvm.java11, env, etc.
{code:java}
@Requires({ jvm.java11 && os.linux }) {code}
Unfortunately, there is no code completion as IDE doesn't know about
that delegation (and jvm, os fields/methods). Groovy 2 introduced
@DelegatesTo, however it cannot be used with other annotations or methods.
It can be tricked by creating a static final instance of PreconditionContext
(it's stateless) somewhere (e.g. in the Specification super class), but people
has to know to refer it, e.g:
{code:java}
@Requires({ CTX.jvm.java11 }){code}
Alternatively, I was thinking about a method in the base Spock class:
{code:java}
protected static def ctx(@DelegatesTo(PreconditionContext) Closure closure) {
closure()
}{code}
which could be referenced as:
{code:java}
@Requires({ ctx { jvm.java10Compatible } }){code}
It works, but again "ctx" has to be referenced on demand.
The best long-term solution would be to allow to use @DelegatesTo at the method
level:
{code:java}
public @interface MyRequires {
@DelegatesTo(PreconditionContext.class) Class value();
} {code}
It would provide code completion out of the box (once IDEs have support for
that ). The second main drawback I see is being not very intuitive declaration
and limited usage.
was:
TL;TR. I would like to have a way to inform IDE that a passed in an annotation
Closure's execution is in fact delegated to a specific object (type). E.g.
"@Requires(\{ jvm.java11 })" should allow to write "jv" and see jvm in IDE
(once a delegate has that field/getter).
More detailed version (based on my question on the mailing list in [January
2020|https://mail-archives.apache.org/mod_mbox/groovy-users/202001.mbox/%3cb62eefce-5d71-f394-8024-f2dd93c12...@wp.pl%3e]).
One of the nice features of Spock is an ability to define conditions in Closure
when test(s) should (not) be executes with @Required/@IgnoreIf.
@Requires(\{ isSpecialConditionFulfilled() })
def "some test"() {}
The annotation itself is defined as:
@Retention(RetentionPolicy.RUNTIME)
@Target(\{ElementType.TYPE, ElementType.METHOD})
@ExtensionAnnotation(RequiresExtension.class)
public @interface Requires \{
Class value();
}
Down the line the execution is delegated to PreconditionContext which
provides convenient methods/objects such as os.linux, jvm.java11, env, etc.
{code:java}
@Requires({ jvm.java11 && os.linux }){code}
Unfortunately, there is no code completion as IDE doesn't know about
that delegation (and jvm, os fields/methods). Groovy 2 introduced
@DelegatesTo, however it cannot be used with other annotations or methods.
It can be tricked by creating a static final instance of PreconditionContext
(it's stateless) somewhere (e.g. in the Specification super class), but people
has to know to refer it, e.g:
@Requires(\{ CTX.jvm.java11 })
Alternatively, I was thinking about a method in the base Spock class:
{code:java}
protected static def ctx(@DelegatesTo(PreconditionContext) Closure closure) {
closure()
}{code}
which could be referenced as:
{code:java}
@Requires({ ctx { jvm.java10Compatible } }){code}
It works, but again "ctx" has to be referenced on demand.
The best long-term solution would be to allow to use @DelegatesTo at the method
level:
{code:java}
public @interface MyRequires {
@DelegatesTo(PreconditionContext.class) Class value();
} {code}
It would provide code completion out of the box (once IDEs have support for
that ). The second main drawback I see is being not very intuitive declaration
and limited usage.
> Smarter Closure delegation detection in annotation parameters
> -
>
> Key:
[jira] [Created] (GROOVY-10192) Smarter Closure delegation detection in annotation parameters
Marcin Zajaczkowski created GROOVY-10192:
Summary: Smarter Closure delegation detection in annotation
parameters
Key: GROOVY-10192
URL: https://issues.apache.org/jira/browse/GROOVY-10192
Project: Groovy
Issue Type: Improvement
Components: Compiler
Affects Versions: 4.0.0-alpha-3, 3.0.8
Reporter: Marcin Zajaczkowski
TL;TR. I would like to have a way to inform IDE that a passed in an annotation
Closure's execution is in fact delegated to a specific object (type). E.g.
"@Requires(\{ jvm.java11 })" should allow to write "jv" and see jvm in IDE
(once a delegate has that field/getter).
More detailed version (based on my question on the mailing list in [January
2020|https://mail-archives.apache.org/mod_mbox/groovy-users/202001.mbox/%3cb62eefce-5d71-f394-8024-f2dd93c12...@wp.pl%3e]).
One of the nice features of Spock is an ability to define conditions in Closure
when test(s) should (not) be executes with @Required/@IgnoreIf.
@Requires(\{ isSpecialConditionFulfilled() })
def "some test"() {}
The annotation itself is defined as:
@Retention(RetentionPolicy.RUNTIME)
@Target(\{ElementType.TYPE, ElementType.METHOD})
@ExtensionAnnotation(RequiresExtension.class)
public @interface Requires \{
Class value();
}
Down the line the execution is delegated to PreconditionContext which
provides convenient methods/objects such as os.linux, jvm.java11, env, etc.
{code:java}
@Requires({ jvm.java11 && os.linux }){code}
Unfortunately, there is no code completion as IDE doesn't know about
that delegation (and jvm, os fields/methods). Groovy 2 introduced
@DelegatesTo, however it cannot be used with other annotations or methods.
It can be tricked by creating a static final instance of PreconditionContext
(it's stateless) somewhere (e.g. in the Specification super class), but people
has to know to refer it, e.g:
@Requires(\{ CTX.jvm.java11 })
Alternatively, I was thinking about a method in the base Spock class:
{code:java}
protected static def ctx(@DelegatesTo(PreconditionContext) Closure closure) {
closure()
}{code}
which could be referenced as:
{code:java}
@Requires({ ctx { jvm.java10Compatible } }){code}
It works, but again "ctx" has to be referenced on demand.
The best long-term solution would be to allow to use @DelegatesTo at the method
level:
{code:java}
public @interface MyRequires {
@DelegatesTo(PreconditionContext.class) Class value();
} {code}
It would provide code completion out of the box (once IDEs have support for
that ). The second main drawback I see is being not very intuitive declaration
and limited usage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10055) STC does not support self bounded types
[
https://issues.apache.org/jira/browse/GROOVY-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348713#comment-17348713
]
Marcin Zajaczkowski commented on GROOVY-10055:
--
I believe have bumped into the same problem with:
{code:java}
WebClient.create(getBaseHttpUrl())
.get()
.uri("/path")
.accept(MediaType.APPLICATION_JSON)
.header("Authorization", "any")
Groovyc: [Static type checking] - Cannot call S#header(java.lang.String,
java.lang.String[]) with arguments [java.lang.String, groovy.lang.String{code}
accept() is defined as:
{code:java}
interface RequestHeadersSpec> {
S accept(MediaType... acceptableMediaTypes);
... {code}
When I explicitly cast the result of accept() to a typed class
(RequestHeadersSpec) the compilation passes.
It worked fine with 3.0.7 (Spock 2.0 final uses 3.0.8 which generates the
problem)
> STC does not support self bounded types
> ---
>
> Key: GROOVY-10055
> URL: https://issues.apache.org/jira/browse/GROOVY-10055
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.8
>Reporter: Damir Murat
>Assignee: Eric Milles
>Priority: Major
>
> Some popular libraries use self bounded types for creating builder
> hierarchies. For example,
> PostgreSQLContainer (from Tescontainers library) is declared as
> {code}
> public class PostgreSQLContainer>
> extends JdbcDatabaseContainer
> {code}
> where JdbcDatabaseContainer is declared as
> {code}
> public abstract class JdbcDatabaseContainer JdbcDatabaseContainer> extends GenericContainer implements
> LinkableContainer
> {code}
> and so on.
> In the following example (tested with Groovy Console), I'm trying to create
> and modify such an object with its corresponding fluent API:
> {code}
> import org.testcontainers.containers.PostgreSQLContainer
> import groovy.transform.CompileStatic
> @Grab("org.testcontainers:testcontainers:1.15.3")
> @Grab("org.testcontainers:postgresql:1.15.3")
> @CompileStatic
> class TestcontainersTester {
> static void testSome() {
> PostgreSQLContainer postgresqlServer = new PostgreSQLContainer()
> .withExposedPorts(5432)
> .withEnv(["TZ": "Europe/Paris"])
> .withDatabaseName("my_database")
> .withUsername("user")
> .withPassword("pass")
> // Working alternative 1
> //PostgreSQLContainer postgresqlServer = new
> PostgreSQLContainer>>>()
> //.withExposedPorts(5432)
> //.withEnv(["TZ": "Europe/Paris"])
> //.withDatabaseName("my_database")
> //.withUsername("user")
> //.withPassword("pass")
> // Working alternative 2
> //PostgreSQLContainer postgresqlServer = new PostgreSQLContainer<>()
> //postgresqlServer.withExposedPorts(5432)
> //postgresqlServer.withEnv(["TZ": "Europe/Paris"])
> //postgresqlServer.withDatabaseName("my_database")
> //postgresqlServer.withUsername("user")
> //postgresqlServer.withPassword("pass")
> println postgresqlServer
> }
> }
> TestcontainersTester.testSome();
> {code}
> Unfortunately, STC complains with several errors:
> {code}
> 4 compilation errors:
> [Static type checking] - Cannot call SELF#withEnv(java.util.Map
> ) with arguments [java.util.LinkedHashMap
> ]
> at line: 11, column: 17
> [Static type checking] - Cannot find matching method
> java.lang.Object#withDatabaseName(java.lang.String). Please check if the
> declared type is correct and if the method exists.
> at line: 12, column: 26
> [Static type checking] - Cannot find matching method
> java.lang.Object#withUsername(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 13, column: 22
> [Static type checking] - Cannot find matching method
> java.lang.Object#withPassword(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 9, column: 44
> {code}
> There are two working alternatives in the example. "Alternative 1" is not
> really practical, but maybe it can help with solving the issue. "Alternative
> 2" is an actual practical workaround that can be further improved by using
> the "with" method.
> Tnx
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-10040) @AnnotationCollector - Only classes and closures can be used for attribute 'value' in ...
[
https://issues.apache.org/jira/browse/GROOVY-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332557#comment-17332557
]
Marcin Zajaczkowski edited comment on GROOVY-10040 at 4/26/21, 4:14 PM:
I was able to reproduce that problem without Closure. Using any enum is also
problematic
{code:java}
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
Class clazz = loader.parseClass("""
//@${CustomCompiler.class.packageName}.EnumAnnotation(${CustomCompiler.class.packageName}.MyEnum.BAR)
//works fine
@${CustomCompiler.class.packageName}.MetaEnum
class Foo {
void foo() {
}
}
""")
assert clazz
}
}
enum MyEnum {
FOO, BAR
}
@interface EnumAnnotation {
MyEnum value()
}
@EnumAnnotation(MyEnum.BAR)
@AnnotationCollector
@interface MetaEnum {
}
{code}
With an error:
{code:java}
Exception in thread "main"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script_38dfc334e76a8e3f31d2efef7266fb23.groovy: -1: Expected enum value for
attribute value in @info.solidsoft.blog.spock2.migration.EnumAnnotation
@ line -1, column -1.
1 error
...{code}
was (Author: szpak):
I was able to reproduce that problem without Closure. Using any enum is also
problematic
{code:java}
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
Class clazz = loader.parseClass("""
//@${CustomCompiler.class.packageName}.EnumAnnotation(${CustomCompiler.class.packageName}.MyEnum.BAR)
//works fine
@${CustomCompiler.class.packageName}.MetaEnum
class Foo {
void foo() {
}
}
""")
assert clazz
}
}
enum MyEnum {
FOO, BAR
}
@interface EnumAnnotation {
MyEnum value()
}
@EnumAnnotation(MyEnum.BAR)
@AnnotationCollector
@interface MetaEnum {
}
{code}
> @AnnotationCollector - Only classes and closures can be used for attribute
> 'value' in ...
> -
>
> Key: GROOVY-10040
> URL: https://issues.apache.org/jira/browse/GROOVY-10040
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.7
> Environment: Groovy 3.0.7
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> I've bumped into that problem writing regression tests for using
> @AnnotationCollector in Spock to achieve meta-annotation support. A custom
> annotation accepting Clusure is problematic with @AnnotationCollector. It
> compiles file with groovyc, but not with ClassLoader (which is used by
> Spock's EmbeddedSpecCompiler).
> The problem can be simply reproduced with `GroovyClassLoader`:
> {code:java}
> package foobar
> import groovy.transform.AnnotationCollector
> class CustomCompiler {
> final GroovyClassLoader loader = new
> GroovyClassLoader(getClass().classLoader)
> static void main(String[] args) {
> new CustomCompiler().compile()
> }
> void compile() {
> Class clazz = loader.parseClass("""
> //@${CustomCompiler.class.packageName}.RetryCustom //works fine
> @${CustomCompiler.class.packageName}.MetaCustom
> //MultipleCompilationErrorsException exception
> class Foo {
> void foo() {
> }
> }
> """)
> assert clazz
> }
> }
> @RetryCustom(1)
> @RequiresCustom({ 1 == 1 })
> @AnnotationCollector
> @interface MetaCustom {
> }
> @interface RequiresCustom {
> Class value()
> }
> @interface RetryCustom {
> int value()
> }
> {code}
> which results in:
> {code:java}
> Exception in thread "main"
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Script_45e27a459ca58d9b86efd544e2929b39.groovy: -1: Only classes and closures
> can be used for attribute 'value' in @foobar.RequiresCustom
> @ line -1, column -1.
> 1 error
> at
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:295)
> at
> org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:984)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:389)
> at
> groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332)
> at
> org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163)
> at
> org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330)
> at
[jira] [Commented] (GROOVY-10040) @AnnotationCollector - Only classes and closures can be used for attribute 'value' in ...
[
https://issues.apache.org/jira/browse/GROOVY-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332557#comment-17332557
]
Marcin Zajaczkowski commented on GROOVY-10040:
--
I was able to reproduce that problem without Closure. Using any enum is also
problematic
{code:java}
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
Class clazz = loader.parseClass("""
//@${CustomCompiler.class.packageName}.EnumAnnotation(${CustomCompiler.class.packageName}.MyEnum.BAR)
//works fine
@${CustomCompiler.class.packageName}.MetaEnum
class Foo {
void foo() {
}
}
""")
assert clazz
}
}
enum MyEnum {
FOO, BAR
}
@interface EnumAnnotation {
MyEnum value()
}
@EnumAnnotation(MyEnum.BAR)
@AnnotationCollector
@interface MetaEnum {
}
{code}
> @AnnotationCollector - Only classes and closures can be used for attribute
> 'value' in ...
> -
>
> Key: GROOVY-10040
> URL: https://issues.apache.org/jira/browse/GROOVY-10040
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.7
> Environment: Groovy 3.0.7
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> I've bumped into that problem writing regression tests for using
> @AnnotationCollector in Spock to achieve meta-annotation support. A custom
> annotation accepting Clusure is problematic with @AnnotationCollector. It
> compiles file with groovyc, but not with ClassLoader (which is used by
> Spock's EmbeddedSpecCompiler).
> The problem can be simply reproduced with `GroovyClassLoader`:
> {code:java}
> package foobar
> import groovy.transform.AnnotationCollector
> class CustomCompiler {
> final GroovyClassLoader loader = new
> GroovyClassLoader(getClass().classLoader)
> static void main(String[] args) {
> new CustomCompiler().compile()
> }
> void compile() {
> Class clazz = loader.parseClass("""
> //@${CustomCompiler.class.packageName}.RetryCustom //works fine
> @${CustomCompiler.class.packageName}.MetaCustom
> //MultipleCompilationErrorsException exception
> class Foo {
> void foo() {
> }
> }
> """)
> assert clazz
> }
> }
> @RetryCustom(1)
> @RequiresCustom({ 1 == 1 })
> @AnnotationCollector
> @interface MetaCustom {
> }
> @interface RequiresCustom {
> Class value()
> }
> @interface RetryCustom {
> int value()
> }
> {code}
> which results in:
> {code:java}
> Exception in thread "main"
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Script_45e27a459ca58d9b86efd544e2929b39.groovy: -1: Only classes and closures
> can be used for attribute 'value' in @foobar.RequiresCustom
> @ line -1, column -1.
> 1 error
> at
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:295)
> at
> org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:984)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:389)
> at
> groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332)
> at
> org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163)
> at
> org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrap.invoke(PojoMetaMethodSite.java:203)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at
>
[jira] [Created] (GROOVY-10041) @AnnotationCollector - CompileDynamicProcessor seems to be ignored
Marcin Zajaczkowski created GROOVY-10041:
Summary: @AnnotationCollector - CompileDynamicProcessor seems to
be ignored
Key: GROOVY-10041
URL: https://issues.apache.org/jira/browse/GROOVY-10041
Project: Groovy
Issue Type: Bug
Components: Compiler, Static compilation
Affects Versions: 3.0.7
Environment: Groovy 3.0.7
Reporter: Marcin Zajaczkowski
I'm not able to make CompileDynamicProcessor works with @AnnotationCollector:
{code:java}
@Requires({ jvm.java8Compatible })
@AnnotationCollector(processor =
"org.codehaus.groovy.transform.CompileDynamicProcessor")
@interface MetaRequiresRepeated {
} {code}
fails with:
{code:java}
Groovyc: [Static type checking] - The variable [jvm] is undeclared. {code}
The same error is when I try to use @AnnotationCollector with default processor.
The @Requires annotation is defined in Spock as follows :
{code:java}
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@ExtensionAnnotation(RequiresExtension.class)
@Repeatable(Requires.Container.class)
public @interface Requires {
Class value();
/**
* @since 2.0
*/
@Beta
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@interface Container {
Requires[] value();
}
}{code}
and the Closure is executed in the context of a PreconditionContext which knows
jvm.
The following code works fine:
{code:java}
@Requires({ PreconditionContext pc -> pc.jvm.java8Compatible })
@AnnotationCollector
@interface MetaRequiresRepeated {
}{code}
Slightly related to GROOVY-10040
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10040) @AnnotationCollector - Only classes and closures can be used for attribute 'value' in ...
[
https://issues.apache.org/jira/browse/GROOVY-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-10040:
-
Description:
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
package foobar
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
Class clazz = loader.parseClass("""
//@${CustomCompiler.class.packageName}.RetryCustom //works fine
@${CustomCompiler.class.packageName}.MetaCustom
//MultipleCompilationErrorsException exception
class Foo {
void foo() {
}
}
""")
assert clazz
}
}
@RetryCustom(1)
@RequiresCustom({ 1 == 1 })
@AnnotationCollector
@interface MetaCustom {
}
@interface RequiresCustom {
Class value()
}
@interface RetryCustom {
int value()
}
{code}
which results in:
{code:java}
Exception in thread "main"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script_45e27a459ca58d9b86efd544e2929b39.groovy: -1: Only classes and closures
can be used for attribute 'value' in @foobar.RequiresCustom
@ line -1, column -1.
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:295)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:984)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:389)
at
groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrap.invoke(PojoMetaMethodSite.java:203)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
at foobar.CustomCompiler.compile(CustomCompiler.groovy:15)
at foobar.CustomCompiler$compile.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
at foobar.CustomCompiler.main(CustomCompiler.groovy:10)
{code}
If it really happens only with `GroovyClassLoader`,it is a minor problem.
However, I believe, I might have observed that occasionally while compiling
with Idea 2020.3 (but I'm not able to reproduce it right now and I might
confuse parameters).
was:
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
package foobar
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
[jira] [Updated] (GROOVY-10040) @AnnotationCollector - Only classes and closures can be used for attribute 'value' in ...
[
https://issues.apache.org/jira/browse/GROOVY-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-10040:
-
Description:
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
loader.clearCache()
Class clazz = loader.parseClass("""
//@${CustomCompiler.class.packageName}.RetryCustom //works fine
@${CustomCompiler.class.packageName}.MetaCustom
//MultipleCompilationErrorsException exception
class Foo {
void foo() {
}
}
""")
assert clazz
}
}
@RetryCustom(1)
@RequiresCustom({ 1 == 1 })
@AnnotationCollector
@interface MetaCustom {
}
@interface RequiresCustom {
Class value()
}
@interface RetryCustom {
int value()
}
{code}
which results in:
{code:java}
Exception in thread "main"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script_45e27a459ca58d9b86efd544e2929b39.groovy: -1: Only classes and closures
can be used for attribute 'value' in @foobar.RequiresCustom
@ line -1, column -1.
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:295)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:984)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:389)
at
groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrap.invoke(PojoMetaMethodSite.java:203)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
at foobar.CustomCompiler.compile(CustomCompiler.groovy:15)
at foobar.CustomCompiler$compile.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
at foobar.CustomCompiler.main(CustomCompiler.groovy:10)
{code}
If it really happens only with `GroovyClassLoader`,it is a minor problem.
However, I believe, I might have observed that occasionally while compiling
with Idea 2020.3 (but I'm not able to reproduce it right now and I might
confuse parameters).
was:
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
loader.clearCache()
Class
[jira] [Updated] (GROOVY-10040) @AnnotationCollector - Only classes and closures can be used for attribute 'value' in ...
[
https://issues.apache.org/jira/browse/GROOVY-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-10040:
-
Description:
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
package foobar
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
loader.clearCache()
Class clazz = loader.parseClass("""
//@${CustomCompiler.class.packageName}.RetryCustom //works fine
@${CustomCompiler.class.packageName}.MetaCustom
//MultipleCompilationErrorsException exception
class Foo {
void foo() {
}
}
""")
assert clazz
}
}
@RetryCustom(1)
@RequiresCustom({ 1 == 1 })
@AnnotationCollector
@interface MetaCustom {
}
@interface RequiresCustom {
Class value()
}
@interface RetryCustom {
int value()
}
{code}
which results in:
{code:java}
Exception in thread "main"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script_45e27a459ca58d9b86efd544e2929b39.groovy: -1: Only classes and closures
can be used for attribute 'value' in @foobar.RequiresCustom
@ line -1, column -1.
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:295)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:984)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:389)
at
groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrap.invoke(PojoMetaMethodSite.java:203)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
at foobar.CustomCompiler.compile(CustomCompiler.groovy:15)
at foobar.CustomCompiler$compile.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
at foobar.CustomCompiler.main(CustomCompiler.groovy:10)
{code}
If it really happens only with `GroovyClassLoader`,it is a minor problem.
However, I believe, I might have observed that occasionally while compiling
with Idea 2020.3 (but I'm not able to reproduce it right now and I might
confuse parameters).
was:
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
[jira] [Updated] (GROOVY-10040) @AnnotationCollector - Only classes and closures can be used for attribute 'value' in ...
[
https://issues.apache.org/jira/browse/GROOVY-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-10040:
-
Description:
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
loader.clearCache()
Class clazz = loader.parseClass("""
//@${CustomCompiler.class.packageName}.RetryCustom //works fine
@${CustomCompiler.class.packageName}.MetaCustom
//MultipleCompilationErrorsException exception
class Foo {
void foo() {
}
}
""")
assert clazz
}
}
@RetryCustom(1)
@RequiresCustom({ 1 == 1 })
@AnnotationCollector
@interface MetaCustom {
}
@interface RequiresCustom {
Class value()
}
@interface RetryCustom {
int value()
}
{code}
which results in:
{code:java}
Exception in thread "main"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script_45e27a459ca58d9b86efd544e2929b39.groovy: -1: Only classes and closures
can be used for attribute 'value' in @foobar.RequiresCustom
@ line -1, column -1.
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:295)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:984)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:389)
at
groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrap.invoke(PojoMetaMethodSite.java:203)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
at foobar.CustomCompiler.compile(CustomCompiler.groovy:15)
at foobar.CustomCompiler$compile.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
at foobar.CustomCompiler.main(CustomCompiler.groovy:10)
{code}
If it really happens only with `GroovyClassLoader`,it is a minor problem.
However, I believe, I might have observed that occasionally while compiling
with Idea 2020.3 (but I'm not able to reproduce it right now and I might
confuse parameters).
was:
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
loader.clearCache()
Class
[jira] [Created] (GROOVY-10040) @AnnotationCollector - Only classes and closures can be used for attribute 'value' in ...
Marcin Zajaczkowski created GROOVY-10040:
Summary: @AnnotationCollector - Only classes and closures can be
used for attribute 'value' in ...
Key: GROOVY-10040
URL: https://issues.apache.org/jira/browse/GROOVY-10040
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 3.0.7
Environment: Groovy 3.0.7
Reporter: Marcin Zajaczkowski
I've bumped into that problem writing regression tests for using
@AnnotationCollector in Spock to achieve meta-annotation support. A custom
annotation accepting Clusure is problematic with @AnnotationCollector. It
compiles file with groovyc, but not with ClassLoader (which is used by Spock's
EmbeddedSpecCompiler).
The problem can be simply reproduced with `GroovyClassLoader`:
{code:java}
import groovy.transform.AnnotationCollector
class CustomCompiler {
final GroovyClassLoader loader = new GroovyClassLoader(getClass().classLoader)
static void main(String[] args) {
new CustomCompiler().compile()
}
void compile() {
loader.clearCache()
Class clazz = loader.parseClass("""
//@${CustomCompiler.class.packageName}.RetryCustom //works fine
@${CustomCompiler.class.packageName}.MetaCustom
//MultipleCompilationErrorsException exception
class Foo {
void foo() {
}
}
""")
assert clazz
}
}
@RetryCustom(1)
@RequiresCustom({ 1 == 1 })
@AnnotationCollector
@interface MetaCustom {
}
@interface RequiresCustom {
Class value()
}
@interface RetryCustom {
int value()
}
{code}
which results in:
{code:java}
Exception in thread "main"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script_45e27a459ca58d9b86efd544e2929b39.groovy: -1: Only classes and closures
can be used for attribute 'value' in @foobar.RequiresCustom
@ line -1, column -1.
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:295)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:984)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:389)
at
groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163)
at
org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrap.invoke(PojoMetaMethodSite.java:203)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
at foobar.CustomCompiler.compile(CustomCompiler.groovy:15)
at foobar.CustomCompiler$compile.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
at foobar.CustomCompiler.main(CustomCompiler.groovy:10)
{code}
If it really happens only with `GroovyClassLoader`,it is a minor problem.
However, I believe, I might have observed that occasionally while compiling
with Idea 2020.3 (but I'm not able to reproduce it right now and I might
confuse parameters).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9762) Wrong type resolved if method reference used with typed method
[
https://issues.apache.org/jira/browse/GROOVY-9762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9762:
Description:
I've encountered a problem with type checking if a method reference is used.
In following (stripped down from the original production case) code in the line
with the error variable the following error is reported:
{code:java}
> Task :compileTestGroovy
startup failed:
/home/foobar.../MethodReferenceProblemWithType.groovy: 15: [Static type
checking] - Cannot assign value of type java.lang.Object to variable of type
java.util.List
@ line 15, column 31.
List error = opt.map(this::just).get() {code}
{code:java}
@CompileStatic
class MethodReferenceProblemWithType {
static void reproduce() {
Optional opt = Optional.ofNullable(Integer.valueOf(1))
List ok = opt.map(o -> just(o)).get()//ok
List error = opt.map(this::just).get() //problem
}
private static List just(T data) {
return new ArrayList();
}
} {code}
If `@CompileStatic` is removed, I still see a type incompatibility warning in
Idea. Switching to lambda is a workaround, therefore it's just a minor glitch.
Tested with Groovy 3.0.5.
was:
I've encountered a problem with type checking if a method reference is used.
In following (stripped down from the original production case) code in the line
with the error variable the following error is reported:
{code:java}
> Task :compileTestGroovy
startup failed:
/home/foobar.../MethodReferenceProblemWithType.groovy: 15: [Static type
checking] - Cannot assign value of type java.lang.Object to variable of type
java.util.List
@ line 15, column 31.
List error = opt.map(this::just).get() {code}
{code:java}
@CompileStatic
class MethodReferenceProblemWithType {
static void reproduce() {
Optional opt = Optional.ofNullable(Integer.valueOf(1))
List ok = opt.map(o -> just(o)).get()//ok
List error = opt.map(this::just).get() //problem
}
private static List just(T data) {
return new ArrayList();
}
} {code}
If `@CompileStatic` is removed, I still see a type incompatibility warning in
Idea. Switching to lambda is an workaround. Tested with Groovy 3.0.5.
> Wrong type resolved if method reference used with typed method
> --
>
> Key: GROOVY-9762
> URL: https://issues.apache.org/jira/browse/GROOVY-9762
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.5
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> I've encountered a problem with type checking if a method reference is used.
> In following (stripped down from the original production case) code in the
> line with the error variable the following error is reported:
> {code:java}
> > Task :compileTestGroovy
> startup failed:
> /home/foobar.../MethodReferenceProblemWithType.groovy: 15: [Static type
> checking] - Cannot assign value of type java.lang.Object to variable of type
> java.util.List
> @ line 15, column 31.
> List error = opt.map(this::just).get() {code}
> {code:java}
> @CompileStatic
> class MethodReferenceProblemWithType {
> static void reproduce() {
> Optional opt = Optional.ofNullable(Integer.valueOf(1))
> List ok = opt.map(o -> just(o)).get()//ok
> List error = opt.map(this::just).get() //problem
> }
> private static List just(T data) {
> return new ArrayList();
> }
> } {code}
> If `@CompileStatic` is removed, I still see a type incompatibility warning in
> Idea. Switching to lambda is a workaround, therefore it's just a minor
> glitch. Tested with Groovy 3.0.5.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9762) Wrong type resolved if method reference used with typed method
Marcin Zajaczkowski created GROOVY-9762:
---
Summary: Wrong type resolved if method reference used with typed
method
Key: GROOVY-9762
URL: https://issues.apache.org/jira/browse/GROOVY-9762
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 3.0.5
Reporter: Marcin Zajaczkowski
I've encountered a problem with type checking if a method reference is used.
In following (stripped down from the original production case) code in the line
with the error variable the following error is reported:
{code:java}
> Task :compileTestGroovy
startup failed:
/home/foobar.../MethodReferenceProblemWithType.groovy: 15: [Static type
checking] - Cannot assign value of type java.lang.Object to variable of type
java.util.List
@ line 15, column 31.
List error = opt.map(this::just).get() {code}
{code:java}
@CompileStatic
class MethodReferenceProblemWithType {
static void reproduce() {
Optional opt = Optional.ofNullable(Integer.valueOf(1))
List ok = opt.map(o -> just(o)).get()//ok
List error = opt.map(this::just).get() //problem
}
private static List just(T data) {
return new ArrayList();
}
} {code}
If `@CompileStatic` is removed, I still see a type incompatibility warning in
Idea. Switching to lambda is an workaround. Tested with Groovy 3.0.5.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9492) Relax groovy.test.NotYetImplemented dependency on JUnit 4's AssertionFailedError
[
https://issues.apache.org/jira/browse/GROOVY-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9492:
Description:
Working on removing the remainder of JUnit 4 from spock-core, I have
encountered {{@groovy.transform.NotYetImplemented}} which transformation is
wired to {{junit.framework.AssertionFailedError}}. It's deprecated in favor of
{{@groovy.test.NotYetImplemented}}, but the corresponding transformation is
also wired to {{AssertionFailedError}}. That makes its usage without JUnit 4
(and also testing in Spock 2) harder
It would be good to check at runtime which exception is available at classpath
to work also in the situation without JUnit 4 on classpath.
Btw, I don't know which component should I choose. There is no groovy-test
component.
was:
Working on removing the remainder of JUnit 4 from spock-core, I have
encountered {{@groovy.transform.NotYetImplemented}} which transformation is
wired to {{junit.framework.AssertionFailedError}}. It's deprecated in favor of
{{@groovy.test.NotYetImplemented}}, but the corresponding transformation is
also wired to {{AssertionFailedError}}. That makes its usage without JUnit 4
(and also testing in Spock 2) harder
It would be good to check at runtime which exception is available at classpath
to works also in the situation without JUnit 4 on classpath.
Btw, I don't know which component should I choose. There is no groovy-test
component.
> Relax groovy.test.NotYetImplemented dependency on JUnit 4's
> AssertionFailedError
>
>
> Key: GROOVY-9492
> URL: https://issues.apache.org/jira/browse/GROOVY-9492
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-test-junit5
>Affects Versions: 3.0.2
>Reporter: Marcin Zajaczkowski
>Assignee: Paul King
>Priority: Minor
> Labels: breaking
> Fix For: 4.0.0-alpha-1, 3.0.3
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Working on removing the remainder of JUnit 4 from spock-core, I have
> encountered {{@groovy.transform.NotYetImplemented}} which transformation is
> wired to {{junit.framework.AssertionFailedError}}. It's deprecated in favor
> of {{@groovy.test.NotYetImplemented}}, but the corresponding transformation
> is also wired to {{AssertionFailedError}}. That makes its usage without JUnit
> 4 (and also testing in Spock 2) harder
> It would be good to check at runtime which exception is available at
> classpath to work also in the situation without JUnit 4 on classpath.
>
> Btw, I don't know which component should I choose. There is no groovy-test
> component.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[ https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082360#comment-17082360 ] Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 2:42 PM: --- Yes, it's rather a separate issue related to the fact how integration tests are configured. Most likely not Java 14 related. was (Author: szpak): It's rather a separate issue related to the fact how integration tests are configured. Most likely not Java 14 related. > Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in > Spock tests > - > > Key: GROOVY-9505 > URL: https://issues.apache.org/jira/browse/GROOVY-9505 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 3.0.3 > Environment: Ubuntu 20.04 > Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition) > Build #IU-201.6668.121, built on April 8, 2020 > Runtime version: 11.0.6+8-b765.25 amd64 > Adopt Open JDK 14.0.0.hs-adpt >Reporter: Kamil Jedrzejuk >Priority: Critical > Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from > 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png, > image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png, > image-2020-04-13-16-31-38-734.png, image-2020-04-13-16-31-47-635.png, > image-2020-04-13-16-32-50-825.png > > Original Estimate: 720h > Time Spent: 10m > Remaining Estimate: 719h 50m > > I have a problem with integration tests. I've updated Java from 11 to 14. > I can compile my application, but I can't run a integration tests. > I'm using a Gradle 6.3 > Open JDK 14 > Spring Boot 2.4 > 2.0-M2-groovy-3.0 > > The code you can find here > [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[ https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082360#comment-17082360 ] Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 2:42 PM: --- Yes, it's rather a separate issue related to the fact how integration tests are configured. was (Author: szpak): Yes, it's rather a separate issue related to the fact how integration tests are configured. Most likely not Java 14 related. > Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in > Spock tests > - > > Key: GROOVY-9505 > URL: https://issues.apache.org/jira/browse/GROOVY-9505 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 3.0.3 > Environment: Ubuntu 20.04 > Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition) > Build #IU-201.6668.121, built on April 8, 2020 > Runtime version: 11.0.6+8-b765.25 amd64 > Adopt Open JDK 14.0.0.hs-adpt >Reporter: Kamil Jedrzejuk >Priority: Critical > Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from > 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png, > image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png, > image-2020-04-13-16-31-38-734.png, image-2020-04-13-16-31-47-635.png, > image-2020-04-13-16-32-50-825.png > > Original Estimate: 720h > Time Spent: 10m > Remaining Estimate: 719h 50m > > I have a problem with integration tests. I've updated Java from 11 to 14. > I can compile my application, but I can't run a integration tests. > I'm using a Gradle 6.3 > Open JDK 14 > Spring Boot 2.4 > 2.0-M2-groovy-3.0 > > The code you can find here > [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[ https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082360#comment-17082360 ] Marcin Zajaczkowski commented on GROOVY-9505: - It's rather a separate issue related to the fact how integration tests are configured. Most likely not Java 14 related. > Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in > Spock tests > - > > Key: GROOVY-9505 > URL: https://issues.apache.org/jira/browse/GROOVY-9505 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 3.0.3 > Environment: Ubuntu 20.04 > Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition) > Build #IU-201.6668.121, built on April 8, 2020 > Runtime version: 11.0.6+8-b765.25 amd64 > Adopt Open JDK 14.0.0.hs-adpt >Reporter: Kamil Jedrzejuk >Priority: Critical > Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from > 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png, > image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png, > image-2020-04-13-16-31-38-734.png, image-2020-04-13-16-31-47-635.png, > image-2020-04-13-16-32-50-825.png > > Original Estimate: 720h > Time Spent: 10m > Remaining Estimate: 719h 50m > > I have a problem with integration tests. I've updated Java from 11 to 14. > I can compile my application, but I can't run a integration tests. > I'm using a Gradle 6.3 > Open JDK 14 > Spring Boot 2.4 > 2.0-M2-groovy-3.0 > > The code you can find here > [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082349#comment-17082349
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 2:30 PM:
---
**Update**. My response to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
was (Author: szpak):
**Update**. Response to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png,
> image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png
>
> Original Estimate: 720h
> Time Spent: 10m
> Remaining Estimate: 719h 50m
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082349#comment-17082349
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 2:29 PM:
---
**Update**. Response to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
was (Author: szpak):
**Update**. Response to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png,
> image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png
>
> Original Estimate: 720h
> Time Spent: 10m
> Remaining Estimate: 719h 50m
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082349#comment-17082349
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 2:29 PM:
---
**Update**. Response to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
was (Author: szpak):
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
**Update**. hmm, I responded to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png,
> image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png
>
> Original Estimate: 720h
> Time Spent: 10m
> Remaining Estimate: 719h 50m
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082349#comment-17082349
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 2:28 PM:
---
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
**Update**. hmm, I responded to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
was (Author: szpak):
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
**Update**. I responded to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png,
> image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png
>
> Original Estimate: 720h
> Time Spent: 10m
> Remaining Estimate: 719h 50m
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082349#comment-17082349
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 2:28 PM:
---
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
**Update**. I responded to the comment that was deleted:
{code:java}
_/home/kamil/Documents/projects/priv/weatherinformer/src/test/groovy/com/twitter/kamilyedrzejuq/weather/domain/SampleData.java:17:
error: cannot find symbol_
_return FetchCityWeatherCommand.of(cityName);_
_^_
_symbol: method of(String)_ {code}
was (Author: szpak):
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png,
> image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png
>
> Original Estimate: 720h
> Time Spent: 10m
> Remaining Estimate: 719h 50m
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082349#comment-17082349
]
Marcin Zajaczkowski commented on GROOVY-9505:
-
And this comes back to my original question to Paul :).
> Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production
> code?
> (assuming ASM_API_VERSION in
>[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
> is changed to Opcodes.ASM8)
It seems that no and there is some extra work required on the Groovy side to
deal with that bytecode.
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png,
> image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png
>
> Original Estimate: 720h
> Time Spent: 10m
> Remaining Estimate: 719h 50m
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082343#comment-17082343
]
Marcin Zajaczkowski commented on GROOVY-9505:
-
And that is the result after those changes? :)
Still "{{java.lang.UnsupportedOperationException: This feature requires ASM8}}"?
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png,
> image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png
>
> Original Estimate: 720h
> Time Spent: 10m
> Remaining Estimate: 719h 50m
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[ https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082326#comment-17082326 ] Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 2:01 PM: --- In addition you might want to do the same for "GroovyCompile" tasks (or "AbstractCompile" in general). was (Author: szpak): In addition you might want to do the same for "GroovyCompile" tasks. > Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in > Spock tests > - > > Key: GROOVY-9505 > URL: https://issues.apache.org/jira/browse/GROOVY-9505 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 3.0.0-beta-2 > Environment: Ubuntu 20.04 > Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition) > Build #IU-201.6668.121, built on April 8, 2020 > Runtime version: 11.0.6+8-b765.25 amd64 > Adopt Open JDK 14.0.0.hs-adpt >Reporter: Kamil Jedrzejuk >Priority: Critical > Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from > 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png, > image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png > > Original Estimate: 720h > Time Spent: 10m > Remaining Estimate: 719h 50m > > I have a problem with integration tests. I've updated Java from 11 to 14. > I can compile my application, but I can't run a integration tests. > I'm using a Gradle 6.3 > Open JDK 14 > Spring Boot 2.4 > 2.0-M2-groovy-3.0 > > The code you can find here > [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[ https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082326#comment-17082326 ] Marcin Zajaczkowski commented on GROOVY-9505: - In addition you might want to do the same for "GroovyCompile" tasks. > Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in > Spock tests > - > > Key: GROOVY-9505 > URL: https://issues.apache.org/jira/browse/GROOVY-9505 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 3.0.0-beta-2 > Environment: Ubuntu 20.04 > Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition) > Build #IU-201.6668.121, built on April 8, 2020 > Runtime version: 11.0.6+8-b765.25 amd64 > Adopt Open JDK 14.0.0.hs-adpt >Reporter: Kamil Jedrzejuk >Priority: Critical > Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from > 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png, > image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png > > Original Estimate: 720h > Time Spent: 10m > Remaining Estimate: 719h 50m > > I have a problem with integration tests. I've updated Java from 11 to 14. > I can compile my application, but I can't run a integration tests. > I'm using a Gradle 6.3 > Open JDK 14 > Spring Boot 2.4 > 2.0-M2-groovy-3.0 > > The code you can find here > [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[ https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082325#comment-17082325 ] Marcin Zajaczkowski commented on GROOVY-9505: - Have you enabled it properly? https://blog.solidsoft.pl/2020/03/02/enable-java-14-preview-features-in-gradle-maven-and-idea/#gradle > Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in > Spock tests > - > > Key: GROOVY-9505 > URL: https://issues.apache.org/jira/browse/GROOVY-9505 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 3.0.0-beta-2 > Environment: Ubuntu 20.04 > Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition) > Build #IU-201.6668.121, built on April 8, 2020 > Runtime version: 11.0.6+8-b765.25 amd64 > Adopt Open JDK 14.0.0.hs-adpt >Reporter: Kamil Jedrzejuk >Priority: Critical > Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from > 2020-04-12 22-23-52.png, image-2020-04-13-15-35-10-149.png, > image-2020-04-13-15-35-15-834.png, image-2020-04-13-15-51-39-107.png > > Original Estimate: 720h > Remaining Estimate: 720h > > I have a problem with integration tests. I've updated Java from 11 to 14. > I can compile my application, but I can't run a integration tests. > I'm using a Gradle 6.3 > Open JDK 14 > Spring Boot 2.4 > 2.0-M2-groovy-3.0 > > The code you can find here > [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082313#comment-17082313
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 1:32 PM:
---
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
in Groovy source code to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, used it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?
was (Author: szpak):
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
in Groovy source code to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082313#comment-17082313
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 1:31 PM:
---
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
in Groovy source code to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?
was (Author: szpak):
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
in Groovy source code to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082313#comment-17082313
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 1:31 PM:
---
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
in Groovy source code to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?\{{}}
was (Author: szpak):
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?\{{}}
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082313#comment-17082313
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 1:31 PM:
---
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
in Groovy source code to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?
was (Author: szpak):
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
in Groovy source code to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?\{{}}
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082313#comment-17082313
]
Marcin Zajaczkowski commented on GROOVY-9505:
-
[~CamilYed] Have you change [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?{{}}
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082313#comment-17082313
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 1:30 PM:
---
[~CamilYed] Have you changed [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?\{{}}
was (Author: szpak):
[~CamilYed] Have you change [this
line|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
to:
> public static final int ASM_API_VERSION = Opcodes.ASM8;
built Groovy locally, use it in your project and still have:
> {{java.lang.UnsupportedOperationException: This feature requires ASM8}}
?{{}}
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[ https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082299#comment-17082299 ] Marcin Zajaczkowski commented on GROOVY-9505: - It's not a problem with the asm version anymore. 3.0.3 uses 8.1. However, as I mentioned in my last comment CompilerConfiguration (also in master) uses Opcodes.ASM7 which generates the last error (see the asm code in the given line). The case, I asked Paul, is if it there are other things to do to make Groovy be able to recognized record in compiled Java 14 code. The thing you [~CamilYed] may - if you have time - is to bump this (Opcodes.ASM8) locally, compile and build Groovy and (if successful) check if that snapshot works in your project. > Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in > Spock tests > - > > Key: GROOVY-9505 > URL: https://issues.apache.org/jira/browse/GROOVY-9505 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 3.0.0-beta-2 > Environment: Ubuntu 20.04 > Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition) > Build #IU-201.6668.121, built on April 8, 2020 > Runtime version: 11.0.6+8-b765.25 amd64 > Adopt Open JDK 14.0.0.hs-adpt >Reporter: Kamil Jedrzejuk >Priority: Critical > Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from > 2020-04-12 22-23-52.png > > Original Estimate: 720h > Remaining Estimate: 720h > > I have a problem with integration tests. I've updated Java from 11 to 14. > I can compile my application, but I can't run a integration tests. > I'm using a Gradle 6.3 > Open JDK 14 > Spring Boot 2.4 > 2.0-M2-groovy-3.0 > > The code you can find here > [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082237#comment-17082237
]
Marcin Zajaczkowski edited comment on GROOVY-9505 at 4/13/20, 11:12 AM:
[~paulk] I made a separate investigation in the meantime
[here|https://github.com/spockframework/spock/issues/1142#issuecomment-612855754]
and the key question there is:
Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production code?
(assuming ASM_API_VERSION in
[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
is changed to Opcodes.ASM8)
was (Author: szpak):
[~paulk] I made a separate investigation in the meantime
[here|https://github.com/spockframework/spock/issues/1142#issuecomment-612855754]
and the key question there is:
Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production code?
(once ASM_API_VERSION in
[CompilerConfiguration|https://github.com/apache/groovy/blob/a9946449a943fcf55204f8bbfaa71f3419500f2a/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L125]
is changed to Opcodes.ASM8)
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9505) Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in Spock tests
[
https://issues.apache.org/jira/browse/GROOVY-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082237#comment-17082237
]
Marcin Zajaczkowski commented on GROOVY-9505:
-
[~paulk] I made a separate investigation in the meantime
[here|https://github.com/spockframework/spock/issues/1142#issuecomment-612855754
] and the key question there is:
Can Groovy (3.0.3) interact with {{record}} defined in Java 14 production code?
> Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 on JDK 14 in
> Spock tests
> -
>
> Key: GROOVY-9505
> URL: https://issues.apache.org/jira/browse/GROOVY-9505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0-beta-2
> Environment: Ubuntu 20.04
> Intellij IDEA IntelliJ IDEA 2020.1 (Ultimate Edition)
> Build #IU-201.6668.121, built on April 8, 2020
> Runtime version: 11.0.6+8-b765.25 amd64
> Adopt Open JDK 14.0.0.hs-adpt
>Reporter: Kamil Jedrzejuk
>Priority: Critical
> Attachments: Screenshot from 2020-04-12 22-23-10.png, Screenshot from
> 2020-04-12 22-23-52.png
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> I have a problem with integration tests. I've updated Java from 11 to 14.
> I can compile my application, but I can't run a integration tests.
> I'm using a Gradle 6.3
> Open JDK 14
> Spring Boot 2.4
> 2.0-M2-groovy-3.0
>
> The code you can find here
> [https://github.com/KamilJedrzejuk/weatherinformer/tree/develop]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9492) Relax groovy.test.NotYetImplemented dependency on JUnit 4's AssertionFailedError
[
https://issues.apache.org/jira/browse/GROOVY-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076177#comment-17076177
]
Marcin Zajaczkowski commented on GROOVY-9492:
-
I tested 3.0.3-SNAPSHOT in Spock tests for `@NotYetImplemented` and it works
fine without JUnit 4 on classpath. Thanks!
> Relax groovy.test.NotYetImplemented dependency on JUnit 4's
> AssertionFailedError
>
>
> Key: GROOVY-9492
> URL: https://issues.apache.org/jira/browse/GROOVY-9492
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-test-junit5
>Affects Versions: 3.0.2
>Reporter: Marcin Zajaczkowski
>Assignee: Paul King
>Priority: Minor
> Labels: breaking
> Fix For: 4.0.0-alpha-1, 3.0.3
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Working on removing the remainder of JUnit 4 from spock-core, I have
> encountered {{@groovy.transform.NotYetImplemented}} which transformation is
> wired to {{junit.framework.AssertionFailedError}}. It's deprecated in favor
> of {{@groovy.test.NotYetImplemented}}, but the corresponding transformation
> is also wired to {{AssertionFailedError}}. That makes its usage without JUnit
> 4 (and also testing in Spock 2) harder
> It would be good to check at runtime which exception is available at
> classpath to works also in the situation without JUnit 4 on classpath.
>
> Btw, I don't know which component should I choose. There is no groovy-test
> component.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9492) Relax groovy.test.NotYetImplemented dependency on JUnit 4's AssertionFailedError
Marcin Zajaczkowski created GROOVY-9492:
---
Summary: Relax groovy.test.NotYetImplemented dependency on JUnit
4's AssertionFailedError
Key: GROOVY-9492
URL: https://issues.apache.org/jira/browse/GROOVY-9492
Project: Groovy
Issue Type: Improvement
Components: groovy-test-junit5
Affects Versions: 3.0.2
Reporter: Marcin Zajaczkowski
Working on removing the remainder of JUnit 4 from spock-core, I have
encountered {{@groovy.transform.NotYetImplemented}} which transformation is
wired to {{junit.framework.AssertionFailedError}}. It's deprecated in favor of
{{@groovy.test.NotYetImplemented}}, but the corresponding transformation is
also wired to {{AssertionFailedError}}. That makes its usage without JUnit 4
(and also testing in Spock 2) harder
It would be good to check at runtime which exception is available at classpath
to works also in the situation without JUnit 4 on classpath.
Btw, I don't know which component should I choose. There is no groovy-test
component.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-8411) Support instanceof-like flow typing for class literal switch case
[
https://issues.apache.org/jira/browse/GROOVY-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059778#comment-17059778
]
Marcin Zajaczkowski commented on GROOVY-8411:
-
[~emilles] Would it be possible to backport your implementation in
[https://github.com/groovy/groovy-eclipse/issues/1056] to Apache Groovy?
> Support instanceof-like flow typing for class literal switch case
> -
>
> Key: GROOVY-8411
> URL: https://issues.apache.org/jira/browse/GROOVY-8411
> Project: Groovy
> Issue Type: Improvement
>Reporter: Eric Milles
>Priority: Minor
>
> Would it be possible to extend the {{maybeFile instanceof File ?
> maybeFile.canonicalPath : maybeFile.toString()}} flow typing where
> {{maybeFile}} is seen as {{File}} in the true expression position to work for
> {{switch}}?
> This is the kind of construct I am thinking of:
> {code}
> switch (maybeFile) {
> case File:
> maybeFile.canonicalPath
> break
> default:
> maybeFile.toString()
> }
> {code}
> Currently the example fails in an {{@TypeChecked}} or {{@CompileStatic}}
> scope, there is an error for the {{canonicalPath}} reference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9470) Automatic type casting with switch..case with instanceof
[
https://issues.apache.org/jira/browse/GROOVY-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059777#comment-17059777
]
Marcin Zajaczkowski commented on GROOVY-9470:
-
Thanks, closing in favor of GROOVY-8411.
> Automatic type casting with switch..case with instanceof
>
>
> Key: GROOVY-9470
> URL: https://issues.apache.org/jira/browse/GROOVY-9470
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 3.0.2
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> It could be useful to have automatic type casting (also with static
> compilation) with switch..case with instanceof:
> {code:java}
> void sortItOut(Object o) {
> switch(o) {
> case String:
> println "String: ${o.length()}" //currently only in dynamic Groovy
> break
> case Integer:
> println "Integer: ${o.longValue()}" //currently only in dynamic
> Groovy
> break
> default:
> throw new IllegalArgumentException(o.toString())
> }
> }
> {code}
> The same as currently for if with instanceof:
> {code:java}
> if (o instanceof String) {
> useString(o)
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GROOVY-9470) Automatic type casting with switch..case with instanceof
[
https://issues.apache.org/jira/browse/GROOVY-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski closed GROOVY-9470.
---
Resolution: Duplicate
> Automatic type casting with switch..case with instanceof
>
>
> Key: GROOVY-9470
> URL: https://issues.apache.org/jira/browse/GROOVY-9470
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 3.0.2
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> It could be useful to have automatic type casting (also with static
> compilation) with switch..case with instanceof:
> {code:java}
> void sortItOut(Object o) {
> switch(o) {
> case String:
> println "String: ${o.length()}" //currently only in dynamic Groovy
> break
> case Integer:
> println "Integer: ${o.longValue()}" //currently only in dynamic
> Groovy
> break
> default:
> throw new IllegalArgumentException(o.toString())
> }
> }
> {code}
> The same as currently for if with instanceof:
> {code:java}
> if (o instanceof String) {
> useString(o)
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9469) Original exception during global AST transformation no longer preserved in error message
[
https://issues.apache.org/jira/browse/GROOVY-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9469:
Description:
Global AST transformation in Spock throws exception with meaningful error
message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
executed with Groovy 2.4):
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception org.spockframework.util.IncompatibleGroovyVersionException:
The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is not
compatible
with Groovy 2.4.3. For more information, see
http://versioninfo.spockframework.org
Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
Groovy artifact: file:/.../groovy-2.4.3.jar
{code}
However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception java.lang.reflect.InvocationTargetException
{code}
It's not very constructive for people seeing that error message. Firstly, I
suspected some incompatibilities in the Spock code which completely fails with
new Groovy. However, it turned out that the exception is hidden by Groovy
itself.
I slightly modified ASTTransformationVisitor it detect that situation and get
target/cause in a case of InvocationTargetException - my
[PR|https://github.com/apache/groovy/pull/1193].
It helped, however, I haven't found any change in the ASTTransformationVisitor
which could cause that regression. It might to some 2.5→3.0 change how
constructor are called (e.g. around CachedConstructor which is used, but
doesn't seem to intercept the exception) or anything else. You might want to
investigate it - it worked without my tweak in Groovy 2.5.
Related Spock issues: [https://github.com/spockframework/spock/issues/1067]
was:
Global AST transformation in Spock throws exception with meaningful error
message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
executed with Groovy 2.4):
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception org.spockframework.util.IncompatibleGroovyVersionException:
The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is not
compatible
with Groovy 2.4.3. For more information, see
http://versioninfo.spockframework.org
Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
Groovy artifact: file:/.../groovy-2.4.3.jar
{code}
However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception java.lang.reflect.InvocationTargetException
{code}
It's not very constructive for people seeing that error message. Firstly, I
suspected some incompatibilities in the Spock code which completely fails with
new Groovy. However, it turned out that the exception is hidden by Groovy
itself.
I slightly modified ASTTransformationVisitor it detect that situation and get
target/cause in a case of InvocationTargetException - my
[PR|https://github.com/apache/groovy/pull/1193].
It helped, however, I haven't found any change in the ASTTransformationVisitor
which could cause that regression. It might to some 2.5→3.0 change how
constructor are called or anything else. You might want to investigate it - it
worked without my tweak in Groovy 2.5.
Related Spock issues: https://github.com/spockframework/spock/issues/1067
> Original exception during global AST transformation no longer preserved in
> error message
>
>
> Key: GROOVY-9469
> URL: https://issues.apache.org/jira/browse/GROOVY-9469
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0, 3.0.2
>Reporter: Marcin Zajaczkowski
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Global AST transformation in Spock throws exception with meaningful error
> message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
> executed with Groovy 2.4):
> {code:java}
> Could not instantiate global transform class
>
[jira] [Created] (GROOVY-9470) Automatic type casting with switch..case with instanceOf
Marcin Zajaczkowski created GROOVY-9470:
---
Summary: Automatic type casting with switch..case with instanceOf
Key: GROOVY-9470
URL: https://issues.apache.org/jira/browse/GROOVY-9470
Project: Groovy
Issue Type: Improvement
Components: Compiler
Affects Versions: 3.0.2
Reporter: Marcin Zajaczkowski
It could be useful to have automatic type casting (also with static
compilation) with switch..case with instanceof:
{code:java}
void sortItOut(Object o) {
switch(o) {
case String:
println "String: ${o.length()}" //currently only in dynamic Groovy
break
case Integer:
println "Integer: ${o.longValue()}" //currently only in dynamic Groovy
break
default:
throw new IllegalArgumentException(o.toString())
}
}
{code}
The same as currently for if with instanceof:
{code:java}
if (o instanceof String) {
useString(o)
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9470) Automatic type casting with switch..case with instanceof
[
https://issues.apache.org/jira/browse/GROOVY-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9470:
Summary: Automatic type casting with switch..case with instanceof (was:
Automatic type casting with switch..case with instanceOf)
> Automatic type casting with switch..case with instanceof
>
>
> Key: GROOVY-9470
> URL: https://issues.apache.org/jira/browse/GROOVY-9470
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 3.0.2
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> It could be useful to have automatic type casting (also with static
> compilation) with switch..case with instanceof:
> {code:java}
> void sortItOut(Object o) {
> switch(o) {
> case String:
> println "String: ${o.length()}" //currently only in dynamic Groovy
> break
> case Integer:
> println "Integer: ${o.longValue()}" //currently only in dynamic
> Groovy
> break
> default:
> throw new IllegalArgumentException(o.toString())
> }
> }
> {code}
> The same as currently for if with instanceof:
> {code:java}
> if (o instanceof String) {
> useString(o)
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9469) Original exception during global AST transformation no longer preserved in error message
[
https://issues.apache.org/jira/browse/GROOVY-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9469:
Priority: Minor (was: Major)
> Original exception during global AST transformation no longer preserved in
> error message
>
>
> Key: GROOVY-9469
> URL: https://issues.apache.org/jira/browse/GROOVY-9469
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0, 3.0.2
>Reporter: Marcin Zajaczkowski
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Global AST transformation in Spock throws exception with meaningful error
> message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
> executed with Groovy 2.4):
> {code:java}
> Could not instantiate global transform class
> org.spockframework.compiler.SpockTransform specified at
> jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
> because of exception
> org.spockframework.util.IncompatibleGroovyVersionException:
> The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is
> not compatible
> with Groovy 2.4.3. For more information, see
> http://versioninfo.spockframework.org
> Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
> Groovy artifact: file:/.../groovy-2.4.3.jar
> {code}
> However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
> {code:java}
> Could not instantiate global transform class
> org.spockframework.compiler.SpockTransform specified at
> jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
> because of exception java.lang.reflect.InvocationTargetException
> {code}
> It's not very constructive for people seeing that error message. Firstly, I
> suspected some incompatibilities in the Spock code which completely fails
> with new Groovy. However, it turned out that the exception is hidden by
> Groovy itself.
> I slightly modified ASTTransformationVisitor it detect that situation and get
> target/cause in a case of InvocationTargetException - my
> [PR|https://github.com/apache/groovy/pull/1193].
> It helped, however, I haven't found any change in the
> ASTTransformationVisitor which could cause that regression. It might to some
> 2.5→3.0 change how constructor are called or anything else. You might want to
> investigate it - it worked without my tweak in Groovy 2.5.
> Related Spock issues: https://github.com/spockframework/spock/issues/1067
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9469) Original exception during global AST transformation no longer preserved in error message
[
https://issues.apache.org/jira/browse/GROOVY-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9469:
Description:
Global AST transformation in Spock throws exception with meaningful error
message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
executed with Groovy 2.4):
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception org.spockframework.util.IncompatibleGroovyVersionException:
The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is not
compatible
with Groovy 2.4.3. For more information, see
http://versioninfo.spockframework.org
Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
Groovy artifact: file:/.../groovy-2.4.3.jar
{code}
However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception java.lang.reflect.InvocationTargetException
{code}
It's not very constructive for people seeing that error message. Firstly, I
suspected some incompatibilities in the Spock code which completely fails with
new Groovy. However, it turned out that the exception is hidden by Groovy
itself.
I slightly modified ASTTransformationVisitor it detect that situation and get
target/cause in a case of InvocationTargetException - my
[PR|https://github.com/apache/groovy/pull/1193].
It helped, however, I haven't found any change in the ASTTransformationVisitor
which could cause that regression. It might to some 2.5→3.0 change how
constructor are called or anything else. You might want to investigate it - it
worked without my tweak in Groovy 2.5.
Related Spock issues: https://github.com/spockframework/spock/issues/1067
was:
Global AST transformation in Spock throws exception with meaningful error
message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
executed with Groovy 2.4):
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception org.spockframework.util.IncompatibleGroovyVersionException:
The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is not
compatible
with Groovy 2.4.3. For more information, see
http://versioninfo.spockframework.org
Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
Groovy artifact: file:/.../groovy-2.4.3.jar
{code}
However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception java.lang.reflect.InvocationTargetException
{code}
It's not very constructive for people seeing that error message. Firstly, I
suspected some incompatibilities in the Spock code which completely fails with
new Groovy. However, it turned out that the exception is hidden by Groovy
itself.
I slightly modified ASTTransformationVisitor it detect that situation and get
target/cause in a case of InvocationTargetException - my
[PR|https://github.com/apache/groovy/pull/1193].
It helped, however, I haven't found any change in the ASTTransformationVisitor
which could cause that regression. It might to some 2.5→3.0 change how
constructor are called or anything else. You might want to investigate it - it
worked without my tweak in Groovy 2.5.
> Original exception during global AST transformation no longer preserved in
> error message
>
>
> Key: GROOVY-9469
> URL: https://issues.apache.org/jira/browse/GROOVY-9469
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0, 3.0.2
>Reporter: Marcin Zajaczkowski
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Global AST transformation in Spock throws exception with meaningful error
> message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
> executed with Groovy 2.4):
> {code:java}
> Could not instantiate global transform class
> org.spockframework.compiler.SpockTransform specified at
> jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
> because of exception
>
[jira] [Updated] (GROOVY-9469) Original exception during global AST transformation no longer preserved in error message
[
https://issues.apache.org/jira/browse/GROOVY-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9469:
Flags: Patch
> Original exception during global AST transformation no longer preserved in
> error message
>
>
> Key: GROOVY-9469
> URL: https://issues.apache.org/jira/browse/GROOVY-9469
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0, 3.0.2
>Reporter: Marcin Zajaczkowski
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Global AST transformation in Spock throws exception with meaningful error
> message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
> executed with Groovy 2.4):
> {code:java}
> Could not instantiate global transform class
> org.spockframework.compiler.SpockTransform specified at
> jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
> because of exception
> org.spockframework.util.IncompatibleGroovyVersionException:
> The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is
> not compatible
> with Groovy 2.4.3. For more information, see
> http://versioninfo.spockframework.org
> Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
> Groovy artifact: file:/.../groovy-2.4.3.jar
> {code}
> However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
> {code:java}
> Could not instantiate global transform class
> org.spockframework.compiler.SpockTransform specified at
> jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
> because of exception java.lang.reflect.InvocationTargetException
> {code}
> It's not very constructive for people seeing that error message. Firstly, I
> suspected some incompatibilities in the Spock code which completely fails
> with new Groovy. However, it turned out that the exception is hidden by
> Groovy itself.
> I slightly modified ASTTransformationVisitor it detect that situation and get
> target/cause in a case of InvocationTargetException - my
> [PR|https://github.com/apache/groovy/pull/1193].
> It helped, however, I haven't found any change in the
> ASTTransformationVisitor which could cause that regression. It might to some
> 2.5→3.0 change how constructor are called or anything else. You might want to
> investigate it - it worked without my tweak in Groovy 2.5.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9469) Original exception during global AST transformation no longer preserved in error message
[
https://issues.apache.org/jira/browse/GROOVY-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9469:
Description:
Global AST transformation in Spock throws exception with meaningful error
message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
executed with Groovy 2.4):
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception org.spockframework.util.IncompatibleGroovyVersionException:
The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is not
compatible
with Groovy 2.4.3. For more information, see
http://versioninfo.spockframework.org
Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
Groovy artifact: file:/.../groovy-2.4.3.jar
{code}
However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception java.lang.reflect.InvocationTargetException
{code}
It's not very constructive for people seeing that error message. Firstly, I
suspected some incompatibilities in the Spock code which completely fails with
new Groovy. However, it turned out that the exception is hidden by Groovy
itself.
I slightly modified ASTTransformationVisitor it detect that situation and get
target/cause in a case of InvocationTargetException - my
[PR|https://github.com/apache/groovy/pull/1193].
It helped, however, I haven't found any change in the ASTTransformationVisitor
which could cause that regression. It might to some 2.5→3.0 change how
constructor are called or anything else. You might want to investigate it - it
worked without my tweak in Groovy 2.5.
was:
Global AST transformation in Spock throws exception with meaningful error
message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
executed with Groovy 2.4):
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception org.spockframework.util.IncompatibleGroovyVersionException:
The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is not
compatible
with Groovy 2.4.3. For more information, see
http://versioninfo.spockframework.org
Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
Groovy artifact: file:/.../groovy-2.4.3.jar
{code}
However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception java.lang.reflect.InvocationTargetException
{code}
It's not very constructive for people seeing that error message. Firstly, I
suspected some incompatibilities in the Spock code which completely fails with
new Groovy. However, it turned out that the exception is hidden by Groovy
itself.
I slightly modified ASTTransformationVisitor it detect that situation and get
target/cause in a case of InvocationTargetException - my PR.
It helped, however, I haven't found any change in the ASTTransformationVisitor
which could cause that regression. It might to some 2.5→3.0 change how
constructor are called or anything else. You might want to investigate it - it
worked without my tweak in Groovy 2.5.
> Original exception during global AST transformation no longer preserved in
> error message
>
>
> Key: GROOVY-9469
> URL: https://issues.apache.org/jira/browse/GROOVY-9469
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.0, 3.0.2
>Reporter: Marcin Zajaczkowski
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Global AST transformation in Spock throws exception with meaningful error
> message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
> executed with Groovy 2.4):
> {code:java}
> Could not instantiate global transform class
> org.spockframework.compiler.SpockTransform specified at
> jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
> because of exception
> org.spockframework.util.IncompatibleGroovyVersionException:
> The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5
[jira] [Created] (GROOVY-9469) Original exception during global AST transformation no longer preserved in error message
Marcin Zajaczkowski created GROOVY-9469:
---
Summary: Original exception during global AST transformation no
longer preserved in error message
Key: GROOVY-9469
URL: https://issues.apache.org/jira/browse/GROOVY-9469
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 3.0.2, 3.0.0
Reporter: Marcin Zajaczkowski
Global AST transformation in Spock throws exception with meaningful error
message if used with incompatible Groovy version (e.g. Spock for Groovy 2.5
executed with Groovy 2.4):
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-1.3-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception org.spockframework.util.IncompatibleGroovyVersionException:
The Spock compiler plugin cannot execute because Spock 1.3.0-groovy-2.5 is not
compatible
with Groovy 2.4.3. For more information, see
http://versioninfo.spockframework.org
Spock artifact: file:/.../spock-core-1.3-groovy-2.5.jar
Groovy artifact: file:/.../groovy-2.4.3.jar
{code}
However, it stopped working with Spock 2.0 for Groovy 2.5 and Groovy 3.0:
{code:java}
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/.../spock-core-2.0-M1-groovy-2.5.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception java.lang.reflect.InvocationTargetException
{code}
It's not very constructive for people seeing that error message. Firstly, I
suspected some incompatibilities in the Spock code which completely fails with
new Groovy. However, it turned out that the exception is hidden by Groovy
itself.
I slightly modified ASTTransformationVisitor it detect that situation and get
target/cause in a case of InvocationTargetException - my PR.
It helped, however, I haven't found any change in the ASTTransformationVisitor
which could cause that regression. It might to some 2.5→3.0 change how
constructor are called or anything else. You might want to investigate it - it
worked without my tweak in Groovy 2.5.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9369) Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
[
https://issues.apache.org/jira/browse/GROOVY-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9369:
Description:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]
. Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
was:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
> Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
>
>
> Key: GROOVY-9369
> URL: https://issues.apache.org/jira/browse/GROOVY-9369
> Project: Groovy
> Issue Type: Task
> Components: groovy-runtime
>Affects Versions: 3.0.0-rc-2, 3.0.0-rc-3
>Reporter: Marcin Zajaczkowski
>Priority: Major
>
> TL;TR. It is problematic in Groovy 3 to distinguish go.x and
> go.getProperty("x") in a call (at the level of an interceptor for a mocking
> system)?
> A ticket to track problem raised using the [mailing
> list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]
> . Quoted original concerns:
> {quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
> started for a property access go.x (go - some GroovyObject instance with
> a field
[jira] [Updated] (GROOVY-9369) Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
[
https://issues.apache.org/jira/browse/GROOVY-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9369:
Description:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|[https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
was:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|[https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e].]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
> Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
>
>
> Key: GROOVY-9369
> URL: https://issues.apache.org/jira/browse/GROOVY-9369
> Project: Groovy
> Issue Type: Task
> Components: groovy-runtime
>Affects Versions: 3.0.0-rc-2, 3.0.0-rc-3
>Reporter: Marcin Zajaczkowski
>Priority: Major
>
> TL;TR. It is problematic in Groovy 3 to distinguish go.x and
> go.getProperty("x") in a call (at the level of an interceptor for a mocking
> system)?
> A ticket to track problem raised using the [mailing
> list|[https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]]
> Quoted original concerns:
>
> {quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
> started for a property access go.x (go - some GroovyObject instance with
[jira] [Updated] (GROOVY-9369) Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
[
https://issues.apache.org/jira/browse/GROOVY-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9369:
Description:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
was:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
> Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
>
>
> Key: GROOVY-9369
> URL: https://issues.apache.org/jira/browse/GROOVY-9369
> Project: Groovy
> Issue Type: Task
> Components: groovy-runtime
>Affects Versions: 3.0.0-rc-2, 3.0.0-rc-3
>Reporter: Marcin Zajaczkowski
>Priority: Major
>
> TL;TR. It is problematic in Groovy 3 to distinguish go.x and
> go.getProperty("x") in a call (at the level of an interceptor for a mocking
> system)?
> A ticket to track problem raised using the [mailing
> list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]
> Quoted original concerns:
> {quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
> started for a property access go.x (go - some GroovyObject instance with
> a field
[jira] [Updated] (GROOVY-9369) Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
[
https://issues.apache.org/jira/browse/GROOVY-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9369:
Description:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
was:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|[https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
> Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
>
>
> Key: GROOVY-9369
> URL: https://issues.apache.org/jira/browse/GROOVY-9369
> Project: Groovy
> Issue Type: Task
> Components: groovy-runtime
>Affects Versions: 3.0.0-rc-2, 3.0.0-rc-3
>Reporter: Marcin Zajaczkowski
>Priority: Major
>
> TL;TR. It is problematic in Groovy 3 to distinguish go.x and
> go.getProperty("x") in a call (at the level of an interceptor for a mocking
> system)?
> A ticket to track problem raised using the [mailing
> list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e]
> Quoted original concerns:
>
> {quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
> started for a property access go.x (go - some GroovyObject instance with
> a
[jira] [Updated] (GROOVY-9369) Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
[
https://issues.apache.org/jira/browse/GROOVY-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-9369:
Description:
TL;TR. It is problematic in Groovy 3 to distinguish go.x and
go.getProperty("x") in a call (at the level of an interceptor for a mocking
system)?
A ticket to track problem raised using the [mailing
list|[https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e].]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
{quote}
was:
TL;TR. It is problematic in Groovy 3 to go.x and go.getProperty("x") in a call
(at the level of an interceptor for a mocking system)?
A ticket to track problem raised using the [mailing
list|[https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e].]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]{quote}
> Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
>
>
> Key: GROOVY-9369
> URL: https://issues.apache.org/jira/browse/GROOVY-9369
> Project: Groovy
> Issue Type: Task
> Components: groovy-runtime
>Affects Versions: 3.0.0-rc-2, 3.0.0-rc-3
>Reporter: Marcin Zajaczkowski
>Priority: Major
>
> TL;TR. It is problematic in Groovy 3 to distinguish go.x and
> go.getProperty("x") in a call (at the level of an interceptor for a mocking
> system)?
> A ticket to track problem raised using the [mailing
> list|[https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e].]
> Quoted original concerns:
>
> {quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
> started for a property access go.x (go - some GroovyObject instance with
> a field "x") to call
[jira] [Created] (GROOVY-9369) Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
Marcin Zajaczkowski created GROOVY-9369:
---
Summary: Unable to distinguish foo.x and foo.getProperty("x") in
call interceptor
Key: GROOVY-9369
URL: https://issues.apache.org/jira/browse/GROOVY-9369
Project: Groovy
Issue Type: Task
Components: groovy-runtime
Affects Versions: 3.0.0-rc-3, 3.0.0-rc-2
Reporter: Marcin Zajaczkowski
TL;TR. It is problematic in Groovy 3 to go.x and go.getProperty("x") in a call
(at the level of an interceptor for a mocking system)?
A ticket to track problem raised using the [mailing
list|[https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%3c54d78589-67e2-7c92-6512-240782960...@wp.pl%3e].]
Quoted original concerns:
{quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
started for a property access go.x (go - some GroovyObject instance with
a field "x") to call go.getProperty("x") instead of go.getX() directly
(as it took place in Groovy 2). This broke tests for mocking with a
property call (getX() is stubbed, but go.x is called) and forced me to
detect getProperty("x") calls in a mock interceptor - to analyze deeper
and check which method (here getter) is being called and if has been
stubbed.
However, in addition, it should be possible to just stub direct
go.getProperty("x") calls [1]. To do that, currently, I have to analyze
a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper
process only the other calls (go.x). It seems to work, but it's quite
ugly and fragile. I wonder, how to reliably differentiate those two
types of calls?
[1] -[
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
[2] -[
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-7907) Cannot assign value of type java.lang.Object with varargs, parameterized method and @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469970#comment-15469970
]
Marcin Zajaczkowski commented on GROOVY-7907:
-
Thanks for a quick fix.
> Cannot assign value of type java.lang.Object with varargs, parameterized
> method and @CompileStatic
> --
>
> Key: GROOVY-7907
> URL: https://issues.apache.org/jira/browse/GROOVY-7907
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.7
> Environment: Groovy 2.4.7 (tested also with 2.4.4)
>Reporter: Marcin Zajaczkowski
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.4.8
>
>
> Static compilation fails when method is parameterized and there are varargs
> arguments which are not used in the call.
> {code}
> Error:(9, 23) Groovyc: [Static type checking] - Cannot assign value of type
> java.lang.Object to variable of type Ext.
> {code}
> Simple classes to reproduce the problem:
> {code}
> public class FooInJava { //needs to be in Java, a class in Groovy works fine
> T create(Class type, Object... args) { return null; }
> }
> class Ext {}
> @CompileStatic
> class FooMain {
> static void main(String[] args) {
> Ext create = new FooInJava().create(Ext) //casting is required to
> make compilation pass
> }
> }
> {code}
> It only occurs if a class with unfortunate method signature is written in
> Java and static compilation is enabled. Casting to the right type helps.
> Originally spotted with Gradle - `ExtensionContainer.create(...)`.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7907) Cannot assign value of type java.lang.Object with varargs, perameterized method and @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Zajaczkowski updated GROOVY-7907:
Description:
Static compilation fails when method is parameterized and there are varargs
arguments which are not used in the call.
{code}
Error:(9, 23) Groovyc: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type Ext.
{code}
Simple classes to reproduce the problem:
{code}
public class FooInJava { //needs to be in Java, a class in Groovy works fine
T create(Class type, Object... args) { return null; }
}
class Ext {}
@CompileStatic
class FooMain {
static void main(String[] args) {
Ext create = new FooInJava().create(Ext) //casting is required to make
compilation pass
}
}
{code}
It only occurs if a class with unfortunate method signature is written in Java
and static compilation is enabled. Casting to the right type helps. Originally
spotted with Gradle - `ExtensionContainer.create(...)`.
was:
Static compilation fails when method is parameterized and there are varargs
arguments which are not used in the call.
{code}
Error:(9, 23) Groovyc: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type Ext.
{code}
Simple classes to reproduce the problem:
{code}
public class FooInJava {
T create(Class type, Object... args) { return null; }
}
class Ext {}
@CompileStatic
class FooMain {
static void main(String[] args) {
Ext create = new FooInJava().create(Ext) //casting is required to make
compilation pass
}
}
{code}
It only occurs if a class with unfortunate method signature is written in Java
and static compilation is enabled. Casting to the right type helps. Originally
spotted with Gradle - `ExtensionContainer.create(...)`.
> Cannot assign value of type java.lang.Object with varargs, perameterized
> method and @CompileStatic
> --
>
> Key: GROOVY-7907
> URL: https://issues.apache.org/jira/browse/GROOVY-7907
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.7
> Environment: Groovy 2.4.7 (tested also with 2.4.4)
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> Static compilation fails when method is parameterized and there are varargs
> arguments which are not used in the call.
> {code}
> Error:(9, 23) Groovyc: [Static type checking] - Cannot assign value of type
> java.lang.Object to variable of type Ext.
> {code}
> Simple classes to reproduce the problem:
> {code}
> public class FooInJava { //needs to be in Java, a class in Groovy works fine
> T create(Class type, Object... args) { return null; }
> }
> class Ext {}
> @CompileStatic
> class FooMain {
> static void main(String[] args) {
> Ext create = new FooInJava().create(Ext) //casting is required to
> make compilation pass
> }
> }
> {code}
> It only occurs if a class with unfortunate method signature is written in
> Java and static compilation is enabled. Casting to the right type helps.
> Originally spotted with Gradle - `ExtensionContainer.create(...)`.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GROOVY-7907) Cannot assign value of type java.lang.Object with varargs, perameterized method and @CompileStatic
Marcin Zajaczkowski created GROOVY-7907:
---
Summary: Cannot assign value of type java.lang.Object with
varargs, perameterized method and @CompileStatic
Key: GROOVY-7907
URL: https://issues.apache.org/jira/browse/GROOVY-7907
Project: Groovy
Issue Type: Bug
Components: Static compilation
Affects Versions: 2.4.7
Environment: Groovy 2.4.7 (tested also with 2.4.4)
Reporter: Marcin Zajaczkowski
Priority: Minor
Static compilation fails when method is parameterized and there are varargs
arguments which are not used in the call.
{code}
Error:(9, 23) Groovyc: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type Ext.
{code}
Simple classes to reproduce the problem:
{code}
public class FooInJava {
T create(Class type, Object... args) { return null; }
}
class Ext {}
@CompileStatic
class FooMain {
static void main(String[] args) {
Ext create = new FooInJava().create(Ext) //casting is required to make
compilation pass
}
}
{code}
It only occurs if a class with unfortunate method signature is written in Java
and static compilation is enabled. Casting to the right type helps. Originally
spotted with Gradle - `ExtensionContainer.create(...)`.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
