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
