[jira] [Updated] (GROOVY-7938) inconsistent access of methods in outer class

[Paul King (JIRA)]

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

Paul King updated GROOVY-7938:
--
Affects Version/s: 2.4.7

> inconsistent access of methods in outer class
> -
>
> Key: GROOVY-7938
> URL: https://issues.apache.org/jira/browse/GROOVY-7938
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.7
>Reporter: Paul King
>
> Groovy handles access to outer instance and static methods from inner classes 
> but not nested (i.e. static) ones. The following code illustrates the problem:
> {code}class Outer {
> static Integer fooCount = 0
> Integer barCount = 0
> static void incFoo() { fooCount++ }
> void incBar() { barCount++ }
> static class Nested {
> static void nestedIncFoo() { incFoo() }
> }
> Inner innerFactory() { new Inner() }
> class Inner { }
> }
> Outer.incFoo()
> //Outer.Nested.nestedIncFoo() // => MME
> assert Outer.fooCount == 1 // but should be 2 if no MME
> new Outer().with {
> incBar()
> incFoo()
> innerFactory().with {
> incBar()
> incFoo()
> }
> assert barCount == 2
> assert fooCount == 3 // but should be 4 if no MME
> }
> {code}
> After the fix, the following is expected to work:
> {code}
> class Outer {
> static Integer fooCount = 0
> Integer barCount = 0
> static void incFoo() { fooCount++ }
> void incBar() { barCount++ }
> static class Nested {
> static void nestedIncFoo() { incFoo() }
> }
> Inner innerFactory() { new Inner() }
> class Inner { }
> }
> Outer.incFoo()
> Outer.Nested.nestedIncFoo()
> assert Outer.fooCount == 2
> new Outer().with {
> incBar()
> incFoo()
> innerFactory().with {
> incBar()
> incFoo()
> }
> assert barCount == 2
> assert fooCount == 4
> }
> {code}
> Basically the commented out line should work.



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

[jira] [Updated] (GROOVY-7938) inconsistent access of methods in outer class

[Paul King (JIRA)]

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

Paul King updated GROOVY-7938:
--
Description: 
Groovy handles access to outer instance and static methods from inner classes 
but not nested (i.e. static) ones. The following code illustrates the problem:
{code}class Outer {
static Integer fooCount = 0
Integer barCount = 0
static void incFoo() { fooCount++ }
void incBar() { barCount++ }
static class Nested {
static void nestedIncFoo() { incFoo() }
}
Inner innerFactory() { new Inner() }
class Inner { }
}

Outer.incFoo()
//Outer.Nested.nestedIncFoo() // => MME
assert Outer.fooCount == 1 // but should be 2 if no MME

new Outer().with {
incBar()
incFoo()
innerFactory().with {
incBar()
incFoo()
}
assert barCount == 2
assert fooCount == 3 // but should be 4 if no MME
}
{code}
After the fix, the following is expected to work:
{code}
class Outer {
static Integer fooCount = 0
Integer barCount = 0
static void incFoo() { fooCount++ }
void incBar() { barCount++ }
static class Nested {
static void nestedIncFoo() { incFoo() }
}
Inner innerFactory() { new Inner() }
class Inner { }
}

Outer.incFoo()
Outer.Nested.nestedIncFoo()
assert Outer.fooCount == 2

new Outer().with {
incBar()
incFoo()
innerFactory().with {
incBar()
incFoo()
}
assert barCount == 2
assert fooCount == 4
}
{code}
Basically the commented out line should work.

  was:
Groovy handles access to outer instance and static methods from inner classes 
but not nested (i.e. static) ones.
{code}
class Outer {
  private static Integer fooCount = 0
  private Integer barCount = 0
  static getFoo() { fooCount }
  static void incFoo() { fooCount++ }
  def getBar() { barCount }
  def void incBar() { barCount++ }
  static class Nested { }
  Inner innerFactory() { new Inner() }
  class Inner { }
}
Outer.incFoo()
//Outer.Nested.incFoo() // => MME
assert Outer.foo == 1 // expected: 2 if no MME

new Outer().with {
  incBar()
  incFoo()
  innerFactory().with {
incBar()
incFoo()
  }
  assert bar == 2
  assert foo == 3 // expected: 4 if no MME
}
{code}
Basically the commented out line should work.


