[jira] [Commented] (GROOVY-8431) toDebugString method as a core concept

[JIRA]

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

Leonard Brünings commented on GROOVY-8431:
--

While not supporting this feature, I'd suggest to use a {{ToStringHelper}} 
similar to guava instead of some parameters like
String toDebugString(int indentationLevel, String indentationString = '\t')
this way we can be flexible, while having a standard api/way to output 
structured content. The {{DebugStringBuilder}} would be an interface with a 
default implementation, a developer/tool could choose to supply a different 
implementation for their needs. The GroovyObject would add a default 
{{toDebugString()}} method that in turn calls the overridable 
{{toDebugString(DebugStringBuilder builder)}}

> toDebugString method as a core concept
> --
>
> Key: GROOVY-8431
>     URL: https://issues.apache.org/jira/browse/GROOVY-8431
> Project: Groovy
>  Issue Type: Proposal
>  Components: GEP, groovy-jdk
>Affects Versions: 3.x, 2.5.x
>Reporter: mgroovy
>Priority: Major
>  Labels: features
>
> * Groovy should introduce a toDebugString method as a core concept, to 
> separate debug to-string-conversion semantics from heavily oversubscribed 
> standard Java Object#toString.
> * The power of this feature as a core concept lies in support to create
> ## Easy to use, human readable debug output of any object
> ## Creating debug output of objects owned by other objects (i.e. hierarchical 
> debug output)
> * Adding this feature should be relatively simple, the challenge is to decide 
> what features/parameters toDebugString should have, because this will be hard 
> to change once the feature has been introduced.   
> * The default implementation could
> ## Call the Java default Object#toString method
> ## Automatically create a reflection based output (performance will probably 
> be bad for this, so it might be better to enable this behavior through an 
> annotation)
> ## Returns something along the line of getClass().simpleName + '@' + 
> System.identityHashcode(this) (though Object#toString is probably more useful)
> ## Fall back to the class' toString method (although in most cases it's most 
> likely not what the user wants/expects)
> * An extension would be for an overloaded toDebugString to take an 
> indentationLevel and indentationString parameter:
> {code}String toDebugString(int indentationLevel, String indentationString = 
> '\t'){code}
> ** Implementations would be expected to indent the resulting String 
> accordingly, which is very helpful for
> ### Complex objects which require a multi-line output to make sense of them 
> in a debug log
> ### Outputting inner objects (e.g. a collection) owned by an object
> ** Groovy default implementation could be, to indent the result of calling 
> toDebugString(), by scanning for newline sequences in the returned string
> * Questions:
> ## Is there a better name than the (relatively long) "toDebugString" ?
> *** toDebugString was suggested, since it is easy to discover, and its 
> purpose should immediately clear
> ## Should the return type of toDebugString be GString instead of String ?
> *** This would allow for Groovy to process the objects embedded in the 
> GString differently
> *** Having an additional GString toDebugGString() method might be an 
> alternative
> ## Should there be additional parameters such as a terseness/verboseness 
> parameter, which indicates how compact or verbose the generated debug string 
> should be (implementations would be free to ignore this, of course) ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-3942) Using metaClass to override methods in class hierarchy does not work as expected

[JIRA]

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

Jan Šmucr commented on GROOVY-3942:
---

Just ran into this and trying to figure out some workaround. :(

> Using metaClass to override methods in class hierarchy does not work as 
> expected
> 
>
> Key: GROOVY-3942
> URL: https://issues.apache.org/jira/browse/GROOVY-3942
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 1.8-beta-1
> Environment: Windows XP
>Reporter: Alex McManus
>Priority: Major
> Attachments: MetaclassOverrideTest.groovy
>
>
> I've found some strange behaviour when dynamically overriding methods that 
> are called in a class hierarchy, which I think might be a bug. The problem is 
> that when I override a method on a subclass, code in the superclass still 
> calls the original method (note all classes are Groovy ones, I know this 
> wouldn't work with a Java class hierarchy).
> I've isolated it to this sample code:
> {code:Java}
> class BaseClass {
> def baseClassMethod() {
> println "BaseClass.baseClassMethod()"
> internalMethod()
> }
> def internalMethod() {
>println "BaseClass.internalMethod()"
> }
> }
> class SubClass extends BaseClass {
> def subClassMethod() {
> println "SubClass.subClassMethod()"
> internalMethod()
> }
> }
> def subClass = new SubClass()
> subClass.metaClass.internalMethod = { -> println ("
> (dynamic).internalMethod()")}
> subClass.baseClassMethod()
> subClass.subClassMethod()
> {code}
> ...which gives me the following output...
> BaseClass.baseClassMethod()
> BaseClass.internalMethod()
> SubClass.subClassMethod()
> (dynamic).internalMethod()
> I would have expected that the dynamic version of internalMethod() would be 
> called both times, given that Groovy has dynamic method dispatching.
> Some discussion of this issue took place on the mailing list: 
> http://old.nabble.com/Problems-using-metaClass-to-override-methods-in-class-hierarchy-td26743895.html#a26743895
> The suggestion is that the CallSiteArray.createCallCurrentSite(...) method 
> could check whether the receiver is a sub class of the sender class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8151) Unreadable assert output

[JIRA]

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

Michał Gazda updated GROOVY-8151:
-
Attachment: image-2018-02-01-12-48-26-783.png

> Unreadable assert output
> 
>
> Key: GROOVY-8151
> URL: https://issues.apache.org/jira/browse/GROOVY-8151
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Windows 7, JDK 1.8.0_66
>Reporter: Iurii
>Priority: Major
> Attachments: image-2018-02-01-12-48-12-547.png, 
> image-2018-02-01-12-48-26-783.png, image-2018-02-01-12-48-52-359.png
>
>
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test')
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test')
> {code}
> It's unclear from the output what was the right hand value.
> E.g. the following code shows readable error message:
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test').toString()
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test').toString()
>  |
>  testaaa
> {code}
> Expected:
> the first code example should show the right hand value in the output



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8151) Unreadable assert output

[JIRA]

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

Michał Gazda updated GROOVY-8151:
-
Attachment: image-2018-02-01-12-48-12-547.png

> Unreadable assert output
> 
>
> Key: GROOVY-8151
> URL: https://issues.apache.org/jira/browse/GROOVY-8151
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Windows 7, JDK 1.8.0_66
>Reporter: Iurii
>Priority: Major
> Attachments: image-2018-02-01-12-48-12-547.png, 
> image-2018-02-01-12-48-26-783.png, image-2018-02-01-12-48-52-359.png
>
>
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test')
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test')
> {code}
> It's unclear from the output what was the right hand value.
> E.g. the following code shows readable error message:
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test').toString()
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test').toString()
>  |
>  testaaa
> {code}
> Expected:
> the first code example should show the right hand value in the output



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8151) Unreadable assert output

[JIRA]

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

Michał Gazda updated GROOVY-8151:
-
Attachment: image-2018-02-01-12-48-52-359.png

> Unreadable assert output
> 
>
> Key: GROOVY-8151
> URL: https://issues.apache.org/jira/browse/GROOVY-8151
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Windows 7, JDK 1.8.0_66
>Reporter: Iurii
>Priority: Major
> Attachments: image-2018-02-01-12-48-12-547.png, 
> image-2018-02-01-12-48-26-783.png, image-2018-02-01-12-48-52-359.png
>
>
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test')
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test')
> {code}
> It's unclear from the output what was the right hand value.
> E.g. the following code shows readable error message:
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test').toString()
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test').toString()
>  |
>  testaaa
> {code}
> Expected:
> the first code example should show the right hand value in the output



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8151) Unreadable assert output

[JIRA]

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

Michał Gazda updated GROOVY-8151:
-
Attachment: image-2018-02-01-12-49-09-656.png

> Unreadable assert output
> 
>
> Key: GROOVY-8151
> URL: https://issues.apache.org/jira/browse/GROOVY-8151
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Windows 7, JDK 1.8.0_66
>Reporter: Iurii
>Priority: Major
> Attachments: image-2018-02-01-12-48-12-547.png, 
> image-2018-02-01-12-48-26-783.png, image-2018-02-01-12-48-52-359.png, 
> image-2018-02-01-12-49-09-656.png
>
>
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test')
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test')
> {code}
> It's unclear from the output what was the right hand value.
> E.g. the following code shows readable error message:
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test').toString()
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test').toString()
>  |
>  testaaa
> {code}
> Expected:
> the first code example should show the right hand value in the output



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8151) Unreadable assert output

[JIRA]

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

Michał Gazda commented on GROOVY-8151:
--

Hello, any progress with this issue? Similar thing happens when I have some 
method and do static import:

!image-2018-02-01-12-48-52-359.png!

->

!image-2018-02-01-12-49-09-656.png!

Here we are missing what function actually returned.

When I add qualified reference:

!image-2018-02-01-12-48-12-547.png!

->

!image-2018-02-01-12-48-26-783.png!

> Unreadable assert output
> 
>
> Key: GROOVY-8151
> URL: https://issues.apache.org/jira/browse/GROOVY-8151
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Windows 7, JDK 1.8.0_66
>Reporter: Iurii
>Priority: Major
> Attachments: image-2018-02-01-12-48-12-547.png, 
> image-2018-02-01-12-48-26-783.png, image-2018-02-01-12-48-52-359.png, 
> image-2018-02-01-12-49-09-656.png
>
>
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test')
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test')
> {code}
> It's unclear from the output what was the right hand value.
> E.g. the following code shows readable error message:
> {code}
> class Test {
> static void main(String[] args) {
> assert 'test' == transform('test').toString()
> }
> static String transform(String str) {
> str + 'aaa'
> }
> }
> {code}
> Output:
> {code}
> Exception in thread "main" Assertion failed: 
> assert 'test' == transform('test').toString()
>  |
>  testaaa
> {code}
> Expected:
> the first code example should show the right hand value in the output



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8471) Contents of META-INF/services/org.codehaus.groovy.source.Extensions conflict with Maven/Jisaw

[JIRA]

Ceki Gülcü created GROOVY-8471:
--

 Summary: Contents of 
META-INF/services/org.codehaus.groovy.source.Extensions conflict with 
Maven/Jisaw
 Key: GROOVY-8471
 URL: https://issues.apache.org/jira/browse/GROOVY-8471
 Project: Groovy
  Issue Type: Bug
Affects Versions: 2.4.13, 3.0.0-alpha-1
Reporter: Ceki Gülcü


