Yes on demand compiling of Java sources just like Groovy by GroovyClassLoader would enable high performance code to be trivially put into a .java file in the project tree.

I'm not sure but I think that to generate the bytecode, you don't need the real class but its name. So the error we get is a hint and not a necessity.

Therefore, I'd like to try this: We run groovyc first. Groovyc needs to see all Java source files as well as the Groovy scripts. When a groovy script needs something from a java file, we parse it (just build the AST) and look if the symbols are there. If they are, the bytecode is generated.

This way, we wouldn't need the Java class files to exist when compiling Groovy code; the source code would be sufficient.

The AST parser is probably readily available through the Eclipse Java compiler. I think just checking for the file names is not sufficient if we have to resolve static symbols.

As for the second comment: I have been toying with the idea to release projects as source only. You get a JAR, the JAR contains all the sources and the runtime compiles what it needs to a cache. Never a headache when searching for bugs, source is always available, line number are correct, getting variable debug info is a cinch if you need them.

the name alone is not enough, because this way you don't get the compile time checks working. For example to test if all abstract methods overwritten.

I thought you can easily and freely mix groovy and java files in your project and reference classes/methods/members. But without such compiler you must choose which to compile first and some cases cannot be resolved at all. E.g.: Java class "J" uses groovy class "G" (compiled before "J"). But "G" cannot use "J" as when "G" is compiled, the "J" byte code (.class) does not exist yet). This makes groovy 50% flexible. Groovy compiler should resolve dependencies in "*.java" files as well.

All subtasks (only one) are finished. therefore this one is too I believe.

close off release 1.5.4