Glad the community could help you & things look Groovy now G-)
Cheers,
mg
On 28/02/2020 09:02, Mickaël SALMON wrote:
Thank you very much for your support.
Except this tricky use case for which I'm sure will find a solution
for refactoring the existing scripts, Groovy integration in my Java
application is OK Now.
Chers, Mickael.
------------------------------------------------------------------------
*From:* Jochen Theodorou <blackd...@gmx.org>
*Sent:* Thursday, February 27, 2020 16:39
*To:* Mickaël SALMON <m...@sylob.com>
*Subject:* Re: please help : GroovyCastException: why ?
Am 27.02.20 um 16:16 schrieb Mickaël SALMON:
> Okay.
>
> In fact, I don't understand which this code works in Java but not in
> Groovy (even if naming a variable with a class name, not in camel case,
> is weird ...).
That is because Groovy has an overlap of variable names and class names
Java does not have.
In Java a=b is clearely assigning the value of variable b to a. If a is
a class instead it will fail compilation. If there is a variable b and b
class a, then the variable will be taken. To ensure you do mean the
class, you have to write a=b.class
In Groovy a=b is different.here b could be also a class b. if there is
no local variable b, then b might be still a class or (dynamic)
property. Thus the compiler will first check if it is a class and then
proceed to make it a (dynamic) property access. In dynamic Groovy this
expression def a=b may never fail compilation, because even if there is
no class b and no local variable b and no static property b, there is
still a possibly dynamic property b. If it then does not exist at
runtime, you will get a MissingPropertyException. But this mechanism
proofed to be problematic for the users. It turned out to be a problem
for the performance. Which is why we said, that if the name b follows
the class naming conventions of upper-case and camel-case, it must be a
class name and otherwise not.
bye Jochen