> inconsistent access of methods in outer class
> -
>
> Key: GROOVY-7938
> URL: https://issues.apache.org/jira/browse/GROOVY-7938
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.7
>Reporter: Paul King
>
> Groovy handles access to outer instance and static methods from inner classes 
> but not nested (i.e. static) ones. The following code illustrates the problem:
> {code}class Outer {
> static Integer fooCount = 0
> Integer barCount = 0
> static void incFoo() { fooCount++ }
> void incBar() { barCount++ }
> static class Nested {
> static void nestedIncFoo() { incFoo() }
> }
> Inner innerFactory() { new Inner() }
> class Inner { }
> }
> Outer.incFoo()
> //Outer.Nested.nestedIncFoo() // => MME
> assert Outer.fooCount == 1 // but should be 2 if no MME
> new Outer().with {
> incBar()
> incFoo()
> innerFactory().with {
> incBar()
> incFoo()
> }
> assert barCount == 2
> assert fooCount == 3 // but should be 4 if no MME
> }
> {code}
> After the fix, the following is expected to work:
> {code}
> class Outer {
> static Integer fooCount = 0
> Integer barCount = 0
> static void incFoo() { fooCount++ }
> void incBar() { barCount++ }
> static class Nested {
> static void nestedIncFoo() { incFoo() }
> }
> Inner innerFactory() { new Inner() }
> class Inner { }
> }
> Outer.incFoo()
> Outer.Nested.nestedIncFoo()
> assert Outer.fooCount == 2
> new Outer().with {
> incBar()
> incFoo()
> innerFactory().with {
> incBar()
> incFoo()
> }
> assert barCount == 2
> assert fooCount == 4
> }
> {code}
> Basically the commented out line should work.



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

[jira] [Created] (GROOVY-7938) inconsistent access of methods in outer class

[Paul King (JIRA)]

Paul King created GROOVY-7938:
-

 Summary: inconsistent access of methods in outer class
 Key: GROOVY-7938
 URL: https://issues.apache.org/jira/browse/GROOVY-7938
 Project: Groovy
  Issue Type: Bug
Reporter: Paul King


Groovy handles access to outer instance and static methods from inner classes 
but not nested (i.e. static) ones.
{code}
class Outer {
  private static Integer fooCount = 0
  private Integer barCount = 0
  static getFoo() { fooCount }
  static void incFoo() { fooCount++ }
  def getBar() { barCount }
  def void incBar() { barCount++ }
  static class Nested { }
  Inner innerFactory() { new Inner() }
  class Inner { }
}
Outer.incFoo()
//Outer.Nested.incFoo() // => MME
assert Outer.foo == 1 // expected: 2 if no MME

new Outer().with {
  incBar()
  incFoo()
  innerFactory().with {
incBar()
incFoo()
  }
  assert bar == 2
  assert foo == 3 // expected: 4 if no MME
}
{code}
Basically the commented out line should work.



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

[jira] [Comment Edited] (GROOVY-7933) Incorrect boxing of boolean primitive types

[Jose Ignacio Acin Pozo (JIRA)]

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

Jose Ignacio Acin Pozo edited comment on GROOVY-7933 at 9/13/16 10:05 AM:
--

This is probably a bit off-topic for this particular issue, but should 
@CompileStatic and interpreted behaviour actually be different? I think it sort 
of makes sense as @CompileStatic methods should be chosen at compile time(like 
Java does) instead of runtime (like Groovy does):

>From http://groovy-lang.org/differences.html#_multi_methods :

"In Groovy, the methods which will be invoked are chosen at runtime. This is 
called runtime dispatch or multi-methods. It means that the method will be 
chosen based on the types of the arguments at runtime. In Java, this is the 
opposite: methods are chosen at compile time, based on the declared types."

>From 
>http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html
> :

"This will let the Groovy compiler use compile time checks in the style of Java 
then perform static compilation, thus bypassing the Groovy meta object 
protocol. When a class is annotated, all methods, properties, files, inner 
classes, etc. of the annotated class will be type checked."

Also more info taken from here 
http://java-performance.info/static-code-compilation-groovy-2-0/ :

"Both these features are connected, because you need a type inference in order 
to statically choose the best matching method at compile time. Static type 
checking allows you to check your Groovy code for type safety as well as for 
absence of typos in the method/property names."

"Static compilation allows Groovy 2.0 to generate direct method calls, which 
are no longer using Groovy runtime as an intermediary. This feature actually 
allows you to avoid going into the Groovy runtime for the huge share of methods 
– think how many overloaded methods do you usually have in your code – 
non-overloaded methods could always be safely converted into the normal method 
calls."



was (Author: joseignacio.acinp...@gmail.com):
Should @CompileStatic and interpreted behaviour actually be different? I think 
it sort of makes sense as @CompileStatic methods should be chosen at compile 
time(like Java does) instead of runtime (like Groovy does):

>From http://groovy-lang.org/differences.html#_multi_methods :