>From what [I can 
>gather|http://markmail.org/thread/nekeppbvwrfl7hbb#query:+page:1+mid:qtqqcfrw6us6aupz+state:results],
> Jigsaw module resolution analyzes the contents of module-info.class, 
>MANIFEST.MF and META-INF/services/* files. 

As such, it turns out that the contents of 
{{src/resources/META-INF/services/org.codehaus.groovy.source.Extensions}} 
prevents groovy-*.jar from being loaded as an automatic module, at least within 
a Maven build.

[~rfscholte] has pointed out that this is not a Maven specific problem as can 
be verified in JShell by invoking: 
{code}
java.lang.module.ModuleFinder.of(java.nio.file.Paths.get(artifact)).findAll().stream().findFirst().get().descriptor().name()
{code}





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword

[JIRA]

Rémy Letient created GROOVY-8475:


 Summary: CLONE - I am unable to instantiate objects using the 
"new" keyword
 Key: GROOVY-8475
 URL: https://issues.apache.org/jira/browse/GROOVY-8475
 Project: Groovy
  Issue Type: Bug
  Components: Groovysh
Affects Versions: 2.4.0-beta-3
 Environment: Linux - Debian jessie/sid 64 bits
Reporter: Rémy Letient
 Fix For: 2.4.0-rc-1
 Attachments: testA.groovy

I am embedding Groovysh in a java application. After some tests, I realized 
that the "new" keyword seems to not work in the last groovysh version. When I 
try to do:
a = new A()
I obtain: "unable to resolve class A"

This is an example:

groovy:000> class A {
class A {
groovy:001>   public A() {
public A() {
groovy:002> name = "default"
name = "default"
groovy:003> }
}
groovy:004>   String name;
String name;
groovy:005>   }
}
===> true
groovy:000> a = new A()
a = new A()
ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
script14159599676571305654112.groovy: 1: unable to resolve class A 
 @ line 1, column 5.
   a = new A()
   ^

1 error

However, if I use the newInstance method it works:
groovy:000> a = A.newInstance()
a = A.newInstance()
===> A@2154cecb

I tested the same code in the previous version (2.3.7) and it works




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword

[JIRA]

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

Rémy Letient updated GROOVY-8475:
-
Attachment: image-2018-02-10-18-36-27-122.png

> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
>  Issue Type: Bug
>  Components: Groovysh
>Affects Versions: 2.4.0-beta-3
> Environment: Linux - Debian jessie/sid 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Fix For: 2.4.0-rc-1
>
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized 
> that the "new" keyword seems to not work in the last groovysh version. When I 
> try to do:
> a = new A()
> I obtain: "unable to resolve class A"
> This is an example:
> groovy:000> class A {
> class A {
> groovy:001>   public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004>   String name;
> String name;
> groovy:005>   }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A 
>  @ line 1, column 5.
>a = new A()
>^
> 1 error
> However, if I use the newInstance method it works:
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> I tested the same code in the previous version (2.3.7) and it works



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword

[JIRA]

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

Rémy Letient commented on GROOVY-8475:
--

I'm cloned the original issu because it still.

I'm with ubuntu 17.03 and Groovy 2.4.0, 2.4.13, 2.4.12

With the Groovy 2.3.7 that works.

 

 

 

 

> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
>  Issue Type: Bug
>  Components: Groovysh
>Affects Versions: 2.4.0-beta-3
> Environment: Linux - Debian jessie/sid 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Fix For: 2.4.0-rc-1
>
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized 
> that the "new" keyword seems to not work in the last groovysh version. When I 
> try to do:
> a = new A()
> I obtain: "unable to resolve class A"
> This is an example:
> groovy:000> class A {
> class A {
> groovy:001>   public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004>   String name;
> String name;
> groovy:005>   }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A 
>  @ line 1, column 5.
>a = new A()
>^
> 1 error
> However, if I use the newInstance method it works:
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> I tested the same code in the previous version (2.3.7) and it works



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword

[JIRA]

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

Rémy Letient updated GROOVY-8475:
-
Fix Version/s: (was: 2.4.13)
   (was: 2.4.12)
   (was: 2.4.0)

> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
>  Issue Type: Bug
>  Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized 
> that the "new" keyword seems to not work in the last groovysh version. When I 
> try to do:
> a = new A()
> I obtain: "unable to resolve class A"
> This is an example:
> groovy:000> class A {
> class A {
> groovy:001>   public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004>   String name;
> String name;
> groovy:005>   }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A 
>  @ line 1, column 5.
>a = new A()
>^
> 1 error
> However, if I use the newInstance method it works:
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> I tested the same code in the previous version (2.3.7) and it works



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword

[JIRA]

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

Rémy Letient updated GROOVY-8475:
-
Affects Version/s: (was: 2.4.0-beta-3)
   2.4.0
   2.4.12
   2.4.13

> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
>  Issue Type: Bug
>  Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized 
> that the "new" keyword seems to not work in the last groovysh version. When I 
> try to do:
> a = new A()
> I obtain: "unable to resolve class A"
> This is an example:
> groovy:000> class A {
> class A {
> groovy:001>   public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004>   String name;
> String name;
> groovy:005>   }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A 
>  @ line 1, column 5.
>a = new A()
>^
> 1 error
> However, if I use the newInstance method it works:
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> I tested the same code in the previous version (2.3.7) and it works



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword

[JIRA]

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

Rémy Letient updated GROOVY-8475:
-
Fix Version/s: (was: 2.4.0-rc-1)
   2.4.0
   2.4.12
   2.4.13

> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
>  Issue Type: Bug
>  Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized 
> that the "new" keyword seems to not work in the last groovysh version. When I 
> try to do:
> a = new A()
> I obtain: "unable to resolve class A"
> This is an example:
> groovy:000> class A {
> class A {
> groovy:001>   public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004>   String name;
> String name;
> groovy:005>   }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A 
>  @ line 1, column 5.
>a = new A()
>^
> 1 error
> However, if I use the newInstance method it works:
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> I tested the same code in the previous version (2.3.7) and it works



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword

[JIRA]

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

Rémy Letient edited comment on GROOVY-8475 at 2/10/18 5:40 PM:
---

I'm cloned the original issu because it still.

I'm with ubuntu 16 and Groovy 2.4.0, 2.4.13, 2.4.12

With the Groovy 2.3.7 that works.

 

 

 

 


was (Author: jwillow):
I'm cloned the original issu because it still.

I'm with ubuntu 17.03 and Groovy 2.4.0, 2.4.13, 2.4.12

With the Groovy 2.3.7 that works.

 

 

 

 

> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
>     URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
>  Issue Type: Bug
>  Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
> Linux - Ubuntu 16 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized 
> that the "new" keyword seems to not work in the last groovysh version. When I 
> try to do:
> a = new A()
> I obtain: "unable to resolve class A"
> This is an example:
> groovy:000> class A {
> class A {
> groovy:001>   public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004>   String name;
> String name;
> groovy:005>   }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A 
>  @ line 1, column 5.
>a = new A()
>^
> 1 error
> However, if I use the newInstance method it works:
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> I tested the same code in the previous version (2.3.7) and it works



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword

[JIRA]

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

Rémy Letient updated GROOVY-8475:
-
Environment: 
Linux - Debian jessie/sid 64 bits
Linux - Ubuntu 16 64 bits

  was:Linux - Debian jessie/sid 64 bits


> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
>  Issue Type: Bug
>  Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
> Linux - Ubuntu 16 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized 
> that the "new" keyword seems to not work in the last groovysh version. When I 
> try to do:
> a = new A()
> I obtain: "unable to resolve class A"
> This is an example:
> groovy:000> class A {
> class A {
> groovy:001>   public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004>   String name;
> String name;
> groovy:005>   }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A 
>  @ line 1, column 5.
>a = new A()
>^
> 1 error
> However, if I use the newInstance method it works:
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> I tested the same code in the previous version (2.3.7) and it works



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8471) Contents of META-INF/services/org.codehaus.groovy.source.Extensions conflict with Maven/Jisaw

[JIRA]

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

Ceki Gülcü commented on GROOVY-8471:


[~paulk] Thank you.

> Contents of META-INF/services/org.codehaus.groovy.source.Extensions conflict 
> with Maven/Jisaw
> -
>
> Key: GROOVY-8471
> URL: https://issues.apache.org/jira/browse/GROOVY-8471
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.13
>Reporter: Ceki Gülcü
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.0-beta-3
>
>
> From what [I can 
> gather|http://markmail.org/thread/nekeppbvwrfl7hbb#query:+page:1+mid:qtqqcfrw6us6aupz+state:results],
>  Jigsaw module resolution analyzes the contents of module-info.class, 
> MANIFEST.MF and META-INF/services/* files. 
> As such, it turns out that the contents of 
> {{src/resources/META-INF/services/org.codehaus.groovy.source.Extensions}} 
> prevents groovy-*.jar from being loaded as an automatic module, at least 
> within a Maven build.
> [~rfscholte] has pointed out that this is not a Maven specific problem as can 
> be verified in JShell by invoking: 
> {code}
> java.lang.module.ModuleFinder.of(java.nio.file.Paths.get(artifact)).findAll().stream().findFirst().get().descriptor().name()
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8505) ArrayIndexOutOfBoundsException with @Nullable change

[JIRA]

Lóránt Pintér created GROOVY-8505:
-

 Summary: ArrayIndexOutOfBoundsException with @Nullable change
 Key: GROOVY-8505
 URL: https://issues.apache.org/jira/browse/GROOVY-8505
 Project: Groovy
  Issue Type: Bug
  Components: Compiler
Affects Versions: 2.4.12
 Environment: See [Gradle build 
scan|https://scans.gradle.com/s/gr3dszv44wkfg/console-log#L476] for execution 
details.
Reporter: Lóránt Pintér


*Steps to reproduce:*

{code}
$ git clone [https://github.com/gradle/gradle
$ cd gradle
$ git checkout c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
$ ./gradlew :core:compileTestGroovy
$ # ^ This version works
$ git revert --no-commit head
$ ./gradlew :core:compileTestGroovy
$ # ^ This will fail
{code}

The reverted commit is this:

https://github.com/gradle/gradle/pull/4682/commits/c8e7ac4adb2f72390ed681eb8bfdaa4baa8e

It removes a {{@Nullable}} annotation from a constructor parameter. If the 
annotation is present (i.e. the commit is reverted), {{./gradlew 
:core:compileTestGroovy}} will produce the following exception:

{code}
java.lang.ArrayIndexOutOfBoundsException: 1
at org.codehaus.groovy.vmplugin.v5.Java5.makeParameters(Java5.java:451)
at 
org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:382)
at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280)
at 
org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1009)
at 
org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1004)
at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:998)
at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:941)
at 
org.codehaus.groovy.classgen.asm.InvocationWriter.castToNonPrimitiveIfNecessary(InvocationWriter.java:863)
at 
org.codehaus.groovy.classgen.asm.OperandStack.doConvertAndCast(OperandStack.java:345)
at 
org.codehaus.groovy.classgen.asm.OperandStack.doGroovyCast(OperandStack.java:282)
at 
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateEqual(BinaryExpressionHelper.java:344)
at 
org.codehaus.groovy.classgen.AsmClassGenerator.visitDeclarationExpression(AsmClassGenerator.java:637)
at 
org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:89)
at 
org.codehaus.groovy.classgen.asm.StatementWriter.writeExpressionStatement(StatementWriter.java:613)
at 
org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeExpressionStatement(OptimizingStatementWriter.java:366)
at 
org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:624)
at 
org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
at 
org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:85)
at 
org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:159)
at 
org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:570)
at 
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
at 
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
at 
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
at 
org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:434)
at 
org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:387)
at 
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
at 
org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:511)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1081)
at 
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
at 
org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:233)
at 
org.codehaus.groovy.control.CompilationUnit.call(CompilationUnit.java:825)
at 
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1065)
at 
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at 
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at 
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at 
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:537)
at 
org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:175)
{code}

The change actually happens in Java code that the

[jira] [Created] (GROOVY-8507) groovyc hangs when compiling nested enum

[JIRA]

Álvaro Iradier created GROOVY-8507:
--

 Summary: groovyc hangs when compiling nested enum
 Key: GROOVY-8507
 URL: https://issues.apache.org/jira/browse/GROOVY-8507
 Project: Groovy
  Issue Type: Bug
  Components: Compiler
Affects Versions: 2.4.5
 Environment: Linux ubuntu-xenial 4.4.0-116-generic #140-Ubuntu SMP Mon 
Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Álvaro Iradier


This problem was discovered in a Jenkins pipeline, but then nailed down and 
found it failed with *groovyc* compiler too.

Creating a script with two nested enums, like:
{code:java}
class TestClass {
enum OuterEnum {
VALUE,
enum InnerEnum {
A
}
}
}
{code}
And compiling with groovyc script.groovy makes the compiler freeze with 100% 
CPU usage.

In Jenkins, this results in the Job and executor being freezed and zombie (need 
to kill the job and executor thread), but I am reporting this to Jenkins as an 
independent issue.

As the problem seems to happen in a stripped down groovy script, I am reporting 
it here too.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8505) ArrayIndexOutOfBoundsException with @Nullable change

[JIRA]

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

Lóránt Pintér updated GROOVY-8505:
--
Environment: 
See https://scans.gradle.com/s/gr3dszv44wkfg/console-log#L476 for execution 
details.


  was:See [Gradle build 
scan|https://scans.gradle.com/s/gr3dszv44wkfg/console-log#L476] for execution 
details.


> ArrayIndexOutOfBoundsException with @Nullable change
> 
>
> Key: GROOVY-8505
> URL: https://issues.apache.org/jira/browse/GROOVY-8505
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 2.4.12
> Environment: See 
> https://scans.gradle.com/s/gr3dszv44wkfg/console-log#L476 for execution 
> details.
>Reporter: Lóránt Pintér
>Priority: Major
>
> *Steps to reproduce:*
> {code}
> $ git clone [https://github.com/gradle/gradle
> $ cd gradle
> $ git checkout c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This version works
> $ git revert --no-commit head
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This will fail
> {code}
> The reverted commit is this:
> https://github.com/gradle/gradle/pull/4682/commits/c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> It removes a {{@Nullable}} annotation from a constructor parameter. If the 
> annotation is present (i.e. the commit is reverted), {{./gradlew 
> :core:compileTestGroovy}} will produce the following exception:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.codehaus.groovy.vmplugin.v5.Java5.makeParameters(Java5.java:451)
> at 
> org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:382)
> at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280)
> at 
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1009)
> at 
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1004)
> at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:998)
> at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:941)
> at 
> org.codehaus.groovy.classgen.asm.InvocationWriter.castToNonPrimitiveIfNecessary(InvocationWriter.java:863)
> at 
> org.codehaus.groovy.classgen.asm.OperandStack.doConvertAndCast(OperandStack.java:345)
> at 
> org.codehaus.groovy.classgen.asm.OperandStack.doGroovyCast(OperandStack.java:282)
> at 
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateEqual(BinaryExpressionHelper.java:344)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitDeclarationExpression(AsmClassGenerator.java:637)
> at 
> org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:89)
> at 
> org.codehaus.groovy.classgen.asm.StatementWriter.writeExpressionStatement(StatementWriter.java:613)
> at 
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeExpressionStatement(OptimizingStatementWriter.java:366)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:624)
> at 
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
> at 
> org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:85)
> at 
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:159)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:570)
> at 
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:434)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:387)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:511)
> at 
> org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1081)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
> 

[jira] [Commented] (GROOVY-8505) ArrayIndexOutOfBoundsException with @Nullable change

[JIRA]

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

Lóránt Pintér commented on GROOVY-8505:
---

I haven't tried with an earlier Groovy version, the {{@Nullable}} was added 
recently.

I haven't seen the compile error, the compilation succeeds for me as soon as I 
remove the {{@Nullable}} annotation.

> ArrayIndexOutOfBoundsException with @Nullable change
> 
>
> Key: GROOVY-8505
> URL: https://issues.apache.org/jira/browse/GROOVY-8505
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 2.4.12
> Environment: See 
> https://scans.gradle.com/s/gr3dszv44wkfg/console-log#L476 for execution 
> details.
>Reporter: Lóránt Pintér
>Priority: Major
>
> *Steps to reproduce:*
> {code}
> $ git clone [https://github.com/gradle/gradle
> $ cd gradle
> $ git checkout c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This version works
> $ git revert --no-commit head
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This will fail
> {code}
> The reverted commit is this:
> https://github.com/gradle/gradle/pull/4682/commits/c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> It removes a {{@Nullable}} annotation from a constructor parameter. If the 
> annotation is present (i.e. the commit is reverted), {{./gradlew 
> :core:compileTestGroovy}} will produce the following exception:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.codehaus.groovy.vmplugin.v5.Java5.makeParameters(Java5.java:451)
> at 
> org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:382)
> at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280)
> at 
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1009)
> at 
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1004)
> at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:998)
> at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:941)
> at 
> org.codehaus.groovy.classgen.asm.InvocationWriter.castToNonPrimitiveIfNecessary(InvocationWriter.java:863)
> at 
> org.codehaus.groovy.classgen.asm.OperandStack.doConvertAndCast(OperandStack.java:345)
> at 
> org.codehaus.groovy.classgen.asm.OperandStack.doGroovyCast(OperandStack.java:282)
> at 
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateEqual(BinaryExpressionHelper.java:344)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitDeclarationExpression(AsmClassGenerator.java:637)
> at 
> org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:89)
> at 
> org.codehaus.groovy.classgen.asm.StatementWriter.writeExpressionStatement(StatementWriter.java:613)
> at 
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeExpressionStatement(OptimizingStatementWriter.java:366)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:624)
> at 
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
> at 
> org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:85)
> at 
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:159)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:570)
> at 
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:434)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:387)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:511)
> at 
> org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1081)
> at 
> org.codehaus.groovy

[jira] [Commented] (GROOVY-8505) ArrayIndexOutOfBoundsException with @Nullable change

[JIRA]

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

Lóránt Pintér commented on GROOVY-8505:
---

Thanks Paul. How can I try to reproduce this with 2.4.15? Is there a snapshot 
build I can use? Thanks.

> ArrayIndexOutOfBoundsException with @Nullable change
> 
>
> Key: GROOVY-8505
> URL: https://issues.apache.org/jira/browse/GROOVY-8505
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 2.4.12
> Environment: See 
> https://scans.gradle.com/s/gr3dszv44wkfg/console-log#L476 for execution 
> details.
>Reporter: Lóránt Pintér
>Priority: Major
>
> *Steps to reproduce:*
> {code}
> $ git clone [https://github.com/gradle/gradle
> $ cd gradle
> $ git checkout c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This version works
> $ git revert --no-commit head
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This will fail
> {code}
> The reverted commit is this:
> https://github.com/gradle/gradle/pull/4682/commits/c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> It removes a {{@Nullable}} annotation from a constructor parameter. If the 
> annotation is present (i.e. the commit is reverted), {{./gradlew 
> :core:compileTestGroovy}} will produce the following exception:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at 
> org.codehaus.groovy.vmplugin.v5.Java5.makeParameters(Java5.java:451)
> at 
> org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:382)
> at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280)
> at 
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1009)
> at 
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1004)
> at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:998)
> at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:941)
> at 
> org.codehaus.groovy.classgen.asm.InvocationWriter.castToNonPrimitiveIfNecessary(InvocationWriter.java:863)
> at 
> org.codehaus.groovy.classgen.asm.OperandStack.doConvertAndCast(OperandStack.java:345)
> at 
> org.codehaus.groovy.classgen.asm.OperandStack.doGroovyCast(OperandStack.java:282)
> at 
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateEqual(BinaryExpressionHelper.java:344)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitDeclarationExpression(AsmClassGenerator.java:637)
> at 
> org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:89)
> at 
> org.codehaus.groovy.classgen.asm.StatementWriter.writeExpressionStatement(StatementWriter.java:613)
> at 
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeExpressionStatement(OptimizingStatementWriter.java:366)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:624)
> at 
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
> at 
> org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:85)
> at 
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:159)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:570)
> at 
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:434)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:387)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
> at 
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:511)
> at 
> org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1081)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
> at 
> org.codehaus.groovy.classge

[jira] [Created] (GROOVY-8586) Support Java 9 ARM blocks

[JIRA]

Jesper Steen Møller created GROOVY-8586:
---

 Summary: Support Java 9 ARM blocks
 Key: GROOVY-8586
 URL: https://issues.apache.org/jira/browse/GROOVY-8586
 Project: Groovy
  Issue Type: Improvement
  Components: Compiler
Affects Versions: 3.x
Reporter: Jesper Steen Møller


Java 9 introduces a ARM-with-existing-resources construct, like this:
{code:java}
OutputStream stream = foo();
try (stream) {
   stream.write(whatever());
}
{code}
In other words, the resource need not be in the form of an initialization, but 
can just be a variable.

Now that we have ARM in Groovy, we should be able to add this form as well.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call

[JIRA]

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

Cédric Champeau commented on GROOVY-6668:
-

I understand the temptation, but no, we shouldn't. This isn't about usability, 
this is about type safety. "Fixing" this would open Pandora's box. I think this 
works exactly as expected, and we must educate people that GString!=String.

> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
>     URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8652) Putting key on generic Map fails when using CompileStatic

[JIRA]

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

Cleydson José de Figueiredo Júnior updated GROOVY-8652:
---
Description: 
I'm trying to use Groovy's short hand way to put a new key value to an 
encapsulated Map. But the compilation fails with:

 
{code:java}
[Static type checking] - Cannot assign value of type java.lang.String to 
variable of type ?   
{code}
 

Scenario to reproduce:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.map.key = 'value'
}

setMapValue()
{code}
Using the method *put* works just fine.

 

  was:
I'm trying to use Groovy's short hand way to put a new key value to a 
encapsulated Map. But the compilation fails with:

 
{code:java}
[Static type checking] - Cannot assign value of type java.lang.String to 
variable of type ?   
{code}
 

Scenario to reproduce:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.map.key = 'value'
}

setMapValue()
{code}
Using the method *put* works just fine.

 


> Putting key on generic Map fails when using CompileStatic
> -
>
> Key: GROOVY-8652
> URL: https://issues.apache.org/jira/browse/GROOVY-8652
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 3.0.0-alpha-2, 2.4.15, 2.5.0
> Environment: Elementary OS Freya 0.3.2
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: Cleydson José de Figueiredo Júnior
>Priority: Minor
>  Labels: compilestatic
>
> I'm trying to use Groovy's short hand way to put a new key value to an 
> encapsulated Map. But the compilation fails with:
>  
> {code:java}
> [Static type checking] - Cannot assign value of type java.lang.String to 
> variable of type ?   
> {code}
>  
> Scenario to reproduce:
> {code:java}
> import groovy.transform.CompileStatic
> @CompileStatic
> class MapHolder {
>private Map map = [:]
>Map getMap() {
>   return map
>}
> }
> @CompileStatic
> static setMapValue() {
>MapHolder mapHolder = new MapHolder()
>mapHolder.map.key = 'value'
> }
> setMapValue()
> {code}
> Using the method *put* works just fine.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8652) Putting key on generic Map fails when using CompileStatic

[JIRA]

Cleydson José de Figueiredo Júnior created GROOVY-8652:
--

 Summary: Putting key on generic Map fails when using CompileStatic
 Key: GROOVY-8652
 URL: https://issues.apache.org/jira/browse/GROOVY-8652
 Project: Groovy
  Issue Type: Bug
  Components: Static compilation
Affects Versions: 2.5.0, 2.4.15, 3.0.0-alpha-2
 Environment: Elementary OS Freya 0.3.2
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
Reporter: Cleydson José de Figueiredo Júnior


I'm trying to use Groovy's short hand way to put a new key value to a 
encapsulated Map. But the compilation fails with:

 
{code:java}
[Static type checking] - Cannot assign value of type java.lang.String to 
variable of type ?   
{code}
 

Scenario to reproduce:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.map.key = 'value'
}

setMapValue()
{code}
Using the method *put* works just fine.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8652) Putting key on generic Map fails when using CompileStatic

[JIRA]

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

Cleydson José de Figueiredo Júnior updated GROOVY-8652:
---
Description: 
I'm trying to use Groovy's short hand way to put a new key value to an 
encapsulated Map. But the compilation fails with:

 
{code:java}
[Static type checking] - Cannot assign value of type java.lang.String to 
variable of type ?   
{code}
 

Scenario to reproduce:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.map.key = 'value'
}

setMapValue()
{code}
Using the method *put* works just fine:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.put('key', 'value')
}

setMapValue()
{code}
 

  was:
I'm trying to use Groovy's short hand way to put a new key value to an 
encapsulated Map. But the compilation fails with:

 
{code:java}
[Static type checking] - Cannot assign value of type java.lang.String to 
variable of type ?   
{code}
 

Scenario to reproduce:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.map.key = 'value'
}

setMapValue()
{code}
Using the method *put* works just fine.

 


> Putting key on generic Map fails when using CompileStatic
> -
>
>     Key: GROOVY-8652
> URL: https://issues.apache.org/jira/browse/GROOVY-8652
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 3.0.0-alpha-2, 2.4.15, 2.5.0
> Environment: Elementary OS Freya 0.3.2
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: Cleydson José de Figueiredo Júnior
>Priority: Minor
>  Labels: compilestatic
>
> I'm trying to use Groovy's short hand way to put a new key value to an 
> encapsulated Map. But the compilation fails with:
>  
> {code:java}
> [Static type checking] - Cannot assign value of type java.lang.String to 
> variable of type ?   
> {code}
>  
> Scenario to reproduce:
> {code:java}
> import groovy.transform.CompileStatic
> @CompileStatic
> class MapHolder {
>private Map map = [:]
>Map getMap() {
>   return map
>}
> }
> @CompileStatic
> static setMapValue() {
>MapHolder mapHolder = new MapHolder()
>mapHolder.map.key = 'value'
> }
> setMapValue()
> {code}
> Using the method *put* works just fine:
> {code:java}
> import groovy.transform.CompileStatic
> @CompileStatic
> class MapHolder {
>private Map map = [:]
>Map getMap() {
>   return map
>}
> }
> @CompileStatic
> static setMapValue() {
>MapHolder mapHolder = new MapHolder()
>mapHolder.put('key', 'value')
> }
> setMapValue()
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8652) Putting key on generic Map fails when using CompileStatic

[JIRA]

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

Cleydson José de Figueiredo Júnior updated GROOVY-8652:
---
Description: 
I'm trying to use Groovy's short hand way to put a new key value to an 
encapsulated Map. But the compilation fails with:

 
{code:java}
[Static type checking] - Cannot assign value of type java.lang.String to 
variable of type ?   
{code}
 

Scenario to reproduce:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.map.key = 'value'
}

setMapValue()
{code}
Using the *put* method works just fine:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.put('key', 'value')
}

setMapValue()
{code}
 

  was:
I'm trying to use Groovy's short hand way to put a new key value to an 
encapsulated Map. But the compilation fails with:

 
{code:java}
[Static type checking] - Cannot assign value of type java.lang.String to 
variable of type ?   
{code}
 

Scenario to reproduce:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.map.key = 'value'
}

setMapValue()
{code}
Using the method *put* works just fine:
{code:java}
import groovy.transform.CompileStatic

@CompileStatic
class MapHolder {
   private Map map = [:]

   Map getMap() {
  return map
   }
}

@CompileStatic
static setMapValue() {
   MapHolder mapHolder = new MapHolder()
   mapHolder.put('key', 'value')
}

setMapValue()
{code}
 


> Putting key on generic Map fails when using CompileStatic
> -
>
> Key: GROOVY-8652
> URL: https://issues.apache.org/jira/browse/GROOVY-8652
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 3.0.0-alpha-2, 2.4.15, 2.5.0
> Environment: Elementary OS Freya 0.3.2
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: Cleydson José de Figueiredo Júnior
>Priority: Minor
>  Labels: compilestatic
>
> I'm trying to use Groovy's short hand way to put a new key value to an 
> encapsulated Map. But the compilation fails with:
>  
> {code:java}
> [Static type checking] - Cannot assign value of type java.lang.String to 
> variable of type ?   
> {code}
>  
> Scenario to reproduce:
> {code:java}
> import groovy.transform.CompileStatic
> @CompileStatic
> class MapHolder {
>private Map map = [:]
>Map getMap() {
>   return map
>}
> }
> @CompileStatic
> static setMapValue() {
>MapHolder mapHolder = new MapHolder()
>mapHolder.map.key = 'value'
> }
> setMapValue()
> {code}
> Using the *put* method works just fine:
> {code:java}
> import groovy.transform.CompileStatic
> @CompileStatic
> class MapHolder {
>private Map map = [:]
>Map getMap() {
>   return map
>}
> }
> @CompileStatic
> static setMapValue() {
>MapHolder mapHolder = new MapHolder()
>mapHolder.put('key', 'value')
> }
> setMapValue()
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

Josef Härtl created GROOVY-8666:
---

 Summary: New partial groovy 2.5 causes split-packages itself
 Key: GROOVY-8666
 URL: https://issues.apache.org/jira/browse/GROOVY-8666
 Project: Groovy
  Issue Type: Bug
  Components: release, XML Processing
Affects Versions: 2.5.0
Reporter: Josef Härtl


The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our) or Java 9 (what we are migrating 
to): This presents a split-package itself: As we already reproduced in our 
build: Whatever jar of these is loaded first wins the groovy.util package and 
"overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl updated GROOVY-8666:

Description: 
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself.

  was:
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our) or Java 9 (what we are migrating 
to): This presents a split-package itself: As we already reproduced in our 
build: Whatever jar of these is loaded first wins the groovy.util package and 
"overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself.


> New partial groovy 2.5 causes split-packages itself
> ---
>
>     Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release, XML Processing
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Blocker
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl updated GROOVY-8666:

Description: 
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not. I consider this a very major problem 
as very serious problems can arise from that.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself.

  was:
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself.


> New partial groovy 2.5 causes split-packages itself
> ---
>
>     Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release, XML Processing
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Blocker
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem as very serious problems can arise from that.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl updated GROOVY-8666:

Description: 
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not. I consider this a very major problem 
as very serious problems can arise from that.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself. If one wants to split groovy, the split will have to 
follow package borders.

  was:
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not. I consider this a very major problem 
as very serious problems can arise from that.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself.


> New partial groovy 2.5 causes split-packages itself
> ---
>
>     Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release, XML Processing
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Blocker
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem as very serious problems can arise from that.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl updated GROOVY-8666:

Description: 
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not. I consider this a very major problem 
and a blocker as it makes execution unreliable and randomish.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself. If one wants to split groovy, the split will have to 
follow package borders.

  was:
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not. I consider this a very major problem 
as very serious problems can arise from that.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself. If one wants to split groovy, the split will have to 
follow package borders.


> New partial groovy 2.5 causes split-packages itself
> ---
>
>     Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release, XML Processing
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Blocker
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl updated GROOVY-8666:

Description: 
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not. I consider this a very major problem 
and a blocker as it makes execution unreliable and randomish. I did not check 
but somewhat guess that this is not the only collision of this sort.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself. If one wants to split groovy, the split will have to 
follow package borders.

  was:
The splitting of groovy into smaller causes another, very major, problem:

First, consider the "main" groovy jar: It contains the package groovy.util with 
numerous classes.

Secondly, consider the groovy-xml jar. It contains the package groovy.util and 
therein the classes XMLParser etc.

Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
migrating to): This presents a split-package itself: As we already reproduced 
in our build: Whatever jar of these is loaded first wins the groovy.util 
package and "overrides" the other.

As a result, it's become random whether our users can use XMLParser or not. 
Sometimes it is found, sometimes it's not. I consider this a very major problem 
and a blocker as it makes execution unreliable and randomish.

Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
split-packages to itself. If one wants to split groovy, the split will have to 
follow package borders.


> New partial groovy 2.5 causes split-packages itself
> ---
>
>     Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release, XML Processing
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Blocker
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

We're placing the jars on the classpath.

More specifically, we are placing them as OSGi-plugins on the classpath as of 
now. OSGi (and Java 9 as i see it) forbid overlapping packages and will only 
load the first one they see. Sometimes this will be groovy itself, sometimes it 
will be groovy-xml. I could only verify the OSGi standpoint by now since we're 
still migrating to java 9.

Modularity in terms of Jigsaw is not our primary concern as of now. It's just 
that as i see it, OSGi and Java 9 share the same premise: One package may only 
be hosted by one jar. Module-packages will win over classpath-packages but 
that's another story and not the point here.

> New partial groovy 2.5 causes split-packages itself
> ---
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Minor
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

Can't say anything regarding the smaller pieces as before version 2.5. Like so 
many others (compare GROOVY-8644) we always used the fat -all jar and merely 
discovered that such one does no longer exist as of 2.5.

As i understand Java 9 by now i don't think that the smaller jars will work on 
the module path either as their packages overlap. Up to Java 8 this was no 
problem, but from Java 9 on, this are split-packages as i see it.

What i can say for sure is however, that these split packages do cause problems 
with osgi. And from my point of understanding, Java 9 does behave very 
similarily.

> New partial groovy 2.5 causes split-packages itself
> ---
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Minor
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

Regarding Java 9: Considering your posts above and the reference 
implementations oracle itself suggests in JEP-320, maybe java 9 on classpath is 
indeed more relaxed about split-packages (as long they do not overlap with a 
module). So i'm dropping that point for now: Can't say for sure. Perhaps 
someone can.

Regarding OSGi: It eludes me why this is a minor bug. For OSGi-users this is 
quite a blocker. I see that it could be rather hard to fix without breaking 
structure and maintaining the split for java9. Perhaps version 3 will also help 
OSGi, but i guess version 3 isn't to be expected soon?

Would it be an intermediary option to release the "fat" jar under a different 
name, e.g. "-all-osgi"? That would relax things for OSGi quite a bit while 
clearly stating what it is for.

> New partial groovy 2.5 causes split-packages itself
> ---
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Minor
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl edited comment on GROOVY-8666 at 6/26/18 10:58 AM:
---

We're placing the jars on the classpath.

More specifically, we are placing them as OSGi-plugins on the classpath as of 
now. OSGi (and Java 9 as i see it (PS: Perhaps this really only affects the 
module path)) forbid overlapping packages and will only load the first one they 
see. Sometimes this will be groovy itself, sometimes it will be groovy-xml. I 
could only verify the OSGi standpoint by now since we're still migrating to 
java 9.

Modularity in terms of Jigsaw is not our primary concern as of now. It's just 
that as i see it, OSGi and Java 9 (PS: Perhaps really only on the module path) 
share the same premise: One package may only be hosted by one jar.


was (Author: josef härtl):
We're placing the jars on the classpath.

More specifically, we are placing them as OSGi-plugins on the classpath as of 
now. OSGi (and Java 9 as i see it) forbid overlapping packages and will only 
load the first one they see. Sometimes this will be groovy itself, sometimes it 
will be groovy-xml. I could only verify the OSGi standpoint by now since we're 
still migrating to java 9.

Modularity in terms of Jigsaw is not our primary concern as of now. It's just 
that as i see it, OSGi and Java 9 share the same premise: One package may only 
be hosted by one jar. Module-packages will win over classpath-packages but 
that's another story and not the point here.

> New partial groovy 2.5 causes split-packages itself
> ---
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Minor
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

Were there any special considerations for the fat jar-build then / what was the 
tooling you used?As long this isn't resolved i would at least like to reproduce 
the previous state as accurately as possible.

> New partial groovy 2.5 causes split-packages itself
> ---
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Major
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

I guess it's fair to restrict this ticket to the osgi aspect if the java module 
"split-package"-aspect is considered for version 3 anyway (sounded like that in 
your first statement).

I'll try the merge-workaround. Porting the gradle-approach did not seem 
feasible, but as i understand it, the adjustments to the package structure done 
by jarjar ("groovyjarjar") are part of the smaller jars as well anyway. 
So, effectively, the adjustments that would be made there are already done 
anyway. Actually makes lot of sense to keep the result the same, regardless if 
one uses smaller or all-jar.

Given that it seems rather probable that a 
extract-merge-repack-re-osgi-approach could work. I'll test that one out.

Still not sure whether it wouldn't be better if there still was an official 
"-all"-artifact, even if one named it "-osgi" to clarify who and who not should 
use it. Even if simply merging the jars myself works out in the end: In our 
case it lept through our tests and was only discovered by a beta-user who could 
sometimes not use XMLParser anymore. It could only be discovered if one 
excplicitly tested the separate features (which is rather unlikely if one 
simply used -all previously and did not draw the line between the features). I 
guess this could happen to other osgi-deployments as well if not advertised 
very explicitly.

 

Even Java 11's [JEP-320|http://openjdk.java.net/jeps/320]'s suggestion to 
replace parts of the removed modules with  [com.sun.xml.bind : 
jaxb-ri|https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-ri/2.3.0.1] 
has the same problem (jaxb-core splits jaxb-impl regarding com.sun.xml.bind), 
so the devs building the parts also provide a version for osgi 
([https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-osgi/2.3.0.1]) which 
is essentially a merge of all jaxb-parts. The devs of the zip, the jaxb-parts 
and the osgi-bundle are all the same according to maven. So i guess they did 
not find a better solution than merging too. 

> New partial groovy 2.5 causes split-packages itself
> ---
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Major
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

Another finding: I analysed our project for further split-packages and found 
that Eclipse RCP does in fact use split-packages successfully. It does so by 
defining OSGi Fragments instead of full bundles. The technique is for example 
described in here: 
[https://www.ibm.com/support/knowledgecenter/SSRTLW_8.5.5/com.ibm.osgi.common.doc/topics/cbundlefragment.html]
 . This way the fragment (in our case groovy-xml) could live inside the groovy 
bundle and add it's own classes.

> groovy-all pom approach breaks OSGi due to split-packages
> -
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Critical
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

[JIRA]

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

Josef Härtl edited comment on GROOVY-8666 at 6/29/18 11:41 AM:
---

Another finding: I analysed our project for further split-packages and found 
that Eclipse RCP does in fact use split-packages successfully. It does so by 
defining OSGi Fragments instead of full bundles. The technique is for example 
described in here: 
[https://www.ibm.com/support/knowledgecenter/SSRTLW_8.5.5/com.ibm.osgi.common.doc/topics/cbundlefragment.html]
 and 
[https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.fragmenthost].
 This way the fragment (in our case groovy-xml) could live inside the groovy 
bundle and add it's own classes.


was (Author: josef härtl):
Another finding: I analysed our project for further split-packages and found 
that Eclipse RCP does in fact use split-packages successfully. It does so by 
defining OSGi Fragments instead of full bundles. The technique is for example 
described in here: 
[https://www.ibm.com/support/knowledgecenter/SSRTLW_8.5.5/com.ibm.osgi.common.doc/topics/cbundlefragment.html]
 . This way the fragment (in our case groovy-xml) could live inside the groovy 
bundle and add it's own classes.

> groovy-all pom approach breaks OSGi due to split-packages
> -
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Critical
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

[JIRA]

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

Josef Härtl edited comment on GROOVY-8666 at 6/29/18 12:40 PM:
---

Another finding: I analysed our project for further split-packages and found 
that Eclipse RCP does in fact use split-packages successfully. It does so by 
defining OSGi Fragments instead of full bundles. The technique is for example 
described in here: 
[https://www.ibm.com/support/knowledgecenter/SSRTLW_8.5.5/com.ibm.osgi.common.doc/topics/cbundlefragment.html]
 and 
[https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.fragmenthost].
 This way the fragment (in our case groovy-xml) could live inside the groovy 
bundle and add it's own classes.

PS: Experiments with Eclipse RCP (our Client) und Equinox (our Server) in 
general suggest that including
{code:java}
Fragment-Host: groovy{code}
into the MANIFEST.MF of the groovy-*.jar indeed solves the 
split-package-problems.

Any OSGi experts around whether this would have any downsides?


was (Author: josef härtl):
Another finding: I analysed our project for further split-packages and found 
that Eclipse RCP does in fact use split-packages successfully. It does so by 
defining OSGi Fragments instead of full bundles. The technique is for example 
described in here: 
[https://www.ibm.com/support/knowledgecenter/SSRTLW_8.5.5/com.ibm.osgi.common.doc/topics/cbundlefragment.html]
 and 
[https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.fragmenthost].
 This way the fragment (in our case groovy-xml) could live inside the groovy 
bundle and add it's own classes.

> groovy-all pom approach breaks OSGi due to split-packages
> -
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Critical
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

OK, thank you. For that and your help in this matter in general.

Can't say much about the require-approach from a technical point of view. Only 
thing that comes to my mind about that: An empty "all-jar" could be quite a 
trap for non-osgi users finding it. I guess standard-Java will likely treat it 
as the empty jar it is. Given GROOVY-8644 the widespread use of the all-jar 
could attract lots of developers searching for such an all-jar. So, if going 
that way, one should name it very differently.

> groovy-all pom approach breaks OSGi due to split-packages
> -
>
> Key: GROOVY-8666
>     URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Priority: Critical
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

OK thanks.

I'll do some tests with the Snapshots in our application(s).

I agree to the presumption to include this only to 2.X, not to 3.X. Resolving 
the split in the package structure for java modules should also mend it for 
osgi.

On automatically testing it in a test suite: As unsatisfactory as it is: I'm 
unsure of how or even whether this can be done realistically.

The ones who initially designed our application once designed it w/o tests 
regarding osgi itself, they just did junit tests that considered the osgi 
bundles as plain java and mocked osgi apart. As one can see with this ticket, 
this won't always suffice. 

Some time ago we implemented some kind of verification-feature inside our 
application itself that can be used by our users, but also by ourselves to 
verify the application as a whole is behaving like it should and to verify it 
still behaves like in previous releases. That way it's tested in the most 
realistic way possible. Many tests in there are using groovy. However, the 
shadowed package area was smally enough to leap through our tests / did not 
interfere with them. Complex as they were, they did not use xml parsing of 
groovy.

I'm also increasing our tests for shadowing/split-packages in general. But this 
is also done without junit or the like. Instead, i'm analysing the structure of 
all our osgi bundles used by a custom script producing a list of potential 
overlaps to be examined by some of us. Only this way i can see all potential 
overlaps without relying on sheer luck testing the right thing at the right 
time. This way i also found the fragment-approach as eclipse itself makes much 
use of it.

Other than that, it's going to be difficult i'm afraid. Already testing out the 
bug of this ticket proved that: While our client (based on Eclipse RCP that's 
based on equinox) showed random behaviour whether XPathUtil would be present or 
not (depending on the loading order of the bundles), our server (equinox-jetty) 
more or less resorted to a state of constant denial. In the end 
shadowing/split-package-problems like this totally depend on the loading order. 
From then on, it can be random, never found or always occur. From a quick 
search: There seem to be some libraries for testing osgi inside an osgi 
environment. But in the end the results will heavily depend on their loading 
mechanism and configuration. As some kind of osgi-tester would have to include 
something like that, it would bias the result straight away.

So i'm a bit out of luck on that. Should some osgi expert come by, i would 
appreciate any input on automatically testing something like this myself.

> groovy-all pom approach breaks OSGi due to split-packages
> -
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Assignee: Paul King
>Priority: Critical
> Fix For: 2.5.1
>
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

[JIRA]

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

Josef Härtl edited comment on GROOVY-8666 at 7/2/18 5:54 AM:
-

OK thanks.

I'll do some tests with the Snapshots in our application(s).

I agree to the presumption to include this only to 2.X, not to 3.X. Resolving 
the split in the package structure for java modules should also mend it for 
osgi.

On automatically testing it in a test suite: As unsatisfactory as it is: I'm 
unsure of how or even whether this can be done realistically.

The ones who initially designed our application once designed it w/o tests 
regarding osgi itself, they just did junit tests that considered the osgi 
bundles as plain java and mocked osgi apart. As one can see with this ticket, 
this won't always suffice. 

Some time ago we implemented some kind of verification-feature inside our 
application itself that can be used by our users, but also by ourselves to 
verify the application as a whole is behaving like it should and to verify it 
still behaves like in previous releases. That way it's tested in the most 
realistic way possible. Many tests in there are using groovy. However, the 
shadowed package area was small enough to leap through our tests / did not 
interfere with them. Complex as they were, they did not use xml parsing of 
groovy.

I'm also increasing our tests for shadowing/split-packages in general. But this 
is also done without junit or the like. Instead, i'm analysing the structure of 
all our osgi bundles by a custom script producing a list of potential overlaps 
to be examined by some of us. Only this way i can see all potential overlaps 
without relying on sheer luck testing the right thing at the right time or 
relying on implementations. This way i also found the fragment-approach as 
eclipse itself makes much use of it.

Other than that, it's going to be difficult i'm afraid. Already testing out the 
bug of this ticket proved that: While our client (based on Eclipse RCP that's 
based on equinox) showed random behaviour whether XPathUtil would be present or 
not (depending on the loading order of the bundles), our server (equinox-jetty) 
more or less resorted to a state of constant denial. In the end 
shadowing/split-package-problems like this totally depend on the loading order. 
From then on, it can be random, never found or always occur. From a quick 
search: There seem to be some libraries for testing osgi inside an osgi 
environment. But in the end the results will heavily depend on their loading 
mechanism and configuration. As some kind of osgi-tester would have to include 
something like that, it would bias the result straight away.

So i'm a bit out of luck on that. Should some osgi expert come by, i would 
appreciate any input on automatically testing something like this myself.


was (Author: josef härtl):
OK thanks.

I'll do some tests with the Snapshots in our application(s).

I agree to the presumption to include this only to 2.X, not to 3.X. Resolving 
the split in the package structure for java modules should also mend it for 
osgi.

On automatically testing it in a test suite: As unsatisfactory as it is: I'm 
unsure of how or even whether this can be done realistically.

The ones who initially designed our application once designed it w/o tests 
regarding osgi itself, they just did junit tests that considered the osgi 
bundles as plain java and mocked osgi apart. As one can see with this ticket, 
this won't always suffice. 

Some time ago we implemented some kind of verification-feature inside our 
application itself that can be used by our users, but also by ourselves to 
verify the application as a whole is behaving like it should and to verify it 
still behaves like in previous releases. That way it's tested in the most 
realistic way possible. Many tests in there are using groovy. However, the 
shadowed package area was smally enough to leap through our tests / did not 
interfere with them. Complex as they were, they did not use xml parsing of 
groovy.

I'm also increasing our tests for shadowing/split-packages in general. But this 
is also done without junit or the like. Instead, i'm analysing the structure of 
all our osgi bundles used by a custom script producing a list of potential 
overlaps to be examined by some of us. Only this way i can see all potential 
overlaps without relying on sheer luck testing the right thing at the right 
time. This way i also found the fragment-approach as eclipse itself makes much 
use of it.

Other than that, it's going to be difficult i'm afraid. Already testing out the 
bug of this ticket proved that: While our client (based on Eclipse RCP that's 
based on equinox) showed random behaviour whether XPathUtil would b

[jira] [Comment Edited] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

[JIRA]

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

Josef Härtl edited comment on GROOVY-8666 at 7/2/18 6:02 AM:
-

OK thanks.

I'll do some tests with the Snapshots in our application(s). As soon 
[https://oss.jfrog.org/oss-snapshot-local/org/codehaus/groovy] gets back 
online... 

I agree to the presumption to include this only to 2.X, not to 3.X. Resolving 
the split in the package structure for java modules should also mend it for 
osgi.

On automatically testing it in a test suite: As unsatisfactory as it is: I'm 
unsure of how or even whether this can be done realistically.

The ones who initially designed our application once designed it w/o tests 
regarding osgi itself, they just did junit tests that considered the osgi 
bundles as plain java and mocked osgi apart. As one can see with this ticket, 
this won't always suffice. 

Some time ago we implemented some kind of verification-feature inside our 
application itself that can be used by our users, but also by ourselves to 
verify the application as a whole is behaving like it should and to verify it 
still behaves like in previous releases. That way it's tested in the most 
realistic way possible. Many tests in there are using groovy. However, the 
shadowed package area was small enough to leap through our tests / did not 
interfere with them. Complex as they were, they did not use xml parsing of 
groovy.

I'm also increasing our tests for shadowing/split-packages in general. But this 
is also done without junit or the like. Instead, i'm analysing the structure of 
all our osgi bundles by a custom script producing a list of potential overlaps 
to be examined by some of us. Only this way i can see all potential overlaps 
without relying on sheer luck testing the right thing at the right time or 
relying on implementations. This way i also found the fragment-approach as 
eclipse itself makes much use of it.

Other than that, it's going to be difficult i'm afraid. Already testing out the 
bug of this ticket proved that: While our client (based on Eclipse RCP that's 
based on equinox) showed random behaviour whether XPathUtil would be present or 
not (depending on the loading order of the bundles), our server (equinox-jetty) 
more or less resorted to a state of constant denial. In the end 
shadowing/split-package-problems like this totally depend on the loading order. 
From then on, it can be random, never found or always occur. From a quick 
search: There seem to be some libraries for testing osgi inside an osgi 
environment. But in the end the results will heavily depend on their loading 
mechanism and configuration. As some kind of osgi-tester would have to include 
something like that, it would bias the result straight away.

So i'm a bit out of luck on that. Should some osgi expert come by, i would 
appreciate any input on automatically testing something like this myself.


was (Author: josef härtl):
OK thanks.

I'll do some tests with the Snapshots in our application(s).

I agree to the presumption to include this only to 2.X, not to 3.X. Resolving 
the split in the package structure for java modules should also mend it for 
osgi.

On automatically testing it in a test suite: As unsatisfactory as it is: I'm 
unsure of how or even whether this can be done realistically.

The ones who initially designed our application once designed it w/o tests 
regarding osgi itself, they just did junit tests that considered the osgi 
bundles as plain java and mocked osgi apart. As one can see with this ticket, 
this won't always suffice. 

Some time ago we implemented some kind of verification-feature inside our 
application itself that can be used by our users, but also by ourselves to 
verify the application as a whole is behaving like it should and to verify it 
still behaves like in previous releases. That way it's tested in the most 
realistic way possible. Many tests in there are using groovy. However, the 
shadowed package area was small enough to leap through our tests / did not 
interfere with them. Complex as they were, they did not use xml parsing of 
groovy.

I'm also increasing our tests for shadowing/split-packages in general. But this 
is also done without junit or the like. Instead, i'm analysing the structure of 
all our osgi bundles by a custom script producing a list of potential overlaps 
to be examined by some of us. Only this way i can see all potential overlaps 
without relying on sheer luck testing the right thing at the right time or 
relying on implementations. This way i also found the fragment-approach as 
eclipse itself makes much use of it.

Other than that, it's going to be difficult i'm afraid. Already testing out the 
bug of this ticket proved that: Wh

[jira] [Commented] (GROOVY-8666) groovy-all pom approach breaks OSGi due to split-packages

[JIRA]

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

Josef Härtl commented on GROOVY-8666:
-

I did some tests.

Testing environment: Build of our client and server where the problem occured. 
Client: ~50%, server: ~100% failure.

In this environment i swapped out groovy 2.5.0 to Snapshots of 2.5.1 from 
02-Jul-2018 ~08:00.

Around at least 10 tests and restarts each: 0% failure on client, 0% failure on 
server.

--> Solution verified as working.

Thanks for your help :)

> groovy-all pom approach breaks OSGi due to split-packages
> -
>
> Key: GROOVY-8666
> URL: https://issues.apache.org/jira/browse/GROOVY-8666
> Project: Groovy
>  Issue Type: Bug
>  Components: release
>Affects Versions: 2.5.0
>Reporter: Josef Härtl
>Assignee: Paul King
>Priority: Critical
> Fix For: 2.5.1
>
>
> The splitting of groovy into smaller causes another, very major, problem:
> First, consider the "main" groovy jar: It contains the package groovy.util 
> with numerous classes.
> Secondly, consider the groovy-xml jar. It contains the package groovy.util 
> and therein the classes XMLParser etc.
> Regardless whether you use OSGi (like in our case) or Java 9 (what we are 
> migrating to): This presents a split-package itself: As we already reproduced 
> in our build: Whatever jar of these is loaded first wins the groovy.util 
> package and "overrides" the other.
> As a result, it's become random whether our users can use XMLParser or not. 
> Sometimes it is found, sometimes it's not. I consider this a very major 
> problem and a blocker as it makes execution unreliable and randomish. I did 
> not check but somewhat guess that this is not the only collision of this sort.
> Therefore, the splitting of groovy 2.5 into smaller pieces introduced 
> split-packages to itself. If one wants to split groovy, the split will have 
> to follow package borders.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8623) Groovy Object Browser within Groovy Console could show Groovy version in about help

[JIRA]

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

Jacek Musiał commented on GROOVY-8623:
--

Hello, World! I have made pull request to solve this task.
[https://github.com/apache/groovy/pull/771]

> Groovy Object Browser within Groovy Console could show Groovy version in 
> about help
> ---
>
> Key: GROOVY-8623
> URL: https://issues.apache.org/jira/browse/GROOVY-8623
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8701) StreamingTemplateEngine renders escaped character with backslash

[JIRA]

Szymon Stępaniak created GROOVY-8701:


 Summary: StreamingTemplateEngine renders escaped character with 
backslash
 Key: GROOVY-8701
 URL: https://issues.apache.org/jira/browse/GROOVY-8701
 Project: Groovy
  Issue Type: Bug
  Components: Templating
Affects Versions: 2.5.1
Reporter: Szymon Stępaniak


Using {{groovy.text.StreamingTemplateEngine}} to render a template containing 
escaped character (e.g. {{\$}}) produces output containing escape character. 
Using the same template with {{groovy.text.GStringTemplateEngine}} does not 
produce an output containing escape character.

The quickest way to reproduce the issue:

 
{code}
import groovy.text.StreamingTemplateEngine

def placeholders = [
  "StreamingTemplateEnginePlaceholder": "SOME_VALUE",
]
def templateContent = new File('test.php.template').text

def engine = new StreamingTemplateEngine()
def configContent = engine.createTemplate(templateContent)
  .make(placeholders)
  .toString()

println configContent
{code}

test.php.template

{code:php}

{code}

Output:

{code:php}

{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8701) StreamingTemplateEngine renders escaped character with backslash

[JIRA]

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

Szymon Stępniak commented on GROOVY-8701:
-

I would be more than happy if I could volunteer and fix this issue. Just need 
information if this bug report is reasonable and if there is a green light to 
start working on the fix.

> StreamingTemplateEngine renders escaped character with backslash
> 
>
> Key: GROOVY-8701
> URL: https://issues.apache.org/jira/browse/GROOVY-8701
> Project: Groovy
>  Issue Type: Bug
>  Components: Templating
>Affects Versions: 2.5.1
>Reporter: Szymon Stępniak
>Priority: Minor
>
> Using {{groovy.text.StreamingTemplateEngine}} to render a template containing 
> escaped character (e.g. {{\$}}) produces output containing escape character. 
> Using the same template with {{groovy.text.GStringTemplateEngine}} does not 
> produce an output containing escape character.
> The quickest way to reproduce the issue:
>  
> {code}
> import groovy.text.StreamingTemplateEngine
> def placeholders = [
>   "StreamingTemplateEnginePlaceholder": "SOME_VALUE",
> ]
> def templateContent = new File('test.php.template').text
> def engine = new StreamingTemplateEngine()
> def configContent = engine.createTemplate(templateContent)
>   .make(placeholders)
>   .toString()
> println configContent
> {code}
> test.php.template
> {code:php}
>  \$my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
> ?>
> {code}
> Output:
> {code:php}
>  \$my_php_config_variable = "SOME_VALUE"
> ?>
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8701) StreamingTemplateEngine renders escaped character with backslash

[JIRA]

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

Szymon Stępniak updated GROOVY-8701:

Description: 
Using {{groovy.text.StreamingTemplateEngine}} to render a template containing 
escaped character (e.g. {{\$}}) produces output containing escape character. 
Using the same template with {{groovy.text.GStringTemplateEngine}} does not 
produce an output containing escape character.

The quickest way to reproduce the issue:

 
{code}
import groovy.text.StreamingTemplateEngine

def placeholders = [
  "StreamingTemplateEnginePlaceholder": "SOME_VALUE",
]
def templateContent = new File('test.php.template').text

def engine = new StreamingTemplateEngine()
def configContent = engine.createTemplate(templateContent)
  .make(placeholders)
  .toString()

println configContent
{code}

test.php.template

{code:php}

{code}

Output:

{code:php}

{code}

When template does not escape dollar character then rendering such a template 
produces following exception:

{code:bash}
Caught: groovy.text.TemplateExecutionException: Template execution error at 
line 2:
 1:  2: $my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
 3: ?>

groovy.text.TemplateExecutionException: Template execution error at line 2:
 1:  2: $my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
 3: ?>

at test.run(test.groovy:9)
Caused by: groovy.lang.MissingPropertyException: No such property: 
my_php_config_variable for class: groovy.tmp.templates.StreamingTemplateScript1
... 1 more
{code}

  was:
Using {{groovy.text.StreamingTemplateEngine}} to render a template containing 
escaped character (e.g. {{\$}}) produces output containing escape character. 
Using the same template with {{groovy.text.GStringTemplateEngine}} does not 
produce an output containing escape character.

The quickest way to reproduce the issue:

 
{code}
import groovy.text.StreamingTemplateEngine

def placeholders = [
  "StreamingTemplateEnginePlaceholder": "SOME_VALUE",
]
def templateContent = new File('test.php.template').text

def engine = new StreamingTemplateEngine()
def configContent = engine.createTemplate(templateContent)
  .make(placeholders)
  .toString()

println configContent
{code}

test.php.template

{code:php}

{code}

Output:

{code:php}

{code}


> StreamingTemplateEngine renders escaped character with backslash
> ----
>
> Key: GROOVY-8701
> URL: https://issues.apache.org/jira/browse/GROOVY-8701
> Project: Groovy
>  Issue Type: Bug
>  Components: Templating
>Affects Versions: 2.5.1
>Reporter: Szymon Stępniak
>Priority: Minor
>
> Using {{groovy.text.StreamingTemplateEngine}} to render a template containing 
> escaped character (e.g. {{\$}}) produces output containing escape character. 
> Using the same template with {{groovy.text.GStringTemplateEngine}} does not 
> produce an output containing escape character.
> The quickest way to reproduce the issue:
>  
> {code}
> import groovy.text.StreamingTemplateEngine
> def placeholders = [
>   "StreamingTemplateEnginePlaceholder": "SOME_VALUE",
> ]
> def templateContent = new File('test.php.template').text
> def engine = new StreamingTemplateEngine()
> def configContent = engine.createTemplate(templateContent)
>   .make(placeholders)
>   .toString()
> println configContent
> {code}
> test.php.template
> {code:php}
>  \$my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
> ?>
> {code}
> Output:
> {code:php}
>  \$my_php_config_variable = "SOME_VALUE"
> ?>
> {code}
> When template does not escape dollar character then rendering such a template 
> produces following exception:
> {code:bash}
> Caught: groovy.text.TemplateExecutionException: Template execution error at 
> line 2:
>  1:   --> 2: $my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
>  3: ?>
> groovy.text.TemplateExecutionException: Template execution error at line 2:
>  1:   --> 2: $my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
>  3: ?>
>   at test.run(test.groovy:9)
> Caused by: groovy.lang.MissingPropertyException: No such property: 
> my_php_config_variable for class: 
> groovy.tmp.templates.StreamingTemplateScript1
>   ... 1 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8701) StreamingTemplateEngine renders escaped character with backslash

[JIRA]

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

Szymon Stępniak commented on GROOVY-8701:
-

I have found following comment in the source code - 
[https://github.com/apache/groovy/blob/0aba754d9e31828644027f98099c301a192aa351/subprojects/groovy-templates/src/main/groovy/groovy/text/StreamingTemplateEngine.java#L562]
 It suggests that keeping a single backslash when it is not followed by {{${}} 
is done on purpose. However it introduces inconsistency - 
StreamingTemplateEngine groovydoc says:
{quote}This engine has equivalent functionality to the \{@link 
groovy.text.SimpleTemplateEngine} but creates the template using writable 
closures making it more scalable for large templates.
{quote}
but it does not produce the same output as SimpleTemplateEngine. When I pass 
the same template to the SimpleTemplateEngine it escapes \$ and removes 
backslash from the parsed template. What do you think about this situation? 
Should StreamingTemplateEngine produce the same output? I'm guessing that it 
shouldn't produce different output. 

I'm willing to work on that. Please share any feedback.

> StreamingTemplateEngine renders escaped character with backslash
> 
>
> Key: GROOVY-8701
>     URL: https://issues.apache.org/jira/browse/GROOVY-8701
> Project: Groovy
>  Issue Type: Bug
>  Components: Templating
>Affects Versions: 2.5.1
>Reporter: Szymon Stępniak
>Priority: Minor
>
> Using {{groovy.text.StreamingTemplateEngine}} to render a template containing 
> escaped character (e.g. {{\$}}) produces output containing escape character. 
> Using the same template with {{groovy.text.GStringTemplateEngine}} does not 
> produce an output containing escape character.
> The quickest way to reproduce the issue:
>  
> {code}
> import groovy.text.StreamingTemplateEngine
> def placeholders = [
>   "StreamingTemplateEnginePlaceholder": "SOME_VALUE",
> ]
> def templateContent = new File('test.php.template').text
> def engine = new StreamingTemplateEngine()
> def configContent = engine.createTemplate(templateContent)
>   .make(placeholders)
>   .toString()
> println configContent
> {code}
> test.php.template
> {code:php}
>  \$my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
> ?>
> {code}
> Output:
> {code:php}
>  \$my_php_config_variable = "SOME_VALUE"
> ?>
> {code}
> When template does not escape dollar character then rendering such a template 
> produces following exception:
> {code:bash}
> Caught: groovy.text.TemplateExecutionException: Template execution error at 
> line 2:
>  1:   --> 2: $my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
>  3: ?>
> groovy.text.TemplateExecutionException: Template execution error at line 2:
>  1:   --> 2: $my_php_config_variable = "${StreamingTemplateEnginePlaceholder}"
>  3: ?>
>   at test.run(test.groovy:9)
> Caused by: groovy.lang.MissingPropertyException: No such property: 
> my_php_config_variable for class: 
> groovy.tmp.templates.StreamingTemplateScript1
>   ... 1 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8708) SyntaxException when extending groovy.lang.Script

[JIRA]

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

Brongniart Jérôme updated GROOVY-8708:
--
Description: 
We are facing an issue when using the following groovy script is used as a 
ScriptBaseClass with version 2.3.0 or greater:
{code:java}
abstract class Templates extends Script {
def test() {
def a = [];
return a;
}
}
{code}
 Error:
{noformat}
Script1.groovy: 1: A transform used a generics containing ClassNode Templates 
for the super class Script1 directly. You are not supposed to do this. Please 
create a new ClassNode referring to the old ClassNode and use the new ClassNode 
instead of the old one. Otherwise the compiler will create wrong descriptors 
and a potential NullPointerException in TypeResolver in the OpenJDK. If this is 
not your own doing, please report this bug to the writer of the transform.
{noformat}
The error happens when calling the following example (This example is working 
as expected when using Groovy 2.2.2):
{code:java}
import java.io.IOException;
import org.codehaus.groovy.control.CompilationFailedException;
import org.codehaus.groovy.control.CompilerConfiguration;
import groovy.lang.GroovyShell;
import groovy.lang.Script;

public class GroovyTest {

public static void main(String[] args) throws 
CompilationFailedException, IOException {

CompilerConfiguration groovyCompilerConfiguration = new 
CompilerConfiguration();
groovyCompilerConfiguration.setScriptBaseClass("Templates");
groovyCompilerConfiguration.setDebug(true);
groovyCompilerConfiguration.setVerbose(true);

GroovyShell shell = new 
GroovyShell(groovyCompilerConfiguration);
Script script = shell.parse("print \"test\"");
}

}
{code}
Is this an issue from Groovy or is this change expected?

Thanks and regards

  was:
We are facing an issue when using the following groovy script is used as a 
ScriptBaseClass with version 2.3.0 or greater:
{code:java}
abstract class Templates extends Script {
def test() {
def a = [];
return a;
}
}
{code}
 Error:
{noformat}
Script1.groovy: 1: A transform used a generics containing ClassNode Templates 
for the super class Script1 directly. You are not supposed to do this. Please 
create a new ClassNode referring to the old ClassNode and use the new ClassNode 
instead of the old one. Otherwise the compiler will create wrong descriptors 
and a potential NullPointerException in TypeResolver in the OpenJDK. If this is 
not your own doing, please report this bug to the writer of the transform.
{noformat}
The error happens when calling the following example (This example is working 
as expected when using Groovy 2.2.2):
{code:java}
import java.io.IOException;
import org.codehaus.groovy.control.CompilationFailedException;
import org.codehaus.groovy.control.CompilerConfiguration;
import groovy.lang.GroovyShell;
import groovy.lang.Script;

public class GroovyTest {

public static void main(String[] args) throws 
CompilationFailedException, IOException {

CompilerConfiguration groovyCompilerConfiguration = new 
CompilerConfiguration();
groovyCompilerConfiguration.setScriptBaseClass("Templates");
groovyCompilerConfiguration.setDebug(true);
groovyCompilerConfiguration.setVerbose(true);

GroovyShell shell = new 
GroovyShell(groovyCompilerConfiguration);
Script script = shell.parse("print \"test\"");
}

}
{code}
If this an issue from Groovy or is this change expected?

Thanks and regards


> SyntaxException when extending groovy.lang.Script
> -
>
>     Key: GROOVY-8708
> URL: https://issues.apache.org/jira/browse/GROOVY-8708
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 2.3.0
>Reporter: Brongniart Jérôme
>Priority: Major
>
> We are facing an issue when using the following groovy script is used as a 
> ScriptBaseClass with version 2.3.0 or greater:
> {code:java}
> abstract class Templates extends Script {
> def test() {
> def a = [];
> return a;
> }
> }
> {code}
>  Error:
> {noformat}
> Script1.groovy: 1: A transform used a generics containing ClassNode Templates 
> for the super class Script1 directly. You are not supposed to do this. Please 
> create a new ClassNode referring to the old ClassNode and use the new 
> ClassNode instead of the old one. Otherwise the compiler will create wrong 
> descriptors and a potential NullPointerException i

[jira] [Created] (GROOVY-8708) SyntaxException when extending groovy.lang.Script

[JIRA]

Brongniart Jérôme created GROOVY-8708:
-

 Summary: SyntaxException when extending groovy.lang.Script
 Key: GROOVY-8708
 URL: https://issues.apache.org/jira/browse/GROOVY-8708
 Project: Groovy
  Issue Type: Bug
  Components: Compiler
Affects Versions: 2.3.0
Reporter: Brongniart Jérôme


We are facing an issue when using the following groovy script is used as a 
ScriptBaseClass with version 2.3.0 or greater:
{code:java}
abstract class Templates extends Script {
def test() {
def a = [];
return a;
}
}
{code}
 Error:
{noformat}
Script1.groovy: 1: A transform used a generics containing ClassNode Templates 
for the super class Script1 directly. You are not supposed to do this. Please 
create a new ClassNode referring to the old ClassNode and use the new ClassNode 
instead of the old one. Otherwise the compiler will create wrong descriptors 
and a potential NullPointerException in TypeResolver in the OpenJDK. If this is 
not your own doing, please report this bug to the writer of the transform.
{noformat}
The error happens when calling the following example (This example is working 
as expected when using Groovy 2.2.2):
{code:java}
import java.io.IOException;
import org.codehaus.groovy.control.CompilationFailedException;
import org.codehaus.groovy.control.CompilerConfiguration;
import groovy.lang.GroovyShell;
import groovy.lang.Script;

public class GroovyTest {

public static void main(String[] args) throws 
CompilationFailedException, IOException {

CompilerConfiguration groovyCompilerConfiguration = new 
CompilerConfiguration();
groovyCompilerConfiguration.setScriptBaseClass("Templates");
groovyCompilerConfiguration.setDebug(true);
groovyCompilerConfiguration.setVerbose(true);

GroovyShell shell = new 
GroovyShell(groovyCompilerConfiguration);
Script script = shell.parse("print \"test\"");
}

}
{code}
If this an issue from Groovy or is this change expected?

Thanks and regards



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8695) @Delegate does not compile deterministically

[JIRA]

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

Lóránt Pintér updated GROOVY-8695:
--
Attachment: ConcurrentSpecification-with-groovy-2.4.15.zip

> @Delegate does not compile deterministically
> 
>
> Key: GROOVY-8695
> URL: https://issues.apache.org/jira/browse/GROOVY-8695
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Luke Daley
>Priority: Major
> Attachments: ConcurrentSpecification-with-groovy-2.4.15.zip, 
> ConcurrentSpecification.class, ConcurrentSpecification.class
>
>
> Checkout gradle/gradle from Github, run:
> ```
> ./gradlew core:cleanCompileTestFixturesGroovy core:compileTestFixturesGroovy 
> --no-build-cache && md5 
> subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class
> ```
> This class is super thin: 
> [https://github.com/gradle/gradle/blob/a1b9612fa06f90f20b115cede557e22287501034/subprojects/core/src/testFixtures/groovy/org/gradle/util/ConcurrentSpecification.groovy#L23]
>  
> Guess is that it is `@Delegate` or `@Delegate` in conjunction with Spock
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8695) @Delegate does not compile deterministically

[JIRA]

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

Lóránt Pintér commented on GROOVY-8695:
---

I tried to run this with a Gradle 4.10 nightly that uses Groovy 2.4.15:

{code}
./gradlew core:cleanCompileTestFixturesGroovy core:compileTestFixturesGroovy 
--no-build-cache; md5 
subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class
{code}

It still results in different MD5s being generated:

{code}
MD5 
(subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class)
 = cebcafb31a5fb7114e3f65ae72c5d12a
MD5 
(subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class)
 = 6a7fef52e516b317355c6cd0fddf7f94
MD5 
(subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class)
 = f2600a8b15ff00051a6b4beb827f413b
{code}

That means this issue is not yet resolved.

> @Delegate does not compile deterministically
> 
>
> Key: GROOVY-8695
> URL: https://issues.apache.org/jira/browse/GROOVY-8695
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Luke Daley
>Priority: Major
> Attachments: ConcurrentSpecification-with-groovy-2.4.15.zip, 
> ConcurrentSpecification.class, ConcurrentSpecification.class
>
>
> Checkout gradle/gradle from Github, run:
> ```
> ./gradlew core:cleanCompileTestFixturesGroovy core:compileTestFixturesGroovy 
> --no-build-cache && md5 
> subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class
> ```
> This class is super thin: 
> [https://github.com/gradle/gradle/blob/a1b9612fa06f90f20b115cede557e22287501034/subprojects/core/src/testFixtures/groovy/org/gradle/util/ConcurrentSpecification.groovy#L23]
>  
> Guess is that it is `@Delegate` or `@Delegate` in conjunction with Spock
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8695) @Delegate does not compile deterministically

[JIRA]

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

Lóránt Pintér commented on GROOVY-8695:
---

I've attached ConcurrentSpecification-with-groovy-2.4.15.zip with a couple 
different class file versions.

> @Delegate does not compile deterministically
> 
>
> Key: GROOVY-8695
> URL: https://issues.apache.org/jira/browse/GROOVY-8695
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Luke Daley
>Priority: Major
> Attachments: ConcurrentSpecification-with-groovy-2.4.15.zip, 
> ConcurrentSpecification.class, ConcurrentSpecification.class
>
>
> Checkout gradle/gradle from Github, run:
> ```
> ./gradlew core:cleanCompileTestFixturesGroovy core:compileTestFixturesGroovy 
> --no-build-cache && md5 
> subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class
> ```
> This class is super thin: 
> [https://github.com/gradle/gradle/blob/a1b9612fa06f90f20b115cede557e22287501034/subprojects/core/src/testFixtures/groovy/org/gradle/util/ConcurrentSpecification.groovy#L23]
>  
> Guess is that it is `@Delegate` or `@Delegate` in conjunction with Spock
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8695) @Delegate does not compile deterministically

[JIRA]

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

Lóránt Pintér commented on GROOVY-8695:
---

>From the {{javap}} output it looks like the order of (delegate?) methods is 
>different between the different versions of the output.

> @Delegate does not compile deterministically
> 
>
> Key: GROOVY-8695
> URL: https://issues.apache.org/jira/browse/GROOVY-8695
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Luke Daley
>Priority: Major
> Attachments: ConcurrentSpecification-with-groovy-2.4.15.zip, 
> ConcurrentSpecification.class, ConcurrentSpecification.class
>
>
> Checkout gradle/gradle from Github, run:
> ```
> ./gradlew core:cleanCompileTestFixturesGroovy core:compileTestFixturesGroovy 
> --no-build-cache && md5 
> subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class
> ```
> This class is super thin: 
> [https://github.com/gradle/gradle/blob/a1b9612fa06f90f20b115cede557e22287501034/subprojects/core/src/testFixtures/groovy/org/gradle/util/ConcurrentSpecification.groovy#L23]
>  
> Guess is that it is `@Delegate` or `@Delegate` in conjunction with Spock
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8695) @Delegate does not compile deterministically

[JIRA]

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

Lóránt Pintér commented on GROOVY-8695:
---

[~paulk] Groovy 2.4.1 is a dependency of the Spock framework, and it gets 
upgraded to 2.4.15. Here it is in the build scan: 
https://scans.gradle.com/s/q5leuivalqfws/dependencies?focusedDependency=WzE2LDAsNDM5LFsxNiwwLFs0MzldXV0&focusedDependencyDependenciesToggled=W1s0NzgsMTYwXSxbNDc4LDE2MV0sWzQ3OCw0NDBdXQ&toggled=W1sxNl0sWzE2LDBdXQ

> @Delegate does not compile deterministically
> 
>
> Key: GROOVY-8695
> URL: https://issues.apache.org/jira/browse/GROOVY-8695
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Luke Daley
>Priority: Major
> Attachments: ConcurrentSpecification-with-groovy-2.4.15.zip, 
> ConcurrentSpecification.class, ConcurrentSpecification.class
>
>
> Checkout gradle/gradle from Github, run:
> ```
> ./gradlew core:cleanCompileTestFixturesGroovy core:compileTestFixturesGroovy 
> --no-build-cache && md5 
> subprojects/core/build/classes/groovy/testFixtures/org/gradle/util/ConcurrentSpecification.class
> ```
> This class is super thin: 
> [https://github.com/gradle/gradle/blob/a1b9612fa06f90f20b115cede557e22287501034/subprojects/core/src/testFixtures/groovy/org/gradle/util/ConcurrentSpecification.groovy#L23]
>  
> Guess is that it is `@Delegate` or `@Delegate` in conjunction with Spock
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8732) @CompileStatic refers to private field in parent class

[JIRA]

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

Lóránt Pintér updated GROOVY-8732:
--
Summary: @CompileStatic refers to private field in parent class  (was: 
@CompileStatic accesses private field in parent class)

> @CompileStatic refers to private field in parent class
> --
>
> Key: GROOVY-8732
> URL: https://issues.apache.org/jira/browse/GROOVY-8732
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.15, 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.1
>Reporter: Lóránt Pintér
>Priority: Major
>
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> interface Thing {
> void call()
> }
> @CompileStatic
> class ThingImpl implements Thing {
> void call() {}
> }
> @CompileStatic
> class Parent {
> private final ThingImpl thing
> public Thing getThing() { null }
> }
> @CompileStatic
> class Child extends Parent {
> public void doSomething() {
> thing.call()
> }
> }
> {code}
> Compile via: {{groovyc Example.groovy}}.
> The line {{thing.call}} in {{Child.doSomething()}} calls {{getThing()}}, but 
> then ends up referring to the returned value according to the private field's 
> type from {{Parent}} ({{ThingImpl}}) instead of the actual returned type 
> ({{Thing}}). The private field from {{Parent}} (or its type) should not be 
> visible to {{Child}} at all.
> {code}
>   public void doSomething();
> descriptor: ()V
> flags: (0x0001) ACC_PUBLIC
> Code:
>   stack=1, locals=1, args_size=1
>  0: aload_0
>  1: invokevirtual #20 // Method 
> Parent.getThing:()LThing;
>  4: checkcast #22 // class ThingImpl
>  7: invokevirtual #25 // Method ThingImpl.call:()V
> 10: aconst_null
> 11: pop
> 12: return
> {code}
> This is causing now problems for Gradle plugins compiled against Grade 4.9 or 
> before trying to run on Gradle 4.9, because we've made a change to an 
> internal type (`ProjectInternal`) that ended up being referred to via this 
> bug in compiled and released code. See 
> https://github.com/gradle/gradle/issues/6027



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8732) @CompileStatic allows access to private field in parent class

[JIRA]

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

Lóránt Pintér updated GROOVY-8732:
--
Summary: @CompileStatic allows access to private field in parent class  
(was: @CompileStatic allows access to private )

> @CompileStatic allows access to private field in parent class
> -
>
> Key: GROOVY-8732
> URL: https://issues.apache.org/jira/browse/GROOVY-8732
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.15, 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.1
>Reporter: Lóránt Pintér
>Priority: Major
>
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> interface Thing {
> void call()
> }
> @CompileStatic
> class ThingImpl implements Thing {
> void call() {}
> }
> @CompileStatic
> class Parent {
> private final ThingImpl thing
> public Thing getThing() { null }
> }
> @CompileStatic
> class Child extends Parent {
> public void doSomething() {
> thing.call()
> }
> }
> {code}
> Compile via: {{groovyc Example.groovy}}.
> The line {{thing.call}} in {{Child.doSomething()}} calls {{getThing()}}, but 
> then ends up referring to the returned value according to the private field's 
> type from {{Parent}} ({{ThingImpl}}) instead of the actual returned type 
> ({{Thing}}). The private field from {{Parent}} (or its type) should not be 
> visible to {{Child}} at all.
> {code}
>   public void doSomething();
> descriptor: ()V
> flags: (0x0001) ACC_PUBLIC
> Code:
>   stack=1, locals=1, args_size=1
>  0: aload_0
>  1: invokevirtual #20 // Method 
> Parent.getThing:()LThing;
>  4: checkcast #22 // class ThingImpl
>  7: invokevirtual #25 // Method ThingImpl.call:()V
> 10: aconst_null
> 11: pop
> 12: return
> {code}
> This is causing now problems for Gradle plugins compiled against Grade 4.9 or 
> before trying to run on Gradle 4.9, because we've made a change to an 
> internal type (`ProjectInternal`) that ended up being referred to via this 
> bug in compiled and released code. See 
> https://github.com/gradle/gradle/issues/6027



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8732) @CompileStatic accesses private field in parent class

[JIRA]

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

Lóránt Pintér updated GROOVY-8732:
--
Summary: @CompileStatic accesses private field in parent class  (was: 
@CompileStatic allows access to private field in parent class)

> @CompileStatic accesses private field in parent class
> -
>
> Key: GROOVY-8732
> URL: https://issues.apache.org/jira/browse/GROOVY-8732
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.15, 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.1
>Reporter: Lóránt Pintér
>Priority: Major
>
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> interface Thing {
> void call()
> }
> @CompileStatic
> class ThingImpl implements Thing {
> void call() {}
> }
> @CompileStatic
> class Parent {
> private final ThingImpl thing
> public Thing getThing() { null }
> }
> @CompileStatic
> class Child extends Parent {
> public void doSomething() {
> thing.call()
> }
> }
> {code}
> Compile via: {{groovyc Example.groovy}}.
> The line {{thing.call}} in {{Child.doSomething()}} calls {{getThing()}}, but 
> then ends up referring to the returned value according to the private field's 
> type from {{Parent}} ({{ThingImpl}}) instead of the actual returned type 
> ({{Thing}}). The private field from {{Parent}} (or its type) should not be 
> visible to {{Child}} at all.
> {code}
>   public void doSomething();
> descriptor: ()V
> flags: (0x0001) ACC_PUBLIC
> Code:
>   stack=1, locals=1, args_size=1
>  0: aload_0
>  1: invokevirtual #20 // Method 
> Parent.getThing:()LThing;
>  4: checkcast #22 // class ThingImpl
>  7: invokevirtual #25 // Method ThingImpl.call:()V
> 10: aconst_null
> 11: pop
> 12: return
> {code}
> This is causing now problems for Gradle plugins compiled against Grade 4.9 or 
> before trying to run on Gradle 4.9, because we've made a change to an 
> internal type (`ProjectInternal`) that ended up being referred to via this 
> bug in compiled and released code. See 
> https://github.com/gradle/gradle/issues/6027



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8732) @CompileStatic allows access to private

[JIRA]

Lóránt Pintér created GROOVY-8732:
-

 Summary: @CompileStatic allows access to private 
 Key: GROOVY-8732
 URL: https://issues.apache.org/jira/browse/GROOVY-8732
 Project: Groovy
  Issue Type: Bug
  Components: Static compilation
Affects Versions: 2.5.1, 3.0.0-alpha-3, 2.6.0-alpha-4, 2.4.15
Reporter: Lóránt Pintér


{code}
import groovy.transform.CompileStatic

@CompileStatic
interface Thing {
void call()
}

@CompileStatic
class ThingImpl implements Thing {
void call() {}
}

@CompileStatic
class Parent {
private final ThingImpl thing

public Thing getThing() { null }
}

@CompileStatic
class Child extends Parent {
public void doSomething() {
thing.call()
}
}
{code}

Compile via: {{groovyc Example.groovy}}.

The line {{thing.call}} in {{Child.doSomething()}} calls {{getThing()}}, but 
then ends up referring to the returned value according to the private field's 
type from {{Parent}} ({{ThingImpl}}) instead of the actual returned type 
({{Thing}}). The private field from {{Parent}} (or its type) should not be 
visible to {{Child}} at all.

{code}
  public void doSomething();
descriptor: ()V
flags: (0x0001) ACC_PUBLIC
Code:
  stack=1, locals=1, args_size=1
 0: aload_0
 1: invokevirtual #20 // Method 
Parent.getThing:()LThing;
 4: checkcast #22 // class ThingImpl
 7: invokevirtual #25 // Method ThingImpl.call:()V
10: aconst_null
11: pop
12: return
{code}

This is causing now problems for Gradle plugins compiled against Grade 4.9 or 
before trying to run on Gradle 4.9, because we've made a change to an internal 
type (`ProjectInternal`) that ended up being referred to via this bug in 
compiled and released code. See https://github.com/gradle/gradle/issues/6027



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8739) groovysh can't evaluate slashy strings

[JIRA]

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

Роман Донченко updated GROOVY-8739:
---
Description: 
If you type a slashy string into groovysh, it expects more input instead of 
evaluating it:
{code:java}
groovy:000> /abc/
groovy:001{code}
I know slashy strings can be ambiguous, but that shouldn't be an issue here, 
since an expression can't begin with a division operator.

  was:
If you type in a slashy string into groovysh, it expects more input instead of 
evaluating it:
{code:java}
groovy:000> /abc/
groovy:001{code}
I know slashy strings can be ambiguous, but that shouldn't be an issue here, 
since an expression can't begin with a division operator.


> groovysh can't evaluate slashy strings
> --
>
> Key: GROOVY-8739
>     URL: https://issues.apache.org/jira/browse/GROOVY-8739
> Project: Groovy
>  Issue Type: Bug
>  Components: Groovysh
>Affects Versions: 3.0.0-alpha-3, 2.5.1
>Reporter: Роман Донченко
>Priority: Minor
>
> If you type a slashy string into groovysh, it expects more input instead of 
> evaluating it:
> {code:java}
> groovy:000> /abc/
> groovy:001{code}
> I know slashy strings can be ambiguous, but that shouldn't be an issue here, 
> since an expression can't begin with a division operator.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8739) groovysh can't evaluate slashy strings

[JIRA]

Роман Донченко created GROOVY-8739:
--

 Summary: groovysh can't evaluate slashy strings
 Key: GROOVY-8739
 URL: https://issues.apache.org/jira/browse/GROOVY-8739
 Project: Groovy
  Issue Type: Bug
  Components: Groovysh
Affects Versions: 2.5.1, 3.0.0-alpha-3
Reporter: Роман Донченко


If you type in a slashy string into groovysh, it expects more input instead of 
evaluating it:
{code:java}
groovy:000> /abc/
groovy:001{code}
I know slashy strings can be ambiguous, but that shouldn't be an issue here, 
since an expression can't begin with a division operator.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8740) groovy.util.CliBuilder doesn't handle parse errors correctly

[JIRA]

Роман Донченко created GROOVY-8740:
--

 Summary: groovy.util.CliBuilder doesn't handle parse errors 
correctly
 Key: GROOVY-8740
 URL: https://issues.apache.org/jira/browse/GROOVY-8740
 Project: Groovy
  Issue Type: Bug
  Components: groovy-jdk
Affects Versions: 2.5.1
Reporter: Роман Донченко


In Groovy 2.5, {{groovy.util.CliBuilder}} is a wrapper that delegates to 
{{groovy.cli.commons.CliBuilder}}. However, this wrapper doesn't correctly 
handle the case when the arguments fail to be parsed.

Here's how it works with the real {{CliBuilder}}:
{code:java}
groovy:000> options = new groovy.cli.commons.CliBuilder(stopAtNonOption: 
false).parse(['-x'])
error: Unrecognized option: -x
usage: groovy

===> null{code}
And here's what happens with the wrapper:
{code:java}
groovy:000> options = new groovy.util.CliBuilder(stopAtNonOption: 
false).parse(['-x'])
error: Unrecognized option: -x
usage: groovy

===> groovy.util.OptionAccessor@6fc3e1a4
groovy:000> options.arguments()
ERROR java.lang.NullPointerException:
Cannot invoke method arguments() on null object{code}
I get an object that pretends to be {{null}}, but isn't. So I can't determine 
whether the parsing was successful or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8741) Single character GString and '==' with Character or Number

[JIRA]

Mikko Värri created GROOVY-8741:
---

 Summary: Single character GString and '==' with Character or Number
 Key: GROOVY-8741
 URL: https://issues.apache.org/jira/browse/GROOVY-8741
 Project: Groovy
  Issue Type: Bug
Reporter: Mikko Värri


Similar things have been touched before, like GROOVY-2340. But I didn't see 
exactly this. I'm not sure if single character GStrings are even a thing. Sorry 
if they aren't.

But I found the following a bit inconsistent:
{code:java}
final String S = 'A'
final Character C = 'A'
final GString G = "$S"
final Number N = 65

assert C == S && S == G // 1a
assert C  ==  G // 1b

assert S == C && G == S // 2a
//assert  G == C  // 2b, fails, inconsistent with 2a and 1b

assert N == S && S == G // 3a
//assert N  ==  G // 3b, fails, inconsistent with 3a

assert S == N && G == S // 4a
//assert  G == N  // 4b, fails, inconsistent with 4a
{code}
So, a single character GString equals a character, but only if it is on RHS. It 
doesn't equal a number, ever. I wonder if it should behave like String here.

If there's interest in "fixing" this, I've got a patch that allows all those 
asserts pass and doesn't seem to fail any of the existing test cases.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8798) Mention changes in `pop` method for lists in 2.5.x breaking changes

[JIRA]

Vladimír Oraný created GROOVY-8798:
--

 Summary: Mention changes in `pop` method for lists in 2.5.x 
breaking changes
 Key: GROOVY-8798
 URL: https://issues.apache.org/jira/browse/GROOVY-8798
 Project: Groovy
  Issue Type: Task
Affects Versions: 2.5.2
Reporter: Vladimír Oraný


The behavior of  `pop` method (DefaultGroovyMethods#pop(List)  has changed in 
2.5.x but it is not mentioned in breaking changes in 2.5.x release notes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8799) Postpone changes in list's pop and push to version 3.x

[JIRA]

Vladimír Oraný created GROOVY-8799:
--

 Summary: Postpone changes in list's pop and push to version 3.x
 Key: GROOVY-8799
 URL: https://issues.apache.org/jira/browse/GROOVY-8799
 Project: Groovy
  Issue Type: Bug
Affects Versions: 2.5.2, 2.5.1, 2.5.0
Reporter: Vladimír Oraný


Changing the behaviour of default list methods push and pop in 2.5 seems to be 
too radical. If possible it would be better to revert the change in 2.5.x 
branch, deprecate the methods and keep the old behaviour until 3.x release.

 

This change could introduce bugs which are not easy to determine, especially in 
3rd party libraries. As far I know the only one large Groovy franeojfr which 
relies on 2.5.x is micronaut but I believe it would be easy to find all 
critical locations there if any 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8814) AnnotationCollector not removed during stub generation

[JIRA]

Leonard Brünings created GROOVY-8814:


 Summary: AnnotationCollector not removed during stub generation
 Key: GROOVY-8814
 URL: https://issues.apache.org/jira/browse/GROOVY-8814
 Project: Groovy
  Issue Type: Bug
  Components: Stub generator / Joint compiler
Affects Versions: 2.5.2, 2.4.15
Reporter: Leonard Brünings
 Attachments: groovy-stubs-annotation.zip

The Groovy Stubs generator leaves the AnnotationCollectors in the generator 
stubs sources instead of replacing them with the collected annotations, which 
in turn causes javac to fail, since they are not valid annotations. (Related to 
GROOVY-7056)

{{[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on 
project example: Compilation failure}}
 {{[ERROR] 
/C:/dev/github/groovy-stubs-annotation/target/generated-sources/groovy-stubs/main/org/example/Service.java:[19,18]
 incompatible types: groovy.transform.CompileDynamic cannot be converted to 
java.lang.annotation.Annotation}}
{code:title=Groovy Source}
@CompileStatic
class Service {

  @CompileDynamic
  List dynamic() {
    []
  }
}
{code}
gets transformed into
{code:java|title=Generated Stub}
@groovy.transform.CompileStatic() public class Service
  extends java.lang.Object  implements
    groovy.lang.GroovyObject {
@groovy.transform.CompileDynamic() public  java.util.List 
dynamic() { return (java.util.List)null;}
}
{code}
 

See attached Project to reproduce

For groovy 2.4.15: {{./mvnw clean install}}

For groovy 2.5.2: {{./mvnw clean install -Pgroovy-2.5}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8822) Conflict between @Generated and @Delegate

[JIRA]

François Guillot created GROOVY-8822:


 Summary: Conflict between @Generated and @Delegate
 Key: GROOVY-8822
 URL: https://issues.apache.org/jira/browse/GROOVY-8822
 Project: Groovy
  Issue Type: Bug
Affects Versions: 2.5.3
Reporter: François Guillot


I get 
java.lang.annotation.AnnotationFormatError: Duplicate annotation for class: 
interface groovy.transform.Generated: @groovy.transform.Generated()
On a class with a field declared with @Delegate

 

Removing @Delegate works around the problem



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8822) Conflict between @Generated and @Delegate

[JIRA]

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

François Guillot commented on GROOVY-8822:
--

Yes the delegate is a groovy class.

I can't extract my problematic example, and I didn't manage to reproduce it yet

> Conflict between @Generated and @Delegate
> -
>
> Key: GROOVY-8822
> URL: https://issues.apache.org/jira/browse/GROOVY-8822
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: François Guillot
>Priority: Major
>
> I get 
> java.lang.annotation.AnnotationFormatError: Duplicate annotation for class: 
> interface groovy.transform.Generated: @groovy.transform.Generated()
> On a class with a field declared with @Delegate
>  
> Removing @Delegate works around the problem



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8826) Captured loop variables have surprising and Java-incompatible behavior

[JIRA]

Роман Донченко created GROOVY-8826:
--

 Summary: Captured loop variables have surprising and 
Java-incompatible behavior
 Key: GROOVY-8826
 URL: https://issues.apache.org/jira/browse/GROOVY-8826
 Project: Groovy
  Issue Type: Bug
Affects Versions: 3.0.0-alpha-3
Reporter: Роман Донченко


Consider this source:

{code:java}
import java.util.ArrayList;
import java.util.Arrays;

public class Test {
public static void main(String... args) {
ArrayList closures = new ArrayList<>();

for (int i: new int[] {1, 2})
closures.add(() -> System.out.println(i));

for (Runnable closure: closures)
closure.run();
}
}
{code}

If it's compiled as Java, the output is:

{code}
1
2
{code}

But if it's compiled as Groovy, the output is:

{code}
2
2
{code}

In other words, in Java each iteration gets a unique instance of the {{i}} 
variable, which is captured in the corresponding closure, while in Groovy, only 
one {{i}} variable exists and is captured into both closures. IMO, the Groovy 
behavior is significantly less useful, and it would be nice if in 3.0 it was 
changed to match Java.

Groovy also exhibits the same behavior with Groovy closures and 
{{for(...in...)}} loops. I just used Java-compatible syntax for this example in 
order to contrast Groovy and Java.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8826) Captured loop variables have surprising and Java-incompatible behavior

[JIRA]

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

Роман Донченко commented on GROOVY-8826:


bq. {{for (int i=0; i Captured loop variables have surprising and Java-incompatible behavior
> --
>
> Key: GROOVY-8826
> URL: https://issues.apache.org/jira/browse/GROOVY-8826
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 3.0.0-alpha-3
>Reporter: Роман Донченко
>Priority: Major
>
> Consider this source:
> {code:java}
> import java.util.ArrayList;
> import java.util.Arrays;
> public class Test {
> public static void main(String... args) {
> ArrayList closures = new ArrayList<>();
> for (int i: new int[] {1, 2})
> closures.add(() -> System.out.println(i));
> for (Runnable closure: closures)
> closure.run();
> }
> }
> {code}
> If it's compiled as Java, the output is:
> {code}
> 1
> 2
> {code}
> But if it's compiled as Groovy, the output is:
> {code}
> 2
> 2
> {code}
> In other words, in Java each iteration gets a unique instance of the {{i}} 
> variable, which is captured in the corresponding closure, while in Groovy, 
> only one {{i}} variable exists and is captured into both closures. IMO, the 
> Groovy behavior is significantly less useful, and it would be nice if in 3.0 
> it was changed to match Java.
> Groovy also exhibits the same behavior with Groovy closures and 
> {{for(...in...)}} loops. I just used Java-compatible syntax for this example 
> in order to contrast Groovy and Java.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (GROOVY-8841) Released version 2.5.3 is not available in Maven central

[JIRA]

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

Cédric Champeau closed GROOVY-8841.
---
Resolution: Fixed

This is not a bug, 2.5.3 is not released yet

> Released version 2.5.3 is not available in Maven central
> 
>
> Key: GROOVY-8841
> URL: https://issues.apache.org/jira/browse/GROOVY-8841
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Vimal David
>Priority: Major
>
> Released version 2.5.3 is not available in Maven central. While using the 
> latest released version in [GMavenPlus|https://github.com/groovy/GMavenPlus] 
> I got the following 
> [error|https://travis-ci.org/groovy/GMavenPlus/builds/440694867?utm_source=github_status&utm_medium=notification]:
> {code:java}
> [ERROR] Failed to execute goal on project gmavenplus-plugin: Could not 
> resolve dependencies for project 
> org.codehaus.gmavenplus:gmavenplus-plugin:maven-plugin:1.6.2-SNAPSHOT: The 
> following artifacts could not be resolved: 
> org.codehaus.groovy:groovy:jar:indy:2.5.3, 
> org.codehaus.groovy:groovy-ant:jar:indy:2.5.3, 
> org.codehaus.groovy:groovy-groovydoc:jar:indy:2.5.3: Could not find artifact 
> org.codehaus.groovy:groovy:jar:indy:2.5.3 in central 
> (http://repo.maven.apache.org/maven2) 
> {code}
> Further, I checked the [maven 
> central|https://search.maven.org/search?q=g:org.codehaus.groovy%20AND%20a:groovy&core=gav]
>  as well and the version 2.5.3 is not available.
> In addition to that, the project 
> [README.adoc|https://github.com/apache/groovy/blob/master/README.adoc] file 
> need to be updated and the latest artifact has to be deployed to 
> [Bintray|https://bintray.com/groovy/maven/groovy] as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8848) Named parameters documentation missing explanation for mixing multiple parameters use case

[JIRA]

Szymon Stępniak created GROOVY-8848:
---

 Summary: Named parameters documentation missing explanation for 
mixing multiple parameters use case
 Key: GROOVY-8848
 URL: https://issues.apache.org/jira/browse/GROOVY-8848
 Project: Groovy
  Issue Type: Documentation
  Components: Documentation
Affects Versions: 2.5.3, 3.0.0-alpha-3
Reporter: Szymon Stępniak


It looks like current documentation page that explains named parameters is 
missing information about what happens when we start mixing named parameters 
with additional parameters.

Current documentation - 
http://docs.groovy-lang.org/latest/html/documentation/#_named_arguments

This problem was reported on Stack Overflow - 
https://stackoverflow.com/questions/52832382/omiting-brackets-for-named-arguments-inverts-order/52834346#52834346

Please assign this task to me - I will prepare a pull request with 
documentation update in a few hours.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8848) Named parameters documentation missing explanation for mixing multiple parameters use case

[JIRA]

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

Szymon Stępniak commented on GROOVY-8848:
-

Pull request ready to review - https://github.com/apache/groovy/pull/812

> Named parameters documentation missing explanation for mixing multiple 
> parameters use case
> --
>
> Key: GROOVY-8848
> URL: https://issues.apache.org/jira/browse/GROOVY-8848
> Project: Groovy
>  Issue Type: Documentation
>  Components: Documentation
>Affects Versions: 3.0.0-alpha-3, 2.5.3
>Reporter: Szymon Stępniak
>Priority: Minor
>
> It looks like current documentation page that explains named parameters is 
> missing information about what happens when we start mixing named parameters 
> with additional parameters.
> Current documentation - 
> http://docs.groovy-lang.org/latest/html/documentation/#_named_arguments
> This problem was reported on Stack Overflow - 
> https://stackoverflow.com/questions/52832382/omiting-brackets-for-named-arguments-inverts-order/52834346#52834346
> Please assign this task to me - I will prepare a pull request with 
> documentation update in a few hours.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8820) Closure inside trait cannot use Closure's delegate variables

[JIRA]

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

Frederico Costa Galvão commented on GROOVY-8820:


Can be reproduced with as little code as:

 
{code:groovy}
trait Bacon {
def what() {
String[] l = []
l.with {
length
}
}
}

class B implements Bacon {}

new B().what()
{code}

Changing `trait` with `class` and `implements` with `extends` makes the code 
run properly.

 

 

 

> Closure inside trait cannot use Closure's delegate variables
> 
>
> Key: GROOVY-8820
> URL: https://issues.apache.org/jira/browse/GROOVY-8820
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.2
> Environment: Groovy Version: 3.0.0-alpha-3 JVM: 1.8.0_171 Vendor: 
> Oracle Corporation OS: Mac OS X
>Reporter: Renato Athaydes
>Priority: Major
>
> The following code throws an error at runtime:
>  
> {code:java}
> trait T {
>     def doIt() {
>     return {
>     n = 1
>     }
>     }
> }
> class Delegate {
>     int n
> }
>     
> class Tish implements T {
>     def go() {
>     def closure = doIt()
>     def d = new Delegate()
>     closure.delegate = d
>     closure()
>     assert d.n == 1
>     println "All good!"
>     }
> }
> new Tish().go(){code}
>  
> This is the error I see on Groovy 3.0.0-alpha-3 (same as previous versions):
>  
> {code:java}
> groovy.lang.MissingPropertyException: No such property: n for class: 
> Tish{code}
>  
> This is expected to work because, outside of traits, it does: this runs 
> successfully:
>  
> {code:java}
> class T {
>     def doIt() {
>     return {
>     n = 1
>     }
>     }
> }
> class Delegate {
>     int n
> }
>     
> class Tisha extends T {
>     def go() {
>     def closure = doIt()
>     def d = new Delegate()
>     closure.delegate = d
>     closure()
>     assert d.n == 1
>     println "All good!"
>     }
> }
> new Tisha().go(){code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8854) MissingMethodException when a public method on a trait calls a static private one in a class hierarchy

[JIRA]

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

Iván López updated GROOVY-8854:
---
Affects Version/s: 3.0.0-alpha-3

> MissingMethodException when a public method on a trait calls a static private 
> one in a class hierarchy
> --
>
> Key: GROOVY-8854
> URL: https://issues.apache.org/jira/browse/GROOVY-8854
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.3
>Reporter: Iván López
>Priority: Major
>
> The following code fails at runtime:
> {code:java}
> trait Validateable {
> boolean validate() {
> return foo()
> }
> private static boolean foo() {
> return false
> }
> }
> class DomainObject implements Validateable {
> String name
> }
> class Child extends DomainObject {
> }
> def child = new Child(name: 'name')
> child.validate()
> {code}
> With this error:
> {code}
> groovy.lang.MissingMethodException: No signature of method: Child.foo() is 
> applicable for argument types: () values: []
> {code}
> Keep in mind that the Trait method is _framework-code_ (in this case from 
> Grails) and {{DomainObject}} and {{Child}} classes are _user-code_.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8854) MissingMethodException when a public method on a trait calls a static private one in a class hierarchy

[JIRA]

Iván López created GROOVY-8854:
--

 Summary: MissingMethodException when a public method on a trait 
calls a static private one in a class hierarchy
 Key: GROOVY-8854
 URL: https://issues.apache.org/jira/browse/GROOVY-8854
 Project: Groovy
  Issue Type: Bug
Affects Versions: 2.5.3, 2.4.15
Reporter: Iván López


The following code fails at runtime:
{code:java}
trait Validateable {

boolean validate() {
return foo()
}

private static boolean foo() {
return false
}
}

class DomainObject implements Validateable {
String name
}

class Child extends DomainObject {
}

def child = new Child(name: 'name')
child.validate()
{code}

With this error:
{code}
groovy.lang.MissingMethodException: No signature of method: Child.foo() is 
applicable for argument types: () values: []
{code}

Keep in mind that the Trait method is _framework-code_ (in this case from 
Grails) and {{DomainObject}} and {{Child}} classes are _user-code_.







--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8855) Calling Matcher.asBoolean() twice returns different results

[JIRA]

Szymon Stępniak created GROOVY-8855:
---

 Summary: Calling Matcher.asBoolean() twice returns different 
results
 Key: GROOVY-8855
 URL: https://issues.apache.org/jira/browse/GROOVY-8855
 Project: Groovy
  Issue Type: Bug
  Components: groovy-runtime
Affects Versions: 2.5.3, 3.0.0-alpha-3
Reporter: Szymon Stępniak


There is one non-deterministic use case of using type coercion from 
{{java.util.regex.Matcher}} to a {{boolean}}. It was initially reported on 
Stack Overflow - https://stackoverflow.com/q/52930876/2194470

And here is an example that shows the problem:

{code:groovy}
def pattern = /[a-z]+/

def input = 'abc'

def matcher = input =~ pattern

println matcher as Boolean
println matcher as Boolean
{code}

Output:

{code:bash}
true
false
{code}

Solution:

This problem can be solved by replacing {{matcher.find()}} with 
{{matcher.find(0)}}, so casting matcher to a boolean does not modify search 
index and always starts from the beginning. 

I will create a pull request in couple of minutes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8878) make @Named* annotations a language feature

[JIRA]

Vladimír Oraný created GROOVY-8878:
--

 Summary: make @Named* annotations a language feature
 Key: GROOVY-8878
 URL: https://issues.apache.org/jira/browse/GROOVY-8878
 Project: Groovy
  Issue Type: Improvement
  Components: Static compilation
Affects Versions: 3.x
Reporter: Vladimír Oraný


As of Groovy 2.5 @Named* annotations are processed by AST transformation which 
disallows to apply the annotations to Java classes. Would be nice if this 
becomes a language feature similar to how @DelegatesTo and @ClosureParams 
annotation works which can be used in Java code and Groovy compiler still 
understands them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8879) @NamedVariant on extension method

[JIRA]

Vladimír Oraný created GROOVY-8879:
--

 Summary: @NamedVariant on extension method
 Key: GROOVY-8879
 URL: https://issues.apache.org/jira/browse/GROOVY-8879
 Project: Groovy
  Issue Type: Bug
  Components: Static compilation
Affects Versions: 2.5.2
Reporter: Vladimír Oraný


I have a method on Java interface

 
{code:java}
RelationshipDefinition source(String cardinality, String title);{code}
 

And I want to create an extension method (as using @NamedVariant in Java 
sources is not supported)

 
{code:java}
@NamedVariant
static RelationshipDefinition source(RelationshipDefinition definition 
@NamedDelegate TitleAndCardinality tac) {
return definition.source(tac.cardinality, tac.title)
}{code}
 

I got an error when I try to use the method such as follows:

 
{code:java}
definition.source(cardinality: '1'){code}
 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8878) make @Named* annotations a language feature

[JIRA]

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

Vladimír Oraný commented on GROOVY-8878:


ok, in that case, `destination` method call should work and there is a bug in 
2.5.x:

 

[https://github.com/musketyr/yuml-dsl-builder/blob/named-arguments-problems/src/test/groovy/cz/orany/yuml/DiagramSpec.groovy#L78-L109]

 

feel free to checkout and test yourself

> make @Named* annotations a language feature
> ---
>
> Key: GROOVY-8878
> URL: https://issues.apache.org/jira/browse/GROOVY-8878
> Project: Groovy
>  Issue Type: Improvement
>  Components: Static compilation
>Affects Versions: 3.x
>Reporter: Vladimír Oraný
>Priority: Major
>
> As of Groovy 2.5 @Named* annotations are processed by AST transformation 
> which disallows to apply the annotations to Java classes. Would be nice if 
> this becomes a language feature similar to how @DelegatesTo and 
> @ClosureParams annotation works which can be used in Java code and Groovy 
> compiler still understands them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8879) @NamedVariant on extension method

[JIRA]

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

Vladimír Oraný commented on GROOVY-8879:


neither worked

 

[https://github.com/musketyr/yuml-dsl-builder/blob/named-arguments-problems/src/test/groovy/cz/orany/yuml/DiagramSpec.groovy#L78-L109]

> @NamedVariant on extension method
> -
>
> Key: GROOVY-8879
> URL: https://issues.apache.org/jira/browse/GROOVY-8879
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.5.2
>Reporter: Vladimír Oraný
>Priority: Major
>
> I have a method on Java interface
>  
> {code:java}
> RelationshipDefinition source(String cardinality, String title);{code}
>  
> And I want to create an extension method (as using @NamedVariant in Java 
> sources is not supported)
>  
> {code:java}
> @NamedVariant
> static RelationshipDefinition source(RelationshipDefinition definition 
> @NamedDelegate TitleAndCardinality tac) {
> return definition.source(tac.cardinality, tac.title)
> }{code}
>  
> I got an error when I try to use the method such as follows:
>  
> {code:java}
> definition.source(cardinality: '1'){code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8878) make @Named* annotations a language feature

[JIRA]

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

Vladimír Oraný commented on GROOVY-8878:


thank you. yes, this was the point I was missing!

> make @Named* annotations a language feature
> ---
>
> Key: GROOVY-8878
> URL: https://issues.apache.org/jira/browse/GROOVY-8878
> Project: Groovy
>  Issue Type: Improvement
>  Components: Static compilation
>Affects Versions: 3.x
>Reporter: Vladimír Oraný
>Priority: Major
> Attachments: namedParams.patch
>
>
> As of Groovy 2.5 @Named* annotations are processed by AST transformation 
> which disallows to apply the annotations to Java classes. Would be nice if 
> this becomes a language feature similar to how @DelegatesTo and 
> @ClosureParams annotation works which can be used in Java code and Groovy 
> compiler still understands them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GROOVY-8878) make @Named* annotations a language feature

[JIRA]

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

Vladimír Oraný resolved GROOVY-8878.

Resolution: Implemented

This was just a misunderstanding how the annotation works. Thank [~paulk] for a 
detailed explanation.

> make @Named* annotations a language feature
> ---
>
> Key: GROOVY-8878
> URL: https://issues.apache.org/jira/browse/GROOVY-8878
> Project: Groovy
>  Issue Type: Improvement
>  Components: Static compilation
>Affects Versions: 3.x
>Reporter: Vladimír Oraný
>Priority: Major
> Attachments: namedParams.patch
>
>
> As of Groovy 2.5 @Named* annotations are processed by AST transformation 
> which disallows to apply the annotations to Java classes. Would be nice if 
> this becomes a language feature similar to how @DelegatesTo and 
> @ClosureParams annotation works which can be used in Java code and Groovy 
> compiler still understands them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (GROOVY-8878) make @Named* annotations a language feature

[JIRA]

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

Vladimír Oraný closed GROOVY-8878.
--

> make @Named* annotations a language feature
> ---
>
> Key: GROOVY-8878
> URL: https://issues.apache.org/jira/browse/GROOVY-8878
> Project: Groovy
>  Issue Type: Improvement
>  Components: Static compilation
>Affects Versions: 3.x
>Reporter: Vladimír Oraný
>Priority: Major
> Attachments: namedParams.patch
>
>
> As of Groovy 2.5 @Named* annotations are processed by AST transformation 
> which disallows to apply the annotations to Java classes. Would be nice if 
> this becomes a language feature similar to how @DelegatesTo and 
> @ClosureParams annotation works which can be used in Java code and Groovy 
> compiler still understands them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8888) Strict @NamedParams

[JIRA]

Vladimír Oraný created GROOVY-:
--

 Summary: Strict @NamedParams
 Key: GROOVY-
 URL: https://issues.apache.org/jira/browse/GROOVY-
 Project: Groovy
  Issue Type: Improvement
Reporter: Vladimír Oraný


Thanks, [~paulk] for explaining how does all the "@Named*" annotation works. I 
have one suggestion for improvement:

At the moment when you add an extra entry in the map, the static compiler won't 
complain. Would be nice to add "strict" property to "@NamedParams" which will 
make any additional entry illegal.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8879) @NamedVariant on extension method

[JIRA]

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

Vladimír Oraný commented on GROOVY-8879:


Right, now it makes sense! It would be great if there is such an option which 
would preserve the first argument. What about 
@NamedVariant(extensionMethod=true) which tells more about the purpose then the 
implementation?

> @NamedVariant on extension method
> -
>
> Key: GROOVY-8879
> URL: https://issues.apache.org/jira/browse/GROOVY-8879
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.5.2
>Reporter: Vladimír Oraný
>Priority: Major
>
> I have a method on Java interface
>  
> {code:java}
> RelationshipDefinition source(String cardinality, String title);{code}
>  
> And I want to create an extension method (as using @NamedVariant in Java 
> sources is not supported)
>  
> {code:java}
> @NamedVariant
> static RelationshipDefinition source(RelationshipDefinition definition 
> @NamedDelegate TitleAndCardinality tac) {
> return definition.source(tac.cardinality, tac.title)
> }{code}
>  
> I got an error when I try to use the method such as follows:
>  
> {code:java}
> definition.source(cardinality: '1'){code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8889) @NamedParam(required=true) is not enforced

[JIRA]

Vladimír Oraný created GROOVY-8889:
--

 Summary: @NamedParam(required=true) is not enforced
 Key: GROOVY-8889
 URL: https://issues.apache.org/jira/browse/GROOVY-8889
 Project: Groovy
  Issue Type: Bug
Affects Versions: 2.5.4
Reporter: Vladimír Oraný


in following snipped the required parameter is not enforced at all:


{code}
import groovy.transform.CompileStatic
import groovy.transform.NamedParam
import groovy.transform.NamedParams

@CompileStatic
class Tester {
String text
String color

static Tester note(String text, String color) {
return new Tester(text: text, color: color)
}
}

@CompileStatic
class TesterBuilder {
static Tester note(
@NamedParams([
@NamedParam(value = 'text', type = String, required = true),
@NamedParam(value = 'color', type = String)
])
Map params
) {
return Tester.note(params.text, params.color)
}
}


@CompileStatic
Tester useBuilder() {
return TesterBuilder.note(color: 'blue')
}

useBuilder()
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8888) Strict @NamedParams

[JIRA]

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

Vladimír Oraný commented on GROOVY-:


I can't see the "unknown" parameter for "@NamedParams" annotation in the latest 
snapshot from here:

[https://oss.jfrog.org/artifactory/oss-snapshot-local/org/codehaus/groovy/groovy/2.5.5-SNAPSHOT/]

or here

[https://oss.jfrog.org/artifactory/oss-snapshot-local/org/codehaus/groovy/groovy/2.6.0-SNAPSHOT/]

 

Am I missing something?

> Strict @NamedParams
> ---
>
> Key: GROOVY-
> URL: https://issues.apache.org/jira/browse/GROOVY-
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Vladimír Oraný
>Priority: Major
>
> Thanks, [~paulk] for explaining how does all the "@Named*" annotation works. 
> I have one suggestion for improvement:
> At the moment when you add an extra entry in the map, the static compiler 
> won't complain. Would be nice to add "strict" property to "@NamedParams" 
> which will make any additional entry illegal.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8916) JsonOutput unable to serialize Locale object

[JIRA]

Sébastien Gadot created GROOVY-8916:
---

 Summary: JsonOutput unable to serialize Locale object
 Key: GROOVY-8916
 URL: https://issues.apache.org/jira/browse/GROOVY-8916
 Project: Groovy
  Issue Type: Bug
  Components: groovy-runtime
Affects Versions: 2.4.15
Reporter: Sébastien Gadot


Trying to serialize an object containing a Locale throws StackOverflowException

example :

 

 
{code:java}
JsonOutput.toJson([loc: Locale.FRANCE])
// expected {"loc": "fr_FR"}
// got StackOverflowException

{code}
{code:java}
java.lang.StackOverflowError
at 
java.lang.reflect.InvocationTargetException.(InvocationTargetException.java:72)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
at groovy.lang.MetaBeanProperty.getProperty(MetaBeanProperty.java:59)
at groovy.lang.PropertyValue.getValue(PropertyValue.java:42)
at 
org.codehaus.groovy.runtime.DefaultGroovyMethods.getProperties(DefaultGroovyMethods.java:474)
at groovy.json.JsonOutput.getObjectProperties(JsonOutput.java:338)
at groovy.json.JsonOutput.writeObject(JsonOutput.java:331)
at groovy.json.JsonOutput.writeMap(JsonOutput.java:469)
at groovy.json.JsonOutput.writeObject(JsonOutput.java:332)
at groovy.json.JsonOutput.writeMap(JsonOutput.java:469)
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GROOVY-8916) JsonOutput unable to serialize Locale object

[JIRA]

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

Sébastien Gadot resolved GROOVY-8916.
-
   Resolution: Fixed
Fix Version/s: 2.5.x

The workaround is OK by me. I will do it this way, thanks

-> Upgrade to 2.5 and use JsonGenerator. 

> JsonOutput unable to serialize Locale object
> 
>
> Key: GROOVY-8916
> URL: https://issues.apache.org/jira/browse/GROOVY-8916
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 2.4.15
>Reporter: Sébastien Gadot
>Priority: Minor
> Fix For: 2.5.x
>
>
> Trying to serialize an object containing a Locale throws 
> StackOverflowException
> example :
>  
>  
> {code:java}
> JsonOutput.toJson([loc: Locale.FRANCE])
> // expected {"loc": "fr_FR"}
> // got StackOverflowException
> {code}
> {code:java}
> java.lang.StackOverflowError
> at 
> java.lang.reflect.InvocationTargetException.(InvocationTargetException.java:72)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaBeanProperty.getProperty(MetaBeanProperty.java:59)
> at groovy.lang.PropertyValue.getValue(PropertyValue.java:42)
> at 
> org.codehaus.groovy.runtime.DefaultGroovyMethods.getProperties(DefaultGroovyMethods.java:474)
> at groovy.json.JsonOutput.getObjectProperties(JsonOutput.java:338)
> at groovy.json.JsonOutput.writeObject(JsonOutput.java:331)
> at groovy.json.JsonOutput.writeMap(JsonOutput.java:469)
> at groovy.json.JsonOutput.writeObject(JsonOutput.java:332)
> at groovy.json.JsonOutput.writeMap(JsonOutput.java:469)
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (GROOVY-8916) JsonOutput unable to serialize Locale object

[JIRA]

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

Sébastien Gadot closed GROOVY-8916.
---

Update to 2.5 and use JsonGenerator

> JsonOutput unable to serialize Locale object
> 
>
> Key: GROOVY-8916
> URL: https://issues.apache.org/jira/browse/GROOVY-8916
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 2.4.15
>Reporter: Sébastien Gadot
>Priority: Minor
> Fix For: 2.5.x
>
>
> Trying to serialize an object containing a Locale throws 
> StackOverflowException
> example :
>  
>  
> {code:java}
> JsonOutput.toJson([loc: Locale.FRANCE])
> // expected {"loc": "fr_FR"}
> // got StackOverflowException
> {code}
> {code:java}
> java.lang.StackOverflowError
> at 
> java.lang.reflect.InvocationTargetException.(InvocationTargetException.java:72)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaBeanProperty.getProperty(MetaBeanProperty.java:59)
> at groovy.lang.PropertyValue.getValue(PropertyValue.java:42)
> at 
> org.codehaus.groovy.runtime.DefaultGroovyMethods.getProperties(DefaultGroovyMethods.java:474)
> at groovy.json.JsonOutput.getObjectProperties(JsonOutput.java:338)
> at groovy.json.JsonOutput.writeObject(JsonOutput.java:331)
> at groovy.json.JsonOutput.writeMap(JsonOutput.java:469)
> at groovy.json.JsonOutput.writeObject(JsonOutput.java:332)
> at groovy.json.JsonOutput.writeMap(JsonOutput.java:469)
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8929) Inconsistent equals and hashCode for int[]

[JIRA]

Albert Fernández Marsal created GROOVY-8929:
---

 Summary: Inconsistent equals and hashCode for int[]
 Key: GROOVY-8929
 URL: https://issues.apache.org/jira/browse/GROOVY-8929
 Project: Groovy
  Issue Type: Bug
Affects Versions: 2.5.4
Reporter: Albert Fernández Marsal


{code}
09:29:~$ groovysh
Groovy Shell (2.4.14, JVM: 1.8.0_171)
Type ':help' or ':h' for help.
---
groovy:000> a = [1,2,3] as int[]
===> [1, 2, 3]
groovy:000> a.class
===> class [I
groovy:000> b = [1,2,3] as int[]
===> [1, 2, 3]
groovy:000> b.class
===> class [I
groovy:000> a == b
===> true
groovy:000> a.hashCode()
===> 1329315688
groovy:000> b.hashCode()
===> 1489933928
groovy:000>
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8929) Inconsistent equals and hashCode for arrays

[JIRA]

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

Albert Fernández Marsal updated GROOVY-8929:

Summary: Inconsistent equals and hashCode for arrays  (was: Inconsistent 
equals and hashCode for int[])

> Inconsistent equals and hashCode for arrays
> ---
>
> Key: GROOVY-8929
> URL: https://issues.apache.org/jira/browse/GROOVY-8929
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Albert Fernández Marsal
>Priority: Major
>
> {code}
> 09:29:~$ groovysh
> Groovy Shell (2.4.14, JVM: 1.8.0_171)
> Type ':help' or ':h' for help.
> ---
> groovy:000> a = [1,2,3] as int[]
> ===> [1, 2, 3]
> groovy:000> a.class
> ===> class [I
> groovy:000> b = [1,2,3] as int[]
> ===> [1, 2, 3]
> groovy:000> b.class
> ===> class [I
> groovy:000> a == b
> ===> true
> groovy:000> a.hashCode()
> ===> 1329315688
> groovy:000> b.hashCode()
> ===> 1489933928
> groovy:000>
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8929) Inconsistent equals and hashCode for arrays

[JIRA]

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

Albert Fernández Marsal updated GROOVY-8929:

Description: 
{code}
09:29:~$ groovysh
Groovy Shell (2.4.14, JVM: 1.8.0_171)
Type ':help' or ':h' for help.
---
# int[]
groovy:000> a = [1,2,3] as int[]
===> [1, 2, 3]
groovy:000> a.class
===> class [I
groovy:000> b = [1,2,3] as int[]
===> [1, 2, 3]
groovy:000> b.class
===> class [I
groovy:000> a == b
===> true
groovy:000> a.hashCode()
===> 1329315688
groovy:000> b.hashCode()
===> 1489933928
# String[]
groovy:000> c = ['a', 'b'] as String[]
===> [a, b]
groovy:000> d = ['a', 'b'] as String[]
===> [a, b]
groovy:000> c == d
===> true
groovy:000> c.hashCode()
===> 319689067
groovy:000> d.hashCode()
===> 6422064
groovy:000>
{code}

  was:
{code}
09:29:~$ groovysh
Groovy Shell (2.4.14, JVM: 1.8.0_171)
Type ':help' or ':h' for help.
---
groovy:000> a = [1,2,3] as int[]
===> [1, 2, 3]
groovy:000> a.class
===> class [I
groovy:000> b = [1,2,3] as int[]
===> [1, 2, 3]
groovy:000> b.class
===> class [I
groovy:000> a == b
===> true
groovy:000> a.hashCode()
===> 1329315688
groovy:000> b.hashCode()
===> 1489933928
groovy:000>
{code}


> Inconsistent equals and hashCode for arrays
> ---
>
> Key: GROOVY-8929
> URL: https://issues.apache.org/jira/browse/GROOVY-8929
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Albert Fernández Marsal
>Priority: Major
>
> {code}
> 09:29:~$ groovysh
> Groovy Shell (2.4.14, JVM: 1.8.0_171)
> Type ':help' or ':h' for help.
> ---
> # int[]
> groovy:000> a = [1,2,3] as int[]
> ===> [1, 2, 3]
> groovy:000> a.class
> ===> class [I
> groovy:000> b = [1,2,3] as int[]
> ===> [1, 2, 3]
> groovy:000> b.class
> ===> class [I
> groovy:000> a == b
> ===> true
> groovy:000> a.hashCode()
> ===> 1329315688
> groovy:000> b.hashCode()
> ===> 1489933928
> # String[]
> groovy:000> c = ['a', 'b'] as String[]
> ===> [a, b]
> groovy:000> d = ['a', 'b'] as String[]
> ===> [a, b]
> groovy:000> c == d
> ===> true
> groovy:000> c.hashCode()
> ===> 319689067
> groovy:000> d.hashCode()
> ===> 6422064
> groovy:000>
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8929) Inconsistent equals and hashCode for int[]

[JIRA]

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

Albert Fernández Marsal updated GROOVY-8929:

Affects Version/s: (was: 2.5.4)
   2.4.14

> Inconsistent equals and hashCode for int[]
> --
>
> Key: GROOVY-8929
> URL: https://issues.apache.org/jira/browse/GROOVY-8929
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Albert Fernández Marsal
>Priority: Major
>
> {code}
> 09:29:~$ groovysh
> Groovy Shell (2.4.14, JVM: 1.8.0_171)
> Type ':help' or ':h' for help.
> ---
> groovy:000> a = [1,2,3] as int[]
> ===> [1, 2, 3]
> groovy:000> a.class
> ===> class [I
> groovy:000> b = [1,2,3] as int[]
> ===> [1, 2, 3]
> groovy:000> b.class
> ===> class [I
> groovy:000> a == b
> ===> true
> groovy:000> a.hashCode()
> ===> 1329315688
> groovy:000> b.hashCode()
> ===> 1489933928
> groovy:000>
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)