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