@Delegate methods not recognized by Java classes

Just wanted to mention that groovyc joint compilation isn't able to compile this either, and probably won't be for the foreseeable future. The Groovy Eclipse plugin is in a better position here due its deep integration with the Eclipse Java compiler, but given the limitation of groovyc, I wouldn't consider this a must have feature for the first release.

Thanks, I just confirmed groovyc can't compile this which is very disappointing. Why does Groovy introduce an annotation if you can't use it? Is the Groovy language just not stable enough for production environments? The only way I can get it to compile is to groovyc the groovy file, then javac the java file. Things like this and poor Maven support (GMaven doesn't compile this either, nor does it support generics) are really starting to kill my company's adoption of the groovy language.

> Why does Groovy introduce an annotation if you can't use it?

You can use the new members it introduces from other groovy. The problem is that the AST transform for Delegate runs late, too late for java to see the method it introduces. I have a prototype variant of Eclipse Groovy that enables this functionality but it is too hacky to release into the current builds. My prototype was based around @Singleton support (and the associated getInstance() method).

> Is the Groovy language just not stable enough for production environments?

I don't see it as a stability issue, it is a feature of how @Delegate support is implemented through AST transformation. If the AST transform ran before stub generation then joint compilation would work, but writing AST transforms that run that early can be difficult as the ast being modified may not be resolved. So the behaviour is well defined and predictable, but I agree not ideal for a mixed java/groovy project.

> The only way I can get it to compile is to groovyc the groovy file, then javac the java file.

Yep - since then by the time javac sees the groovy output the AST transforms have all successfully run.

I do plan to support this if I can, but not in M1.

not going to get to these for 2.0.1

Any decision as to whether or not we want to be supporting this in the future? Perhaps we can add a compile switch that allows it (even though such code would be broken if compiled by groovyc).

Personally, I'm skeptical of going beyond groovyc in terms of what programs can be compiled. This will only cause new problems. And to tell the truth, I don't see groovyc supporting this anytime soon, because it would probably mean to switch to a totally different joint compilation strategy (namely to feed groovyc with Java type information by parsing the Java sources).

Peters reason is precisely why I have done nothing about this feature. I was waiting to see what groovyc does about this.

If it were supported by our joint compiler strategy in eclipse, you'd simply have to use the eclipse compiler in batch mode outside of the IDE - and not groovyc directly. Basically it wouldn't be a problem groovyc has to solve any more...

Hmmm, using Eclipse compiler for my master build sounds scary to me. Will it work with Maven? Ant? Gradle? Build servers? What if you have IDEA/NetBeans users on your project? Just my 2 cent.

It should be no scarier than using the eclipse compiler to do the product builds for your java projects. Most of the SpringSource projects build using the eclipse compiler (they want their product builds to do the same thing as their IDE builds - plus the eclipse compiler has nicer error messages and more configurable warnings).

However, I understand your concern. This is another reason I haven't pushed it. I don't know if I yet want to support the eclipse joint compiler as the suggested batch compiler for joint projects, there are still bugs that need ironing out first. Will it work with Maven and ant? Should do, the eclipse compiler already does - but there likely need to be a few tweaks to ensure .groovy files are picked up and passed through (usage of a new task). Will it work with gradle? no idea, but I can't see why it wouldn't, I just don't know enough about gradle. I don't see a problem with users continuing to work in idea/netbeans if they wish to - the eclipse joint compiler will support a superset of what groovyc joint compilation can handle (eg. cross language @Delegate) - so users of those IDEs won't be able to write code it can't handle. I'm discussing with Graeme possibly changing grails to use it, instead of using groovyc.

Right now the only instructions for batch usage are here:
http://andrewclement.blogspot.com/2010/02/running-groovy-eclipse-joint-compiler.html
and they aren't as straightforward as I'd like.

I think of particular interest to you is how it handles Ast transforms, since Spock won't work if they don't work. I will say Ast transforms are not where we focus our efforts on groovy-eclipse - and that is probably a big factor in your concerns (understandably). Maybe I could initially recommend it for batch usage only for users not exploiting some funky transform. 'Supported' transforms would be those built into groovyc, those grails requires, and other well known well tested ones like Spock - if the users stray out of that space we don't recommend the eclipse joint compiler.

We can't do much about this since groovyc itself does not support this and we do not want to break compatibility with the compiler. We can look at this in the future if/when groovyc starts using groovy-eclipse for stub generation.

any progress in this issue since the latest comment is more than year old?

We haven't had any chance to look at this recently.