[jira] [Assigned] (GROOVY-7750) @Lazy allows instantiation of abstract class

[Paul King (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GROOVY-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King reassigned GROOVY-7750:
-

Assignee: Paul King

> @Lazy allows instantiation of abstract class
> 
>
> Key: GROOVY-7750
> URL: https://issues.apache.org/jira/browse/GROOVY-7750
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 2.4.4
>Reporter: Johann
>Assignee: Paul King
>Priority: Minor
>  Labels: usability
>
> Given this code:
> {code:java}
> @Lazy
> Foo foo
> abstract class Foo {}
> {code}
> You'll get:
> {code}
> java.lang.InstantiationException
>   at 
> sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:48)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>   at 
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:80)
>   at 
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:239)
> {code}
> This isn't really helpful. If I mistype a method name, Groovy will help me 
> out with suggestions, why not here?
> MODIFICATION by blackdrag:
> @Lazy should recognize this and fail compilation to avoid the initialization 
> of an abstract class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GROOVY-7750) @Lazy allows instantiation of abstract class

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GROOVY-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286411#comment-15286411
 ] 

ASF GitHub Bot commented on GROOVY-7750:


GitHub user paulk-asert opened a pull request:

https://github.com/apache/groovy/pull/334

GROOVY-7750: @Lazy allows instantiation of abstract class



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paulk-asert/groovy groovy7750

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/334.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #334


commit 58bcbac0f354a7da678fd23b23df196c9edda743
Author: paulk 
Date:   2016-05-17T11:06:50Z

GROOVY-7750: @Lazy allows instantiation of abstract class




> @Lazy allows instantiation of abstract class
> 
>
> Key: GROOVY-7750
> URL: https://issues.apache.org/jira/browse/GROOVY-7750
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 2.4.4
>Reporter: Johann
>Priority: Minor
>  Labels: usability
>
> Given this code:
> {code:java}
> @Lazy
> Foo foo
> abstract class Foo {}
> {code}
> You'll get:
> {code}
> java.lang.InstantiationException
>   at 
> sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:48)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>   at 
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:80)
>   at 
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:239)
> {code}
> This isn't really helpful. If I mistype a method name, Groovy will help me 
> out with suggestions, why not here?
> MODIFICATION by blackdrag:
> @Lazy should recognize this and fail compilation to avoid the initialization 
> of an abstract class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] groovy pull request: GROOVY-7750: @Lazy allows instantiation of ab...

[paulk-asert]

GitHub user paulk-asert opened a pull request:

https://github.com/apache/groovy/pull/334

GROOVY-7750: @Lazy allows instantiation of abstract class



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paulk-asert/groovy groovy7750

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/334.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #334


commit 58bcbac0f354a7da678fd23b23df196c9edda743
Author: paulk 
Date:   2016-05-17T11:06:50Z

GROOVY-7750: @Lazy allows instantiation of abstract class




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GROOVY-7826) Infinite recursion in genericTypeAsString

[Jochen Theodorou (JIRA)]

[ 
https://issues.apache.org/jira/browse/GROOVY-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286399#comment-15286399
 ] 

Jochen Theodorou commented on GROOVY-7826:
--

I feel bad about the change in PR #333. If DecompiledClassNode misses the  
generic type information it is actually a bug, unless the information is 
invalid, then this needs to be fixed. if the information is valid, then of 
course it should not cause a problem.  Comparing the generics information when 
C1 is in Java and when it is in Groovy should reveal the problem.

> Infinite recursion in genericTypeAsString
> -
>
> Key: GROOVY-7826
> URL: https://issues.apache.org/jira/browse/GROOVY-7826
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.8.0_91 Vendor: Oracle 
> Corporation OS: Linux
>Reporter: Magnus Reftel
>  Labels: regresion
> Attachments: groovy-7826.zip
>
>
> The following two Java classes C1 and C2 cause Groovy to enter infinite 
> recursion in genericTypeAsString when a method that takes a C1 is declared:
> C1.java:
> public class C1 ,T1 extends C1> { }
> class C2, T1 extends C1> { }
> repro.groovy
> def f(C1 c1) { }
> This is reduced from actual code in Jenkins, where Run and Job have type 
> parameters like this.



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

[Paul King (JIRA)]

[ 
https://issues.apache.org/jira/browse/GROOVY-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286274#comment-15286274
 ] 

Paul King commented on GROOVY-7530:
---

There is no date set at this stage. There are over twenty bug fixes already, so 
it would be good if we can do another release not too far down the track. You 
can grab snapshot artifacts in the meantime if you want.

> 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
>Assignee: Paul King
> Fix For: 2.4.7
>
>
> {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)