groovy

Build a compiler that can handle Groovy and Java source code

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0
  • Fix Version/s: 1.5
  • Component/s: command line processing
  • Labels:
    None
  • Number of attachments :
    0

Description

The Groovy compiler is able to compile Groovy source code, but not Java source code. Existing Java compilers compile Java source code, but not Groovy.

This leads to problems when trying to mix Groovy and Java classes freely in a project.

Examples:

(1) Factory pattern

Assume a Java interface, a Java implementation and a Java factory that returns an instance of the Java implementation.

If you want to replace the Java implementation with one written in Groovy, the Groovy implementation will depend on the Java interface, while the Java factory will depend on the Groovy implementation.

With separate compilers for Java and Groovy, the developer will either have to

  • manually assure a certain order of compilation (use Java compiler to compile Java interface, use Groovy compiler to compile Groovy implementation, use Java compiler to compile Java factory) - this can be done in an Ant build script, but e.g. not in Eclipse - or
  • use classloading instead of direct references (e.g. use Class.forName in the factory, introduce an IoC container) - this can have negative side effects (refactoring, obfuscation)

(2) Circular dependencies

See the following class hierarchy (thanks Jochen for the example - J1 and J2 are Java classes, G1 is a Groovy class):

class J2 extends G1 extends J1
class J1{
J2 x
}

While this is valid (and can be compiled if only Java or only Groovy classes are used), it it impossible to compile it with the current compilers due to circular dependencies between Java and Groovy classes!

Therefore, for a seamless integration of Java and Groovy, a "combined compiler" is needed that can handle the above cases without the need to change the architecture or the build process for a project.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Marc Palmer added a comment -

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.

Show
Marc Palmer added a comment - 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.
Hide
Permalink
Aaron Digulla added a comment -

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.

Show
Aaron Digulla added a comment - 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.
Hide
Permalink
blackdrag blackdrag added a comment -

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.

Show
blackdrag blackdrag added a comment - 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.
Hide
Permalink
movk added a comment -

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.

Show
movk added a comment - 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.
Hide
Permalink
Paul King added a comment -

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

Show
Paul King added a comment - All subtasks (only one) are finished. therefore this one is too I believe.
Hide
Permalink
Paul King added a comment -

close off release 1.5.4

Show
Paul King added a comment - close off release 1.5.4

People

  • Assignee:
    Unassigned
    Reporter:
    Michael Baehr
Vote (13)
Watch (10)

Dates

  • Created:
    Updated:
    Resolved: