groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: please help : GroovyCastException: why ? - introduce @ClassName annotation ?
Date Fri, 28 Feb 2020 20:25:22 GMT
Glad the community could help you & things look Groovy now G-)



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 <>
> *Sent:* Thursday, February 27, 2020 16:39
> *To:* Mickaël SALMON <>
> *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 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

View raw message