[jira] [Commented] (GROOVY-9113) Unreachable code was not flagged by groovy compiler
[
https://issues.apache.org/jira/browse/GROOVY-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836336#comment-16836336
]
Jochen Theodorou commented on GROOVY-9113:
--
I see this more as feature request than as bug
> Unreachable code was not flagged by groovy compiler
> ---
>
> Key: GROOVY-9113
> URL: https://issues.apache.org/jira/browse/GROOVY-9113
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.8.0_91 Vendor: Oracle
> Corporation OS: Windows 10
>Reporter: Ashish
>Priority: Major
>
> The {{break}} statement after {{return'1'}} was not flagged as unreachable by
> groovy
> {code:java}
> switch(x) {
> case ['Front', 'Steer']:
> return '1'
> break
> case 'Drive':
> return '2'
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9114) Groovy chooses inline reified method over standard from Kotlin class
[
https://issues.apache.org/jira/browse/GROOVY-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836350#comment-16836350
]
Jochen Theodorou commented on GROOVY-9114:
--
To proceed we need to following information:
(1) the information Java Reflection gets about the methods
(2) the method signatures as they are written to the bytecode
To provide the information I think it would be best to provide a minimal kotlin
file containing a class with the methods, we can then compile to bytecode and
inspect the class in reflection and with bytecode tools.
> Groovy chooses inline reified method over standard from Kotlin class
> -
>
> Key: GROOVY-9114
> URL: https://issues.apache.org/jira/browse/GROOVY-9114
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.x
>Reporter: Ernestas
>Priority: Major
>
> Given kotlin class with two methods:
> {code:java}
> fun pathParam(key: String): String =
> ContextUtil.pathParamOrThrow(pathParamMap, key, matchedPath)
>
> /** Reified version of [pathParam] (Kotlin only) */
> inline fun pathParam(key: String) = pathParam(key,
> T::class.java)
> {code}
> and used from groovy as:
> {code:java}
> def id = pathParam("id){code}
> Groovy for some reason chooses inline reified version, which of course fails
> with:
> {noformat}
> java.lang.UnsupportedOperationException: This function has a reified type
> parameter and thus can only be inlined at compilation time, not called
> directly.{noformat}
> Is there anything that can be done so groovy uses the first (non reified,
> understandable by java and groovy) version of the method?
>
> This bug comes from [https://github.com/tipsy/javalin/issues/574]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9114) Groovy chooses inline reified method over standard from Kotlin class
[
https://issues.apache.org/jira/browse/GROOVY-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836662#comment-16836662
]
Jochen Theodorou commented on GROOVY-9114:
--
So the problem that we have "public final
pathParam(Ljava/lang/String;)Ljava/lang/String;" and "private final
pathParam(Ljava/lang/String;)Lcom/test/Example$Holder;". Which is legal for the
JVM, but of course it would be illegal for the Java language. I guess that
because the second method is private the Java compiler actually does not have a
problem.
Our static compiler has a problem, it shows this as ambigous method. That means
it recognizes this as two methods, but it should ignore the private one. So
clearly here I see a bug in our static compiler. We have to retry with a newer
Groovy version I tested with 2.4.7, which is pretty old at this point.
The Groovy runtime produces a meta class model of the class, which is then used
to chose the method. I am not sure if this is prepared for this kind of
constellation. There is a chance that the method selection becomes random
between the two. The problem is that in dynamic Groovy it is so far legal to
that private method. That the method call does not fail at runtime tells me the
other method was not even considered, which means it took the place of the
normal method. Which does not sound right to me, but is in the end no wonder,
the system is not prepared for constellations impossible to produce with Java
or Groovy.
Now the problem is that except for the method doubling I can produce a Holder
class in Java and create a
"pathParam(Ljava/lang/String;)Lcom/test/Example$Holder;" method. There is
nothing in that signature that would let us know we should ignore this method,
except the "private" modifier. So for me the solution is not to ignore the
reified method, because it is a reified method, but because it is private. We
are changing a lot in that area in Groovy 3, so I think that would fit.
Now... as I said, I am no Kotlin expert. Is there any chance Kotlin would
produce this reified method signature and have it not private? Because if that
is the case, we need to think further
> Groovy chooses inline reified method over standard from Kotlin class
> -
>
> Key: GROOVY-9114
> URL: https://issues.apache.org/jira/browse/GROOVY-9114
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.x
>Reporter: Ernestas
>Priority: Major
>
> Given kotlin class with two methods:
> {code:java}
> fun pathParam(key: String): String =
> ContextUtil.pathParamOrThrow(pathParamMap, key, matchedPath)
>
> /** Reified version of [pathParam] (Kotlin only) */
> inline fun pathParam(key: String) = pathParam(key,
> T::class.java)
> {code}
> and used from groovy as:
> {code:java}
> def id = pathParam("id){code}
> Groovy for some reason chooses inline reified version, which of course fails
> with:
> {noformat}
> java.lang.UnsupportedOperationException: This function has a reified type
> parameter and thus can only be inlined at compilation time, not called
> directly.{noformat}
> Is there anything that can be done so groovy uses the first (non reified,
> understandable by java and groovy) version of the method?
>
> This bug comes from [https://github.com/tipsy/javalin/issues/574]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9114) Groovy chooses inline reified method over standard from Kotlin class
[
https://issues.apache.org/jira/browse/GROOVY-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839860#comment-16839860
]
Jochen Theodorou commented on GROOVY-9114:
--
[~udalov] thanks for the pointer. ACC_SYNTHETIC hmm... I think we do ignore
those. For fixing the issue though I would need an information available at
runtime, that tells me I should ignore the method. What would that information
be? Right now I fail to see it.
> Groovy chooses inline reified method over standard from Kotlin class
> -
>
> Key: GROOVY-9114
> URL: https://issues.apache.org/jira/browse/GROOVY-9114
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.x
>Reporter: Ernestas
>Priority: Major
>
> Given kotlin class with two methods:
> {code:java}
> fun pathParam(key: String): String =
> ContextUtil.pathParamOrThrow(pathParamMap, key, matchedPath)
>
> /** Reified version of [pathParam] (Kotlin only) */
> inline fun pathParam(key: String) = pathParam(key,
> T::class.java)
> {code}
> and used from groovy as:
> {code:java}
> def id = pathParam("id){code}
> Groovy for some reason chooses inline reified version, which of course fails
> with:
> {noformat}
> java.lang.UnsupportedOperationException: This function has a reified type
> parameter and thus can only be inlined at compilation time, not called
> directly.{noformat}
> Is there anything that can be done so groovy uses the first (non reified,
> understandable by java and groovy) version of the method?
>
> This bug comes from [https://github.com/tipsy/javalin/issues/574]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9173) IllegalAccessError for class extending Java class that provides protected getProperty/setProperty
[
https://issues.apache.org/jira/browse/GROOVY-9173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863176#comment-16863176
]
Jochen Theodorou commented on GROOVY-9173:
--
Which means the behaviour it should have is (independent of it is dynamic or
static compiled):
(1) Reject compilation of the class Whatever, for its base class (compiled in
Java) has method not compliant with the GroovyObject interface
(2) Allow compilation of the class Whatever, by adding the public methods from
Groovy Object and delegate to the protected ones
I think we have to go with (1), because while (2) is perfectly possible on the
JVM, stub compilation for this will fail as Eric showed already. Do you agree
Eric?
> IllegalAccessError for class extending Java class that provides protected
> getProperty/setProperty
> -
>
> Key: GROOVY-9173
> URL: https://issues.apache.org/jira/browse/GROOVY-9173
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
>Reporter: Eric Milles
>Priority: Major
> Attachments: property-methods.zip
>
>
> Consider the following:
> PropertyBased.java
> {code:java}
> public class PropertyBased {
> protected final Object getProperty(String name) {
> return null;
> }
> protected final void setProperty(String name, Object value) {
> }
> }
> {code}
> Whatever.groovy
> {code:groovy}
> @groovy.transform.CompileStatic
> class Whatever extends PropertyBased {
> def getSomething() {
> 'some thing'
> }
> }
> {code}
> No compiler errors are produced for Whatever having protected
> "implementations" of GroovyObject methods. In this case, our legacy Java
> base class has {{getProperty}} for non-Groovy reasons. However, when
> accessing {{Whatever}} from dynamic Groovy code, {{IllegalAccessError}} is
> thrown. See the attached (run {{gradlew test}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9159) [GEP] Support LINQ, aka GINQ
[
https://issues.apache.org/jira/browse/GROOVY-9159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872221#comment-16872221
]
Jochen Theodorou commented on GROOVY-9159:
--
Can you give an example on how this looks like using a WITH-Clause? see
https://blog.jooq.org/tag/with-clause/ and https://modern-sql.com/feature/with
The big difference is that in your examples starting with FROM you always start
referencing the value or table you build the relation for. But in case of a
WITH-clause this is usually not the case. Here you are first building the
table you are getting the values from usually (but is not a must of course,
could be just used in a condition).
> [GEP] Support LINQ, aka GINQ
>
>
> Key: GROOVY-9159
> URL: https://issues.apache.org/jira/browse/GROOVY-9159
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Priority: Major
> Fix For: 4.x
>
>
> h2. *Ⅰ. Background*
> In order to make querying different types of data sources convenient, we need
> a unified querying interface, i.e. GINQ
> h2. *Ⅱ. Solution*
> The basic rationale can be shown as follows:
> *Groovy User* ==_writes GINQ code_==> *Parrot Parser* ==generates AST==>
> *GINQ Engine* ==_translates AST to Stream-Like method invocations_==>
> *Bytecode Writer*
> h3. {{translates AST to Stream-Like method invocations}} can be designed for
> different cases:
> h4. 1) target objects are all collections
> translates AST to Java 8+ stream method invocations
> h4. 2) target objects are all DB related objects
> translates AST to *JOOQ* method invocations( [https://github.com/jOOQ/jOOQ]
> ), which would be implemented as a {{GINQ provider}} in a seperate
> sub-project(e.g. {{groovy-linq-jooq}}). _Note: *JOOQ* is licensed under
> *APL2* too_( [https://github.com/jOOQ/jOOQ/blob/master/LICENSE] )
> h4. 3) target objects are XML, CSV, etc. related objects, or even mixed types
> of objects
> We can treate the case as a special sub-case of case 1
> h3. *Note:*
> {color:#d04437}1. The exact syntax might be altered before introduction,
> currently working on the general principle.{color}
> 2.GINQ will reuse most of standard SQL syntax, which can make the learning
> curve smooth and avoid infringing the patent of Microsoft.
> 3. All GINQ related keywords are uppercase to avoid breaking existing source
> code as possible as we can, e.g. {{FROM}}, {{WHERE}}, {{SELECT}}, etc.
> 4. In order to support type inference better, {{SELECT}} clause is placed at
> the end of GINQ expression.
> 5. {{alias.VALUE}} is a virtual property and is used to reference the whole
> record as value. It can be simplified as {{alias}}.
> 6. {{SELECT P1, P2 ... Pn}} will create a {{List}} of {{Tuple}} sub-class
> instances when and only when {{n >= 2}}
> h2. *Ⅲ. EBNF*
> h3. TBD
> h2. *Ⅳ. Examples*
> h3. 1. Filtering
> {code:java}
> @groovy.transform.EqualsAndHashCode
> class Person {
> String name
> int age
> }
> def persons = [new Person(name: 'Daniel', age: 35), new Person(name: 'Peter',
> age: 10), new Person(name: 'Alice', age: 22)]
> def result =
> FROM persons p
> WHERE p.age > 15 && p.age <= 35
> SELECT p.name
> assert ['Daniel', 'Alice'] == result
> result =
> FROM persons p
> WHERE p.age > 15 && p.age <= 35
> SELECT p
> assert [new Person(name: 'Daniel', age: 35), new Person(name: 'Alice', age:
> 22)] == result
> {code}
> {code:java}
> def numbers = [1, 2, 3]
> def result =
> FROM numbers t
> WHERE t <= 2
> SELECT t
> assert [1, 2] == result
> {code}
> h3. 2. Joining
> {code:java}
> import static groovy.lang.Tuple.*
> @groovy.transform.EqualsAndHashCode
> class Person {
> String name
> int age
> City city
> }
> @groovy.transform.EqualsAndHashCode
> class City {
> String name
> }
> def persons = [new Person(name: 'Daniel', age: 35, city: new
> City('Shanghai')), new Person(name: 'Peter', age: 10, city: new
> City('Beijing')), new Person(name: 'Alice', age: 22, city: new
> City('Hangzhou'))]
> def cities = [new City('Shanghai'), new City('Beijing'), new
> City('Guangzhou')]
> // inner join
> def result =
> FROM persons p INNER JOIN cities c
> ON p.city.name == c.name
> SELECT p.name
> assert ['Daniel', 'Peter'] == result
> result =
> FROM persons p, cities c
> WHERE p.city.name == c.name
> SELECT p.name
> assert ['Daniel', 'Peter'] == result
> result =
> FROM persons p, cities c
> WHERE p.city == c
> SELECT p.name
> assert ['Daniel', 'Peter'] == result
> // left outer join
> result =
> FROM persons p LEFT JOIN cities c // same to LEFT OUTER JOIN
> ON p.city.name == c.name
> SELECT p.name, c.name
> assert [tuple('Daniel', 'Shanghai'), tuple('Peter', 'Beijing'),
> tu
[jira] [Commented] (GROOVY-9209) Compiler throws an exception in ClassNode#getTypeClass after checking ClassNode#isResolved
[
https://issues.apache.org/jira/browse/GROOVY-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895700#comment-16895700
]
Jochen Theodorou commented on GROOVY-9209:
--
frankly I think getTypeClass should be removed from ClassNode. This method is
really only for classes, that can be realized as a class in the JVM. This is
obviously not the case here. Maybe it would be more correct for
DecompiledClassNode to not to return true for isResolved. But I am not sure
about the implications.
> Compiler throws an exception in ClassNode#getTypeClass after checking
> ClassNode#isResolved
> --
>
> Key: GROOVY-9209
> URL: https://issues.apache.org/jira/browse/GROOVY-9209
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.6
> Environment: intellij idea
>Reporter: Daniil Ovchinnikov
>Priority: Critical
>
> {noformat}
> Error:Groovyc: While compiling mn-gorm-example.main: BUG! exception in phase
> 'canonicalization' in source unit
> '/Users/pditommaso/Projects/mn-gorm-example/src/main/groovy/example/gorm/Bootstrap.groovy'
> JVM class can't be loaded for example.gorm.service.PersonService
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:86)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:175)
> at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1381)
> at
> io.micronaut.ast.groovy.InjectTransform$InjectVisitor.resolveParameterType(InjectTransform.groovy:1117)
> ...
> {noformat}
> {code:java|title=InjectVisitor#resolveParameterType}
> ClassNode parameterType = parameter.type
> if (parameterType.isResolved()) {
> parameterType.typeClass // here
> } else {
> parameterType.name
> }
> {code}
> Code: [https://github.com/pditommaso/mn-gorm-example]
> Steps to reproduce:
> 1. make sure the build is not delegated to Gradle in Preferences | Build,
> Execution, Deployment | Build Tools | Gradle
> 2. rebuild project
> 3. make changes in Person.groovy and Bootstrap.groovy (to mark them as
> subject for recompilation)
> 4. build project
> What happens with {{-Dgroovyc.asm.resolving.only=false}}:
> 1. Bootstrap.groovy and Person.groovy are added to
> {{CompilationUnit#queuedSources}}
> 2. {{ResolveVisitor}} visits Bootstrap.groovy and tries to load PersonService
> 3. {{asmResolving}} flag is set to {{false}} by IntelliJ, this results in
> skipping {{findDecompiled}} call inside
> {{ClassNodeResolver#tryAsLoaderClassOrScript}}
> 4. the PersonService class fails to load because of missing Person class
> 5. {{tryAsScript}} kicks in and adds PersonService to
> {{CompilationUnit#queuedSources}}
> 6. when it comes to Micronaut {{ClassNode#isResolved}} returns {{false}} for
> PersonService
> What happens without {{-Dgroovyc.asm.resolving.only=false}}:
> 1. same
> 2. same
> 3. {{asmResolving}} is not set by IntellliJ
> 4. {{findDecompiled}} returns {{DecompiledClassNode}} for PersonService
> 5. when it comes to Micronaut {{ClassNode#isResolved}} returns {{true}} for
> PersonService, and this results in an exception because the class cannot be
> loaded actually.
> I've tried to fix it in the compiler but I'm not sure what's the proper fix
> would be.
> Please let me know if I can do something within IntelliJ.
> The issue in JB YouTrack for the reference:
> [https://youtrack.jetbrains.com/issue/IDEA-218698]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899676#comment-16899676
]
Jochen Theodorou commented on GROOVY-9211:
--
strongly forbidding access to this constructor is on the list for the guys for
a longer time already. If not some others and myself have used the list to make
them aware that this is a problem.
For the module system we have a weak story here... But this is for JDK8.
Arguably this can be considered a bug somewhat. Yes, it is internal API. But we
are not the only ones using that.
As for the key hack for Groovy to access non-private members in non-Groovy
classes. In Groovy classes we produce a accessible helper method. Thus it is
limited to Java classes (or should be). Since we cannot simply produce helper
methods for these cases we do have the problem, that we have to either follow
Java rules here, or generate helper by instrumentation. The usage the hack
should be removed for newer JDK... or isn't it already?
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906007#comment-16906007
]
Jochen Theodorou commented on GROOVY-9211:
--
The whole trouble is history in this issue. Groovy used to allow access to
class members with non-public modifier for any class controlled by the security
manager and one through reflection. Since Java9 we struggle with this, because
the Java world changed in an incompatible way. And now we have a promise we can
no longer keep. It is a shame that for testing we can no longer use this. I did
often use it myself... There are ways to make that work with instrumentation...
and while I was always against that in general, after working so many times
with mocking frameworks and the likes in EE code, I think that, in a corporate
world at least, there is no way around such things in the end.
My suggestion Daniel would be to remove the Java7 plugin completely in Groovy
3, since that is supposed to be based on Java8 and move the Java9 code for this
to 8. Basically what Mandy said. If we want to keep the logic (for 2.5), than
this private lookup logic has to be migrated to reflection I guess.
[~mandy.ch...@oracle.com] The problem with privateLookupIn is that it does not
provide the semantics we need. Java9 and further has no ways of restoring the
old semantics, because of the module system. We have been hoping, that Java7
and Java8 would not change here, so we can make a clean cut for Java9+. It
seems that is not going to happen and producing a lot of mess.
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906353#comment-16906353
]
Jochen Theodorou edited comment on GROOVY-9211 at 8/13/19 4:07 PM:
---
[~daniel_sun] yes, l think it covers most cases. For as long as Groovy is not
running as named module it should work. So I guess it is no issue for Java8,
where there is no module system at all. But why does the code actually fail?
See my question to Alan.
[~russgold] java.unsupported... I know jdk.unsupported, java.unsupported is
something you chose I assume. If not, do you have some documentation on that?
Thanks for the code.
[~AlanBateman] Actually after looking into the gradle side of the report it is
not that we don't want to use it. The Class initialization does not work as
expected. I mean why is a NoClassDefFoundError thrown at all? Sure, I can
understand, that if during the classloading of Java9, Java8 is loaded, which
loads Java7 and then Java7.LookupHolder fails to init causing the exception (at
least I vaguely remember that failing init of a dependent class causes this
exception - which I find wrong btw). The question though is, why is that inner
class initialized? The code in
https://github.com/apache/groovy/blob/62ab65a7fcc4a63e9d8fdf920fe20b81afaf7138/src/main/java/org/codehaus/groovy/vmplugin/VMPluginFactory.java#L56
should not have caused that, should it?
was (Author: blackdrag):
[~daniel_sun] yes, lets try it. I think it covers most cases. For as long as
Groovy is not running as named module it should work. So I guess it is no issue
for Java8, where there is no module system at all. But why does the code
actually fail? See my question to Alan.
[~russgold] java.unsupported... I know jdk.unsupported, java.unsupported is
something you chose I assume. If not, do you have some documentation on that?
Thanks for the code.
[~AlanBateman] Actually after looking into the gradle side of the report it is
not that we don't want to use it. The Class initialization does not work as
expected. I mean why is a NoClassDefFoundError thrown at all? Sure, I can
understand, that if during the classloading of Java9, Java8 is loaded, which
loads Java7 and then Java7.LookupHolder fails to init causing the exception (at
least I vaguely remember that failing init of a dependent class causes this
exception - which I find wrong btw). The question though is, why is that inner
class initialized? The code in
https://github.com/apache/groovy/blob/62ab65a7fcc4a63e9d8fdf920fe20b81afaf7138/src/main/java/org/codehaus/groovy/vmplugin/VMPluginFactory.java#L56
should not have caused that, should it?
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906353#comment-16906353
]
Jochen Theodorou commented on GROOVY-9211:
--
[~daniel_sun] yes, lets try it. I think it covers most cases. For as long as
Groovy is not running as named module it should work. So I guess it is no issue
for Java8, where there is no module system at all. But why does the code
actually fail? See my question to Alan.
[~russgold] java.unsupported... I know jdk.unsupported, java.unsupported is
something you chose I assume. If not, do you have some documentation on that?
Thanks for the code.
[~AlanBateman] Actually after looking into the gradle side of the report it is
not that we don't want to use it. The Class initialization does not work as
expected. I mean why is a NoClassDefFoundError thrown at all? Sure, I can
understand, that if during the classloading of Java9, Java8 is loaded, which
loads Java7 and then Java7.LookupHolder fails to init causing the exception (at
least I vaguely remember that failing init of a dependent class causes this
exception - which I find wrong btw). The question though is, why is that inner
class initialized? The code in
https://github.com/apache/groovy/blob/62ab65a7fcc4a63e9d8fdf920fe20b81afaf7138/src/main/java/org/codehaus/groovy/vmplugin/VMPluginFactory.java#L56
should not have caused that, should it?
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906716#comment-16906716
]
Jochen Theodorou commented on GROOVY-9211:
--
[~mandy.ch...@oracle.com] thanks a lot, I forgot that this was added only to
Groovy3. Since I am not so much involved with the project anymore things like
that happen, sorry. Which means [~daniel_sun] [~paulk] should we backport the
changes for GROOVY-8843?
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907430#comment-16907430
]
Jochen Theodorou commented on GROOVY-9211:
--
[~paulk] Groovy 3 should not have the problem
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GROOVY-9230) Parentheses: omit or not?
[ https://issues.apache.org/jira/browse/GROOVY-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911242#comment-16911242 ] Jochen Theodorou commented on GROOVY-9230: -- Paul really said most, just a few more points: * GO is an example of a language that gives a complete style and tool to reformat your code accordingly. This was done to end all the formatting discussions. * DSLs category A (I just invented that term) are for me not so much for native programmers. They are for experts and they do not want to learn a new programming language. What they want is to write their DSL based logic with as minimal change as possible. An internal DSL is of course more limited than an external one, but even in an external DSL not everything can be done, what experts thought of. An internal DSL is thus a compromise between what the language offers and what syntax the experts desire. Here enforced rules for optional elements and formatting are in the way. * DSLs category B are for native programmers. There are no real experts to speak of, the DSL thus is only there to increase readability of code. These Mini-DSLs are quite common. Here formatting rules and enforcing what is optional and what not does not really hurt most of the time and may increase readability. These DSLs are often mini DSLs and we have a few of them. Here ideomatic Groovy is something that can work. * DSLs category C are not for experts, nor native programmers. The style of the DSL is often mostly descriptive. These are the most painful ones, because the people have problems understanding ideomatic Groovy (because they come for example from Java) for the parts, that are actually not descriptive. At the same time you have experts to be, that then block the further development of the DSL into something more comprehensible. In other words, this type of DSL tries to fit them all and usually falls short of doing so. But in the end every programming language has elements you don't like, this is a perfectly normal state people arrange themselves with over time. Does ideomatic Groovy fit here? I am not sure. But since you define a DSL without really having a previous syntax to follow, then in my opinion the ideomatic way may require more learning but should lead to a better style overall. The problem is a tool usually cannot tell easily if a DSL is category A, B or C. We would have to add something to exclude formatting here (or allow a formatting plugin kind of). But coming back to "I would like to know what you recommend: should we omit parentheses or not? " I would put Gradle in Category C. In my opinion the DSL really needs an overhaul, with more descriptive elements. But Gradle came far and changed semantics a lot (in terms of the DSL) and it has all the problems an DSL category C usually has (including people blocking evolution). But in the end I would say you can omit them ;) > Parentheses: omit or not? > - > > Key: GROOVY-9230 > URL: https://issues.apache.org/jira/browse/GROOVY-9230 > Project: Groovy > Issue Type: Documentation > Components: syntax >Reporter: rkrisztian >Priority: Major > > The Groovy Style Guide mentions that parentheses can be omitted (not always, > I know). And that's it. I think the primary purpose of a style guide is to > define a good set of recommendations for coding practices, rather than list > all the available options. (Because that's like good old Perl: you can write > the same thing in so many ways, since the syntax is so lenient, which then > practically doomed the language.) So the style guide that is supposed to give > us answers, is still leaving us with questions right now. > I would like to know what you recommend: should we omit parentheses or not? I > am really puzzled, because: > * IntelliJ IDEA can suggest auto-removal of unnecessary parentheses. > * I think Gradle started with not using parentheses but now it mixes up > styles: [https://github.com/gradle/gradle/issues/10307] > * The Internet kinda started making up their own style guides, and it is not > the first time I see that they actually recommend the parentheses for > readability: > [https://books.google.hu/books?id=7Hc5DwAAQBAJ&lpg=PA347&ots=I5irALxRRu&dq=groovy%20code%20style%20parentheses&hl=hu&pg=PA347#v=onepage&q=groovy%20code%20style%20parentheses&f=false] > * Whereas, for DSLs, the target audience may not know programming so well, > so the parentheses are not recommended: > [https://books.google.hu/books?id=RNtOCwAAQBAJ&lpg=PA16&ots=xEOKCWi0xo&dq=groovy%20code%20style%20parentheses&hl=hu&pg=PA16#v=onepage&q=groovy%20code%20style%20parentheses&f=false] > But this still puzzles me. > * Are missing parentheses really that hard to read? If someone with no > programming skills can read statements w
[jira] [Commented] (GROOVY-9230) Parentheses: omit or not?
[
https://issues.apache.org/jira/browse/GROOVY-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911649#comment-16911649
]
Jochen Theodorou commented on GROOVY-9230:
--
inconsistent style in the same project is a problem, since it increases
readability, yes. Having a differing style from the general in an open source
project is also a problem for the same reason. so it really is for us to define
what idiomatic Groovy is. I like having the freedom not have to follow those
rules as well. using the parenthesis all the time is not idomatic, I think we
agree on that. I personally, and I think that can be read between the lines,
would prefer having a Go style tool to just reformat all the code and be done
with it. But it does not exist atm and might be a bit more work than just a
CodeNarc rule. Why kotlin does a better job is something you should explain, I
do not know Kotlin well enough to really know about this. As for static
compilation... well, surly the @CompileStatic (part of the Groovy distribution)
will not produce code as good as Kotlin (because sometimes it falls back to
dynamic code and there are still a lot of bugs involving generics), but I think
it is decent and it turns Groovy into a static language. Having the IDE assist
us is nice, but also has to be implemented. I am pretty sure the guys at
Netbeans, Idea and Greclipse are happy to have help here. When I read this it
kind of sounds sarcastic, but I am 100% serious... there are so many things we
could do with more manpower. My "official" guide would be:
* {{logger.info 'hello'}} over {{logger.info('hello')}}
* {noformat}compile ("org.apache.ivy:ivy:$ivyVersion") {
transitive = false
}{noformat}
over {noformat}compile "org.apache.ivy:ivy:$ivyVersion", { transitive =
false} {noformat}
or {noformat}compile ("org.apache.ivy:ivy:$ivyVersion", { transitive = false})
{noformat}
or {noformat}compile "org.apache.ivy:ivy:$ivyVersion", {
transitive = false
} {noformat}. Btw {noformat}compile "org.apache.ivy:ivy:$ivyVersion" {
transitive = false}{noformat} is actually equal to
{noformat}compile("org.apache.ivy:ivy:$ivyVersion"({ transitive =
false})){noformat}.. it would not be an transformation with equal meaning. Yes,
you can use a GString for a method name in Groovy.
* {{logger.info()}} needs to have the parens, because {{logger.info}} is
actually a property expression and not a method call
> Parentheses: omit or not?
> -
>
> Key: GROOVY-9230
> URL: https://issues.apache.org/jira/browse/GROOVY-9230
> Project: Groovy
> Issue Type: Documentation
> Components: syntax
>Reporter: rkrisztian
>Priority: Major
>
> The Groovy Style Guide mentions that parentheses can be omitted (not always,
> I know). And that's it. I think the primary purpose of a style guide is to
> define a good set of recommendations for coding practices, rather than list
> all the available options. (Because that's like good old Perl: you can write
> the same thing in so many ways, since the syntax is so lenient, which then
> practically doomed the language.) So the style guide that is supposed to give
> us answers, is still leaving us with questions right now.
> I would like to know what you recommend: should we omit parentheses or not? I
> am really puzzled, because:
> * IntelliJ IDEA can suggest auto-removal of unnecessary parentheses.
> * I think Gradle started with not using parentheses but now it mixes up
> styles: [https://github.com/gradle/gradle/issues/10307]
> * The Internet kinda started making up their own style guides, and it is not
> the first time I see that they actually recommend the parentheses for
> readability:
> [https://books.google.hu/books?id=7Hc5DwAAQBAJ&lpg=PA347&ots=I5irALxRRu&dq=groovy%20code%20style%20parentheses&hl=hu&pg=PA347#v=onepage&q=groovy%20code%20style%20parentheses&f=false]
> * Whereas, for DSLs, the target audience may not know programming so well,
> so the parentheses are not recommended:
> [https://books.google.hu/books?id=RNtOCwAAQBAJ&lpg=PA16&ots=xEOKCWi0xo&dq=groovy%20code%20style%20parentheses&hl=hu&pg=PA16#v=onepage&q=groovy%20code%20style%20parentheses&f=false]
> But this still puzzles me.
> * Are missing parentheses really that hard to read? If someone with no
> programming skills can read statements without them better, than how come the
> opposite is true for an advanced programmer?
> * Should the no-parentheses style be suggested only for DSLs? That would
> include Gradle too, right?
> Thanks in advance.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (GROOVY-9278) Java compatibility: consider supporting local class definitions
[
https://issues.apache.org/jira/browse/GROOVY-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952087#comment-16952087
]
Jochen Theodorou commented on GROOVY-9278:
--
The rough definition is that they are exactly like normal inner classes and are
also compile like those in the class scope. The main difference (besides maybe
modifiers) is that the name visibility is limited to the method.
> Java compatibility: consider supporting local class definitions
> ---
>
> Key: GROOVY-9278
> URL: https://issues.apache.org/jira/browse/GROOVY-9278
> Project: Groovy
> Issue Type: New Feature
>Reporter: Eric Milles
>Priority: Minor
>
> Consider the following Java code:
> {code:java}
> class Main {
> public static void main(String[] args) {
> class Local implements Runnable { // allows modifiers "final" and
> "abstract" only!
> @Override public void run() {
> System.out.println("works");
> }
> }
> new Main().meth(new Local());
> }
> void meth(Runnable runnable) {
> runnable.run();
> }
> }
> {code}
> I was not aware this was supported until encountering it in another codebase.
> Typically I would use an anonymous inner class in similar situations. For
> increased cross-compatibility, Groovy could implement support for locally
> defined classes. There is probably some Java spec that defines their
> characteristics.
> At the moment groovyc emits "Class definition not expected here. Please
> define the class at an appropriate place or perhaps try using a block/Closure
> instead." for this code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9352) Static compilation fails with NoClassDefFoundError
[ https://issues.apache.org/jira/browse/GROOVY-9352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001811#comment-17001811 ] Jochen Theodorou commented on GROOVY-9352: -- "As Groovy allows private members be accessed, we still need these nodes representing the private members," is right for the dynamic runtime, but if we reference a pre-compiled class X in the compiler, we really do not need that information. The fix here would not work otherwise actually. If ClassNode is used as a replacement for reflection things are different. And that does happen. > Static compilation fails with NoClassDefFoundError > -- > > Key: GROOVY-9352 > URL: https://issues.apache.org/jira/browse/GROOVY-9352 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.5.8, 3.0.0-rc-2 >Reporter: Cédric Champeau >Assignee: Daniel Sun >Priority: Major > Fix For: 2.5.9, 3.0.0-rc-3 > > Time Spent: 40m > Remaining Estimate: 0h > > The static compiler is trying to resolve classes which it shouldn't. Imagine > the following scenario: > > * a project written in Java exposes class `A` which has a private method > using `D` as a parameter > * `D` is an _implementation_ dependency of `A`, meaning it's not exposed in > its public API, so consumers of `A` should never require `D` to build against > `A` > * a project `B` written in Groovy consumes `A` and tries to call a _public_ > method of `A` > ** if the class is using `@CompileStatic`, compilation FAILS with a > NoClassDefFoundError > ** if the class doesn't use `@CompileStatic`, compilation passes as expected > The reason is that when we compile `B`, we only put on the compile classpath > the _API_ dependencies of `A`. But Groovy breaks because when it inspects > class `A`, it tries to load internal implementation details (private fields, > methods) and as such fails. > This is a big problem because it effectively breaks the contract of > API/implementation separation, and forces either the producer to declare `D` > as an _implementation_ dependency, which it's not, or redeclare `D` as an > implementation dependency of `B`, which it isn't either, just to make the > compiler happy! > > The Gradle build itself is suffering from this. This is not nice because it > forces compilation of things we don't need, and forces us to redeclare > dependencies that we shouldn't. > > To reproduce, checkout this project: > [https://github.com/melix/groovy-compiler-bug] > > and run `./gradlew build` > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9373) ASM: rework line numbers for blocks with fast-path, try/catch or return statement insertion
[
https://issues.apache.org/jira/browse/GROOVY-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021493#comment-17021493
]
Jochen Theodorou commented on GROOVY-9373:
--
I think you are aware of it, but there is one factor playing especially bad
into this and that is the logic for primitive optimizations. Code like this
{code:Java}
def fib(int n) {
if (n<1) return 1 // line 2
return fib(n-1) + fib(n-2) // line 3
}
{code}
Is compiled roughly like this:
{code:Java}
def fib(int n){
if (primtiveOptsDisabled) {
if (PrimtiveTypeConversions.lessThan(n,1)) return 1 // line 2
return getCallSite(0).call(getCallSite(1).call(getCallSite(2).call(n,1)),
getCallSite(3).call(getCallSite(4).call(n,1))) // line 3
} else {
if (n<1) return 1 //line 2
return fib(n-1) + fib(n-2) // line 3
}
{code}
which then results in the duplicated path problem you mentioned. This is also a
possible problem for code coverage tools. If the code is compile static, with
indy or with primitive opts turned off, this would not happen. Given the
improvements in the callsite caching for indy my suggestion would be to remove
primitive opts and the old callsite caching code and do everything static or
with indy for Groovy 4.
Another problem is that the logic of the debugger in java has to be basically
reverse engineered. At least no JVM engineer has been brave enough to explain
me the workings of the tool so far.
> ASM: rework line numbers for blocks with fast-path, try/catch or return
> statement insertion
> ---
>
> Key: GROOVY-9373
> URL: https://issues.apache.org/jira/browse/GROOVY-9373
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.18, 2.5.9, 3.0.0-rc-3
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
>
> GROOVY-4063, GROOVY-4505, GROOVY-7647, GROOVY-8742, GROOVY-9076, GROOVY-9126
> and GROOVY-9199 present (possibly) conflicting concerns. Code coverage
> metrics are thrown off when line number information exists outside of the
> reachable paths in the bytecode. Debug break and step exhibit strange
> behaviors when the bytecode contains insufficient or duplicated line number
> information.
> Can the ASM changes in StatementWriter be reworked to address these concerns?
> See also https://github.com/jacoco/jacoco/issues/884
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9373) ASM: rework line numbers for blocks with fast-path, try/catch or return statement insertion
[ https://issues.apache.org/jira/browse/GROOVY-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022759#comment-17022759 ] Jochen Theodorou commented on GROOVY-9373: -- interesting find... +1 > ASM: rework line numbers for blocks with fast-path, try/catch or return > statement insertion > --- > > Key: GROOVY-9373 > URL: https://issues.apache.org/jira/browse/GROOVY-9373 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.18, 2.5.9, 3.0.0-rc-3 >Reporter: Eric Milles >Assignee: Eric Milles >Priority: Major > > GROOVY-4063, GROOVY-4505, GROOVY-7647, GROOVY-8742, GROOVY-9076, GROOVY-9126 > and GROOVY-9199 present (possibly) conflicting concerns. Code coverage > metrics are thrown off when line number information exists outside of the > reachable paths in the bytecode. Debug break and step exhibit strange > behaviors when the bytecode contains insufficient or duplicated line number > information. > Can the ASM changes in StatementWriter be reworked to address these concerns? > See also https://github.com/jacoco/jacoco/issues/884 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9379) Binding shadows getters in script or base script
[
https://issues.apache.org/jira/browse/GROOVY-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026042#comment-17026042
]
Jochen Theodorou commented on GROOVY-9379:
--
I agree with what you wrote, the only problem is that this is not really a bug.
It is per design, but from a time prior to Groovy 1, when Groovy had for
example no real property-missing mechanism and basically no idea support.
Changing this now would be a major breaking change. But using a script base
class can actually bypass this, if the base class overwrite get/setProperty..
or the script for that matter.
> Binding shadows getters in script or base script
>
>
> Key: GROOVY-9379
> URL: https://issues.apache.org/jira/browse/GROOVY-9379
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 3.0.0-rc-2
> Environment: CentOS 8, OpenJDK 11
>Reporter: Jochen Eddelbuettel
>Priority: Major
>
>
> {code:java}
> boolean isPasswordOK() { false }
> binding.setVariable("passwordOK", true)
> if (passwordOK) print "You're in"
> {code}
> Accessing a variable available in the binding takes precedent over utilizing
> a getter. This is extremely risky if the script author doesn't have full
> control over the binding and forgets to call all his getters explicitly,
> especially when they come from a BaseScript and he/she uses the code
> suggestions from IntelliJ, which show any getters as simple property names.
> The expected behaviour of the code above, should be NOT to let anyone in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9381) Support async/await like ES7
[ https://issues.apache.org/jira/browse/GROOVY-9381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026851#comment-17026851 ] Jochen Theodorou commented on GROOVY-9381: -- that one is on my list for Groovy for a while already actually ;) HOw much do you want to involve gpars here? > Support async/await like ES7 > > > Key: GROOVY-9381 > URL: https://issues.apache.org/jira/browse/GROOVY-9381 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17032220#comment-17032220
]
Jochen Theodorou commented on GROOVY-9369:
--
[~paulk] this sounds like the MOP broke. If yes, then this is a major break
and, if not intended, should delay 3.0. But I am actually surprised that our
tests did not catch this. Or maybe it is not as dramatic as it sounds from this
issue... Afaik the old logic is, if getProperty is overwritten, we call
getProperty, otherwise we call the getter directly...
> 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 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-9409) org.codehaus.groovy.runtime.callsite.GroovySunClassLoader is unusable
[
https://issues.apache.org/jira/browse/GROOVY-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041038#comment-17041038
]
Jochen Theodorou commented on GROOVY-9409:
--
FYI: The reason this code exists is to provide a classloader we can use when
generating callsite helper classes at runtime, that bypass bytecode
verification. Not because the bytecode we produce may be wrong and we want to
still pass it, it is to safe the time the verifier takes to speed up the
one-time costs when invoking a method in the old callsite caching. I am
wondering if this can still work in a java9+ scenario. As the [~widemann] got a
ClassFormatError it is not yet fully clear if this is because of verification,
or if here is a general upfront check you cannot bypass. Also the environment
is still Java8, for which I expect this to still work. But in the end we may
have to do changes here in the near future
> org.codehaus.groovy.runtime.callsite.GroovySunClassLoader is unusable
> -
>
> Key: GROOVY-9409
> URL: https://issues.apache.org/jira/browse/GROOVY-9409
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 3.0.0
> Environment: OpenJDK 8u222
>Reporter: Baltasar Trancon Widemann
>Priority: Major
> Attachments: Example.java
>
>
> The singleton class loader supposedly defined by
> {{org.codehaus.groovy.runtime.callsite.GroovySunClassLoader}} cannot be used.
> The creation of the instance fails with a {{ClassFormatError}}. The attached
> Java code demonstrates the issue:
> {noformat}
> $ javac -classpath
> $HOME/.m2/repository/org/codehaus/groovy/groovy/3.0.0/groovy-3.0.0.jar
> Example.java
> $ java -classpath
> .:$HOME/.m2/repository/org/codehaus/groovy/groovy/3.0.0/groovy-3.0.0.jar
> Example
> GroovySunClassLoader.sunVM = null
> Creating a new GroovySunClassLoader ...
> Exception in thread "main" java.lang.ClassFormatError: Absent Code attribute
> in method that is not native or abstract in class file
> org/codehaus/groovy/runtime/callsite/AbstractCallSite
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
> at
> org.codehaus.groovy.reflection.SunClassLoader.define(SunClassLoader.java:95)
> at
> org.codehaus.groovy.runtime.callsite.GroovySunClassLoader.loadAbstract(GroovySunClassLoader.java:69)
> at
> org.codehaus.groovy.runtime.callsite.GroovySunClassLoader.(GroovySunClassLoader.java:51)
> at Example$1.(Example.java:7)
> at Example.main(Example.java:7)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9415) failure in static compilation with getAt
Jochen Theodorou created GROOVY-9415:
Summary: failure in static compilation with getAt
Key: GROOVY-9415
URL: https://issues.apache.org/jira/browse/GROOVY-9415
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Reporter: Jochen Theodorou
{code:Java}
class l {
static T getAt(T x) {return x}
}
@groovy.transform.CompileStatic
def m() {
List x = l[1,2,3]
return x
}
m()
{code}
this code fails to compile {pre}
[Static type checking] - Cannot find matching method
java.lang.Class#getAt(java.util.List). Please check if the declared type is
correct and if the method exists.
@ line 7, column 22.
List x = l[1,2,3]
^
1 error
{pre}
The error message makes me think that l is seen as an instance of Class instead
of the class l. Changing the class name l does not make a difference for me. I
tested with groovy 3.0.1 and 2.4.7, same error, so unlikely to be new
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9418) Why implicitly call of the inner class instance not allowed?
[
https://issues.apache.org/jira/browse/GROOVY-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042920#comment-17042920
]
Jochen Theodorou commented on GROOVY-9418:
--
[~paulk] I remember we had a discussion about something like this long ago. And
I think we made a decision in this area, just I am not remembering the details
anymore. The handling does check for Closure, so if parent.child is a Closure,
it would work. It works with a local variable as you have shown (and I on
stackoverflow). But the big question here is if we should see this as a bug or
an kind of intended limitation. Surely checking for a call method is more
expensive than checking for the object to be an instance of Closure. And maybe
such a decision should be then put into the documentation
> Why implicitly call of the inner class instance not allowed?
>
>
> Key: GROOVY-9418
> URL: https://issues.apache.org/jira/browse/GROOVY-9418
> Project: Groovy
> Issue Type: Bug
> Components: Groovy Console, groovy-runtime
>Affects Versions: 2.4.18
>Reporter: gekm
>Priority: Major
>
> A parent and inner child classes:
> {code}
> class Parent {
> def name
> def child = new Child()
> def call() {
> println('parent called')
> }
> }
> class Child {
> def call() {
> println('child called')
> }
> }
> {code}
> Calling:
> {code}
> import base.Parent
> parent = new Parent(name: 'parent')
> parent()
> parent.child.call()
> parent.child()
> {code}
> output:
> {noformat}
> parent called
> child called
> Caught: groovy.lang.MissingMethodException: No signature of method:
> base.Parent.child() is applicable for argument types: () values: []
> Possible solutions: call(), find(), find(groovy.lang.Closure), getChild(),
> setChild(java.lang.Object), split(groovy.lang.Closure)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9516) Static compiler infers wrong type for implicitly shared variables
[
https://issues.apache.org/jira/browse/GROOVY-9516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090347#comment-17090347
]
Jochen Theodorou commented on GROOVY-9516:
--
Eric, would it not be better to handle this like an if-else and eval the type
of z to A here?
> Static compiler infers wrong type for implicitly shared variables
> -
>
> Key: GROOVY-9516
> URL: https://issues.apache.org/jira/browse/GROOVY-9516
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 3.0.0, 2.5.11
>Reporter: Konstantin Nisht
>Priority: Major
>
> Consider the following code
> {code:groovy}
> class A {}
> class B extends A{ def b() {}}
> class C extends A{}
> @CompileStatic
> static foo() {
> def x = new B()
> ({ x = new C() })()
> def z = x
> z.b()
> }
> {code}
> Here type of {{z}} in the last line of the method is deduced to be {{B}}.
> Attempt to execute {{z.b()}} leads to cast exception, which is unexpected
> under static compilation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9596) Cannot access protected field of Java superclass with --illegal-access=deny
[
https://issues.apache.org/jira/browse/GROOVY-9596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17140213#comment-17140213
]
Jochen Theodorou commented on GROOVY-9596:
--
It is not really a bug, it is a limitation of the reflective code and the
bytecode generation at runtime. The only way this is going to work is with
invokedynamic. Meaning you should compile with --indy to enable compilation
using invokedynamic. If that is still failing, then there is indeed a bug.
> Cannot access protected field of Java superclass with --illegal-access=deny
> ---
>
> Key: GROOVY-9596
> URL: https://issues.apache.org/jira/browse/GROOVY-9596
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 3.0.4, 2.5.12
> Environment: JDK 14
> Groovy 2.5.12 or 3.0.4
>Reporter: Kevin Rushforth
>Priority: Major
> Attachments: Main.groovy, Main2.groovy, MyAWTEvent.groovy,
> MyFilterReader.groovy
>
>
> When using the Java option {{--illegal-access=deny}}, a Groovy subclass that
> extends a Java superclass in the Java runtime (e.g., a class in the
> {{java.base}} module) cannot access a protected field in the parent class
> using {{this.fieldName}}.
> To reproduce this bug, use JDK 14 (or later) and run the following using
> either Groovy 2.5.12 or 3.0.4:
> {{$ groovyc Main.groovy MyFilterReader.groovy}}
> {{$ _JAVA_OPTIONS="--illegal-access=deny" groovy Main}}
> It works correctly without {{--illegal-access=deny}}. You can add
> {{-Dsun.reflect.debugModuleAccessChecks=access}} to get more detailed
> information about the illegal access exceptions that are being swallowed by
> Groovy.
> {{$ _JAVA_OPTIONS="--illegal-access=deny
> -Dsun.reflect.debugModuleAccessChecks=access" groovy Main}}
> WORKAROUND: change the following line in the Groovy subclass:
> line = ((BufferedReader)this.in).readLine();
> to:
> line = ((BufferedReader)super.in).readLine();
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9601) Parsing text into a class became much slower under Groovy 3.x
[
https://issues.apache.org/jira/browse/GROOVY-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17144875#comment-17144875
]
Jochen Theodorou commented on GROOVY-9601:
--
[~daniel_sun] I think you should not test this with GCL#parseClass if you want
to know if antlr4 or antlr2 are to blame. Instead I would suggest to use the
parser directly to create the initial AST, to avoid class transforms and
especially class resolution to influence the parsing result.
If I use
{code}
import groovy.transform.CompileStatic
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.Phases
def code = """
package lab
import groovy.transform.CompileStatic
@CompileStatic
class MyClass {
${x->
1000.times{i -> x << """
public void myMethod${i}() {
println('method ${i} invoked...')
}
"""}
}
}
"""
def cu = new CompilationUnit()
cu.addSource 'hello.groovy', code
def time0 = System.nanoTime()
cu.compile Phases.CONVERSION
def time1 = System.nanoTime()
println "time = ${(time1 - time0) / 100}ms"
{code}
With this my test program I get 157-200ms for 2.5.12. and 170-224ms for 3.0.4.
The tendency is to be 10% slower
If I change the phase to class generation I see for 2.5.12 573-656ms and for
3.0.4 721-816ms. Now I see a tendency of being 50% slower.
This tells me three things:
a) parsing takes only a fraction of the time of total compilation
b) parsing seems not to cause the 50% slow down
c) doing this from the console makes a big difference compared to when running
from the command line.
If I remove @CompileStatic in the code to be compiled, because it is code that
causes the compiler to be a lot slower I get of course lower times:
3.0.4: 476-580ms
2.5.12: 419-467ms
And even though I see here a slow down of 10-20%, it is still very far away
from the 50% before.
Ah yes... I did not use the cache threshold property in any of this. I tried it
out and I did not really see a difference. But as you can see I have a range of
190ms in my times. That is because I executed the code like 20 times or so, to
see how stable the results are. On my machine they are not very stable, so this
is more than just a one-time event up or down, that caused this. Anyway... I
tend to believe that the difference you did observe is because of the
instability of the result, rather than that there is a real difference for this
test here.
All in all my culprit is not ANTLR4, but @CompileStatic.
> Parsing text into a class became much slower under Groovy 3.x
> -
>
> Key: GROOVY-9601
> URL: https://issues.apache.org/jira/browse/GROOVY-9601
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 3.0.4
> Environment: Openjdk 11
>Reporter: Fabian Depry
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Attachments: 5.png, image-2020-06-25-17-42-31-315.png,
> no_tuning.png
>
>
> Our Java application needs to execute dynamically generated Groovy code and
> we use the GroovyClassLoader to create a class from that generated code.
> When we tried to upgrade to Groovy 3.x we noticed a huge bump in the time it
> takes to create those dynamic classes (it became 10 times slower for some of
> them).
> Here is a very simple example of how we use the class loader:
> {code:java}
> package lab;
> import groovy.lang.GroovyClassLoader;
> public class GroovySpeedLab {
> public static void main(String[] args) {
> StringBuilder buf = new StringBuilder();
> buf.append("package lab\r\n");
> buf.append("\r\n");
> buf.append("import groovy.transform.CompileStatic\r\n");
> buf.append("\r\n");
> buf.append("@CompileStatic\r\n");
> buf.append("class MyClass {\r\n");
> for (int i = 0; i < 1000; i++) {
> buf.append("\r\n");
> buf.append("public void myMethod").append(i).append("()
> {\r\n");
> buf.append("println('method ").append(i).append("
> invoked...')\r\n");
> buf.append("}\r\n");
> }
> buf.append("}\r\n");
> long start = System.currentTimeMillis();
> new GroovyClassLoader().parseClass(buf.toString());
> System.out.println("Done parsing in " + (System.currentTimeMillis() -
> start) + "ms");
> }
> }
> {code}
> While this runs very quickly (because the methods are trivial), it it still
> consistently 50% slower with 3.x (but I am including this example mainly to
> show our use-case, not to focus on its speed difference).
> Our
[jira] [Commented] (GROOVY-9611) Reflexive access to class attributes broken in Groovy 3
[
https://issues.apache.org/jira/browse/GROOVY-9611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149217#comment-17149217
]
Jochen Theodorou commented on GROOVY-9611:
--
That is an interesting issue. The class causing the IllegalAccessException is
not in Groovy, but in Java. So the only chance this can go wrong is in the way
the anonymous inner class Script$1 is compiled - specifically the modifiers
> Reflexive access to class attributes broken in Groovy 3
> ---
>
> Key: GROOVY-9611
> URL: https://issues.apache.org/jira/browse/GROOVY-9611
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.4
> Environment: macOs Catalina, openjdk 13.0.2 2020-01-14, Groovy 3.0.4
>Reporter: Gildas Morvan
>Priority: Major
> Attachments: GROOVY-9611.zip
>
>
> Since Groovy 3, the reflexive access to Groovy class attributes from Java is
> broken.
>
> The [following
> code|[https://github.com/gildasmorvan/similar2logo/blob/master/similar2logo-examples/src/main/groovy/fr/univ_artois/lgi2a/similar2logo/examples/boids/GroovyBoidsSimulation.groovy]]
> which works fine with groovy 2.5.* raises this exception:
>
> {{}}
>
> {code:java}
> juin 30, 2020 9:01:33 AM
> fr.univ_artois.lgi2a.similar.extendedkernel.libs.web.view.SimilarHtmlGenerator
> renderParameter
> WARNING: The parameter public double
> fr.univ_artois.lgi2a.similar2logo.examples.boids.GroovyBoidsSimulation$1.minInitialSpeed
> cannot be found
> java.lang.IllegalAccessException: class
> fr.univ_artois.lgi2a.similar.extendedkernel.libs.web.view.SimilarHtmlGenerator
> cannot access a member of class
> fr.univ_artois.lgi2a.similar2logo.examples.boids.GroovyBoidsSimulation$1 with
> modifiers "public"
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:376)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:642)
> at java.base/java.lang.reflect.Field.checkAccess(Field.java:1075)
> at java.base/java.lang.reflect.Field.get(Field.java:416)
> at
> fr.univ_artois.lgi2a.similar.extendedkernel.libs.web.view.SimilarHtmlGenerator.renderParameter(SimilarHtmlGenerator.java:290)
> at
> fr.univ_artois.lgi2a.similar.extendedkernel.libs.web.view.SimilarHtmlGenerator.lambda$renderParameters$4(SimilarHtmlGenerator.java:243)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at j2html.tags.ContainerTag.with(ContainerTag.java:100)
> at j2html.TagCreator.each(TagCreator.java:108)
> at
> fr.univ_artois.lgi2a.similar.extendedkernel.libs.web.view.SimilarHtmlGenerator.renderParameters(SimilarHtmlGenerator.java:243)
> at
> fr.univ_artois.lgi2a.similar.extendedkernel.libs.web.view.SimilarHtmlGenerator.renderView(SimilarHtmlGenerator.java:166)
> at
> fr.univ_artois.lgi2a.similar.extendedkernel.libs.web.view.SimilarHttpServer.lambda$initServer$0(SimilarHttpServer.java:112)
> at spark.RouteImpl$1.handle(RouteImpl.java:72)
> at spark.http.matching.Routes.execute(Routes.java:61)
> at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:134)
> at spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1671)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:505)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698)
> at
> org.eclipse.jetty.util.thread.QueuedThrea
[jira] [Commented] (GROOVY-9588) groovyCompile 6x slower in 3.0.4 than 2.5.6
[
https://issues.apache.org/jira/browse/GROOVY-9588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150404#comment-17150404
]
Jochen Theodorou commented on GROOVY-9588:
--
My suggestion would be
{noformat}
number of files * 15
{noformat}
But 50G heap? We must find a way to reduce that.
> groovyCompile 6x slower in 3.0.4 than 2.5.6
> ---
>
> Key: GROOVY-9588
> URL: https://issues.apache.org/jira/browse/GROOVY-9588
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Affects Versions: 3.0.4
>Reporter: Eric Helgeson
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
>
> _It was suggested I open an issue here as well. I am a user of groovy so do
> not know a lot of the details that could help diagnose. I would be happy to
> gather them if told what was required._
> [https://github.com/grails/grails-core/issues/11571]
> We are upgrading a large Grails app with 400+ controllers, 550+ services, 350
> domains, 4000 files with 950k loc to Grails 4.1.0.M1 + Gradle 5.6.4.
> Using Gradle 5.6.4 with Java 8 & Grails 4.0.3(Groovy 2.5) a
> clean/groovyCompile took approximately 5 minutes.
>
> Using Gradle 5.6.4 with Java 11 & Grails 4.1.0.M1(Groovy 3.0.4) a
> {{clean}}/{{groovyCompile}} takes 33 minutes on a 2019 MBP w/ 2.4 GHz 8-Core
> Intel Core i9 & 64gb of RAM.
> I have tried giving the groovyCompile task 16/32gb of ram, with no noticeable
> change. I've also tried -Dgroovy.antlr4=false - but this gave other compile
> time errors I did not see with it set to true (so was unable to have a full
> successful compile)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-7693) Error when trying to print negative number in console
[ https://issues.apache.org/jira/browse/GROOVY-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043772#comment-15043772 ] Jochen Theodorou commented on GROOVY-7693: -- just to add: the no-args method call requires the usage of round brackets, thus println is never considered being a method call here. This all already happens during parsing. > Error when trying to print negative number in console > - > > Key: GROOVY-7693 > URL: https://issues.apache.org/jira/browse/GROOVY-7693 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 2.4.5 > Environment: OS: Mac OS X 10.11 and Debian GNU/Linux Jessie 8.0 > Java: JDK 7u80 > Groovy: 2.4.5 >Reporter: Michael Chen >Priority: Minor > > $ groovy -e 'println -3' > Caught: groovy.lang.MissingPropertyException: No such property: println for > class: script_from_command_line > groovy.lang.MissingPropertyException: No such property: println for class: > script_from_command_line > at script_from_command_line.run(script_from_command_line:1) > $ groovy -e 'println (-3)' > -3 > This error occurred when written either in script file or on-the-fly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GROOVY-7693) Error when trying to print negative number in console
[
https://issues.apache.org/jira/browse/GROOVY-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-7693.
--
Resolution: Won't Fix
Assignee: Jochen Theodorou
I don't think we can fix that really. just think of for example {{foo-bar}}. Is
this now supposed to be a method call of the method foo with the expression
{{-bar}}, or is that supposed to be variable/property {{foo}} minus
variable/property {{bar}}? The expression case gives us more merit, thus you
will have to write {{foo(-bar)}} to make it work.
> Error when trying to print negative number in console
> -
>
> Key: GROOVY-7693
> URL: https://issues.apache.org/jira/browse/GROOVY-7693
> Project: Groovy
> Issue Type: Bug
> Components: Groovy Console
>Affects Versions: 2.4.5
> Environment: OS: Mac OS X 10.11 and Debian GNU/Linux Jessie 8.0
> Java: JDK 7u80
> Groovy: 2.4.5
>Reporter: Michael Chen
>Assignee: Jochen Theodorou
>Priority: Minor
>
> $ groovy -e 'println -3'
> Caught: groovy.lang.MissingPropertyException: No such property: println for
> class: script_from_command_line
> groovy.lang.MissingPropertyException: No such property: println for class:
> script_from_command_line
> at script_from_command_line.run(script_from_command_line:1)
> $ groovy -e 'println (-3)'
> -3
> This error occurred when written either in script file or on-the-fly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7704) .getAt epxression parsing rules
[ https://issues.apache.org/jira/browse/GROOVY-7704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050352#comment-15050352 ] Jochen Theodorou commented on GROOVY-7704: -- So you say (1..10)[2] is mapped then to (1..10).getAt(2) and (1..10) [2] is mapped to...(1..10).getAt(2)? No, I guess what you really target is something like println[2] and println [2]. With the first one looking for a variable println and use getAt on it, while the second one is supposed to be a method call which is given the list [2] > .getAt epxression parsing rules > --- > > Key: GROOVY-7704 > URL: https://issues.apache.org/jira/browse/GROOVY-7704 > Project: Groovy > Issue Type: Wish >Reporter: Dmitry Geurkov > > expression f[g] is translated into f.getAt(g) > same is when there is a space between f and [g] > however from my point of view space character introduces separation of > concept thus this behavior is not correct and it should be evaluated into > function call f([g]) instead of f.getAt(g) > For example in Ruby f [g] is considered a function call with Array as first > argument which is more natural way looking at it. While in f[g] is correctly > interpreted as index lookup > Some more examples of how this should behave: > (1..10)[2] is correctly interpreted as index lookup > (1..10) [2] is two separate objects: range and array -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GROOVY-7709) NPE with ConvertedClosure
Jochen Theodorou created GROOVY-7709:
Summary: NPE with ConvertedClosure
Key: GROOVY-7709
URL: https://issues.apache.org/jira/browse/GROOVY-7709
Project: Groovy
Issue Type: Bug
Reporter: Jochen Theodorou
{code}
interface Y extends GroovyObject {}
def cl = {println 1} as Y
assert cl instanceof GroovyObject
if (cl) println "!cl"
{code}
the code above will cause the execution of the method getMetaClass in the
boolean part of the "if". It looks like this code path now produces a NPE
{code}
java.lang.NullPointerException
at
org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:919)
at
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:902)
at
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToBoolean(DefaultTypeTransformation.java:185)
at
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.booleanUnbox(DefaultTypeTransformation.java:74){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7709) NPE with ConvertedClosure
[
https://issues.apache.org/jira/browse/GROOVY-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7709:
-
Affects Version/s: 2.4.5
> NPE with ConvertedClosure
> -
>
> Key: GROOVY-7709
> URL: https://issues.apache.org/jira/browse/GROOVY-7709
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5
>Reporter: Jochen Theodorou
>
> {code}
> interface Y extends GroovyObject {}
> def cl = {println 1} as Y
> assert cl instanceof GroovyObject
> if (cl) println "!cl"
> {code}
> the code above will cause the execution of the method getMetaClass in the
> boolean part of the "if". It looks like this code path now produces a NPE
> {code}
> java.lang.NullPointerException
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:919)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:902)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToBoolean(DefaultTypeTransformation.java:185)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.booleanUnbox(DefaultTypeTransformation.java:74){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7709) NPE with ConvertedClosure
[
https://issues.apache.org/jira/browse/GROOVY-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052678#comment-15052678
]
Jochen Theodorou commented on GROOVY-7709:
--
not tested against master
> NPE with ConvertedClosure
> -
>
> Key: GROOVY-7709
> URL: https://issues.apache.org/jira/browse/GROOVY-7709
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5
>Reporter: Jochen Theodorou
>
> {code}
> interface Y extends GroovyObject {}
> def cl = {println 1} as Y
> assert cl instanceof GroovyObject
> if (cl) println "!cl"
> {code}
> the code above will cause the execution of the method getMetaClass in the
> boolean part of the "if". It looks like this code path now produces a NPE
> {code}
> java.lang.NullPointerException
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:919)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:902)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToBoolean(DefaultTypeTransformation.java:185)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.booleanUnbox(DefaultTypeTransformation.java:74){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7709) NPE with ConvertedClosure
[
https://issues.apache.org/jira/browse/GROOVY-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054596#comment-15054596
]
Jochen Theodorou commented on GROOVY-7709:
--
1.6.9, really? I thought 2.3.6 was working as well
> NPE with ConvertedClosure
> -
>
> Key: GROOVY-7709
> URL: https://issues.apache.org/jira/browse/GROOVY-7709
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5
>Reporter: Jochen Theodorou
>
> {code}
> interface Y extends GroovyObject {}
> def cl = {println 1} as Y
> assert cl instanceof GroovyObject
> if (cl) println "!cl"
> {code}
> the code above will cause the execution of the method getMetaClass in the
> boolean part of the "if". It looks like this code path now produces a NPE
> {code}
> java.lang.NullPointerException
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:919)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:902)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToBoolean(DefaultTypeTransformation.java:185)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.booleanUnbox(DefaultTypeTransformation.java:74){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15060116#comment-15060116
]
Jochen Theodorou commented on GROOVY-7683:
--
normally the ClassInfo object does not only refer to the class directly, but
also indirectly using hard references, for example through method methods,
which are based on the real methods of the class, which are based on
reflection, which then have direct references to classes again, of which
usually the class in question is one. If a patch like this fixes the problem so
should enabling CMS. So frankly I would not expect this patch to work, in fact
I would be quite surprised if it does. But if someone has this problem and can
try out if the patch changes anything, I am curious to hear about the results.
I would help even if the patch would not work out
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7713) CompileStatic checking fails with null returns
[
https://issues.apache.org/jira/browse/GROOVY-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7713:
-
Component/s: Static Type Checker
> CompileStatic checking fails with null returns
> --
>
> Key: GROOVY-7713
> URL: https://issues.apache.org/jira/browse/GROOVY-7713
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.4, 2.4.5
>Reporter: Scott Douglas
>Priority: Minor
> Attachments: Test1.groovy, Test2.groovy, Test3.groovy, Test4.groovy
>
>
> -
> TEST 1
> -
> {code}
> package test
> import groovy.transform.CompileStatic
> class TestClass {
> @CompileStatic
> void doTest() {
> Closure closure = {
> return "foo";
> }
> }
> }
> {code}
> Compiles fine.
> -
> TEST 2
> -
> {code}
> package test
> import groovy.transform.CompileStatic
> class TestClass {
> @CompileStatic
> void doTest() {
> Closure closure = {
> if ("bah".length() == 3) {
> return null
> }
> return "foo";
> }
> }
> }
> {code}
> ...gives...
> {code}
> groovyc Test2.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Test2.groovy: 9: [Static type checking] - Incompatible generic argument
> types. Cannot assign groovy.lang.Closure to:
> groovy.lang.Closure
> @ line 9, column 29.
> Closure closure = {
>^
> 1 error
> {code}
> -
> TEST 3
> -
> {code}
> package test
> import groovy.transform.CompileStatic
> class TestClass {
> @CompileStatic
> void doTest() {
> Closure closure = {
> return null;
> }
> }
> }
> {code}
> ...gives...
> {code}
> groovyc Test3.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Test3.groovy: 9: [Static type checking] - Incompatible generic argument
> types. Cannot assign groovy.lang.Closure to:
> groovy.lang.Closure
> @ line 9, column 29.
> Closure closure = {
>^
> 1 error
> {code}
> -
> TEST 4
> -
> {code}
> package test
> import groovy.transform.CompileStatic
> class TestClass {
> @CompileStatic
> void doTest() {
> Closure closure = {
> }
> }
> }
> {code}
> Compiles fine.
> -
> COMMENTS
> -
> All files were compiled with 'groovyc Test\[1234\].groovy'. I expected all
> tests to compile. I wouldn't have thought returning null would cause a static
> compilation failure since null is a valid String. Also, I expected test 3 and
> test 4 to be equivalent.
> The workaround appears to be to cast the closure, like:
> {code}
> Closure closure = (Closure) {
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7713) CompileStatic checking fails with null returns
[
https://issues.apache.org/jira/browse/GROOVY-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15063776#comment-15063776
]
Jochen Theodorou commented on GROOVY-7713:
--
The problem is that null requires a quite different handling in the type
system, since it can mean any type. And there are still a lot of bugs in that
area. Casting the null should for example also bypass your problems.
> CompileStatic checking fails with null returns
> --
>
> Key: GROOVY-7713
> URL: https://issues.apache.org/jira/browse/GROOVY-7713
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.4, 2.4.5
>Reporter: Scott Douglas
>Priority: Minor
> Attachments: Test1.groovy, Test2.groovy, Test3.groovy, Test4.groovy
>
>
> -
> TEST 1
> -
> {code}
> package test
> import groovy.transform.CompileStatic
> class TestClass {
> @CompileStatic
> void doTest() {
> Closure closure = {
> return "foo";
> }
> }
> }
> {code}
> Compiles fine.
> -
> TEST 2
> -
> {code}
> package test
> import groovy.transform.CompileStatic
> class TestClass {
> @CompileStatic
> void doTest() {
> Closure closure = {
> if ("bah".length() == 3) {
> return null
> }
> return "foo";
> }
> }
> }
> {code}
> ...gives...
> {code}
> groovyc Test2.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Test2.groovy: 9: [Static type checking] - Incompatible generic argument
> types. Cannot assign groovy.lang.Closure to:
> groovy.lang.Closure
> @ line 9, column 29.
> Closure closure = {
>^
> 1 error
> {code}
> -
> TEST 3
> -
> {code}
> package test
> import groovy.transform.CompileStatic
> class TestClass {
> @CompileStatic
> void doTest() {
> Closure closure = {
> return null;
> }
> }
> }
> {code}
> ...gives...
> {code}
> groovyc Test3.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Test3.groovy: 9: [Static type checking] - Incompatible generic argument
> types. Cannot assign groovy.lang.Closure to:
> groovy.lang.Closure
> @ line 9, column 29.
> Closure closure = {
>^
> 1 error
> {code}
> -
> TEST 4
> -
> {code}
> package test
> import groovy.transform.CompileStatic
> class TestClass {
> @CompileStatic
> void doTest() {
> Closure closure = {
> }
> }
> }
> {code}
> Compiles fine.
> -
> COMMENTS
> -
> All files were compiled with 'groovyc Test\[1234\].groovy'. I expected all
> tests to compile. I wouldn't have thought returning null would cause a static
> compilation failure since null is a valid String. Also, I expected test 3 and
> test 4 to be equivalent.
> The workaround appears to be to cast the closure, like:
> {code}
> Closure closure = (Closure) {
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[ https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067388#comment-15067388 ] Jochen Theodorou commented on GROOVY-7683: -- How things on the JVM are supposed to be working is the following... imagine a class that is nowhere referenced anymore, but in an equally otherwise non-referenced class loader and another object. Imagine this other object is softly reachable, meaning no strong/weak/phantom reference is pointing to it.This is supposed to mean, that the class is softly reachable as well. So in theory, as long as the ClassInfo object is not strongly reachable, the ClassInfo object could be collected along with the class. In the practice though, things do not always work like that. I know for sure, that the IBM JVM for example needs special options given to it, to even check such a case. For the Oracle JVM enabling CMS used to help with this problem. For the Oracle JVM the problem is that normally the garbage collection for classes and the garbage collection for instances is not done together. So unless the ClassInfo object is collected it happens that the class will stay. Since ClassInfo objects are normally softly referenced, they will stay till the very last moment, increasing the probability of the problem to occur. The fact, that there is a multitude of objects referenced by ClassInfo, which hold strong references to the class (for example a reflective method object could be one, but the type information in the meta methods is already enough) does not help the garbage collector at all. As bad as it sounds, in the end it depends on the implementation of the garbage collector if that object can be collected. So it is supposed to work, but can for several reasons not sometimes. Of course that is all theory and past experience. It is very possible, that there is somewhere a strong reference, where it should not be. But as I tried to explain above, changing ClassInfo to use a weak key for the Class is not something I would expect to really help. The patch that is attached here, tries it with a SoftReference. WeakReference could be better, but frankly there are still many many strong references to the class through other objects hard referenced by the ClassInfo object. Could be, that this decreases the number of hard references just enough to not be over some threshold optimization in the garbage collector and then allows the garbage collector to collect. Or it might not have any effect. My expectation is that it won't change anything. As for the ClassInfoCleanup.. it is not right that it is not stored. When you create a Soft/WeakReference, then there will be a reference object and a ReferenceQueue. The queue will know the reference. And it is not that those references simply vanish. In fact, if you don't clean up the queue, you will get a memory leak from that side, even if the objects you reference would be collected. But for Weak/SoftReference this is not actually the case, you would need PhantomReference for that. On the other hand, you are right, that this code has almost zero relevance when it comes to the automatic removal of ClassInfo. If the ClassInfo has a strong reference set, the ClassInfo object itself will not be weak referenced. Same for the cleanups... there are more to support garbage collection a little, than that they are really needed. The real code managing the reference is in ManagedLinkedList as far as GlobalClassSet is concerned. Or the manged hashmap in GroovyClassValuePreJava7. Oh, one correction... ClassInfo is mostly weakly reachable in those structures, not softly. cachedClassRef and artifactClassLoader are should be soft reachable, same for the entries of LocalMap > Memory leak when using Groovy as JSR-223 scripting language. > > > Key: GROOVY-7683 > URL: https://issues.apache.org/jira/browse/GROOVY-7683 > Project: Groovy > Issue Type: Bug > Components: GroovyScriptEngine >Affects Versions: 2.4.5 > Environment: OS: tested on Mac OS X El Capitan and Windows 10. > JVM: tested on 1.8.0_60 and 1.8.0_65. >Reporter: Arkadiusz Gasinski > Labels: jsr-223 > Attachments: > 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch > > > We have a Java EE 7 web application in production that when handling single > HTTP request can load and execute up to several Groovy scripts using the > jsr-223 API. This application is deployed to GlassFish 4.1 server cluster > with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to > restart them every couple of days (3-4), because of leaking memory. After > analyzing a couple of heap dumps, our main suspect is Groovy with its > MetaMethodIndex$Entry class (the below table sho
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067895#comment-15067895
]
Jochen Theodorou commented on GROOVY-7683:
--
John, you are right... I should not write comments on JIRA at 2:00 in the
morning. The Reference has to be alive to be enqueued, you are fully right
there. The conclusion that ClassInfoCleanup is then doing about nothing is most
likely right as well, some for DebugRef. Those have been handled different
before the ClassValue rewrite.
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7716) groovy.json.internal.FastStringUtils.StringImplementation#toCharArray fails on jdk9
[ https://issues.apache.org/jira/browse/GROOVY-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou updated GROOVY-7716: - Labels: jdk9 (was: ) > groovy.json.internal.FastStringUtils.StringImplementation#toCharArray fails > on jdk9 > --- > > Key: GROOVY-7716 > URL: https://issues.apache.org/jira/browse/GROOVY-7716 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.3.10 >Reporter: Nikita Salnikov-Tarnovski > Labels: jdk9 > > Trying to build my application on recent jdk9 build I got the following > exception: > java.lang.ClassCastException: [B cannot be cast to [C > at > groovy.json.internal.FastStringUtils$StringImplementation$1.toCharArray(FastStringUtils.java:88) > at > groovy.json.internal.FastStringUtils.toCharArray(FastStringUtils.java:175) > at groovy.json.internal.BaseJsonParser.parse(BaseJsonParser.java:103) > at groovy.json.JsonSlurper.parseText(JsonSlurper.java:208) > I believe that jdk9 has changed the inner representation of Strings (see > http://openjdk.java.net/jeps/254). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7709) NPE with ConvertedClosure
[
https://issues.apache.org/jira/browse/GROOVY-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15071438#comment-15071438
]
Jochen Theodorou commented on GROOVY-7709:
--
The question is what the right behaviour is. In case of {code:Java}inteface Foo
{ def x(); def y()}
def cl = [x:{1},y:{2}]
def object = cl as Foo
assert object instanceof Foo
assert object.x() == 1
assert object.y() == 2
{code}
We have the map taking care of what method is supposed to be used for a
specific method. But we do also allow this:
{code:Java}inteface Foo { def x(); def y()}
def cl = {1}
def object = cl as Foo
assert object instanceof Foo
assert object.x() == 1
assert object.y() == 1
{code}
and here the Closure object is taken for everything. So according to that, it
is not really wrong if the closure reacts to getMetaClass or asBoolean. but
calling getMetaClass twice... hmm... I can't tell for sure if that is wrong or
not.
As for the NPE... I have had no time to properly look at this, but could it be
that it happens, because the returned meta class is null?
> NPE with ConvertedClosure
> -
>
> Key: GROOVY-7709
> URL: https://issues.apache.org/jira/browse/GROOVY-7709
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5
>Reporter: Jochen Theodorou
>
> {code}
> interface Y extends GroovyObject {}
> def cl = {println 1} as Y
> assert cl instanceof GroovyObject
> if (cl) println "!cl"
> {code}
> the code above will cause the execution of the method getMetaClass in the
> boolean part of the "if". It looks like this code path now produces a NPE
> {code}
> java.lang.NullPointerException
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:919)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:902)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToBoolean(DefaultTypeTransformation.java:185)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.booleanUnbox(DefaultTypeTransformation.java:74){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7721) Static type checking fails when compiling against a Java8 interface with inherited methods
[
https://issues.apache.org/jira/browse/GROOVY-7721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073842#comment-15073842
]
Jochen Theodorou commented on GROOVY-7721:
--
This would mean the static compiler does not ignore the synthetic bridge method
in I2 (created for the R[] returning method)
> Static type checking fails when compiling against a Java8 interface with
> inherited methods
> --
>
> Key: GROOVY-7721
> URL: https://issues.apache.org/jira/browse/GROOVY-7721
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.0
>Reporter: Peter Gromov
>Assignee: Cédric Champeau
>
> Create classes.java:
> {code}
> interface I {
> R[] method();
> }
> interface I2 extends I {
> R2[] method();
> }
> interface R {}
> interface R2 extends R {}
> {code}
> compile it with JDK 8 javac.
> Then create usage.groovy:
> {code}import groovy.transform.CompileStatic
> @CompileStatic
> class Gr {
> R2[] x(I2 i) {
>return i.method();
> }
> }
> {code}
> Compile it with groovyc (also run with Java8) with the classes from previous
> compilation in the classpath. Compilation fails:
> {code}
> usage.groovy: 6: [Static type checking] - Reference to method is ambiguous.
> Cannot choose between [R2[] I2#method(), R[] I2#method()]
> @ line 6, column 15.
> return i.method();
> ^
> 1 error
> {code}
> Originally reported as https://youtrack.jetbrains.com/issue/IDEA-148973
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7530) disjoint() does not work correctly if objects don't implement Comparable
[
https://issues.apache.org/jira/browse/GROOVY-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15082995#comment-15082995
]
Jochen Theodorou commented on GROOVY-7530:
--
if there is an issue about talking about the security problem per se, then I
suggest mailing either us directly by mail or to use the apache security
infrastructure through http://www.apache.org/security/
> disjoint() does not work correctly if objects don't implement Comparable
>
>
> Key: GROOVY-7530
> URL: https://issues.apache.org/jira/browse/GROOVY-7530
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.4
>Reporter: Tobias Ahlers
>
> {code:java}
> class Foo {
> private String name
> Foo(String name) {
> this.name = name
> }
> public boolean equals(Object o) {
> if (this == o) return true
> if (o == null || getClass() != o.getClass()) return false
> Foo that = (Foo) o
> return Objects.equals(name, that.name)
> }
> public int hashCode() {
> return Objects.hash(name)
> }
> }
> def a = [new Foo("foo")]
> def b = [new Foo("foo")]
> assert !a.disjoint(b)
> {code}
> If disjoint() is used on a list with objects not implementing Comparable the
> wrong result is returned.
> intersect() shows the same wrong behavior.
> It's looks like the NumberAwareComparator not implementing the equals case as
> of commit 286532c is the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7291) Declaration of double variable without value assignment referrenced in closure
[
https://issues.apache.org/jira/browse/GROOVY-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7291:
-
Fix Version/s: 2.5.0-beta-1
2.4.6
> Declaration of double variable without value assignment referrenced in closure
> --
>
> Key: GROOVY-7291
> URL: https://issues.apache.org/jira/browse/GROOVY-7291
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 1.8.6, 2.2.1, 2.4.0
> Environment: Windows 8.1, JDK 1.7_71 and 1.8_25
>Reporter: David Richter
> Fix For: 2.4.6, 2.5.0-beta-1
>
> Attachments: groovyBug.zip
>
>
> I have problem with following code:
> double a;
> def b = {
>a = a + 1;
> }
> b();
> I tried to compile it with groovy 1.8.6 and it worked
> variable 'a' was instantiated with value 0.0
> but after upgrade to groovy 2.2.1
> it throws NullPointerException because variable 'a' is instantiated to null
> I tried to decompile class files and declaration of 'a' looked like this:
> version 1.8.6
> CallSite[] var1 = $getCallSiteArray();
> final Reference a = new
> Reference((Double)DefaultTypeTransformation.box(0.0D));
> DefaultTypeTransformation.doubleUnbox(a.get());
> ...
> version 2.2.1
> CallSite[] var1 = $getCallSiteArray();
> final Reference a = new Reference((Object)null);
> Double var1 = (Double)a.get();
> ...
> I tried it also with version 2.4.0 but it has same result as 2.2.1
> In attachment are groovy classes, compiled classes and consoleOutputs for
> versions 1.8.6 and 2.2.1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7291) Declaration of double variable without value assignment referrenced in closure
[
https://issues.apache.org/jira/browse/GROOVY-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7291:
-
Priority: Critical (was: Major)
> Declaration of double variable without value assignment referrenced in closure
> --
>
> Key: GROOVY-7291
> URL: https://issues.apache.org/jira/browse/GROOVY-7291
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 1.8.6, 2.2.1, 2.4.0
> Environment: Windows 8.1, JDK 1.7_71 and 1.8_25
>Reporter: David Richter
>Priority: Critical
> Fix For: 2.4.6, 2.5.0-beta-1
>
> Attachments: groovyBug.zip
>
>
> I have problem with following code:
> double a;
> def b = {
>a = a + 1;
> }
> b();
> I tried to compile it with groovy 1.8.6 and it worked
> variable 'a' was instantiated with value 0.0
> but after upgrade to groovy 2.2.1
> it throws NullPointerException because variable 'a' is instantiated to null
> I tried to decompile class files and declaration of 'a' looked like this:
> version 1.8.6
> CallSite[] var1 = $getCallSiteArray();
> final Reference a = new
> Reference((Double)DefaultTypeTransformation.box(0.0D));
> DefaultTypeTransformation.doubleUnbox(a.get());
> ...
> version 2.2.1
> CallSite[] var1 = $getCallSiteArray();
> final Reference a = new Reference((Object)null);
> Double var1 = (Double)a.get();
> ...
> I tried it also with version 2.4.0 but it has same result as 2.2.1
> In attachment are groovy classes, compiled classes and consoleOutputs for
> versions 1.8.6 and 2.2.1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7291) Declaration of double variable without value assignment referrenced in closure
[
https://issues.apache.org/jira/browse/GROOVY-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15083011#comment-15083011
]
Jochen Theodorou commented on GROOVY-7291:
--
I did set the fix version for the next release, because I think that is a more
than usual bug. But I have only very little time these days to actually do the
change. So either someone else does, or you have to wait and see - sorry.
Well... another option would actually be, that you guys pay the company
employing me to spend time on fixing this - but I don't expect that to be an
option
> Declaration of double variable without value assignment referrenced in closure
> --
>
> Key: GROOVY-7291
> URL: https://issues.apache.org/jira/browse/GROOVY-7291
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 1.8.6, 2.2.1, 2.4.0
> Environment: Windows 8.1, JDK 1.7_71 and 1.8_25
>Reporter: David Richter
>Priority: Critical
> Fix For: 2.4.6, 2.5.0-beta-1
>
> Attachments: groovyBug.zip
>
>
> I have problem with following code:
> double a;
> def b = {
>a = a + 1;
> }
> b();
> I tried to compile it with groovy 1.8.6 and it worked
> variable 'a' was instantiated with value 0.0
> but after upgrade to groovy 2.2.1
> it throws NullPointerException because variable 'a' is instantiated to null
> I tried to decompile class files and declaration of 'a' looked like this:
> version 1.8.6
> CallSite[] var1 = $getCallSiteArray();
> final Reference a = new
> Reference((Double)DefaultTypeTransformation.box(0.0D));
> DefaultTypeTransformation.doubleUnbox(a.get());
> ...
> version 2.2.1
> CallSite[] var1 = $getCallSiteArray();
> final Reference a = new Reference((Object)null);
> Double var1 = (Double)a.get();
> ...
> I tried it also with version 2.4.0 but it has same result as 2.2.1
> In attachment are groovy classes, compiled classes and consoleOutputs for
> versions 1.8.6 and 2.2.1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7701) org.codehaus.groovy.runtime.typehandling.GroovyCastException in Groovy ".with { ... }" - Block
[
https://issues.apache.org/jira/browse/GROOVY-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15083017#comment-15083017
]
Jochen Theodorou commented on GROOVY-7701:
--
as long as the bug is open, you cannot expect it been fixed in the next version
> org.codehaus.groovy.runtime.typehandling.GroovyCastException in Groovy ".with
> { ... }" - Block
> --
>
> Key: GROOVY-7701
> URL: https://issues.apache.org/jira/browse/GROOVY-7701
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.3, 2.4.4, 2.4.5
> Environment: all?
> Tested with Ubuntu 14.04.3 LTS (64 Bit) | MacOS 10.11 and Groovy 2.4.5, 2.3.4
>Reporter: Maik Igloffstein
>
> h1. Problem
> {code}
> subClass.with {
> type = ['String']
> }
> {code}
> Should change _SubClass.type_ and not _TopClass.type_.
> The script works fine with _type2_ instead of _type_. Is _type_ a reserved
> word? I can't find any documentation about this.
> h2. Unit-Test / Groovy Console-Test
> {code}
> class SubClass{
> List type
> }
> class TopClass{
> int type = 10
> @Lazy
> List something = {
> List tmp = []
> for(int i = 0; i < 5; i++){
> def subClass = new SubClass()
> subClass.with {
> type = ['String'] // throws
> org.codehaus.groovy.runtime.typehandling.GroovyCastException
> }
> tmp.add(subClass)
> }
> tmp
> }()
> }
> def topClass = new TopClass()
> println GroovySystem.version
> println(topClass.type)
> println(topClass.something)
> println(topClass.type)
> {code}
> h2. Exception
> {code}
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object '[String]' with class 'java.util.ArrayList' to class 'int'
> at TopClass$_getSomething_closure1$_closure2.doCall(ConsoleScript3:15)
> at TopClass$_getSomething_closure1.doCall(ConsoleScript3:14)
> at TopClass$_getSomething_closure1.doCall(ConsoleScript3)
> at TopClass.getSomething(ConsoleScript3:11)
> at ConsoleScript3.run(ConsoleScript3:26)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7530) disjoint() does not work correctly if objects don't implement Comparable
[
https://issues.apache.org/jira/browse/GROOVY-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085307#comment-15085307
]
Jochen Theodorou commented on GROOVY-7530:
--
Ok, thanks for the clarification. We had been very very much irritated by this
code causing a vulnerability issue. It is not out of question, since the
example exploit for CVE-2015-3253 you mentioned actually does misuse a sorting
structure in Java for the exploit. so I could not totally exclude such a
possibility.
Anyway... back to the problem.
{code:Java}
def a = [new Foo("foo")]
def b = [new Foo("foo")]
assert !a.disjoint(b)
{code}
The basic problem is as follows.. if the objects are somehow comparable, then
you can do disjoint in O(nlogn), by first sorting one and then checking against
the other. If the objects are not comparable and if I can only check for
equality, then I am required to use an O(n*n) approach, by checking each
elements of one list, against each of the other.. well it is more like n*n/2,
but that does not matter when looking at the complexity. So in older versions
we first did check both lists if all elements are Comparable, to then later
decide on the strategy and go with the nlogn of the n*n variant. But this
approach did also not get the desired results, as can be seen in the test in
286532c
But I am wondering now... maybe the better approach is to add one more check
like {code:java}
if (o1.getClass()==o2.getClass() && (o1.equals(o2)) return 0;
{code}
But I wonder what we are supposed to return if equals gives false. If we say we
return only 0, we could also think about removing the class check. or we keep
the class check and return -1 in case of equals returning false.
> disjoint() does not work correctly if objects don't implement Comparable
>
>
> Key: GROOVY-7530
> URL: https://issues.apache.org/jira/browse/GROOVY-7530
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.4
>Reporter: Tobias Ahlers
>
> {code:java}
> class Foo {
> private String name
> Foo(String name) {
> this.name = name
> }
> public boolean equals(Object o) {
> if (this == o) return true
> if (o == null || getClass() != o.getClass()) return false
> Foo that = (Foo) o
> return Objects.equals(name, that.name)
> }
> public int hashCode() {
> return Objects.hash(name)
> }
> }
> def a = [new Foo("foo")]
> def b = [new Foo("foo")]
> assert !a.disjoint(b)
> {code}
> If disjoint() is used on a list with objects not implementing Comparable the
> wrong result is returned.
> intersect() shows the same wrong behavior.
> It's looks like the NumberAwareComparator not implementing the equals case as
> of commit 286532c is the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7727) Cannot create unicode sequences using \Uxxxxxx
[ https://issues.apache.org/jira/browse/GROOVY-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou updated GROOVY-7727: - Summary: Cannot create unicode sequences using \Uxx (was: CAnnot create unicode sequences using \Uxx) > Cannot create unicode sequences using \Uxx > -- > > Key: GROOVY-7727 > URL: https://issues.apache.org/jira/browse/GROOVY-7727 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.4.5 >Reporter: Andres Almiray > > According to > http://www.oracle.com/technetwork/articles/java/supplementary-142654.html > "For text input, the Java 2 SDK provides a code point input method which > accepts strings of the form "\Uxx", where the uppercase "U" indicates > that the escape sequence contains six hexadecimal digits, thus allowing for > supplementary characters. A lowercase "u" indicates the original form of the > escape sequences, "\u". You can find this input method and its > documentation in the directory demo/jfc/CodePointIM of the J2SDK." > The following code fails with a syntax exception > s = "\U01f5d0" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7670) CLONE - dash in script filename
[
https://issues.apache.org/jira/browse/GROOVY-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090959#comment-15090959
]
Jochen Theodorou commented on GROOVY-7670:
--
The problem is that the dash is not a valid part of a class name in the JVM.
And it has been like that since early versions of the JDK, so I wonder what you
mean with that being a regression from quite a recent Groovy version Jamie. It
is of course always possible that the name check in the JVM did not always
catch all invalid cases, thus allowing illegal class names sometimes. But it
would help if you could tell me what Groovy version you had in mind, just in
case. Because we did add some name mangling, which could be reused here as well.
Anyway... my suggestion for a fix would be to use the existing name mangling
and apply it to script class names.
> CLONE - dash in script filename
> ---
>
> Key: GROOVY-7670
> URL: https://issues.apache.org/jira/browse/GROOVY-7670
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.4.5
> Environment: Oracle Java 8, Windows (although OS is not relevant IMHO)
>Reporter: Christoph Grothaus
>Priority: Minor
> Attachments: fibonacci-numbers.groovy, fibonacci_numbers.groovy
>
>
> Cannot create script with dash ("-") in filename.
> Please try to run the two attached groovy scripts. The one with an underscore
> in the filename runs happily (don't wonder, it gives no output). The one with
> a dash in the filename gives this error: {noformat}$ groovy
> fibonacci-numbers.groovy
> Caught: java.lang.ClassFormatError: Illegal class name
> "fibonacci-numbers$fib" in class file fibonacci-numbers$fib
> java.lang.ClassFormatError: Illegal class name "fibonacci-numbers$fib" in
> class file fibonacci-numbers$fib
> at fibonacci-numbers.run(fibonacci-numbers.groovy:5){noformat}
> It really took me some time to figure out that the dash was causing this. I
> would like to see Groovy allowing dashes in script filenames. If that should
> be impossible, at least the error message should cleary indicate that I have
> used an illegal character in the script filename.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7530) disjoint() does not work correctly if objects don't implement Comparable
[
https://issues.apache.org/jira/browse/GROOVY-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090961#comment-15090961
]
Jochen Theodorou commented on GROOVY-7530:
--
yes, also a good idea... I do like this more, because it preserves that
hashcode order in case of unrelated objects
> disjoint() does not work correctly if objects don't implement Comparable
>
>
> Key: GROOVY-7530
> URL: https://issues.apache.org/jira/browse/GROOVY-7530
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.4
>Reporter: Tobias Ahlers
>
> {code:java}
> class Foo {
> private String name
> Foo(String name) {
> this.name = name
> }
> public boolean equals(Object o) {
> if (this == o) return true
> if (o == null || getClass() != o.getClass()) return false
> Foo that = (Foo) o
> return Objects.equals(name, that.name)
> }
> public int hashCode() {
> return Objects.hash(name)
> }
> }
> def a = [new Foo("foo")]
> def b = [new Foo("foo")]
> assert !a.disjoint(b)
> {code}
> If disjoint() is used on a list with objects not implementing Comparable the
> wrong result is returned.
> intersect() shows the same wrong behavior.
> It's looks like the NumberAwareComparator not implementing the equals case as
> of commit 286532c is the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7530) disjoint() does not work correctly if objects don't implement Comparable
[
https://issues.apache.org/jira/browse/GROOVY-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7530:
-
Fix Version/s: 2.5.0-beta-1
> disjoint() does not work correctly if objects don't implement Comparable
>
>
> Key: GROOVY-7530
> URL: https://issues.apache.org/jira/browse/GROOVY-7530
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.4
>Reporter: Tobias Ahlers
> Fix For: 2.5.0-beta-1
>
>
> {code:java}
> class Foo {
> private String name
> Foo(String name) {
> this.name = name
> }
> public boolean equals(Object o) {
> if (this == o) return true
> if (o == null || getClass() != o.getClass()) return false
> Foo that = (Foo) o
> return Objects.equals(name, that.name)
> }
> public int hashCode() {
> return Objects.hash(name)
> }
> }
> def a = [new Foo("foo")]
> def b = [new Foo("foo")]
> assert !a.disjoint(b)
> {code}
> If disjoint() is used on a list with objects not implementing Comparable the
> wrong result is returned.
> intersect() shows the same wrong behavior.
> It's looks like the NumberAwareComparator not implementing the equals case as
> of commit 286532c is the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7621) Memory Leak (metaClassRegistry) unable to remove metaClass based on instances
[ https://issues.apache.org/jira/browse/GROOVY-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091664#comment-15091664 ] Jochen Theodorou commented on GROOVY-7621: -- Is script not a GroovyObject? Because in this case (and actually in any other case as well) script.metaClass = null is supposed to delete the per instance meta class. And if you want to use the registry... There is a setMetaClass(Object,MetaClass) method, which you can give a null meta class, to remove the per instance meta class for that object. And you could use the iterator to remove the per instance meta class by calling remove once you have reached the entry. But script.metaClass = null, and this Iterator.remove are both using MetaClassRegistryImpl.setMetaClass(Object,MetaClass) to remove the per instance meta class for a non-GroovyObject class. For a GroovyObject implementing class you have the meta class stored directly on that instance, but then of course it is collected with the instance as well > Memory Leak (metaClassRegistry) unable to remove metaClass based on instances > - > > Key: GROOVY-7621 > URL: https://issues.apache.org/jira/browse/GROOVY-7621 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.3.7 > Environment: Running from Eclipse, JBoss with jdk 1.6 >Reporter: Kimball C Sampson > > I'm using the GroovyScriptEngine in a web server environment where the > scripts are provided properties on-the-fly from database objects. This is > done by implementing script.metaClass.propertyMissing. When I return a > value, I set the metaClass to give the returned value even more > sub-properties. After processing 100k records or so, I run out of memory. I > tried to write code to remove entries from the metaClassRepository, but > there's no way to do it for an object instanced based metaClass. Also, I've > outputed the GroovySystem.metaClassRepository.iterator().size() and it kept > growing. The values are out of scope so they should get garbage collected, > but the metaClasses aren't getting cleaned up. > The workaround to this problem was to implement a groovy Proxy, though, I > liked the metaClass solution better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (GROOVY-7709) NPE with ConvertedClosure
[
https://issues.apache.org/jira/browse/GROOVY-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reopened GROOVY-7709:
--
the issue was not fixed by PR 237, was it?
> NPE with ConvertedClosure
> -
>
> Key: GROOVY-7709
> URL: https://issues.apache.org/jira/browse/GROOVY-7709
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5
>Reporter: Jochen Theodorou
> Fix For: 2.4.6
>
>
> {code}
> interface Y extends GroovyObject {}
> def cl = {println 1} as Y
> assert cl instanceof GroovyObject
> if (cl) println "!cl"
> {code}
> the code above will cause the execution of the method getMetaClass in the
> boolean part of the "if". It looks like this code path now produces a NPE
> {code}
> java.lang.NullPointerException
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:919)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:902)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToBoolean(DefaultTypeTransformation.java:185)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.booleanUnbox(DefaultTypeTransformation.java:74){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7105) Oracle Thin Driver Fails with an Exception in Groovy 2.3.x
[
https://issues.apache.org/jira/browse/GROOVY-7105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097978#comment-15097978
]
Jochen Theodorou commented on GROOVY-7105:
--
The problem is that there is a jar, with classes, requiring other classes and
those classes are not there. In Java this might not be a problem, because there
the order in which classes are loaded is well known enough to be sure, that
those missing classes are never requested, unless certain features are used.
Well... groovy has to do things different. I am perfectly fine with the
try-catch PR, but it is not the case that Groovy does wrong classloading or
anything like that here. There are many scenarios in which a construct like
that can blow up
> Oracle Thin Driver Fails with an Exception in Groovy 2.3.x
> --
>
> Key: GROOVY-7105
> URL: https://issues.apache.org/jira/browse/GROOVY-7105
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk, SQL processing
>Affects Versions: 2.3.0
>Reporter: Charlie Hubbard
>Priority: Blocker
>
> Trying to load the Oracle driver in Groovy fails with the following error:
> java.lang.NoClassDefFoundError: oracle/xdb/XMLType
> at java_sql_Connection$getMetaData.call(Unknown Source)
> at db_test.printMetaData(db_test.groovy:9)
> at db_test.printMetaData(db_test.groovy)
> at db_test$printMetaData$0.callCurrent(Unknown Source)
> at db_test.run(db_test.groovy:45)
> Caused by: java.lang.ClassNotFoundException: oracle.xdb.XMLType
> ... 5 more
> This works in Groovy 2.1.x. This is loading the thin driver which doesn't
> require extra libraries. It appears that Groovy loads Oracle's OCI driver
> which requires these additional jar files and fails.
> {code}
> import groovy.sql.Sql
> import java.sql.ResultSet
> import java.sql.DatabaseMetaData
> void printMetaData( Sql sql, catalog = null, schema = null ) {
> try {
> DatabaseMetaData metadata = sql.connection.getMetaData()
>
> ResultSet rs = metadata.getCatalogs()
> while( rs.next() ) {
>String catalogName = rs.getString("TABLE_CAT")
>println("${catalogName}")
> }
> rs.close()
>
> rs = metadata.getSchemas()
> while( rs.next() ) {
>String catalogName = rs.getString("TABLE_CAT")
>String schemaName = rs.getString("TABLE_SCHEM")
>
>println("${catalogName}.${schemaName}")
> }
> rs.close()
>
> def types = [ "TABLE" ]
> rs = metadata.getTables( catalog, schema, null, types.toArray( new
> String[types.size()]) )
> while( rs.next() ) {
>String catalogName = rs.getString("TABLE_CAT")
>String schemaName = rs.getString("TABLE_SCHEM")
>String tableName = rs.getString("TABLE_NAME")
>println("${catalogName}.${schemaName}.${tableName}")
> }
> rs.close()
> } finally {
> sql.close()
> }
> }
> oracle = Sql.newInstance("jdbc:oracle:thin:@//localhost:1521/PDB1",
> "someUser", "somePassword", "oracle.jdbc.driver.OracleDriver")
> printMetaData( oracle )
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-7709) NPE with ConvertedClosure
[
https://issues.apache.org/jira/browse/GROOVY-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-7709.
--
Resolution: Fixed
ah sorry, my mistake
> NPE with ConvertedClosure
> -
>
> Key: GROOVY-7709
> URL: https://issues.apache.org/jira/browse/GROOVY-7709
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5
>Reporter: Jochen Theodorou
> Fix For: 2.4.6
>
>
> {code}
> interface Y extends GroovyObject {}
> def cl = {println 1} as Y
> assert cl instanceof GroovyObject
> if (cl) println "!cl"
> {code}
> the code above will cause the execution of the method getMetaClass in the
> boolean part of the "if". It looks like this code path now produces a NPE
> {code}
> java.lang.NullPointerException
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:919)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:902)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToBoolean(DefaultTypeTransformation.java:185)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.booleanUnbox(DefaultTypeTransformation.java:74){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-3683) groovyc can't joint compile a Java class that uses a delegate method from a Groovy class with an @Delegate property annotation
[
https://issues.apache.org/jira/browse/GROOVY-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-3683:
-
Issue Type: Bug (was: Sub-task)
Parent: (was: GROOVY-4579)
> groovyc can't joint compile a Java class that uses a delegate method from a
> Groovy class with an @Delegate property annotation
> --
>
> Key: GROOVY-3683
> URL: https://issues.apache.org/jira/browse/GROOVY-3683
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Stub generator / Joint compiler
>Affects Versions: 1.6.4
> Environment: OS X Leopard w/ Java JDK 1.6.0
>Reporter: Scott Murphy
>
> {code:title=Test.groovy}
> class Test {
> @Delegate TestDelegate test = new TestDelegate(name:"Scott")
> }
> class TestDelegate { String name }
> {code}
> {code:title=TestRun.java}
> public class TestRun {
> public static void main(String args[]) {
> System.out.println(new Test().getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-4579) Integrate the Eclipse compiler as optional module
[ https://issues.apache.org/jira/browse/GROOVY-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-4579. -- Resolution: Won't Fix Fix Version/s: (was: 2.x) given the current story it is not likely to happen anymore. Instead a joint compilation based on an existing java parser with much less footprint that eclipse is the target now. Thus I close this > Integrate the Eclipse compiler as optional module > - > > Key: GROOVY-4579 > URL: https://issues.apache.org/jira/browse/GROOVY-4579 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Jochen Theodorou > > Integration of the eclipse compiler will allow many transform related issues > to be solved -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7732) NioGroovyMethods compiled for java 7 in non-indy groovy
[ https://issues.apache.org/jira/browse/GROOVY-7732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107591#comment-15107591 ] Jochen Theodorou commented on GROOVY-7732: -- I don't think this part is really using complicated classloading magic. it is a plugin mechanism that is used here. groovy-nio defines extension methods, which are loaded at startup. If the methods cannot be loaded because of for example the wrong jdk version, the extension methods are not loaded. So Groovy may want to load jdk7 classes through loading the nio extension module, but on jdk6, groovy will end up ignoring the module. Of course things are different if you statically compiler against that extension methods, but then you cannot expect that groovy program to run under jdk6 as well. Those java.lang.UnsupportedClassVersionError should be logging messages and should actually also show something about the name of the module that was tried to load. Most simple solution, exclude groovy-nio from the build. But as I said, besides the log messages there should be no other effect > NioGroovyMethods compiled for java 7 in non-indy groovy > --- > > Key: GROOVY-7732 > URL: https://issues.apache.org/jira/browse/GROOVY-7732 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.4.5 > Environment: jdk 1.6u45 > groovy-all-2.3.x.jar or groovy-all-2.4.x.jar >Reporter: Rafael Gonçalves Sampaio >Priority: Minor > Labels: groovy-all > > As per docs non-indy versions of groovy requires jvm 1.6, but this error is > being issued when running a jasper report compiled with groovy versions above > 2.2.2. using java 6. Report is still shown but lots of verbose in log. > java.lang.UnsupportedClassVersionError: > org/codehaus/groovy/runtime/NioGroovyMethods : Unsupported major.minor > version 51.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7732) NioGroovyMethods compiled for java 7 in non-indy groovy
[ https://issues.apache.org/jira/browse/GROOVY-7732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110281#comment-15110281 ] Jochen Theodorou commented on GROOVY-7732: -- Well, so far we have been defining something as requirement in terms of "does no longer run if not fulfilled". It does work with JDK6 though. In that sense JDK7 is no requirement. We could extend the table maybe and mention nio there directly. What do you think? > NioGroovyMethods compiled for java 7 in non-indy groovy > --- > > Key: GROOVY-7732 > URL: https://issues.apache.org/jira/browse/GROOVY-7732 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.4.5 > Environment: jdk 1.6u45 > groovy-all-2.3.x.jar or groovy-all-2.4.x.jar >Reporter: Rafael Gonçalves Sampaio >Priority: Minor > Labels: groovy-all > > As per docs non-indy versions of groovy requires jvm 1.6, but this error is > being issued when running a jasper report compiled with groovy versions above > 2.2.2. using java 6. Report is still shown but lots of verbose in log. > java.lang.UnsupportedClassVersionError: > org/codehaus/groovy/runtime/NioGroovyMethods : Unsupported major.minor > version 51.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7061) Type inference not working for Collections.sort()
[
https://issues.apache.org/jira/browse/GROOVY-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110379#comment-15110379
]
Jochen Theodorou commented on GROOVY-7061:
--
I would have expected the compiler failing with a failure about the method not
being found, if the interface really was not considered being a SAM class.
> Type inference not working for Collections.sort()
> -
>
> Key: GROOVY-7061
> URL: https://issues.apache.org/jira/browse/GROOVY-7061
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.3.6, 2.4.5
>Reporter: Peter Ledbrook
>
> In this example:
> {code}
> import groovy.transform.TypeChecked
> doIt()
> @TypeChecked
> void doIt() {
> List nums = [1, 2, 3, -2, -5, 6]
> //nums.sort { a, b -> a.abs() <=> b.abs() }
> Collections.sort(nums, { a, b -> a.abs() <=> b.abs() })
> }
> {code}
> the type checking fails on the closure arguments (no method {{abs()}} on type
> {{Object}}). Interestingly, it works fine for the line that's commented out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-7738) BUG! exception in phase 'semantic analysis' in source unit
[
https://issues.apache.org/jira/browse/GROOVY-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-7738.
--
Resolution: Cannot Reproduce
Assignee: Jochen Theodorou
first what the error means: while resolving classes during the compilation of a
script, we did do a class loader based lookup, and this lookup failed with a
compilation error, because the class loader did cause a compilation on its own.
This is bad, because this has big problems with class duplication and circular
reference. So we added a logic, which will do a special class loading, which
excludes further automated compilation ... instead the new source is then
queued into the current compilation process.
So this means to me a parent of the classloader used for lookups is also a
GroovyClassLoader, set to automatically compile scripts -> bad, wrong setup.
And also means no bug in Groovy. If that is due to the setup of your
environment as provided by soap UI, then it is a bug in soap UI, not Groovy. if
that is due to your own setup, then you can ask for advice, if you can show
describe us your setup. But without that information I already gave all the
advice I can. But all in all, this is no Groovy bug as far as I can tell
> BUG! exception in phase 'semantic analysis' in source unit
> --
>
> Key: GROOVY-7738
> URL: https://issues.apache.org/jira/browse/GROOVY-7738
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.1.7
>Reporter: harrry
>Assignee: Jochen Theodorou
>
> we have a project developed in groovy using 1.8.0 using SOAPUI 5.1.2. I
> migrated the project from SoapUI 5.1.2 to Ready API 1.2.2 which has groovy
> groovy-all 2.1.7.jar. Ready API 1.2.2 is no more compatible with groovy
> 1.8.0.So, I was using groovy -all 2.1.7 jar but when I run my script I was
> getting the below error:-
> {noformat}
> Fri Jan 29 10:12:28 EST 2016:ERROR:cannot get error line number!
> Fri Jan 29 10:12:28 EST 2016:ERROR:java.lang.IllegalStateException: No match
> found
>java.lang.IllegalStateException: No match found
> at java.util.regex.Matcher.group(Unknown Source)
> at
> com.eviware.soapui.support.GroovyUtils.extractErrorLineNumber(GroovyUtils.java:132)
> at
> com.eviware.soapui.impl.wsdl.teststeps.WsdlGroovyScriptTestStep.run(WsdlGroovyScriptTestStep.java:164)
> at
> com.eviware.soapui.impl.wsdl.panels.teststeps.GroovyScriptStepDesktopPanel$RunAction$1.run(GroovyScriptStepDesktopPanel.java:263)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Fri Jan 29 10:12:28 EST 2016:ERROR:BUG! exception in phase 'semantic
> analysis' in source unit 'Script5.groovy' The lookup for
> dbUtils_TargetApi.TGTQueries caused a failed compilaton. There should not
> have been any compilation from this call.
>BUG! exception in phase 'semantic analysis' in source unit
> 'Script5.groovy' The lookup for dbUtils_TargetApi.TGTQueries caused a failed
> compilaton. There should not have been any compilation from this call.
> at
> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:188)
> at
> org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:168)
> at
> org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:124)
> at
> org.codehaus.groovy.control.ResolveVisitor.resolveToOuter(ResolveVisitor.java:616)
> at
> org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:268)
> at
> org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:236)
> at
> org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:220)
> at
> org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:232)
> at
> org.codehaus.groovy.control.ResolveVisitor.transformConstructorCallExpression(ResolveVisitor.java:969)
> at
> org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:646)
> at
> org.codehaus.groovy.control.ResolveVisitor.transformDeclarationExpression(ResolveVisitor.java:1010)
> at
> org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:638)
> at
> org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:139)
> at
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorS
[jira] [Updated] (GROOVY-7741) StackoverflowError with Closure and CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7741:
-
Component/s: Static compilation
> StackoverflowError with Closure and CompileStatic
> -
>
> Key: GROOVY-7741
> URL: https://issues.apache.org/jira/browse/GROOVY-7741
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.5
>Reporter: Gerhard Langs
>
> run the code below - it fails with a stackoverflow:
> {code}
> $ groovy ClosureStackOverflow.groovy
> Caught: java.lang.StackOverflowError
> java.lang.StackOverflowError
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> {code}
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class ClosureStackOverflow {
> Closure addTextClosure = { "xx" }
> void f()
> {
> List nodes = [ "sth" ]
> nodes.each {
> // here we get the overflow:
> addTextClosure()
> }
> }
> static void main(String[] args) {
> new ClosureStackOverflow().f()
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7741) StackoverflowError with Closure and CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15125356#comment-15125356
]
Jochen Theodorou commented on GROOVY-7741:
--
I can verify this bug happens and it happens only with static compilation
enabled
> StackoverflowError with Closure and CompileStatic
> -
>
> Key: GROOVY-7741
> URL: https://issues.apache.org/jira/browse/GROOVY-7741
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.5
>Reporter: Gerhard Langs
>
> run the code below - it fails with a stackoverflow:
> {code}
> $ groovy ClosureStackOverflow.groovy
> Caught: java.lang.StackOverflowError
> java.lang.StackOverflowError
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> {code}
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class ClosureStackOverflow {
> Closure addTextClosure = { "xx" }
> void f()
> {
> List nodes = [ "sth" ]
> nodes.each {
> // here we get the overflow:
> addTextClosure()
> }
> }
> static void main(String[] args) {
> new ClosureStackOverflow().f()
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7744) static import of multiple methods with same name
[
https://issues.apache.org/jira/browse/GROOVY-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130297#comment-15130297
]
Jochen Theodorou commented on GROOVY-7744:
--
expected? kind of. Groovy cannot resolve this kind of situation without static
compilation. to know which method to use exactly, you need to know the
signature of the call exactly as well. And that is an information that is
currently not available in Groovy. With the ideas I have for Groovy 3 we might
be able to resolve the problem, but in today's Groovy I see no chance. So what
is the alternative? Leave it as is? Produce an error message? If we produce an
error message, do we want to not do it if static compilation is in use?
> static import of multiple methods with same name
>
>
> Key: GROOVY-7744
> URL: https://issues.apache.org/jira/browse/GROOVY-7744
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Affects Versions: 2.4.5
>Reporter: Cazacu Mihai
>
> Hi,
> Please take a look at this code:
> {code:title=test.groovy|borderStyle=solid}
> import groovy.transform.CompileStatic
> import static A1.a // as a1
> import static A2.a // as a2
> import static A3.a // as a3
> @CompileStatic
> class A1 {
> static void a(String str) { println 'a1' }
> }
> @CompileStatic
> class A2 {
> static void a(int i) { println 'a2' }
> }
> @CompileStatic
> class A3 {
> static void a(boolean b) { println 'a3' }
> }
> a("string")
> a(1)
> a(true)
> {code}
> Running it, a compile exception is thrown:
> {quote}
> Caught: groovy.lang.MissingMethodException: No signature of method: static
> A3.a() is applicable for argument types: (java.lang.String) values: [string]
> Possible solutions: a(boolean), any(), any(groovy.lang.Closure),
> is(java.lang.Object), wait(), wait(long)
> groovy.lang.MissingMethodException: No signature of method: static A3.a() is
> applicable for argument types: (java.lang.String) values: [string]
> Possible solutions: a(boolean), any(), any(groovy.lang.Closure),
> is(java.lang.Object), wait(), wait(long)
> {quote}
> It seems that the latest import overwrites the previous ones.
> Is this the expected behavior in Groovy (Java allows this syntax)?
> Best regards,
> Mihai
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7748) SAM & @CompileStatic failure
[
https://issues.apache.org/jira/browse/GROOVY-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7748:
-
Component/s: Static Type Checker
> SAM & @CompileStatic failure
>
>
> Key: GROOVY-7748
> URL: https://issues.apache.org/jira/browse/GROOVY-7748
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Maxim Medvedev
>
> Groovyc fails to compile SAM coercion used in variable declaration
> {code}
> interface Function {
> I fun(D dom)
> }
> class A{}; class B{}
> @CompileStatic
> void sample() {
> Function f = {A dom -> return new B() } //compilation fails here
> }
> void bar(Function fun) {}
> @CompileStatic
> void sample2() {
> bar {A dom -> return new B() } //compiles & runs ok
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7748) SAM & @CompileStatic failure
[
https://issues.apache.org/jira/browse/GROOVY-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131969#comment-15131969
]
Jochen Theodorou commented on GROOVY-7748:
--
The error message is {code}[Static type checking] - Incompatible generic
argument types. Cannot assign Function to: Function
{code}
> SAM & @CompileStatic failure
>
>
> Key: GROOVY-7748
> URL: https://issues.apache.org/jira/browse/GROOVY-7748
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Maxim Medvedev
>
> Groovyc fails to compile SAM coercion used in variable declaration
> {code}
> interface Function {
> I fun(D dom)
> }
> class A{}; class B{}
> @CompileStatic
> void sample() {
> Function f = {A dom -> return new B() } //compilation fails here
> }
> void bar(Function fun) {}
> @CompileStatic
> void sample2() {
> bar {A dom -> return new B() } //compiles & runs ok
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7749) Cannot using maven shading because of Extension Modules Check
[ https://issues.apache.org/jira/browse/GROOVY-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132802#comment-15132802 ] Jochen Theodorou commented on GROOVY-7749: -- And how exactly should it behave? > Cannot using maven shading because of Extension Modules Check > - > > Key: GROOVY-7749 > URL: https://issues.apache.org/jira/browse/GROOVY-7749 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.4.5 >Reporter: Marc Hadfield > > groovy checks at init time whether there is another groovy on the classpath, > and exits with an error if so. > this prevents using maven shading (and similar techniques) to combine > multiple versions of jars into a single distribution. > the specific exception thrown comes from here: > https://github.com/apache/groovy/blob/master/src/main/org/codehaus/groovy/runtime/metaclass/MetaClassRegistryImpl.java#L511 > this problem occurs often in Hadoop and Spark jobs where multiple versions of > Groovy may appear. Specifically in Apache Spark 1.6.0, groovy 2.1.6 is > embedded. > A solution would require modifications to how the scans for things like: > "META-INF/services/org.codehaus.groovy.runtime.ExtensionModule" work so that > maven shading can merge multiple groovys together. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7500) Problem With Runtime Metaprogramming Over A Trait Method
[
https://issues.apache.org/jira/browse/GROOVY-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139171#comment-15139171
]
Jochen Theodorou commented on GROOVY-7500:
--
yes
> Problem With Runtime Metaprogramming Over A Trait Method
>
>
> Key: GROOVY-7500
> URL: https://issues.apache.org/jira/browse/GROOVY-7500
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Jeff Scott Brown
> Attachments: metaprogramovertrait.zip
>
>
> It looks like I cannot runtime metaprogram over a trait method.
> The attached metaprogramovertrait.zip file contains the following:
> {code:title=src/main/groovy/demo/SomeClass.groovy}
> package demo
> class SomeClass implements SomeTrait {}
> {code}
> {code:title=src/main/groovy/demo/SomeTrait.groovy}
> package demo
> trait SomeTrait {
> void someMethod() {
> }
> }
> {code}
> {code:title=src/test/groovy/demo/SomeClassSpec.groovy}
> package demo
> import spock.lang.Specification
> class SomeClassSpec extends Specification {
> void 'test something'() {
> given:
> SomeClass.metaClass.someMethod = { ->
> throw new UnsupportedOperationException()
> }
> when:
> new SomeClass().someMethod()
> then:
> UnsupportedOperationException ex = thrown()
> }
> }
> {code}
> If I remove the method from the trait, the test passes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7600) @Immutable support for Optional?
[
https://issues.apache.org/jira/browse/GROOVY-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148198#comment-15148198
]
Jochen Theodorou commented on GROOVY-7600:
--
I take out of this discussion so far, that we miss a way to express "immutable
if the generics parameters are immutable". It is a difference to the
black/white look @Immutable currently has. And Optional is not the only case to
consider here. I think the same goes for a field of type List. In that case we
use a cloned unmodifiable List, but what is it worth, if the list elements are
still mutable?
> @Immutable support for Optional?
>
>
> Key: GROOVY-7600
> URL: https://issues.apache.org/jira/browse/GROOVY-7600
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.4.4
>Reporter: Christopher Smith
>
> The {{@Immutable}} transform does not have any particular understanding of
> {{java.util.Optional}}. The holder class itself is immutable, but the logical
> immutability depends on the contained type. It would be helpful for
> {{@Immutable}} to understand such holder types and do its sanity check on the
> generic type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7621) Memory Leak (metaClassRegistry) unable to remove metaClass based on instances
[ https://issues.apache.org/jira/browse/GROOVY-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148240#comment-15148240 ] Jochen Theodorou edited comment on GROOVY-7621 at 2/16/16 8:05 AM: --- Can we just close this bug at the 2.4.6 release? Or is there still something left to do? was (Author: blackdrag): Can we just close this bug, at the 2.4.6 release? Or is there still something left to do? > Memory Leak (metaClassRegistry) unable to remove metaClass based on instances > - > > Key: GROOVY-7621 > URL: https://issues.apache.org/jira/browse/GROOVY-7621 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.3.7 > Environment: Running from Eclipse, JBoss with jdk 1.6 >Reporter: Kimball C Sampson > > I'm using the GroovyScriptEngine in a web server environment where the > scripts are provided properties on-the-fly from database objects. This is > done by implementing script.metaClass.propertyMissing. When I return a > value, I set the metaClass to give the returned value even more > sub-properties. After processing 100k records or so, I run out of memory. I > tried to write code to remove entries from the metaClassRepository, but > there's no way to do it for an object instanced based metaClass. Also, I've > outputed the GroovySystem.metaClassRepository.iterator().size() and it kept > growing. The values are out of scope so they should get garbage collected, > but the metaClasses aren't getting cleaned up. > The workaround to this problem was to implement a groovy Proxy, though, I > liked the metaClass solution better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7621) Memory Leak (metaClassRegistry) unable to remove metaClass based on instances
[ https://issues.apache.org/jira/browse/GROOVY-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148240#comment-15148240 ] Jochen Theodorou commented on GROOVY-7621: -- Can we just close this bug, at the 2.4.6 release? Or is there still something left to do? > Memory Leak (metaClassRegistry) unable to remove metaClass based on instances > - > > Key: GROOVY-7621 > URL: https://issues.apache.org/jira/browse/GROOVY-7621 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.3.7 > Environment: Running from Eclipse, JBoss with jdk 1.6 >Reporter: Kimball C Sampson > > I'm using the GroovyScriptEngine in a web server environment where the > scripts are provided properties on-the-fly from database objects. This is > done by implementing script.metaClass.propertyMissing. When I return a > value, I set the metaClass to give the returned value even more > sub-properties. After processing 100k records or so, I run out of memory. I > tried to write code to remove entries from the metaClassRepository, but > there's no way to do it for an object instanced based metaClass. Also, I've > outputed the GroovySystem.metaClassRepository.iterator().size() and it kept > growing. The values are out of scope so they should get garbage collected, > but the metaClasses aren't getting cleaned up. > The workaround to this problem was to implement a groovy Proxy, though, I > liked the metaClass solution better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GROOVY-7621) Memory Leak (metaClassRegistry) unable to remove metaClass based on instances
[ https://issues.apache.org/jira/browse/GROOVY-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou updated GROOVY-7621: - Fix Version/s: 2.4.6 > Memory Leak (metaClassRegistry) unable to remove metaClass based on instances > - > > Key: GROOVY-7621 > URL: https://issues.apache.org/jira/browse/GROOVY-7621 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.3.7 > Environment: Running from Eclipse, JBoss with jdk 1.6 >Reporter: Kimball C Sampson > Fix For: 2.4.6 > > > I'm using the GroovyScriptEngine in a web server environment where the > scripts are provided properties on-the-fly from database objects. This is > done by implementing script.metaClass.propertyMissing. When I return a > value, I set the metaClass to give the returned value even more > sub-properties. After processing 100k records or so, I run out of memory. I > tried to write code to remove entries from the metaClassRepository, but > there's no way to do it for an object instanced based metaClass. Also, I've > outputed the GroovySystem.metaClassRepository.iterator().size() and it kept > growing. The values are out of scope so they should get garbage collected, > but the metaClasses aren't getting cleaned up. > The workaround to this problem was to implement a groovy Proxy, though, I > liked the metaClass solution better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7601) shallow parameter for @Immutable
[
https://issues.apache.org/jira/browse/GROOVY-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148251#comment-15148251
]
Jochen Theodorou commented on GROOVY-7601:
--
Frankly, I would like to have a different transform for this like @Final...
on the other hand, why not just make the fields and class final, and apply
@Canonical to the class instead? You would then still not implement Immutable,
but do you even wish for that?
> shallow parameter for @Immutable
>
>
> Key: GROOVY-7601
> URL: https://issues.apache.org/jira/browse/GROOVY-7601
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.4.4
>Reporter: Christopher Smith
>
> I am using {{@Immutable}} for some command objects, where some of the fields
> are sometimes-complex domain objects. In this case, I don't need deep
> immutability for semantic correctness, and it would be helpful to have a
> parameter to indicate that the transform shouldn't bother checking the
> fields' types, just make them final and generate the appropriate methods:
> {code}
> @Immutable(shallow = true)
> class PayCommand {
> Invoice invoice
> Money amount
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7762) Static inner classes not visible to child classes
[
https://issues.apache.org/jira/browse/GROOVY-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158404#comment-15158404
]
Jochen Theodorou commented on GROOVY-7762:
--
If it works if in the same CompilationUnit, but not if X is precompiled, then
this means the inner classes list in the ClassNode for X is not filled
correctly (probably not at all)
> Static inner classes not visible to child classes
> -
>
> Key: GROOVY-7762
> URL: https://issues.apache.org/jira/browse/GROOVY-7762
> Project: Groovy
> Issue Type: Sub-task
> Components: class generator
>Affects Versions: 2.1.6, 2.2.0-beta-1, 2.1.7, 2.2.0, 2.4.0-beta-3
>Reporter: Kenneth Gendron
>
> If both the parent class and the child are in the same file or project (i.e.
> they are being compiled together), this works; however, if the parent is
> compiled into a separate JAR, the child class is unable to see the parents
> inner classes.
> Example:
> {code}class X {
> static class Y {}
> }{code}
> Compile X into a separate JAR.
> {code}class Z extends X {
> Z() {
> Y y = new Y();
> }
> }{code}
> Compiling Z will cause an error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7763) Various problems with type inference in Groovy 2.4.6
[ https://issues.apache.org/jira/browse/GROOVY-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159182#comment-15159182 ] Jochen Theodorou commented on GROOVY-7763: -- to explain the problem a bit more If you use the literal list, you cannot specify the type of it correctly, thus we have special logic for the literal list to obey an relaxed check. Then you can do List l = [new X()], with X extends Y, even though this would normally fail. And it looks like some of the numerous changes been made changed also the behaviour of these literals. And while we do have special logic for the assignment case, we had next to no logic for the return case at all. After GROOVY-7598 we have now logic for the return case, but no special handling of literal lists (and I assume we have the same problem with maps). So in other words, this must be added. > Various problems with type inference in Groovy 2.4.6 > > > Key: GROOVY-7763 > URL: https://issues.apache.org/jira/browse/GROOVY-7763 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.6 >Reporter: Graeme Rocher >Priority: Critical > > After trying to upgrade Grails to Groovy 2.4.6 there are numerous problems > with @CompileStatic and type inference with Maps and Lists. If I had seen the > vote for the release in time I would have tested and voted -1, so sorry for > only reporting this afterwards. > This commits shows the changes I had to make in order to get Grails to > compile with Groovy 2.4.6: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8 > You can see for example that previously returning a list initialised with > variables of the correct type compiled, but no longer does: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-3092a650525dc131a0394eca4282362bL35 > Also empty lists and maps no longer seem to compile. See: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-07f8418b033d870eee3c1cee97e44f4cL121 > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-15a1d1d639cada3a0c85c7200547db02L40 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GROOVY-7767) Single-parameter method chosen zero parameters passed
[
https://issues.apache.org/jira/browse/GROOVY-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7767:
-
Issue Type: Sub-task (was: Bug)
Parent: GROOVY-2503
> Single-parameter method chosen zero parameters passed
> -
>
> Key: GROOVY-7767
> URL: https://issues.apache.org/jira/browse/GROOVY-7767
> Project: Groovy
> Issue Type: Sub-task
>Affects Versions: 2.4.6
>Reporter: Mike Martin
>
> When there is a single variant of a given method name, and that method has a
> single parameter, then calls to that method with zero arguments will result
> in a call to the method with a value of {{null}}, even though the no argument
> is present in the actual method call. This is surprising and leads to silent
> errors. Instead, I would expect groovy to throw an error saying that no
> matching method could be found.
> Example:
> {code}
> new A()
> class A {
> A(){
> m()
> }
> void m(String param){
> println "param: $param"
> }
> }
> {code}
> Running the code above yields:
> {code}
> param: null
> {code}
> But I would expect it to yield something like:
> {code}
> Caught: groovy.lang.MissingMethodException: No signature of method: A.m() is
> applicable for argument types: () values: []
> Possible solutions: m(java.lang.String), is(java.lang.Object), dump(), any(),
> any(groovy.lang.Closure), use([Ljava.lang.Object;)
> groovy.lang.MissingMethodException: No signature of method: A.m() is
> applicable for argument types: () values: []
> Possible solutions: m(java.lang.String), is(java.lang.Object), dump(), any(),
> any(groovy.lang.Closure), use([Ljava.lang.Object;)
> at A.(testClass2.groovy:8)
> at testClass2.run(testClass2.groovy:3)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7767) Single-parameter method chosen zero parameters passed
[
https://issues.apache.org/jira/browse/GROOVY-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15166943#comment-15166943
]
Jochen Theodorou commented on GROOVY-7767:
--
I am pretty sure we have an issue for this already somewhere. The current MOP
defines this behaviour, so it is really intended to work like that. But for the
uncertain-when-to-come MOP 2 we do intend to change this. To document that and
ensure it is not forgotten, I made this a subtask of a MOP 2 collections task.
Should I find the original issue, I may close this one here as duplicate though
> Single-parameter method chosen zero parameters passed
> -
>
> Key: GROOVY-7767
> URL: https://issues.apache.org/jira/browse/GROOVY-7767
> Project: Groovy
> Issue Type: Sub-task
>Affects Versions: 2.4.6
>Reporter: Mike Martin
>
> When there is a single variant of a given method name, and that method has a
> single parameter, then calls to that method with zero arguments will result
> in a call to the method with a value of {{null}}, even though the no argument
> is present in the actual method call. This is surprising and leads to silent
> errors. Instead, I would expect groovy to throw an error saying that no
> matching method could be found.
> Example:
> {code}
> new A()
> class A {
> A(){
> m()
> }
> void m(String param){
> println "param: $param"
> }
> }
> {code}
> Running the code above yields:
> {code}
> param: null
> {code}
> But I would expect it to yield something like:
> {code}
> Caught: groovy.lang.MissingMethodException: No signature of method: A.m() is
> applicable for argument types: () values: []
> Possible solutions: m(java.lang.String), is(java.lang.Object), dump(), any(),
> any(groovy.lang.Closure), use([Ljava.lang.Object;)
> groovy.lang.MissingMethodException: No signature of method: A.m() is
> applicable for argument types: () values: []
> Possible solutions: m(java.lang.String), is(java.lang.Object), dump(), any(),
> any(groovy.lang.Closure), use([Ljava.lang.Object;)
> at A.(testClass2.groovy:8)
> at testClass2.run(testClass2.groovy:3)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7771) Exception driven control flow in groovy.lang.Script.getProperty()
[ https://issues.apache.org/jira/browse/GROOVY-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171738#comment-15171738 ] Jochen Theodorou commented on GROOVY-7771: -- This looks like a breaking change for 2.5, maybe even 3.0, or we have to reject the patch and close the issue as "Won't fix". So the question is if Binding does imply that everything you can get through getVariable has to be true for hasVariable and has to appear in getVariables, at any point in time or not. If yes, then we can no longer support variables created on use for example. > Exception driven control flow in groovy.lang.Script.getProperty() > - > > Key: GROOVY-7771 > URL: https://issues.apache.org/jira/browse/GROOVY-7771 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.6 >Reporter: Benjamin Graf >Assignee: Pascal Schumacher > > groovy.lang.Script.getProperty() calls Binding.getProperty() and does > therfore react on MissingPropertyException. This control flow is an > antipattern causing unnecessary Throwable.fillInStackTrace() calls which cost > cpu time. It might be better to check with Binding.hasProperty() first to > avoid Exception flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7771) Exception driven control flow in groovy.lang.Script.getProperty()
[ https://issues.apache.org/jira/browse/GROOVY-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172965#comment-15172965 ] Jochen Theodorou commented on GROOVY-7771: -- I think you misunderstand... The default for a Script is that the variable must be assigned to at least before it becomes available for a read. But by exchanging the Binding to one, that does something else, like creating the variable on first read and if there was no write yet, we get a different behaviour. If we start checking hasVariable, this won't work anymore. This would still work of course, but you get in trouble with getVariables, plus in that case you never have the exception problem. > Exception driven control flow in groovy.lang.Script.getProperty() > - > > Key: GROOVY-7771 > URL: https://issues.apache.org/jira/browse/GROOVY-7771 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.6 >Reporter: Benjamin Graf >Assignee: Pascal Schumacher > > groovy.lang.Script.getProperty() calls Binding.getProperty() and does > therfore react on MissingPropertyException. This control flow is an > antipattern causing unnecessary Throwable.fillInStackTrace() calls which cost > cpu time. It might be better to check with Binding.hasProperty() first to > avoid Exception flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-3583) Grape issues
[
https://issues.apache.org/jira/browse/GROOVY-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173457#comment-15173457
]
Jochen Theodorou commented on GROOVY-3583:
--
I see XercesImpl two times, two times from the grape directory... Does that
mean @Grap added it to the system loader and the root loader? Because that
would be wrong for sure
> Grape issues
>
>
> Key: GROOVY-3583
> URL: https://issues.apache.org/jira/browse/GROOVY-3583
> Project: Groovy
> Issue Type: Bug
> Components: Grape
>Affects Versions: 1.6.3
> Environment: jdk 1.5-06
> groovy 1.6.3
> WIndows xp
>Reporter: Keith Hyland
>Assignee: Paul King
> Fix For: 1.7-beta-2
>
>
> I have a simple piece of groovy for accessing a (oracle) DB.
> The code works fine once I include the jdbc jar in my $GROOVY_HOME/lib folder.
> However I would like to use grape to dynamically manage dependencies so I
> changed the code to below.
> {code}
> import groovy.grape.Grape
> Grape.grab(group:'oracle', module:'ojdbc14', version:'10.1.0.4.0' )
> import groovy.sql.Sql
> import java.sql.Time
> def db = Sql.newInstance("jdbc:oracle:thin:@flagtest.intmet.ie:1525:BEAM",
> "user", "password",
> "oracle.jdbc.driver.OracleDriver")
> {code}
> This results in
> {code}
> Caught: java.sql.SQLException: No suitable driver
> at t2.run(t2.groovy:8)
> {code}
> If I add the following import after the Grape.grab
> {code}
> import oracle.jdbc.driver.OracleDriver
> {code}
> I get the following
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed,
> C:\dev\t2.groovy: 4: unable to resolve class oracle.jdbc.driver.OracleDriver
> @ line 4, column 1.
>import oracle.jdbc.driver.OracleDriver;
>^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177138#comment-15177138
]
Jochen Theodorou edited comment on GROOVY-7772 at 3/3/16 4:21 AM:
--
I think I don't understand pattern number 3 actually... I would have thought
you are talking about something like this:{code:Java}
class X {
static foo(){}
}
def x = new X()
def m = x.&foo
m.call()
{code}but this does not fail, not dynamic compiled and not static compiled. The
meaning of x.&y() is in all cases always x.y(), be x a class, y a static method
or not and combinations of it. Which is why pattern 4 fails. What happens if we
see x.&y(args...) like a method taking X and args..., for which we curry (in
the Groovy sense) the first argument with x? In other words: x.&y becomes
{xarg, args... -> xarg.y(args)}.curry( x ), then all cases work like before,
because that is actually what we are doing (kind of). A more Java-like version
would be to have {xarg, args... -> if (y is static) X.y(args) else
xarg.y(args)}.curry( x ). Then all 4 cases would work.
was (Author: blackdrag):
I think I don't understand pattern number 3 actually... I would have thought
you are talking about something like this:{code:Java}
class X {
static foo(){}
}
def x = new X()
def m = x.&foo
m.call()
{code}but this does not fail, not dynamic compiled and not static compiled. The
meaning of x.&y() is in all cases always x.y(), be x a class, y a static method
or not and combinations of it. Which is why pattern 4 fails. What happens if we
see x.&y(args...) like a method taking X and args..., for which we curry (in
the Groovy sense) the first argument with x? In other words: x.&y becomes
{xarg, args... -> xarg.y(args)}.curry(x), then all cases work like before,
because that is actually what we are doing (kind of). A more Java-like version
would be to have {xarg, args... -> if (y is static) X.y(args) else
xarg.y(args)}.curry(x). Then all 4 cases would work.
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177138#comment-15177138
]
Jochen Theodorou commented on GROOVY-7772:
--
I think I don't understand pattern number 3 actually... I would have thought
you are talking about something like this:{code:Java}
class X {
static foo(){}
}
def x = new X()
def m = x.&foo
m.call()
{code}but this does not fail, not dynamic compiled and not static compiled. The
meaning of x.&y() is in all cases always x.y(), be x a class, y a static method
or not and combinations of it. Which is why pattern 4 fails. What happens if we
see x.&y(args...) like a method taking X and args..., for which we curry (in
the Groovy sense) the first argument with x? In other words: x.&y becomes
{xarg, args... -> xarg.y(args)}.curry(x), then all cases work like before,
because that is actually what we are doing (kind of). A more Java-like version
would be to have {xarg, args... -> if (y is static) X.y(args) else
xarg.y(args)}.curry(x). Then all 4 cases would work.
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reassigned GROOVY-7772:
Assignee: Jochen Theodorou
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177720#comment-15177720
]
Jochen Theodorou edited comment on GROOVY-7772 at 3/3/16 11:57 AM:
---
I would actually like to keep the outside face the same, meaning we create a
{xarg, args... ->}.curry( x ) every time. Instead I would like to change the
logic inside... but using your logic:
{code:Java}
{xarg, args... ->
if x instanceof Class && y is_not_static_method then
args[0].y(args[1..n])
else
xarg.y(args)
}{code}
was (Author: blackdrag):
I would actually like to keep the outside face the same, meaning we create a
{xarg, args... ->}.curry(x) every time. Instead I would like to change the
logic inside... but using your logic:
{code:Java}
{xarg, args... ->
if x instanceof Class && y is_not_static_method then
args[0].y(args[1..n])
else
xarg.y(args)
}{code}
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177720#comment-15177720
]
Jochen Theodorou commented on GROOVY-7772:
--
I would actually like to keep the outside face the same, meaning we create a
{xarg, args... ->}.curry(x) every time. Instead I would like to change the
logic inside... but using your logic:
{code:Java}
{xarg, args... ->
if x instanceof Class && y is_not_static_method then
args[0].y(args[1..n])
else
xarg.y(args)
}{code}
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179783#comment-15179783
]
Jochen Theodorou commented on GROOVY-7772:
--
what do you mean by extracted to the outside for y? You mean as String or do
you mean as some kind of method object? Because the later we cannot really do.
As for a String... that is what the current MethodClosure does already, the
static method check is done inside MethodClosure then.
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7044) Cloned NodeBuilder created nodes share values (child nodes) with original node.
[
https://issues.apache.org/jira/browse/GROOVY-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182779#comment-15182779
]
Jochen Theodorou commented on GROOVY-7044:
--
This PR requires a testcase
> Cloned NodeBuilder created nodes share values (child nodes) with original
> node.
> ---
>
> Key: GROOVY-7044
> URL: https://issues.apache.org/jira/browse/GROOVY-7044
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk, XML Processing
>Affects Versions: 2.3.6
>Reporter: Damir Perovi?
>Priority: Minor
> Attachments: NodeBuilderTest.groovy
>
>
> Cloning nodes created by NodeBuilder share child nodes with original node.
> If node is added to original node or child node value is changed, the cloned
> node will see those changes. Same applies to cloned node, adding node or
> changing child node value will be seen by original node.
> The problem seem to originate in NodeBuilder methods:
> {code}
> protected Object createNode(Object name)
> protected Object createNode(Object name, Map attributes)
> {code}
> which use ArrayList when creating new Node instead of NodeList.
> Can be easily reproduced by groovysh or use attached junit file.
> {noformat}
> groovy:000> x1 = new NodeBuilder().a() { b() }
> ===> a[attributes={}; value=[b[attributes={}; value=[
> groovy:000> x2 = x1.clone()
> ===> a[attributes={}; value=[b[attributes={}; value=[
> groovy:000> x1.appendNode('c')
> ===> c[attributes={}; value=[]]
> groovy:000> x1
> ===> a[attributes={}; value=[b[attributes={}; value=[]], c[attributes={};
> value=[
> groovy:000> x2
> ===> a[attributes={}; value=[b[attributes={}; value=[]], c[attributes={};
> value=[
> groovy:000> x1.b[0].setValue(1)
> ===> null
> groovy:000> x1
> ===> a[attributes={}; value=[b[attributes={}; value=1], c[attributes={};
> value=[
> groovy:000> x2
> ===> a[attributes={}; value=[b[attributes={}; value=1], c[attributes={};
> value=[
> groovy:000> x2.c[0].setValue(2)
> ===> null
> groovy:000> x1
> ===> a[attributes={}; value=[b[attributes={}; value=1], c[attributes={};
> value=2]]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182782#comment-15182782
]
Jochen Theodorou commented on GROOVY-7772:
--
Sure, I was probably not explaining cleanly enough... of course it is a virtual
call if it is a virtual method. On the JVM it is actually really difficult to
call P#method from outside, without meaning C#method
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185972#comment-15185972
]
Jochen Theodorou commented on GROOVY-7772:
--
I think there is one more point to clear:
{code:Java}
class X {
def m() {1}
def m(int i) {i+1}
}
def ref = new X().&m
assert ref() == 1
assert ref(1) == 2
assert ref.parameterTypes == [int]{code}
As you can imagine code like this would not be possible in Java. It also means.
The implementation guarantees, that the prameterTypes will be corresponding to
the longest signature. If multiple signatures of the same length exists, then a
random one might be taken. In similar fashion this imposes a problem for
determining if we do dispatch on a static method or not in your code. Imagine
for example m() being static and m(int) not, and the reference X.&m. The code
will make a setup for isStaticMethod=false and owner being a Class,
prameterTypes will become [X,int], a call X.&m(1) will incorrectly not work
according to the logic in doCall.
Actually the class has another big problem not caused by this change. If we do
a call to the MethodClosure from Groovy, the meta class logic will be used. But
if we do the call from Java, the logic in doCall will be used. They have to
stay in sync, to show the same effect, which is bad. Good would be one version
using the other. Now for efficiency reasons we have sometimes direct calls from
call to doCall. So at this point I would normally suggest making the class
final and remove the doCall method. call, goes to doCall dynamically, so the
logic in the meta class would still work out... but this would be a breaking
change.. So instead I would let doCall throw an Exception.
Then of course call should not be specified by MethodClosure at all. And of
course the decision if we do a dispatch based on the static method or not, with
an instance or a Class, must be completely in the MetaClassImpl part, you
already touched. But instead of blindly invoking, you will need to get the
MetaMethod and check. for the special case, to blindly invoke otherwise. This
of course also means MethodClosure would not have a isStaticMethod property as
well
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7790) Put the value in get method with default value
[
https://issues.apache.org/jira/browse/GROOVY-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-7790:
-
Description:
I'm not sure whether it was designed, but it seems to be weird.
{code:Java}
groovy> imap=['a':1, 'b':2]
groovy> if(imap.get('c',null)==null){ }
groovy> imap.each{k, v -> println "${k}:${v}" }
a:1
b:2
c:null
Result: [a:1, b:2, c:null]{code}
was:
I'm not sure whether it was designed, but it seems to be weird.
groovy> imap=['a':1, 'b':2]
groovy> if(imap.get('c',null)==null){ }
groovy> imap.each{k, v -> println "${k}:${v}" }
a:1
b:2
c:null
Result: [a:1, b:2, c:null]
> Put the value in get method with default value
> ---
>
> Key: GROOVY-7790
> URL: https://issues.apache.org/jira/browse/GROOVY-7790
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Reporter: Maoxiang Qian
>
> I'm not sure whether it was designed, but it seems to be weird.
> {code:Java}
> groovy> imap=['a':1, 'b':2]
> groovy> if(imap.get('c',null)==null){ }
> groovy> imap.each{k, v -> println "${k}:${v}" }
> a:1
> b:2
> c:null
> Result: [a:1, b:2, c:null]{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7790) Put the value in get method with default value
[
https://issues.apache.org/jira/browse/GROOVY-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15195657#comment-15195657
]
Jochen Theodorou commented on GROOVY-7790:
--
>From the javadoc of this method:{code}
* Looks up an item in a Map for the given key and returns the value -
unless
* there is no entry for the given key in which case add the default value
* to the map and return that.
{code}
So it behaves exactly like specified and intended. What is it you find weird?
That the map is touched?
> Put the value in get method with default value
> ---
>
> Key: GROOVY-7790
> URL: https://issues.apache.org/jira/browse/GROOVY-7790
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Reporter: Maoxiang Qian
>
> I'm not sure whether it was designed, but it seems to be weird.
> {code:Java}
> groovy> imap=['a':1, 'b':2]
> groovy> if(imap.get('c',null)==null){ }
> groovy> imap.each{k, v -> println "${k}:${v}" }
> a:1
> b:2
> c:null
> Result: [a:1, b:2, c:null]{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7772) Class.&instanceMethod had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201268#comment-15201268
]
Jochen Theodorou commented on GROOVY-7772:
--
let's concentrate on one point first, overloads...{code:Java}
for(MetaMethod m : methods) {
if (m.getParameterTypes().length > maximumNumberOfParameters) {
Class[] pt = m.getNativeParameterTypes();
maximumNumberOfParameters = pt.length;
parameterTypes = pt;
isStaticMethod = m.isStatic();
}
}
{code}
What happens if there are two methods of the same length?
maximumNumberOfParameters will have the right information still, but
parameterTypes might be one or the other, same for isStaticMethod. You can't be
sure which one is taken, since
InvokerHelper.getMetaClass(clazz).respondsTo(owner, method); does not guarantee
any order. This means that information is unstable. So if you have two methods
with the same number of parameters and the same name, You, as user, cannot be
sure which of those two will be taken into consideration for your
isStaticMethod based logic. You can see that already a bit when you look at
line 63 in MethodClosure in your PR. There you adjust the parameter types,
basically making it more for instance methods. But just before you had a loop
selecting on the length of these parameter types, and there static and
non-static was equal. Why is the non-static version not automatically longer in
the first loop already?
This then leads to line 77. If we cannot be sure that the partial method
selection through the logic before was right, then it is most probably wrong to
build on top of that information and do as if it was right. You see that
parameterTypes plays absolutely no role in doCall. But isStaticMethod is
equally bad. So instead of initializing the MethodClosure with this information.
I think we have to get the information new... That means get the metaclass, ask
it for a instance MetaMethod that fits the given arguments, change the
signature to the static version and ask for a fitting static method. If only
one of them exists, we have a candidate for our call. If both exist, then we
can call either the first or the second... or we produce a
MethodSelectionException. Of course there might be more than one method that
could respond in both cases... those are probably error cases as well
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7807) CompileStatic doesn't call asBoolean
[
https://issues.apache.org/jira/browse/GROOVY-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223767#comment-15223767
]
Jochen Theodorou commented on GROOVY-7807:
--
I used this test:
{code}
class Foo { boolean asBoolean() { foo || bar || keks || blorb } }
@groovy.transform.CompileStatic
def m () {
if (new Foo()) {println 1}
}
m()
{code}
This fails with a MissingPropertyException as expected. Which means asBoolean
is called
> CompileStatic doesn't call asBoolean
>
>
> Key: GROOVY-7807
> URL: https://issues.apache.org/jira/browse/GROOVY-7807
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.4
>Reporter: Johann
>
> I have a class that implements asBoolean:
> {code:java}
> class Foo {
>
> /**
> * @return whether any properties are true
> */
> boolean asBoolean() {
> foo || bar || keks || blorb
> }
> }
> {code}
> When using this class in a class that has {{@CompileStatic}} applied to it,
> the {{asBoolean}} method is not called in a ternary expression.
> May be related to GROOVY-6802.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7807) CompileStatic doesn't call asBoolean
[
https://issues.apache.org/jira/browse/GROOVY-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223766#comment-15223766
]
Jochen Theodorou commented on GROOVY-7807:
--
I cannot reproduce this in Groovy 2.4.5
> CompileStatic doesn't call asBoolean
>
>
> Key: GROOVY-7807
> URL: https://issues.apache.org/jira/browse/GROOVY-7807
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.4
>Reporter: Johann
>
> I have a class that implements asBoolean:
> {code:java}
> class Foo {
>
> /**
> * @return whether any properties are true
> */
> boolean asBoolean() {
> foo || bar || keks || blorb
> }
> }
> {code}
> When using this class in a class that has {{@CompileStatic}} applied to it,
> the {{asBoolean}} method is not called in a ternary expression.
> May be related to GROOVY-6802.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7811) Block frequently occurs Groovy multithreading capabilities of mixin
[ https://issues.apache.org/jira/browse/GROOVY-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou updated GROOVY-7811: - Summary: Block frequently occurs Groovy multithreading capabilities of mixin (was: Stack Overflow Questions Jobs Tags Users Badges Ask Question BLOCK frequently occurs Groovy multithreading capabilities of mixin) > Block frequently occurs Groovy multithreading capabilities of mixin > --- > > Key: GROOVY-7811 > URL: https://issues.apache.org/jira/browse/GROOVY-7811 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.6 >Reporter: 刘新宇 >Priority: Blocker > > Groovy:2.4.6 > please see : > http://stackoverflow.com/questions/36419161/block-frequently-occurs-groovy-multithreading-capabilities-of-mixin#comment60481097_36419161 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7811) Block frequently occurs Groovy multithreading capabilities of mixin
[
https://issues.apache.org/jira/browse/GROOVY-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228709#comment-15228709
]
Jochen Theodorou commented on GROOVY-7811:
--
The code from stack voerflow:
{code:Java}
class ClassMixinTest {
public static void main(String[] args) {
ExecutorService service = Executors.newFixedThreadPool(100)
while (true) {
service.submit(new Runnable() {
@Override
void run() {
invoke()
}
})
service.submit()
}
}
static void invoke() {
ClassMixinTest.User user = new ClassMixinTest.User()
long start = System.nanoTime()
user.metaClass.mixin(ClassMixinTest.Man)
println("spend" + (System.nanoTime() - start))
}
static class User {
}
static class Man {
}
}{code}
> Block frequently occurs Groovy multithreading capabilities of mixin
> ---
>
> Key: GROOVY-7811
> URL: https://issues.apache.org/jira/browse/GROOVY-7811
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.6
>Reporter: 刘新宇
>Priority: Blocker
>
> Groovy:2.4.6
> please see :
> http://stackoverflow.com/questions/36419161/block-frequently-occurs-groovy-multithreading-capabilities-of-mixin#comment60481097_36419161
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