"In Groovy, the methods which will be invoked are chosen at runtime. This is 
called runtime dispatch or multi-methods. It means that the method will be 
chosen based on the types of the arguments at runtime. In Java, this is the 
opposite: methods are chosen at compile time, based on the declared types."

>From 
>http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html
> :

"This will let the Groovy compiler use compile time checks in the style of Java 
then perform static compilation, thus bypassing the Groovy meta object 
protocol. When a class is annotated, all methods, properties, files, inner 
classes, etc. of the annotated class will be type checked."

Also more info taken from here 
http://java-performance.info/static-code-compilation-groovy-2-0/ :

"Both these features are connected, because you need a type inference in order 
to statically choose the best matching method at compile time. Static type 
checking allows you to check your Groovy code for type safety as well as for 
absence of typos in the method/property names."

"Static compilation allows Groovy 2.0 to generate direct method calls, which 
are no longer using Groovy runtime as an intermediary. This feature actually 
allows you to avoid going into the Groovy runtime for the huge share of methods 
– think how many overloaded methods do you usually have in your code – 
non-overloaded methods could always be safely converted into the normal method 
calls."


> Incorrect boxing of boolean primitive types
> ---
>
> Key: GROOVY-7933
> URL: https://issues.apache.org/jira/browse/GROOVY-7933
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 2.4.7
>Reporter: Henri Tremblay
>
> A boolean primitive type seems to be boxed for no apparent reason. See the 
> example below. The problem disappear when using @CompileStatic or if 
> explicitly casting to (boolean).
> {code:java}
> public class Demo {
>public void a(boolean a){
>System.out.println("boolean was called");
>}
>public void a(Object a){
>System.out.println("Object was called");
>}
> }
> class Groovy {
>static void main(String[] args) {
>def demo = new Demo()
>demo.a(true)
>}
> }
> {code}
> *Output:*
> Object was called



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

[jira] [Commented] (GROOVY-7933) Incorrect boxing of boolean primitive types

[Jose Ignacio Acin Pozo (JIRA)]

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

Jose Ignacio Acin Pozo commented on GROOVY-7933:


Should @CompileStatic and interpreted behaviour actually be different? I think 
it sort of makes sense as @CompileStatic methods should be chosen at compile 
time(like Java does) instead of runtime (like Groovy does):

>From http://groovy-lang.org/differences.html#_multi_methods :

"In Groovy, the methods which will be invoked are chosen at runtime. This is 
called runtime dispatch or multi-methods. It means that the method will be 
chosen based on the types of the arguments at runtime. In Java, this is the 
opposite: methods are chosen at compile time, based on the declared types."

>From 
>http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html
> :

"This will let the Groovy compiler use compile time checks in the style of Java 
then perform static compilation, thus bypassing the Groovy meta object 
protocol. When a class is annotated, all methods, properties, files, inner 
classes, etc. of the annotated class will be type checked."

Also more info taken from here 
http://java-performance.info/static-code-compilation-groovy-2-0/ :

"Static compilation allows Groovy 2.0 to generate direct method calls, which 
are no longer using Groovy runtime as an intermediary. This feature actually 
allows you to avoid going into the Groovy runtime for the huge share of methods 
– think how many overloaded methods do you usually have in your code – 
non-overloaded methods could always be safely converted into the normal method 
calls."


> Incorrect boxing of boolean primitive types
> ---
>
> Key: GROOVY-7933
> URL: https://issues.apache.org/jira/browse/GROOVY-7933
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 2.4.7
>Reporter: Henri Tremblay
>
> A boolean primitive type seems to be boxed for no apparent reason. See the 
> example below. The problem disappear when using @CompileStatic or if 
> explicitly casting to (boolean).
> {code:java}
> public class Demo {
>public void a(boolean a){
>System.out.println("boolean was called");
>}
>public void a(Object a){
>System.out.println("Object was called");
>}
> }
> class Groovy {
>static void main(String[] args) {
>def demo = new Demo()
>demo.a(true)
>}
> }
> {code}
> *Output:*
> Object was called



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

[jira] [Commented] (GROOVY-6396) same linkedlist code different behavior between groovy and java

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GROOVY-6396:


GitHub user paulk-asert opened a pull request:

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

GROOVY-6396: same linkedlist code different behavior between groovy a…

…nd java

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

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

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

https://github.com/apache/groovy/pull/419.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 #419


commit 72bcd6ed039b854678228653daf88acc8604676b
Author: paulk 
Date:   2016-09-13T09:40:31Z

GROOVY-6396: same linkedlist code different behavior between groovy and java




