[jira] [Updated] (GROOVY-10795) Regression: Returning List/Map created via literal as typed generic
[ https://issues.apache.org/jira/browse/GROOVY-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Eddelbuettel updated GROOVY-10795: - Description: This script {code:java} @groovy.transform.CompileStatic List foo() { def list = [ ] list << "xyz" return list }{code} produces startup failed: C:\Projects\Gradle\DARWin\DARWinTester\DARWin\src\TestScript.groovy: 5: [Static type checking] - Incompatible generic argument types. Cannot assign java.util.List to: java.util.List @ line 5, column 12. return list The same code worked fine in 3.0.5 and 3.0.8. It last worked in 3.0.10. Version 4.0.6 produces the same error. was: This script {code:java} @groovy.transform.CompileStatic List foo() { def list = [ ] list << "xyz" return list }{code} produces startup failed: C:\Projects\Gradle\DARWin\DARWinTester\DARWin\src\TestScript.groovy: 5: [Static type checking] - Incompatible generic argument types. Cannot assign java.util.List to: java.util.List @ line 5, column 12. return list The same code worked fine in 3.0.5 and 3.0.8. It last worked in 3.0.10. Version 4.0.6. produces the same error. > Regression: Returning List/Map created via literal as typed generic > --- > > Key: GROOVY-10795 > URL: https://issues.apache.org/jira/browse/GROOVY-10795 > Project: Groovy > Issue Type: Bug > Components: Static compilation, Static Type Checker >Affects Versions: 3.0.11, 3.0.13, 4.0.6 >Reporter: Jochen Eddelbuettel >Priority: Major > > This script > {code:java} > @groovy.transform.CompileStatic > List foo() { > def list = [ ] > list << "xyz" > return list > }{code} > produces > startup failed: > C:\Projects\Gradle\DARWin\DARWinTester\DARWin\src\TestScript.groovy: 5: > [Static type checking] - Incompatible generic argument types. Cannot assign > java.util.List to: java.util.List > @ line 5, column 12. > return list > > The same code worked fine in 3.0.5 and 3.0.8. > It last worked in 3.0.10. Version 4.0.6 produces the same error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-10795) Regression: Returning List/Map created via literal as typed generic
[ https://issues.apache.org/jira/browse/GROOVY-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Eddelbuettel updated GROOVY-10795: - Affects Version/s: 4.0.6 3.0.11 Description: This script {code:java} @groovy.transform.CompileStatic List foo() { def list = [ ] list << "xyz" return list }{code} produces startup failed: C:\Projects\Gradle\DARWin\DARWinTester\DARWin\src\TestScript.groovy: 5: [Static type checking] - Incompatible generic argument types. Cannot assign java.util.List to: java.util.List @ line 5, column 12. return list The same code worked fine in 3.0.5 and 3.0.8. It last worked in 3.0.10. Version 4.0.6. produces the same error. was: This script {code:java} @groovy.transform.CompileStatic List foo() { def list = [ ] list << "xyz" return list }{code} produces startup failed: C:\Projects\Gradle\DARWin\DARWinTester\DARWin\src\TestScript.groovy: 5: [Static type checking] - Incompatible generic argument types. Cannot assign java.util.List to: java.util.List @ line 5, column 12. return list The same code worked fine in 3.0.5 and 3.0.8. > Regression: Returning List/Map created via literal as typed generic > --- > > Key: GROOVY-10795 > URL: https://issues.apache.org/jira/browse/GROOVY-10795 > Project: Groovy > Issue Type: Bug > Components: Static compilation, Static Type Checker >Affects Versions: 3.0.11, 3.0.13, 4.0.6 >Reporter: Jochen Eddelbuettel >Priority: Major > > This script > {code:java} > @groovy.transform.CompileStatic > List foo() { > def list = [ ] > list << "xyz" > return list > }{code} > produces > startup failed: > C:\Projects\Gradle\DARWin\DARWinTester\DARWin\src\TestScript.groovy: 5: > [Static type checking] - Incompatible generic argument types. Cannot assign > java.util.List to: java.util.List > @ line 5, column 12. > return list > > The same code worked fine in 3.0.5 and 3.0.8. > It last worked in 3.0.10. Version 4.0.6. produces the same error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-10795) Regression: Returning List/Map created via literal as typed generic
Jochen Eddelbuettel created GROOVY-10795: Summary: Regression: Returning List/Map created via literal as typed generic Key: GROOVY-10795 URL: https://issues.apache.org/jira/browse/GROOVY-10795 Project: Groovy Issue Type: Bug Components: Static compilation, Static Type Checker Affects Versions: 3.0.13 Reporter: Jochen Eddelbuettel This script {code:java} @groovy.transform.CompileStatic List foo() { def list = [ ] list << "xyz" return list }{code} produces startup failed: C:\Projects\Gradle\DARWin\DARWinTester\DARWin\src\TestScript.groovy: 5: [Static type checking] - Incompatible generic argument types. Cannot assign java.util.List to: java.util.List @ line 5, column 12. return list The same code worked fine in 3.0.5 and 3.0.8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-10007) Breaking change in property resolution 2.4 -> 3.0
Jochen Eddelbuettel created GROOVY-10007: Summary: Breaking change in property resolution 2.4 -> 3.0 Key: GROOVY-10007 URL: https://issues.apache.org/jira/browse/GROOVY-10007 Project: Groovy Issue Type: Bug Components: Compiler Affects Versions: 3.0.7, 3.0.5 Environment: OpenJDK 11, IdeaC 2020.3.3 Reporter: Jochen Eddelbuettel I've created a library utilizing propertyMissing. By convention, it expects property names to be running against camel casing conventions (starting with a single upper case letter), to avoid conflicts with actual properties (bean style, with getters). In Groovy 2.4 a call of obj.Owner would not be resolved to obj.getOwner(). Only obj.owner would be equivalent to obj.getOwner(). In Groovy 3.0 obj.Owner results in a call to obj.getOwner() as well. As a result, no call to propertyMissing for "Owner" occurs any more. Thus properties that used to be resolved by metaprogramming, can now result in actual method calls, which can potentially have a huge impact on the behavior of existing code. I've looked back into the 3.0.0 release notes and there is no mention of this being a breaking change. This script, who assertions were jolly fine in 2.4.15, should behave the same in 3.0.x: {code:java} import groovy.json.JsonSlurper JsonSlurper.metaClass.propertyMissing = { String name -> name } def slurp = new JsonSlurper() slurp.maxSizeForInMemory = 50 assert slurp.maxSizeForInMemory == 50 assert slurp.MaxSizeForInMemory == "MaxSizeForInMemory" {code} Interestingly, this is not a problem for setters, which suggests to me that the change is unintended behaviour get getters and should be fixed. It is a problem with @CompileStatic too. obj.Owner statically compiles to obj.getOwner(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-7615) MarkupTemplateBuilder autoEscape only escapes top level model properties
[ https://issues.apache.org/jira/browse/GROOVY-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196779#comment-17196779 ] Jochen Eddelbuettel commented on GROOVY-7615: - My expectation would be that the MarkupTemplateEngine works fully aligned with groovy.xml.MarkupBuilder or at least can be configured that way. This is a real show stopper. > MarkupTemplateBuilder autoEscape only escapes top level model properties > > > Key: GROOVY-7615 > URL: https://issues.apache.org/jira/browse/GROOVY-7615 > Project: Groovy > Issue Type: Bug > Components: Templating >Affects Versions: 2.4.4 >Reporter: Rainer Schmitz >Priority: Major > > {{TemplateConfiguration.setAutoEscape(true)}} only affects values in models > top level. Nested values will not be escaped. > Example: > {code}import groovy.text.markup.MarkupTemplateEngine > import groovy.text.markup.TemplateConfiguration > def tplConf = new TemplateConfiguration() > tplConf.autoEscape = true > def engine = new MarkupTemplateEngine(tplConf) > def template = engine.createTemplate (''' > html { > body { > div(unsafeContents) > div(nested.unsafe) > } > } > ''') > model = new HashMap(); > model.put("unsafeContents", "I am an hacker."); > model.put("nested", [unsafe: "I am an hacker."]); > Writable output = template.make(model) > assert 'I am an hacker.I am an > hacker.' == output.toString(){code} > {{div(nested.unsafe)}} is not escaped. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9554) @Field variable access within closures broken
[ https://issues.apache.org/jira/browse/GROOVY-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141053#comment-17141053 ] Jochen Eddelbuettel commented on GROOVY-9554: - Wow, Eric, that pull request looks like your taking this bull by the horns. I'll keep watching how this evolves and be playing with your other advice for the time being. > @Field variable access within closures broken > - > > Key: GROOVY-9554 > URL: https://issues.apache.org/jira/browse/GROOVY-9554 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.4.15, 3.0.3 >Reporter: Jochen Eddelbuettel >Assignee: Eric Milles >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > > {code:java} > @groovy.transform.Field String abc > binding.variables.clear() > abc = "abc" > println binding.hasVariable("abc") > ["D","E","F"].each { abc += it } > println binding.getVariable("abc") > assert abc == "abcDEF" > {code} > If a variable is declared using the @Field annotation, it can be assigned to > in the main script body, but any assignment inside a closure (here the > closure used with each) ends up in the script binding instead. Assignments > within regular methods work fine, too. If the variables is accessed inside > the closure and it is not in the binding, then the value will come from the > field. As soon as it is in the binding, the binding variable takes precedence > over the field. In both cases the field declared with @Field needs to have > precedence over anything that is in the binding, just like local variables do. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9558) Wrong code for putAt on Map that is member of closure delegate
[ https://issues.apache.org/jira/browse/GROOVY-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141050#comment-17141050 ] Jochen Eddelbuettel commented on GROOVY-9558: - Thanks for tracking this down so quickly. Static compilation is way beyond my capabilites of analysis, besides describing the symptoms, when I come across such oddities. > Wrong code for putAt on Map that is member of closure delegate > -- > > Key: GROOVY-9558 > URL: https://issues.apache.org/jira/browse/GROOVY-9558 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 3.0.3, 2.5.12 > Environment: Oracle JDK8 1.8.0_162, IntelliJ CE 2019.3.4, indy enabled >Reporter: Jochen Eddelbuettel >Assignee: Eric Milles >Priority: Minor > Fix For: 4.0.0-alpha-1, 3.0.5, 2.5.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > > I'm compiling this little Closure with @CompileStatic enabled > {code:java} > scriptEngine.config.tap { > // Code generation goes wrong here > optimizationOptions["indy"] = true > // This code is generated correctly > optimizationOptions.indy = true > }{code} > {code:java} > // Generated fault code - obviously no call to getOptimizationOptions() > boolean var2 = > true;DefaultGroovyMethods.putAt(((Class)((_main_closure1)this).getDelegate()).cast(((_main_closure1)this).getDelegate()), > "indy", var2); > // Correct code for the second line, via setProperty > boolean bool1 = > true;ScriptBytecodeAdapter.setProperty(Boolean.valueOf(bool1), null, > ((CompilerConfiguration)((_main_closure1)this).getDelegate()).getOptimizationOptions(), > (String)"indy"); > {code} > Compilation works, but I get a runtime error, which is easily explicable > given the generated code: > Exception in thread "main" > org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast > object 'org.codehaus.groovy.control.CompilerConfiguration@15d9bc04' with > class 'org.codehaus.groovy.control.CompilerConfiguration' to class > 'java.util.Map' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9603) Assignment of Map literal to Map element fails to compile (static)
Jochen Eddelbuettel created GROOVY-9603: --- Summary: Assignment of Map literal to Map element fails to compile (static) Key: GROOVY-9603 URL: https://issues.apache.org/jira/browse/GROOVY-9603 Project: Groovy Issue Type: Bug Components: Static compilation, Static Type Checker Affects Versions: 3.0.4, 3.0.3 Reporter: Jochen Eddelbuettel Declare a Map. When trying to put a map literal into that map, assignments in property style (map.key = ...) and subscript style (map[key] = ...) fail with *[Static type checking] - No such property: ... for class: java.lang.Object* First assigning to a local variable gives no such problems. If the Map were to contain objects of a specific type, coercion from map to that particular type would make sense. This coercion from Map to Object makes to sense. A Map is an Object and should simply become the new value for that particular key, which is just what is happening with regular compilation. Same for Map and Map map) { def innerMap = [ foo: "bar", bar: "foo" ] // No problem on this assignment map.someProp = innerMap assert map.someProp["foo"] == "bar" // The next three lines should all be equivalent // but the 2nd and 3rd don't CompileStatic map.put("someProp", [ abc: "efg" ]) map["someProp"] = [ abc: "hij" ] map.someProp = [ abc: "klm" ] assert map.someProp["abc"] == "klm" } {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9379) Binding shadows getters in script or base script
[ https://issues.apache.org/jira/browse/GROOVY-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109437#comment-17109437 ] Jochen Eddelbuettel commented on GROOVY-9379: - Well IntelliJ IDEA just recently caught on to the problem. It did pick up the class set by @BaseScript for a long time already, but now it only accepts explicit get() calls for type inference and marks as dubious. That helps avoiding this trap. > Binding shadows getters in script or base script > > > Key: GROOVY-9379 > URL: https://issues.apache.org/jira/browse/GROOVY-9379 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 3.0.0-rc-2 > Environment: CentOS 8, OpenJDK 11 >Reporter: Jochen Eddelbuettel >Priority: Major > > > {code:java} > boolean isPasswordOK() { false } > binding.setVariable("passwordOK", true) > if (passwordOK) print "You're in" > {code} > Accessing a variable available in the binding takes precedent over utilizing > a getter. This is extremely risky if the script author doesn't have full > control over the binding and forgets to call all his getters explicitly, > especially when they come from a BaseScript and he/she uses the code > suggestions from IntelliJ, which show any getters as simple property names. > The expected behaviour of the code above, should be NOT to let anyone in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9554) @Field variable access within closures broken
[ https://issues.apache.org/jira/browse/GROOVY-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109436#comment-17109436 ] Jochen Eddelbuettel edited comment on GROOVY-9554 at 5/17/20, 11:28 AM: I guess this [blog post|[https://e.printstacktrace.blog/groovy-script-closure-does-not-modify-field-annotated-variable/]] kind of explains that I'm looking at a bug that is deemed a feature, right? If @Field could generate a getter and a setter, that would allow forcing accesss to the field. An explicit call to the getter or setter would prevent the shadowing by the binding, which is the approach I've taken to make sure I'm reaching my @BaseScript defined properties. How is that for a future improvement? It could even be a separate AST Annotation, e.g. @PropertyField or @BeanField. was (Author: eddelplus): I guess this [blog post|[https://e.printstacktrace.blog/groovy-script-closure-does-not-modify-field-annotated-variable/]] kind of explains that I'm looking at a bug that is deemed a feature, right? If @Field could generate a getter and a setter, that would allow forcing accesss to the field. An explicit call to the getter or setter would prevent the shadowing by the binding, which is the approach I've taken to make sure I'm reaching by @BaseScript defined properties. How is that for a future improvement? It could even be a separate AST Annotation, e.g. @PropertyField. > @Field variable access within closures broken > - > > Key: GROOVY-9554 > URL: https://issues.apache.org/jira/browse/GROOVY-9554 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.4.15, 3.0.3 >Reporter: Jochen Eddelbuettel >Priority: Major > > > {code:java} > @groovy.transform.Field String abc > binding.variables.clear() > abc = "abc" > println binding.hasVariable("abc") > ["D","E","F"].each { abc += it } > println binding.getVariable("abc") > assert abc == "abcDEF" > {code} > If a variable is declared using the @Field annotation, it can be assigned to > in the main script body, but any assignment inside a closure (here the > closure used with each) ends up in the script binding instead. Assignments > within regular methods work fine, too. If the variables is accessed inside > the closure and it is not in the binding, then the value will come from the > field. As soon as it is in the binding, the binding variable takes precedence > over the field. In both cases the field declared with @Field needs to have > precedence over anything that is in the binding, just like local variables do. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9554) @Field variable access within closures broken
[ https://issues.apache.org/jira/browse/GROOVY-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109436#comment-17109436 ] Jochen Eddelbuettel commented on GROOVY-9554: - I guess this [blog post|[https://e.printstacktrace.blog/groovy-script-closure-does-not-modify-field-annotated-variable/]] kind of explains that I'm looking at a bug that is deemed a feature, right? If @Field could generate a getter and a setter, that would allow forcing accesss to the field. An explicit call to the getter or setter would prevent the shadowing by the binding, which is the approach I've taken to make sure I'm reaching by @BaseScript defined properties. How is that for a future improvement? It could even be a separate AST Annotation, e.g. @PropertyField. > @Field variable access within closures broken > - > > Key: GROOVY-9554 > URL: https://issues.apache.org/jira/browse/GROOVY-9554 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.4.15, 3.0.3 >Reporter: Jochen Eddelbuettel >Priority: Major > > > {code:java} > @groovy.transform.Field String abc > binding.variables.clear() > abc = "abc" > println binding.hasVariable("abc") > ["D","E","F"].each { abc += it } > println binding.getVariable("abc") > assert abc == "abcDEF" > {code} > If a variable is declared using the @Field annotation, it can be assigned to > in the main script body, but any assignment inside a closure (here the > closure used with each) ends up in the script binding instead. Assignments > within regular methods work fine, too. If the variables is accessed inside > the closure and it is not in the binding, then the value will come from the > field. As soon as it is in the binding, the binding variable takes precedence > over the field. In both cases the field declared with @Field needs to have > precedence over anything that is in the binding, just like local variables do. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9558) Wrong code for putAt on Map that is member of closure delegate
Jochen Eddelbuettel created GROOVY-9558: --- Summary: Wrong code for putAt on Map that is member of closure delegate Key: GROOVY-9558 URL: https://issues.apache.org/jira/browse/GROOVY-9558 Project: Groovy Issue Type: Bug Components: Static compilation Affects Versions: 3.0.3 Environment: Oracle JDK8 1.8.0_162, IntelliJ CE 2019.3.4, indy enabled Reporter: Jochen Eddelbuettel I'm compiling this little Closure with @CompileStatic enabled {code:java} scriptEngine.config.tap { // Code generation goes wrong here optimizationOptions["indy"] = true // This code is generated correctly optimizationOptions.indy = true }{code} {code:java} // Generated fault code - obviously no call to getOptimizationOptions() boolean var2 = true;DefaultGroovyMethods.putAt(((Class)((_main_closure1)this).getDelegate()).cast(((_main_closure1)this).getDelegate()), "indy", var2); // Correct code for the second line, via setProperty boolean bool1 = true;ScriptBytecodeAdapter.setProperty(Boolean.valueOf(bool1), null, ((CompilerConfiguration)((_main_closure1)this).getDelegate()).getOptimizationOptions(), (String)"indy"); {code} Compilation works, but I get a runtime error, which is easily explicable given the generated code: Exception in thread "main" org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'org.codehaus.groovy.control.CompilerConfiguration@15d9bc04' with class 'org.codehaus.groovy.control.CompilerConfiguration' to class 'java.util.Map' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9554) @Field variable access within closures broken
Jochen Eddelbuettel created GROOVY-9554: --- Summary: @Field variable access within closures broken Key: GROOVY-9554 URL: https://issues.apache.org/jira/browse/GROOVY-9554 Project: Groovy Issue Type: Bug Components: Compiler Affects Versions: 3.0.3, 2.4.15 Reporter: Jochen Eddelbuettel {code:java} @groovy.transform.Field String abc binding.variables.clear() abc = "abc" println binding.hasVariable("abc") ["D","E","F"].each { abc += it } println binding.getVariable("abc") assert abc == "abcDEF" {code} If a variable is declared using the @Field annotation, it can be assigned to in the main script body, but any assignment inside a closure (here the closure used with each) ends up in the script binding instead. Assignments within regular methods work fine, too. If the variables is accessed inside the closure and it is not in the binding, then the value will come from the field. As soon as it is in the binding, the binding variable takes precedence over the field. In both cases the field declared with @Field needs to have precedence over anything that is in the binding, just like local variables do. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9379) Binding shadows getters in script or base script
Jochen Eddelbuettel created GROOVY-9379: --- Summary: Binding shadows getters in script or base script Key: GROOVY-9379 URL: https://issues.apache.org/jira/browse/GROOVY-9379 Project: Groovy Issue Type: Bug Components: groovy-runtime Affects Versions: 3.0.0-rc-2 Environment: CentOS 8, OpenJDK 11 Reporter: Jochen Eddelbuettel {code:java} boolean isPasswordOK() { false } binding.setVariable("passwordOK", true) if (passwordOK) print "You're in" {code} Accessing a variable available in the binding takes precedent over utilizing a getter. This is extremely risky if the script author doesn't have full control over the binding and forgets to call all his getters explicitly, especially when they come from a BaseScript and he/she uses the code suggestions from IntelliJ, which show any getters as simple property names. The expected behaviour of the code above, should be NOT to let anyone in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-8100) MarkupBuilder cant yield before first tag
[ https://issues.apache.org/jira/browse/GROOVY-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Eddelbuettel updated GROOVY-8100: Affects Version/s: 3.0.0-rc-2 > MarkupBuilder cant yield before first tag > - > > Key: GROOVY-8100 > URL: https://issues.apache.org/jira/browse/GROOVY-8100 > Project: Groovy > Issue Type: Bug > Components: XML Processing >Affects Versions: 2.4.8, 3.0.0-rc-2 > Environment: Oracle Java 1.8.0_112, Windows 10 x64 >Reporter: Jochen Eddelbuettel >Priority: Major > > Trying to produce an HTML5 compliant !DOCTYPE before starting with the > HTML-Elements. Without setting the private field 'state' to 2, the output > does not show the yielded output. > {code} > def html = new groovy.xml.MarkupBuilder(new PrintWriter(System.out)) > //html.state = 2 > html.mkp.yieldUnescaped("\n") > html.h1("Header") > {code} > I suggest fixing this by changing the yield-Method to not check the state > before doing the output, so that we see some output when the initial state is > still 0: > {code} > void yield(String value, boolean escaping) { > if (state == 1) { > state = 2; > this.nodeIsEmpty = false; > out.print(">"); > } > // -- remove -- if (state == 2 || state == 3) { > out.print(escaping ? escapeElementContent(value) : value); > // -- remove -- } > } > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-8100) MarkupBuilder cant yield before first tag
[ https://issues.apache.org/jira/browse/GROOVY-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Eddelbuettel updated GROOVY-8100: Priority: Major (was: Minor) > MarkupBuilder cant yield before first tag > - > > Key: GROOVY-8100 > URL: https://issues.apache.org/jira/browse/GROOVY-8100 > Project: Groovy > Issue Type: Bug > Components: XML Processing >Affects Versions: 2.4.8 > Environment: Oracle Java 1.8.0_112, Windows 10 x64 >Reporter: Jochen Eddelbuettel >Priority: Major > > Trying to produce an HTML5 compliant !DOCTYPE before starting with the > HTML-Elements. Without setting the private field 'state' to 2, the output > does not show the yielded output. > {code} > def html = new groovy.xml.MarkupBuilder(new PrintWriter(System.out)) > //html.state = 2 > html.mkp.yieldUnescaped("\n") > html.h1("Header") > {code} > I suggest fixing this by changing the yield-Method to not check the state > before doing the output, so that we see some output when the initial state is > still 0: > {code} > void yield(String value, boolean escaping) { > if (state == 1) { > state = 2; > this.nodeIsEmpty = false; > out.print(">"); > } > // -- remove -- if (state == 2 || state == 3) { > out.print(escaping ? escapeElementContent(value) : value); > // -- remove -- } > } > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9321) @CompileStatic on call of static method on interface (Java 8): VerifyError
[ https://issues.apache.org/jira/browse/GROOVY-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16983778#comment-16983778 ] Jochen Eddelbuettel commented on GROOVY-9321: - No difference whether I pick my groovy jars from the indy or the lib directory of the distribution. Provided class file compiled with non-indy. > @CompileStatic on call of static method on interface (Java 8): VerifyError > -- > > Key: GROOVY-9321 > URL: https://issues.apache.org/jira/browse/GROOVY-9321 > Project: Groovy > Issue Type: Bug > Components: bytecode, Compiler >Affects Versions: 2.5.8, 3.0.0-rc-1 > Environment: Oracle Java 1.8.0_112, IDEA CE 2019.1 >Reporter: Jochen Eddelbuettel >Priority: Minor > Labels: @CompileStatic > Attachments: AgentTester.class, ErrorDetails.txt > > > This is the rogue line > def cfg = IDx4SessionPoolConfiguration.builder() > Changing this to something more normal like > {color:#172b4d}def cfg = new ConfigurationBuilder(){color} > {color:#172b4d}fixes the problems. So does not compiling with @CompileStatic > or running the code in a VM with -noverify option. The decompiled code looks > jolly good in jd-gui.{color} > {color:#172b4d}The problem does not exists in 2.4.15-indy{color} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9321) @CompileStatic on call of static method on interface (Java 8): VerifyError
Jochen Eddelbuettel created GROOVY-9321: --- Summary: @CompileStatic on call of static method on interface (Java 8): VerifyError Key: GROOVY-9321 URL: https://issues.apache.org/jira/browse/GROOVY-9321 Project: Groovy Issue Type: Bug Components: bytecode, Compiler Affects Versions: 3.0.0-rc-1, 2.5.8 Environment: Oracle Java 1.8.0_112, IDEA CE 2019.1 Reporter: Jochen Eddelbuettel Attachments: AgentTester.class, ErrorDetails.txt This is the rogue line def cfg = IDx4SessionPoolConfiguration.builder() Changing this to something more normal like {color:#172b4d}def cfg = new ConfigurationBuilder(){color} {color:#172b4d}fixes the problems. So does not compiling with @CompileStatic or running the code in a VM with -noverify option. The decompiled code looks jolly good in jd-gui.{color} {color:#172b4d}The problem does not exists in 2.4.15-indy{color} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-8100) MarkupBuilder cant yield before first tag
[ https://issues.apache.org/jira/browse/GROOVY-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Eddelbuettel updated GROOVY-8100: Description: Trying to produce an HTML5 compliant !DOCTYPE before starting with the HTML-Elements. Without setting the private field 'state' to 2, the output does not show the yielded output. {code} def html = new groovy.xml.MarkupBuilder(new PrintWriter(System.out)) //html.state = 2 html.mkp.yieldUnescaped("\n") html.h1("Header") {code} I suggest fixing this by changing the yield-Method to not check the state before doing the output, so that we see some output when the initial state is still 0: {code} void yield(String value, boolean escaping) { if (state == 1) { state = 2; this.nodeIsEmpty = false; out.print(">"); } // -- remove -- if (state == 2 || state == 3) { out.print(escaping ? escapeElementContent(value) : value); // -- remove -- } } {code} was: Trying to produce an HTML5 compliant !DOCTYPE before starting with the HTML-Elements. Without setting the private field 'state' to 2, the output does not show the yielded output. {quote} def html = new groovy.xml.MarkupBuilder(new PrintWriter(System.out)) //html.state = 2 html.mkp.yieldUnescaped("\n") html.h1("Header") {quote} I suggest fixing this by changing the yield-Method to not check the state before doing the output, so that we see some output when the initial state is still 0: {quote} void yield(String value, boolean escaping) { if (state == 1) { state = 2; this.nodeIsEmpty = false; out.print(">"); } // -- remove -- if (state == 2 || state == 3) { out.print(escaping ? escapeElementContent(value) : value); // -- remove -- } } {quote} > MarkupBuilder cant yield before first tag > - > > Key: GROOVY-8100 > URL: https://issues.apache.org/jira/browse/GROOVY-8100 > Project: Groovy > Issue Type: Bug > Components: XML Processing >Affects Versions: 2.4.8 > Environment: Oracle Java 1.8.0_112, Windows 10 x64 >Reporter: Jochen Eddelbuettel >Priority: Minor > > Trying to produce an HTML5 compliant !DOCTYPE before starting with the > HTML-Elements. Without setting the private field 'state' to 2, the output > does not show the yielded output. > {code} > def html = new groovy.xml.MarkupBuilder(new PrintWriter(System.out)) > //html.state = 2 > html.mkp.yieldUnescaped("\n") > html.h1("Header") > {code} > I suggest fixing this by changing the yield-Method to not check the state > before doing the output, so that we see some output when the initial state is > still 0: > {code} > void yield(String value, boolean escaping) { > if (state == 1) { > state = 2; > this.nodeIsEmpty = false; > out.print(">"); > } > // -- remove -- if (state == 2 || state == 3) { > out.print(escaping ? escapeElementContent(value) : value); > // -- remove -- } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GROOVY-8100) MarkupBuilder cant yield before first tag
Jochen Eddelbuettel created GROOVY-8100: --- Summary: MarkupBuilder cant yield before first tag Key: GROOVY-8100 URL: https://issues.apache.org/jira/browse/GROOVY-8100 Project: Groovy Issue Type: Bug Components: XML Processing Affects Versions: 2.4.8 Environment: Oracle Java 1.8.0_112, Windows 10 x64 Reporter: Jochen Eddelbuettel Priority: Minor Trying to produce an HTML5 compliant !DOCTYPE before starting with the HTML-Elements. Without setting the private field 'state' to 2, the output does not show the yielded output. {quote} def html = new groovy.xml.MarkupBuilder(new PrintWriter(System.out)) //html.state = 2 html.mkp.yieldUnescaped("\n") html.h1("Header") {quote} I suggest fixing this by changing the yield-Method to not check the state before doing the output, so that we see some output when the initial state is still 0: {quote} void yield(String value, boolean escaping) { if (state == 1) { state = 2; this.nodeIsEmpty = false; out.print(">"); } // -- remove -- if (state == 2 || state == 3) { out.print(escaping ? escapeElementContent(value) : value); // -- remove -- } } {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346)