Message-ID: <1607866649.93511.1397902118696.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_93510_1336049976.1397902118695" ------=_Part_93510_1336049976.1397902118695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Take this simple script as an example:
Note that running
groovyc Greet.groovy does not produce any=
errors. Instead, a
MissingMethodException is thrown at runtim=
This is because Groovy is a dynamic language. Several other things could=
be happening to make this code valid at runtime. Using the MetaClass, you =
could add a
salude() method to the Greet class at runtime. You=
could also add a
state property to
would make the
welcome(..) call valid. See ExpandoMetaClass and TMPGroovy Categories.
Type checking to the rescue
If all you need is a scripting language and that you don't rely on the d= ynamic behaviour, since Groovy 2.0.0, you can add an annotation that will a= ctivate type checking:
The compiler will report errors at compile time instead of runtime. See&= nbsp;GEP 8 - St= atic type checking for details.
Actually, no. The way Groovy method selection is done, it actually takes= longer if you provide lots of static type information. Th= is could possibly change in the future, but as of Groovy 1.1 this is not th= e case. See this thread for more info.
In theory, we could. It would only work for methods available a= t compile time, and only for fields and parameters that you have s= trongly typed. But as we mentioned above, that hurts performance! Plus, the= re are a number of frameworks that rely heavily on dynamic methods (i.e. GORM ). In this case, you would get gobs of warnings, and likel= y just start ignoring them because it is just noise.
It might be scary to do away with all of your static typing and compile = time checking at first. But many Groovy veterans will attest that it m= akes the code cleaner, easier to refactor, and, well, more dynamic= . You should make all efforts to use unit tests to verify your intended beh= avior. Also keep in mind that Groovy also offers a slew of features to make unit testing easier as well.
Since Groovy 2.0.0, you can annotate your code with @CompileStatic. Be w= arned that while this will improve performance, it changes the semantics of= your code. See GEP 10 - Static compilation for details.