> same linkedlist code different behavior between groovy and java
> ---
>
> Key: GROOVY-6396
> URL: https://issues.apache.org/jira/browse/GROOVY-6396
> Project: Groovy
>  Issue Type: Bug
>  Components: jdk conflict
>Reporter: boshi 
>  Labels: breaking
>
> I am using `linkedlist` as a stack in groovy 
> as doc says, `pop()` take elm from the first
> Stack Method  Equivalent Deque Method  
> push(e)   addFirst(e) 
> pop() removeFirst()
> so a `linkedlist` [1,2,3] should pop() 1 2 3
> and it does in Java, but does NOT in groovy. WHY?
> test below
> {code:title=A.java}
> import java.util.*;
> 
> public class A{
> 
> 
> public static void main(String[] args){
> 
> String[] x = "1/2/3/".split("/");
> LinkedList  stack = new LinkedList(Arrays.asList(x));
> System.out.println(stack.pop());
> }
> }
> {code}
> compile and run
> {noformat}
> $ javac A.java
> $ java A
> 1
> {noformat}
> runing in groovy
> {noformat}
> $ ln -s A.java A.groovy
> $ groovy A.groovy
> 3
> {noformat}
> here is my java and groovy version
> {noformat}
> $ java -version
> java version "1.6.0_51"
> Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-11M4509)
> Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode)
> $ groovy -version
> Groovy Version: 2.1.5 JVM: 1.6.0_51 Vendor: Apple Inc. OS: Mac OS X
> {noformat}



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

[GitHub] groovy pull request #419: GROOVY-6396: same linkedlist code different behavi...

[paulk-asert]

GitHub user paulk-asert opened a pull request:

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

GROOVY-6396: same linkedlist code different behavior between groovy a…

…nd java

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

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

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

https://github.com/apache/groovy/pull/419.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 #419


commit 72bcd6ed039b854678228653daf88acc8604676b
Author: paulk 
Date:   2016-09-13T09:40:31Z

GROOVY-6396: same linkedlist code different behavior between groovy and java




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

[GitHub] groovy pull request #418: GROOVY-7937: CLONE - same linkedlist code differen...

[paulk-asert]

GitHub user paulk-asert opened a pull request:

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

GROOVY-7937: CLONE - same linkedlist code different behavior between …

…groovy and java (fix priority of DGM methods vs actual methods on an 
object)

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

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

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

https://github.com/apache/groovy/pull/418.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 #418


commit 49e952c8926942060a7048afd3728f4a6d30a9e3
Author: paulk 
Date:   2016-09-13T06:54:51Z

GROOVY-7937: CLONE - same linkedlist code different behavior between groovy 
and java (fix priority of DGM methods vs actual methods on an object)




---
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-6396) same linkedlist code different behavior between groovy and java

[Paul King (JIRA)]

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

Paul King commented on GROOVY-6396:
---

There are two parts to this issue. One is that DGM methods on an interface are 
being selected ahead of methods already available within the instance. The 
other is that the DGM push/pop methods for Lists store/retrieve items in the 
reverse order to the backing list compared with Java's Deque interface. This 
issue will solve the latter of those two issues. The clone will be for solving 
the former.

> same linkedlist code different behavior between groovy and java
> ---
>
> Key: GROOVY-6396
> URL: https://issues.apache.org/jira/browse/GROOVY-6396
> Project: Groovy
>  Issue Type: Bug
>  Components: jdk conflict
>Reporter: boshi 
>  Labels: breaking
>
> I am using `linkedlist` as a stack in groovy 
> as doc says, `pop()` take elm from the first
> Stack Method  Equivalent Deque Method  
> push(e)   addFirst(e) 
> pop() removeFirst()
> so a `linkedlist` [1,2,3] should pop() 1 2 3
> and it does in Java, but does NOT in groovy. WHY?
> test below
> {code:title=A.java}
> import java.util.*;
> 
> public class A{
> 
> 
> public static void main(String[] args){
> 
> String[] x = "1/2/3/".split("/");
> LinkedList  stack = new LinkedList(Arrays.asList(x));
> System.out.println(stack.pop());
> }
> }
> {code}
> compile and run
> {noformat}
> $ javac A.java
> $ java A
> 1
> {noformat}
> runing in groovy
> {noformat}
> $ ln -s A.java A.groovy
> $ groovy A.groovy
> 3
> {noformat}
> here is my java and groovy version
> {noformat}
> $ java -version
> java version "1.6.0_51"
> Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-11M4509)
> Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode)
> $ groovy -version
> Groovy Version: 2.1.5 JVM: 1.6.0_51 Vendor: Apple Inc. OS: Mac OS X
> {noformat}



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