[jira] [Commented] (GROOVY-8431) toDebugString method as a core concept
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
Á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
[ 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
[ 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
[ 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
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
[ 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
[ 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
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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
Роман Донченко 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
Роман Донченко 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
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
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
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
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
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
[ 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
Роман Донченко 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
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
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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
[ 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
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
[ 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
[ 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[]
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
[ 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
[ 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[]
[ 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)