[
https://issues.apache.org/jira/browse/GROOVY-11320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17945398#comment-17945398
]
Eric Milles commented on GROOVY-11320:
--------------------------------------
I have run into similar troubles with the unary plus. We used to write:
{code:groovy}
def foo() {
return "x"
+ "y"
}
{code}
Where "x" and "y" could be arbitrarily long expressions -- thus the line wrap.
We changed our Java coding standard to put operators at the end of the line to
prevent this from being seen as `return "x"` followed by dead code.
Does the unary plus operator do anything useful in Groovy? In Java it is
supposed to do widening or promotion on numeric types.
> Unable to resolve class when putting variables into brackets.
> -------------------------------------------------------------
>
> Key: GROOVY-11320
> URL: https://issues.apache.org/jira/browse/GROOVY-11320
> Project: Groovy
> Issue Type: Bug
> Components: parser, parser-antlr4
> Affects Versions: 4.0.10, 3.0.20
> Reporter: Philip Markus
> Priority: Major
>
> After migrating from Groovy 2.5 to Groovy 4.0, we experience some strange
> parsing behavior.
> {code:java}
> def foo = "spongebog"
> def bar = " squarepants"
> (foo) + (bar){code}
> The above snippet will yield a parser error "Unable to resolve class foo".
> This worked fine in 2.5, but seems to have been broken since 3.0. (Tried it
> in Groovy web console)
> I couldn't find any hints in the release notes, what might be the cause of
> this change and I am not sure what the expression (ClassName) even tries to
> perform. After all class names work as constants for their Class instance
> (without .class as in Java) anyway, with or without brackets.
> We know that those brackets are unnecessary, but for a reason that I am not
> aware of, we have lots of such expressions lying around in small snippets.
> Note: Our application is written in Java, but allows users to adapt runtime
> behavior using Groovy scripts and also is used for expressions in mail
> templates. which means we cannot just change the affected code, as they will
> still linger around in databases across different installations of our
> software.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
