Thanks for the release of Groovy
2.1.0-rc-1. I like many of future which
included in this release. But i have
1. Can we use the custom type checker
to control the code generation?
For example, when static type error
"Method not found" occurred,
can we modify the generating code
to "invokeMethod()" call on
Strictly speaking, this is type checking, so no, you should not
change the AST. Technically, this is another story, you have access
to the AST so you can change it. This is not something I would
recommand, but you can.
It's so cool.
2. Custom type checker can be used for
more general checking?
For example, raise error if the
method name is not camel
case or class name is not starts
with lower case character.
Yes, you can. This is one of the goals of type checking extensions:
the ability to throw errors where the regular type checker would be
happy, as to raise errors in DSL context, for example.
I get it.
thanks again for very significant
Thank you for testing!
i'm writing Japanese short article introducing 2.1.0 new features,
I'd like to include your information.
Thank you again,
I hope to use groovyc's config script and CompilerCustomizationBuilder
on 'groovy' command in future version of groovy.Is there a any plan for it?
As a reminder of what's coming (pending the final
release notes document), here's what you can expect
from Groovy 2.1:
complete invoke dynamic support when
running with the "indy" JAR on JDK 7
upgrade to GPars
1.0: the Groovy distribution now bundles
the GPars 1.0 final release
annotation: to help IDEs and the static
type checker and compiler to know that method
calls in a method parameter closure are
delegated to another parameter of the method --
nice for DSLs like in Gradle build files
checking extensions: so you can type check
your DSLs at compile-time with your own logic
a meta-annotation system:
which allows you to define a new annotation
actually combining several others -- which also
means being able to apply several AST
transformations with a single custom annotation
custom base script
class flag for the groovyc compiler: to
set a base script class when compiling Groovy
configuration script: to let you define
various configuration options for the Groovy
compiler, like specifying custom file
extensions, various compilation customizers to
customizer builder: a special builder for
specifying compilation customizers
http:// prefix support for launching Groovy
scripts from the command line
and many bug fixes
and various minor improvements
Thanks a lot to all the contributors to this
And on behalf of the team, I wish our Groovy
users all the best for 2013!
Groovy Project Manager
SpringSource, a division of VMware